包体积优化重要性
移动 App 特别关注投放转化率指标，而 App 包体积是影响用户新增的重要因素，而 App 的包体积又是影响投放转化率的重要因素。
Google 2016 年公布的研究报告显示，包体积每上升 6MB 就会带来下载转化率降低 1%， 当包体积增大到 100MB 时就会有断崖式的下跌 。对于应用商店，普遍有一个流量自动下载的最大阈值，如 应用宝，下载的app超过100M，用流量下载时，会弹窗提示用户是否继续下载，这对下载转化率影响是比较大的。某淘对新业务超过 1M 要总裁审批，一般在平台组都卡掉了。
- 下载转化率：包体积越小，下载转化率越高；
- 性能影响：安装时间长、占用内存大；
Android Apk结构
lib（主要是so文件）
- 主要集中在三方SDK
依赖SDK不规范：高德地图3D->2D；图片加载库Glide、Fresco重复。
已不用的SDK及时下线：阿里短视频SDK下线获得2M优化空间；
SDK及时升级：有些SDK会有优化so体积的版本升级，如阿里播放器升级，带来1M收益 ；
- flutter的dart代码
原生能够提供的功能，不用三方库；
已废弃的项目及时移除项目；
dart代码混淆；
asserts：
- flutter资源
存在2X和3X图，仅保留一套即可 ；
图片压缩，在引入图片前进行压缩，或转换webp或SVG格式；
- weex离线包
仅保留核心weex的场景的离线包；
- 表情图片、Json动画
上传到服务器上动态请求下发；
res:
- drawable
规范资源图片的位置，仅保留一套图；
对png图片转成webp,webp也可再用tinypng压缩，如果UI不通过，让UI提供压缩图片 ；
使用代码实现View的背景设置；
大图、gif放上传服务器；
- layout
精简删除废弃的layout资源，目前有2327个layout文件；
- 基础数据Json文件
仅保留核心基础数据，其他可做动态下发；
- 废弃资源
定期使用Analyze检查并删除各自模块无用资源；
Dex:
三方库、工具库统一，引入新的三方库前，先确认项目中是否存在功能相同库；
无用或下线的功能及时删除；
可以被混淆的代码不要Keep掉，遵照《Android混淆开发规范》；
灰度功能关闭后及时删除相应逻辑及代码；
So 压缩
so压缩是减少so文件的单个体积。
gradle打包时会对工程中的so库进行压缩，最终生成apk包的体积会减小。
android:extractNativeLibs="true"
缺点：在apk安装时，系统会再次对压缩后的so文件解压，从而造成安装apk的时间变长。
minSdkVersion >= 23 默认 android:extractNativeLibs= false。
大so动态下发
针对有些so文件压缩后，体积仍然很大，比如占比超过10%的情况，可以选择动态下发。
主要有下面四个步骤：
- 下载so库
- 解压so库
- 校验so库
- 加载so库
另外，当动态下发的so没有下载、解压、校验、加载完成之前，如果用户进入到了相关的业务场景，需要做好对应的兜底机制。比如在某场景中，使用了 opencv 库来做图片的二维码识别，当so没下载下来时，要识别二维码就会被兜底到 zxing。
优化的成绩
