合抱之木，生于毫末；九层之台，起于累土；千里之行，始于足下。——老子
小弟初学安卓，该文算是小弟的学习过程，课后笔记与一些自己的思考，希望在自己的自学路上留下印记，也许有一些自己想的不对的地方，希望各位前辈斧正。
一、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
Android Studio自带，随时可以吃查看，这个工具可以很直观的让我们发现内存抖动问题，在右端可以看到两数据，两数据之和为APP被分配到的内存大小，Free表示空闲内存，Allocated表示已使用的内存。
这个工具能让我们发现应用存在内存抖动问题，但是无法让我们精准找到问题代码位置，这就需要我们下面介绍的工具。（除了内存抖动，还能通过它进行更多分析查找问题）
2.Allocation Tracker
我们在点击后，对应用操作，完成后再点击一次，就能生成一次报表，我们能看到代码中分配的对象的类型，大小，时间，线程，堆栈等信息。比如我们点击后，进行某操作造成了内存抖动，然后再点击结束，就能从报表中查看是什么对象大量生成造成的这次内存抖动。
3.Heap Viewer
Heap Viewer点击后会进行一次内存快照，重要的是他会在每一次GC后收集一次信息，所以我们可以在点击它左边那个小货车图标来手动GC，再点击DUmp JAVA Heap，这时如果发现我们希望被GC的对象依然存在，则可证明我们的应用发生了内存泄漏。
4.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层级，去除不必要的背景等等，这样也减少了渲染的时间。
还有一个电量优化，这个因为小弟操作较少，经验不足，还是推荐各位大佬看网络上大神们的博文。
