微信小程序和PWA对比分析

---

微信小程序和PWA（Progressive Web App）是目前移动端以及前端受关注度较高的两项技术。小程序自去年公测以来，国内很多公司均投入到小程序的开发中，今日头条、携程、摩拜单车等小程序纷纷在第一时间发布。从实际效果来看，小程序的用户体验普遍受到了好评，并且它可以在微信上安装、卸载和离线使用。PWA则是在传统Web应用的基础上，通过完善Web应用的一些能力，比如离线使用、后台加载、添加到主屏和消息推送等，达到用户体验提升和性能优化。两者的达到的效果相似，但实现技术上略有不同。

小程序剖析（Android）

张小龙在朋友圈披露其对小程序的定义：小程序是一个不需要下载安装就可使用的应用，它实现了应用触手可及的梦想，用户扫一扫或者搜一下即可打开应用。也体现了用完即走的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。从字面上看小程序具有类似Web应用的热部署能力，在功能上又接近于原生APP。

界面分析

小程序采用Web-Native混合方案。WebView渲染基本网页内容，部分块级元素如地图、视频、底部导航栏等由Native View渲染。如图所示，在Android开发者模式中打开显示布局边界选项，可以在小程序中看到所有的Native View被框线分割，而显示主体内容是一块完整的WebView。
WebView的内容通过Chrome浏览器的Inspect功能可以查看到相应的网页元素结构,代码如下图所示。

对多个小程序Inspect后，我们发现页面结构代码基本相同，分为以下几部分，对应图上的区域：
- 基础样式库
- 业务逻辑代码
- 用户自定义样式库
- 页面Dom结构

网页运行机制

小程序是Web和Native混合方案。对于Native模块的性能我们没有疑问，这里主要分析下Web性能是如果实现优化。
通过相应的抓包过程发现，每个小程序对应一个wxapkg文件，wxapkg包含小程序配置文件和已经组装好了的page-frame.html。小程序下载后，访问相应小程序，微信会解压wxapkg文件，并结合Native View展示 page-frame.html。
作为性能上重要的优化点，这里我们主要调研一下小程序网页的部分。以今日头条小程序为例，打开微信内核的调试模式，通过Chrome浏览器进行查看。

当打开今日头条后，在Chrome浏览器调试界面出现两个WebView，其中的一个WebView进行Inspect发现是当前看到小程序的页面。另一个WebView进行Inspect发现是个空白页面。

当点击第一条资讯后，WebView多了一个，资讯列表的WebView仍然在运行，并且界面不变。原先空白的WebView界面则加载了第一条资讯的详情，而新增加的WebView则是空白的页面。

当我们在资讯详情页回退到列表页时，总共两个WebView，列表页WebView显示相应的资讯列表，另一个WebView为空。
从以上的过程可以看到：
- 一个WebView只对应一个用户界面。
- 在打开当前页面后，小程序会提前新建一个WebView并进行初始化。
- 页面跳转不再是一个WebView内部的跳转，而是上升到Native View层次上的转换。
- 页面跳转时，小程序直接用初始化好的WebView进行页面展示，提高加载速度。

开发规范

下图是小程序的开发项目目录结构图。

从目录结构上看，这很类似于一个H5的WebApp，有样式库、页面结构和业务逻辑。开发目录结构与模块和路由结构相呼应。
从规范角度讲，我们从以下几点进行分析，探索相关开发规范制定的合理性。
- 基础组件
不同于传统Web网页开发，小程序开发可以使用的标签不再是

等，而是小程序限定的标签，按照功能与传统Web标签对应如下。

从界面分析那一节我们已经知道，除了媒体、地图等部分组件是原生组件，大部分组件还是网页元素，而且小程序界面最终的Dom结构也是自定义标签元素，如。

作为小程序开发者，只需要写一个。虚线部分为小程序内置的样式库，就可以实现与右边等价的HTML和CSS写法，这样开发者默认开发就相当于使用了微信的一套样式库。
CSS决定了界面的多样性,但由于浏览器内核的历史性和多样性，同样的一套CSS在不同平台上会带来一定程度的兼容性和性能问题。而微信小程序由于其平台的固定性，可以着力于完善基于固定平台的最优CSS样式库。用户采用基础组件开发，自然地继承了相应CSS的最优性能。
- 禁用浏览器Dom API
开发者不支持使用标准的Dom API开发网页，最后的渲染工作由微信端的JS库进行操作。而微信小程序采用Virtual Dom，可以减少重绘和重排的次数，提高了页面的性能。

如果Dom API暴露给用户，虽然界面的交互和操作上更丰富，但开发者对于Dom操作的随意性反而会降低页面的性能。
- 部分原生能力的API使用
微信小程序整体架构类似Hybrid架构。为了弥补Web规范和功能的局限，小程序对于原生一些功能的调用进行了JS层面的封装。

一方面，对于原生组件支持，例如视频、地图等组件，传统Web在性能上是无法与原生组件相媲美的，小程序通过组件方式进行调用。
另一方面，对于原生功能支持，例如文件上传下载、缓存、网络请求WebSocket、录音等功能，小程序通过JS函数的方式进行调用。

