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

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%兼容；从内核层面进行流替换技术，一处变更全场景生效，避免了大量的业务改动。

祛除 Unity 3D 内核的历程。

在 APP 多个业务中，互动环节要显示 3D 粒子效果的机器人，阿丘之类的动画。因为制作 3D 粒子效果的成本比较大，团队起初定的技术方案是采用 Unity 3D 渲染模型。发现 Unity 3D 本身是很出色的特别是对于游戏，但是对于我们网校 APP 这个大平台而言，却不是那么合身，原因如下：U3D 的 library bin 文件占据着 15M 的 APP 体积；U3D 是不开源的碰到一个手机崩溃无从解决；载入释放 U3D 内核内存需要 5 秒产品体验差；使用 U3D 时内存多开销 170m。这种场景让想起几年前在使用 Cocos 渲染时，为了减少 40m 的内核库，居然花费了一周时间精简编译 Cocos 的艰辛历程。这种场景代表某种尴尬：为了特效引入了一个太重的技术方式，这种技术无法做到轻量化，不大适合平台化的 APP。

偶然在使用一个录屏软件时，产生点灵感，3D 特效复杂如果设计动画帧成本太大所以设计部不接受，如果我们做个截屏小工具，运行这些特效连续截屏，截取指定区域，生成动画帧，网校 APP 直接使用程序截屏的动画帧，就可以祛除 U3D Cocos 这种重量级内核了吧，毕竟用

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

户看的是屏幕，产品要的是实现了而不是怎么实现。抱着试一试的心态，开始编写这个工具，中途也遇到了些问题。

**1. 时间平滑问题：**动画效果很重要一点就是帧之间的时间平滑度，起初的程序控制设定在 30ms 一帧采集，但是发现实际的采集结果有的是 30ms，有得是 200ms，时间平滑度出入太大效果不理想。通过时间数据采集，发现采集后编码 PNG 时间，文件 IO 时间变动，中间又有系统内存回收导致的。再次修改采集方法，采用双线程模型加高缓存策略，保证了时间平滑度在 30ms 左右。

**2. 祛除背景问题：**截屏窗体采用纯白背景 0XFFFFFFFF，设想对截屏图片使用程序去除白色部分，然而发现有些色素是有 Alpha 通道的。理论上讲白色可以和任意 Alpha 通道色值混合成目标色值。这就意味着还原 Alpha 通道色值有些不现实，再次陷入困境。。。查阅了颜色混合公式 Dst = (Src * Alpha + (256 – Src.Alpha * Alpha / 255) * Dst ) / 255, 联想到对于同一帧如果分别采用白色背景和红色背景，利用混合模式对比不就能还原出色素的 Alpha 和 RGB 值嘛。于是再次修改采集程序，一个动作分别用红色背景和白色背景采集，生成两套动作。编写相似度算法分别找出每一帧的红色图和白色图，反向色素混合，果然能还原 Alpha 通道和 RGB 值~

**3. 祛除噪点问题：**在祛除背景还原 Alpha 通道后，自以为没问题了，后来发现少量图片有零星噪点，深入分析代码发现，每一帧的白色帧和红色帧不是 100%的吻合，图片边缘合起来对比还是有那么一两个像素的误差。开始各种尝试解决这种误差，祛除噪点，最终找到合适的算法，类似于卷积思想：以白色为基础帧，红色为对比帧，还原白色（X Y）的色素时，通过红色（X Y）周围 9 个点卷积还原，质量无损失，噪点完美祛除~

解决三面三个问题，Unity 3D 截取转动画实现了，每个动作帧生成时间在 4 分钟左右。后续编写独立的动画组件把内存控制在 15m 以内，成功在两个项目中实际应用。本次瘦身方案采用这个策略，祛除掉了 Unity 3D 内核减掉 15m 体积，功能依然满足，成功达成目标！本次减包的主要方案就是资源分离下发，祛除 Unity 3D，顺便删除少量冗余资源，媒体库合并等方式。

**提醒：**可以理解做了个工具，可以截取指定区域的画面，通过算法生成了设计级别的动效，这种方式可以应用在多个场景，比如 cocos 等其他特效技术替换。

作者简介：袁威为好未来高级 Android 工程师

最后对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！