20200305 - 曾侃

[vianvio]

问题列表：

1. app离线包实现以及配套设施，配合图的形式说明。
2. 离线包如何与发布流程打通
3. 游戏业务是否具有复用性？画一张业务大图，包含但不限于：游戏在整个业务生态中的定位，用户从游戏中获得什么，业务方在游戏中获得什么，外部合作方能否参与。
4. 基于3，技术上目前做了什么，未来能做什么

[zengkan0703]

1. 离线包实现及配套设施

1.1 离线包

离线包顾名思义就是把 h5 项目中的静态资源打包，由客户端下载到本地，用来提高 h5 应用打开速度、节省用户流量以及优化弱网体验。

打包

把 h5 项目的资源打包并生成对应的配置文件。再通过 bsdiff 等类似工具把打包后的文件与之前多个版本比对生成对应版本的增量更新包，用来减小用户下载文件大小，提高下载成功率。

打包完成之后将离线包上传到线上，用来供用户下载。同时更新线上版本号。

配置文件

配置文件一般包括当前项目的 id、当前版本、离线包过期时间、离线包检查更新间隔等等。

更新和下载

校验版本更新状态可以有多种方式，取决于项目的实时需求以及客户端的离线包项目数量

• 用户进入项目时发送请求校验，适用于客户端中离线包项目较多的情况，不会发送很多无用的请求
• 客户端固定间隔轮询校验，检测到新版本就自动下载。适用于客户端中离线包项目比较少的情况，优点时能及时更新版本，缺点是比较浪费请求资源

客户端下载离线包到本地后，将增量包和本地离线包合并生成新的离线包。根据项目 id 解压缩到对应文件夹，此时如果用户在该应用内可以提示用户已更新到新版，点击确定刷新页面打开最新版本。

由于下载成功与否和网络状况、离线包大小等息息相关，可以添加下载重试机制。

强制更新

有的项目可能希望发布之后用户直接就访问到最新版，比如接口结构有无法兼容的调整等等，可以借用 web 项目缓存的处理方式，在离线包中不打包 html 文件，且 html 文件不设置缓存，这样用户访问的永远都是线上 html，如果有新版本，直接就会访问到线上最新资源。

这样缺点就是用户每次都会访问线上 html，而且发布新版本之后由于用户的资源也访问的是线上，所以访问速度和体验会稍差。

访问

用户打开应用时，客户端拦截用户发出的资源请求，根据项目 id 判断本地是否有离线包，没有离线包就直接访问线上资源；有离线包就根据路径访问本地资源，访问失败也访问线上资源。

1.2 配套设施

我理解的配套设施有下面几种：

打包工具

主要是实现打包、生成配置文件以及合成增量包的功能。

离线包托管平台

主要用来托管业务的离线包文件以及版本配置等等，支持客户端的下载请求。

发布系统和离线包管理平台

主要用来发布新版本，可以管理各个版本的离线包。可以统计查看某个应用用户所用的离线包占比数据，以及离线包下载成功率等等。

线上项目托管

支持没有离线包或者离线包失效时用户的正常访问

JS Bridge

用于 H5 项目和客户端通信，与离线包相关的可以暴露检测更新或者下载、删除离线包的 API，用来在业务中调用。JS Bridge 主要分为 JS 调用 Native 和 Native 调用 JS 两个方向。

JS 调用 Native

一般有两种实现方式

• js 发送自定义请求（新建 iframe 等方式），按照双方约定好的规则拼接 URL Schemes，客户端拦截请求，再根据请求中的参数执行对应的操作。
• 客户端在 window 上直接注入 js 对象，供 js 调用

Native 调用 JS

安卓和 ios 均可以直接调用 js 代码

2.离线包与发布流程打通

这部分我其实没有太多了解，根据我的理解离线包的项目发布主要分为两个部分：

• 项目本身发布，也就是把项目的资源发布到线上，用户可以直接访问到
• 离线包发布，项目发布的同时把最新的离线包发布到线上，同时更新线上最新的版本号配置，用户下次触发更新检测就会直接下载新版本

3. 游戏业务

下面的分析主要是针对 app 中 H5 小游戏业务

可以根据 app 的用户偏好探索出通用模式，把公用的业务抽离出来方便复用。

4. 基于3，技术上目前做了什么，未来能做什么

像激励广告视频和贴片广告这样几乎与具体业务无关且使用方式很明确的通用逻辑已经提取。

但是像基础 UI 组件库这种需要有一套统一的视觉和设计规范之后才能更好得去做，排行榜、转盘以及道具系统这种则需要再更多业务场景中使用才能沉淀出更合适的公共逻辑和业务组件。

[vianvio]

感谢分享，整理的非常清晰，业务和技术的关系也表现的很清楚。

Q1 更新和下载可以看一下是否有离线消息机制，通过管理后台设定优先级或者类型，通过离线消息通知app后台静默下载一部分离线包，可以帮助一些重要业务在用户首次打开时候获得最佳效果，比如重要活动的主会场页面。

Q2可以尝试看下离线包发布平台是否具备开放能力，通过接口形式，将前端发布与离线包发布通过工具整合起来。

Q3&4 可以站在更高的层面再思考一下，比如游戏业务在整个公司的产品矩阵里是否能做到部分统一，比如权益共通。其次是可以深入一些，类似上面离线包的总结，对业务主体总结之后，配套要做什么也可以看一下，可能中间会发现一些技术上的盲点，往往就是可以发力的地方。

[zengkan0703]

感谢指导。

Q1 这个确实是一个好的提升体验的方法，我觉得业务上的难点主要是避免滥用和浪费。

Q2 自动化发布确实会更不容易出错，我们业务中发布版本会有工单审批之类的，所以暂时做不到代码提交之后自动发布。

Q3&4 主要是自己目前只接触了这一个业务，也没有从整体公司产品的角度考虑过这个问题。这个视角自己以前确实忽略了，之后可以特意训练用这样的角度思考问题。

再次感谢。

[vianvio]

Q2是有解法的，我们内部发布也有审批流程，而且还不只一种，但是发布和审批是解耦来看的，可以考虑一下方案。