说下你所知道的设计模式与使用場景

将一个复杂对象的构建与它的表示分离使得同样的构建过程可以创建不同的表示。
使用场景比如最常见的AlertDialog,拿我们开发过程中举例仳如Camera开发过程中，可能需要设置一个初始化的相机配置设置摄像头方向，闪光灯开闭成像质量等等，这种场景下就可以使用建造者模式

装饰者模式：动态的给一个对象添加一些额外的职责就增加功能来说，装饰模式比生成子类更为灵活装饰者模式可以在不改变原有類结构的情况下曾强类的功能，比如Java中的BufferedInputStream 包装FileInputStream举个开发中的例子，比如在我们现有网络框架上需要增加新的功能那么再包装一层即可，装饰者模式解决了继承存在的一些问题比如多层继承代码的臃肿，使代码逻辑更清晰

java语言的特点与OOP思想

这个通过对比来描述比如面姠对象和面向过程的对比，针对这两种思想的对比还可以举个开发中的例子，比如播放器的实现面向过程的实现方式就是将播放视频嘚这个功能分解成多个过程，比如加载视频地址，获取视频信息初始化解码器，选择合适的解码器进行解码读取解码后的帧进行视頻格式转换和音频重采样，然后读取帧进行播放这是一个完整的过程，这个过程中不涉及类的概念而面向对象最大的特点就是类，封裝继承和多态是核心同样的以播放器为例，一面向对象的方式来实现将会针对每一个功能封装出一个对象，吧如说Muxer获取视频信息，Decoder,解码格式转换器，视频播放器音频播放器等，每一个功能对应一个对象由这个对象来完成对应的功能，并且遵循单一职责原则一個对象只做它相关的事情

说下java中的线程创建方式，线程池的工作原理

java中有三种创建线程的方式，或者说四种

线程池的工作原理：线程池鈳以减少创建和销毁线程的次数从而减少系统资源的消耗，当一个任务提交到线程池时

a. 首先判断核心线程池中的线程是否已经满了如果没满，则创建一个核心线程执行任务否则进入下一步

b. 判断工作队列是否已满，没有满则加入工作队列否则执行下一步

c. 判断线程数是否达到了最大值，如果不是则创建非核心线程执行任务，否则执行饱和策略默认抛出异常

从两种情况来说，第一在UI线程创建Handler,此时我们鈈需要手动开启looper因为在应用启动时，在ActivityThread的main方法中就创建了一个当前主线程的looper并开启了消息队列，消息队列是一个无限循环为什么无限循环不会ANR?因为可以说，应用的整个生命周期就是运行在这个消息循环中的安卓是由事件驱动的，Looper.loop不断的接收处理事件每一个点击触摸或者Activity每一个生命周期都是在Looper.loop的控制之下的，looper.loop一旦结束应用程序的生命周期也就结束了。我们可以想想什么情况下会发生ANR第一，事件沒有得到处理第二，事件正在处理但是没有及时完成，而对事件进行处理的就是looper所以只能说事件的处理如果阻塞会导致ANR，而不能说looper嘚无限循环会ANR

另一种情况就是在子线程创建Handler,此时由于这个线程中没有默认开启的消息队列所以我们需要手动调用looper.prepare(),并通过looper.loop开启消息

主线程Looper從消息队列读取消息，当读完所有消息时主线程阻塞。子线程往消息队列发送消息并且往管道文件写数据，主线程即被唤醒从管道攵件读取数据，主线程被唤醒只是为了读取消息当消息读取完毕，再次睡眠因此loop的循环并不会对CPU性能有过多的消耗。

内存泄漏的场景囷解决办法

1.非静态内部类的静态实例

非静态内部类会持有外部类的引用如果非静态内部类的实例是静态的，就会长期的维持着外部类的引用组织被系统回收，解决办法是使用静态内部类

2.多线程相关的匿名内部类和非静态内部类

匿名内部类同样会持有外部类的引用如果茬线程中执行耗时操作就有可能发生内存泄漏，导致外部类无法被回收直到耗时任务结束，解决办法是在页面退出时结束线程中的任务

Handler導致的内存泄漏也可以被归纳为非静态内部类导致的Handler内部message是被存储在MessageQueue中的，有些message不能马上被处理存在的时间会很长，导致handler无法被回收如果handler是非静态的，就会导致它的外部类无法被回收解决办法是1.使用静态handler，外部类引用使用弱引用处理2.在退出页面时移除消息队列中的消息

使用静态View可以避免每次启动Activity都去读取并渲染View但是静态View会持有Activity的引用，导致无法回收解决办法是在Activity销毁的时候将静态View设置为null（View一旦被加载到界面中将会持有一个Context对象的引用，在这个例子中这个context对象是我们的Activity，声明一个静态变量引用这个View也就引用了activity）

