WebToApp 版本進化史：從網頁轉 APK 到手機上跑 WordPress

把任意網站裝進手機：WebToApp 是什麼

第一次打開 WebToApp 的時候，我以為它就是另一個「網頁轉 APK」的玩具——輸入一個 URL，封裝成 WebView，裝到手機桌面省得每次去瀏覽器收藏夾點。這種工具市面上不少，功能大同小異，沒什麼特別好說的。

但隨著版本更新，這東西的邊界開始變得模糊。現在打開最新的 v2.7.x 版本，類型選擇器裡除了最基礎的「網頁」，還能選 Node.js、PHP、Python、Go 的服務端執行時，甚至有一個 WordPress 專項卡片——選了之後自帶 SQLite 後端，APK 打開就是一個可以裝插件、寫文章的完整 WordPress 站。這已經不是封裝網頁那麼簡單了，它在手機上塞了一個小小的伺服器容器。

WebToApp 由個人開發者 Shiaho 維護，整個專案在 GitHub 上以開源方式發布，WebToApp官網 上可以找到完整的指南。構建器本身也是一個 Android APK——你在手機上裝了它，選好類型、填好目標地址或專案路徑，點一下構建，幾分鐘後手機上就會多出另一個 APK，那就是你自己的「應用」。構建器自動完成 V1/V2/V3 簽名，證書可以自己管理，不會把任何專案數據上傳到外部伺服器。

安裝

WebToApp 本身就是一個 Android APK，所以安裝流程和大多數第三方 APK 一樣：從 WebToApp下載 獲取最新版本，手機允許未知來源安裝，點擊安裝包即可。安裝包大小約 59MB，對於一個內建多種執行時二進位的工具來說算合理。

首次啟動時會請求幾個權限：存儲訪問（讀取你本地的專案文件和輸出 APK）、網路權限（下載執行時二進位和檢查更新）。系統 WebView 和 GeckoView 都支援，但如果你打算用油猴腳本功能，必須確保用的是系統 WebView 內核——GeckoView 下腳本不會生效。

構建出的自訂 APK 安裝時不需要再走一次 WebToApp，就是普通 APK 的安裝流程。但要注意：如果你的自訂 APK 用到了 PHP、Python 這類執行時，首次啟動時 ShellModeManager 會在背景啟動對應的服務，Android 系統在背景殺進程的限制下，長時間不使用後可能需要重新打開才能恢復。

從 v2.0.5 到 v2.7.8：一條迭代時間線

我翻了 WebToApp文檔 裡的版本記錄和開發者在 GitHub Releases 上的更新說明，從 v2.0.5 到現在的 v2.7.8，差不多是兩年多一點的時間。版本號跳得不算密，大約兩三週一個更新，節奏穩定。

v2.0.x 時期：網頁封裝的純工具階段。 這時候的 WebToApp 就是我最初以為的樣子——一個 WebView 封裝器，支援網頁、多站點、離線包幾種類型，基本配置就是填 URL、選圖示、設一些外觀選項。功能集中在「怎麼把一個網站變成能裝到手機桌面的 APK」這件事上，沒什麼野心。

v2.3.x 前後：執行時的引入是第一個轉折點。 我沒在現有文檔裡看到明確的版本號標註，但從功能脈絡推斷，Node.js 和 PHP 類型應該是在這個階段加進來的。這一改變了整個產品的定位——不再是封裝現成內容，而是讓用戶把手機變成一個能跑後端程式的小型主機。開發者的說法是「把裝在服務器上的東西搬到手機」，這個構想在當時看起來有點瘋狂，但確實拉開了和同類工具的差距。

v2.5.x：WordPress 專項出現。 這是目前能確認的時間點——素材裡採集到的版本是 v2.5.5，而 WordPress 類型的文檔已經在線上。這一步很有意思：不是讓用戶自己配置 PHP + SQLite + 啟動參數，而是做了一個專項卡片，預裝 WordPress 核心、自動生成 wp-config.php、SQLite 替代 MySQL 的後端也預設好了。這說明團隊（其實就是 Shiaho 一個人）開始意識到，光給執行時還不夠，還需要給場景。用戶想在手機上跑 WordPress，不應該讓他們從零搭環境——直接給一個能啟動的起點。

v2.7.x 至今：擴展能力的鋪開。 油猴腳本支援、模組市場、AI 圖示生成，這些功能看起來是在補齊生態。油猴那個我覺得特別巧——WebView 環境下很多網站會檢查瀏覽器指紋然後降級，用油猴腳本可以繞過這些限制，同時還能加一些下載影片、自動填表的增強功能。這不是什麼宏大的架構升級，但就是這種解決實際痛點的小功能，讓產品變得好用。

從迭代節奏看團隊的優先級

說「團隊」其實有點誇張——整個專案是 Shiaho 一個人在維護。但從版本脈絡裡能看出一些持續的優先方向：

執行時是一直死磕的方向。 Node.js、PHP、Python、Go 四種語言的執行時都內建了，而且每一種都不是簡單地把二進位塞進 APK 就完事——PHP 有 WordPress 專項優化，Python 需要處理 pip 安裝依賴，Go 編譯成單檔後又要考慮啟動命令。每加一種執行時都是大量的底層工作，但這個方向從引入之後就沒停過。

場景化是第二條線。 WordPress 專項是最明顯的例子。與其說「支援 PHP」，不如說「支援手機上的 WordPress」——這是兩個完全不同層次的承諾。後續的油猴腳本支援、媒體畫廊類型、AI 圖示生成，都是在做類似的事：給能力找場景，讓用戶不用自己拼裝。

而有些事情一直沒管。 比如多語言國際化——文檔和應用介面基本是中文為主，英文資訊比較少。又比如執行時的性能優化——官方文檔裡明確承認「手機 CPU 和記憶體有限，響應速度不如桌面」，但沒有看到針對性能的迭代記錄。還有背景執行穩定性，Android 系統殺進程的問題從引入執行時開始就存在，到現在還是那樣——這是 Android 系統的限制，不是產品 bug，但至少說明這個問題沒有被放在高優先級。

照這個路線，下一步會往哪走

純屬從迭代規律推測，不是官方口徑。

我覺得會出現更多類似 WordPress 的場景化專項。現在執行時已經覆蓋了四種主流語言，下一步與其再加第五種語言，不如在現有基礎上做更多「一鍵啟動」的場景——比如 Node.js 生態裡常見的 Hexo 靜態部落格、Python 的 Jupyter Notebook 或 Streamlit 應用，這些都是已經有成熟生態的東西，做成專項卡片用戶會直接上手。

另一個可能的方向是執行時之間的協作。現在每個應用是獨立的 APK，如果能讓多個應用之間共享一個執行時容器（比如同一個手機上的多個 PHP 應用共用一個 PHP 二進位），能大幅減少 APK 體積和資源浪費。但這涉及到架構層面的改動，短期內不太可能。

至於底層的執行時優化、國際化、背景穩定性這些長期議題，我不太樂觀——從歷史脈絡看，開發者的興趣明顯在「加新能力」而不是「打磨現有」。這不是壞事，個人專案能維持這樣的迭代節奏已經很難得，只是產品本身的定位決定了它更像是一個實驗場而不是一個成熟的商業工具。

寫到這裡我把手機裡的 WebToApp 打開看了一眼——v2.7.8，上次更新是兩週前。類型選擇器裡 WordPress 卡片還是那麼顯眼，點進去自動填好端口和數據目錄，保存完就能跑。這個從一個人的興趣項目成長起來的工具，已經遠遠超過了「網頁轉 APK」的初始定位，而且還在以自己的節奏往前走。

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