我在 Windows 上跑安卓应用这件事上前后折腾了大概三四年。最早是为了在电脑上直接处理手机端的文件传输还有几个只有安卓版本的效率工具后来慢慢变成了习惯——写东西的时候把阅读类、影音类应用挂在副屏上比反复拿手机顺手太多。这中间我试过第三方安卓模拟器、试过手机投屏、也认真用过一段时间已经停服的 WSA适用于 Android 的 Windows 子系统顺带把 Hyper-V、虚拟机平台、BIOS 虚拟化开关这些底层东西摸了个遍。很多人搜Windows 自带安卓模拟器其实指的就是 WSA 那套东西再往里一层就是 Hyper-V 提供的虚拟化底座。这套方案的优势是原生集成、窗口共享、剪贴板互通、文件系统能直接挂载劣势是它对硬件、系统版本、区域策略都有要求而且官方支持已经终止亚马逊应用商店也下线了所以现在再上手必须先把现状搞清楚否则很容易卡在安装第一步。下面这份内容我按是什么、要不要用、怎么装、装不上怎么办、不装它还有什么替代这条线来铺适合想在 PC 上用安卓应用的新手也适合已经在坑里、想找具体报错答案的老手。1. WSA 是个什么东西现在还有没有折腾的价值1.1 先把概念捋清楚它真不是模拟器严格来说WSA 不是模拟器这一点必须先说清楚不然后面所有判断都会歪。传统安卓模拟器比如基于 QEMU 的那一批做的事情是在一台机器的操作系统之上用软件方式虚拟出一整套 ARM 或 x86 硬件环境然后在这套虚拟硬件上装一个完整的安卓系统应用跑在这个虚拟系统里指令要经过翻译才能落到真实 CPU 上。这条路径的好处是兼容性强、跟宿主机隔离得干净代价是性能损耗高、图形渲染要额外过桥。WSA 走的是另一条路。它基于 Hyper-V 的虚拟化能力在 Windows 上跑一个轻量级的虚拟机里面是微软定制过的 Android 系统镜像。关键在于图形这一层它用了 GPU 半虚拟化也叫 GPU-PV的思路把宿主机的显卡能力直接透传给子系统渲染指令不需要在软件层面重写一遍。所以你用 WSA 跑游戏或者滚动列表帧率和流畅度通常比传统模拟器高一个档次CPU 占用也低。音频、窗口、剪贴板、文件系统这几个模块微软都做了和 Windows 外壳的对接应用窗口可以像普通 Win32 窗口一样拖动、贴边、任务栏固定。理解了这一层很多事情就顺了为什么 WSA 必须要开 Hyper-V 或虚拟机平台因为它的底座就是 Hyper-V。为什么它和 VMware、VirtualBox 会打架因为它们抢的是同一套底层虚拟化能力。为什么它比模拟器省资源因为图形不走软件翻译。1.2 官方支持已经停了为什么还有人在用这里有个必须交代的时间线。微软在 2024 年 3 月宣布亚马逊应用商店将于 2025 年 3 月 5 日之后不再在 Windows 11 上提供WSA 本身也随之停止支持。也就是说你现在从微软商店搜适用于 Android 的 Windows 子系统大概率是搜不到或者点了没反应的。但社区的热度并没有立刻降下来原因很现实。第一已经装好的机器可以继续用微软只是不再推送更新、不再提供商店分发本地已经落地的 msix 包和虚拟磁盘并不会凭空消失。第二社区一直在维护打包版本把 WSA 的安装包、依赖框架、甚至带 Google 服务框架的变体整理成离线包绕过商店直接侧载。第三对相当一部分人来说他们要的只是在电脑上开一个安卓应用不需要完整生态这种需求用旧版本完全够。提示本文提到的所有操作都基于公开的技术文档与社区实践涉及的安装包请从可信来源获取注意核对文件来源与完整性不要随意运行来历不明的可执行文件。1.3 三类人适合折腾两类人建议直接放弃以我的经验适合折腾 WSA 的大致是这三类系统是 Windows 11硬件支持虚拟化且不排斥命令行操作的人主要用来跑轻量应用阅读、笔记、影音、部分小游戏对应用生态完整性要求不高已经装了 Hyper-V愿意接受不再更新这个前提把它当作一个长期稳定的工具用。反过来这两类人我建议直接绕开机器是 Windows 10 的。WSA 从头到尾只面向 Windows 11Win10 上那些所谓移植版稳定性很差与其折腾不如换个方案。主力用途是重度手游、需要长期账号安全、需要完整应用商店生态的。停止支持意味着安全补丁和兼容性更新都断了这类场景用第三方模拟器更稳妥。2. 环境准备Hyper-V、虚拟化能力和 BIOS 里的那几个开关2.1 硬件与系统的硬性门槛自查在动任何安装包之前先把下面几项确认一遍能省掉后面一大半的无效折腾。第一项是系统版本。Win11 的 21H2 起始版本就能装但你没必要卡在最低版本上更新到较新的累积更新会少很多莫名其妙的启动失败。第二项是内存。WSA 默认会要 4GB 左右的虚拟内存额度官方建议宿主机 16GB 以上。我实测 8GB 的机器能跑起来但开两个应用之后跟浏览器抢内存会很明显体验一般。第三项也是最容易被忽略的是 CPU 虚拟化是否开启。判断方法很简单打开任务管理器切到性能选项卡点左侧的CPU右下角会有一行虚拟化。如果显示已启用说明 BIOS 里的开关是开的显示已禁用就得重启进 BIOS 去开。这一项不开后面所有安装步骤都会以各种奇怪的方式失败包括但不限于 WSA 启动黑屏、Hyper-V 服务启动报错、模拟器提示 VT-x 不可用。第四项是磁盘。WSA 的虚拟磁盘会随着使用逐步膨胀起步几个 GB用久了十几 GB 也正常系统盘留出至少 20GB 余量比较保险。2.2 BIOS 里的虚拟化开关到底叫什么名字这是问得最多的问题之一因为不同主板厂商叫法差别很大很多人进了 BIOS 翻半天找不到。Intel 平台的常见名字有这么几个Intel Virtualization Technology、Intel VT-x、Vanderpool Technology、Virtualization Technology。一般藏在 Advanced高级下面的 CPU ConfigurationCPU 配置里个别品牌机在 Advanced 的 System Agent Configuration 里面。AMD 平台一般叫 SVM Mode、AMD-V、Secure Virtual Machine位置通常在 Advanced → CPU Configuration 或者 Overclocking 相关菜单下。还有几个容易混淆的相关选项一并说一下IOMMU / VT-d这是给设备直通用的跟虚拟化能不能开是两回事不装 WSA 的话通常不用动Hyper-Threading跟虚拟化无关别搞混Secure Boot和虚拟化不冲突但如果装 Linux 双系统可能有影响。改完之后记得按 F10 保存退出部分主板需要断电重启才真正生效。我遇到过一台机器改完保存了但因为电源线没拔BIOS 电池供电的缓存没清重启后设置又回去了这种情况拔掉电源线等十秒再开机就行。注意BIOS 里改东西之前建议先记一下原来的值万一改错了还能还原。品牌办公机有些选项被厂商锁住了这种情况只能走系统层面的虚拟机平台方案别硬刷 BIOS。2.3 Hyper-V 与虚拟机平台的区别家庭版怎么办这是另一个高频困惑点Windows 功能列表里有两个相似的东西一个叫Hyper-V一个叫虚拟机平台Virtual Machine Platform到底该开哪个简单区分Hyper-V 是完整角色装完之后你会有 Hyper-V 管理器可以自己创建和管理虚拟机虚拟机平台是一个更底层的组件它只提供虚拟化的运行环境不给你管理界面。WSA 需要的是后者外加Windows 虚拟机监控程序平台Windows Hypervisor Platform这一项。专业版、企业版、教育版的 Windows 11功能列表里这两项都能看到直接在启用或关闭 Windows 功能里勾选重启即可。也可以用命令更快地处理dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism /online /enable-feature /featurename:HypervisorPlatform /all /norestart执行完重启一次。用 PowerShell 管理员身份运行普通权限会提示拒绝访问。家庭版的情况要特殊一些。Windows 11 家庭版的Windows 功能对话框里确实找不到Hyper-V这一项这不是你的系统坏了是版本策略。但好消息是虚拟机平台和Windows 虚拟机监控程序平台这两个在家庭版里是可用的而 WSA 恰恰只需要这两个。所以家庭版用户不必去找那些强行开启 Hyper-V的第三方脚本用上面两条 DISM 命令就够了。网上流传的脚本本质也是改注册表标识版本号再跑 DISM副作用未知能不用就不用。如果 DISM 执行后提示找不到功能名先确认系统版本号和累积更新某些早期预览版的功能名拼写有差异可以用这条命令先列出所有可用功能名核对dism /online /get-featureinfo /featurename:VirtualMachinePlatform2.4 装了 WSA 之后 VMware、VirtualBox 报错的处理这个冲突几乎每个用虚拟机的人都撞过。典型报错是您的主机不满足在启用 Hyper-V 或 Device/Credential Guard 的情况下运行 VMware或者 VirtualBox 直接提示 VT-x 不可用。根本原因Hyper-V 一旦启用它就抢占了 CPU 的虚拟化扩展Intel VT-x / AMD-V宿主机会运行在 Hyper-V 之上其他虚拟化软件只能退而求其次走 Windows Hypervisor Platform 接口。新版 VMware Workstation 和 VirtualBox 都支持这种共存模式但性能会打折扣而且必须显式配置。处理思路按你的实际需求分三种第一种以 WSA 为主VMware/VirtualBox 只是偶尔用。那就保持 Hyper-V 开启把 VMware 或 VirtualBox 升级到支持 WHP 的版本能跑就行接受性能损失。第二种两边都要用且对虚拟机性能敏感。那就用双启动配置的思路正常状态下关掉 Hyper-V 的自动启动需要 WSA 时再开。关闭 Hyper-V 自动启动的命令是bcdedit /set hypervisorlaunchtype off改完重启Hyper-V 就不会随系统启动了VMware 能拿回完整的虚拟化能力。想用 WSA 的时候改回 autobcdedit /set hypervisorlaunchtype auto这招我用了很久代价是每次切换要重启一次但胜在干净、不折腾。第三种冲突跟内核隔离有关。Windows 安全中心的内核隔离→内存完整性打开时会占用虚拟化关掉它可能就正常了。但这个功能是安全防护的一部分关不关要自己权衡我个人的建议是不要为了跑虚拟机长期关它。顺带说一句 Hyper-V 虚拟交换机的桥接。如果你在 Hyper-V 管理器里创建了外部类型的虚拟交换机它会绑定到物理网卡宿主机上会出现一个名为Hyper-V Virtual Ethernet Adapter的虚拟网卡。这个操作有个副作用桥接的瞬间宿主机会短暂断网配置完成后 IP 会重新获取。多人协作环境或者远程桌面连着的时候别做这一步容易把自己关在门外。而且桥接配置错了会导致宿主机网络异常遇到这种情况在网络连接里删掉虚拟交换机、把物理网卡的绑定还原就能恢复。3. WSA 安装全流程从依赖包到第一个 APK 跑起来3.1 安装包的获取与几个必需依赖WSA 的安装包本质是一个 msixbundle 格式的 Windows 应用包它不像普通 exe 那样双击就能装完需要几个框架依赖先就位。历史上通过微软商店安装时商店会自动处理依赖现在商店渠道下架了只能手工侧载依赖就得自己准备。一般来说需要这两个框架包Microsoft.VCLibs.140.00.UWPDesktopx64 版本Microsoft.UI.Xaml.2.x具体小版本号要跟 WSA 包要求的对应版本号必须对得上装错了会报一个很典型的错误0x80073CF3意思是包依赖解析失败。这个错我第一次遇到的时候排查了快一个小时最后发现是 UI.Xaml 的版本号比要求的低了一位。如果拿到的是社区整理的整合包通常依赖会一起打包目录结构类似这样WSA-Package/ ├── MicrosoftCorporationII.WindowsSubsystemForAndroid_x.x.x.msixbundle ├── Dependencies/ │ ├── Microsoft.VCLibs.140.00.UWPDesktop.appx │ └── Microsoft.UI.Xaml.2.x.appx如果只拿到单个 msixbundle 没有依赖可以单独去下载对应的框架包注意架构要选 x64。提示核对文件来源是这一步最重要的事。应用包本质上是可以执行任意代码的来源不明就不要装。可以顺手看一下文件属性里的数字签名信息正规渠道的包会有签名。3.2 用 PowerShell 侧载安装的完整命令准备工作做完安装本身只有一条命令。以管理员身份打开 PowerShell切到包所在目录Add-AppxPackage -Path .\MicrosoftCorporationII.WindowsSubsystemForAndroid_2210.40000.7.0_x64_ARM64.msixbundle -DependencyPath .\Dependencies\Microsoft.VCLibs.140.00.UWPDesktop.appx, .\Dependencies\Microsoft.UI.Xaml.2.8.appx几个细节解释一下。-DependencyPath 后面跟的是逗号分隔的依赖列表路径有空格的话要加引号不用多说。包名里的架构标识 x64_ARM64 表示这个包同时包含 x86_64 和 ARM64 两种实现WSA 会根据宿主机自动选择。执行过程中如果弹出是否要安装此应用选安装即可。装完之后开始菜单里会出现适用于 Android 的 Windows 子系统这个应用点开是个设置界面。如果命令报部署失败先看错误码0x80073CF3依赖版本不匹配回去核对 UI.Xaml 版本0x80073CF9安装被策略拦截检查是不是有第三方安全软件在拦0x80073CFB同 ID 的包已经存在先卸载旧版本Get-AppxPackage -Name *WindowsSubsystemForAndroid* | Remove-AppxPackage卸载之后重新执行安装命令即可。需要提醒的是卸载会连同虚拟磁盘一起删掉里面有你的应用数据删之前先确认。3.3 打开开发者模式并用 ADB 连接装完之后第一件事不是急着装应用而是把 ADB 通道打通。打开 WSA 的设置界面找到开发人员模式开关打开它。下面会显示一行此处显示本地 ADB 连接的 IP 地址和端口正常情况下是 127.0.0.1:58526。ADB 工具从 Google 官方的 platform-tools 包里拿解开压缩包后是个 adb.exe建议把它所在的目录加进系统 PATH省得每次都 cd 来 cd 去。连接命令很简单adb connect 127.0.0.1:58526返回connected to 127.0.0.1:58526就是通了。再用adb devices确认一下列表里应该有一行127.0.0.1:58526 device注意末尾是 device 而不是 offline 或 unauthorized。如果是 offline把 WSA 设置里的开发人员模式关掉再开一次重新 connect如果是 unauthorized说明设备侧的授权弹窗没确认在 WSA 窗口里找一下有没有授权提示。有一点容易踩坑ADB 的版本别太老。platform-tools 建议用近两年的版本老版本 adb 连上新系统会报协议错误。3.4 侧载 APK 的三种姿势与架构兼容性判断通道通了装应用就有几种方式。第一种是纯命令行最直接adb install -r D:\apk\app.apk-r表示覆盖安装升级版本的时候用得上。批量安装可以写个循环把目录下的 apk 全过一遍。第二种是用带界面的第三方工具比如社区里流传的 WSA 工具类应用它们本质上是把 adb 命令包了一层拖拽 apk 进去自动执行。适合完全不想碰命令行的人但要注意这类工具的安全性。第三种是用应用商店。WSA 原本内置的是亚马逊应用商店现在这个渠道已经下线了。社区维护的版本有些集成了其他应用分发渠道这类集成的合法性和安全性需要你自己判断我不做具体引导。安装前有一件事必须确认APK 的 CPU 架构。WSA 运行在 x86_64 上它内置了 ARM 指令翻译层所以理论上 arm64-v8a 的包也能跑但翻译过来的性能会比原生 x86_64 包差一截某些强依赖原生库的应用尤其是大型游戏直接闪退。判断方法有好几种。最省事的是看文件名很多下载站会标arm64-v8a、armeabi-v7a、x86_64这样的后缀。也有专门提取 APK 信息的小工具能读出包里的架构信息。装完之后也可以用这条命令确认设备侧识别的架构adb shell getprop ro.product.cpu.abi返回 x86_64 就说明 WSA 的主 ABI 是 x86_64。再查一遍支持的 ABI 列表adb shell getprop ro.product.cpu.abilist会返回一串类似x86_64,x86,arm64-v8a,armeabi-v7a,armeabi的值这个列表越长说明翻译层的覆盖范围越广。4. 那些绕不开的报错从市场不可用到 adb 掉线4.1 This product is unavailable in your market 到底卡在哪这个提示是当年从商店渠道安装 WSA 时最经典的拦路虎原文是this product is unavailable in your market。它跟网络环境、商店区域设置、系统区域三者的组合有关。需要先把因果说清楚微软商店的商品可见性由账号区域和系统区域共同决定WSA 这个商品在部分区域是不上架的。所以当两者不一致或者账号本身所在区域不在上架范围内就会弹这句话。处理思路分两个方向。如果你还在用商店渠道先检查三处设置是否一致Windows 设置里的时间和语言→语言和区域→国家或地区微软账号的个人资料里的国家/地区商店应用本身的区域显示。三者统一之后重启商店再试。注意区域设置改动有冷却期不能随意频繁切换改之前想清楚。更实际的思路是换渠道既然商店渠道已经正式下线直接走前面说的离线包侧载根本不经过商店这个报错自然就不会出现。我后来所有机器都改成侧载安装再没碰过这个问题。4.2 启动黑屏、闪退与虚拟化冲突装完了点开黑屏或者闪一下就退这是第二高频的问题。按下面这个顺序排查基本能覆盖九成情况。先确认虚拟机平台和Windows 虚拟机监控程序平台这两个功能确实开了。用 DISM 查状态dism /online /get-featureinfo /featurename:VirtualMachinePlatform | findstr StateState 显示 Enabled 才算开了。如果显示 Disabled说明之前那条命令没生效或者被别的策略改了。再看事件查看器。WSA 的启动失败会在Windows 日志→应用程序里留下记录来源一般是 WsaClient 或者 Hyper-V 相关组件错误信息比界面上那个启动失败有用得多。第三排查虚拟化冲突。如果你同时装了 VMware 或 VirtualBox检查它们有没有在后台跑着虚拟化服务。有些杀软和加固软件也会占用虚拟化能力尤其是那种带沙箱功能的。第四检查显卡驱动。WSA 的图形走 GPU 半虚拟化驱动太老会导致初始化失败。把显卡驱动更新到近一年的版本再试这条看起来像套话但我确实遇到过两台机器是驱动问题。第五看内存。前面说过 WSA 默认要吃 4GB 左右的虚拟内存8GB 物理内存的机器在开了一堆浏览器标签之后启动失败很常见。关掉些后台程序再试一次。注意如果排查到一半想重置环境别直接删安装目录。正确做法是在 WSA 设置界面里找重置相关的选项或者在设置 → 应用 → 已安装的应用里找到它执行高级选项里的重置这样能把虚拟磁盘状态清干净而不残留。4.3 adb devices 空白、58526 端口连不上这类问题的现象是adb connect直接超时或者连上了但列表里看不到设备。按下面的思路走。第一确认端口号是不是 58526。这个端口不是固定的WSA 每次启动可能会变设置界面里那行此处显示本地 ADB 连接的 IP 地址和端口才是准的照抄那上面的值。我就干过一次拿着教程里的默认端口连了半天其实自己机器上是另一个。第二确认开发人员模式是开着的。关闭再打开一次会重新初始化 ADB 服务。第三端口占用。本机上可能已经有别的程序占用了这个端口用这条命令查netstat -ano | findstr 58526如果输出的 PID 不是 WSA 相关进程说明端口被抢了重启 WSA 会重新分配。第四防火墙。本机回环连接一般不受防火墙影响但如果系统上有第三方安全软件做了端口过滤可能会拦。临时关掉安全软件试一次能快速定位。第五adb server 版本冲突。如果你电脑上同时装了多个来源的 adb比如 Android Studio 自带的、单独下的 platform-tools、某个模拟器附带的它们会互相抢 5037 端口。统一用一份 platform-tools其他全从 PATH 里去掉adb kill-server adb start-server adb connect 127.0.0.1:实际端口这套流程走下来基本上没有连不上的情况。5. 不用 WSA 的几条替代路线横向比一比5.1 第三方安卓模拟器谁更适合长期用如果 WSA 这条路走不通第三方模拟器是最直接的替代。市面上主流的那几款底层技术路线不太一样适用场景也不同。基于 VirtualBox 的那一类兼容性最广老版本 Windows 上也能跑缺点是图形性能一般跑大型游戏吃力。基于自研虚拟化层的那一类图形优化做得好帧率表现接近原生但对硬件和驱动有要求而且安装时会一并装驱动和服务卸载不干净会留下残留。Android Studio 自带的 AVD 是最干净的纯开发用途、可定制性最强但启动慢、资源占用高不适合日常使用。我的选择逻辑是这样的日常轻量应用优先 WSA重度游戏用图形优化好的第三方模拟器开发调试用 Android Studio 的 AVD只是偶尔用一下那就直接用手机投屏别装任何模拟器。选的时候有几个指标值得看一眼对比维度传统虚拟化方案图形优化方案AVD 开发方案图形性能一般好中等兼容性最好较好好资源占用中等较高高系统残留少较多少适合场景轻量应用、老机器游戏、影音开发调试5.2 手机投屏与云手机低配机器的两条活路投屏这件事被严重低估了。如果你只是想在电脑大屏上用手机上的某个应用根本不需要模拟器把手机画面投到电脑上、用鼠标键盘反向控制就行。开源方案里有基于 scrcpy 的画面延迟低、支持剪贴板互通、还能直接拖拽文件。手机厂商自己的多屏协同功能做得更顺手前提是手机和电脑是同一品牌生态。投屏的优势很明显完全不占电脑资源应用跑在真实手机上账号安全性和兼容性都是最好的。缺点是手机得在旁边、得保持连接而且有些应用会检测投屏状态限制功能。云手机是另一条路。它的逻辑是把安卓实例跑在远端服务器上你本地只是看画面。好处是对本地硬件几乎没要求老电脑、轻薄本都能用坏处是依赖网络质量延迟和画质是绑定的而且涉及账号登录的场景要仔细评估数据流向。5.3 社区维护的 WSA 分支值不值得上WSA 停更之后社区里出现了一些维护分支做的事情主要是重新打包安装包、更新依赖框架、有的还集成了额外的服务框架或者权限管理工具。值不值得上我的判断标准有三条。一是你的机器已经装好了原版且用着没问题那没必要动原版稳定就行。二是你需要在全新机器上装官方商店又下架了那社区整合包是相对省事的路径但务必只从有持续维护记录、有明确更新日志的项目获取。三是你不确定来源是否可靠那就别用安卓系统镜像是很底层的组件来源不明的包带来的风险不是能跑两个字能抵掉的。有一点要明确无论哪个分支它都建立在微软已经停止维护的代码基础上安全更新这条线是断的。把它当工具用可以别把它当长期依赖。5.4 APK 转 EXE这件事得先把话说透这个关键词的搜索量一直很高但我得说清楚不存在把 APK 直接编译成原生 Windows 可执行文件的通用方案。市面上打着APK 转 EXE旗号的工具做的事情基本是下面两类之一。第一类是打包器。它把一个小型安卓运行环境加你的 APK 一起塞进一个 exe 文件里双击 exe 时先解压、再启动运行环境、最后加载 APK。本质还是模拟器只是把安装过程藏起来了。这类产物体积大、启动慢、兼容性取决于内置运行环境的版本。第二类是工程化路径。用跨平台框架重写应用或者用官方提供的桌面适配方案把安卓应用适配到桌面环境但这已经属于重新开发不是转换。类似 Cocos Creator 这种游戏引擎打包出来的 APK想上 Windows 得在引擎里重新出 Windows 平台的构建产物跟转 exe 是两回事。所以遇到一键转 exe的宣传先问自己一句它是不是只是给你套了个壳如果是那为什么不直接装个模拟器还省得被套壳工具捆绑些别的东西。6. 实测调优与数据管理几个少有人讲的细节6.1 性能参数怎么配才不卡WSA 的设置界面里有几个可调项配好了体感差别很大。内存分配不是越大越好。分配过大会和宿主机抢内存导致整体卡顿分配过小则应用容易被系统回收。我的经验值是物理内存的 1/4 到 1/316GB 内存的机器给 4GB 比较合适。有个细节是这个值改完要重启 WSA 才生效改完立刻试会觉得没变化。图形首选项一般有两档一档偏向性能一档偏向兼容。跑游戏优先性能档遇到画面撕裂或者渲染异常就切到兼容档。这个选项在不同硬件上的表现不一致值得花十分钟两种都试试选自己机器上更稳的那个。核心数分配同理给太多核会被调度打架我一般给 4 核。还有一条系统层面的优化在电源选项里把电源计划设成高性能尤其是笔记本平衡模式下 WSA 的后台进程容易被降频表现为前台应用帧率忽高忽低。另外把常用的 APK 放在本地 SSD 上安装别放在机械盘或者网络盘。安装过程本身要写大量小文件机械盘上能慢好几倍。6.2 虚拟磁盘、数据备份与迁移WSA 的所有数据都在一个虚拟磁盘文件里位置大致在%LOCALAPPDATA%\Packages\MicrosoftCorporationII.WindowsSubsystemForAndroid_8wekyb3d8bbwe\LocalCache\下面会有一个 Userdata.vhdx这个文件就是整个安卓系统的数据盘。你装的应用、应用产生的数据都在里面。备份它是整个迁移方案的核心。正确做法是先把 WSA 完全关掉在设置界面里找关闭相关的选项或者用任务管理器确认相关进程都退出了然后把这个 vhdx 复制一份到别的地方。恢复的时候反过来关掉 WSA把备份的文件覆盖回去。注意占用中的 vhdx 复制出来是不完整的一定要先关。应用级别的数据备份还有 adb 这条路adb pull /sdcard/Download ./backup这能把你放在共享目录里的文件拉出来Android 12 之后系统对应用私有目录的访问限制变严私有数据通过 adb 直接拉可能拉不到全部需要应用自己支持导出。还有一个容易被忽略的点安卓应用的沙盒目录结构。你如果看过安卓里的文件路径会见到类似content://开头的 URI还有一些形如Android/data/包名/的路径。前者是内容提供器ContentProvider暴露出来的接口后者的Android/data目录从 Android 11 开始对普通文件管理器做了访问限制这就是为什么很多人在电脑上找不到某些应用的缓存目录。理解这一层找文件的时候就不会瞎翻。6.3 常见故障速查表把前面散落的问题整理成一张表遇到问题直接对号入座。现象最可能的原因处理方向安装包部署失败 0x80073CF3框架依赖版本不匹配核对 VCLibs 和 UI.Xaml 版本安装时报同 ID 已存在旧版本未卸载干净用 Get-AppxPackage 查找后移除启动黑屏、闪退虚拟机平台未启用或虚拟化冲突查 DISM 状态、关掉其他虚拟化软件adb 连接超时端口不对或开发人员模式已关照设置界面里的实际端口连重开模式应用装上就闪退APK 架构不匹配或依赖原生库换 x86_64 包或换 arm64 版本试商店提示区域不可用账号区域与系统区域不一致统一下区域设置或直接走侧载换了 VMware 后提示不支持Hyper-V 抢占了虚拟化扩展用 bcdedit 切换 hypervisorlaunchtype桥接虚拟交换机后断网物理网卡绑定被改删掉虚拟交换机还原原绑定这张表里的每一条我都实际撞过处理方式也是验证过的。真正麻烦的是那些不在表里的问题遇到那种情况养成先看事件查看器的习惯比在搜索引擎里反复试关键词效率高得多。最后分享一个我自己一直在用的习惯给 WSA 的虚拟磁盘做一个定期快照式的备份。我大概每个月关掉它、复制一次 vhdx 到移动硬盘成本很低但省掉过至少两次彻底重装的麻烦——尤其是某些应用的账号在重装后需要重新验证、而验证又依赖旧设备环境的时候这个备份就是救命稻草。