Android最终瘦包与优化具体步骤——我的方式

前言

Android优化方式侃侃而谈者甚多，却可能并没有做过一次，今记录吾之方式，待朕回忆，IDE基于AS2.3.3。

---

工具

AndroidStudio自带的Analyze，就在IDE上面工具栏中。

---

方式

• 对包大小动手
• 代码优化、布局优化、内存优化

1.对包大小动手

使用AndroidStudio Build下的分析工具，先分析出apk哪部分占用最大，做出对应的处理，工具显示如下图：

image.png

但是这个只能分析出包大小处在哪里，我们能做的只是缩小包的体积，分析内容大致如下图：

image.png

从这里可以看出我的apk文件大就大在assets和第三方so包，我的包大小约为60M，但是这两个就占了我80%大小，约为44.1M，这个巨惊人，我也惊呆了，不可放任其自由发展：

• ProGuard
  这个东西能够对Java 库类中的代码进行压缩（Shrink）,优化（Optimize）,混淆（Obfuscate）,预检（Preveirfy）。
  　　1. 压缩（Shrink）:在压缩处理这一步中，用于检测和删除没有使用的类，字段，方法和属性。
  　　2. 优化（Optimize）:在优化处理这一步中，对字节码进行优化，并且移除无用指令。
  　　3. 预检（Preveirfy）:在预检这一步中，主要是在Java平台上对处理后的代码进行预检。
  　　4. 混淆（Obfuscate）:在混淆处理这一步中，使用a,b,c等无意义的名称，对类，字段和方法进行重命名。
  参考博客 》》http://blog.csdn.net/shanshan_blog/article/details/53169315
  从以上可以看出混淆这一步可以说是很重要的，虽然我叫它混淆打包，但是它可不只做了混淆这一件事。很遗憾我的当前工程出现了不少问题，我强行在编译时盖住了报错，在这里用不了混淆这块，故此没探究。
• 缩减图片大小
  其实Android是支持webp格式的图片的
  0.WebP 的优势体现在它具有更优的图像数据压缩算法，能带来更小的图片体积，而且拥有肉眼识别无差异的图像质量；同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性，在 JPEG 和 PNG 上的转化效果都相当优秀、稳定和统一。操作如下图
  
  图片.png
  
  右击给他转换下即可
  我这里使用的方式是：
  1.将图片放在mimap文件夹中，这是纹理图文件夹，据说Mipmap纹理技术是目前解决纹理分辨率与视点距离关系的最有效途径,它会先将图片压缩成很多逐渐缩小的图片。当然关于drawable与mipmap文件夹的争议是很多的，个人偏向于mipmap文件夹存放图片。
  下面为摘自https://stackoverflow.com/questions/23935810/mipmap-drawables-for-icons%E3%80%82的一段话。

不同设备上的不同主屏幕启动器应用程序显示各种分辨率的应用程序启动器图标。当应用程序资源优化技术为未使用的屏幕密度移除资源时，启动器图标可能会显得模糊，因为启动器应用程序必须升级显示器的较低分辨率图标。为了避免这些显示问题，应用程序应该使用mipmap/资源文件夹作为启动器图标。Android系统保留这些资源，无论密度剥离，并确保发射器应用程序可以挑选最佳分辨率的图标进行显示。*

2.我用众所周知的 tinypng
对文件夹内图片进行压缩，实践证明，这真的是款神器，这款神器一次性可压缩20张图片，压缩完我习惯是刷新页面，不然无法再次压缩，它会直接显示压缩失败。

说明：优异关系为：有损webP>tinypng>无损webP,但是有损webP在一些灰度图中进一步模糊内容,譬如加载图片时用的placeholder灰色文字图片，故我一直使用的为tinypng.人工压缩后关闭编译时配置Android默认的图片压缩，它不咋地 传送门。

android {
    …
    buildTypes {
        release {
            crunchPngs false
        }
    }
}

