关于Android性能优化总结之一

Android性能优化总结一：UI布局优化

照例先贴参考文章地址，汲取各方面资源起码要标明一下，可能看的文章较多有遗漏的不断补充完善

https://my.oschina.net/nicksong/blog/3043796

https://www.jianshu.com/p/d71b51a0e29f

Android的性能优化决定了应用的竞争力和性价比，同样的一个应用除了功能和面向的市场、用户不同可能有量化级的差别，但是作为一个写程序的，抛开公司产品的市场和其他，更值得我们关注的应该是开发应用的性能问题，所以自己也总结归纳一下自己学习的相关方面内容，以备记忆和查阅

一：Android界面绘制UI渲染性能优化

Android的渲染机制是经历了测量（onMeasure ）布局（onLayout ）绘制（onDraw）在绘制在应用界面层，在这里需要知道Android正常的绘制间隔是60帧每秒，也就是说大概在16ms左右会刷新绘制，也只有在这个<=16毫秒的区间内，才能让用户人眼感觉不到卡顿和绘制不流畅的视觉。Android系统每隔16ms发出VSYNC信号触发UI渲染，如果界面绘制无法正常完成控制在这个时间区域内，会发生丢帧、卡顿，在上边说到的三个方法onMeasure、onLayout、onDraw中消耗的时间太长，就容易造成这种现象，所以为了更好更快的绘制UI界面：

1、当布局可以用FrameLayout完成的时候，尽可能用FrameLayout完成。这里借用文章（https://www.cnblogs.com/andy-songwei/p/10955062.html）中的视图层次结构简介来做一个关于系统View的说明，我们平时Activity中setContentView（...）中对应的layout内容对应图中的ViewGroup树状结构，实际在添加到系统中的时候，还会再裹上一层FrameLayout。

补充这个的本意与性能优化的主题无关，但是想说明的是，官方的建议也是尽可能使用FrameLayout布局，原因是因为他的绘制流程相对简洁，通俗的讲就是因为FrameLayout布局的界面执行上边的三个方法的次数少。而相对的LinearLayout会进行测量绘制一次，RelativeLayout则会测量两次，为了确定布局下各控件位置，不过LinearLayout如果添加了权重属性，则同样需要测量两次，所以根据最简原则来选择自己应用界面的布局相对较好。另外ConstraintLayout 约束性布局的出现，也更好的完善了布局界面的主体，如果可以的话最好使用ConstraintLayout ，可以有效的较少绘制的流程步骤。关于ConstraintLayout 约束性，大概总结其特性，就是某个控件相对另一个控件的位置，例如app:layout_constraintRight_toRightOf表示控件的constraintRight右边在toRightOf谁的右边，这个谁可以是一个ID对应的其他控件，也可以是parent父布局，也就是整个外围的框子。另外还有一些其他属性之类或者详解，可以参考：https://blog.csdn.net/airsaid/article/details/79052011，在这里就不细说

2、除了从布局搭建的建议上去做性能优化，多使用include标签，增加重复布局的复用性，类似做一个登录界面，忘记密码界面或者注册界面，大体上一样的UI都可以考虑使用include增加复用性，通常在使用include的时候，会配合merge标签使用（https://www.jianshu.com/p/fbcc6a17d11e）

使用前：

使用后:

这里参考我找了好几个文章找到的一个相对好理解的图，可以看到在使用了merge标签之后，很明显系统在绘制这布局层的时候少绘制了一个节点，从性能上来讲，他是变得简洁了，更优化了绘制的流程，所以但凡对性能优化有帮助的方法，我们总归是能用则用，不过关于merge的用法，需要自行查找相关的知识

3、使用ViewStub提高显示速度，使用的好处是在布局加载的时候才会占用，不加载的时候会隐藏。通俗的来讲就是不显示给用户看的时候，其他是不去绘制的，只有当用户需要看到这个界面的时候才会去花时间绘制，这样可以减少不必要的绘制过程，用户没打算看到的界面就不会预先绘制加载在那里，优化显示的速度，另外我们在使用控件的visibility属性的时候，尽量用gone不用invisible，因为gone是隐藏不绘制，invisible则是绘制好占着那里的位置，但是不显示。

4、类似布局中子布局和父布局同一个背景色或者，可以减少不必要的属性标签，TextView等控件定义的text属性等需要则加，不需要则尽量不用，能省则省，省着省着性能就上去了，积少成多嘛

5、关于应用冷启动优化，Android应用在启动的时候，会有冷启动、热启动和温启动的区分：

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。2、热启动：当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。

Android冷启动时会默认有一个白屏加载过渡的过程，也可以设置为黑屏或者透明屏

          @drawable/img_splash

  

