Native 二进制 fork+exec 架构：手机上跑完整后端
从网页壳到完整后端
绝大多数「网址转 App」工具的能力截止到 WebView 壳——要么加载远程 URL，要么加载本地 HTML。WebToApp 的服务运行时层跨越了这道边界：它能让 Node.js、PHP、Python、Go 在手机上以原生二进制形式运行起来，在本地端口提供 HTTP 服务。
这条思路和 Termux 很像——Termux 也是在安卓设备上跑真实的 Linux 用户态环境。但 WebToApp 更进一步：它把运行时二进制打包进 APK，导出的 APK 自己就能 fork+exec 这些进程，不依赖 Termux 或任何其他外部工具。
fork+exec 的工作方式
当你创建一个 Node.js 类型的应用并构建 APK 后：
- APK 内嵌了 Node.js 的原生二进制（arm64-v8a 架构，首次从构建器复制过去）
- APK 也内嵌了你的项目源码（通过 apk 的 assets 目录）
- APK 启动后，ShellModeManager 读取 app_config.json，发现这是 Node.js 类型
- 它 fork 一个子进程，exec Node.js 二进制，传入你的项目目录和启动命令
- Node.js 进程在 127.0.0.1:xxxx 上监听 HTTP 请求
- WebView 指向这个 localhost 地址，用户通过 WebView 看到服务端返回的内容
整个链路没有任何 JVM 模拟、没有 JS 解释层、没有远程服务器。是真实的、编译好的原生进程在 CPU 上跑。
为什么这是差异化能力
市面上能在手机上直接构建 APK 的工具很少，能打包完整服务端运行时的更少。WebToApp 做到这件事，靠的是几个关键工程决策：
- 原生二进制打包：不是用某种脚本语言模拟 Node.js/Python 的 API，而是直接 embed 官方发布的 arm64-v8a 编译版
- 端口管理：构建器内置端口扫描、分配、释放机制，防止多个本地服务冲突
- DNS 桥接：APK 内部的 localhost DNS 解析被重定向到正确端口
- 后台运行：Android 11+ 的前台服务 + 唤醒锁机制，让服务不会被系统杀掉
- 依赖安装：首次启动时通过包管理（npm / pip / composer 等）在 APK 内部安装依赖
和 Termux 的对比
| 维度 | Termux | WebToApp 服务运行时 |
|---|---|---|
| 入口 | 终端 Shell | APK 图标 / WebView |
| 打包 | 不能导出 APK | 一键打包成可分发 APK |
| UI | 命令行 | 可选 WebView 作为界面 |
| 隔离 | 全局共享 | 每个 APK 独立进程 |
| 适用场景 | 开发者自己用 | 分发项目给非技术用户 |
两者不是替代关系。Termux 更适合日常开发和实验；WebToApp 服务运行时适合把已成型的项目打包成可安装应用。
架构图（文字版）
导出的 APK（Shell 模式）
├── ShellModeManager（读取 app_config.json）
├── WebView（加载 localhost:xxxx）
├── [可选] 原生运行时二进制（Node / PHP / Python / Go）
│ ├── fork + exec 启动
│ ├── 监听 127.0.0.1:xxxx
│ └── 处理 WebView 的 HTTP 请求
├── assets/app_config.json（你的配置）
└── 权限声明（网络、存储、前台服务等）