Windows 10 Mobile 10240+ 版本曾內建 Project Astoria（Windows Bridge for Android），提供 Android 兼容子系統，允許在 Windows 手機上直接運行 APK。本文回顧其技術架構、部署步驟、限制與微軟最終放棄的戰略原因。

一、技術架構：非虛擬機，而是「子系統轉譯層」

• 核心原理：在 Windows NT 核心之上實現 Android 系統呼叫轉譯層，將 Android Binder IPC、JNI、系統服務映射至 Windows 核心對應功能，類似 WSL (Windows Subsystem for Linux) 架構。
• 非模擬器：不運行 Android Kernel，不需硬體虛擬化支援，APK 原生指令在 ARM 處理器上直接執行，效能接近原生。
• 支援範圍：API Level 16-22 (Android 4.4-5.1)，ARMv7 (32-bit) 應用。不支援 NDK 原生庫 (x86/ARM64)、Google Play Services (GMS)、部分系統級 API (NFC、指紋、SELinux)。

二、部署流程（歷史紀錄，現已不可用）

1. 裝置：Windows 10 Mobile 10149+ (Insider Preview)，開啟「開發者模式」。
2. 電腦：安裝 Windows 10 SDK + Project Astoria 部署工具 (內部測試版，需 NDA)。
3. USB 連接手機，配對授權。
4. 命令列執行部署指令：astoriactl install <app.apk> 或 Visual Studio 建置部署。
5. App 出現在應用程式清單，點擊啟動運行。

三、關鍵限制與體驗缺口

四、微軟為何棄用 Project Astoria？

1. 戰略轉向 UWP (Universal Windows Platform)：納德拉上任後確立「雲優先、行動優先」，但行動端策略轉為「雲端服務跨平台」而非「自建手機生態」。UWP 才是長期棋。
2. 法律與授權風險：Astoria 實質重新實作 Android 運行時，面臨 Oracle Java 版權訴訟風險（同期 Google 因 Java API 官司纏訟多年）。
3. 生態雞蛋問題：缺 GMS 的 Android App 體驗殘缺，開發者不願專門適配，用戶不買單，形成死循環。
4. 資源集中：Windows 10 桌面/平板/ Xbox/ HoloLens/ IoT 共享 UWP 代碼庫，投入 Astoria 分散資源。
5. 市場份額崩塌：Lumia 950/XL 銷量慘淡，Windows 10 Mobile 佔有率 < 1%，無商業正當性。

五、遺產與後續發展

• Project Islandwood (Windows Bridge for iOS)：同期開發，將 iOS Objective-C 專案編譯為 UWP，同樣因戰略調整停止投入。
• WSL (Windows Subsystem for Linux)：Astoria 核心團隊轉向 WSL，將 Linux 系統呼叫轉譯至 NT 核心，現已成熟為 WSL 2 (真實 Linux Kernel)，廣受開發者歡迎。
• Windows 11 Android 子系統 (WSA)：2021 年發布，基於虛擬化技術 (Hyper-V) 運行完整 Android 11/13，支援 Google Play Store (官方/第三方)、圖形加速、檔案共享，實現了 Astoria 未竟之夢，但僅限 Windows 11 桌面版，非手機。
• 微軟 Launcher / Your Phone / Edge / Office 行動版：以 App 形式在 Android/iOS 提供微軟生態整合，成為跨平台策略主力。

六、歷史意義

Project Astoria 是微軟嘗試以「兼容敵人生態」反制生態劣勢的大膽實驗，雖失敗但為 WSL、WSA 鋪路，展示了 NT 核心多子系統架構的強大彈性。對開發者而言，它是「跨平台運行時轉譯」的經典案例；對用戶，則是一段「如果當年堅持下去會怎樣」的遺憾回憶。

如今在 Windows 手機上運行 APK 僅具歷史研究價值，現實路徑是：擁抱 UWP/WinUI 3、或轉向 Android/iOS 並使用微軟雲服務套件。