SPA 开发的一点思考

回想最近独立负责开发的一个需求：App 中的一个子模块，客户端提供的 WebView 加载网页，实现的一个单页应用（SPA）。其中将功能拆分到多个不同的子页面分别实现，各个子页面实质上只是这一 WebView 页面中的一个模块，通过 React Router 去分发路由和渲染它们。

从交互同学手上拿到的 Interaction Flow 流程图，大致描述了各个子页面的元素和用户的跳转关系。而流程图背后，并未体现出页面的堆叠关系、哪一块内容需要生成滚动、层级如何安排等更立体的结构等信息。

对于 Web 前端开发这一角色而言，一开始我很自然而然便以一种「切图仔」的思维，直接开始对着视觉稿开撸；在做的时候遇到矛盾、才会一点点去反推交互视觉同学去对齐和明确各个细节，甚至有时候他们也并未想清楚这个问题，导致视觉和交互变更带来的额外工作量（论俺上个月的加班来源）。

对齐细节时也发现一些当下无法调和的矛盾，主要与页面栈管理有关。页面栈主要是移动 App 开发的概念，描述了页面的堆叠和切换的模式，和浏览器的前进后退历史记录相似。这里问题在于，浏览器（WebView）最初的设计是以网页浏览为中心做的，每一次前进或后退操作，会导致整个页面的刷新，状态无法像移动端 App 那样有很直接的堆叠的模式。也未实现类似 Android / iOS 原生 App 那样平滑的过渡动画效果，切换效果也比较生硬。

其中比较严重的问题是，基于 WebView 的 SPA 子页，在数据埋点与上报的场景有着诸多不便，也容易因为多次曝光导致数据分析出现偏差。

从一个较为抽象的视角去观察，这里核心矛盾在于当下 Web 的形态正在从 “文档” 到 “应用” 的方向去转变；而我们基于文档展示的逻辑去承载整个应用的逻辑，导致体验不是太好。现有的 Web GUI 框架（React / Vue / Angular）等本质上也是在调和这两者的矛盾，但它们仅仅只是解决了基于文档模型实现 GUI 渲染这一层面的问题。更深一层次的移动端的交互细节并未覆盖得很好，比如刚想到的页面切换场景的各种细节。在桌面端对交互的诉求不是很高，只要实现了基本的界面渲染和多窗口就满足需求，所以问题并不太明显。

显然， Web 在移动端的交互场景还是缺失了很多东西。类似微信小程序这样的杂交方案，也正是针对这样的缺憾做了许多工作，小程序框架层面提供了页面栈的功能，同时补齐许多客户端才有的 API。当它融合 Web 的低门槛、分发效率优势与原生  App 的交互体验优势，也开始大肆占领市场。

抛开小程序不谈，在基于纯 WebView 的应用开发，这方面似乎还有不少发挥的空间；无论是 SPA 还是 PWA 也好，在移动端的交互需求下，大致都有着类似按页面拆分功能的场景。或许可以基于 React / Vue / Angular 等 GUI 框架之上，设计一套轻量且完善的页面栈管理方案，这样的 SPA 或 PWA ，在使用感受上也可以很接近原生 App 的体验了。