干Android开发也有3年多了，对性能优化方面有自己的一点心得，特此总计一下。

我把性能优化分成以下几类

• 布局优化
• 绘制优化
• 内存优化
• 启动优化(目前理解的不深，没有总结)

一、布局优化 （第一原则减少嵌套）

image.png

如果都是我们的项目页面一路飘红，就该考虑优化布局减少嵌套了！！！

布局优化 可以采用以下几种方式来实现

1、相同层级能实现效果的情况下，尽量使用系统提供的轻量级ViewGroup，如FrameLayout / LinearLayout而不要使用RelativeLayout，因为RelativeLayout 会测量2次，而FrameLayout / LinearLayout只需一次。但是当LinearLayout使用weight属性时，LinearLayout也需要两次measure 。

2、当使用FrameLayout / LinearLayout 必须要嵌套才能实现，这时就需要考虑采用RelativeLayout实现（总之就是一层的情况下使用 FrameLayout / LinearLayout，涉及到嵌套在考虑RelativeLayout）。

3、更复杂的布局 可是使用ConstraintLayout（约束布局）来实现，他本身就是谷歌为了解决嵌套问题出的布局。

4、include标签 提高布局的复用性，大大方便我们的开发，有人说这个没有减少布局的嵌套吧，include确实没有，但是include和merge联手搭配，效果那是杠杠滴。

5、merge标签 的布局取决于父控件是哪个布局，使用merge相当于减少了自身的一层布局，直接采用父include的布局，当然直接在父布局里面使用意义不大，所以会和include配合使用，既增加了布局的复用性，用减少了一层布局嵌套。

6、ViewStub标签 布局懒加载，当初次渲染布局文件时, ViewStub 控件虽然也占据内存, 但是相比于其他控件, 它所占内存很小. 它主要是作为一个“占位符”, 放置于 View Tree中, 且它本身是不可见的.。

二、绘制优化

首先要了解Android的绘制机制 （这里只是做简单总结，更详细的可以上网自己搜）

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，但是渲染未必成功，如果成功了那么代表一切顺利，但是失败了可能就要延误时间，或者直接跳过去，给人视觉上的表现，就是要么卡了一会，要么跳帧。

View的绘制频率保证60fps是最佳的，这就要求每帧绘制时间不超过16ms(16ms = 1000/60)，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法中的复杂度总是切实有效的。

了解原理后，就容易能找出相应的对策了，根本做法是 减轻自定义View 中onDraw() 的负担。

1、 onDraw方法中不要做耗时的任务，也不做过多的循环操作，特别是嵌套循环，虽然每次循环耗时很小，但是大量的循环势必霸占CPU的时间片，从而造成View的绘制过程不流畅。

2、 除了循环之外，onDraw()中不要创建新的局部对象，因为onDraw()方法一般都会频繁大量调用，就意味着会产生大量的零时对象，不进占用过的内存，而且会导致系统更加频繁的GC，大大降低程序的执行速度和效率。

3、 使用clipRect() 、 quickReject()方法裁剪不显示的区域，防止过度绘制。

三、内存优化 （主要分成三类）

• 内存抖动
• 内存泄漏
• 内存溢出

3.1 内存抖动

发生的原因： 短时间内产生大量垃圾对象，频繁触发GC卡主线程。

造成内存抖动的场景

1、自定义View的onDraw()方法会被频繁调用，所以在这里面不应该频繁的创建对象。

2、当需要大量使用Bitmap的时候，试着把它们缓存在数组中实现复用。

3、对于能够复用的对象，同理可以使用对象池将它们缓存起来。

4、 创建线程不要直接使用new Thread() 的方式，应使用线程池来创建线程。

3.2 内存泄漏

内存泄漏发生的原因： 长生命周期的对象持有了短生命周期对象的引用，导致短生命周期对象不在使用，内存也不会被释放。

造成内存泄漏的场景

1、 内部类使用不当造成的内存泄漏 如直接在Activity中通过匿名内部类的方式使用Handle或Thread。以Handler为例，当Handler发送的Message还没有得到处理，这时关闭Activity，Activity就会发生内存泄漏。

造成的原因是: Handler持有了Activity -> Message持有了Handler -> MessageQueue持有了Message。这样的持有关系导致Activity虽然已经关闭不在使用，但是内存依然不会释放，造成内存泄漏。
解决办法有两种 1. Handler使用静态内部类，通过弱引用的方式持有Activity 2. 在Activity的onDestroy方法调用 handler.removeCallbacksAndMessages(null); 来清空消息。

2、 单例模式使用不当造成的内存泄漏 当单例模式需要传入上下文时，不要直接传入Activity / Service中的上下文对象。单例模式创建后它的生命周期就跟应用生命周期一样长，如果单例持有了Activity / Service， 会导致Activity / Service关闭了 内存依然不会释放。

3、资源未释放造成的内存泄漏 Cursor、I/O流 使用完后未及时关闭。

4、广播，服务为解绑造成的内存泄漏 BroadCastReceiver、Service 绑定广播和服务，一定要记得在不需要的时候给解绑 。

5、使用定时器不当造成的内存泄漏 如在Activity中使用Timer，在Activity关闭的时候没有取消Timer。

6、RxJava使用不当造成的内存泄漏 现在好多项目都喜欢用RxJava，但是如果RxJava在页面关闭时没有取消订阅，可能会造成内存泄漏。

7、属性动画使用不当造成的内存泄漏 如果动画设置了无限播放，在Activity的onDestroy方法中没有取消动画，在自定义View的onDetachedFromWindow中没有取消动画 ，肯定会内存泄漏。

8、静态集合添加对象，在使用完之后未及时释放，造成的内存泄漏

平时开发注意以上几点造成内存泄漏的原因，一般就不会内存泄漏。
如果想要定位内存泄漏的地方有两个方法
1、可以使用AndroidStudio提供的Profiler工具，具体使用方式网上有很多教程
2、使用三方库 LeakCanary

3.3 内存溢出

发生原因： 系统为每一个应用程序分配了不同的内存上限，如果超过这个上限被视为内存泄露，从而被kill掉。

发生内存溢出场景：

1、内存泄漏越来越多，导致内存越来越少，最终内存不足以支持创建新的对象，导致内存溢出

2、加载对象过大 ： 如Bitmap加载没有做优化直接加载原始图片的大小到内存，如果图片超出内存限制，就会内存溢出导致应用崩溃。
Bitmap加载到内存中大小计算分成两种，
1.直接加载网络图片（图片的 宽 * 高 * 像素字节数）。
2.加载drawable中的文件计算公式就比较复杂，需要经过系统转换宽高
新图的高度 = 原图高度 * (设备的 dpi / 目录对应的 dpi )
新图的宽度 = 原图宽度 * (设备的 dpi / 目录对应的 dpi )
得到新的宽高后拿新的宽 *新的高 * 像素字节数就是最终占用内存的大小 。
可以看出图片最终加载到内存，有四个要素决定，所以我们加载网络图片的时候可以先通过BitmapFactory.Options这个Api先不把图片加载到内存中只是得到图片的原始宽高，在跟要展示图片的ImageView的宽高做一个缩放比来减小图片的宽高，像素字节数也可修改（不建议修改）。加载drawable文件中的图片，需要注意存放 哪个分辨率下的drawable。