你的App本可只是一张网页，我已帮你优化

背景

今年夏天，一个儿童表演艺术学校的团队要去迪士尼乐园演出，所有家长都很兴奋。但组织者要求大家安装一款名为“Travelbound”的 App 才能查看行程、交通和住宿信息。作者对此极为不满，认为这根本不应该是一个 App，而应该是一个网页。他决定通过逆向工程把这个 App 的“功能”提取出来，做成一个更好的网页，并分享给整个旅行团。

核心内容

作者对“App 文化”感到愤怒：一个本可以用网页（更小、更快、更通用）呈现的行程信息，却被包装成 App，强制用户安装。这个 App 额外做了两件网页不需要做的事（作者称之为“反功能”）：

• 向开发者报告与 Google 账号关联的跟踪数据；
• 展示广告（美其名曰“灵感”），推销该机构组织的其他旅行。

作者认为，网页相比这个 App 有诸多优势：可复制粘贴、可打印、可保存、可收藏、可搜索、几乎任何设备都能用、可访问性更好。

于是，作者开始“修复”这个 App。他使用 Android Studio 创建虚拟设备，通过 rootAVD 获得 root 权限，安装 Magisk 并自动授予 su 权限，然后用 HTTP Toolkit 拦截 AVD 的网络流量，并只代理 Travelbound App。经过简单实验，他发现 App 通过拼接用户名和密码来构造 URL，例如： https://travelbound.api.vamoos.com/api/itineraries/{username}-{password} 请求返回一个 JSON，包含所有内容：行程各段、广告（“inspirations”）、以及所有被引用的文件（图片等）的交叉引用数组。注意，图片的 S3 URL 过期时间较短，所以即使内容未变，也需要定期重新获取 JSON。

作者用 Ruby 写了一个脚本，通过 Cron 定时任务拉取最新 JSON，生成一个 HTML 页面。他完全跳过了广告（数据 schema 中的“overlayRows”），只列出行程内容和所有未被广告或行程引用的文件（一种懒人方式，收集 PDF 下载链接）。页面用密码保护（与旅行团最初获得的密码相同），并在 <details> 元素中包含原始 JSON 以便检查。

最终，作者创建了一个 0.05MB 的网页（加上可选 35MB 图片），而原 App 本体 43MB，下载额外内容后膨胀到 124MB，且包含跟踪和广告。网页提供了更多功能，能在更多设备上运行。作者感慨：有些任务确实适合 App，但 Travelbound 绝对不是其中之一。

关键要点

• 作者认为，许多 App 本可以用网页实现，尤其是那些内容本身就是 HTML 并通过 HTTP 传输的 App。
• 逆向工程步骤：创建虚拟设备并 root → 安装 Magisk 自动授权 → 使用 HTTP Toolkit 拦截流量 → 分析 URL 模式 → 获取 JSON 数据。
• 原 App 使用用户名和密码拼接成 URL 获取数据，且整个旅行团共享同一组凭据，安全性堪忧（作者猜测他们要么不在乎，要么认为数据敏感度低）。
• 作者去除了广告和跟踪代码，将数据转换为静态 HTML 页面，并定期重新抓取（因为图片 URL 有短期过期时间）。
• 最终网页大小仅为 App 的 1/800 左右（0.05MB vs 43MB），且功能更丰富（可复制、搜索、打印、跨设备等）。
• 作者指出，App 文化让软件公司“自讨苦吃”：开发 App 成本更高（部署到应用商店要花钱），却只能将 HTML 内容传递给更少的人，且功能更少、可访问性更差。

意义与影响

这篇文章反映了当前移动互联网中一个普遍现象：很多服务被强行包装成独立 App，却忽略了 Web 的开放性和便利性。作者通过实际案例，展示了如何用技术手段“解放”被 App 绑架的数据，并指出了 App 开发中的冗余、跟踪和广告问题。更深层的意义在于提醒开发者和用户：并非所有内容都需要一个 App，Web 在很多场景下仍然是更优的选择。同时，它也展示了逆向工程和 DIY 精神如何对抗不合理的“App 文化”，让用户重新获得选择权。