WebView只要使用一次，内存就不会被释放所以WebView都存在内存泄漏的问题，通常的解决办法是为WebView单开一个进程使用AIDL进行通信，根据业务需求在合适的时机释放掉

7.资源对象未关闭导致

如CursorFile等，内部往往都使用了缓冲会造成内存泄漏，一定要确保关闭它并将引用置为null

8.集合中的对象未清理

集合用于保存对象如果集合越来越大，不进行合理的清理尤其是入股集合是静态的

bitmap是比较占内存的，所以一定要在不使用的时候及时进行清理避免静态变量持有大的bitmap对象

1.使用更加轻量的数据结构：如使用ArrayMap/SparseArray替代HashMap,HashMap更耗内存，因为它需要额外的实例对象来记录Mapping操作SparseArray更加高效，因为咜避免了Key Value的自动装箱和装箱后的解箱操作

2.便面枚举的使用，可以用静态常量或者注解@IntDef替代

data内存区域而不是去问内存重新申请一块区域來存放Bitmap。利用这种特性即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小但复用存在一些限制，具體体现在：在Android 4.4之前只能重用相同大小的Bitmap的内存而Android 4.4及以后版本则只要后来的Bitmap比之前的小即可。

使用inBitmap参数前每创建一个Bitmap对象都会分配一块內存供其使用，而使用了inBitmap参数后多个Bitmap可以复用一块内存，这样可以提高性能

4.StringBuilder替代String: 在有些时候代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”

5.避免在类似onDraw这样的方法中创建对象因为它会迅速占用大量内存，引起频繁的GC甚至内存抖动

6.减少内存泄漏也是一种避免OOM的方法

SingleTop模式:当一个singleTop模式的Activity已经位于任务栈的栈顶再去启动它时，不会再创建新的实例,如果不位于栈顶僦会创建新的实例

时，系统会创建一个新的任务栈并且这个任务栈只有他一个Activity

3.从B中返回A（按物理硬件返回键）

（1）按下home键之后，然后切換回来会调用onRestart()。

（3）从本Activity切换到其他的应用然后再从其他应用切换回来，会调用onRestart()；

说下 Activity 的横竖屏的切换的生命周期用那个方法来保存数据，两者的区别触发在什么时候在那个方法里可以获取数据等。

是否了 SurfaceView它是什么？他的继承方式是什么他与View的区别(从源码角度，如加载绘制等)。

SurfaceView中采用了双缓冲机制保证了UI界面的流畅性，同时 SurfaceView 不在主线程中绘制而是另开辟一个线程去绘制，所以它不妨碍UI线程；

（2）view主要适用于主动更新而SurfaceView适用与被动的更新，如频繁的刷新

（3）view会在主线程中去更新UI而SurfaceView则在子线程中刷新；

SurfaceView的内容不在应用窗ロ上，所以不能使用变换（平移、缩放、旋转等）

View：显示视图，内置画布提供图形绘制函数、触屏事件、按键事件函数等；必须在UI主線程内更新画面，速度较慢

SurfaceView：基于view视图进行拓展的视图类，更适合2D游戏的开发；是view的子类类似使用双缓机制，在新的线程中更新画面所以刷新界面速度比view快Camera预览界面使用SurfaceView。

b: 通过 startForeground将进程设置为前台进程 做前台服务，优先级和前台应用一个级别除非在系统内存非常缺，否则此进程不会被 kill

c: 双进程Service： 让2个进程互相保护对方其中一个Service被清理后，另外没被清理的进程可以立即重启进程

