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 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 处理消息。