桌面应用【免费下载链接】SoundSwitchC# application to switch default playing device. Download: https://soundswitch.aaflalo.me/项目地址https://gitcode.com/gh_mirrors/so/SoundSwitch点击查看免费下载SoundSwitch 是一款通过热键在播放/录音设备间快速切换的 Windows 桌面应用C# / WinForms。其主工程SoundSwitch/下的Framework/目录是整个应用的运行时主干runtime backbone音频编排、横幅通知、配置持久化、Profile 管理、自动更新、托盘集成、任务调度与 WinAPI 适配全部集中于此。本文以 SoundSwitch/Framework/AGENTS.md 为骨架结合仓库源码逐条讲解该层的职责边界、硬性变更规则、线程模型与验证方式帮助开发者理解哪些逻辑必须进 Framework、哪些绝不能进 UI这一核心架构原则并掌握配置迁移、事件驱动 UI、工厂模式等落地实现。一、Framework 层的 Scope它到底管什么AGENTS.md开篇明确了该域的职责范围This domain contains app infrastructure: audio orchestration, banner notifications, configuration, profiles, updater, tray integration, job scheduling, and WinAPI adapters.对应到仓库目录即 SoundSwitch/Framework/ 下的核心模块领域Scope 原文对应目录 / 关键文件职责说明audio orchestration音频编排Framework/Audio/、Framework/DeviceCyclerManager/设备枚举、缓存放音、设备循环切换器DeviceCyclerbanner notifications横幅通知Framework/Banner/置顶横幅窗体、横幅位置/显示信息、独占全屏检测configuration配置Framework/Configuration/配置加载/保存、schema 迁移profilesProfileFramework/Profile/Profile 模型、热键/进程/窗口等触发器、ProfileManagerupdater自动更新Framework/Updater/更新检查、下载、签名/校验、安装器调用tray integration托盘集成Framework/TrayIcon/图标切换、双击动作、Tooltip 信息、主题图标job scheduling任务调度Framework/Threading/JobScheduler与受限并发任务调度器WinAPI adapters系统 API 适配Framework/WinApi/、Framework/AutoStart.cs、Framework/HourGlass.cs键盘钩子、主题读取、开机自启、沙漏光标等系统能力其余基础设施还包括 Framework/NotificationManager/通知管理、Framework/Telemetry/遥测、Framework/Toast/Windows Toast 渲染、Framework/Minidump/崩溃转储与 Framework/Factory/抽象工厂基础设施。补充说明AGENTS.md是面向开发者的领域约定文档主工程根目录的 SoundSwitch/AGENTS.md 提供了更高层的 Domain MapFramework / Model / UI / Localization / Services / Util可作为理解本层定位的上下文本文聚焦 Framework 本身。二、核心职责让 Framework 成为运行时主干而非 UI 的附庸AGENTS.md列出三条 Responsibilities本质是回答代码该放哪、数据该怎么流2.1 Keep this layer as the runtime backbone of the app应用的一切非界面核心逻辑都应在 Framework 层完成。典型例子是配置入口 Framework/Configuration/AppConfigs.cspublic static class AppConfigs { public static ISoundSwitchConfiguration Configuration { get; } ConfigurationManager.LoadConfigurationSoundSwitchConfiguration(); }整个应用通过这一个静态入口读取配置UI 层Settings窗体等只消费ISoundSwitchConfiguration暴露的契约不直接触碰文件读写与迁移逻辑。2.2 Centralize OS and device integration here rather than pushing it into UI codeOS/设备集成全部收拢在 Framework 与 SoundSwitch.Audio.Manager/ 中。例如横幅通知的底层入口 Framework/Banner/BannerManager.cs 内部会做独占全屏检测并自动降级到 Toastif (OperatingSystem.IsWindowsVersionAtLeast(10, 0, 17763) ExclusiveFullscreenDetector.IsForegroundInExclusiveFullscreen()) { Log.Debug(Foreground window is in exclusive fullscreen — routing to Toast notification); ToastNotificationRenderer.Show(data); return; }这类运行环境感知逻辑若散落在 UI 代码中会造成横竖屏、全屏游戏等场景难以统一维护——这正是该规则存在的意义。2.3 Route persistent settings throughAppConfigs.Configurationand keep migrations in sync持久化设置必须经由AppConfigs.Configuration路由任何 schema 变更都必须在SoundSwitchConfiguration中同步迁移详见第三节。三、配置 Schema 变更规则向后兼容 必须迁移这是AGENTS.mdChange Rules 的第一条也是 Framework 层最关键的工程约束Any configuration schema change must remain backward compatible and be migrated inSoundSwitchConfiguration.3.1 加载即迁移的机制Framework/Configuration/ConfigurationManager.cs 展示了加载 → 反序列化 → 触发迁移 → 落盘的完整链路obj.FileLocation filePath; if (obj.Migrate()) { obj.Save(); } return obj;即每次启动加载配置时若Migrate()返回true发生了任何迁移迁移后的配置会被立即写回 JSON 文件保证老版本用户升级后配置自动平滑升级。配置文件为 JSON按类型名命名存放于ApplicationPath.Default目录下SoundSwitchConfiguration.json序列化时使用NullValueHandling.Ignore以保持文件精简。3.2 Migrate() 的落地实现MigratedFields 幂等机制Framework/Configuration/SoundSwitchConfiguration.cs 中的Migrate()方法是迁移逻辑的唯一实现地。它维护一个HashSetstring MigratedFields来记录已经迁移过的字段从而保证迁移幂等——同一字段只迁移一次升级链条上多版本连续迁移不会重复执行。真实的迁移案例源码可查设备列表结构升级老字段SelectedPlaybackDeviceListId/SelectedRecordingDeviceListId纯 ID 字符串集合被迁移进新的SelectedDevicesHashSetDeviceInfo含流向 eRender/eCapture 与时间戳随后清空旧字段。通知类型废弃迁移ToastNotification被迁移为BannerNotificationCustomNotification被迁移为SoundNotification——对应通知类型的演进历史。通知设置拆分老版本只有一个通知类型迁移逻辑检测到!NotificationAdvancedMode且两个新字段均为NoNotification时将旧值复制给 Profile 通知与麦克风静音通知SplitNotificationSettings 迁移。属性改名迁移PersistentMuteNotification已[Obsolete]迁移到MicrophoneMuteBannerKeepSystrayIcon已[Obsolete]迁移为SwitchIcon的枚举值。Profile 体系迁移旧ProfileSettings含 HotKey / ApplicationPath 触发器迁移为新的Profile.Profile对象集合并重建Trigger列表。行为修复类迁移例如SwitchForegroundProgram_force_off强制关闭前台切换、CleanupSelectedDevices按NameClean去重、CleanupProfilesForeground、ProfileWin7Win7 下禁用前台切换、SwitchForegroundProgram_fix重置进程设备配置。配置默认值也在此类中定义例如FirstRun true、PlaybackHotKey CtrlAltF11、RecordingHotKey CtrlAltF7、MuteRecordingHotKey CtrlAltM、UpdateCheckInterval 3600*2424 小时、SwitchDeviceNotification BannerNotification、BannerOnScreenTime 3 秒、BannerOpacityPercentage 100、MaxNumberNotification 5等详见 SoundSwitchConfiguration.cs。开发者指引新增配置项时先在SoundSwitchConfiguration中声明带默认值的属性若涉及旧字段改名/废弃务必在Migrate()中补充对应迁移分支并用MigratedFields保证幂等。四、UI 与 Framework 的边界通过 Model/事件解耦禁止直接表单耦合第二条 Change RulesKeep UI-facing behavior exposed through model/events instead of direct form coupling.其含义是Framework 层负责产生行为如设备已切换但不直接操作窗体UI 层通过 SoundSwitch/Model/ 的模型与事件Events.cs、DeviceChangedEvent.cs获得通知并自行更新。典型佐证是 Framework/NotificationManager/NotificationManager.cs 的Init()它订阅模型事件而非监听表单事件——deviceService.DefaultDeviceChanged ModelOnDefaultDeviceChanged; notificationSettings.NotificationSettingsChanged ModelOnNotificationSettingsChanged; notificationSettings.CustomSoundChanged ModelOnCustomSoundChanged; notificationSettings.BannerSettingsChanged ModelOnBannerSettingsChanged;而横幅的真正渲染由 Framework/Banner/BannerForm.cs 的窗体完成但它由BannerManager统一调度UI 窗体之间互不直接引用。这保证了横幅、菜单、通知这类 UI 线程管理器可以在不触碰彼此内部状态的前提下协同工作。五、线程亲和性规则UI 线程管理器必须在 UI 线程上工作第三条 Change RulesPreserve thread-affinity rules for UI-thread managers such as banners, menus, and notifications.WinForms 控件的线程亲和性意味着任何窗体操作都必须在创建它的 UI 线程上执行。Framework 层在多个点显式维护这一约束Framework/Banner/BannerManager.cs 持有静态SynchronizationContext _syncContext并维护DictionaryGuid, BannerForm _bannerForms与单例/自定义位置横幅所有横幅创建与更新都经由该上下文调度。Framework/Updater/AutoUpdater.cs 在构造时捕获SynchronizationContext _context更新下载完成后用_context.Send(...)回到 UI 线程弹出MessageBoxprivate readonly SynchronizationContext _context SynchronizationContext.Current ?? new SynchronizationContext();后台任务统一交给 Framework/Threading/JobScheduler.cs 的IJobScheduler与LimitedConcurrencyLevelTaskScheduler调度避免在 UI 线程上做 IO/下载等阻塞操作。开发者指引新增任何会显示窗体/弹窗/横幅的 Framework 功能都必须像AutoUpdater一样捕获并回投SynchronizationContext纯后台逻辑则应交给JobScheduler。六、通知文本必须走本地化资源第四条 Change RulesUse localized strings for notification text and prompts.SoundSwitch 的本地化体系位于 SoundSwitch/Localization/每种文案一组.resx资源如AboutStrings、SettingsStrings、TrayIconStrings、UpdateDownloadStrings每种资源再按语言拆分为多份语言文件如zh-Hans、ja-JP、de等由 LocalizedStringProvider.cs 与 Factory/LanguageFactory.cs 统一解析。默认语言取自LanguageFactory.GetWindowsLanguage()见配置默认值。因此在 Framework 层写通知文案的正确做法是引用资源例如AutoUpdater中的UpdateDownloadStrings.wrongSignature、UpdateDownloadStrings.wrongChecksumNotificationManager的通知内容也由 Notification/NotificationContentBuilder.cs 结合本地化资源构建。禁止在 Framework 代码中内联硬编码用户可见字符串。七、扩展功能必须复用既有工厂与管理器第五条 Change RulesDo not bypass existing factories/managers when adding a new banner, notification, or profile behavior.Framework 层为可扩展点提供了统一的工厂抽象Framework/Factory/AbstractFactory、IEnumImpl、EnumImplList等与具体工厂Framework/NotificationManager/NotificationFactory.cs —— 依据NotificationType生成横幅/系统通知/声音/无通知等实现NotificationBanner、NotificationWindows、NotificationSound、NotificationNoneFramework/DeviceCyclerManager/DeviceCyclerFactory.cs —— 依据DeviceCyclerType生成不同循环策略Framework/Profile/Trigger/ 的TriggerFactory—— 依据枚举生成热键/进程/窗口等触发器Framework/TrayIcon/IconChanger/ 与IconDoubleClick—— 托盘图标行为枚举实现。新增横幅类型、通知类型或 Profile 行为时正确姿势是新增一个实现类 注册进对应工厂而不是在业务代码里散落if/switch分支。这与EnumImplList/AbstractFactory的设计目标一致枚举驱动的可插拔实现便于扩展与测试。八、Validation如何验证 Framework 层改动AGENTS.md给出两条验证要求Build the solution—— 至少执行dotnet build SoundSwitch.sln -c DebugSoundSwitch/AGENTS.md 亦明确此命令为最低验证标准。If audio or notification behavior changes, verify the related tests and event flows—— 音频/通知相关改动必须回归测试与事件流。仓库中与本层直接相关的测试包括SoundSwitch.Tests/AppSoundRuleMigrationTests应用声音规则迁移、DeviceCyclerTests设备循环、NotificationContentBuilderTests通知内容、ExclusiveFullscreenDetectorTests全屏检测、DeviceFormFactorDetectorTests、SettingsFormTests、LocalizationFallbackTests本地化回退、DarkThemeConsistencyTests暗色主题一致性等SoundSwitch.Audio.Manager.Tests/AudioDeviceEnumeratorGetDeviceTests、AudioPolicyConfigTests、SwitchProcessToRoutingTests等覆盖音频管理器底层。若改动涉及配置 schema可参照AppSoundRuleMigrationTests的模式为Migrate()编写迁移用例确保旧配置升级后字段与默认值符合预期。九、总结Framework 层开发的六条检查清单综合AGENTS.md的 Scope / Responsibilities / Change Rules / Validation在 Framework 层提交改动前应逐一自检归属正确OS 集成与设备编排是否收拢在 Framework而不是混入 UI 代码配置兼容改动是否涉及SoundSwitchConfiguration若是是否在Migrate()中补充了向后兼容迁移且保证幂等MigratedFields解耦UI 可见行为是否通过 Model/事件暴露而非直接操作窗体线程安全横幅/菜单/通知等 UI 线程管理器是否维持线程亲和性SynchronizationContextJobScheduler本地化所有用户可见文案是否走.resx资源而非硬编码字符串复用扩展点是否复用了既有 Factory/Manager而不是另起炉灶遵循这套约定Framework 层就能持续保持运行时主干的地位——集中、解耦、可迁移、可测试这也是 SoundSwitch 十余个基础设施模块能够长期稳定演进的核心原因。后续可结合 SoundSwitch/AGENTS.md全局 Domain Map、docs/architecture.md 与 docs/banner-manager.md 继续深入。赞分享桌面应用【免费下载链接】SoundSwitchC# application to switch default playing device. Download: https://soundswitch.aaflalo.me/项目地址https://gitcode.com/gh_mirrors/so/SoundSwitch点击查看免费下载相关推荐OpenHuman 配置迁移框架深度解析基于 schema_version 的启动期数据迁移机制OpenHuman 配置迁移框架深度解析基于 schema_version 的启动期数据迁移机制 OpenHuman开源个人 AI 助手支持 Mac /人工智能AI 应用本地部署AI Agent交互助手深度研究从 Graphcool Framework 迁移到 Prisma迁移总览与两层 GraphQL 架构解析从 Graphcool Framework 迁移到 Prisma迁移总览与两层 GraphQL 架构解析 导读 本指南是 Prisma 官方迁移指南Mig后端数据库GraphQLOHIF 3.12 到 3.13 迁移指南基础设施升级、API 变更与配置锁定OHIF 3.12 到 3.13 迁移指南基础设施升级、API 变更与配置锁定 本指南基于 OHIF Viewers 仓库 platform/docs/doc医疗健康前端音视频上一篇ant-design Pagination 更多分页省略页码实战大列表分页与折叠页码机制详解下一篇如何在10分钟内构建医疗AI训练数据集Synthea合成患者生成器揭秘创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考