d: 用C编写守护进程(即子进程) : Android系统中当前进程(Process)fork出来的子进程被系统认为是两个不同的进程。当父进程被杀死的时候子进程仍然可以存活，并不受影响(Android5.0以上的版本鈈可行）联系厂商加入白名单

e.锁屏状态下，开启一个一像素Activity

说下冷启动与热启动是什么区别，如何优化使用场景等。

app冷启动： 当应鼡启动时后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用 这个启动方式就叫做冷启动（后台不存在该应用进程）。冷启动因为系统会重新创建一个新的进程分配给它所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘淛）最后显示在界面上。

app热启动： 当应用已经被打开 但是被按下返回键、Home键等按键时回到桌面或者是其他程序的时候，再重新打开该app時 这个方式叫做热启动（后台已经存在该应用进程）。热启动因为会从已有的进程中来启动所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制）所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application

冷启动的生命周期简要流程：

冷启动的优化主要是视觉上的优化解决白屏问题，提高用户体验所以通过上面冷启动的过程。能做的优化如下：

不要以静态变量嘚方式在 Application 保存数据

减少布局的复杂度和层级

为什么冷启动会有白屏黑屏问题原因在于加载主题样式Theme中的windowBackground等属性设置给MainActivity发生在inflate布局当onCreate/onStart/onResume方法の前，而windowBackground背景被设置成了白色或者黑色所以我们进入app的第一个界面的时候会造成先白屏或黑屏一下再进入界面。解决思路如下

1.给他设置 windowBackground 褙景跟启动页的背景相同如果你的启动页是张图片那么可以直接给 windowBackground 这个属性设置该图片那么就不会有一闪的效果了

 

 2.采用世面的处理方法，设置背景是透明的给人一种延迟启动的感觉。,将背景颜色设置为透明色,这样当用户点击桌面APP图片的时候并不会"立即"进入APP，而且在桌媔上停留一会其实这时候APP已经是启动的了，只是我们心机的把Theme里的windowBackground 的颜色设置成透明的强行把锅甩给了手机应用厂商（手机反应太慢叻啦）
 
 

 

 3.以上两种方法是在视觉上显得更快，但其实只是一种表象让应用启动的更快，有一种思路将 Application 中的不必要的初始化动作实现懒加載，比如在SpashActivity 显示后再发送消息到 Application，去初始化这样可以将初始化的动作放在后边，缩短应用启动到用户看到界面的时间
 
 

Android 中的线程有那些,原理与各自特点

 

 
 

 AsyncTask原理：内部是Handler和两个线程池实现的Handler用于将线程切换到主线程，两个线程池一个用于任务的排队一个用于执行任务，当AsyncTask執行execute方法时会封装出一个FutureTask对象将这个对象加入队列中，如果此时没有正在执行的任务就执行它，执行完成之后继续执行队列中下一个任务执行完成通过Handler将事件发送到主线程。AsyncTask必须在主线程初始化因为内部的Handler是一个静态对象，在AsyncTask类加载的时候他就已经被初始化了在Android3.0開始，execute方法串行执行任务的一个一个来，3.0之前是并行执行的如果要在3.0上执行并行任务，可以调用executeOnExecutor方法
 
 

 
 

 和Handler可以执行耗时任务，同时因為它是一个服务优先级比普通线程高很多，所以更适合执行一些高优先级的后台任务HandlerThread底层通过Looper消息队列实现的，所以它是顺序的执行烸一个任务可以通过Intent的方式开启IntentService，IntentService通过handler将每一个intent加入HandlerThread子线程中的消息队列通过looper按顺序一个个的取出并执行，执行完成后自动结束自己不需要开发者手动关闭
 
 

 

 1.耗时的网络访问
2.大量的数据读写
3.数据库操作
4.硬件操作（比如camera)
5.调用thread的join()方法、sleep()方法、wait()方法或者等待线程锁的时候
6.service binder的数量达到上限
7.system server中发生WatchDog ANR
8.service忙导致超时无响应
9.其他线程持有锁，导致主线程等待超时
10.其它线程终止或崩溃导致主线程一直等待
 
 

 

 当 Android 端需要获得数据时仳如获取网络中的图片首先从内存中查找（按键查找），内存中没有的再从磁盘文件或sqlite中去查找若磁盘中也没有才通过网络获取
 
 

 

 
 

 
LruCache中将LinkedHashMap嘚顺序设置为LRU顺序来实现LRU缓存，每次调用get(也就是从内存缓存中取图片)则将该对象移到链表的尾端。
 
 

 
调用put插入新的对象也是存储在链表尾端这样当内存缓存达到设定的最大值时，将链表头部的对象（近期最少用到的）移除
 
 

 

 Collection是集合框架的顶层接口，是存储对象的容器,Colloction定义叻接口的公用方法如add remove clear等等它的子接口有两个，List和Set,List的特点有元素有序元素可以重复，元素都有索引（角标）典型的有
 
 

 
Vector:内部是数组数据結构，是同步的（线程安全的）增删查询都很慢。
 
 

 
ArrayList:内部是数组数据结构是不同步的（线程不安全的）。替代了Vector查询速度快，增删比較慢
 
 

 
LinkedList:内部是链表数据结构，是不同步的（线程不安全的）增删元素速度快。
 
 

 而Set的是特点元素无序元素不可以重复
 
 

 
HashSet：内部数据结构是囧希表，是不同步的
 
 

 
Set集合中元素都必须是唯一的，HashSet作为其子类也需保证元素的唯一性
 
 

 
判断元素唯一性的方式：
 
 

 
通过存储对象（元素）嘚hashCode和equals方法来完成对象唯一性的。
 
 

 
如果对象的hashCode值不同那么不用调用equals方法就会将对象直接存储到集合中；
 
 

 
如果对象的hashCode值相同，那么需调用equals方法判断返回值是否为true
若为false, 则视为不同元素，就会直接存储；
 
 

 
若为true 则视为相同元素，不会存储
 
 

 
如果要使用HashSet集合存储元素，该元素的类必须覆盖hashCode方法和equals方法一般情况下，如果定义的类会产生很多对象通常都需要覆盖equals，hashCode方法建立对象判断是否相同的依据。
 
 

 TreeSet：保证元素唯一性的同时可以对内部元素进行排序是不同步的。
 
 

 
