我所理解的 PHA

PHA, 全称是 Progressive Hybrid App，翻译过来就是渐进式混合应用。这是一个非常表意的名称，也起得很贴切，包含了三层的含义：它是「渐进式」的，渐进的基础是 Web；它是「混合」的方案，混的是 Native 和 Web；它的产出是「应用」，即包含多页面。

PHA 的诞生有其历史背景。技术上它是前端从 Web 角度出发追求更高体验的产物，业务上它是淘宝对货架式电商内有大量会场开发需求所抽象的架构模式。每一个会场其实就是一个小型的终端「应用」。以下图为例，包含了 TabBar、Swiper 等多种嵌套，里面有多个页面。

相对于 WebView，PHA 渐进拓展的能力可以分为几个部分：

• 首先是功能的增强，包括打造应用的能力，如 TabBar、Swiper、页头、启动屏等 UI 能力以及容器&页面生命周期事件、页面间通信、页面间跳转等 API 能力；AppWorker 环境；环境变量、Storage 等 API 能力；
• 其次是性能的增强，包括数据预请求、资源预加载、离线资源缓存、内置 JS、下拉刷新优化等；

PHA 作为 Web 方案的「加法」，不可避免地也引入了一些新的问题。为了「绕开」这些问题，PHA 提供了一些解法：

• 多一次 Manifest 请求，则通过 Manifest 缓存和预请求、主文档预加载或 HTML 模板化来优化；
• 无法透传 URL 参数，则通过添加动态改变页面加载 URL 的参数的方式来支持；
• 无法指定进入的页面，则通过根据 URL 参数动态定位内页的方式来支持。

PHA 是一个一体化的方案。这里面除了客户端容器实现，还包括了前端框架和服务端的配合。前端框架的配合主要是让业务可以通过写 JS 代码自动生成 manifest.json ；服务端的配合主要是 CDN 能够做到通一个 URL 返回 JSON 和 HTML 文件实现降级方案，同时结合 SSR 及模板化/容器缓存等能力可以达到更优的加载体验。

经过了几年的发展，PHA 形成了以 Tab 为主要交互形态应用的用户体验最佳实践，这符合过去「货架式电商」以用户主动发现信息为主要交互模式的需要。结合搭建体系，很好地满足了淘宝对于开发效率和用户体验的需要。

值得注意的是，近些年来沉浸式的信息流/直播类用户被动接受信息的交互模式开始大量地占用用户时长，成为当下流行的应用形态。TNode、NewDetail 都是该模式下从 Native 视角出发的终端解决方案。从应用数量的规模性来说，也许并不需要为该模式建立 Web 应用的解决方案。但从开发体验和用户体验来看，当下的 Hybrid 方案仍有不少的提升空间。它们面临的问题包括不限于开发体验侧的调试和问题排查效率较低，用户体验侧的加载体验和内存占用较差等。同时这些方案的完备性不足和可移植性较差，难以在其他 App 下方便地接入和定制。

笔者认为PHA 的未来方向是探索更多常见交互模式的应用解决方案，统一 App 内的 Web 容器；支持被内嵌，同时针对单页推出极简链路；常态化监控，在能力拓展过程中保证包大小、性能等指标不劣化。