关于PWA落地问题的思考

PWA是最近一个热门话题,很多开发同学都在尝试落地,其中也有些还在犹豫。这篇文章主要阐述对几个问题的看法,供大家参考。
注: 这不是一篇介绍PWA的文章。

简而言之(TL;DR):
 . PWA落地最大的纠结在于iOS支持的问题,且短时间难以得到改善。如果你的业务仅限于iOS,就不用再往下看了。
    . 事实上,PWA本身与其它技术方案并不冲突,比如各类的Web性能优化方案,以及基本的H5技术仍然可以落地共存,PWA只是在其之上进行更进一步。这正是其所谓渐进式命名的由来。
 . PWA正在拥有一个完善的技术体系,涉及五个层次,从Web平台,到各类工具。
 . 无论是从最近Web生态的发展,到未来应用开发技术的演进,再到实际开发落地和维护,PWA都代表了一个正确方向,值得投入。

iOS之痛是个伪命题

iOS中Safari内核支持一直是PWA绕不开的问题。2016年参加Google I/O时,与Chrome团队做了一次交流。他们明确表达了期望UC参与Chromium社区,越多人使用Chromium内核,Safari承受的压力就越大,就能促使其快速跟进Chrome提出的一系列新标准,其中的重点就是PWA方向。Safari团队虽然将Service Worker列入其五年计划,但并没松口开工。反观Microsoft Edge要积极的多。曾经打破浏览器格局的WebKit(Safari)已显然要成为移动时代的IE6了,主要着眼于其封闭的生态思考!

但是,iOS支持的问题不应该阻碍了PWA技术选型!原因是PWA是渐近增强式(Progressive)的技术,其核心是增强,而不是直接替代(比如没有替换某个H5特性,而是新增。),在不支持的场景下可以安全降级。以离线存储为例,AppCache实在太难用, 在没有支持Cache API的情况下可以使用Local Storage实现,如果支持了Cache API,就可以直接使用ServiceWorker+Cache来实现。在技术方案上,有一个基本的实现方案,是通用的。

在支持PWA相关标准的环境下,还可以进一步使用加强的技术方案。正如软件开发没有银弹一样,不能期望一个新技术可以解决所有问题。之前要解决的问题还是要继续分析解决,比如JS逻辑优化、图片压缩、CDN配置优化之类的工作,还是应当要一样展开的。

如果一定在iOS要使用到某些PWA特性带来的好处。可以考虑:

  • 评估使用Polyfill的可行性。直接到下面Polyfills那一节看下。
  • 实现一套在独立线程(类似于Service worker)运作的扩展机制,使用JS Bridge提供给页端使用。有一定的风险,可以提供主要特性的支持,比如Cache & Fetch。
  • 通过各种渠道(Mailing list, App Store, Twitter, etc.)向Safari吐槽。这条简单易行!

PWA === Servie Worker + Fetch + Cache?

初次进行PWA落地,我们往往会聚焦于几个抢眼的特性。从小步快走的角度来看这是正确的,但不能仅限于这一点,我们还需要更加系统了解PWA的技术体系。

从整个技术体系上看,分成五个层次:

  • PWA Features 通过标准定义,开放传播。易于各方理解和支持,特别是凝聚一些中间力量。因为Top的玩家也可以选择玩封闭的生态。
  • Web Platforms (各家浏览器及WebView) Web平台的支持,才能让PWA有应用的空间。特别是进一步与OS的结合,提高了Web应用与原生应用的竞争力,才能保证Web App能够成为应用开发的选项之一。从平台的角度思考,它一定会支持多种技术方案,更多的应用形式能帮助整个应用市场活跃起来。
  • 组件库及工具库(Polymer等) 开发最容易纠结在库、框架、组件的选择上,因为这是实实在在的痛点。有了进一步封装的库、组件、解决方案,无论具体什么形式,它必须要简化PWA的开发,是一个可以复用的技术方案,以降低开发成本和技术风险。
  • 工具及支撑平台 工具则包括开发调试、检测等可以提高开发效率的工具。支撑平台则是为这个生态提供基础服务的。
  • 设计思想和开发模式 在一个技术生态内,对实践的指导原则可以理解对最佳实践的抽象总结,可以帮助开发者更好理解这个生态面对的问题和解决的思路。最终它会影响到工具和组件,甚至是平台和Features。

Features不用多说,Web Platforms则是除了Safari之外的主流浏览器都有支持,只是Edge在支持的范围上有所差异。以下是工具和组件的构成:

最后特别需要提醒的是,落地过程也是一个持续学习和优化的过程。比如Polymer本身有一些性能优化策略,如果简单的使用可能会发现有性能上的降级,UC的同学也是在实践中积累了些经验。

工具库示例:sw-toolbox