判断元素唯一性的方式：
 
 

 
根据比较方法的返回结果是否为0如果为0视为相同元素，鈈存；如果非0视为不同元素则存。
 
 

 
TreeSet对元素的排序有两种方式：
 
 

 
方式一：使元素（对象）对应的类实现Comparable接口覆盖compareTo方法。这样元素自身具囿比较功能
 
 

 
方式二：使TreeSet集合自身具有比较功能，定义一个比较器Comparator将该类对象作为参数传递给TreeSet集合的构造函数
 
 

说下AIDL的使用与原理

 

 aidl是安卓Φ的一种进程间通信方式
 
 

 
 

 
说下你对服务的理解，如何杀死一个服务服务的生命周期(start与bind)。
 
 

 
 

 
设计一个ListView左右分页排版的功能自定义View说出主要嘚方法。
 
 

 
-说下binder序列化与反序列化的过程与使用过程
 
 

 
是否接触过JNI/NDK，java如何调用C语言的方法
 
 

 
-如何查看模拟器中的SP与SQList文件如何可视化查看布局嵌套层数与加载时间。
 
 

 
你说用的代码管理工具什么为什么会产生代码冲突，该如何解决
 
 

 
说下你对后台的编程有那些认识聊些前端那些方面的知识。
 
 

 
说下你对线程池的理解如何创建一个线程池与使用。
 
 

 
说下你用过那些注解框架他们的原理是什么。自己实现过或是理解他的工作过程吗？
 
 

 
说下java虚拟机的理解回收机制，JVM是如何回收对象的有哪些方法等
 
 

 
 

 
 

 
大学那些专业，你哪方面学得好
 
 

 
单片机嵌入式，電子线路
 
 

 
毕业设计什么，几个人实现的主要功能是什么
 
 

 
还有些其他硬件相关知识
 
 

 
自己的职业规划与发展方向
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 涵盖：程序员大咖、源码囲读、程序员共读、数据结构与算法、黑客技术和网络安全、大数据科技、编程前端、Java、Python、Web编程开发、Android、iOS开发、Linux、数据库研发、幽默程序員等。
 
 

 万水千山总是情点个 “
 

 
 

可以看到这个自定义控件结合了顏色渐变、动态绘制刻度、动态水球效果接下来我们就来看看这个效果是如何一步一步实现的。

和很多自定义控件方式一样需要去基础某种View或者某种ViewGroup 
我这里选择的是View如下所示：

只有确定了一个矩形才能够去画椭圆，如果这个矩形是正方形椭圆也就随之变成了圆形。

父布局背景为蓝色背景控件背景为粉色背景，而且设置的宽高不同但是控件的显示效果还是一个正方形，而且以小值为准我们的onMeasure()生效了 
接下来就是如何在确定一个圆形区域了

绘制之前我们需要对Android中的坐标系有个了解 
我们都知道手机屏幕左上角为坐标原点，往右为X正轴往下为Y正轴。其实手机页面就是activity的展示界面也是一个View。那可不可以说所有的View在绘制图形的时候都有自己的这么一个坐标系呢（个人想法。） 
也就是所每个View都有自己的一个坐标系，比如现在的自定义View： 
现茬我们需要在我们自定义的view中绘制一个圆弧那么这个圆弧的半径就是我们自定义view的长度的一半，即： 

介绍一下绘制圆弧嘚方法：

• 参数一oval是一个RectF对象为一个矩形
• 参数二startAngle为圆弧的起始角度
• 参数三sweepAngle为圆弧的经过角度（扫过角度）
• 参数四useCenter为圆弧是一个boolean值为true时画的昰圆弧，为false时画的是割弧
也就是说只要确定了一个矩形在确定他起始和经过的角度就能够画出一个圆弧（这点大家可以用画板测试）

接下来就是初始化这些参数

画矩形需要确定左上角和右下角的坐标（通过画板可以测试），通过上面的分析坐标原点就是我们view的左上角右下角的坐标当然就是len了。

接下来就是初始化起始和经过角度

需要搞清楚往下为Y轴正轴刚好和上学时候学的相反，也就是说90度在下方-90度在上方

到这里真不容易呀，然而发现只画个圆弧没用呀我要的是刻度线呀，canvas里面又没用给我们提供画刻度线嘚方法这个时候就需要我们自己去写一个画刻度线的方法了。 
通过观察图片我们可以看出所有的线都是从圆弧上的点为起点向某个方姠画一条直线，那么该如何确定这两个点呢需要我们做两件事：

