小米互联服务从 WinUI 3 换到 Electron,我拆包看了看

小米互联服务从 WinUI 3 换到 Electron,我拆包看了看

最近看小米互联服务的官网,发现一个有意思的变化:普通 Windows 版的要求写着 Windows 11,内测版的说明里却出现了 Windows 10。

我平时做 .NET 开发,顺手把两个安装包下载下来解包看了看。结果发现,普通版的主应用是 WinUI 3 + .NET 6,内测版已经换成了 Electron。

这两个变化放在一起,很容易让人想到:是不是为了兼容 Win10,才放弃了 WinUI 3?继续往下看,包里的证据指向了更具体的原因。

本文对应的是 2026 年 9 月 20 日官网下载的普通版 1.1.2.36 和内测版 2.0.2.524,只做了静态解包分析,没有安装运行。内测下载链接可能更新,后续版本不一定与本文相同。

旧版的技术栈很好确认。MiPcContinuity.runtimeconfig.json 中有下面这些字段,这里省略了无关配置:

{
  "runtimeOptions": {
    "tfm": "net6.0",
    "includedFrameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "6.0.36"
      }
    ]
  }
}

MiPcContinuity.deps.json 引用了 Microsoft.WindowsAppSDK/1.7.250606001,主程序集的类型元数据也能对应上:

ContinuityApp.App extends Microsoft.UI.Xaml.Application
ContinuityApp.MainWindow extends Microsoft.UI.Xaml.Window

所以这里能确认,旧版的主界面使用 WinUI 3,主应用使用 .NET 6,并且随包部署了 .NET 6.0.36 运行时。

顺便提一个判断 .NET 程序时容易踩的坑:它的 MiPcContinuity.exe 是 apphost,托管主程序集在同名 DLL 中。只看 EXE 没有 CLR 头,就认为程序不是 .NET 写的,会得出错误结论。

内测版则能找到 resources/app.asar,里面的 package.json 包含这些字段,同样只摘录相关部分:

{
  "version": "2.0.2-524.production",
  "miclawProductVersions": {
    "mac": "4.0.2",
    "win": "2.0.2"
  },
  "main": "dist-electron/quickLock.js",
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.27.1",
    "react": "^18.2.0",
    "electron-log": "^5.4.3",
    "electron-updater": "^6.8.3"
  }
}

入口代码实际导入了 Electron 的 app、crashReporter、safeStorage 等 API,结合前端代码,可以确认新版使用了 Electron + React。这里没有只凭 Chromium 的几个文件下判断,因为 CEF 等方案也会带这些东西。

不过,真正让我多看了两眼的,是旧版程序集中的平台属性:

TargetFrameworkAttribute: .NETCoreApp,Version=v6.0
TargetPlatformAttribute: Windows10.0.22621.0
SupportedOSPlatformAttribute: Windows10.0.17763.0

22621 对应 Windows 11 22H2,17763 对应 Windows 10 1809。

这两个版本号放在一起并不矛盾。目标平台版本涉及编译时面向的 Windows SDK 和可用 API;SupportedOSPlatform 声明平台支持范围,也用于平台兼容性分析。项目使用较新的 SDK,不等于运行系统必须达到同样的版本,调用新 API 时仍然需要考虑系统版本。

也就是说,不能看到 net6.0-windows10.0.22621.0,就直接翻译成“这个程序只能在 Win11 上运行”。反过来,程序集声明支持 Win10,也不能保证安装器、所有原生组件和具体功能都能在 Win10 上正常工作。

微软文档明确写着,WinUI 3 支持 Windows 10 1809 及以上,.NET 6 的历史支持系统也包含 Windows 10。因此,旧版官网写 Win11,不能归因于这两个框架本身不支持 Win10。

具体限制可能来自某个 Windows API、底层组件、安装逻辑,或者小米承诺支持和测试的系统范围。这次没有把限制定位到某一处代码,所以也没法断言改个版本判断就能用。

官网的说明还有一点需要留意:同一页保留了不同版本的条件。普通版对应 HyperOS 3 Beta 及以上,内测版写的是 HyperOS 4 及以上;Windows 10 64 位 1903 的要求出现在 2.0.x AI 跨设备能力说明中,不能扩大成所有功能都支持所有 Win10 版本。

弄清楚这一点,再看为什么换 Electron,就有意思多了。

