Android笔记之初识性能优化（纯笔记）

合抱之木，生于毫末；九层之台，起于累土；千里之行，始于足下。——老子

小弟初学安卓，该文算是小弟的学习过程，课后笔记与一些自己的思考，希望在自己的自学路上留下印记，也许有一些自己想的不对的地方，希望各位前辈斧正。

一、Android的垃圾回收机制

JAVA本身有垃圾回收机制，这方便了我们，不需要我们手动去管理资源。以下知识来自网络课程：
　　Android的虚拟机在运行程序时会将内存分为三个区域（实际我查了查资料发现其实JVM也是这样做的，求哪位大神能告知一下Android的GC比起JVM的GC有哪些不一样）：Young Generation,Old Generation,Permanent Generation，直译是新生代、老生代，持久代。

Young Generation内又分三个区域，eden区（不知道怎么翻译）以及两个survivor区（幸存者区？），大多数新建的对象都会放在eden区，而当eden区对象填满时，就会进行Minor GC（属于新生代的GC），这个GC发生频繁且速度快。两个survivor区用来存放在Minor GC中存活下来的对象，至于为什么是两个呢，因为两个survivor区可以保证任意时刻有一个survivor区是空的，当eden区的对象要移入survivor区时，第一次先移入其中一个区，而之后每次则会将eden移入的存活的对象与上一次使用的survivor区里的存活的对象一起移入另一个空的survivor区，多次Minor GC后，还存活下来的survivor区中的对象就会移入Old Generation（两个survivor区还可防止产生碎片，因为这样对象的保存就是连续的）。

Old Generation则使用来存放长期存活的对象（基本来自经过多次Minor GC后从新生代survivor区转来的对象），当满了的时候会执行Major GC,Major GC速度比Minor GC慢，慢10倍左右（来自网络资料，Minor GC发生在新生代，Major GC发生在老生代，更多区别可以查一查网络资料）。

Permanent Generation存放方法区，方法区中有要加载的类信息、静态变量、final类型的常量、属性和方法信息。

---

二、内存优化

常见内存问题：

• 内存抖动:时间内创建了大量对象又马上释放造成。瞬间产生的大量的对象会很快促发GC又将对象回收，即使每次分配的对象占用了很少的内存，但是叠加在一起会增加堆的压力，促发更多GC。这样会影响到帧率，令人感受到卡顿。

• 内存泄漏：即使JVM能替我们进行垃圾回收，但仍然可能会发生内存没被回收的情况，这就造成了内存泄漏的问题，使内存无意义的被占用。

所以，为了使我们的应用不仅功能强还要高性能，我们必须进行内存优化，不然如果应用无故占用过多内存，会对配置不高的手机不友好，用户会选择卸载应用。为了找出内存问题，我们有许多的工具可以使用，方便我们定位问题代码所在。

1.Memory Monitor

Memory Monitor

　　Android Studio自带，随时可以吃查看，这个工具可以很直观的让我们发现内存抖动问题，在右端可以看到两数据，两数据之和为APP被分配到的内存大小，Free表示空闲内存，Allocated表示已使用的内存。

内存抖动

　　这个工具能让我们发现应用存在内存抖动问题，但是无法让我们精准找到问题代码位置，这就需要我们下面介绍的工具。（除了内存抖动，还能通过它进行更多分析查找问题）

2.Allocation Tracker

启动位置

　　我们在点击后，对应用操作，完成后再点击一次，就能生成一次报表，我们能看到代码中分配的对象的类型，大小，时间，线程，堆栈等信息。比如我们点击后，进行某操作造成了内存抖动，然后再点击结束，就能从报表中查看是什么对象大量生成造成的这次内存抖动。

报告

3.Heap Viewer

Heap Viewer

　　Heap Viewer点击后会进行一次内存快照，重要的是他会在每一次GC后收集一次信息，所以我们可以在点击它左边那个小货车图标来手动GC，再点击DUmp JAVA Heap，这时如果发现我们希望被GC的对象依然存在，则可证明我们的应用发生了内存泄漏。

