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

最新推荐文章于 2025-05-11 22:50:20 发布

2401_83947353

最新推荐文章于 2025-05-11 22:50:20 发布

阅读量763

点赞数 19

分类专栏： 2024年程序员学习文章标签： android

本文链接：https://blog.csdn.net/2401_83947353/article/details/137161215

版权

2024年程序员学习专栏收录该内容

270 篇文章

订阅专栏

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

为什么不用插件化？

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

插件技术原理是通过Hook或者Reflect技术修改系统libs和framework代码，Android系统版本设备 ROM众多，Hook Reflect很难100%兼容。
学而思网校平台有20+的二级工程，一个工程变更重新打包时，插件资源id的重新分配，整体工程变更导致20多插件变动需要重新维护，维护人力成本有点大。
插件技术使用时存在数据传递问题自定义UI显示问题，权限重复申请等问题。
插件化的核心是ClassLoader，按照谷歌的文档，最快Android 12将会被限制, 未来有不确定性。

减包计划实施难度？

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

减包前APP体积汇总。

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

附件框架的方案

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

资源分离需要做到脚本自动化，并且只分离指定目录的资源文件，分离出来的zip应该是多个，并且和20多个工程形成一一对应关系。
资源下载需要做到按需下载，进入哪个功能下载哪个资源，避免一次性全部下载导致的loading时间太长。为了减少loading出现，需要根据业务权重做后台预加载机制。
框架层面在保证按需下载的前提下，实现业务层面的统一拦截下载，以避免大量的业务代码修改和调试，做到业务方无感知框架。
以前资源在APP内，附件框架的资源在下载后，框架代码需要做到全方面的资源访问替换技术，以避免大量的业务代码变动，做到业务层面无感知。
考虑到存量用户基数大，各个业务版本迭代资源变动小，为了进一步避免或减少loading出现的概率时间，附件框架可以做增量更新技术。保证存量用户更新资源时，资源包体积减少95%。
20多个离线zip增量迭代10个版本，会产生上百个资源文件，对应的人力维护成本也大。需要配套的自动化附件包发布脚本，一是减轻负重，二是避免人为性失误。
框架需要考虑失败重试机制需要做到多云备份预防网络事故需要做到内置外置卡双存储避免极端情况。需要完整的日志链条以持续优化。

资源分离技术说明

首先规定了附件目录attach, gradle脚本会给每个二级工程生成该目录。业务方只需要把lottie so以及其他大文件移动到附件目录，不需要修改代码。
Jekins打release包时，分离脚本启用了，gradle脚本会自动遍历二级工程：每个工程res下的图片文件会打到zip，源文件会用xml文件占位替换，每个工程的attach文件会打包到zip中。
最终Jekins产生了20+的zip文件，打包完成后命令行运行脚本，自动化发布资源文件到云端。