主要从下面三个方面压缩,还有很多小细节可以优化,可以去官方查找资料
- java代码混淆
- 静态资源引用
- APK包拆开分析
java代码
配置混淆
网上随意找一个通用的Proguard文件,很多按此不表
- 初始安装包:25,165,735
- 配置proguard:24,820,806
- 缩小336K
资源文件
lint清理未使用的资源文件,年老的项目能清理不少的文件
- 选择你的项目
- 点击AS上的Analyze菜单按钮
- 选择Run Inspection by Name
- 会出现一个弹窗
- 输入unused resources
- 下面的输出栏会输出没有用的资源文件。
- 点进去看看,然后删除无用的。
- 再次打包,你会发现你的apk小了很多。
lint分析一下代码,静态代码分析工具
能查找看到不少问题,
图片替换(暂不处理)
图片过一遍,简单的单色图片可以用xml配置出来,可以节约一些
AndResGuard
AndResGuard是一个缩小APK大小的工具,它的原理类似Java Proguard,但是只针对资源。AndResGuard 提供如下功能:
- 图片文件压缩功能。
- 原本冗长的资源路径变短,例如将res/drawable/wechat变为r/d/a。
与此同时,在资源文件多且名字很长的情况下,签名时候MANIFEST.MF和CERT.SF文件也会很大,使用AndResGuard混淆后缩小几百K不是问题。
APK包分析 Android Studio-->Build-->analyze Apk-->选择文件
随便给张示例图
分析发现有这么几个大头:
- assets很大
- so库很大
- 一个小项目有多个.dex文件
检查.dex,
重复或者未使用的三方,一般来说,打开比较大的三方包就行
模块 | 包 | 包名 | 大小 |
---|---|---|---|
图片缓存工具 | ImageLoader | com.nostra13.universalimageloader | 92K |
图片缓存工具 | glider | com.bumpetech.glide | 250K |
Gson工具 | network | com.networkbench.com.google | 117k |
Gson工具 | com.google.gson | 227K | |
环信 | huphenate | com.huphenate.chat | 224K |
网络框架 | okgo | com.lzy.okgo | 60k |
网络框架 | retrofit | com.retrofit2 | 50k |
Assets中的H5
- 前端将不少源码映射也放进来了,去掉所有的js.map和css.map之后打包
- 16,531,394 少了8M
- Assets包从9.9M多直接到了2.3M
so文件过大
这里小科普一下,NDK 开发时会涉及到 CPU 架构的适配,不同的机器上可能会有不同的 CPU 架构,也就是说,翻译到机器上使用的规则不一样,Android 上有7种 CPU 架构。
- armeabi
- armeabi-v7a
- arm64-v8a
- x86
- x86_64
- MIPS
- MIPS64
从厂家上来分是有三种,arm,x86,MIPS,arm 系列是绝大多数手机上使用的,x86 主要是运用在平板上,而 MIPS 基本上就没见过。
正常来说只使用 armeabi-v7a 就可以适配基本所有手机了,因为现在手机基本上都支持这种CPU架构,但是对于同时也能支持 arm64-v8a 的手机来说,性能上就不如使用对应 CPU 架构的快了,毕竟是32位和64位的区别
科大讯飞
libmsc.so 每种平台大概1M
极光推送
- 每种平台大概100K
- 新版的所有so文件加在一起仅在80k左右可以考虑使用新版的sdk
环信
环信包含两个so文件
-
每种平台大概1.5M
由于时间和机型有限,只做分析并没有做具体的优化