打包包体过大问题处理方案
一. Android
前言：obb机制是安卓提供的一种拆分apk的机制，谷歌要求提交商店的apk必须在100M以下，对于游戏来说几乎都会大于100M，所以可以把apk拆分成apk（小于100M）+ obb文件，两个文件一起上传GooglPlay，用户下载的时候会连同apk+obb一起下载到用户手机上，然后我们首次进游戏检查是否含有obb文件，解压该文件就行。
- 当整包包体超过2.1G时：
- 谷歌要求每个obb文件不超过2G，因此我们上传的apk+obb不能超过100M+2G，因此我们的处理方法是：
- 将游戏前期用到的资源记录生成个res_list，通过该res_list和全部的src生成一个低于100M的apk（该方式存在的风险是，当游戏前期资源发生改动时，打新包前切记需要改动该res_list，不然会缺资源报错闪退等）；
- 如果前期用到的资源加上代码后，apk无法压缩到100M内，可以将游戏中的配置表再从apk中剔除掉出来；
- 将剩余资源（和配置表）再拆分成出一个低于2G的.obb文件和一个（或多个）zip文件；
- 将obb文件、zip文件和相关资源配置文件上传cdn服务器；
- 首次进游戏检查是否含有obb文件，再检查该包版本对应的资源配置文件是否还有其他需要下载的zip文件，然后生成下载解压队列（该方式存在风险，该部分代码执行在游戏内更新之前，如果有报错无法通过热更新和patch解决）；
- 如果是国内渠道的包，一般要求apk小于2G，我们的处理方法是：
- 类似于谷歌obb包处理，将游戏前期用到的资源记录生成个res_list，通过该res_list生成一个低于2G的apk；
- 剩下的资源生成一个（或多个）zip文件，将它们和资源配置文件一起上传到cdn服务器；
- 首次进游戏检查是否有需要额外下载的资源，再检查该包版本对应的资源配置文件是否有需要下载的zip文件，然后生成下载解压队列（该方式存在风险，该部分代码执行在游戏内更新之前，如果有报错无法通过热更新和patch解决）;
2. 当整包包体超过4G时： 海外版本因为比较低，目前还没遇到，如果遇到了也可以通过上述思路解决，生成一个2G左右的.obb文件，将剩下的资源分 成多个zip文件供玩家下载； 如果是国内渠道的话，也可以通过上述思路解决，生成1个2G左右apk，剩下资源拆分成多个zip文件供玩家下载；
二. IOS
前言：App Store要求应用程序的未压缩大小必须小于4GB。 也就是将ipa解压后的app_name.app 文件不能超过这些限制。解决方式同国内安卓包即可：
- 类似于谷歌obb包处理，将游戏前期用到的资源记录生成个res_list，通过该res_list生成一个解压后的.app文件低于2G的ipa包；
- 剩下的资源生成一个（或多个）zip文件，将它们和资源配置文件一起上传到cdn服务器；
- 首次进游戏检查是否有需要额外下载的资源，再检查该包版本对应的资源配置文件是否有需要下载的zip文件，然后生成下载 解压队列（该方式存在风险，该部分代码执行在游戏内更新之前，如果有报错无法通过热更新和patch解决）；
三. 上述方式存在的痛点
- 由于是通过res_list来控制apk的内容，所以会存在当游戏前期的资源发生改动时，导致由于包内缺资源而出现的黑屏报错闪 退等问题，所以需要经常手动调整；
- 通过res_list生成的apk或者ipa的大小无法固定下来，因为文件大小会发生变化，而我现在的项目更是没有写死文件， 所以该res_list中包含了部分完整文件夹。当apk或ipa超出限制，就需要手动调整后重新出包测试，往往需要调整多次，非常繁琐；
- 提交给App Store 的ipa包由于包体大小问题，首次进游戏需要下载资源，好像提审的包是不能发生更新的，不过目前仍然提 审成功，需要提前想好万一因为发生更新而提审失败的备用方案；
