1.简述handler的实现原理
android 应用是通过消息驱动运行的，在 android 中一切皆消息，包括触摸事件，视图的绘制、显示和刷新等等都是消息。handler 是消息机制的上层接口，平时开发中我们只会接触到 handler 和 message，内部还有 messagequeue 和 looper 两大助手共同实现消息循环系统。
（1）handler 通过handler的sendxxx或者postxxx来发送一个消息，这里要注意post(runnable r)方法也会将runnable包装成一个message，代码如下：
public final boolean post(runnable r){
return sendmessagedelayed(getpostmessage(r), 0);
}
public final boolean postdelayed(runnable r, long delaymillis){
return sendmessagedelayed(getpostmessage(r), delaymillis);
}
private static message getpostmessage(runnable r) {
message m = message.obtain();
m.callback = r;
return m;
}
从代码中可以看到将runnable赋值给了message.callback了。最终sendxxx和postxxx都会调用到sendmessageattime，代码如下：
public boolean sendmessageattime(message msg, long uptimemillis) {
messagequeue queue = mqueue;
if (queue == null) {
runtimeexception e = new runtimeexception(
this " sendmessageattime() called with no mqueue");
log.w("looper", e.getmessage(), e);
return false;
}
return enqueuemessage(queue, msg, uptimemillis);
}
在这个方法中最终调用了enqueuemessage方法，这里注意将this赋值给了message.target，而此处this就是handler。
private boolean enqueuemessage(messagequeue queue, message msg, long uptimemillis) {
msg.target = this;
if (masynchronous) {
msg.setasynchronous(true);
}
//转到 messagequeue 的 enqueuemessage 方法
return queue.enqueuemessage(msg, uptimemillis);
}
enqueuemessage方法最终调用了messagequeue的enqueuemessage方法，将消息放入队列。 （2）messagequeue messagequeue是一个优先级队列，核心方法是enqueuemessage和next方法，也就是将插入队列，将消息取出队列的操作。 之所以说messagequeue是一个优先级队列是因为enqueuemessage方法中会根据message的执行时间来对消息插入，这样越晚执行的消息会被插入到队列的后边。
而next方法是一个死循环，如果队列中有消息，则next方法会将message移除队列并返回该message，如果队列中没有消息该方法则会处于阻塞状态。
（3）looper looper可以理解为一个消息泵，looper的核心方法是loop。注意loop方法的第一行会首先通过mylooper来得到当前线程的looper,接着拿到looper中的messagequeue，然后开启一个死循环，它会不断的通过messagequeue的next方法将消息取出来，并执行。代码如下：
public static void loop() {
final looper me = mylooper();// 这里要特别注意，是从threadlocal中拿到当前线程的looper。
if (me == null) {
throw new runtimeexception("no looper; looper.prepare() wasn't called on this thread.");
}
final messagequeue queue = me.mqueue;
for (;;) {
//从 messagequeue 中取消息
message msg = queue.next(); // might block
if (msg == null) {
// no message indicates that the message queue is quitting.
return;
}
//通过 handler 分发消息
msg.target.dispatchmessage(msg);
//回收消息
msg.recycleunchecked();
}
}
可以看到在取出message后则会调用message.target调用dispatchmessage方法，这里target就是handler，它是在handler的enqueuemessage时赋值的。紧接着将message进行了回收。 接下来再回到handler看dispatchmessage，代码如下：
public void dispatchmessage(message msg) {
if (msg.callback != null) {
//通过 handler.postxxx 形式传入的 runnable
handlecallback(msg);
} else {
if (mcallback != null) {
//以 handler(handler.callback) 写法
if (mcallback.handlemessage(msg)) {
return;
}
}
//以 handler(){} 内存泄露写法
handlemessage(msg);
}
}
2.一个线程有几个handler？一个线程有几个looper？如何保证？
handler的个数与所在线程无关，可以在线程中实例化任意多个handler。一个线程中只有一个looper。looper的构造方法被声明为了private，我们无法通过new关键字来实例化looper，唯一开放的可以实例化looper的方法是prepare。prepare方法的源码如下：
public static void prepare() {
prepare(true);
}
private static void prepare(boolean quitallowed) {
if (sthreadlocal.get() != null) {
throw new runtimeexception("only one looper may be created per thread");
}
sthreadlocal.set(new looper(quitallowed));
}
我们知道threadlocal是一个线程内部的数据存储类，当某个线程调用prepare方法的时候，会首先通过threadlocal检查这个线程是否已经创建了looper,如果还没创建，则实例化looper并将实例化后的looper保存到threadlocal中，而如果threadlocal中已经保存了looper，则会抛出一个runtimeexception的异常。那么意味着在一个线程中最多只能调用一次prepare方法，这样就保证了looper的唯一性。
3.handler线程是如何切换的？
（1）假设现在有一个线程a，在a线程中通过looper.prepare和looper.loop来开启looper,并且在a线程中实例化出来一个handler。looper.prepare()方法被调用时会为会初始化looper并为threadlocal 设置looper，此时threadlocal中就存储了a线程的looper。另外messagequeue也会在looper中被初始化。
（2）接着当调用loop.loop方法时，loop方法会通过mylooper得到a线程中的looper，进而拿到looper中的messagequeue，接着开启死循环等待执行messagequeue中的方法。 （3）此时，再开启一个线程b，并在b线程中通过handler发送出一个message，这个message最终会通过sendmessageattime方法调用到messagequeue的equeuemessage方法将消息插入到队列。
（3）由于looper的loop是一个死循环，当messagequeue中被插入消息的时候，loop方法就会取出messagequeue中的消息，并执行callback。而此时，looper是a线程的looper,进而调用的message或者handler的callback都是执行在a线成中的。以此达到了线程的切换。
4.handler内存泄漏的原因是什么？如何解决?
通常在使用handler的时候回通过匿名内部类的方式来实例化handler，而非静态的匿名内部类默认持有外部类的引用，即匿名内部类handler持有了外部类。而导致内存泄漏的根本原因是是因为handler的生命周期与宿主的生命周期不一致。
比如说在activity中实例化了一个非静态的匿名内部类handler，然后通过handler发送了一个延迟消息，但是在消息还未执行时结束了activity，此时由于handler持有activity，就会导致activity无法被gc回收，也就是出现了内存泄漏的问题。
解决方式：可以把handler声明为静态的匿名内部类，但这样一来，在handler内部就没办法调用到activity中的非静态方法或变量。那么最终的凯发娱发k8的解决方案可以使用静态内部类 弱引用来解决。代码如下：
public class mainactivity extends appcompatactivity {
private myhandler mmyhandler = new myhandler(this);
@override
protected void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
setcontentview(r.layout.activity_main);
}
private void handlemessage(message msg) {
}
static class myhandler extends handler {
private weakreference mreference;
myhandler(activity reference) {
mreference = new weakreference<>(reference);
}
@override
public void handlemessage(message msg) {
mainactivity activity = (mainactivity) mreference.get();
if (activity != null) {
activity.handlemessage(msg);
}
}
}
@override
protected void ondestroy() {
mmyhandler.removecallbacksandmessages(null);
super.ondestroy();
}
}
5.主线程为什么不用初始化looper？
答：因为应用在启动的过程中就已经初始化主线程looper了。
每个java应用程序都是有一个main方法入口，android是基于java的程序也不例外。android程序的入口在activitythread的main方法中：
public static void main(string[] args) {
...
// 初始化主线程looper
looper.preparemainlooper();
...
// 新建一个activitythread对象
activitythread thread = new activitythread();
thread.attach(false, startseq);
// 获取activitythread的handler，也是他的内部类h
if (smainthreadhandler == null) {
smainthreadhandler = thread.gethandler();
}
...
looper.loop();
// 如果loop方法结束则抛出异常，程序结束
throw new runtimeexception("main thread loop unexpectedly exited");
}
main方法中先初始化主线程looper，新建activitythread对象，然后再启动looper，这样主线程的looper在程序启动的时候就跑起来了。我们不需要再去初始化主线程looper。
6.handler如何保证messagequeue并发访问安全？
答：循环加锁，配合阻塞唤醒机制。
我们可以发现messagequeue其实是“生产者-消费者”模型，handler不断地放入消息，looper不断地取出，这就涉及到死锁问题。如果looper拿到锁，但是队列中没有消息，就会一直等待，而handler需要把消息放进去，锁却被looper拿着无法入队，这就造成了死锁。handler机制的解决方法是循环加锁。在messagequeue的next方法中：
message next() {
...
for (;;) {
...
nativepollonce(ptr, nextpolltimeoutmillis);
synchronized (this) {
...
}
}
}
我们可以看到他的等待是在锁外的，当队列中没有消息的时候，他会先释放锁，再进行等待，直到被唤醒。这样就不会造成死锁问题了。
那在入队的时候会不会因为队列已经满了然后一边在等待消息处理一边拿着锁呢？这一点不同的是messagequeue的消息没有上限，或者说他的上限就是jvm给程序分配的内存，如果超出内存会抛出异常，但一般情况下是不会的。
7.handler的阻塞唤醒机制是怎么回事？
答： handler的阻塞唤醒机制是基于linux的阻塞唤醒机制。
这个机制也是类似于handler机制的模式。在本地创建一个文件描述符，然后需要等待的一方则监听这个文件描述符，唤醒的一方只需要修改这个文件，那么等待的一方就会收到文件从而打破唤醒。和looper监听messagequeue，handler添加message是比较类似的。
8.能不能让一个message加急被处理？/ 什么是handler同步屏障？
答：可以 / 一种使得异步消息可以被更快处理的机制
如果向主线程发送了一个ui更新的操作message，而此时消息队列中的消息非常多，那么这个message的处理就会变得缓慢，造成界面卡顿。所以通过同步屏障，可以使得ui绘制的message更快被执行。
什么是同步屏障？这个“屏障”其实是一个message，插入在messagequeue的链表头，且其target==null。message入队的时候不是判断了target不能为null吗？不不不，添加同步屏障是另一个方法：
public int postsyncbarrier() {
return postsyncbarrier(systemclock.uptimemillis());
}
private int postsyncbarrier(long when) {
synchronized (this) {
final int token = mnextbarriertoken ;
final message msg = message.obtain();
msg.markinuse();
msg.when = when;
msg.arg1 = token;
message prev = null;
message p = mmessages;
// 把当前需要执行的message全部执行
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
// 插入同步屏障
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mmessages = msg;
}
return token;
}
}
可以看到同步屏障就是一个特殊的target，哪里特殊呢？target==null，我们可以看到他并没有给target属性赋值。那这个target有什么用呢？看next方法：
message next() {
...
// 阻塞时间
int nextpolltimeoutmillis = 0;
for (;;) {
...
// 阻塞对应时间
nativepollonce(ptr, nextpolltimeoutmillis);
// 对messagequeue进行加锁，保证线程安全
synchronized (this) {
final long now = systemclock.uptimemillis();
message prevmsg = null;
message msg = mmessages;
/**
* 1
*/
if (msg != null && msg.target == null) {
// 同步屏障，找到下一个异步消息
do {
prevmsg = msg;
msg = msg.next;
} while (msg != null && !msg.isasynchronous());
}
if (msg != null) {
if (now < msg.when) {
// 下一个消息还没开始，等待两者的时间差
nextpolltimeoutmillis = (int) math.min(msg.when - now, integer.max_value);
} else {
// 获得消息且现在要执行，标记messagequeue为非阻塞
mblocked = false;
/**
* 2
*/
// 一般只有异步消息才会从中间拿走消息，同步消息都是从链表头获取
if (prevmsg != null) {
prevmsg.next = msg.next;
} else {
mmessages = msg.next;
}
msg.next = null;
msg.markinuse();
return msg;
}
} else {
// 没有消息，进入阻塞状态
nextpolltimeoutmillis = -1;
}
// 当调用looper.quitsafely()时候执行完所有的消息后就会退出
if (mquitting) {
dispose();
return null;
}
...
}
...
}
}
这个方法我在前面讲过，我们重点看一下关于同步屏障的部分，看注释1的地方的代码：
if (msg != null && msg.target == null) {
// 同步屏障，找到下一个异步消息
do {
prevmsg = msg;
msg = msg.next;
} while (msg != null && !msg.isasynchronous());
}
如果遇到同步屏障，那么会循环遍历整个链表找到标记为异步消息的message，即isasynchronous返回true，其他的消息会直接忽视，那么这样异步消息，就会提前被执行了。注释2的代码注意一下就可以了。
注意，同步屏障不会自动移除，使用完成之后需要手动进行移除，不然会造成同步消息无法被处理。从源码中可以看到如果不移除同步屏障，那么他会一直在那里，这样同步消息就永远无法被执行了。
有了同步屏障，那么唤醒的判断条件就必须再加一个：messagequeue中有同步屏障且处于阻塞中，此时插入在所有异步消息前插入新的异步消息。这个也很好理解，跟同步消息是一样的。如果把所有的同步消息先忽视，就是插入新的链表头且队列处于阻塞状态，这个时候就需要被唤醒了。看一下源码：
boolean enqueuemessage(message msg, long when) {
...
// 对messagequeue进行加锁
synchronized (this) {
...
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mmessages = msg;
needwake = mblocked;
} else {
/**
* 1
*/
// 当线程被阻塞，且目前有同步屏障，且入队的消息是异步消息
needwake = mblocked && p.target == null && msg.isasynchronous();
message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
/**
* 2
*/
// 如果找到一个异步消息，说明前面有延迟的异步消息需要被处理，不需要被唤醒
if (needwake && p.isasynchronous()) {
needwake = false;
}
}
msg.next = p;
prev.next = msg;
}
// 如果需要则唤醒队列
if (needwake) {
nativewake(mptr);
}
}
return true;
}
同样，这个方法我之前讲过，把无关同步屏障的代码忽视，看到注释1处的代码。如果插入的消息是异步消息，且有同步屏障，同时messagequeue正处于阻塞状态，那么就需要唤醒。而如果这个异步消息的插入位置不是所有异步消息之前，那么不需要唤醒，如注释2。
那我们如何发送一个异步类型的消息呢？有两种办法：
使用异步类型的handler发送的全部message都是异步的
给message标志异步
handler有一系列带boolean类型的参数的构造器，这个参数就是决定是否是异步handler：
public handler(@nonnull looper looper, @nullable callback callback, boolean async) {
mlooper = looper;
mqueue = looper.mqueue;
mcallback = callback;
// 这里赋值
masynchronous = async;
}
但是异步类型的handler构造器是标记为hide，我们无法使用，所以我们使用异步消息只有通过给message设置异步标志：
public void setasynchronous(boolean async) {
if (async) {
flags |= flag_asynchronous;
} else {
flags &= ~flag_asynchronous;
}
}
但是！！！！ ，其实同步屏障对于我们的日常使用的话其实是没有多大用处。因为设置同步屏障和创建异步handler的方法都是标志为hide，说明谷歌不想要我们去使用他。所以这里同步屏障也作为一个了解，可以更加全面地理解源码中的内容。
android面试的风向已经变了！
以前，你只要了解四大组件、视图、网络请求，你就能拿到一份薪资丰厚的offer；如果你精通java基础、知道如何处理oom、组件生命周期原理、熟悉android源码、架构体系，进阿里腾讯可能都很轻松。
现在面试是越来越难了！别说阿里、头条、腾讯等大厂，就连很多中小型公司面试问的都是原理。
为了帮助大家深入理解framework源码，分享给大家一份知乎高赞的笔记《android framework精编内核解析》。
本笔记讲解了framework的主要模块，从环境的部署到技术的应用，再到项目实战，让我们不仅是学习框架技术的使用，而且可以学习到使用架构如何解决实际的问题，由浅入深，详细解析framework，让你简单高效学完这块知识！
第一章：深入解析binder
binder机制作为进程间通信的一种手段，基本上贯穿了andorid框架层的全部。所以首先必须要搞懂的android binder的基本通信机制。
本章知识点
binder 系列—开篇
binder driver 初探
binder driver 再探
binder 启动 servicemanager
获取 servicemanager
注册服务(addservice)
获取服务(getservice)
framework 层分析
如何使用 binder
如何使用 aidl
binder 总结
binder 全解析
……
第二章：深入解析handler
本章先宏观理论分析与 message 源码分析，再到messagequeue 的源码分析，looper 的源码分析，handler 的源码分析，handler 机制实现原理总结。最后还整理handler 所有面试题大全解析。
第三章：dalvik vm 进程系统
andorid系统启动、init 进程、zygote、systemserver启动流程、 应用程序的创建使用，activity的创建、销毁 handler和looper。
第四章 深入解析 wms
窗口管理框架 系统动画框架 view的工作原理。
第五章 packagermanagerservice
包管理服务，资源管理相关类
需要的朋友只需要 点赞支持一下 后，然后【点击这里免费获取】
android开发之路并不简单，我们要学的东西不仅仅只有表面的技术，还要深入底层，弄明白下面的原理，只有这样，我们才能够提高自己的竞争力，在当今这个竞争激烈的世界里立足，才能突破瓶颈走的更长更远！
