fresco加载图片原理 优势是什么
缓存怎么处理的
a、根据Uri在已解码的（Bitmap缓存）内存缓存中查找，找到了则返回Bitmap对象；如果没找到，则开启后台线程开始后续的工作。
b、根据Uri在未解码的内存缓存中查找，若找到了则解码，然后缓存到已解码的内存缓存中，并且返回Bitmap对象。
d、如果在未解码的内存缓存中没找到，则根据Uri在磁盘缓存中查找，若找到了则读取数据（byte数组），并缓存到未解码的内存缓存中，解码、然后缓存到已解码的内存缓存中，并且返回Bitmap对象。
e、如果在磁盘缓存中没找到，则从网络或者本地加载数据。加载完成后，依次缓存到磁盘缓存、未解码的内存缓存中。解码、然后缓存到已解码的内存缓存中，并且返回Bitmap对象。
bitmap 内存分配
- 在4.x及以下的系统上，Fresco的bitmap decode会把bitmap的pixel data（像素数据）放到一个“特殊的内存区域’ ”，这个特殊的内存区域其实就是ashmem
- 为什么在4.x及以下系统需要这样做？原因是如果Bitmap数量很多时会占用大量的内存（这里内存特指Java Heap），必然就会更加频繁的触发虚拟机进行GC，GC 会导致stop the world
- 怎么实现的？
- BitmapFactory.Options 的参数 inPurgeable能使bitmap的内存分配到ashmem上。inPurgeable的作用是，在KITKAT及以下，使用该参数的话，当系统需要回收内存的时候，bitmap的pixels可以被清除。好在的是，当pixels需要被重新访问的时候（例如bitmap draw或者调用getPixels()的时候），它们又可以重新被decode出来
- isPurgeable为true的图片，内存分配的时机和流程，只有当bitmap进行draw或者getPixels（这个大抵一致）的时候，bitmap 的pixels才进行实际的内存分配
- bitmap draw的整个流程看，操作都处于UI线程，由于存在耗时的操作，会导致drop frames
- ART模式下，BitmapOptions的inBitmap和inTempStorage去优化内存使用。inBitmap是由上层的BitmapPool 去分配内存，inTempStorage是由 SynchronizedPool分配内存，都是用缓存池的方式分配和回收内存，做到对这些区域的内存可管理，减少各个不同地方自行分配内存 。
- 为啥使用 Ashmem
- Java Heap：大小受系统限制，内存自动回收。
- Native Heap：大小不受系统限制，仅受物理内存限制，内存需要手动释放。
- Ashmem：大小不受系统限制，仅受物理内存限制，系统在需要的时候可以自动回收，也可以手动阻止回收。
data binding
-
原理
- 将xml文件拆分成两部分，一部分是数据文件，一部分是布局文件，在布局文件中，为每个View设置一个tag，数据文件中，标示了相对应的tag的View所需要使用的数据
- 根据上面的两个xml在编译时生成 ActivityDataBindBinding和BR类
- 在 ActivityDataBindBinding 当中，会更加tag对每一个View进行赋值
- 根据上面的xml对数据进行绑定操作 (executeBindings方法)
- 数据的实时刷新
- 在进行set的方法时候，最终会调用到 executeBindings方法
Android中动画的原理
-
帧动画
- animation-list --> AnimationDrawable
- 容易oom
-
view动画
- a.getTransformation方法会返回一个布尔值，表示是否需要继续动画，一旦为true，则父控件会重新计算需要动画需要刷新的区域并且更新该区域。在动画结束之前会不断重绘，从而形成连续的动画效果。
- getTransformation 在这个方法中，根据流逝的时间计算当前动画时间百分比，然后通过插值器（Interpolator）重新计算这个百分比，并且以此来计算当前动画属性值
-
属性动画
- 属性动画是通过VSYNC信号来持续改变属性值进行动画的
- 相比于补间动画，属性动画重绘明显会少很多
- 流程 ObjectAnimator.ofFloat(button,"translationX",0,200);
- 首先会把我们传入的View保存起来
- 然后会初始化一个Holder对象，这个Holder对象是用来干啥的呢？我们传入了一个translationX值，Holder对象中提供一个方法，把translationX拼接成一个set方法，setTranslationX，然后通过反射找到View中的此方法。当数值计算出来之后，执行获取的这个方法。
- KeyframeSet是一个关键帧的集合，最后我们传入0-200就是关键帧
- 插值器，用来计算某一时间中动画长度播放的百分比
- 估值器，根据插值器计算的百分比，来计算某个时间，动画所要更新的值。然后交给Holder执行动画
- 属性动画会监听系统发出的VSYNC信号，每收到一次信号就执行一次
-
插值器和估值器
- 插值器：设置 属性值 从初始值过渡到结束值 的变化规律
- 估值器：设置 属性值 从初始值过渡到结束值 的变化具体数值
- 插值器只是根据时间百分比计算出一个属性值百分比，而把属性值百分比转换为真正属性值则交给估值器来做。例如：插值器返回的是一个百分比，估值器就可以将这个百分比转换成色值（0-255）或者一个坐标
touch事件分发
事件处理都是在 onTouchEvent 里面做的，这一点需要先理解，举个简单的例子，我点击一个按钮，有点击事件的回调，这个点击事件就是在onTouch里面处理的，所有的子View消费了这个事件，大致可以理解为，子View自己处理了touch事件，父View就别处理了，子View处理了点击事件，父View就别处理点击事件了
dispatchTouchEvent
事件分发
- Activity的dispatchTouchEvent方法,下面看一下伪代码：
public boolean dispatchTouchEvent(MotionEvent ev) {
if (child.dispatchTouchEvent(ev)) {
return true; //如果子View消费了该事件,则返回TRUE，让调用者知道该事件已被消费
} else {
return onTouchEvent(ev); //如果子View没有消费该事件，则调用自身的onTouchEvent尝试处理。
}
}
如果返回了true，就说明子View消费了这个事件，就不会调用 onTouchEvent 方法
- ViewGroud的dispatchTouchEvent方法
public boolean dispatchTouchEvent(MotionEvent ev) {
if (!onInterceptTouchEvent(ev)) {
return child.dispatchTouchEvent(ev); //不拦截，则传给子View进行分发处理
} else {
return onTouchEvent(ev); //拦截事件，交由自身对象的onTouchEvent方法处理
}
}
如果拦截了触摸事件，则就会调用自己的 onTouchEvent 方法，如果不拦截，就遍历自己子view,发现自己的符合某个条件，就调用子View的dispatchTouchEvent方法
- View的dispatchTouchEvent方法
public boolean dispatchTouchEvent(MotionEvent ev) {
//如果该对象的监听成员变量不为空，则会调用其onTouch方法，
if (mOnTouchListener != null && mOnTouchListener.onTouch(this, event)) {
return true; //若onTouch方法返回TRUE，则表示消费了该事件，则dispachtouTouchEvent返回TRUE，让其调用者知道该事件已被消费。
}
return onTouchEvent(ev); //若监听成员为空或onTouch没有消费该事件，则调用对象自身的onTouchEvent方法处理。
}
若listener的onTouch方法返回TRUE，则dispatchTouchEvent也会返回TRUE，表示消费该事件。不会调用onTouchEvent方法了
整体代码流程
///////////ViewGroup
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
...省略部分代码
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
//如果是DOWN事件,清除标记,恢复一些标记状态
if (actionMasked == MotionEvent.ACTION_DOWN) {
cancelAndClearTouchTargets(ev);
resetTouchState();
}
//判断是否拦截
final boolean intercepted;
//触发DOWN事件或者mFirstTouchTarget不是Null,才会走if里面的逻辑
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
// 子View可以通知父View，不要拦截
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else { // 不拦截
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
//不是DOWN事件 mFirstTouchTarget为空 拦截后续事件
intercepted = true;
}
...省略部分代码
final boolean canceled = resetCancelNextUpFlag(this)
|| actionMasked == MotionEvent.ACTION_CANCEL;
// Update list of touch targets for pointer down, if needed.
final boolean split = (mGroupFlags & FLAG_SPLIT_MOTION_EVENTS) != 0;
TouchTarget newTouchTarget = null;
boolean alreadyDispatchedToNewTouchTarget = false;
//事件没有被取消或者没有被拦截执行if中逻辑
if (!canceled && !intercepted) {
View childWithAccessibilityFocus = ev.isTargetAccessibilityFocus()
? findChildWithAccessibilityFocus() : null;
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
final int actionIndex = ev.getActionIndex(); // always 0 for down
final int idBitsToAssign = split ? 1 << ev.getPointerId(actionIndex)
: TouchTarget.ALL_POINTER_IDS;
// Clean up earlier touch targets for this pointer id in case they
// have become out of sync.
removePointersFromTouchTargets(idBitsToAssign);
final int childrenCount = mChildrenCount;
//
if (newTouchTarget == null && childrenCount != 0) {
final float x = ev.getX(actionIndex);
final float y = ev.getY(actionIndex);
// Find a child that can receive the event.
// 从前到后为View进行排序
final ArrayList<View> preorderedList = buildTouchDispatchChildList();
final boolean customOrder = preorderedList == null && isChildrenDrawingOrderEnabled();
final View[] children = mChildren;
// 遍历排序后的View，进入淘汰机制
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(preorderedList, children, childIndex);
...
//判断child是否可以响应事件 是否点击在了View的范围之内，如果不是的话，就不会进行下面的操作，也就不会有touch事件的调用
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
//获取上次响应事件的View,DOWN事件时候newTouchTarget为Null
newTouchTarget = getTouchTarget(child);
if (newTouchTarget != null) {
// Child is already receiving touch within its bounds.
// Give it the new pointer in addition to the ones it is handling.
newTouchTarget.pointerIdBits |= idBitsToAssign;
break;
}
resetCancelNextUpFlag(child);
//很重要的一个方法,在下面我们会看这个方法做了什么
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// 消费了这个事件，如果消费了这个事件。会为newTouchTarget赋值，mFirstTouchTarget赋值
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
if (preorderedList != null) {
// childIndex points into presorted list, find original index
for (int j = 0; j < childrenCount; j++) {
if (children[childIndex] == mChildren[j]) {
mLastTouchDownIndex = j;
break;
}
}
} else {
mLastTouchDownIndex = childIndex;
}
mLastTouchDownX = ev.getX();
mLastTouchDownY = ev.getY();
//在这个方法中把child赋值给了mFirstTouchTarget
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
}
ev.setTargetAccessibilityFocus(false);
}
if (preorderedList != null) preorderedList.clear();
}
...
}
}
// Dispatch to touch targets.
if (mFirstTouchTarget == null) { // 这里就标示没有要消费这个事件的View，如果没有，就调用自己的 dispatchTransformedTouchEvent 方法。这里的第三个参数为null
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,TouchTarget.ALL_POINTER_IDS);
} else {
// Dispatch to touch targets, excluding the new touch target if we already
// dispatched to it. Cancel touch targets if necessary.
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
handled = true;
} else {
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
// 这里调用子View的dispatch事件
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
if (cancelChild) {
if (predecessor == null) {
mFirstTouchTarget = next;
} else {
predecessor.next = next;
}
target.recycle();
target = next;
continue;
}
}
predecessor = target;
target = next;
}
}
...
}
...
return handled;
}
//最重要的几行代码的逻辑
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
...省略部分代码
// Perform any necessary transformations and dispatch.
//child为空调用父View的dispatchTouchEvent
if (child == null) {
handled = super.dispatchTouchEvent(transformedEvent);
} else {
...
//child不为空调用child的dispatchTouchEvent方法
handled = child.dispatchTouchEvent(transformedEvent);
}
...
return handled;
}
////////// ViewGroup
public boolean onInterceptTouchEvent(MotionEvent ev) {
if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
&& ev.getAction() == MotionEvent.ACTION_DOWN
&& ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
&& isOnScrollbarThumb(ev.getX(), ev.getY())) {
return true;
}
return false;
}
////////// View
public boolean dispatchTouchEvent(MotionEvent event) {
...
boolean result = false;
...
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
//noinspection SimplifiableIfStatement
ListenerInfo li = mListenerInfo;
//我们看到有mOnTouchListener,并且onTouch返回true,就没有onTouchEvent啥事了
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
if (!result && onTouchEvent(event)) {
result = true;
}
}
...
return result;
}
public boolean onTouchEvent(MotionEvent event) {
...
// 一点击的话，项目返回为true，自己消费事件
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
...
return true;
}
return false;
}
几点结论
- 跟踪一下down事件：所有的touch事件回调都会执行，所以down事件是都会接受到的
- 如果某个被点击的 textView 的 down 事件在onTouchEvent方法中返回了false，就会导致 dispatchTouchEvent 返回false，他的父类dispatchTransformedTouchEvent返回了false, mFirstTouchTarget==null，返回就会调用自己的onTouchEvent方法
- 如果 onInterceptTouchEvent 返回true，此时如果有后续事件过来，mFirstTouchTarget==null intercepted==true，这时候，就不会调用 dispatchTransformedTouchEvent 了，只会调用父类自己的 onTouchEvent方法
- 如果 disallowIntercept 为true，就不会调用 onInterceptTouchEvent 方法了
- 如果有设置TouchListener并且 mOnTouchListener.onTouch()返回的是 true，那么，onTouchEvent 将不会执行，所以onClick也不会执行
- cancel事件的触发：
- 当用户保持按下操作，并从你的控件转移到外层控件时，会触发ACTION_CANCEL
- 当前控件(子控件)收到前驱事件(ACTION_MOVE或者ACTION_MOVE)后，它的父控件突然插手，截断事件的传递，这时，当前控件就会收到ACTION_CANCEL
- 参考了一些资料 资料
ANR产生的原因
- 出现时机
- 输入事件(按键和触摸事件) 5s 内没被处理；
- BroadcastReceiver 的事件 ( onRecieve() 方法) 在规定时间内没处理完 (前台广播为 10s，后台广播为 60s)；
- Service 前台 20s 后台 200s 未完成启动；
- ContentProvider 的 publish() 在 10s 内没进行完。
- ANR 的分析方法
- 使用 adb 导出 ANR 日志并进行分析 traces.txt
- 使用 DDMS 的 traceview 进行分析
- 使用开源项目 ANR-WatchDog 来检測 ANR
- 常见的 ANR 场景
- I/O 阻塞
- 网络阻塞
- 多线程死锁
- 由于响应式编程等导致的方法死循环
- 由于某个业务逻辑执行的时间太长
- 避免 ANR 的方法
- UI 线程尽量只做跟 UI 相关的工作；
- 耗时的工作 (比如数据库操作，I/O，网络操作等)，采用单独的工作线程处理；
- 用 Handler 来处理 UI 线程和工作线程的交互；
- 使用 RxJava 等来处理异步消息。
- 总之，一个原则就是：不在主线程做耗时操作
SpareArray
底层是两条数组，一组存放key，一组存放value
于hashMap相比：使用int[]数组存放key，避免了HashMap中基本数据类型需要装箱的步骤，其次不使用额外的结构体（Entry)，单个元素的存储成本下降。
-
插入过程
- 存放keys的数组是有序的，在put的时候是通过二分查找找到的index
- 如果冲突，新值直接覆盖原值，并且不会返回原值
- 如果当前要插入的 key 的索引上的值为DELETE，直接覆盖，例如：mKeys中并没有 3 这个值，但是通过二分查找得出来，目前应该插入的索引位置为 2 ，但是此时index=2的位置上的key=4，而当前这个位置上对应的value标记为DELETED了，所以会直接将该位置上的key赋值为 3 ，并且将该位置上的value赋值为put()传入的对象。
- 前几步都失败了，检查是否需要gc()并且在该索引上插入数据，例如：数组已经满容量了，而且 3 应该插入的位置已经有 4 了，而 5 所指向的值为DELETED，这种情况下，会先去回收DELETED,重新调整数组结构,然后再重新计算 3 应该插入的位置
- 如果上面几部都无法插入，此时就可以扩容了
remove操作其实是将对应的value值设置为了一个固定的值DELETE，key仍然保存在数组中，目的应该是为了保持索引结构，同时不会频繁压缩数组，保证索引查询不会错位
gc 删除无用的key
-
优势：
- 避免了基本数据类型的装箱操作
- 不需要额外的结构体，单个元素的存储成本更低
- 数据量小的情况下，随机访问的效率更高
-
缺点
- 插入操作需要复制数组，增删效率降低
- 数据量巨大时，复制数组成本巨大，gc()成本也巨大
- 数据量巨大时，查询效率也会明显下降
Eventbus
- 整体流程
- 注册
- 通过反射或者注解的方式，或者订阅者所有的订阅方法
- 将当前订阅者添加到EventBus总的事件订阅者集合中
- 将当前订阅者所有订阅的事件类型添加到typeBySubscriber中
- 发送
- 得到要发送事件的类型
- 根据事件类型获取所有订阅者，循环向每个订阅者发送消息
- 反注册
- 通过typeBySubscriber获取当前订阅者所有的事件类型
- 循环遍历每一个事件类型，并删除当前订阅者的订阅方法
- 注册
- 关于订阅方法
- 允许一个类有多个参数相同的订阅方法。
- 子类继承并重写了父类的订阅方法，那么只会把子类的订阅方法添加到订阅者列表，父类的方法会忽略。
// 子类调用的时候 methodClassOld 为空，
// 父类的时候 methodClassOld(此时为子类)不为空，并且methodClassOld.isAssignableFrom(methodClass)为false,此时返回为false，并且 subscriberClassByMethodKey 里面为子类
Class<?> methodClassOld = subscriberClassByMethodKey.put(methodKey, methodClass);
if (methodClassOld == null || methodClassOld.isAssignableFrom(methodClass)) {
// Only add if not already found in a sub class
return true;
} else {
// Revert the put, old class is further down the class hierarchy
subscriberClassByMethodKey.put(methodKey, methodClassOld);
return false;
}
-
post一个事件
- 如果事件继承自父类，那么父类也会作为事件被发送
- 粘性事件：先发送出去，然后让后面注册的订阅者能够收到该事件，在注册的时候有对粘性事件的处理
- 如何进行线程切换的？
- 主线程：通过HandlerPoster, HandlerPoster 继承自 Handler,该handler内部有一个PendingPostQueue，这是一个队列，保存了PendingPost，即待发送的post，该PendingPost封装了event和subscription，通过sendMessage来发送处理消息
- 子线程：通过BackgroundPoster，BackgroundPoster继承自Runnable，内部有PendingPostQueue这个队列，通过eventBus.getExecutorService().execute(this);来处理方法的调用
- 异步线程，AsyncPoster，是一个Runnable，实现原理与BackgroundPoster大致相同，它内部不用判断之前是否已经有一条线程已经在运行了，它每次post事件都会使用新的一条线程。
-
优缺点
- 优点：独立出一个发布订阅模块，调用者可以通过使用这个模块，屏蔽一些线程切换问题，简单地实现发布订阅功能
- 缺点：大量的滥用，将导致逻辑的分散，出现问题后很难定位。代码可读性差
Handler
-
Handler Looper MessageQueue
- Looper ：负责关联线程以及消息的分发在该线程下**从 MessageQueue 获取 Message，分发给 Handler ；
- MessageQueue ：是个队列，负责消息的存储与管理，负责管理由 Handler 发送过来的 Message ；
- Handler : 负责发送并处理消息，面向开发者，提供 API，并隐藏背后实现的细节。
-
postDelayed的原理
- 1.消息是通过MessageQueen中的enqueueMessage()方法加入消息队列中的，并且它在放入中就进行好排序，链表头的延迟时间小，尾部延迟时间最大
- 2.Looper.loop()通过MessageQueue中的next()去取消息
- 3.next()中如果当前链表头部消息是延迟消息，则根据延迟时间进行消息队列会阻塞，不返回给Looper message，知道时间到了，返回给message
- 4.如果在阻塞中有新的消息插入到链表头部则唤醒线程
- 5.Looper将新消息交给回调给handler中的handleMessage后，继续调用MessageQueen的next()方法，如果刚刚的延迟消息还是时间未到，则计算时间继续阻塞
-
为什么不允许在子线程中访问UI
- 因为Android的UI控件并不是线程安全的,如果多线程中并发访问可能导致UI控件处于不可预期的状态。加锁可不可以呢？加上锁机制会让UI访问的逻辑变得复杂;其次锁机制会降低UI访问的效率,因为锁机制会阻塞某些线程的执行.
-
Looper.myLooper() 是如何获取到当前线程的Looper的？
- myLooper()内部使用ThreadLocal实现，因此能够获取各个线程自己的Looper
-
MessageQueue中底层是采用的队列
- 采用单链表的数据结构来维护消息队列，而不是采用队列
-
MessageQueue.next() 会因为发现了延迟消息，而进行阻塞。那么为什么后面加入的非延迟消息没有被阻塞呢？
- 调用 MessageQueue.next() 方法的时候会调用 Native 层的 nativePollOnce() 方法进行精准时间的阻塞。在 Native 层，将进入 pullInner() 方法，使用 epoll_wait 阻塞等待以读取管道的通知。如果没有从 Native 层得到消息，那么这个方法就不会返回。此时主线程会释放 CPU 资源进入休眠状态。
- 当我们加入消息的时候，会调用 MessageQueue.enqueueMessage() 方法，添加完 Message 后，如果消息队列被阻塞，则会调用 Native 层的 nativeWake() 方法去唤醒。它通过向管道中写入一个消息，结束上述阻塞，触发上面提到的 nativePollOnce() 方法返回，好让加入的 Message 得到分发处理。
-
Handler 的 dispatchMessage() 分发消息的处理流程？
- 使用 Handler 的时候我们会覆写 Handler 的 handleMessage() 方法。当我们调用该 Handler 的 send() 或者 post() 发送一个消息的时候，发送的信息会被包装成 Message，并且将该 Message 的 target 指向当前 Handler，这个消息会被放进 Looper 的 MQ 中。然后在 Looper 的循环中，取出这个 Message，并调用它的 target Handler，也就是我们定义的 Handler 的 dispatchMessage() 方法处理消息，此时会调用到 Handler 的 handleMessage() 方法处理消息，并回调 Callback.
-
Looper 中的 quit() 和 quitSafely() 有什么区别
- quit() 和 quitSafely() 的本质就是让消息队列的 next() 返回 null，以此来退出Looper.loop()。
- quit() 调用后直接终止 Looper，不在处理任何 Message，所有尝试把 Message 放进消息队列的操作都会失败，比如 Handler.sendMessage() 会返回 false，但是存在不安全性，因为有可能有 Message 还在消息队列中没来的及处理就终止 Looper 了。
- quitSafely() 调用后会在所有消息都处理后再终止 Looper，所有尝试把 Message 放进消息队列的操作也都会失败。
-
Looper.loop() 在什么情况下会退出？
- next() 方法返回的 msg == null；2) 线程意外终止。
-
如何保证一个线程最多只能有一个 Looper？如何保证只有一个 MessageQueue
- 通过保证只有一个 Looper 来保证只有以一个 MQ. 在一个线程中使用 Handler 之前需要使用 Looper.prepare() 创建 Looper，它会从 ThreadLocal 中获取，如果发现 ThreadLocal 中已经存在 Looper，就抛异常。
-
一个 Looper 是如何区分多个 Handler 的？
- Looper 不会区分 Handler，每个 Handler 会被添加到 Message 的 target 字段上面，Looper 通过调用 Message.target.handleMessage() 来让 Handler 处理消息。