黑屏和白屏效果不太好看，透明屏则会有明显的启动慢的错觉效果，所以建议是使用上述style来优化启动界面的过渡效果，定义一张启动界面图，最好和启动界面的背景一致，可以无感过渡，让用户视觉体验更流程

另外关于这个启动过渡界面的时长，主要是受到Application中启动项的影响，如果在Application中过多的初始化一些第三方，或者其他操作都会导致启动时间过长，所以建议不在Application中进行耗时操作，不参与业务操作，可以将部分初始化，类似友盟、第三方deBugly等初始化放在线程做操作

二：关于UI渲染效果检查工具和使用

UI渲染导致的卡顿等影响性能的问题一旦发生，都不太容易检测和修改，这时候就需要我们借助一些IDE提供的工具来尝试分析原因和发生的地方。

1、Android自带的开发者选项调试工具，我们从一个新手开始一步一步介绍使用步骤和工具，为了避免没有经常使用过的生疏者找起来晕头转向，这里结合了几个文章资料做了总结，首先是“GPU呈现模式分析工具”

第一步：开启手机的开发者模式，“关于手机”——连击版本号开启开发者模式

第二部：手机开发者模式选项中——GPU呈现模式分析选项打开

、

 

参考文章:https://www.jianshu.com/p/ffba2bdd85f5

这篇文章中有关于各个颜色柱状图对应的含义和标识，对应用UI绘制的流程简单分析：

红色代表了“执行时间”；黄色通常较短，它代表着CPU通知GPU“你已经完成视图渲染了”；蓝色代表了视图绘制所花费的时间，表示视图在界面发生变化（更新）的用时情况；绿色水平线代表16ms,要确保一秒内打到60fps,你需要确保这些帧的每一条线都在绿色的16ms标记线之下.任何时候你看到一个竖线超过了绿色的标记现,你就会看到你的动画有卡顿现象产生.；橙色部分表示的是处理时间,或者说是CPU告诉GPU渲染一帧的时间,这是一个阻塞调用,因为CPU会一直等待GPU发出接到命令的回复,如果柱状图很高,那就意味着你给GPU太多的工作,太多的负责视图需要OpenGL命令去绘制和处理.

通过GPU渲染模式分析呈现可以知道大致哪里有卡顿，哪里可能会出现问题，哪里绘制花费CPU消耗更多

2、接下来要定位具体问题原因和修改方法，可以考虑systrace工具，Android studio原来是有的，但是在3.0中Tools取消了

因为Android Studio 3.0官网上的原话：

Android Device Monitor is a standalone tool that provides a UI for several Android app debugging and analysis tools. However, most components of the Android Device Monitor are deprecated in favor of updated tools available in Android Studio 3.0 and higher. The table below helps you decide which developer tools you should use.

（Android设备监视器是一个独立的工具，为几个Android应用调试和分析工具提供了一个UI。 但是，大多数Android设备监视器组件已弃用，以支持Android Studio 3.0和更高版本中提供的更新工具。下表帮助您决定应该使用哪些开发人员工具）

可以参考：https://blog.csdn.net/qq_32434307/article/details/90053047在studio中使用，但是我这里使用无法打开执行，所以尝试用eclipse来生成trace文件分析。

第一步：打开Window->Show View -> Other-> Android选项卡。

第二部：找到对应的进程名和真机Device设备，Capture system wide trace using Android sysTrace按键，如图位置：

第三部：设置对应执行时长、大小以及文件生成的保存路径：

在真机操作执行的过程中，开始加载进度时长，自动生成trace的html文件

第四步：找到trace文件进行分析，这里需要用到Chrome浏览器来打开生成的trace 文件。怎么打开这个文件？

需要在浏览器地址栏输入:chrome://tracing/

在左上角load加载中可以加载生成的trace文件，生成这样的CPU使用等的界面图，就算完成了

这是一些查看时的快捷键：

参考文章:https://www.jianshu.com/p/75aa88d1b575

SysTrace显示每一帧的绘制，并会高亮显示渲染比较慢的帧，使用绿色、黄色、红色来显示，每一帧的渲染时间超过16ms会用黄色或者红色来显示；这个比GPU渲染模式分析更准确的显示每一帧,而且也会给出相对应的修改建议和具体问题。

三：收尾

关于UI绘制性能优化上，还是建议：

尝试使用ConstraintLayout：它提供了类似的功能，并且没有性能上的缺陷。

避免丢帧比较耗时的操作能不放在主线程中执行，就尽量不放在主线程中执行

减少绘制流程，ViewGroup树状View分支

以及之前说到的其他