アンドロイドアプリのインストールパッケージ減量プログラム
アンドロイドアプリのインストールパッケージのサイズの最適化:根拠、指標や方法を採用することができます。
以下に要約されます。
なぜパッケージ痩身をインストール
- パッケージには、痩身、それを必要ですか?
- あなたは何をする必要はありませんか?
インストールパッケージを小型化する主な理由は、アプリケーション・ダウンロード・変換と保持率を考慮することである。
アプリケーションも、ユーザーは特にモバイルネットワークや交通費の場合には、ダウンロードすることはできません。
また、携帯電話のスペースの問題ので、ユーザー時にはそれが最初にそれらの大きいスペースを狙っなり、いくつかのアプリケーションをアンインストールすることを選択する必要があるかもしれませんので、アプリケーションのサイズも保持に影響を与えます。
しかし、今どこでも何時代、無線LAN、大きくて安い、携帯電話のハードウェアもダンスエスカレートさ近い速度をパックに流れ、より速く、より高度な、より大きな、薄いインストールパッケージは本当に必要?誰かが気遣いますそれは?
もちろん、そうでない場合は、ここで書かれた記事が終わって、必要に応じて一定の存在しない
ユーザーは、ダウンロードしてインストール、大きいインストールパッケージする方法を多くのアプリケーションあなたはこの大きな決める気にしていない場合でも、ダウンロード時間が長くなりますので、他のは、ダウンロードが完了するため、またはネットオフさまざまな理由でキャンセルされる。
または少し長いダウンロード時間ので、完成後ので、ユーザーは、このアプリを使用することを忘れています。
現代の人々の忍耐は、そうでなければ、このような軽量アプレットソリューションは存在しませんが、限られています。
シンインストールパッケージにはある程度の問題を改善し、定量化することができます。
ダウンロードダウンロード変換および保持、インストールパッケージのサイズの最適化に加えて、いくつかの理由があります。
- プリインストールされたアプリケーションのプロモーションコスト。
- 最大パケットサイズ制限アプリケーション市場を満たしています。
- 技術も、運用レベルでは、我々はさらに再建と改善のため、未使用のコードとリソースをクリーンアップ、私たちのコードベース、いくつかの低値の事業を除去する必要性を再検討することができます。
取付構成パッケージ
APKパッケージをインストールし、我々はそれが含まれているかを見ることができます後に解凍、基本的にzipファイル圧縮され、通常、次のとおりです。
- 一個の以上
classes.dex
のファイル:コードコンパイラの結果。 assets/
フォルダ。resources.arsc
: 编译后的二进制资源文件, 包含了所有res/values
中的XML内容, 如字符串, style等, 也包括对没编译进来的资源(比如layout和图片)的路径.res/
: 没有被编译进resources.arsc
文件的资源: layout, drawable等.AndroidManifest.xml
: merge后的manifest文件.META-INF/
: 包含签名文件等.
如果有native的库, 可能还会有lib/
文件夹.
尺寸指标
安装包大小有几个指标呢?
有三个:
- 文件尺寸: 这可能是最直观的一个, 就是我们build出来的文件大小. 但是其实它是最不重要的一个指标.
- 下载尺寸: 下载app需要的大小, 最重要的指标. 因为下载市场(Google Play)会帮我们做优化, 下载尺寸会比文件的尺寸小.
一般增量安装和全新安装需要的大小是不一样的. - 安装尺寸: app安装到手机上, 启动解压之后的大小, 关系到app的留存率.
安装包分析工具
在做安装包体积优化之前, 建议用工具看一下当前的安装包情形, 找到当前的bottle neck, 这样才能有的放矢.
优化之后也好做一个比较.
APK Analyzer
APK Analyzer是Android Studio自带的工具.
使用APK Analyzer的三种方法:
Build > Analyze APK..
, 选择.apk
文件.- 切换到Project View, 双击build/outputs/apk目录下的apk文件.
- 把apk文件拖到Android Studio的编辑窗口中.
利用这个工具可以查看apk的各个组成部分以及它们各自的大小, 包括文件大小和预估的下载大小.
这个工具还可以比较两个APK, 从而可以看出具体是哪个部分有尺寸的变化.
官方插件: Android Size Analyzer
在Android Studio中可以添加Plugin: Android Size Analyzer
.
安装之后重启Android Studio, 接着就可以点击菜单Analyze > Analyze App Size
.
点击之后会给出建议, 显示出项目中比较大的文件, 建议转化一些图片到webp格式, 建议开启代码压缩混淆等.
安装包瘦身措施: Coding阶段
减少代码(native和Java代码)
- 控制第三方库的使用: 依赖第三方库的时候, 尽量减小范围, 或者使用更加友好的替代. (ProGuard会移除不用的代码, 但是它不会移除库的内部依赖.)
- 减少不必要的生成代码.
- 减少枚举的使用.
- 减小native库: 移除debug symbols和关闭so库压缩.
控制资源使用
要控制资源的使用: 减少资源的数量, 减小资源的大小.
设备屏幕支持
Android有很多屏幕密度类型:
ldpi, mdpi, tvdpi, hdpi, xhdpi, xxhdpi and xxxhdpi
并不是需要每个资源都提供多密度版本的.
当一个屏幕密度下没有提供特定的资源, Android会自动根据这个资源其他密度的版本进行缩放.
如果你的app仅需要提供缩放图像, 你可以只在drawable-nodpi
中提供单个资源. (建议还是至少有一个xxhdpi
.)
shape的使用
很多时候我们并不需要一个图片, 比如纯色或渐变色的背景, 带边框, 带圆角等.
用<shape>
尺寸就会比较小, 也不用多个密度的版本.
复用资源
这里的复用可以是改变了颜色和旋转方向等的复用.
比如改资源的tint, 或者把一个图旋转了之后再用. (thumb up变成thumb down了).
压缩图片
可以用一些工具对PNG和JPEG图片进行无损压缩: 图片质量无损但是尺寸变小.
使用WebP格式的图片
可以使用WebP格式的图片, 比JPEG和PNG压缩得更好.
Android Studio提供了转换工具: Create WebP images
注意: Google Play只接受PNG作为launcher icon.
使用矢量图
可以使用矢量图来作为可伸缩的资源, 在Android中是VectorDrawable对象.
但是矢量图的渲染需要系统的时间花销, 所以推荐只有小的icon使用矢量图.
逐帧动画
不要再使用很多个图片逐帧播放来实现一个动画效果了.
尽量用改变属性的动画来节省资源使用.
另外还有一些手段比如在程序中绘制, 而不是使用图片.
安装包瘦身措施: Post-coding阶段
Lint静态分析
Lint是静态分析工具, 会提示项目中的各种问题.
针对不用的资源, 可以专门这样检查:
在Android Studio中: Analyze -> Run Inspection by Name... -> Unused Resources
.
扫描后会对所有未使用的资源给出警告.
注意, 因为是Lint静态检查, 所以会有一些错报和漏报的情况:
assets/
目录不被扫描.- 检测不到第三方库中带来的不用的资源.
- 错报: 资源在项目中实际上用了, 但是被检测出来了. 如果资源是被动态引用的, 比如用
getIdntifer()
方法, 拼名字使用, 会被lint错误地报告说没有用到. - 漏报: 实际上没有用到, 但是没有检测出来. 这是因为还有另一个没有用到的代码引用了这个资源.
比如有一个没有人用的Fragment, 它的布局文件就不会被检测出来, 因为写在了代码里. (注意: 如果是不用的布局中include了另一个布局, 这两个布局都能被检测出来.)
静态检查只是帮我们检测并报告, 真正要移除这些资源还得靠我们手动删除.
代码压缩和混淆
ProGuard -> R8会帮我们删除不用的代码, 进行名称改写和代码优化.
minifyEnabled true
不用的代码被移除了, 类和成员的名称都被改得很短, 从而有效地减小了dex文件的大小.
这里需要注意rules的编写, 不要过度保护.
比较追求极致的方法会从这个方面下手, 进一步细化优化ProGuard Rules, 以达到更深度的混淆和压缩.
shrinkResources
移除不用资源的一个有利工具shrinkResources
:
android {
// Other settings
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
为了开启压缩资源, 必须先开启压缩代码, 即minifyEnabled
要为true
.
这样, 在打包的时候, 首先移除了不用的代码, 然后Gradle才能检测哪些资源还在被代码引用, 从而移除不用的资源.
注意这个过程并没有真的删除掉资源, 只是将不用的资源替换了一个简单版本.
跟代码压缩一样, 资源压缩也可以指定一个自定义的规则, 明确指明哪些资源要保留.
注意开启了代码压缩和混淆之后, 编译速度会变慢, 所以一般debug版本不开启.
这种删除方式靠谱吗? 精确吗? 会误删吗?
常规情况下resource shrinker还挺准确的.
但是如果你的代码(或依赖的库)中有用到Resources.getIdentifier()
方法来获取资源, (比如AppCompat中这么做), 那么说明你的代码会根据一个动态生成的字符串来查找资源.
如:
val name = String.format("img_%1d", angle + 1)
val res = resources.getIdentifier(name, "drawable", packageName)
这个时候resource shrinker默认会表现得很保守, 会保留所有符合这个名字模式的资源, 认为它们都是可能会被用到的, 从而不会删除它们.
而且resource shrinker还会扫描字符串, 查找符合资源格式的URLs, 比如file:///android_res/drawable//ic_plus_anim_016.png
, 从而保留这些对应的资源.
所以不用担心, 默认情况下, 资源压缩都是"better safe than sorry"的模式.
如果你想激进一点, 可以在keep.xml
里面把压缩模式指定为shrinkMode="strict"
, 这时候你就必须手动指定需要keep的动态使用的资源了.
如何查看都删了什么呢?
用命令行:
./gradlew clean assembleRelease --info | grep "Skipped unused resource"
注意这里assembleRelease
可以替换成任何一个开启了资源压缩的type.
执行了之后会列出所有被替换成dummy file的资源.
用IDE:
在Android Studio的Build窗口下, Toggle View切换到详细信息模式下. Build, 然后查找信息, 可以看见信息中会有一句:
Removed unused resources: Binary resource data reduced from XXXKB to YYYKB: Removed Z%
显示资源压缩节省出来的大小.
文件:
在app的输出路径(<module-name>/build/outputs/mapping/release/
)下, 和mapping.txt
一起, 还有一个resources.txt
文件.
文件的最后会列出一系列的Skipped unused resource
.
同时这个文件里也详细地写了资源之所以会被保留下来的理由. 关键字: matches string pool
. 这是前面说过的为了防止有动态使用资源的情况而采取的保守措施.
如果有空的话可以把这些Skipped unused resource
标注的文件都手动从代码库里删除.
声明支持的配置, 删掉其他
Gradle的resource shrinker会删除没有被代码用到的资源, 但是不会删掉不同设备配置下的可替代资源
(alternative resources).
可以利用resConfigs
, 来删除你的app并不需要的配置资源.
原理就是声明app支持的配置, 这样其他不支持的配置的资源就会被删除, 从而减少apk的尺寸.
比如你包含了一个库, 这个库中带有各种语言的资源, 这样默认你的app就会包含所有这些库中包含的语言的字符串. 你可以明确声明app支持的语言, 那么其他语言资源就会被删除:
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
见Remove unused alternative resources
安装包瘦身措施: 发布阶段
因为有的资源会提供多个版本, 所以一个用户下载的apk中可能包含了一些他永远也用不到的内容.
为了保证每个用户的下载尺寸都尽量小, 我们可以改进发布包的形式: 拆分成多个针对不同机型的apks;
如果是在Google Play发布, 还可以用App Bundle, 由Google Play帮我们做拆分.
Build多个apks
根据屏幕密度和指令集(ABI)的不同, 可以拆分多个apk, 每种配置只下载自己需要的资源, 从而达到减小安装包大小的目的.
Gradle就可以帮我们做这个拆分创建的工作.
具体实现见:
Build multiple APKs.
Android App Bundles
用Google Play发布应用时可以使用Android App Bundle的格式, 这是一种新的发布格式, 包含了应用所有的编译代码和资源, 把apk的生成和签名留给Google Play来做.
Google Play会根据用户不同的设备配置来生成优化的apk, 这样用户下载的就只是对应自己设备的代码和资源. 开发者不用为不同设备准备多个apk, 用户也得到了更小更优化的结果.
安装包瘦身措施: 进阶补充
要更加极致地压缩安装包, 还有一些更加复杂的手段, 比如:
- 业务层面: 动态feature, 资源动态加载.
- Dex: 加大混淆力度, 混淆四大组件和View; 去除debug信息; 优化Dex分包; Dex压缩.
- ネイティブライブラリ:デバッグ情報を削除するには、圧縮、仕立て。
- リソース:リソース短いパスと混同名;圧縮。
加えて、さらなる分析パッケージの体積はCIに添加することができる不注意ように、大きな依存するかどうか、リソースの過剰導入を知っていて、速やかに導入され、各バージョンの寸法変化を与えることができ、監視を自動化するために、搭載されるであろう。
概要
まとめこの記事を見て、減量のトピックのためのインストールパッケージ:
。?まず第一に、なぜ我々はこの問題を議論しなければならない- >アプリを使用しての可能性を増大させるためには、ダウンロードされ、インストールされて保持した(なぜ薄いそれがなければならない- >自分自身を高めるために競争を高めます力は。)
第二に、インストールされた構成のパッケージ、および関連する指標は、検出のための手段。(薄い指標と測定は注意が必要です。)
インストールパッケージの実践の量を削減する方法に焦点を当てています。(薄い様々な私は意味します。)
参考資料
- アプリのサイズを小さくします
- シュリンク、難読化、およびあなたのアプリを最適化
- APKスプリットを設定します
- 複数のAPKを構築
- 画面サイズと密度
- APKアナライザを使用してビルドを分析
- 最適化された構文解析アリペイアプリケーションの構築:Androidのパケットサイズの極端な圧縮
- 米国企業 - のAndroidアプリの薄型パッケージの最適化の練習
- タイムオタク:Androidの開発マスタークラス、パッケージサイズの最適化(上)、(次の)
最後に、マイクロチャネル公衆番号に注意を歓迎:パラディン風