一.前言
目前的转转app是一个典型的hybrid app,采用的是业内主流的做法: 客户端内有大量业务页面使用webview内加载h5页面承载。
其优点是显而易见的,即:web页面上线频度满足快速迭代的业务需求,不受客户端审核和发版的时间限制,也可以将各个业务线的开发工作分摊到各个业务的fe团队上,使得个业务线可以并行开发。
而缺点,则不言而喻的在于客户端内webview加载h5页面,准确来说是web应用的性能和体验,是肯定不及客户端的。本篇文章中,笔者将会梳理立足于本团队内,根据团队的特点和制约,开发并实践web应用的静态资源离线系统的过程与实践。
痛点1:
现今本团队内的端内web应用,均是由webpack构建打包而成的单页或多页web应用,前端工程构建完成的结果是这样的画风
可以看出其静态资源中,不乏体积几百k~几m不等,而这些静态资源均是首次打开页面时需要下载的,并且在web应用有更新时,这些静态资源文件均会发生变化,也需要重新下载。
导致:首次打开·线上h5资源更新·网络条件差的时候,或者本地页面缓存失效的时候。 出现:
这使得移动端网页体验像一块巨石—它包含了大量 CPU 计算的 JavaScript 包,拖延了页面的加载和可交互的速度。 而对于任何一家互联网公司,性能往往与利益直接相关。 面对海量的交易用户,提升web应用加载的体验成为了fe和app 工程师极力重视解决的一个问题。
痛点2
其一: 笔者之前也调研过 service worker等利用web api 来实现pwa的离线缓存方案,但目前转转的app使用的还是系统原生的webview。暂时不兼容pwa特性.(点击查看本团队过往对于pwa项目的尝试总结)
其二: 目前各个业务团队使用的技术栈的范围比较广,涵盖vue及react等生态方案。同时各个业务线均在保持快节奏的业务开发,需要设计一套能良好工作,更重要的是可以让各业务线前端工程可以低成本无痛接入,对业务代码不会产生侵入,不会引发风险与问题的接入方案。
我们的方案:
在调研了腾讯 手机QQ 阿里 美团 新浪 等公司的实现方案后,我们设计了自己的web应用静态资源离线系统方案:
图片是粗糙的,印象是模糊的。下面我们从 前端构建和发布测 和 app测 两个方向分别来分别阐述:
1.前端构建和发布测:
我们采用腾讯alloy团队出品的webpack离线包插件:ak-webpack-plugin,其可以根据配置,将webpack的构建出的静态资源,压缩成映射了静态资源在cdn路径url的zip压缩包。 同时在配置的过程中,也可以选择 排除掉 部份文件(比如图片,并不是所有构建出的图片都是用得到的)。其生成的压缩结构如下:
在此过程中,我们不需要关注资源之间加载的依赖关系,更不需要关注具体的业务逻辑。 只需要关注webpack构建后生成的资源文件夹的结构。
把生成和上传离线资源包的过程封装成了一个npm script后,就可以方便地在各个需要接入离线系统的项目中移植,相比起pwa等方法,算是一个改造成本很低的方案。解决了接入的痛点。
生成的离线资源如何让客户端如何上传呢?
交由各个fe工程师手动上传吗? 这样显然不符合效率最大化的原则。幸好我们有持续集成和发布工具jenkins。在本团队的发布与上线流程中,jenkins代替fe工程师构建与部署前端项目。使前端项目也像传统的app与后端项目一样做到了开发与构建部署分离,提高了团队的效率。 而我们生成和部署离线包的操作,也交由jenkins替我们完成。
2.转转app测
在客户端内,预制了一份最新的各业务线的离线包与版本号的配置表。app安装后首次启动时,会将压缩包解压到手机rom中。 各业务线配置中包含app访问线上的静态资源时需拦截的url规则map:
[
{
"bizid": 13,
"date": "1513681326579",