总之，微信小程序结合了各种优化策略。在Web层面上虚拟Dom、高性能CSS样式库，原生层面上有WebView预加载，原生模块覆盖等。虽然在开发上建立了一定的限制，但带来了整体性能上的提升。
这里我们对微信小程序从技术层面和产品层面进行了汇总，如下图所示。

PWA

(P)rogressive (W)eb (A)pps

---

渐进式的Web应用，WebApp大家都熟悉，那什么叫渐进式，前端的同学都了解一些概念比如” 渐进增强“ ，即在不影响主要功能的情况下，使用一些高级的CSS和JavaScript特性来提高性能或者开发效率的开发方式，PWA的P和这个想法有些类似——我可以按照常规标准来开发一个WebApp，PWA主推的能力：离线，推送，桌面访问这三个能力，本身来说都不属于一个传统WebApp的一部分，所以不会影响的主要功能的开发，而这些PWA的部分都可以在开发完这个WebApp之后单独添加。所以这就是优雅的渐进式WebApp。

ServcieWorker

在说PWA之前必须先简要PWA的核心——ServcieWorker， PWA的所提及到的所有功能都是围绕着ServcieWorker来展开，那什么是ServcieWorker：详细的解释请参照MDN或者Google Developer上面给出解释，这里先给一个大致的总结，ServiceWorker是一个单独的后台线程，不依赖于某一个WebView，它是一个Proxy，用于监听以及管理服务的请求以及返回。首先我们看一下ServiceWorker兼容性。

运行机制

ServiceWorker是运行在单独线程，在浏览器进程退出之后，ServiceWorker线程也会关闭。再次打开浏览器之后，可以通过Wake Up机制唤醒ServiceWorker线程。
PWA网页和浏览器生命周期一致，浏览器进程杀掉网页也销毁了。ServiceWorker进程在网页关闭后，如果内存足够，也不会被销毁。

PWA给用户带来的最大好处——优化用户体验

缓存机制：ServiceWorker + CacheStorage

在这之前所有的离线功能是交给Application Cache和IndexedDB，IndexedDB是一个优秀的API，但是Application Cache自诞生初期就被吐槽，其对于缓存的控制不灵活一直为人所诟病，所以更多用户选择，将静态资源响应头的max-age和expire字段设置成最大，使得缓存用不过期来达到离线效果。但是自从有了CacheStorage之后，“麻麻再也不用担心控制缓存的能力了”。因为CacheStorage + ServcieWorker简直就是控制缓存的最佳组合，CacheStorage 可以将静态资源批量或者单个导入，在ServcieWorker中对指定地址的静态资源进行监听，当ServcieWorker接收fetch事件时，开发者可以按照具体的业务需求，来制定是否使用或者如何使用缓存的策略。具体实现可以参考下图。

推送通知：Push + Notification

Notification和Push功能是绑定使用的，这里着重讲一下通知功能，首先是兼容性：

在最新的规范中以及不提倡使用New Notification()的方式了，改由ServcieWorker来接管，没错！又是ServiceWorker，请看下图：

小贴士：开发者可以在inspector下使用模拟推送来调试通知功能

推送是一个很有价值接口，并且依赖于ServcieWorker线程，所以是否能够推送成功，全都仰仗ServiceWorker线程是否存在，之前曾经提到过，ServcieWorker是运行在单独线程，在浏览器线程退出之后，ServcieWorker线程也会关闭，ServcieWorker线程在网页关闭后，如果内存足够，也不会被销毁。

桌面访问：ServcieWorker + Web App Manifest

这个功能有可能是三个功能中表面上看起来最酷炫的一个功能，首先来看一下兼容性

添加桌面图标，这个功能就算没有PWA也是可以实现的，但是目前添加桌面图标指示简单的打开网页而已，在获得HTML、JavaScript和CSS之前，页面将会呈现一段时间的空白时间，但是WebApp Manifest功能可以在这一空白时间内补上一开屏画面，从而提高用户等待期间的体验。目前该功能还是比较简陋的，对于一些稍微高级一点的需求就无法支持了，比如背景图片，动画。具体支持的定制能力请参照下图：

展望一下PWA

PWA所提供的离线访问、桌面访问、通知推送功能将原本只能通过浏览器逐级切换的在线网页体验推向了可离线访问的类Native App体验，并且提供了Web Push和Notification API，将原本只能够由Native应用才能做的事情转变为Web应用一样能够使用，配合渲染性能更加强劲的内核渲染引擎，在渲染性能上拉近与Native应用的距离，另外两大搜索巨头Google和百度对于PWA都寄予厚望，对于前端开发者来说很有理由相信OpenWeb的明天是很灿烂的。

结语

正如上文所述，两者主要都是基于Web技术，都是为了用户体验的优化，只不过实现原理不太相同：
小程序类似传统的Hybrid架构，对渲染性能要求较高的组件,通过Native 组件来实现，以弥补传统Web页面性能上的不足。另外传统Web无法访问的本地能力，需要通过JSSDK来实现。而PWA是Web能力的增强，通过提供更多的接口和规范可以让Web应用更接近Native应用。