美文网首页Android开发Android技术知识Android开发
Android开发简记:140M到67M,学而思网校如何在一周内

Android开发简记:140M到67M,学而思网校如何在一周内

作者: Android_until | 来源:发表于2020-06-09 16:49 被阅读0次

    APP为什么要减包?

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

    祛除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和RGB值嘛。于是再次修改采集程序,一个动作分别用红色背景和白色背景采集,生成两套动作。编写相似度算法分别找出每一帧的红色图和白色图,反向色素混合,果然能还原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+架构视频+面试文档+源码笔记 这几块的内容。免费分享给大家,非常适合有这些困惑的朋友。也是希望可以帮助到大家提升进阶,有需要的可以简信我领取。

    相关文章

      网友评论

        本文标题:Android开发简记:140M到67M,学而思网校如何在一周内

        本文链接:https://www.haomeiwen.com/subject/zsszzhtx.html