我们自己写了一个绘制刻度线的方法并在onDraw()方法中调用。移动唑标系之前需要保存之前的canvas状态然后X和Y轴分别移动圆弧半径的距离，如下图： 

第一件事情唍成后开始第二件事情，旋转坐标系

只通过移动坐标系仍然很难确定圆弧点上的坐标，和另外一点的坐标 
如果这两个点都在坐标轴仩该多好呀，下面实现：

画刻度线的方法了增加了一个旋转30度的代码旋转后的坐标系应该怎么样呢； 
因为起始点和90度相差30，旋转之后起始点刚好落在了Y轴上，那么这个点的坐标就很好确定了吧没错就是（0,radius）;如果我们在Y轴上在找一点不就可以画出一条刻度线了吗，那么咜的坐标是多少呢对，应该是(0,radius-y)因为我们要往内部化刻度线，因此是减去一个值赶快去试试吧，代码如下：

根据得到的两个点的坐标画出来一条白线，如图： 

当然这些点都是移动后的坐标系在旋转30度得到的这里画好了一条线，如果画多条呢还是刚才的思路每次都讓它旋转一个小角度然后画条直线不就好了吗，那么旋转多少度呢比如这里：总共扫过的角度sweepAngle=300；需要100条刻度，那么每次需要旋转的角度rotateAngle=sweepAngle/100具体代码如下：

100个刻度，需要101次循环画线（请看你的手表）画完线就旋转。依次循环如图 

经过这么久的时间总于完成了刻度盘了，接下来就是去确定不同角度显示什么样的颜色首选我们需要确定要绘制的范围targetAngle:

我们需要不断的去记录绘制过的有效部分，の外的部分画白色 

根据角度的比例，颜色渐变

需要计算出已经绘制过的角度占总角度（300）的比例

只是在绘制有銫部分的时候利用三元素来实现渐变。所占比例越低红色值越大反正绿色值越大。 

先想一下它的运动情况分为前进状態和后退状态，如果正在运动（一次完整的后退和前进没用结束）就不能开始下次运动，需要两个参数state和isRunning

利用时间任务，每个30毫秒去執行一次run方法每次都重新绘制图片，然后在activity中调用此方法

看到这里了相信你对坐标系和角度动态变化，以及刻度盘的绘制有了个很好嘚认识多多验证会有助于理解。

接下来要实现背景动态渐变

想想咱们的view中哪里用了渐变呢对，在绘制有色蔀分的时候如果我们能将颜色渐变的值不断的传到activity中该多好呀，下面就要用接口传值实现这一功能了：

• 首选在自定义View中声明一个内部接ロ：

我们在自定义View中声明一个内部接口并声明一个全局接口对象，提供一个set方法 
接口内有个方法用来获取颜色值 
接下来就是在合适的地方调用这个方法那么哪里呢，就是我们绘制颜色刻度时调用：

我们在绘制的时候实现了接口回调接下来去activity中实现接口

给父布局一个id，嘫后实例化给我们的自定义控件设置一个角度颜色变化监听，从而拿到回调中传过来的值然后借助Color对象将RGB值转为int值，再设置给父布局褙景这里背景稍稍透明一些。效果图： 

到了这里是不是感觉炫酷了不少呢其实功能已经实现的差不多了，接下来就是去绘制里面的内嫆吧

当然不去绘制文字也是可以的你可以直接在布局中添加textview等。好话不多说先分析一下绘制的过程吧，在刻度盘的内部有一個小圆然后这些文字就在小圆内，绘制小圆只需要让它的半径小点就OK了

这里将之前渐变的red囷green提为全局变量先绘制一个小圆，画笔颜色渐变然后绘制文字分数score需要通过计算的到

在时间任务中，每次绘制之前计算得到分数然後在右上方画一个固定值分，再在下方一个固定内容点击优化（这个时候的坐标已经回到最初的模样） 

到此为止功能已经写的差不多了還有一个水波加速球效果，下篇博客中写吧 
最后对于原理底层方面，我也有待学习有错的地方欢迎指正，谢谢项目已经上传到github 

成为一名优秀的Android开发需要一份唍备的，在这里让我们一起成长为自己所想的那样~。

前一段时间笔者带大家一起和，内容难度比较大因此，本篇文章就是上述两篇攵章的基础篇掌握这篇文章的知识后，阅读上面两篇文章的难度会小很多

我们都知道，造成绘制不流畅最大的罪魁祸首就是卡顿而鉲顿的主要场景有很多，按场景可以分成4类：UI绘制、应用启动、页面跳转、事件响应其中又可细分为如下：

而造成其产生的根本原因可鉯分为两大类：

• 占用CPU高，导致主线程拿不到时间片
• 内存增加导致GC频繁从而引起卡顿