报告

4.LeakCanary

LeakCanary

　　这个工具真是神奇啊，只需要我们简单配置后，在应用操作中只要发生了内存泄漏它就会通过通知栏来告诉我们，我们便可查看，如上图的画面，最上层就是造成内存泄漏的罪魁祸首，而往下逐层就是它的外层，真是好贴心啊。具体使用可以去github中查看（操作十分简单）—— LeakCanary的GITHUB。

还有一些检测内存的工具小弟就不一一介绍了，最后记录一下从各个地方收集来的内存优化方法：

• 尽量使用静态内部类，因为静态内部类不会持有外部内的引用，可以被正常回收。
• 适当弱引用和软引用（比如使用handler的时候啦）
• 在生命周期结束后释放资源
• 使用Android特有的轻量数据结构（用SpareArray代替HashMap）
• 避免在onDraw方法中创建对象（因为onDraw方法可能会被频繁调用）
• 使用对象池
• Bitmap复用
• ......

还有可能会造成内存泄漏的原因：

• 单例模式造成的内存泄漏（单例对象持有了Activity的context，导致Activity不能被回收）
• 非静态内部类的静态实例造成的内存泄漏（非静态内部类持有Activity引用）
• Handler的内部类造成的内存泄漏（handler持有Activity引用，若Activity结束而消息还未处理完，将导致Activity不能被回收，应当使用弱引用来处理）

---

三、视图优化

1.渲染

Android系统中有一个VSYNC信号，系统通过发送这个信号触发UI的渲染、重绘，间隔时间为16ms，为了使画面不卡顿，我们就应将渲染时间控制在16ms以内。

Android手机的开发者选项里就提供了我们工具来观察渲染时间，就是GPU呈现模式分析（Profile GPU Rendering），这里我们选择在屏幕上显示为条形图。

选择显示条形图

然后就是这幅光景，那条绿色的横线就代表着16ms，我们的目标就是让下面的这个条形图不要高出这条绿线（我的破手机分分钟就能高出这条线！）。这里可以看到下面的条形图有三种颜色，橙、红，篮。

蓝色代表了创建更新Display List的时间，红色表示渲染时间，橙色表示CPU等待处理的时间。如果蓝色过长，就说明绘制时间过长；红色过长，可能就是onDraw方法中做了很复杂的操作或者是视图重绘了（比如旋转屏幕，很容易看出卡顿吧），橙色过长可能就是CPU给GPU的任务过多导致。

2.过度绘制（OverDraw）

通俗点说就是在某片区域里多次绘制视图，比如Activity本身有个背景色，我们又在布局文件上再加了个背景，这样就过度绘制了一次，查看这个我们依然是在开发者选项中使用工具——Show GPU OverDraw

选哪个不用我说了吧

我现在先打开QQ，进入下图的界面，可以看到，一些区域被覆盖不同的透明色，总共有四种颜色，蓝色(1x过度绘制)、绿色(2x过度绘制)、粉红(3x过度绘制)、红色(4x过度绘制，因为叠在一起可能看不清楚，那些“朋友圈”、“扫一扫”等这些在ListView上的控件都是红色区域），我们的目标就是尽量让蓝色区域多一点（我本来以为蓝色就是只有1层，结果发现还是有白色的，所以蓝色就是在底层上画了一层），不过有些过度绘制也没办法避免，你看下面的微信不是也有这么多红的嘛。因为你加个TextView、ImageView什么的就算你过度绘制了一次，但你又不可能不用，对吧。

微信

为了使蓝色区域多一点，红色少一点，我们可以降低View层级，去除不必要的背景等等，这样也减少了渲染的时间。

---

还有一个电量优化，这个因为小弟操作较少，经验不足，还是推荐各位大佬看网络上大神们的博文。