离线包方案

业务量大的手机客户端非常适合使用混合开发方案，开发效率高，热更新，技术成熟。好的混合开发方案，既不是完全依仗 H5 前端（客户端甚至只有一个 WebView 壳），也不是只掺杂少量 H5 页面（只有一些展示页是 H5），应该是发挥 H5 和 Native 的各自优势，紧密的配合。如，H5 的导航就可以借助原生导航 混合开发: 原生导航替代浏览器导航 Web 页 js-native-navigation，两者相互配合实现体验的提升，离线包方案也是其中之一。

常用优化方案

重度的混合开发面临的主要问题就是页面的加载效率，弱网的情况下简直让人抓狂。提升页面的加载效率的主要方法就是使用缓存，众多缓存方案中，最常使用的就是浏览器缓存机制，服务器配置 Cache-Control:max-age=3153600 缓存时间为一年（任意的足够长时间），而前端资源文件名都带有 hash 值，如 xxx.6sdf9sdf.js，资源文件内容发生变化，对应的 hash 值也要发生变化，如此就能更好的使用浏览器缓存，消灭 304，提升页面的加载效率。如何对项目资源的文件名，资源的 hash 进行维护，就要使用 webpack 工具，在编译的时候自动帮我们做这些事。也可以用 service-worker 做缓存，但是 service-worker 的兼容性还不够理想。

还有一种方案就是离线包方案，简单来说，就是客户端提前将资源下载到客户端本地存储，Webview 从本地加载 H5 页面及相关资源。说起来简单，但是实现起来并不容易，且会涉及一些问题需要解决，如接口请求的跨域问题，差量更新问题，更新失败的线上应急处理等。
插图：

混合开发-离线包示意简图.png

离线包实现逻辑

下面我详细叙述下离线包方案的前后台逻辑。
项目首次上线，后管上传一份全量离线版本和全量线上版本 1.0，客户端第一次启动时，需要向后台发送一个检查更新接口，带上离线包的版本号，第一次启动没有离线包，所以版本号送空即可。后台会返回 1.0 版本的离线包下载地址，客户端静默下载，并保存到本地。如果下载失败，不具备加载离线包的情况下，使用线上版本访问。

服务器上有：
1.0 离线包 1.0 线上包

项目更新迭代到了 1.1 版本
后管上传 1.1 的全量离线包和 1.1 的全量线上包，后台对 1.1 和 1.0 的全量离线包进行差量比较分析，打包出一份 1.1-1.0 版本的差量离线包。1.0 线上包做归档，清除。客户端启动时，发检查版本请求，上送本地的离线包版本号，服务端返回对应客户端本地离线包版本的差量更新包，下载完成后，与本地包进行文件 merge。merge 完成则更新本地的离线包版本号。

服务器上有
1.0 全量离线包（供比对分析用）
1.1 差量离线包（供用户下载）  1.1 全量离线包     1.1 全量线上包

项目继续更新迭代到 1.2 版本
后管上传 1.2 的全量离线包和 1.2 的全量线上包，后台对 1.2 和 1.1，1.0 的全量离线包分别进行差量比较分析，打包出一份 1.2-1.1 和 1.2-1.0 版本的差量离线包。 1.1 的差量包和线上包可以归档，清除。客户端逻辑同上

服务器上有
1.0 全量离线包
1.1 全量离线包
1.2 全量离线包，1.2 - 1.1 差量包，1.2 - 1.0 差量包，1.2 线上包

项目再次更新迭代，以此类推，如果本地不想保存过多的差量包，可以设置如果旧版本号超出两个版本，则使用新版本的全量更新离线包进行更新。

客户端的 Webview 访问本地资源，前端的 Api 请求需要借助原生来发送请求接口（js-native 交互）来解决跨域问题。

方案优缺点对比

方案	优点	缺点
浏览器缓存	轻量，实现简单	浏览器缓存大小限制
离线包方案	无缓存大小限制，控制灵活，可以缓存任意资源	实现复杂，开发成本较大

总结

业务量较大，重度混合开发项目，且公司具备足够的研发资源可以使用离线包方案。业务量一般，或轻混合开发，或研发资源紧张的公司不适合离线包方案。