• so文件夹减少
  通过大量百度，知识汇集，其中的知识点涉及cpu abi，最后得出结论只保留 armeabi-v7a 文件夹。 额。。目前还没有发生什么不兼容问题，

至此App大小减小的比较喜人，贡献最大的其实还是so文件夹的减小，现在大小直接看下图，剔除了一半多，很高兴。

图片.png

2. 代码优化

1). Analyze → Inspect Code
我们在写代码过程中总有自己的小习惯，但是这个习惯谷歌爸爸是看不起的，他要求绝对的规范和美观，所以他给了代码审查也定义了这个规则，我们只要使用 Analyze → Inspect Code

image.png

从这里我们看出里面都是报错和警告，在这里根据提醒修改你能使绝大多数代码规范，但是提示不是万能的，不能都改，仁者见仁吧，查看过程中还发现了一个有趣的事儿，如下图：

image.png

这里它嫌弃我同事写的script代码放的方式,直接将其判定为错误，而且还给出明确提示，代码结构是这样的：

2). Analyze → Code Cleanup
这个直接能对你的一些代码进行写法调优，但是我使用了下，没发现什么有效，不建议使用。

2. 查看ViewTree（Hierarchy Viewer生成树图）.

布局树图，这个都是大家所知道，什么减少嵌套，多用ViewStub、include标签复用，多用Merge标签合并之类的，其实大多数时候我们都不会理会这个东西，但是真的会有层级过多而导致崩溃问题，所以我们在做优化的时候呢，虽然知道自己改动的几率不大，但是还是要生成树图图片然后查看一番，翻翻有没有确实很过分的布局，有的话我们必须改掉它。
具体做法：

image.png

按照上图打开监视器。你没有看错，这个监视器也可以查看data/data文件夹下的数据，我们知道查看data/data文件夹一般都是越狱手机或者虚拟机，这个也不例外，要想获取Tree图必须使用虚拟机，下图是我首页Tree图的大概情况。

image.png

页面那么多，怎么可能一个个分析，我一般一个个点击Activity页面，观察这上面的树层级，感觉有点多的就点击看看结构再对比实际视图修改下，原则就是不过分怎么都好说。

3.内存优化

内存优化真的是一个老大难的问题，我百度了很多博客，都是侃侃而谈，有些有步骤，可是最后结论大体都可归纳为 经验之谈，有很多有借鉴意义，可是不是我想要的，我这里也暂时没什么好的干货，仅做此次研究的记载：
这个作为最大的参考文章：http://blog.csdn.net/qq_23191031/article/details/63685756
开局先看App

图片.png

就是这种炫酷饼图，我没用到它

图片.png

AS上各种显示，反正我没搞懂，我就记下我能弄的步骤：
1.将dump下来的堆快照生成标准hprof文件以能够让MAT工具正常打开
2.Activity A->ActivityB

image.png

至于MAT比较这里不再赘述，记住去除虚引用之类的，方可见真文章,
最简单的就是A->B->A->B,收集快照，然后打开做些操作去除干扰，截图，反复操作几次,对比截图内容，这个东西太耗时间了。

• 拓展：

Android代码内存优化建议-Android资源篇
http://www.androidperformance.com/2015/07/20/Android-Performance-Memory-AndroidResource.html
Android代码内存优化建议-Android官方篇
http://www.androidperformance.com/2015/07/20/Android-Performance-Memory-Google.html#7-%E7%9F%A5%E6%99%93%E5%86%85%E5%AD%98%E7%9A%84%E5%BC%80%E6%94%AF%E6%83%85%E5%86%B5
Android代码内存优化建议-OnTrimMemory优化
http://www.androidperformance.com/2015/07/20/Android-Performance-Memory-onTrimMemory.html
Android代码内存优化建议-Java官方篇
http://www.androidperformance.com/2015/07/20/Android-Performance-Memory-Java.html

待完善...