文集目录
ps：喜欢的点赞哦 android性能跟踪分析工具系列 - 目录
万事初始，理论先行，理论都不知道，给你上面的那些工具你又能怎样呢，再说这些工具的目的也是为了发现定位问题，至于找到问题如何解决，什么算是问题，哪里可以优化这些没有理论是不行的
这里我就不班门弄斧了，已经有很多优秀的文章了，这里贴出来：
我在这里简单总结一下：
1. java内存区域如何划分？
目前有2种说法：
- JVM角度：堆（Heap），栈（Stacks）方法区（MethodArea），运行时常量池（RuntimeConstant Pool），本地方法栈（NativeMethod Stacks），PC Register(PC寄存器)。
- 进程角度：堆（Heap），栈（Stacks），数据段（data segment），代码段（code segment）。
对于我们来说分清堆内存和栈内存就行了，我们平时创建的对象不管是在哪创建的，不管是类还是方法里都是存在堆内存中的。堆内存不连续，垃圾多了效率就低了。栈内存，先入后出，和 activity 栈一样，效率高，另外栈内存使用的是 cpu 中的内存部分，所以计算速度非常快，这里存储的都是方法的数据，用过既删。
2. java中的引用有哪些？
强引用(StrongReference)：
GC 不会回收强引用的内存片段，当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。软引用(SoftReference)：
如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。弱引用(WeakReference)：
在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。虚引用(PhantomReference)：
如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。
3. 什么是内存泄露，内存泄露的场景有哪些？
什么是内存泄露：
本该被回收的资源，因为被别的对象意外持有，导致不能回收。-
内存泄露的场景：
- 非静态内部类的静态对象
非静态内部类的对象 会持有外部类的引用，那么这个静态对象不销毁，外部类就一直有人引用而不能被销毁。因为静态对象的生命周期和 app 一样长啊。 - 静态对象持有大数据对象
像 application 的静态对象，他要是持有一个页面，那么这个页面在关闭后，该页面的对象也不会被销毁。 - 注册/注销
比如 给一个页面用 EventBus 注册事件，在页面关闭时没有注销。这个问题本质就是上一个的情况，事件总线框架都会维护一个全局的静态事例，你把一个页面注册到这个静态实例里，你不会主动注销，那么页面就会一直被这个静态实例持有，不能销毁回收。 - 资源没关闭
资源性对象如Cursor、Stream、Socket，Bitmap，应该在使用后及时关闭。未在finally中关闭，会导致异常情况下资源对象未被释放的隐患。 - handle
Handler通过发送Message与主线程交互，Message发出之后是存储在MessageQueue中的，有些Message也不是马上就被处理的。本质就是注册/注销这类问题。
- 非静态内部类的静态对象
4. java垃圾回收(Garbage Collector) 机制？
java垃圾回收器简称 GC ，据说 GC 有多种算法，根据情况不同来回切换，最常用，最广被人知的是对象引用的索引算法。java 有表会维护对象引用关系，从表的根节点GC ROOT开始找，没有被上级引用到的对象都被视为无用的。
5. android 渲染原理
这里简单的说一下我们需要知道的：
- android 系统是16ms 刷新一次界面，1秒刷新60次，界面一秒刷新次数也叫帧数，也就是说 android 系统的界面刷新是60帧/秒
- 16ms 要是不能完成一帧的计算绘制，那么这一帧就不会显示在界面上，那么对于用户来说在32ms 内看到的是相同的内容，这也就是造成界面卡顿的最浅显原因
- 界面刷新一次的过程：
- cpu测量，布局界面上变动的视图对象，然后绘制这些 view(onDraw方法) 生成界面一帧数据
- 然后 cpu 把这计算出的这一帧数据传递给 gpu，这一帧数据也叫纹理，具体的去看 OpenGL的内容
- gpu 根据cpu 传递过来的纹理数据，去具体的绘制出2D 图形来
- cpu 等待 pgu 通知绘制完成，cpu 才可以去干别的事，要不 cpu 会一直等着。。。这才算是完成了一帧的渲染
- ps：可能不太准确，但是大概其就是这样了，这也是我看了好多资料才基本整理出来的
6. 界面优化
-
过度绘制解决方案：
- 去掉 window 的默认背景
当我们使用了Android自带的一些主题时，window会被默认添加一个纯色的背景，这个背景是被DecorView持有的。当我们的自定义布局时又添加了一张背景图或者设置背景色，那么DecorView的background此时对我们来说是无用的，但是它会产生一次Overdraw，带来绘制性能损耗。去掉window的背景可以在onCreate()中setContentView()之后调用getWindow().setBackgroundDrawable(null);或者在theme中添加android:windowbackground="null"； - 去掉其他不必要的背景
有时候为了方便会先给Layout设置一个整体的背景，再给子View设置背景，这里也会造成重叠，如果子View宽度mach_parent，可以看到完全覆盖了Layout的一部分，这里就可以通过分别设置背景来减少重绘。再比如如果采用的是selector的背景，将normal状态的color设置为“@android:color/transparent”,也同样可以解决问题。这里只简单举两个例子，我们在开发过程中的一些习惯性思维定式会带来不经意的Overdraw，所以开发过程中我们为某个View或者ViewGroup设置背景的时候，先思考下是否真的有必要，或者思考下这个背景能不能分段设置在子View上，而不是图方便直接设置在根View上。 - clipRect的使用
我们可以通过canvas.clipRect()来 帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠 组件的自定义View来控制显示的区域。同时clipRect方法还可以帮助节约CPU与GPU资源，在clipRect区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。
- 去掉 window 的默认背景
-
减少视图层级方案：
- ViewStub
可以让部分 view 在我们需要的时候再去初始化加载显示，而不是页面一启动就去初始化加载，虽然实际上我们不会让这部分界面去显示。比如各种状态页面和适合使用 viewstub 来展示 - Merge标签
MMerge标签可以干掉一个view层级。Merge的作用很明显，但是也有一些使用条件的限制。有两种情况下我们可以使用Merge标签来做容器控件。第一种子视图不需要指定任何针对父视图的布局属性，就是说父容器仅仅是个容器，子视图只需要直接添加到父视图上用于显示就行。另外一种是假如需要在LinearLayout里面嵌入一个布局（或者视图），而恰恰这个布局（或者视图）的根节点也是LinearLayout，这样就多了一层没有用的嵌套，无疑这样只会拖慢程序速度。而这个时候如果我们使用merge根标签就可以避免那样的问题。另外Merge只能作为XML布局的根标签使用，当Inflate以开头的布局文件时，必须指定一个父ViewGroup，并且必须设定attachToRoot为true。 - 使用Hierarchy Viewer查看视图层级，进而优化减少视图层级
- LinearLayout有时比RelativeLayout效率稍好
RelativeLayout 比 LinearLayout measu 次数多，前提是在2着有这相同的视图层级的时候，但是 LinearLayout 在使用权重后也会多次 measu - 使用新出的 ConstraintLayout 来减少视图层级
这个 ConstraintLayout 很厉害，用它做布局比线性和相对布局有很打的优势啊，具体看着这里解析ConstraintLayout的性能优势
- ViewStub
