QEMU 手機版的版本演化：從龐然大物到口袋裡的虛擬電腦

qemu 是什麼

如果你手上的 Android 手機能跑起一個完整的 Windows 7 作業系統，而且不需要 root、不需要刷機，只要從 qemu下載 拿到這個 33MB 的 APK——這件事聽起來有點不可思議，但它就是 qemu 做到的。

qemu 本質上是一個虛擬電腦模擬器。它不像是大家熟悉的 VirtualBox 或 VMware 那樣主要跑在桌面系統上，而是更底層、更靈活——它能在一個完全不同架構的 CPU 上，把另一個架構的指令逐條翻譯執行。x86 主機跑 ARM、ARM 主機跑 RISC-V，這些跨架構的事情，qemu 幹了二十多年。

而這次我們談的不是那個 Linux 命令列裡敲 qemu-system-x86_64 的龐然大物，是它在 Android 上的一個變體——一個啟動器（launcher），把常用配置做成圖形介面、把 Win7 镜像預先塞好、讓普通用戶也能在兩三分鐘內把自己的手機變成一台迷你 PC。

安裝

Android 版 qemu 的安裝比桌面版本簡單得多，但也有幾個獨特的前置條件需要注意。

首先是 APK 本身只有 33MB，算是輕量級。但它運行時需要一個完整的作業系統镜像——通常就是 Win7，镜像文件本身可能有好幾個 GB，這部分不包含在 APK 內，需要額外從 qemu官網 獲取或從其他地方複製進來。安裝包打開後，系統會引導你把镜像文件放到指定目錄，通常是手機內部存儲的 qemu/images/ 路徑下。

安裝時可能會遇到 Android 9 以上的存儲權限問題。第一次啟動時，qemu 會彈窗要求「所有文件訪問權限」——這是因為它需要直接讀取 SD 卡或內部存儲上的镜像文件，不走系統的 MediaStore 管道。這個權限如果拒絕了，啟動器會一直在「找不到镜像」的狀態打轉。

CPU 架構的選擇是安裝後的第一次配置。qemu 啟動器在啟動時會自動偵測手機的 CPU 架構——ARM64 手機預設跑 x86_64 模擬，這是最常見也最穩定的組合。具體參數含義可以參考 qemu文檔 的說明。如果你手動切到其他架構（比如模擬 ARM），效能會明顯下降，但功能上是允許的。盒數、CPU 型號這些參數第一次可以保持預設，之後在高級設置裡慢慢調整。

另外要提的一點是，安裝前確保手機至少有 10GB 以上的可用空間——镜像文件加上 qemu 運行時的臨時文件，會佔用不少存儲。

從核心專案到手機啟動器的版本演化

我關注 qemu 這個專案已經有些年頭了。說起來也挺有意思，當初我接觸它的時候，它還只是 Linux 伺服器上用來做跨架構編譯測試的工具，誰能想到二十多年後，它會以一個這麼「接地氣」的樣子出現在我的手機桌面上。

現狀：1.1.0 版本它長什麼樣

目前最新的 1.1.0 版本是一個乾淨俐落的啟動器。打開之後就是一個直觀的鏡像列表，預設已經綁好了 Win7 镜像，點一下就能啟動。圖形設定介面把桌面版需要通過命令列參數指定的選項（CPU 盒數、記憶體大小、磁碟配置）做成了滑桿和下拉選單，對普通用戶友好了很多。

但它仍然保留了 qemu 的靈魂——高級模式下你仍然可以手動填寫 CPU 架構、修改 -accel 參數、自訂網路模式。啟動器只是個殼，底下跑的還是那個經典的 TCG 指令翻譯引擎。

從技術參數來看，1.1.0 版本的效能相比早期版本提升了不少——在旗艦 ARM64 手機上模擬 x86_64 的 Win7，啟動時間從之前的兩分多鐘縮到了四十秒左右，日常使用（瀏覽器、文書處理）也不會有明顯卡頓。這背後是好幾個版本迭代的優化積累。

來路：二十多年的三個關鍵轉折

