转转hybrid app web静态资源离线系统实践

一.前言

目前的转转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",