背景
博主当前所做的业务是一个以内容为主的App，新活动的发布非常频繁。
1.活动发布的成本高
活动跟版发布，则用户需要频繁的更新App才能够体验最新的活动。
App上架，会受到应用市场的制约。
2.使用热更新的方式发布活动，风险大
热更新的影响范围为整个App。
3.App包越来越大
随着活动越来越多，如果所有的活动均打包到App里面，那么App的体积会越来越大。
根据Cocos的官方文档，从2.4版本，Cocos开始支持AssetBundle，能够让我们将某个模块独立出来，以插件的方式加载。
https://docs.cocos.com/creator/manual/zh/release-notes/subpackage-upgrade-guide.html
所以我们想到，将所有的活动做成AssetBundle，然后每个活动单独发布，这样就可以降低我们活动发布的成本，并减少包大小。
整体设计
整体的设计和热更新的设计大同小异，这里不再赘述，有兴趣的同学可以参考：
https://blog.csdn.net/hbdatouerzi/article/details/121330536
遇到的挑战
1.如何降低活动发布的风险
如果我们使用热更新的方式去发布活动，那么每个活动的发布均会产生一次热更新，而热更新的影响范围是整个App，这无疑会增加很多的风险，而用AssetBundle的方式，能够将影响范围控制在Bundle包内，降低风险。同时，我们也借鉴了热更新的管理方式，在本地保留上一个版本的Bundle包，当发生异常情况时，可以加载上一个Bundle包作为兜底的策略。
2.如何设计Bundle包
我们在没有使用AssetBundle之前，所有的活动均独立开发，每个活动所依赖的资源不统一，不方便复用也不方便自动化测试。
针对这种情况，我们对所有的活动进行了改造，将所有的资源抽象到BaseTemplate当中，构造统一的活动资源环境。
并统一了活动的行为，方便进行自动化测试。
经过我们的改造，Cocos开发的活动能够快速复用到课件编辑器当中，方便教研老师快速配题。
3.提高活动的成功率
AssetBundle的成功率比热更新要求更高。
如果热更新失败，用户可以通过更新新版本来解决。
如果AseetBundle活动加载失败，用户无法完成活动，则会直接影响用户体验。
我们在AssetBundle SDK1.0发布之后，观察活动的成功率，发现iOS的成功率为99.87%，Android的成功率为99.93%，我们希望Android和iOS的成功率均达到99.9+%。
通过失败上报，我们发现，活动失败的ip地址均集中分布在黑龙江地区，因此我们想到了使用多CDN下载的方式来解决。
多CDN下载
所谓多CDN下载，就是将Bundle包放在不同的CDN上，然后客户端在初始化的时候竞速，自动选择最快的CDN，如果下载失败，则自动切换CDN。
增加了多CDN下载之后，我们观察AssetBundle的成功率，发现Android的成功率提升到99.97%，iOS的成功率提升到了99.93%，达到了预期。