前段时间老大给了我一个任务，主要是帮我们开发直播应用，让Android安装包瘦身。安装包从18MB减少到18MB减少到12.5MB用了大约一周的时间。本来可以优化到10MB以下，但是由于其他原因，现阶段只限制在12.5MB。这里把优化的思路和使用的工具记录下来，方便以后回顾，有需要的童鞋也可以参考。瘦身的目的从目的导向来看，我们不会无缘无故去做某事，那么我们瘦身的目的是什么？答案是：提高下载转化率。下载转化率是多少？举个例子：你的app大小是18MB，有100个潜在用户想下载试用。结果20个用户觉得安装包太大立马离开，还有20个用户在等待。如果在下载过程中取消下载，则只有60个用户真正下载并安装了该应用，因此该应用的下载转化率为60/100=60%。简单概括就是：安装包越小，用户等待下载的时间越短，在手机存储配置小的设备上体验越好，应用下载的转化率越高。记得之前在腾讯大讲堂听微信大牛说微信第一版只有400KB左右，瞬间膜拜。安装包的组成要对安装包进行瘦身，首先需要了解安装包的组成和结构。下面简单介绍一下各个组件及其作用：其中，安装包中占比较大的部分包括：dex文件、res文件文件夹、assets文件夹、lib文件夹和resource.arsc文件。所以接下来的瘦身优化就是把这些文件变小，从而达到瘦身的目的。从AndroidStudio2.2.3开始，增加了浏览APK结构的功能。我们可以直接将安装包拖入IDE中，然后我们就可以直接浏览它的组成和对应的大小，这样我们就可以非常方便的对比分析每一步的优化结果。.资源细化了解了APK的组成之后，我们就可以开始优化工作了，因为资源文件在APK中所占的比例最高，所以优先从资源细化入手。尽量只保存一个图片资源。开发目录下会有drawable或mipmap目录，以适配不同dpi的屏幕。以下是适应不同命名目录的dpi范围。目前市场上的大部分型号都在xxhdpi范围内。因此，可以考虑在xxhdpi目录下只保留一张图片资源。具体资源在哪个目录下，保留多少资源，要根据应用本身的实际模型分布来决定。使用DrawableXML,Color,.9PNG代替PNG在某些情况下，我们可以考虑使用DrawableXML代替PNG，比如：一个渐变背景图，几行XML就可以画出来，为什么要用几十到几百KPNG文件；使用Color代替PNG，如：纯色背景；从性能上看，相对于使用图片资源，需要先生成Bitmap，再传给底层进行GPU渲染。使用DrawableXML和Color效率更高，直接将Shape信息传递给底层由GPU渲染，CPU和内存占用会更少；用.9PNG代替PNG，场景很多，就不举例了；用JPG代替PNG，用JPG代替PNG，因为JPG没有Alpha通道，所以文件体积更小，对于不需要透明度的图片可以考虑。小心使用WebP而不是PNG。由于WebP效果很好，同样的效果下，WebP文件比PNG文件小很多。所以网上很多人说用WebP代替PNG。我不同意这一点。原因如下：WebP至少在Android端只支持4.0。为了兼容4.0以下的环境，需要引入额外的兼容库，增加了安装包的体积；AndroidStudio不支持预览WebP图片，无法预览引用WebP的布局文件；BAT应用及同类竞品解压后，基本没有发现资源文件中使用了WebP；有损编码格式的音频文件替换来自以下官方文档https://developer.android的无损音频文件。com/guide/topics/media/media-formats.html可以看到Android平台支持的音视频格式。下面列出常用的有损和无损格式（不要以为有损编码就是音质差）：无损格式：WAV、PCM、ALS、ALAC、TAK、FLAC、APE、WavPack(WV)有损格式：MP3、实际开发中需要用到AAC、WMA、OggVorbis音频文件，尽量使用MP3、Ogg这种有损格式，尽量不要使用WAV、PCM等Lossless音频。去除无用资源这里去除无用资源文件主要分为两部分：解包不用的资源和删除不用的资源。为了不打包不用的资源，在项目的build.gradle中配置shrinkResourcestrue。删除不用的资源，通过AndroidStudio右键项目=>Analyze=>RunInspectionbyName=>输入UnusedResurroces可以看到所有不用的资源文件。建议定期清理这些无用文件。一方面，您可以减小项目的大小。另一方面，资源文件过多会导致打包后的resources.arsc文件越来越大。公司有一个项目，resources.arsc文件达到了2-3MB，有点意外。结合以上几点，我们就可以有效的减小我们安装包中的res文件夹、assets文件夹和resource.arsc文件的体积，从而达到瘦身的目的。工具上一章提到了优化的思想。本章整理了优化过程中使用的工具。TinyPNG：https://tinypng.com/，支持压缩PNG/JPEG文件，效果不错。pngquant：https://pngquant.org/，支持PNG压缩，有时TinyPNG处理后的图片会多一点噪点，可以考虑使用pngquant来处理。ImageOptim：https://imageoptim.com/mac，支持压缩PNG/JPEG/GIF，效果显着，可以看这里https://www.diycode.cc/topics/496，可惜只支持Mac，Windows派对正在经历艰难时期。mozjpeg：https://imageoptim.com/mozjpeg，用于PNG转JPEG，JPEG压缩，效果很好。AdobeAuditionCC：http://www.adobe.com/cn/products/audition.html，Adobe出品，支持改变音频采样率、分辨率和通道数，从而达到切割音频（采样码率、分辨率和声道数是音频文件格式的关键参数，决定了音频文件的大小）。以上就是我在优化过程中用到的好工具。如果大家有更好的推荐，欢迎补充。另外，在压缩图片的时候，不要贪图方便，直接一次性压缩整个资源目录下的图片。很多时候，做这个项目的人可能已经压缩了一些资源文件，这很容易导致二次压缩，造成一些图像失真。在这里，我的建议是，到应用程序的资源目录下，将资源文件从大到小排序，定一个标准。如果超过20KB的图片需要压缩，复制这些合格的图片进行压缩。处理后保证没有失真后再替换相应的图片资源再进行优化。音频文件的处理是相同的。Nativelibrary瘦身Nativelibrary瘦身主要是减少对CPU架构的支持。配置非常简单。使用build.gradle中的abiFilters配置需要的CPU架构，将不需要兼容的so文件从项目中移除。.根据我们用户的机型分布，最终只保留了对armeabi-v7a的支持。注意，这个需要根据自己产品的实际情况来决定。由于之前对CPU架构分布不是很了解，在此感谢微信张绍文、沪江许易生、虎牙郑晓斌给我的科普贴。综上所述，我们的安装包中lib文件夹的大小可以有效的减小，从而达到瘦身的目的。还有一种方法是通过在build.gradle中配置include，为每个CPU架构生成单独的安装包。虽然看起来不错，但是国内很多应用市场在上架的时候并不支持这种每CPU一个包的配置。所以这个方法比较鸡肋，不推荐去做。如果应用只有GooglePlay，确实比配置abiFilters要好很多。这里可以做的代码瘦身的事情有很多，主要有以下几点：去除过时函数的代码。反正有VCS，删除的代码随时可以找回；知道自己又写了一套，只能通过codereview来解决；去掉功能重叠的框架，比如：项目中有几套网络访问框架Volley、AsyncHttpClient、Retrofit等，只能通过codereview来解决；去掉无用的依赖或者jar包；减少对Support兼容包的依赖，Support-V4包很大，项目引入无疑会增加dex文件的体积，Google已经意识到这个问题，所以Support-V7一开始就做了拆分，并且开始拆分Support-V4，虽然目前效果不明显，但还是值得期待的，尤其是你发现少了Support-V4包之后，可能会从2dex变成1dex就可以了;插件，一种懒加载的思路，让用户先安装宿主包，对一些功能模块做插件，然后在特定的时间下载安装；综上所述，我们可以有效的简化我们安装包中dex文件的大小，从而达到瘦身的目的。结论在整个优化过程中，我将项目从18MB优化到12.5MB。以上部分优化点受其他原因影响，只能暂时放弃，可以考虑列入下一次优化计划。套路大概是这样的。实践中，请根据自己的项目来决定，优先优化性价比较高的部分（性价比=最佳尺寸/所需时间）。
