Android开发简记：140M到67M，学而思网校如何在一周内构建一套可持续的瘦身系统？

APP体积越大推广转化成本越高，因为平台功能众多，学而思网校的APP体积是在144m左右，疫情期间由于公益直播涌入大量用户，转换率上的硬伤更加暴露出来。同时移动部设定了自我突破的若干指标，转换率是关键指标，背负紧急军令我们开始了减包任务，一定要做到70m。

为什么不用插件化？

19年团队曾经尝试过插件化技术，经过两个项目试水碰到一系列问题，最终放弃使用插件化，原因如下：

1. 插件技术原理是通过Hook或者Reflect技术修改系统libs和framework代码，Android系统版本 设备 ROM众多，Hook Reflect很难100%兼容。

2. 学而思网校平台有20+的二级工程，一个工程变更重新打包时，插件资源id的重新分配，整体工程变更导致20多插件变动需要重新维护，维护人力成本有点大。

3. 插件技术使用时存在数据传递问题 自定义UI显示问题，权限重复申请等问题。

4. 插件化的核心是ClassLoader，按照谷歌的文档，最快Android 12将会被限制, 未来有不确定性。

减包计划实施难度？

1. 涉及到20+的二级工程 资源类型众多 调用代码分布广泛，要求在底层框架统一实现核心技术。
2. 需要兼容Android4.4到最新的版本系统，同时核心技术兼容后续系统迭代。设备上需要兼容各个手机品牌的高中低，兼容任务繁重。
3. 产品迭代迅速，为了避免后续开发导致APP慢慢滋长，需要设计统一的技术框架保持持久轻量。
4. 总体开发时间一周，测试一周，各个业务线还在并行开发，为了保障时间节点，技术框架需要做到最小的业务代码代动。

减包前APP体积汇总。

通过数据统计发现，20多个工程的res图片资源 assets的lottie动效资源 libs下的so文件合计约有70m。其他零散的100kb文件有6m左右。20多个二级功能，其资源一次性打进APP里是不合理的，毕竟用户常用的就那么几个。为什么不把资源分离出来托管到云端，使用时再拉取呢？想法很简单，但是面临一系列的问题，我们有6000多张图片，托管CDN的话，业务代码都要修改访问链接不现实。一个想法在内心产生，可以做一个离线附件的技术框架嘛。

附件框架的方案

附件框架：开发时资源打进APP不影响业务方开发调试预览；发版时指定的资源统一分离出来托管到云端，进入对应功能前确保资源包下载完了，运行阶段不受影响。文字虽短，框架层需要支持一下特性：

1. 资源分离需要做到脚本自动化，并且只分离指定目录的资源文件，分离出来的zip应该是多个，并且和20多个工程形成一一对应关系。

2. 资源下载需要做到按需下载，进入哪个功能下载哪个资源，避免一次性全部下载导致的loading时间太长。为了减少loading出现，需要根据业务权重做后台预加载机制。

3. 框架层面在保证按需下载的前提下，实现业务层面的统一拦截下载，以避免大量的业务代码修改和调试，做到业务方无感知框架。

4. 以前资源在APP内，附件框架的资源在下载后，框架代码需要做到全方面的资源访问替换技术，以避免大量的业务代码变动，做到业务层面无感知。

5. 考虑到存量用户基数大，各个业务版本迭代资源变动小，为了进一步避免或减少loading出现的概率时间，附件框架可以做增量更新技术。保证存量用户更新资源时，资源包体积减少95%。

6. 20多个离线zip增量迭代10个版本，会产生上百个资源文件，对应的人力维护成本也大。需要配套的自动化附件包发布脚本，一是减轻负重，二是避免人为性失误。

7. 框架需要考虑失败重试机制 需要做到多云备份预防网络事故 需要做到内置外置卡双存储避免极端情况。需要完整的日志链条以持续优化。

资源分离技术说明

1. 首先规定了附件目录attach, gradle脚本会给每个二级工程生成该目录。业务方只需要把lottie so以及其他大文件移动到附件目录，不需要修改代码。

2. Jekins打release包时，分离脚本启用了，gradle脚本会自动遍历二级工程：每个工程res下的图片文件会打到zip，源文件会用xml文件占位替换，每个工程的attach文件会打包到zip中。

3. 最终Jekins产生了20+的zip文件，打包完成后命令行运行脚本，自动化发布资源文件到云端。

资源发布自动化技术

1. 批量编译点九图 确保APP使用时无失真拉伸
2. 批量使用熊猫 WEBP技术对图片文件优化 以减少资源体积
3. 自动对比历史版本归档记录 产生对应的增量更新文件
4. 同时发布多个资源包到案例云和腾讯云 双云避免网络事故

使用python脚本自动化发布做到人力不及的流程，避免了类似于插件化维护的管理成本。

抽象统一的下载框架

1. 底层框架统一拦截跳转，确定需要进入的二级模块，检查下载对应资源文件，下载后继续跳转。统一实现了20+业务的核心代码，避免业务改动。

2. 下载环节做到网络错误感知，阿里云腾讯云自动切换，4次失败重试避免网络事故。文件存储时优先内置卡，次要外置卡存储，避免极端的文件读写问题。

3. 框架层面统一文件管理，版本迭代管理，避免修改业务代码。同时增量更新确保用户最小的下载量。

资源访问的无缝替换

附件资源分离做到自动化 发布做到自动化 下载做到了抽象统一。再做到无缝替换技术，基本上业务代码变更就很微小。所谓无缝替换，就是从关键接口层面统一APP内置资源 下载资源的访问。核心技术一处实现，业务代码无需变更。下面列举res无缝替换 lottie无缝替换 Glide无缝替换。

如你所见，无缝替换技术是重写关键接口而非Hook的方式，这让网校APP做到100%兼容；从内核层面进行流替换技术，一处变更全场景生效，避免了大量的业务改动。

最后

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长。而不成体系的学习效果低效漫长且无助。时间久了，付出巨大的时间成本和努力，没有看到应有的效果，会气馁是再正常不过的。

所以学习一定要找到最适合自己的方式，有一个思路方法，不然不止浪费时间，更可能把未来发展都一起耽误了。

如果你是卡在缺少学习资源的瓶颈上，那么刚刚好我能帮到你。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！*