利益相关，暂不能透露具体是哪款 APP 。

先说说背景：
项目因为原生实现某种功能难度较大，加上投入、历史遗留等其他因素限制，选择了“App + H5 ”混合应用的混合式方案对 APP 中的业务实现进行改造升级。改造项目进行时，对这个主题做了思考。

项目经过两年的几次迭代，分别试过楼主所说的两种方案：
• “webview + http 缓存”
• “离线包”

上面两种方案，我们在日活跃 5k 左右的项目上实验了两年左右。
最后因为“内容可控”和要“快速修改”的要求，和面对“网络劫持”的问题，选择了“离线包”方案。

---------------------------------------------

在项目完成后，我对方案做了技术总结，分析了它们的优劣：

• 在线服务，“webview + http 缓存” 方案

项目研发时，我们不约而同地想到在线服务的加载形式，即客户端使用域名的形式访问提供加载资源的 HTTP 服务器。

在线服务与 Web 应用程序别无二致，使得我们有更多的时间投入到设计应用生命周期和程序 API 中去。

可是随着项目上线若干个月，在线服务存在的缺陷便暴露出来：

- 没有预加载：首次打开的体验很差，所有文件都要从网络请求
- 缓存不可控：缓存的大小和策略由系统 webview 控制。缓存的清理逻辑不可控，往往加-载缓存几张图片后，重要的 HTML/JS/CSS 缓存就被清除了
- 网络劫持：页面被运营商或其他第三方劫持，将长时间缓存劫持的页面，导致整个功能失效

• 离线加载，楼主的“离线包”方案

离线加载方式能较好的解决在线服务存在的若干问题。

离线加载方式把功能模块的页面和资源打包在客户端中，Webview 组件加载本地资源文件，避免了联网因素的产生。 亦可将页面文件压缩成离线包，在自定义时机把离线包下载下来，做解压、校验等工作，达到在线更新 /热更新的效果。

- 离线包：前端项目构建产出的文件打包成 zip 格式，并以 ${project}_${date}_${verison}.zip 命名方式交付至客户端，存放在 App 项目内作为资源引用，称为离线包。

- 下载包：与离线包的产出相似，下载包定义为某个离线包的迭代版本，文件将存放于服务器或 CDN 上，便于客户端需要时下载。

---------------------------------------------

总的来说选哪个方案，考虑方案的优劣，最终要从投入产出比来考虑，以及面向立项中主要问题出发，才能解决实际问题。
从生产中解放出来，陪陪你爱的人，做些美好的事情。