热更方案
## 安卓整包热更（代码+资源）
第一阶段，需要实现安卓的【整包热更】功能，包括代码和资源的热更机制，以实现：
1. 让灰度测试能迭代更多版本，并减少对玩家的干扰，以及对渠道的依赖；
2. 以让大版本可以以热更的方式发布出去；
目前在技术层面，有两个可行方案：
|方案|预计工作量|热包管理机制|优势|劣势|
|-|-|-|-|-|
|基于UnityAndroidIl2cppPatch自定义方案|?|需要自己实现|● 更新体验能做到极致，类似王者或MLBB一样；<br>● 无第三方依赖风险；|● 工作量可能比较大，需要评估 <br>● 技术上需要踩一些坑|
|乐变热更方案|小于1周|自带后台|● 接入快速，蛇蛇已经测试接入过；<br>● 支持分包、差分下载等额外加分功能；|● 体验上无法做到极致； <br>● 依赖于第三方，稳定性有风险；<br>● 有一定的费用|
整包热更方案需要在11月11日左右完成并选择一个渠道以非强更方式发布出去。建议是应用宝或4399这类能覆盖全量机型的渠道。
## AssetBunble资源热更
第二阶段，需要实现资源以AssetBundle包的形式进行管理，并支持AB包资源的单独热更（无需重启App）。
这部分工作有一定的前置条件，依赖于：
1. Unity版本，不同的版本对AB包的设计有较大影响，需要先确定升级到哪个Unity版本再进行；
2. 跟资源、内存优化工作有一定的耦合，需要放在一起设计；
因此，预计至少要到12月底才能进行。
## 使用LUA写单局外新的业务层需求
第三阶段，是更长期的目标，要实现单局外的新业务需求和频率改动的模块，改用LUA实现。这样iOS在某些小版本更新时，就可以不用提交AppStore审核了（但涉及单局内的改动依然需要提交）。
优先级偏低，可以在半年后再回顾这件事情。