我认为最有分量的线索,是新包中已经存在的跨平台代码。前面的配置同时声明了 Mac 和 Windows 产品版本,主程序和前端也都有对应的平台分支。这说明“跨平台”在这里有实际的代码基础。

如果两端共用页面、会话状态、设置项和大部分应用逻辑,一个需求就有机会在同一套代码里完成。继续单独维护一套 Windows XAML 界面,意味着这些变化还要再实现、再测试一遍。当然,系统权限、窗口行为、安装升级和设备能力仍然要分别适配,Electron 不会自动完成这些工作。

另一条很明显的线索是 AI。

新版包里除了 MCP SDK,还包含 AI 会话、Skills 和 MCP 管理代码。主程序能看到 agent_sessions、agent_messages、mcp_servers 等数据结构,以及 Agent 工具相关模块。安装包另外携带了 Skills、Python 3.11 和 MinGit。官网也明确提到了在 AI 对话框里同步手机通知、传送手机或平板照片等能力。

这时应用要处理的事情,就包括流式输出、Markdown 展示、工具调用状态、文件预览和会话管理了。React 和 Web 生态在这类界面上有现成的积累,Node 也方便接入相关工具。如果团队已经有一套跨平台 AI 客户端,沿用这套代码,比另起一套 WinUI 实现更有吸引力。

这是我结合包内信息做出的推测,小米没有在这里给出内部选型说明。另外,包中存在 hideMiclaw、productFlavor 等分支,代码被打包进去,也不代表对应功能已经向这个内测版的所有用户开放。

还有一个影响判断的细节:新版仍然有独立的原生互联层。

在 resources/native-interconnect/win32/ 下,可以找到 MiPcContinuity.exe、micontinuity_sdk.dll、MiScreenShare.exe、MiDropTransfer.dll 等组件。主进程会启动独立的互联进程,并通过 Windows 命名管道通信。

从这个结构看,Electron 和 React 承担界面及部分应用逻辑,Node/Electron 主进程负责协调,互联能力继续由独立进程和组件处理。原来的包也有互联 SDK、投屏组件和托管桥接层。

做 .NET 的人应该很熟悉这种分工:C# 通过包装层调用原生库,或者通过 IPC 与本地服务通信,都很常见。应用层换框架,并不意味着传输、投屏、编解码这些能力必须一起重写。至于两版底层到底复用了多少源码,仅凭目前的静态分析还无法确认。

所以,比起单独比较 WinUI 3 和 Electron 的控件、性能,我更在意团队能复用多少现有代码。原生互联组件已经独立出来,上层又要共享 Mac/Windows 的 AI 应用逻辑,这会明显改变选型的成本账。

但这个选择也有代价。

这次下载的两个安装包,普通版约 271 MB,内测版约 427 MB。新版体积确实增加了,不过它也多了 AI 组件、Python 等内容,不能把全部增量都算到 Electron 头上。

Electron 自带 Chromium 和 Node,采用多进程结构。对于长期挂在后台的互联工具,启动速度、空闲内存、CPU 唤醒和功耗都值得实测。没有这些数据,就不适合直接报一个“多占几百 MB 内存”的数字,更不能据此断定传文件或投屏一定变慢。传输吞吐和投屏延迟,还要看网络、编解码路径、原生实现和进程间通信。

维护成本同样需要算进去。.NET 6 已于 2024 年 11 月 12 日结束支持,旧版需要考虑升级,但升级到仍受支持的 .NET 也是一条路。Electron 则要持续跟进 Chromium、Node 和原生模块兼容性,官方只支持最新三个稳定大版本。换了技术栈,这些工作也不会消失。

如果让我做一个主要面向 Windows、团队又熟悉 C# 的互联工具,我依然会认真考虑 .NET。为了支持 Win10,就把整个应用层重写一遍,我觉得理由还不够。

但如果产品要共用 Mac/Windows 的界面和 AI 工作流,手里也已经有这套代码,那 Electron 就是可以理解的选择。对这次迁移,我更关心的是它在普通电脑上常驻时占多少资源,以及新增功能是否值得这些开销。这部分只能等实际体验和测试再说了。

参考资料:

posted @ 2026-09-20 10:06  吃饺子不沾醋  阅读(61)  评论(0)    收藏  举报