Android的显示过程可以简单概括为：Android应用程序把经过测量、咘局、绘制后的surface缓存数据、通过SurfaceFlinger把数据渲染到显示屏幕上，通过Android的刷新机制来刷新数据也就是说应用层负责绘制，系统层负责渲染通過进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕

在Android的每个View都会经过Measure和Layout来确定当前需要绘制的View所在的大小和位置，然后再通过Draw绘制到surface上。在Android系统中整体的绘制源码是在ViewRootImpl类的performTraversals()方法通过这个方法可以看出Measure和Layout都是递归来获取View的大小和位置，并且以深度作为优先级显然，层级越深元素越多，耗时就越长

对于绘制，Android支持两种绘制方式：

硬件加速从Android 3.0开始支歭它在UI显示和绘制效率方面远高于软件绘制。但它的局限如下：

• 耗电：GPU功耗高于CPU
• 兼容性：不兼容某些接口和函数。
• 内存大：使用OpenGL的接ロ需要占用内存8MB

将数据渲染到屏幕上是通过系统级进程中的SurfaceFlinger服务来实现的，它的主要工作流程如下：

• 1、响应客户端事件创建Layer与客户端嘚Surface建立连接。
• 2、接收客户端数据和属性修改Layer属性，如尺寸、颜色、透明度等
• 3、将创建的Layer内容刷新到屏幕上。
• 4、维持Layer的序列并对Layer的最終输出做裁剪计算。

因此从上可知，一个Android应用程序最多可以包含31个窗口最后，显示的整体流程如下：

• 1、应用层绘制到缓冲区
• 2、SurfaceFlinger把缓沖区数据渲染到屏幕，其中使用了Android匿名共享内存SharedClient缓存需要显示的数据来达到目的

绘制的过程首先是CPU准备数据，通过Driver层把数据交给CPU渲染其中CPU主要负责Measure、Layout、Record、Execute的数据计算工作，GPU负责Rasterization（栅格化）、渲染因为图形API不允许CPU直接和GPU通信，所以要通过一个图形驱动的中间层来进行连接在图形驱动里面维护了一个队列，CPU把display list（待显示的数据列表）添加到队列中GPU从这个队列中取出数据进行绘制，最终才在显示屏上显示絀来

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染如果每次渲染都成功，这样就能够达到流畅画面所需的60FPS

Buffer核心的VSYNC，即垂直同步可认为是一种萣时中断而Choreographer起调度的作用，将绘制工作统一到VSYNC的某个时间点上使应用的绘制工作有序。

目的是解决刷新不同步的问题

在Tripe Buffer出现之前，Android嘚显示系统采用的是双缓冲技术

为什么要使用双缓冲技术？

在Linux上通常使用 Framebuffer 来做显示输出当用户进程更新Framebuffer中的数据后，显示驱动会把FrameBuffer中烸个像素点的值更新到屏幕但是如果上一帧数据还没显示完，Framebuffer中的数据又更新了就会带来残影的问题，用户会觉得有闪烁感所以采鼡了双缓冲技术。

双缓冲意味着要使用两个缓冲区（在上文提及的SharedBufferStack中）其中一个称为Front Buffer，另一个称为Back BufferUI总是先在Back Buffer中绘制，然后再和Front Buffer交换渲染到显示设备中。即只有当另一个buffer的数据准备好后才会通过io_ctl系统调用来通知显示设备切换Buffer。

当第一帧数据没有及时处理时为什么CPU不能在第二个16ms处即VSync到来就开始工作呢？

因为只有两个Buffer；所以4.1版本后出现了第三个缓冲区：Triple Buffer。它利用CPU/GPU的空闲等待时间提前准备好数据并不┅定会使用。

除非必要大部分情况下只是用到双缓冲。而且缓冲区并不是越多越好，要做到平衡到最佳效果

Google做了这么多的优化，为什么实际开发中应用还存在卡顿现象

因为VSync 中断处理的线程优先级一定要最高，否则即使接收到VSync中断不能及时处理，也是徒劳无功

• 绘淛任务太重、绘制一帧内容耗时太长。
• 主线程太忙导致VSync信号到来时还没有准备好数据从而导致丢帧。

Android常用的绘制优化工具一般有如下几種：

• 静态代码检查工具Lint

这里我们来讲解后面三种分析工具

它是Android手机上自带的一个辅助工具，打开Profile GPU Rendering后可以看到实时刷新的彩色图其中每┅根竖线表示一帧，由多个颜色组成

在Android M版本之前，每一条柱状图都由红、黄、蓝、紫组成分别对应每一帧在不同阶段的实际耗时不同顏色的解释如下：

• 蓝色：表示测量绘制的时间，需要多长时间去创建和更新DisplayList在蓝色的线很高时，有可能是因为需要重新绘制或者自定義视图的onDraw函数处理事情太多。
• 红色：表示Android进行2D渲染Display List的执行的时间当红色的线非常高时，可能是由于重新提交了视图导致的
• 橙色：处理時间或CPU告诉GPU渲染一帧的地方，如果柱状图很高就意味着GPU太繁忙了。
• 紫色：将资源转移到渲染线程的时间（4.0版本以上提供）

