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学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!*

  • 28
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值