qemu 的故事要從 2003 年說起。法國工程師 Fabrice Bellard 創建了這個專案，最初的目標很簡單——讓 Linux 開發者能在自己的主機上編譯並測試其他架構的程式。那個時候它甚至不是一個虛擬機器，而是一個 user-mode 的指令翻譯器。

第一個大轉折是硬件加速的引入。早期 qemu 靠純軟體翻譯（TCG）跑所有指令，效能低得可憐。2007 年前後，Linux 核心的 KVM 模組成熟起來，qemu 開始透過 /dev/kvm 把 CPU 指令直接丟給硬件執行——這就是後來大家熟知的 KVM 加速模式。這個轉變讓 qemu 的效能從物理機的 15% 飆到了 90% 以上，也讓它從一個開發工具變成了真正可用的虛擬機器方案。

第二個轉折是跨平台擴張。macOS 的 Hypervisor.framework、Windows 的 WHPX、甚至 Android 本身——qemu 陸續接上了各平台的硬件加速介面。到這個階段，qemu 已經從「Linux 上的一個工具」變成了「幾乎所有平台上都有一個版本」的通用虛擬化引擎。

第三個轉折就是我們手上這個 Android 啟動器了。桌面版 qemu 的命令列參數有上百個，普通用戶根本碰不動。於是有人開始給它做圖形前端——virt-manager、GNOME Boxes 都是這條路線上的產物。但這些前端本質上還是「給開發者用的」，真正面向普通消費者的 Android 啟動器，是這兩年才出現的方向。從純引擎到圖形殼，從伺服器到手機，這個轉變的幅度比前兩個都要大。

規律：他們一直在死磕什麼

回看這二十多年的迭代，我發現 qemu 團隊有幾件事一直在死磕，也有幾件事一直不太管。

一直在死磕的是效能和兼容性。TCG 引擎從最初的簡單翻譯器演化成了一個多層快取的即時編譯器；KVM、HVF、WHPX 三個平台的硬件加速介面一個不漏地接上；跨架構模擬的覆蓋面越來越廣——x86、ARM、RISC-V、MIPS、PPC，甚至一些已經沒落的架構也還在維護。這些都是硬骨頭，但他們啃了二十年還在啃。

一直不太管的是用戶體驗的簡化。命令列介面二十年沒有本質變化；新用戶想跑起一個虛擬機，仍然需要對 CPU 架構、磁碟映像格式、網路模式有基本概念。圖形前端的工作基本上都是社區第三方在做——virt-manager 不是 qemu 官方的，Android 啟動器也不是。官方專注在引擎本身，把「怎麼讓普通人也能用」這件事交給了外圍。

還有一件值得注意的事：Android 版本的迭代節奏明顯比桌面版快。桌面版 qemu 的主要版本更新大約每半年一次，而 Android 啟動器從 1.0 到現在的 1.1.0，中間只隔了兩三個月。這可能說明團隊或者社區對移动端有更高的期望，也可能是因為 Android 版相對年輕、需要補的功能還比較多。

預判：照這個路線下一步會去哪

如果讓我從迭代規律來推測，有兩個方向大概率會看到。

第一個是硬件加速在手機上的進一步優化。目前 Android 版 qemu 主要還是靠 TCG 軟體翻譯在跑，因為 Android 本身沒有像 Linux KVM 那樣通用的硬件加速介面（除非 root 並修改系統核心）。但 Android 13 之後引入了一些新的虛擬化 API，如果 qemu 能利用上，手機上跑虛擬機的效能會有一個質的飛躍。這件事的技術門檻很高，但按照團隊死磕效能的性格，我覺得他們已經在看了。

第二個是預裝镜像的多樣化。目前主要就是 Win7，這是最保守也最通用的選擇。但我猜接下來會看到 Win10、Linux 發行版、甚至一些輕量級的 Chromium 系統作為可選預裝镜像出現。這是讓產品從「能跑」變成「有用」的關鍵一步。

當然這些都只是從迭代規律推的，不代表官方計畫。但從 2003 年那個簡單的指令翻譯器，到今天我手機上這個能跑 Win7 的小啟動器，qemu 已經走了足夠遠的路——接下來它往哪走，我都不會太驚訝。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。