工具库固化了一些常用的实现,以sw-toolbox为例,其核心是提供一组离线应用的策略机制,可以结合导航使用不同加载策略。详细的策略说明文档是: The Offline Cookbook, 其中总结并定义了在离线应用中涉及的五种加载策略。sw-toolbox对应定义如下的策略:

  • networkFirst
  • cacheFirst
  • fastest
  • cacheOnly
  • networkOnly
    其中fastest的策略是同步从Cache和网络中加载,使用先返回的数据。另外还可以指定超时时间等加载选项。超时选项(networkTimeoutSeconds)设置是需要考虑的,因为Chrome的网络请求没有默认的Timeout机制,UC则是自己做了实现。详细内容看它的API定义文档

整个使用非常简洁,下面是一个service worker的写法,使得进入offline/时仅从缓存加载:

// DEMO for sw-toolbox.
importScripts('sw-toolbox/sw-toolbox.js');

// Optional
toolbox.options.cache.name = 'sw-toolbox-cache';

toolbox.precache(['./caching.html', './offline/index.html']);

// Define different strategies as below:
toolbox.router.default = toolbox.fastest;
// Below router means to load data from cache only while navigating to offline.
toolbox.router.get('/offline/.*', toolbox.cacheOnly);

// For more details, please refer to SW-Toolbox API:
//    https://googlechrome.github.io/sw-toolbox/api.html

完整的例子可以访问这里PWA Demo

HTTPS还是HTTP2?

这里有一个清晰的技术链条:

  • PWA要求使用HTTPS。
  • HTTP2较HTTPS提供更高的性能表现。
    所以在考虑PWA落地,还要纠结下HTTPS和HTTP2。HTTPS本身会有一定的成本(证书、CPU等)和性能影响(首次明显),HTTP2则有更好的性能收益,但应用上有不同的Web优化策略,核心是多路复用和Server Push,使得之前的一些优化实践无效,甚至有负作用,比如内联资源,分散服务器等。可以简单参考Web 开发者的 HTTP/2 性能优化指南

除了自己的服务部署,还要涉及CDN的支持。正如之前HTTP Pipeline的支持,浏览器乐于支持,但实际测试数据却发现性能更差,原因就是大部分的服务器后台和CDN都没有支持。现在的情况是,目前国内的主要CDN可以支持HTTPS,如阿里云还支持了HTTP2。 长远来看一定是HTTP2,只是需要从业务本身出发,仔细评估下相关的风险和影响,绝非是后台做了支持就万事大吉了。

PWA特性支持不完整,怎么破?

PWA这个体系涉及的功能很多,也是逐渐在完善。Chrome本身迭代比较快,国内浏览器有一个较长的跟进周期。所以特性支持不全是比较容易遇到的问题。举个例子,饿了么团队在PWA实践中遇到了Fetch Redirect失败的问题,详情可以参考:PWA 在饿了么的实践经验。从页端或者后台还是比较容易处理的。

但是不是所有的问题都能这样解决,也会有必须内核进行支持的问题,这种情况下,浏览器是可以做部分升级的。如果你遇到了,欢迎随时和我们联系。

关于Polyfills

仅列几个给有需要的同学参考:

PWA的未来

PWA首先瞄准的是应用开发,以其官方定义,是为应用开发者提供多一个选择。所以会尽力缩小其与原生应用在能力上的差距。回头想到2012年前后那股也是Chrome推动的WebApp,最终不了了之。现在的PWA机会其实也就是H5的未来空间。

可以想象未来5年,应用开发的技术模式一定会有很大的变化。总体方向就是高动态性、低开发成本(包括了低风险), 产品形式上超级应用 (包括OS)和轻快的小型应用两极分化,前者越来越寡头,后者则占据绝大多数。

纵观现在App开发技术上的创新都是在这个方向上,包括RN, Weex, AMP(或者Instant Article), PWA, Android Instant App之类。无论Native容器、或者原生应用本身如何发展,产品对动态性的需求只会越来越高。而产品技术的复杂度也会越来越高,开发周期、变更成本、维护成本都有越来越高的要求。

Web的优势是开放的标准,一是持续改进,不断扩展和丰富,使其展现能力越来越强。二是技术清晰透明,易于理解和传播,有助于降低开发成本,包括风险。着眼于未来,不在于现在谁的市场占比提升速度,而在于哪方能更稳健地持续提供系统的支持,让生态更完整。

具体到内容展现,或者渲染技术上。虽然Web目前仍然有较大的性能问题,但它正通过自身的优化、以及提供原生扩展不断缩小差距。以UC实践的经验来看,除了内核演进外,前端对渲染性能的理解和优化也是同样关键的问题。可以参考Roger的对页端开发高性能(交互/动画) Mobile WebApp 的一些思考

再回到2016年底到现在3月份,Node.js的成熟推广,Weex/RN发力,再到小程序造的势(轻快),让页端承担应用+H5主力开发的模式越来越清晰。
再从Google对Web开发者的推崇(16年底的开发者大会)以及对业界的技术推广活动,到iOS AppStore的热修复门,一边推,一边收紧,所产生的不确定性反而让H5方向更为明确。


问题总是越辨越明,欢迎大家指正。

评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值