Web PWA的极致，比App更像App
这是一个平平无奇的音乐App Vooh，你可以在里面搜索歌曲，添加播放列表，播放音乐。
你可以滑动返回上一级页面，就像任何一个普通的App那样。
你可以流畅地展开音乐播放面板，看着歌词随着播放时间滚动。
当然，你也可以在电脑端，或者iPad上使用这个App。
而它与App的唯一不同，在于安装它不需要下载庞大的安装文件，只需要一个链接。音乐播放器Vooh的本体，只是一个网页。
作为一个诞生了好几年的老技术，PWA（Progressive Web Application）自诞生以来一直都不温不火，Google对它的愿景是最终所有的网页都能做到和App一致的体验，但直到现在，它都像是一道可有可无的饭后甜点。对于网页来说，即用即走似乎是它与生俱来的诅咒，用户既没有将Web安装到桌面的必要，也没有这个耐心，毕竟对于网络延迟增加1秒都可能导致访问量降低80%的地狱难度模式的网页用户生态而言，让一个浏览器用户点击一个陌生的“Install as application”的按钮简直是天方夜谭。尽管它就在那里，但乐于尝试的人似乎总是寥寥无几。既然PWA和纯网页能做的事情相差无几，那为什么还要浪费桌面空间增加一个以后可能再也不会使用的图标呢？
我一直认为，PWA应该朝着更像App的方向努力，才能体现出它的价值。然而，目前的许多PWA，看起来只是把普通的网页做成了全屏，与在浏览器中的体验别无二致，做不出差异化，用户自然没有动力去安装PWA，PWA那些听起来十分美好的特性便成了空中楼阁，无源之水，这个名字也越来越将从人们的视野中慢慢淡去。
如何才能让PWA更像APP，这是一个问题。毕竟浏览器的交互逻辑和原生App相比，有着很大的区别，用户早已习惯了移动浏览器中的前进后退，页面加载时的白屏，以及几乎不存在的手势交互，似乎在说，没关系，这就是网页，它做到这个份上已经足够了。然而，若要把这份体验带到模仿原生App的PWA中去，那势必将迎来用户预期低落的反噬，连这样那样的交互体验都没有，还能叫App？
为了了解目前的PWA究竟能做到何种地步，我开发了Vooh，一个竭尽可能模仿原生App实现的PWA音乐播放器。它尽力实现了一个原生App应该具备的一切交互细节，包括页面间自然的动画过渡，跟手的手势交互，为触屏优化的样式细节等等，我尽可能将它的每个细节都尽可能地做到与App别无二致，就是为了探索Web能力的极限。而在这之后，我也打算将Vooh的实现原理整理出来，并且准备逐步将之前的做过的项目“App化”，来一窥Google期待的未来，究竟是什么样子。
无处不在的过渡动画
尽管Vue，React以及原生CSS都提供了方便的方式实现过渡动画，但是对于大多数网页来说，一个Loading动画可能就是整个页面里动画最多的地方了。这对于网页来说的确无关紧要，毕竟用户们早已习惯了浏览器里生硬的切换效果，没有成体系的交互反馈，以及突然消失出现的页面区域。尽管在许多成熟组件库慢慢开始注重交互动画的优化之后，这样的情况在慢慢改善，但是依然难以改变用户的刻板印象。因此，为用户的预期提供动画反馈是伪装成原生App的一个关键步骤，否则，缺少反馈的使用体验会一下子将用户安装和使用PWA的欲望拉得很低。
除去老生常谈的按钮悬浮、按下时的动画，页面间的过渡动画也是不可缺少的一环。如果你仔细观察iOS的Tab页面，就能发现在切换Tab的时候，也会有细微的不易察觉的缩放淡出渐变，正是这种细致入微的动画组成了iOS App丝滑体验中重要的一部分。
表单组件的动画效果也很重要，Vooh尽可能地使用了iOS风格的表单组件，例如Button，Switch等，以贴合用户的日常视觉体验。
手势交互
手势是网页与App的重要差异点，一般来说，很少会有网页支持用户的滑动返回，长按呼出菜单等复杂的手势操作，而这正是让你的PWA丝般顺滑的关键。
需要注意的是，由于大部分移动浏览器和JS本身单线程的限制，手势交互依赖监听器的执行速度，而很难跑满设备屏幕的帧率上限，尤其是iOS设备上，开启低电量模式的情况下，监听器的帧率可能只有不到30 FPS，肉眼可见的卡顿。目前为止，也没有看到任何浏览器厂商有关于优化手势交互的提案，手势交互就像一道横亘在网页与App之间的鸿沟，没有丝毫跨越的可能，只能尽可能地模仿。
离线访问
没有哪个用户能接受打开App时整个页面全部消失无法操作，APP的最大优点就是离线可用，好在Service Worker的推出让这一点不再是问题，通过Service Worker对网页资源进行缓存，可以实现在低网速甚至离线环境下，也能继续使用PWA，就像真正的App那样。
然而不幸的是，在iOS设备上，Service Worker离线缓存不再可用，开启飞行模式或者关闭网络连接后将无法访问任何网页，包括已经安装在桌面上的PWA，
偶遇现代IE厂商，拼尽全力无法战胜。
细节之外的细节
而Vooh在这些基础能力之外，还增加了许多其他的细节设计，让整个App在模仿原生App时更进一步。
1，存储占用管理
在移动设备上，PWA与App的存储占用是分隔开的，而且往往要经过十分复杂的步骤才能看到PWA的实际空间占用，因此对于音乐播放器这种高度依赖本地资源的应用来说，一个显而易见的存储占用管理系统能有效缓解用户的存储焦虑。
2，接入系统播放器
隆重介绍Media Session API，它能让JS直接接入系统播放器控件，即使在后台也可以允许用户通过系统自带的播放器控制媒体的播放，例如下一曲、播放暂停等，在iOS设备上，还能直接适配灵动岛，这下谁还能分辨谁是原生App。
3，深色模式
在Apple等手机厂商的推动下，大部分的App都已经适配深色模式，而网页对于深色模式的适配比起App要更为简单，毕竟CSS实在是太灵活了，Vooh当然也做了适配，在不同的模式下都能完美贴合系统的主体模式。
为了提升Vooh与其他原生播放器的（根本不存在的）竞争力，我也煞费苦心地加入了许多的细节，来让用户有真正使用它的动力，例如根据歌曲封面动态取色，自动识别的滚动歌词等，希望能让它在用户的手机桌面上多待一段时间。
未竟之事
不过，即使是做到了这个地步，PWA的能力始终是有极限的。有些App轻易能做到的事，对于PWA而言犹如天堑一般遥不可及，包括但不限于：
1，后台活动
在移动设备上，网页也好，PWA也好，基本上没有任何后台活动能力，甚至上面提到的Media Session API，在iOS上顶多也只最多能支持后台播放1～2首歌曲，然后就会被强行停止，更不用说后台导航，推送通知这种活在梦里的API了，这方面浏览器天生就是残废，未来也看不到有任何改进的可能，因此在开发PWA时，一定要远离这些方向。在js都能跑虚拟机，剪视频的当下，Web开发者们推送一条通知的希冀却只能在另一个平行时空实现了。
2，跳转到PWA
据说Andriod Chrome支持使用PWA来打开特定的链接，不过在iOS上就别想了。
3，触感反馈
同样，Web也只能使用早已被淘汰的Vibrate，细腻的振动反馈和Taptic Engine对网页来说也是天方夜谭。
4，调用原生功能
还有无数浩如烟海的功能是PWA完全无法实现的，例如系统级的音量调节，亮度调节等，我能理解这是浏览器对恶意网站的限制，但这也确实极大限制了Web的发展，比如奠定了Web安全基础的跨域限制，如今成为了许多大型Web应用的掣肘。我由衷地希望某天浏览器能制定一个更宽松的PWA标准，例如安装到桌面后能提供更多的权限，提供一个无跨域限制的fetch代替品等等，然而即使对Web上心如Google，也没有考虑过这个方向的可能性。JS正在和越来越宽松的宿主环境（Tuari，Electron）一步步蚕食着原生GUI开发的领地，而它的发源地，浏览器却只能被所谓的安全性限制，成为一个只负责播放动画的花瓶。
总结
正如所说，一切能由javascript实现的终将会用javascript实现。如今，越来越多的平台小程序，快应用，乃至于H5套壳的App越来越多，随着浏览器性能的进一步提升，Web能做到的事越来越多，但是Web的交互性却并没有随着javascript的繁荣而被重视起来，受限于javascript的单线程特性，要完全模拟App的使用体验还是有一定的差距，一个劲地往原生体验上靠，有时也并不一定是最好的选择，Vooh的出现只是给了开发者们一个可能的方向，Web的轻量，优秀的可触达性与PWA有机结合，才是Web的发展方向。同时也希望各家浏览器厂商们能加快适配新的Web特性，能够让程序们在写代码时少掉一些头发，便是最大的善事了。