从APK的文件结构说起
APK在安装和更新之前都需要经过网络将其下载到手机，如果APK越大消耗的流量就会越多，特别是对于使用移动网络的用户来讲，消耗流量越多就代表需要花更多的钱去购买流量。同时一些第三方应用商城也会对上传的APK大小有限制，所以为了能够让产品能够更受商城和用户欢迎，APK瘦身是第一步，更小的APK标示着更多地用户愿意去下载和体验。
为了能够减小APK的大小，首先需要知道APK由哪些部分构成，然后针对每个部分做相应的优化工作，下图是一个APK解压后的文件结构:
各文件的介绍如下：
-
classes.dex：classes.dex是java源码编译后生成的java字节码文件。但由于Android使用的dalvik虚拟机与标准的java虚拟机是不兼容的，dex文件与class文件相比，不论是文件结构还是opcode都不一样。目前常见的java反编译工具都不能处理dex文件。Android模拟器中提供了一个dex文件的反编译工具，dexdump。用法为首先启动Android模拟器，把要查看的dex文件用adb push上传的模拟器中，然后通过adb shell登录，找到要查看的dex文件，执行dexdump xxx.dex。另，有人介绍到Dedexer是目前在网上能找到的唯一一个反编译dex文件的开源工具，需要自己编译源代码。
-
resources.arsc：编译后的二进制资源文件
-
AndroidManifest.xml：该文件是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等等信息，如要把apk上传到Google Market上，也要对这个xml做一些配置。在apk中的AndroidManifest.xml是经过压缩的，可以通过AXMLPrinter2工具解开，具体命令为：java -jar AXMLPrinter2.jar AndroidManifest.xml
-
proguard.cfg：代码混淆配置文件；
-
project.properties：标示APK的target sdk和依赖关系，这里的依赖关系指示的是该APK依赖到了哪些工程；
-
assets：assets目录可以存放一些配置文件（比如webview本地资源、图片资源等等），这些文件的内容在程序运行过程中可以通过相关的API获得。具体的方法可以参考SDK中的例子：在sdk的 \SDK\1.6\android-sdk-windows-1.6_r1\platforms\android-1.6\samples\ApiDemos 例子中，有个com.example..android.apis.content 的例子，在这个例子中他把一个text文件放到工程的asset目录下，然后把这个txt当作普通文件处理。处理的过程在ReadAsset.java中。同理，asset也可以放置其他文件。
-
lib：lib目录下的子目录armeabi存放的是一些so文件。这个地方多讲几句，都是在开发过程中摸索出来的。eclipse在打包的时候会根据文件名的命名规则（lib**.so）去打包so文件，开头和结尾必须分别为“lib”和“.so”，否则是不会打包到apk文件中的。其他非eclipse开发环境没有测试过。如果你是用SDK和NDK开发的话，这部分很重要，甚至可以通过把一些不是so文件的文件通过改名打包到apk中，具体能干些什么那就看你想干什么了，呵呵呵！
-
META-INF：META-INF目录下存放的是签名信息，用来保证apk包的完整性和系统的安全。在eclipse编译生成一个apk包时，会对所有要打包的文件做一个校验计算，并把计算结果放在META-INF目录下。这就保证了apk包里的文件不能被随意替换。比如拿到一个apk包后，如果想要替换里面的一幅图片，一段代码， 或一段版权信息，想直接解压缩、替换再重新打包，基本是不可能的。如此一来就给病毒感染和恶意修改增加了难度，有助于保护系统的安全。
-
res：res目录存放资源文件。包括图片、字符串、raw文件夹下面的音频文件、各种xml文件等等。
从图一可知，APK中classes.dex、lib、资源文件是大头，APK瘦身主要就是优化这三类，关于这三种类型的文件比较成熟的优化方法有：
-
classes.dex:通过代码混淆，删掉不必要的jar包和代码实现该文件的优化；
-
lib:一个硬件设备对应一个架构（mips、arm或者x86），只保留与设备架构相关的库文件夹（主流的架构都是arm的，mips属于小众，默认也是支持arm的so的，但x86的不支持），这样可以大大降低lib文件夹的大小；
-
资源文件：通过Lint工具扫描代码中没有使用到的静态资源。
上面介绍的三种类型文件的优化方案的确能够在一定程度上减小APK的大小，但在最近做项目的过程中经过研究发现还可以更进一步优化APK的大小，具体方案如下：
-
多分辨率适配：我之前写过一篇关于多分辨率适配的文章Android多分辨率适配经验总结,一套图、一套布局，多套dimens.xml文件，在使用最小资源的情况下搞定多分辨率适配；
-
预置数据：和游戏一样，程序和数据分离，进入模块时下载预置数据（下载的策略需要注重用户体验，在需要使用数据的地方下载）；
-
图片资源：使用tinypng和webP，下面详细介绍图片资源优化的方案。
图片资源优化攻略
图片资源的优化原则是：在不降低图片效果、保证APK显示效果的前提下缩小图片文件的大小。
使用tinypng优化大部分图片资源：
tinypng是一个支持压缩png和jpg图片格式的网站，通过其独特的算法（通过一种叫“量化”的技术，把原本png文件的24位真彩色压缩为8位的索引演示，是一种矢量压缩方法，把颜色值用数值123等代替。）可以实现在无损压缩的情况下图片文件大小缩小到原来的30%-50%。压缩率和压缩后的效果如下：
上面的图片对比举例不太好，不过可以看到压缩前后图片效果并没有变化，需要说明的是：tinypng支持png和jpg图片的压缩，并且也支持9图的压缩。
tinypng的缺点是在压缩某些带有过渡效果（带alpha值）的图片时，图片会失真，这种图片可以将png图片转换为下面介绍的webP格式，可以在保证图片质量的前提下大幅缩小图片的大小。
tinypng提供了开放接口供开发者开发属于自己的压缩工具，不过这是付费服务，对于普通用户来说，tinypng为每个用户提供的每月图片免费压缩数量已经足够了。
使用webP图片格式：
WebP是谷歌研发出来的一种图片数据格式，它是一种支持有损压缩和无损压缩的图片文件格式，派生自图像编码格式 VP8。根据 Google 的测试，无损压缩后的 WebP 比 PNG 文件少了 45％ 的文件大小，即使这些 PNG 文件经过其他压缩工具压缩之后，WebP 还是可以减少 28％ 的文件大小。目前很多公司已经将webP技术运用到Android APP中，比如FaceBook、腾讯、淘宝。webP相比于png最明显的问题是加载稍慢，不过现在的智能设备硬件配置越来越高，这都不是事儿。
假如你打算在 App 中使用 WebP，除了 Android4.0 以上提供的原生支持外，其他版本以可以使用官方提供的解析库webp-android-backport编译成so使用。
通常UI提供的图片都是png或者jpg格式，我们可以通过智图或者isparta将其它格式的图片转换成webP格式，isparta可实现批量转换，墙裂推荐！
使用tintcolor实现按钮反选效果：
通常按钮的正反旋图片我们都是通过提供一张按钮正常图片和一张按钮反选图片，然后通过selector实现，两张图片除了alpha值不一样外其它的内容都是重复的，在Android 5.0及以上的版本可以通过tintcolor实现只提供一张按钮的图片，在程序中实现按钮反选效果，前提是图片的内容一样，只是正反选按钮的颜色不一样。
（1）
清除Android工程中没用到的资源
项目需求一改再改，UI一调再调，结果就是项目中一堆已经用不到但却没有清理的垃圾资源，不说工程大小问题，对新进入项目的人或看其他模块的代码的人来说，这些没清理的资源可能也可能会带来困扰，所以最好还是清理掉这些垃圾，对于一个稍微大一点的工程来说，手工清理明显是不现实的，这就需要一个方法做这些事情。
清理资源文件
要清理没用的资源，首要的工作当然是找到他们，我们知道Anroid SDK中有一个工具叫lint，可以帮助我们查看工程中存在的问题，其中有一项功能就是查找没用到的资源，这样这一步就简单了，直接对需要清理的工程执行以下命令：
lint --check "UnusedResources" [project_path] > result.txt
执行完以上命令后工程中关于UnusedResources的问题就都保存到result.txt了，先来看一下result.txt的内容
res/values/arrays.xml:202: Warning: The resource R.array.msg_my_friend_category_items appears to be unused [UnusedResources]
^M
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
res/layout/back_up_level_list.xml: Warning: The resource R.layout.back_up_level_list appears to be unused [UnusedResources]
res/layout/backup_list.xml: Warning: The resource R.layout.backup_list appears to be unused [UnusedResources]
res/layout/backup_listview_item.xml: Warning: The resource R.layout.backup_listview_item appears to be unused [UnusedResources]
可以看到列出了没用到的layout及没用到的values值等信息。有了这些信息，接下来需要做的就是分析这些信息了，手工分析不太现实，因为这个文件可能会非常大，比如我执行上述命令后文件就有2212行，这种事情，当然是交给计算机解决了。
仔细看生成的文本中的内容会发现结果是按行输出的，每个问题是单独的一行，而且每一行中的内容也很有规律
file_path[:line]: Warning: info [UnusedResources}
所以还是可以很方便地得到哪个文件甚至哪行有问题的，我处理的时候只清理了没用的文件，像上面的res/values/arrays.xml:202就没有管，下面看下怎么清除没用到的资源文件。
String projectPath = "***";
BufferedReader reader = new BufferedReader(new FileReader("/home/angeldevil/result.txt"));
String line;
int count = 0;
while((line = reader.readLine()) != null) {
if (line.contains("UnusedResources") && !line.contains("res/value") && !line.contains("appcompat")) {
count++;
int end = line.indexOf(":");
if (end != -1){
String file = line.substring(0, end);
String f = projectPath +file;
System.out.println(f);
new File(f).delete();
}
}
}程序非常简单，就几行代码，就是读取result.txt文件的每一行，根据自己需要的条件过滤掉不需要处理的行（比如我只想清理anim、drawable及layout，所以过滤掉res/value目录下的信息，并且忽略appcompat相关的信息），每一行":"前的字符串就是文件名，找到了文件名就好处理了，直接删除，或者打印出来，或者写到一个文件里以再次确认是否确认要删除，当把结果写到一个文件后我们就可以查看这个文件是否有现在没用到但仍不想删除的文件，如果有，处理方法也很简单，去掉这一行或简单地做个标记，如前面打#，然后再读取这个文件把没做标记的行对应的文件删除就行了。
看起来很简单，但是有几点需要注意：
- 有些layout文件，可能你之前用了他们，并在相应的Java文件中用了这个layout布局中的id，如对某些ID的控件设置了onClickListener，并在onClick的switch...case中引用了这些ID，但最后又不用这个Layout了，这时这个layout就是UnusedResource，但是以前引用它的Java代码中对这个layout中的某些ID的引用还没清除，此时删掉这个Layout就会报错，你可以选择清理报错的Java代码，因为它们其实时Dead Code。或者每次清理一部分资源文件，如先清理layout，再清理drawable，对于每一项也可以根据文件名的规则每次再清理一小部分，如只清理res/layout中以item_of开头的文件。
- lint的分析貌似是不完全准确的，或者说不够智能，比如有一个drawable只被一个layout引用，而这个layout又是Unused的，lint可能不会发现这个drawable是Unused，这就需要我们多次重复执行前面的步骤，直到count为0。
- lint只能分析资源文件，即res目录下的文件，如果要分析Java文件还需要其他方法，而且，有可能某个资源文件被某Java文件引用，而这个Java文件又是Unused，这样这个资源文件就会逃过lint的检查，所以我们最好先清理了Java文件再清理资源文件。
清理Java文件
首先还是要找到未用到的文件，还是利用工具，我用的是UCDetector，即Unused Code Detector，使用方法就不说了，直接Google一下。
安装Eclipse的UCDetector插件，对工程执行检查，这个需要的时间可能会很长，我当时检查了两个小时。。同lint一样，结果会输出到一个文本文件中，同样是每个问题一行，所以只要行分析就行了，比如这样：
com..SampleAdapter.(SampleAdapter.java:18) Class "SampleAdapter" has 0 references SampleAdapter org.ucdetector.analyzeMarkerReference
com..SampleAdapter.(SampleAdapter.java:56) Change visibility of Member class "SampleAdapter.ViewHolder" to private - May cause compile errors! SampleAdapter.ViewHolder org.ucdetector.analyzeMarkerVisibilityPrivate
可以看到，检测结果中包含很多信息，如某个类没被用到，某个方法的可见性太大等，同样的，现在只处理没用到的类文件，其他不管了。
String reportPath = "**/ucdetector_reports/UCDetectorReport_001.txt";
BufferedReader reader = new BufferedReader(new FileReader(reportPath));
String line;
int count = 0;
while((line = reader.readLine()) != null) {
if (line.contains("Class") && line.contains("has 0 references") && !line.contains("Method")[ && other conditions]) {
count++;
int end = line.indexOf(".<init>");
if (end != -1){
String className = line.substring(0, end);
System.out.println(className);
}
}
}通过以上代码基本上就能找到没用到的类了，还是建议不直接删除而是把结果输出出来，因为结果输出来以后你会发现很多文件你是不想删除的，如：
com.nostra13.universalimageloader.core.assist.DiscCacheUtil.(DiscCacheUtil.java:31) Class "DiscCacheUtil" has 0 references DiscCacheUtil org.ucdetector.analyzeMarkerReference Sergey Tarasevich (nostra13[at]gmail[dot]com)
某些类库中的文件也可能会被检测出来，对于这种直接在if条件中过滤掉就好了，也可能自己的一些文件暂时没用到但不想删除，从结果中过滤就好了。
清理资源就两个步骤：
- 找到未用到的资源
- 按需清理这些资源
通过UCDetector和lint基本上就可以检测到项目中UnusedResource相关的问题了，一般像方法可见性，某个方法没用到这种问题，不处理也罢，改到相应的文件时手工处理算了，主要处理的就是某些文件或类没被用到，有检测报告，分析下报告就行了。这种报告一般是每行报告一个问题并且每行的文字是有规律的（工具生成的肯定有规律），按规律过滤出我们需要的信息就行了
Android Studio Lint
项目新版本的迭代接近尾声, 因为历史累积问题, 导致有很多无效的资源让已经臃肿的APK变得更肿, 因此公司决定做一次Android APK的资源瘦身.
这次瘦身使用的是 Lint审查工具 , 用Android Studio的Generate Signed APK打包, 瘦身前APK为17.3M, 瘦身后为15.7M. 瘦身结果为APK大小减少了1.6M(9.x%)
1. 完全相同的一张图片, 在项目中存在多份(不同的开发人员从UI资源文件夹里复制出来, 修改为不同的名字, 引入工程)
2. 版本多次迭代后, 许多XML文件已经不再使用了(包括布局文件, 自定义图形文件, 动画文件, 颜色文件, 字符文件strings.xml, 单位文件dimens.xml等).
3. 由于功能的迭代, 有些Activity, Fragment已经无效(好像 Android Studio Lint无法查处这一类的无效资源 )
******** ******** 第二部分: 瘦身工具介绍 ******** ********
1. 使用的是Android Studio工具做代码审查( Inspect Code功能 ), 实际上使用到的是其中 Android Lint 部分
2. Inspect Code配置(可以 单独选择Module 'app' 部分, 个人感觉library部分审查的意义不大. 不过为了方便, 我还是选择了 Whole project. .. 不过这样的结果就是, 同事的红点键盘电脑还没有Inspect完... 我已经把150多个无效资源全部处理完了... 所以还是 自行决定是否Fire The Whole吧 ...)
******** 第三部分: Android Studio Inspect Code 结果简介 ********
zzzZZZ(Inspecting...)
1. 既然是瘦身, 那无效资源引用就是头等重要的事了. 个人觉得这部分都在 Inpsection模块的Android Lint 视图里面了.
首先, 在Inspection模块里找到Android Lint
然后, 在Inspection模块的Android Lint里向下滑动找到 Ununsed resources
来, 看一下Unused recources展开后的样子(对不起, 重复图片, 无效xml文件, 无效的strings.xml和dimens.xml都已经处理完了)...
( 说一下一个我自己的 处理"技巧" 吧, 对于无效的xml文件, 要删除起来其实还比较麻烦, 因为Android Studio在xml页面好像没有删除按钮??? 我是这么做的:
在Inspect Code 的Android List结果展示区, 双击对应的xml无效提示(例如: The resource 'R.dimen.spacing_0_5' appears to be unused这一个item),
进入对应的xml文件后, 把所有内容删除... 不要怕... 错了git可以恢复的...
当你删除的手酸的时候或者内心惶恐不安的时候, 在Android Studio里Clean一下工程[不懂的谷歌搜索: Android Studio Clean 工程...]
之后在Android Studio工程里遍历所有的xml文件, 对于没有内容的xml文件, Android Studio会用红色的波浪线提示, 然后选中所有需要删除的xml文件, 一次性删除... 建议带上引用审查)
安全删除之引用审查
( 说一下一个坑吧 ... 事情的起因是这样的: android.content.res.Resources$NotFoundException
Android Lint信誓旦旦的说, R.dimen.spacing_0_5是没用的(实际上他的名字是R.dimen.spacing_0.5...) 后删之, 保留了values-1280x720目录下diemns.xml里的R.dimen.spacing_0.5定义...
这样看起来应该出现在分辨率为1280x720的HTC D816V完美不崩溃而其他分辨率可能崩溃的情况... 然而HTC D816V表示不服, 打开APP后崩溃,遂伙同Android Studio提示单身程序狗: Caused by: android.content.res.Resources$NotFoundException: File res/drawable/common_btn_grayf10.xml from drawable resource ID #0x7f0a0018
我找了一下, common_btn_grayf10.xml确实存在... HTC你"眼瞎"是不是!!! 还是Android Studio聪明, 在xml预览图里无预览, 但是提示spacing_0.5 not in right format... 于是将spacing_0.5修改为spacing_1, 错误提示不记得在不在了, 但是程序依旧崩溃... 查了很久后, 尝试将spacing_0.5也放到values/dimens.xml里试试... 结果崩溃问题解决...
总结: 在做适配的时候, 一定要保证values/dimens.xml文件是最大而全的 .就是说values/dimens.xml = values-aaxbb U values-ccxdd U etc... 这里U是离散数学里的取并集的意思(打我吧... 很罗嗦对不对)
)
2. 实际上Android Studio的Inspect Code还蛮强大的, 会帮你审查无效的LinearLayout, xml布局里View过多, onDraw()函数中分配内存这一类的效率问题. 举一个 Code style的例子 (实在无语了有没有!)
代码里是这么写的:
Intent intent = getIntent();
if (null != intent) {
goToMainPageFlag = intent.getBooleanExtra(KEY_GO_TO_MAIN_PAGE_FLAG, false);
} else {
goToMainPageFlag = false;
}
Inspect Code提示:
就是说, Android Studio的Inspect Code告诉你, 你的代码一点都不优雅... 应该改成酱:
Intent intent = getIntent();
goToMainPageFlag = (null != intent && intent.getBooleanExtra(KEY_GO_TO_MAIN_PAGE_FLAG, false));
结论: 把六行的代码改成两行, 确实是一个很好的Code Style实践有没有! 是的, Android Studio的Inspect Code功能我也是第一次用, 里面东西实在太多了, 大大小小事无巨细的, 没事儿多看看长长见识也是极好的... 虽然有时候你可能不能在短时间内一下子把所有选项优化完, 不过多看才会有优化的意识, 在之后的Code实践里就会逐渐的靠近最佳实践.
gradle plug 0.14.0, runProguard 更名为minifyEnabled
去除无用资源
gradle plug 0.14.0, runProguard 更名为minifyEnabled
去除无用资源
Android Gradle plug从0.14.0开始，支持自动去除没有使用的资源。
不过，这个开关是默认关闭的。可以在build type使用 shrinkResources true 开启。 要注意，这个功能的使用依赖于code shrinking， 所以minifyEnabled也必须打开。
Support for automatic removal of unused resources
Off by default for now, enable by setting shrinkResources to true in your release build types. Requires minifyEnabled as well.
具体配置如下
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
}
}
}
效果
以我正在开发的一个app为例
-
使用前2.02MB
-
使用后1.90MB
效果明显！
http://www.tuicool.com/articles/nI3uEfV
http://www.v2ex.com/t/145676
1768
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
