-
资源分离需要做到脚本自动化，并且只分离指定目录的资源文件，分离出来的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文件，打包完成后命令行运行脚本，自动化发布资源文件到云端。
资源发布自动化技术
- 批量编译点九图 确保APP使用时无失真拉伸
- 批量使用熊猫 WEBP技术对图片文件优化 以减少资源体积
- 自动对比历史版本归档记录 产生对应的增量更新文件
- 同时发布多个资源包到案例云和腾讯云 双云避免网络事故
使用python脚本自动化发布做到人力不及的流程，避免了类似于插件化维护的管理成本。
抽象统一的下载框架
-
底层框架统一拦截跳转，确定需要进入的二级模块，检查下载对应资源文件，下载后继续跳转。统一实现了20+业务的核心代码，避免业务改动。
-
下载环节做到网络错误感知，阿里云腾讯云自动切换，4次失败重试避免网络事故。文件存储时优先内置卡，次要外置卡存储，避免极端的文件读写问题。
-
框架层面统一文件管理，版本迭代管理，避免修改业务代码。同时增量更新确保用户最小的下载量。
资源访问的无缝替换
附件资源分离做到自动化 发布做到自动化 下载做到了抽象统一。再做到无缝替换技术，基本上业务代码变更就很微小。所谓无缝替换，就是从关键接口层面统一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这种重量级内核了吧，毕竟用户看的是屏幕，产品要的是实现了而不是怎么实现。抱着试一试的心态，开始编写这个工具，中途也遇到了些问题。
**1. 时间平滑问题：**动画效果很重要一点就是帧之间的时间平滑度，起初的程序控制设定在30ms一帧采集，但是发现实际的采集结果有的是30ms，有得是200ms，时间平滑度出入太大效果不理想。通过时间数据采集，发现采集后编码PNG时间，文件IO时间变动，中间又有系统内存回收导致的。再次修改采集方法，采用双线程模型加高缓存策略，保证了时间平滑度在30ms左右。
**2. 祛除背景问题：**截屏窗体采用纯白背景0XFFFFFFFF，设想对截屏图片使用程序去除白色部分，然而发现有些色素是有Alpha通道的。理论上讲白色可以和任意Alpha通道色值混合成目标色值。这就意味着还原Alpha通道色值有些不现实，再次陷入困境。。。查阅了颜色混合公式 Dst = (Src * Alpha + (256 – Src.Alpha * Alpha / 255) * Dst ) / 255, 联想到对于同一帧如果分别采用白色背景和红色背景，利用混合模式对比不就能还原出色素的Alpha和RG
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
B值嘛。于是再次修改采集程序，一个动作分别用红色背景和白色背景采集，生成两套动作。编写相似度算法分别找出每一帧的红色图和白色图，反向色素混合，果然能还原Alpha通道和RGB值~
**3. 祛除噪点问题：**在祛除背景还原Alpha通道后，自以为没问题了，后来发现少量图片有零星噪点，深入分析代码发现，每一帧的白色帧和红色帧不是100%的吻合，图片边缘合起来对比还是有那么一两个像素的误差。开始各种尝试解决这种误差，祛除噪点，最终找到合适的算法，类似于卷积思想：以白色为基础帧，红色为对比帧，还原白色（X Y）的色素时，通过红色（X Y）周围9个点卷积还原，质量无损失，噪点完美祛除~
解决三面三个问题，Unity 3D截取转动画实现了，每个动作帧生成时间在4分钟左右。后续编写独立的动画组件把内存控制在15m以内，成功在两个项目中实际应用。本次瘦身方案采用这个策略，祛除掉了Unity 3D内核减掉15m体积，功能依然满足，成功达成目标！本次减包的主要方案就是资源分离下发，祛除Unity 3D，顺便删除少量冗余资源，媒体库合并等方式。
**提醒：**可以理解做了个工具，可以截取指定区域的画面，通过算法生成了设计级别的动效，这种方式可以应用在多个场景，比如cocos等其他特效技术替换。
作者简介：袁威为好未来高级Android工程师
最后对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！
最近许多朋友都在经历着面试，这里推荐一下自己之前整理的文章给大家，希望能有点帮助：
我肝了3个月终于整理出了这份超全面的《Android面试题及解析》，面试不再怕的了！
被辞退后我一周面试了13家公司，想给你们分享这个收获
最后在这里，我整理了一份资料分享给大家，内容包含：?Android学习PDF+架构视频+面试文档+源码笔记?这几块的内容。免费分享给大家，非常适合有这些困惑的朋友。也是希望可以帮助到大家提升进阶，有需要的可以简信我领取。
oid学习PDF+架构视频+面试文档+源码笔记]( )**?这几块的内容。免费分享给大家，非常适合有这些困惑的朋友。也是希望可以帮助到大家提升进阶，有需要的可以简信我领取。