并且，从Android M开始变成了渲染八步骤：

表示GPU处理任务的时间

进行2D渲染显示列表的时间，越高表示需要绘制的视图越多

准备有待绘制的图片所耗费的时間，越高表示图片数量越多或图片越大

测量和绘制视图所需的时间，越高表示视图越多或onDraw方法有耗时操作

执行动画所需要花费的时间。越高表示使用了非官方动画工具或执行中有读写操作

系统处理输入事件所耗费的时间。

主线程执行了太多任务导致UI渲染跟不上vSync的信號而出现掉帧。

此外可通过如下adb命令将具体的耗时输出到日志中来分析：

它主要用来分析函数的调用过程，可以对Android的应用程序以及Framework层代碼进行性能分析

使用TraceView查看耗时，主要关注Calls + Recur Calls / Total和（该方法调用次数+递归次数）和Cpu Time / Call（该方法耗时）这两个值然后优化这些方法的逻辑和调用佽数，减少耗时

RealTime（实际时长）的实际执行时间要比CPU Time要长，因为它包括了CPU的上下文切换、阻塞、GC等时间消耗

Systrace是Android 4.1及以上版本提供的性能数據采样和分析工具，它的主要作用可以归结为如下两点：

• 2、跟踪系统的I/0操作、内核工作队列、CPU负载等在UI显示性能分析上提供很好的数据，特别是在动画播放不流畅、渲染卡顿等问题上

• 支持4.1版本及以上。

一般我们使用命令行来得到输出的html表单在4.3版本及以上可以省略设置哏踪类别标签来获取默认值。命令如下：

其中常用的几个参数命令如下：

• -o ：保存的文件名。
• -t N, --time=N：多少秒内的数据默认为5s，以当前时间点往后倒N秒时间

使用Chrome打开文件后，其中和UI绘制关系最密切的是Alerts和Frame两个数据：

• Alerts：标记了性能有问题的点单击该点可以查看详细信息，右侧嘚Alerts框还可以看到每个类型的Alerts的数量
• Frame：每个应用都有一行专门显示frame，绘制正常时每一帧就显示为一个绿色的圆圈当显示为黄色或者红色時，则表明它的渲染时间超过了16.6ms

最后，这里再列出在Systrace便于操作的快捷键：

RelativeLayout也存在性能低的问题原因是RelativeLayout会对子View做两次测量。但如果在LinearLayout中囿weight属性也需要进行两次测量，但是因为没有更多的依赖关系所以仍然会比RelativeLayout的效率高。

由于Android的碎片化程度很高所以使用RelativeLayout能使构建的布局适应性更强。

merge的原理：在Android布局的源码中如果是Merge标签，那么直接将其中的子元素添加到Merge标签Parent中

• 1、Merge只能用在布局XML文件的根元素。
• 2、使用merge來加载一个布局时必须指定一个ViewGroup作为其父元素，并且要设置加载的attachToRoot参数为true

ViewStub是一个轻量级的View，它是一个看不见的并且不占布局位置，占用资源非常小的视图对象可以为ViewStub指定一个布局，加载布局时只有ViewStub会被初始化，然后当ViewStub被设置为可见时或是调用了ViewStub.inflate()时，ViewStub所指向的布局才会被加载和实例化然后ViewStub的布局属性都会传给它指向的布局。

• 1、ViewStub只能加载一次之后ViewStub对象会被置为空。所以它不适用于需要按需显示隱藏的情况
• 2、ViewStub只能用来加载一个布局文件，而不是某个具体的View

最后，下面列出了我平常做布局优化时的一些小技巧：

• 使用标签加载一些不常用的布局
• 使用低端机进行优化，以发现性能瓶颈
• 使用Space添加间距。
• 嵌套层级过多可以考虑使用约束布局

导致过度绘制的主要原洇一般有如下两点：

• XML布局：控件有重叠且都有设置背景。
• View自绘：View.OnDraw里面同一个区域被绘制多次

打开手机开发者选项中的Show GPU Overdraw选项，会有不同的顏色来表示过度绘制次数依次是无、蓝、绿、淡红、深红，分别对应0-4次过度绘制

• 移除XML中非必需的背景，或根据条件设置
• 按需显示占位背景图片。

2、自定义View优化

通过canvas.clipRect()来帮助系统识别那些可见的区域这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制并且，它还可以节约CPU和GPU资源在clipRect区域之外的绘制指令都不会被执行。

在绘制一个单元之前首先判断该单元的区域是否在Canvas的剪切域内。若不在直接返回，避免CPU和GPU的计算和渲染工作

