android性能跟踪分析工具系列

文集目录

ps：喜欢的点赞哦 android性能跟踪分析工具系列 - 目录

万事初始，理论先行，理论都不知道，给你上面的那些工具你又能怎样呢，再说这些工具的目的也是为了发现定位问题，至于找到问题如何解决，什么算是问题，哪里可以优化这些没有理论是不行的

这里我就不班门弄斧了，已经有很多优秀的文章了，这里贴出来：

Android 之旅：Google 发布 Android 性能优化典范
性能优化基本概念
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 内看到的是相同的内容，这也就是造成界面卡顿的最浅显原因
界面刷新一次的过程：
1. cpu测量，布局界面上变动的视图对象，然后绘制这些 view(onDraw方法) 生成界面一帧数据
2. 然后 cpu 把这计算出的这一帧数据传递给 gpu，这一帧数据也叫纹理，具体的去看 OpenGL的内容
3. gpu 根据cpu 传递过来的纹理数据，去具体的绘制出2D 图形来
4. cpu 等待 pgu 通知绘制完成，cpu 才可以去干别的事，要不 cpu 会一直等着。。。这才算是完成了一帧的渲染
5. 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区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。
减少视图层级方案：
- 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的性能优势

android性能跟踪分析工具系列 - 各种理论简介