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 的体验了。

找到的一些不错的文:

  1. LINE MANGA: Smooth page transition with Page Stack - LINE ENGINEERING
  2. Getting started | React Navigation
  3. 我理解的 SPA - 囧克斯
  4. SPA-单页Web应用 | WUWEI'S BLOG
仅有 1 条评论
  1. Chromium 新的 Shared element transitions API
    https://developer.chrome.com/blog/shared-element-transitions-for-spas/

添加新评论