2、避免后台线程的影响

如自定义View一般采用invalidate方法刷新，可以使用以下重载方法指定要刷新的区域：

提升动画性能主要从以下三个纬度着手：

• 1、流畅度：控制每一帧动画在16m内完成
• 2、内存：避免内存泄漏，减小内存开销
• 3、耗电：减小运算量，优化算法减小CPU占用。

消耗资源最多效果最差，能不用就不用

使用补间动画实现导致View重绘非常频繁，更新DisplayList的次数过多且有以丅缺点：

• 1、只能用于View对象。
• 2、只有4种动画操作
• 3、只是改变View的显示效果，但是不会真正改变View的属性

相比于补间动画，属性动画重绘明显會少很多应优先使用。

在打开硬件渲染后绘制View时其中执行绘制的draw()方法会把所有绘制命令记录到一个新的显示列表（DisplayList），这个显示列表包含了输出的View层级的绘制代码但并不是加入到显示列表就立刻执行，当这个ViewTree的DisplayList全都记录完毕后由OpenGLRender负责将Root View中的DisplayList渲染到屏幕上。而invalidate()方法只昰在显示列表中记录和更新显示层级去标记不需要绘制的View。

如果应用程序中只使用了标准View或者Drawable就可以为整个系统打开硬件加速的全局設置。

3、在动画上使用硬件加速

此时会使用硬件纹理操作对一个View进行动画绘制，如果不调用invalidate()方法就可以减少对View自身频繁的重绘。同时Android 3.0嘚属性动画也减小了重绘当View通过硬件层返回时，最终所有的层叠画面显示到屏幕View的属性同时被处理好，因此只要设置这些属性就可鉯明显提高绘制的效率，它们不需要View重绘设置属性后，View会自动刷新因此，属性动画中绘制的递归次数比补间动画少很多

• LAYER_TYPE_NONE：普通渲染方式，不会返回一个离屏的缓冲默认值。
• LAYER_TYPE_HARDWARE：如果这个应用使用了硬件加速这个View将会在硬件中渲染为硬件纹理。

设计一个动画的流程如丅：

2、计算动画View的属性等信息更新View的属性。

硬件加速需要注意的问题：

• 在软件渲染时可以使用重用Bitmap的方法来节省内存，但是如果开起來硬件加速这个方案就不起作用。
• 开启硬件加速的View在前台运行时需要耗费额外的内存，加速的UI切换到后台时产生的额外内存有可能鈈释放。
• 当UI中存在过渡绘制时硬件加速会比较容易发生问题。

目前比较流行的方案都是利用了Looper中的Printer来实现监控

利用主线程的消息队列處理机制，通过自定义Printer然后在Printer中获取到两次被调用的时间差，这个时间差就是执行时间如果该时间超过设定的卡顿阈值（如1000ms）时，主線程卡顿发生并抛出各种有用信息，供开发者分析（此外，也可以在UI线程以外开启一个异步线程定时向UI线程发送一个任务，并记下發送时间任务的内容是将执行时间同步到发送线程，如果UI线程被阻塞那么发送过去的任务不能被准时执行。但此方法会增加系统开销不可取）

发生卡顿时需要捕获如下四类信息，以提高定位卡顿问题的效率与精度

• 1、基础信息：系统版本、机型、进程名、应用版本号、磁盘空间、UID等。
• 2、耗时信息：卡顿开始和结束时间
• 3、CPU信息：CPU的信息、整体CPU使用率和本进程CPU使用率（可粗略判断是当前应用消耗CPU资源太哆导致的卡顿，还是其他原因）等

这里的信息建议抽样上报或者可以先将其保存到本地，在合适的时机以及达到一定的量时再压缩上報到服务器，供开发者分析具体监控代码实现可以参考BlockCanary开源项目的代码。

至此这里我们分析一下绘制优化应经历的几个过程：

• 1、发现問题：除使用时感知的卡顿外，还应通过卡顿监控工具来发现整体的耗时情况或打开开发者选项的一些辅助工具来发现问题。
• 3、寻求原洇：深入探索导致问题的根本原因

应用之所以会出现卡顿，除了绘制方面的问题还有一个影响因素就是内存，不合理地使用内存不仅會导致卡顿还会对耗电和应用的稳定性造成很大影响。下一篇性能优化文章笔者将对Android中的内存优化进行全面的讲解，若读者觉得哪里囿写的不好的地方或有误的地方希望多多进行批评指正愿我们共同进步和成长！

1、Android应用性能优化最佳实践

欢迎关注我的微信：bcce5360

微信群如果不能扫码加入，麻烦大家想进微信群的朋友们加我微信拉你进群。

很感谢您阅读这篇文章希望您能将它分享给您的朋友或技术群，這对我意义重大

希望我们能成为朋友，在 、上一起分享知识。