精华简报：Windows On ARM 原生应用少？你可以试试这些改造方法
来源：少数派 sspai
文章链接：https://sspai.com/prime/story/create-your-own-windows-apps
TL;DR
Windows on ARM 经过近十年演进，转译运行 x86/x64 应用已接近传统平台，但转译带来的额外开销仍非最佳体验，而原生 ARM64 应用——尤其是国产常用软件——依然稀缺。文章提出两条“用户侧自救”路径：一是将单页 Web 服务通过 PWA 或 Pake CLI 直接打包为 ARM64 原生桌面应用；二是针对大量基于 Electron 框架的套壳应用，通过替换底层 Electron 运行时外壳（保留跨平台的 app.asar 业务包），将现有 x64 程序低成本改造成 ARM64 原生版本。借助 AI Agent 等工具，非开发人员也能完成架构分析与改造，从而在 ARM 设备上获得更低功耗、更高性能的原生体验。
核心观点与技术/商业洞察
1. Windows on ARM 的“能用”与“好用”之间存在体验鸿沟
- Windows on ARM 并非新事物：微软 2012 年 Windows RT 因无法兼容 Win32 失败，2016 年与高通合作通过动态二进制转译才奠定可用基础。
- 当前 Windows 11 + Prism 仿真引擎已让转译运行 x86/x64 应用成熟度大幅提升，日常使用接近传统 x86 平台。
- 但“能转译运行”不等于“最佳体验”：指令集转换带来额外 CPU 与内存开销，功耗更高、性能打折。
- 关键矛盾：开发商 ARM64 原生适配进度缓慢，尤其大量国产常用应用长期只提供 x86/x64 版本，用户被迫在“能用”与“好用”之间妥协。
2. 方法一：将单页 Web 端直接打包为 ARM64 原生客户端
- 许多高频在线服务（社交媒体、轻量网页工具）没有官方 Windows 桌面客户端，浏览器多标签页管理低效。
- PWA（渐进式 Web 应用）：利用 Chromium 内核浏览器（Chrome/Edge）的“安装”功能，可将响应式网站变成独立窗口、独立任务栏图标的轻量应用。但 PWA 仍受浏览器进程管理限制，无法脱离浏览器独立分发，窗口定制能力弱。
- Pake（开源工具）：基于 Tauri 架构，利用 Windows 内置 WebView2 渲染，可将任意网页打包成真正的 ARM64 原生
.msi安装包。安装包极小、内存占用低、免转译原生运行。 - 本地编译要点：官方云端工作流目前仅支持 x86/x64，需本地安装 Node.js、Rust 工具链与 LLVM，通过
pnpm install -g pake-cli或npm install -g pake-cli安装 CLI，然后执行pake <URL> --name "应用名"即可生成 ARM64 安装包。 - 技术洞察：Web 技术栈 + 系统级 WebView 正在成为轻量桌面应用的可行路径，Tauri 相比 Electron 在体积和资源占用上具有显著优势。
3. 方法二：将 Electron 套壳应用改造成 ARM64 原生版本
- 大量 Windows 桌面应用并非传统 C/C++ 原生程序，而是基于 Electron 框架的“容器化”应用。
- 识别 Electron 应用的特征：
- 根目录包含
locales文件夹及大量.pak资源文件； - 存在记录 Electron 版本号的
version文件或LICENSE.electron.txt； resources目录下有app.asar文件（打包核心前端代码）。
- 根目录包含
- Electron 架构的可改造性：Electron 由“运行时外壳（Chromium 渲染内核 + Node.js）”与“业务包（app.asar）”组成。官方 x64 安装包仅外壳编译为 x64 机器指令，而
app.asar内的界面与交互逻辑本质是跨平台的 JavaScript/HTML/CSS 代码。 - 换核原理：只要应用未依赖特定架构的 C++ 原生扩展（Native Addons），保留原
app.asar，替换为 ARM64 原生 Electron 外壳，即可实现免转译原生运行。 - 具体操作流程（以墨刀为例）：
- 下载原应用免安装 ZIP，解压后查看
version文件确认 Electron 版本（如 32.1.0）； - 下载对应版本的 Electron ARM64 预编译包（如
electron-v32.1.0-win32-arm64.zip）； - 将原包
resources/app.asar复制到新目录resources/下； - 将
electron.exe重命名为原程序名（如Mockitt.exe）； - 使用 Resource Hacker 将原版图标和版本信息写回新 exe，获得与官方一致的体验。
- 下载原应用免安装 ZIP，解压后查看
- 技术洞察：Electron 的“外壳/业务分离”设计意外地为用户侧架构迁移提供了便利，但也暴露出对原生扩展的依赖风险——一旦应用使用 Native Addons，换核方案将失效。
4. AI Agent 降低技术门槛，赋能非开发人员
- 文章强调“借助 AI Agent 等工具的辅助，即便是非开发人员也能轻松分析应用的底层架构并找到改造思路”。
- 这意味着架构识别、版本匹配、命令生成、错误排查等原本需要专业知识的工作，现在可以通过 AI 辅助完成，大幅降低用户自行改造的技术门槛。
- 商业洞察：AI 正在改变软件生态的“供给侧”——当官方原生适配缺位时，用户可以利用 AI 工具自行填补空白，形成一种“自给自足”的软件适配模式。
对行业的启发与影响
1. 用户侧“自给自足”将倒逼厂商加速原生适配
当用户能够通过简单改造获得 ARM64 原生体验时，官方 x64 应用的性能劣势会被进一步放大。长期忽视 ARM 平台的厂商可能面临用户流失或口碑下降，尤其是那些基于 Electron 的套壳应用——用户会发现“换核”后体验显著提升，从而对官方适配进度产生更强诉求。
2. Web 技术栈与跨平台框架的战略价值凸显
Pake/Tauri 和 Electron 的案例共同说明：基于 Web 技术的应用在跨架构迁移上具有天然优势。对于开发者而言，选择跨平台框架（如 Tauri、Flutter、Electron）意味着未来可以更低成本覆盖 ARM64 等新兴平台。这可能会加速行业从传统 Win32/C++ 向 Web 技术栈的迁移。
3. 开源工具与社区生态成为 ARM 生态成熟的关键补充
Pake、Electron 预编译包、Resource Hacker 等开源/免费工具，以及镜像源、社区教程，共同构成了用户侧改造的基础设施。在官方生态尚未完善时，开源社区的力量能够有效填补空白，推动 Windows on ARM 生态的实用化进程。
4. 安全与稳定性风险不容忽视
用户自行替换 Electron 外壳、修改 exe 资源，可能带来以下问题：
- 签名失效：修改后的 exe 失去官方数字签名，可能触发杀毒软件误报或企业安全策略拦截；
- 自动更新中断：改造后的应用无法通过官方渠道自动更新，需手动跟进新版本；
- 原生扩展兼容性：若应用依赖特定架构的 Native Addons，换核后可能出现崩溃或功能异常；
- 版权与许可风险：部分应用的 EULA 可能禁止修改或逆向，用户需自行评估合规性。
5. AI Agent 将重塑软件适配与维护模式
AI 辅助改造的兴起，意味着未来软件适配可能不再完全依赖厂商。用户或第三方社区可以利用 AI 自动分析应用架构、生成改造脚本、甚至批量处理多个应用。这可能催生新的“社区驱动适配”模式，但也对软件供应链安全提出新挑战。
总结：文章提供了一套实用且低门槛的 Windows on ARM 原生应用改造方案，揭示了 Web 技术栈与 Electron 架构在跨平台迁移中的独特优势。其深层意义在于：当官方原生适配滞后时，用户借助开源工具与 AI 辅助，能够主动突破生态短板，这既是对厂商的鞭策，也预示着软件适配模式正在从“厂商主导”向“用户参与”演进。