【保姆级】包体积优化教程

2022-09-19 15:06:15 浏览数 (1)

市面上有很多优化方案,但是都没有一个完整的链路体系,现在它来了,本文将带你进阶新高度,不管是面试、绩效KPI,还是汇报宣讲,都能让你游刃有余!

前置必读:

Android包体积优化(常规、进阶、极致) 涵盖各阶段全面的优化方案。

1、背景

  • 提升下载转化率
  • 提升更新率,这个是鲜有人提到的,二次下载同样重要,它能推动业务快速落地。

具体可以参考前置必读里面的

2、现状

  • 最新版本?MB,突破80大关?100大关?竞对?
  • 近6个月平均每个月增速?MB
  • 近6个月平均每个版本更新周期(7天?10天?)

横向对比、纵向对比 输出报表

3、目标

减少30MB & 降低30%

树立目标

4、现状具体分析

  1. 图片占比15%
  2. 代码占比25%
  3. so文件50%
  4. 其他10%

结合项目分析,输出每项占比背后的具体因素(设计花哨?业务复杂?架构合理?) 输出饼图

5、优化思路

  1. 压缩参与打包的文件
  2. 减少参与打包的文件

从哪入手,怎么做

6、规划思考

  1. 如何保证稳定性?
  2. 如何长效治理?

站在更高的角度去思考问题 如果不能保证稳定性,那宁愿不做 做完就反弹,那就是白做

7、里程碑

  1. 信息公示
  2. 确保进度稳中推进
  3. 有风险及时寻求资源支持

8、抓手

  • Android Studio
  • ApkChecker
  • ClassShark
  • 产出具有项目特色的工具

切入点

9、技术大图

PPT汇报示例

9、图片优化

由手动模式向工具模式进化

10、代码优化

11、远程so

需要熟悉打包流程,知道Gradle的各种Task执行在干什么事。

大致流程图:

打包阶段,在合并apk之前,把需要远程的so文件上传至远端,然后剔除掉。

Flutter的so远程这方面没啥资料,提一下,源码搜一下FlutterLoader,继承FlutterLoader重写startInitialization,原理就是干预原有的so文件加载路径。

11.1、下载流程

沉淀通用的下载SDK

  1. 网络状态管理
  2. 下载任务优先级调度
  3. 断点续传

11.1.1、启动下载(闲时)

闲时下载:用户是无感知的,即使失败,也不需要交互形式表现。

11.1.2、按需下载

按需下载:下载流程与闲时下载一样,但交互表现形式不一样,需要让用户感知你在干什么、什么进度,提供一个loading页承载。

自检:不一定是我们代码的问题,可能是用户网络不可用、存储不够等,针对不同的情况,给予不同的指导操作。

12、测试

  1. 兼容性:android 5.0-12.0
  2. 是否重复下载、是否可用(32/64)
  3. 断网、弱网
  4. 覆盖安装
  5. 前台退后台

13、监控告警

13.1、埋点

  1. success
  2. error code/message
  3. so name
  4. retry
  5. demotion
  6. storage size
  7. download type
  8. download time
  9. 设备信息
  10. 网络信息
  11. 用户信息

埋点的信息其实就是排障需要的信息

13.2、监控

  1. 下载成功率
  2. load成功率
  3. loading页打开成功率

13.3、告警

  1. x分钟x次失败
  2. 根据历史趋势

告警形式包括但不限于钉钉群、微信群、短信、电话等。

13.4、排障

  1. 沉淀排障指南
  2. 数据库底表查询sql

14、长效治理

给打包增加一个后置卡口,既可以感知每次的增长因素,也可以避免疯狂反弹。

后置卡口的设计原理:

  1. 打包过程中会对资源文件、代码文件、jar/aar等文件进行合并,既然知道有哪些文件,就可以知道这些文件的大小,就可以输出一个file size的文件作为当前版本的基线。
  2. 阈值配置信息可写死,可远程配置。

15、结果

  • 优化前、优化后对比
  • 竞对 对比
  • 下载时间对比
  • 安装时间对比

输出报表,列出各项数据的对比

16、未来规划

  1. 增加白名单机制,比如logo是不需要压缩的
  2. 沉淀方法论
  3. 流程工具化、智能化
  4. 月度报告
  5. 数据大盘

没有完美的方案,一定是有可以优化改进的地方

17、价值&意义

  1. 技术:沉淀通用组件、技术创新(flutter)
  2. 团队:个人影响力
  3. 公司:减少带宽,全年节省x经费
  4. 用户:下载时间减少x、安装时间减少x、
  5. 社会:每次下载减少x流量,全年节省流量x亿

18、思考

  1. 需要做到极致吗?理论上启动非必须的图片、文件、so都是可以远程的,可是 减肥是要越瘦越好吗?
  2. 是否考虑极简包方案?

避免做个工具人

19、面试问题

  1. 为什么选用tinypng,原理是什么,还有其他方案吗?
  2. 远程so的选定标准是什么?
  3. 支持断点续传吗?
  4. 会重复下载吗?
  5. 下载可以根据网络选择吗?
  6. 有文件完整性校验吗?
  7. 有下载优先级吗?
  8. 怎么避免64位设备下到32位so文件?
  9. so文件更新之后会在设备上与老的版本共存吗?
  10. 兜底方案是什么?
  11. 还有哪些可以优化的地方?

20、最后

  1. 顶级厨师在线烹饪,做好了自己吃,不负责喂

    0 人点赞