android中handler机制

㈠ android面试必问handler机制浅析

Handler是Android中的异步消息处理机制。当发送一个消息之后，这个消息是进入一个消息队列（MessageQueue），在消息队列中通过Looper去循环的获取队列中的消息，然后将消息分派给对应的处理者进行处理。

Message：存储需要处理操作的信息

MessageQueue：先进先出，存储handler发送过来的消息

Looper：循环器，它是消息队列和handler的通信媒介，1：循环的取出消息队列中的消息；2：将取出的消息发送给对应的处理者

Handler：主线程和子线程的通信媒介，1:添加消息到消息队列； 2:处理循环器分派过来的消息

在handler机制中，Looper.loop方法会不断循环获取Message， 其中的消息的获取是通过调用MessageQueue的next()方法获取的，而该方法会调用nativePollOnce()方法 ，这是一个native方法。底层的实现涉及到Linux pipe/epoll机制,nativePollOnce()被阻塞时,主线程会释放CPU资源,进入休眠状态. 直到下个消息到达或者有事务发生,会通过pipe管道写端写入数据来唤醒looper工作。

Android6.0及以前的版本使用管道与epoll来完成Looper的休眠与唤醒的

Android6.0及以后的版本使用eventfd与epoll来完成Looper的休眠与唤醒的

如果不处理的话，会阻塞线程，处理方案是调用Looper的quit()（清空所有的延迟和非延迟的消息）和quitSafely()（只清空延迟消息）衡冲； 这个方法会调用MessageQueue的quit()方法，清空所有的Message，并调用nativeWake()方法唤醒之前被阻塞的nativePollOnce()，使得方法next()方法中的for循环继续执行，接下来发现Message为null后就会结束循环，Looper结束。如此便可以释放内存和线程

同进程线程间内存共享，通过咐和歼handler通信，消息的内容是不需要从一个线程拷贝到另一个线程，因为两个线程间可使用的内存是同一个区域。（注意：线程私有区域ThreadLocal）

管道的作用就是当一个线程准备好Message，并放入消息池，这时需要通知了一个线程B去处理这个消息。线程A向管道的写端写入数据，管道有数据便会唤醒线程B去处理消息。管道的作用是用于通知另一个线程的，这便是最核心的作用。

从内存角度，通信过程中binder涉及到一次内存拷贝，handler机制中的Message根本不需要拷贝，本身就是在同一片内存。

从CPU角度，为了Binder通信底层驱动还需要创建一个binder线程池，每次通信涉及binder线程的创建和内存的分配等比较浪费CPU资源

原因：handler发送的消息在当前handler的消息队列中，如果此时activity被finish掉了，那么消息队列的消息依旧由handler进行处理，若此时handler申明为内存类（非静态内部类），内部类持有外部类的实例引用，这样在GC垃圾回收时发现Activity还有其他引用存在，因而就不会去回首这个Activity，进而棚物导致Activity泄漏。

方法：使用静态内部类，并且使用WeakReference包裹外部类的对象。首先静态内部类不持有外部类的引用，使用静态的handler不会导致activity的泄漏，handler定义static的同时，还要用WeakReference包裹外部类的对象。

㈡ [Android]View的Handler机制

有一定开发经验，大家应该对Handler的机制有非常深刻的了解，Handler在Android开发中被广泛用于线程间通信。
近来遇到了一个问题，在view init的情况下使用view自身的handler会崩溃，但是直接使用postDelay却指嫌能正常运行。
这里需要思考几个问题
1.view的handler是从哪里来的呢？
2.view的handler为何会崩溃？
3.View的post的运行机制是？
读了这篇文章，你就能理解到这些问题

可以看到是handler是从mAttachInfo过来的.

在dispatchAttachedToWindow的时候来传递过来，而viewgroup中触发这个传递操作。
这里最终会在ViewRootImpl中创建出来AttachInfo对象。
而handler是来自于自定义的ViewRootHandler，那就可以知道，整个Activity的View系统共用一个Handler是由ViewRootImpl创建，用于处理页面视图事件等处理。

dispatchAttachedToWindow是在View调用init初始化之后的，handler还没有被初始化，所以就导致handler返回null对唯举手象出外，答脊如果不判空就会崩溃了。

可以看到当mAttachInfo未初始化的时候，会先将runnable塞到一个队列当中。

当view被绑定到窗口的时候，会将队列和handler绑定，然后启动队列任务

㈢ Android的handler机制的原理

Android的handler机制的原理分为异步通信准备，消息发送，消息循环，消息处理。

1、异步通信准备

在主线程中创建处理器对象(Looper)、消息队列对象(Message Queue)和Handler对象。

2、消息入队

工作线程通过Handler发送消息(Message) 到消息队列(Message Queue)中。

3、消息循环

消息出队: Looper循环取出消息队列(Message Queue) 中的的消息(Message)。

消息分发: Looper将取出的消息 (Message) 发送给创建该消息的处理者(Handler)。

4、消息处理

处理者(Handler) 接收处理器(Looper) 发送过来的消息(Message)，根据消息(Message) 进行U操作。

handler的作用

handler是android线程之间的消息机制，主要的作用是将一个任务切换到指定的线程中去执行，（准确的说是切换到构成handler的looper所在的线程中去出处理）android系统中的一个例子就是主线程中的所有操作都是通过主线程中的handler去处理的。

Handler的运行需要底层的 messagequeue和 looper做支撑。

㈣ 消息机制

Android的消息机制是指Handler的运行机制以及Handler所附带的MessageQueue和Looper的工作过程。Handler的主要作用是将一个任务切换到某个指定的线程中去执行。
Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常。

主线程即UI线程，它就是ActivityThread，ActivityThread被创建时就会初始化Looper，这也是主线程中默认可以使用Handler的原因。

1.Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，Handler通过ThreadLocal来获取当前线程的Looper，ThreadLocal作用是可以在每个线程中存储数据；
2.Handler创建完毕后，这个时候其内部的Looper以及MessageQueue就可以和Handler一起协同工作了，通过Handler的post方法将一个Runnable投递到Handler内部的Looper中去处理，也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中处理；
3.当Handler的send方法被调用时，它会调用MessageQueue的enqueueMessage方法将这个消息放入消息队列，Looper发现有新消息到来时，就会处理这个消息，最终消息中的Runnable或者Handler的handleMessage方法就会被调用。
4.Looper是运行在创建Handler所在的线程中，这样Handler中的业务逻辑会被切换到创建Handler所在的线程中去执行了。

ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储之后，只有在指定线程中可以获取到存储的数据，对于其他线程来说则无法获取到数据。
使用场景：android源码中会使用如Looper，ActivityThread，AMS中都手宽消用到了ThreadLocal还有就是复杂逻辑下的对象传递，比毕知如监听器的传递。

MessageQueue主要包含两个操作，插入和读取分别对应enqueueMessage
和next，enqueueMessage的作用是往消息队列中插入一条消息，而next的作用是从消息队列中取出一条消息并将其从消息队列中移除。它是通过一个单链表的数据结构来维护消息列表。

消息循环，它会不停地从MessageQueue中查看是否有新消息，如果有新消息就会立刻处理，否则就一直阻塞在那里。
通过Looper.prepare()即可以为当前线程创建一个Looper，接着通过Looper.loop()来开启消息循环。

Looper除了prepare方法外，还提供了prepareMainLooper方法，这个方法主要是给主线程也就是ActivityThread创建Looper使用的，其本质也是通过prepare方法来实现的。Looper提供了getMainLooper方法，通过它可以在任何地方获取到主线程的Looper，Looper也可以退出，提供了quit和quitSafely方法。
Looper的loop方法是一个死循环，唯一跳出循环的方式是MessageQueue的next方法返回了null；当Looper的quit方法被调用时，Looper就会调用MessageQueue的quit或者quitSafely方法来通知消息队列退出，当消息队列被标记为退出状态时，它的next方法就会返回null。
loop方法会调用MessageQueue的next方法来获取新消息，而next是一个阻塞操作，当没有消息时，next方法会一直阻塞在那，这也导致了loop方法一直阻塞在那。

Android的主线程就是ActivityThread，主线程的入口方法为main，在main方法中系统会通过Looper.prepareMainLooper()来创建主线程的Looper以及MessageQueue，并通过Looper.loop()来开启主线程的消息循环。
主线程的消巧埋息循环开始了以后，ActivityThread还需要一个Handler来和消息队列进行交互，这个Handler就是ActivityThread.H,它内部定义了一组消息类型，主要包括了四大组件的启动和停止过程。
ActivityThread通过ApplicationThread和AMS进行进程间通信，AMS以进程间通信的方式完成ActivityThread的请求后会回调ApplicationThread中的Binder方法，然后ApplicationThread会向H发送
消息，H接收消息后会将ApplicationThread中的逻辑切换到ActivityThread中去执行，即切换到主线程中去执行，这个过程就是主线程的消息循环模型。

在子线程执行完耗时操作，Handler通过sendMessage发送消息后，会调用MessageQueue.enqueueMessage方法向消息队列中添加消息，然后Looper调用loop()方法开启循环后会不断地从消息队列中读取消息，然后调用目标Handler的dispatchMessage方法传递消息，然后回到Handler所在线程，目标Handler收到消息，调用handleMessage方法，接收消息，处理消息。

每个线程中只能存在一个Looper，Looper是保存在ThreadLocal中的。主线程（UI线程）已经创建了一个Looper，所以在主线程中不需要再创建Looper，但是在其他线程中需要创建Looper。每个线程中可以有多个Handler，即一个Looper可以处理来自多个Handler的消息。 Looper中维护一个MessageQueue，来维护消息队列，消息队列中的Message可以来自不同的Handler。

㈤ [Android源码分析] － 异步通信Handler机制

一、问题：在Android启动后会在新进程里创建一个主线程，也叫UI线程（ 非线程安全 ）这个线程主要负责监听屏幕点击事件与界面绘制。当Application需要进行耗时操作如网络请求等，如直接在主线程进行容易发生ANR错误。所以会创建子线程来执行耗时任务，当子线程执行完毕需要通知UI线程并修改界面时，不可以直接在子线程修改UI，怎么办？

解决方法：Message Queue机制可以实现子线程与UI线程的通信。

该机制包括Handler、Message Queue、Looper。Handler可以把消息/ Runnable对象 发给Looper，由它把消息放入所属线程的消息队列中，然后Looper又会自动把消息队列里的消息/Runnable对象 广播 到所属线程里的Handler，由Handler处理接收到的消息或Runnable对象。

1、Handler

每次创建Handler对象时，它会自动绑定到创建它的线程上。如果是主线程则默认包含一个Message Queue，否则需要自己创建一个消息队列来存储。

Handler是多个线程通信的信使。比如在线程A中创建AHandler，给它绑定一个ALooper，同时创建属于A的消息队列AMessageQueue。然后在线程B中使用AHandler发送消息给ALooper，ALooper会把消息存入到AMessageQueue，然后再把AMessageQueue广播给A线程里的AHandler，它接收到消息会进行处理。从而实现通信。

2、Message Queue

在主线程里默认包含了一个消息队列不需要手动创建。在子线程里，使用Looper.prepare()方法后，会先检查子线程是否已有一个looper对象，如果有则无法创建，因为每个线程只能拥有一个消息队列。没有的话就为子线程创建一个消息队列。

Handler类包含Looper指针和MessageQueue指针，而Looper里包含实际MessageQueue与当前线程指针。

下面分别就UI线程和worker线程讲解handler创建过程：

首先，创建handler时，会自动检查当前线程是否包含looper对象，如果包含，则将handler内的消息队列指向looper内部的消息队列，否则，抛出异常请求执行looper.prepare()方法。

 － 在 UI线程 中，系统自动创建了Looper 对象，所以，直接new一个handler即可使用该机制；

－ 在 worker线程 中，如果直接创建handler会抛出运行时异常－即通过查‘线程－value’映射表发现当前线程无looper对象。所以需要先调用Looper.prepare()方法。在prepare方法里，利用ThreadLocal<Looper>对象为当前线程创建一个Looper（利用了一个Values类，即一个Map映射表，专为thread存储value，此处为当前thread存储一个looper对象）。然后继续创建handler， 让handler内部的消息队列指向该looper的消息队列（这个很重要，让handler指向looper里的消息队列，即二者共享同一个消息队列，然后handler向这个消息队列发送消息，looper从这个消息队列获取消息） 。然后looper循环消息队列即可。当获取到message消息，会找出message对象里的target，即原始发送handler，从而回调handler的handleMessage() 方法进行处理。

 － handler与looper共享消息队列 ，所以handler发送消息只要入列，looper直接取消息即可。

 － 线程与looper映射表 ：一个线程最多可以映射一个looper对象。通过查表可知当前线程是否包含looper，如果已经包含则不再创建新looper。

5、基于这样的机制是怎样实现线程隔离的，即在线程中通信呢。 

核心在于 每一个线程拥有自己的handler、message queue、looper体系 。而 每个线程的Handler是公开 的。B线程可以调用A线程的handler发送消息到A的共享消息队列去，然后A的looper会自动从共享消息队列取出消息进行处理。反之一样。

二、上面是基于子线程中利用主线程提供的Handler发送消息出去，然后主线程的Looper从消息队列中获取并处理。那么还有另外两种情况：

1、主线程发送消息到子线程中；

采用的方法和前面类似。要在子线程中实例化AHandler并设定处理消息的方法，同时由于子线程没有消息队列和Looper的轮询，所以要加上Looper.prepare(),Looper.loop()分别创建消息队列和开启轮询。然后在主线程中使用该AHandler去发送消息即可。

2、子线程A与子线程B之间的通信。

1、 Handler为什么能够实现不同线程的通信？核心点在哪？

不同线程之间，每个线程拥有自己的Handler、消息队列和Looper。Handler是公共的，线程可以通过使用目标线程的Handler对象来发送消息，这个消息会自动发送到所属线程的消息队列中去，线程自带的Looper对象会不断循环从里面取出消息并把消息发送给Handler，回调自身Handler的handlerMessage方法，从而实现了消息的线程间传递。

2、 Handler的核心是一种事件激活式（类似传递一个中断）的还是主要是用于传递大量数据的？重点在Message的内容，偏向于数据传输还是事件传输。

目前的理解，它所依赖的是消息队列，发送的自然是消息，即类似事件中断。

0、 Android消息处理机制(Handler、Looper、MessageQueue与Message)

1、 Handler、Looper源码阅读

2、 Android异步消息处理机制完全解析，带你从源码的角度彻底理解

谢谢！

wingjay


㈥ Android多线程的四种方式：Handler、AsyncTask、ThreadPoolExector、IntentService

     异步通信机制，将工作线程中需更新UI的操作信息 传递到 UI主线程，从而实现 工作线程对UI的更新处理，最终实现异步消息的处理。Handler不仅仅能将子线程的数据传递给主线程，它能实现任意两个线程的数据传递。

（1）Message

    Message 可以在线程之间传递消息。可以在它的内部携带少量数据，用于在不同线程之间进行数据交换。除了 what 字段，还可以使用 arg1 和 arg2 来携带整型数据，使用 obj 来携带 Object 数据。

（2） Handler

    Handler 作为处理中心，用于发送（sendMessage 系列方法）与处理消息（handleMessage 方法）。

（3） MessageQueue

    MessageQueue 用于存放所有通过 Handler 发送的消息。这部分消息会一直存放在消息队列中，直到被处理。每个线程中只会有一个 MessageQueue 对象

（4） Looper

    Looper 用于管理 MessageQueue 队列，Looper对象通过loop()方法开启了一个死循环——for (;;)｛｝，不断地从looper内的MessageQueue中取出Message，并传递到 Handler 的 handleMessage() 方法中。每个线程中只会有一个 Looper 对象。

    AsyncTask 是一种轻量级的任务异步类，可以在后台子线程执行任务，且将执行进度及执行结果传递给 UI 线程。

（1）onPreExecute()

    在 UI 线程上工作，在任务执行 doInBackground() 之前调用。此步骤通常用于设置任务，例如在用户界面中显示进度条。

（2）doInBackground(Params... params)

    在子线程中工作，在 onPreExecute() 方法结束后执行，这一步被用于在后台执行长时间的任务，Params 参数通过 execute(Params) 方法被传递到此方法中。任务执行结束后，将结果传递给 onPostExecute(Result) 方法，同时我们可以通过 publishProgress(Progress) 方法，将执行进度发送给 onProgressUpdate(Progress) 方法。

（3）onProgressUpdate(Progress... values)

    在 UI 线程上工作，会在 doInBackground() 中调用 publishProgress(Progress) 方法后执行，此方法用于在后台计算仍在执行时(也就是 doInBackgound() 还在执行时)将计算执行进度通过 UI 显示出来。例如，可以通过动画进度条或显示文本字段中的日志，从而方便用户知道后台任务执行的进度。

（4）onPostExecute(Result result)

    在 UI 线程上工作，在任务执行完毕（即 doInBackground(Result) 执行完毕）并将执行结果传过来的时候工作。

使用规则：

（1）AsyncTask 是个抽象类，所以要创建它的子类实现抽象方法

（1）AsyncTask 类必须是在 UI 线程中被加载，但在Android 4.1（API 16）开始，就能被自动加载完成。

（2）AsyncTask 类的实例对象必须在 UI 线程中被创建。

（3）execute() 方法必须是在 UI 线程中被调用。

（4）不要手动调用方法 onPreExecute()、onPostExecute()、doInBackground()、onProgressUpdate()

（5）任务只能执行一次(如果尝试第二次执行，将抛出异常)。即一个AsyncTask对象只能调用一次execute()方法。

原理：

          其源码中原理还是 Thread 与 Handler 的实现，其包含 两个线程池，一个 Handler，如下所示：

名称类型作用

SERIAL_EXECUTOR线程池分发任务，串行分发，一次只分发一个任务

THREAD_POOL_EXECUTOR线程池执行任务，并行执行，执行的任务由 SERIAL_EXECUTOR 分发

InternalHandlerHandler负责子线程与主线程的沟通，通知主线程做 UI 工作

    一方面减少了每个并行任务独自建立线程的开销，另一方面可以管理多个并发线程的公共资源，从而提高了多线程的效率。所以ThreadPoolExecutor比较适合一组任务的执行。Executors利用工厂模式对ThreadPoolExecutor进行了封装。

Executors提供了四种创建ExecutorService的方法，他们的使用场景如下：

1. Executors.newFixedThreadPool()

    创建一个定长的线程池，每提交一个任务就创建一个线程，直到达到池的最大长度，这时线程池会保持长度不再变化。

当线程处于空闲状态时，它们并不会被回收，除非线程池被关闭。当所有的线程都处于活动状态时，新任务都会处于等待状态，直到有线程空闲出来。

只有核心线程并且不会被回收，能够更加快速的响应外界的请求。

2. Executors.newCachedThreadPool()

    创建一个可缓存的线程池，如果当前线程池的长度超过了处理的需要时，它可以灵活的回收空闲的线程，当需要增加时，它可以灵活的添加新的线程，而不会对池的长度作任何限制

    线程数量不定的线程池，只有非核心线程，最大线程数为 Integer.MAX_VALUE。当线程池中的线程都处于活动状态时，线程池会创建新的线程来处理新任务，否则利用空闲的线程来处理新任务。线程池中的空闲线程具有超时机制，为 60s。

    任务队列相当于一个空集合，导致任何任务都会立即被执行，适合执行大量耗时较少的任务。当整个线程池都处于限制状态时，线程池中的线程都会超时而被停止。

3. Executors.newScheledThreadPool()

    创建一个定长的线程池，而且支持定时的以及周期性的任务执行，类似于Timer。

    非核心线程数没有限制，并且非核心线程闲置的时候立即回收，主要用于执行定时任务和具有固定周期的重复任务。

4. Executors.newSingleThreadExecutor()

    创建一个单线程化的executor，它只创建唯一的worker线程来执行任务

    只有一个核心线程，保证所有的任务都在一个线程中顺序执行，意义在于不需要处理线程同步的问题。

    一般用于执行后台耗时任务，当任务执行完成会自动停止；同时由于它是一个服务，优先级要远远高于线程，更不容易被系统杀死，因此比较适合执行一些高优先级的后台任务。

使用步骤：创建IntentService的子类，重写onHandleIntent方法，在onHandleIntent中执行耗时任务

    原理：在源码实现上，IntentService封装了HandlerThread和Handler。onHandleIntent方法结束后会调用IntentService的stopSelf(int startId)方法尝试停止服务。

    IntentService的内部是通过消息的方式请求HandlerThread执行任务，HandlerThread内部又是一种使用Handler的Thread，这就意味着IntentService和Looper一样是顺序执行后台任务的

（HandlerThread：封装了Handler + ThreadHandlerThread适合在有需要一个工作线程（非UI线程）+任务的等待队列的形式，优点是不会有堵塞，减少了对性能的消耗，缺点是不能同时进行多个任务的处理，需要等待进行处理。处理效率低，可以当成一个轻量级的线程池来用）

㈦ Handler源码分析

Handler对于Android开发者再熟悉不过了，也是面试题的常客了，所以了解Handler机制的源码就很有必要了，虽然Handler分析的文章已经有很多，但是自己总结一遍，印象才更深刻。

Handler机制，是Android中的一种消息传递机制，在开发中十分常用。由于Android从3.0开始不允许耗时操作在主线程中执行，必须在子线程中执行完后，将结果发送到主线程中更新UI。所以简单来讲Handler就是子线程和主线程通信的一种技术。

先是常规使用，Handler在主线程中创建，开启子线程处理耗时操作，再通过Handler发送消息到主线程，Handler的handleMessage()方法就会被回调，再更新UI。

以及也很常用的，post()和postDelayed()。

还有一种场景，就是子线程中创建Handler，让子线程成为轮训的线程，接收其他线程的消息，开发中并不多，但是特定场景会很有用，例如有一个一直执行的子线程，一直定时扫描着当前位置信息，到了指定范围，发送一个播放语音的消息的消息到主线程。

接下来就是Handler源码分析了：

一般我们获取Message会调用Handler的obtainMessage()方法，这个方法是获取一个复用的Message对象，内部采用享元模式复用Message对象，在Android中，View绘制，Activity生命周期，都是使用Handler发送Message实现，如果每次都new一个消息对象，肯定是十分消耗内存的，也容易产生GC垃圾回收导致卡顿。

我们平常在主线程使用Handler时，并没有调用过Looper.prepare()和Looper.loop()这2个方法，为什么创建Handler时不会抛出异常呢？

原因就是创建Handler时，调用Looper.myLooper()获取主线程绑定的Looper不为空，所以没有抛出异常。经过Looper类中查找发现，除了Looper.prepare()之外，还有一个prepareMainLooper()的方法。

prepareMainLooper()方法的注释，意思大概就是，创建主线程的Looper对象，该方法由Android框架在主线程自动调用，我们不应该主动调用该方法。

那么什么时候会调用prepareMainLooper()方法呢，AndroidStudio点击方法查找调用链，我们发现在ActivityThread中有调用。ActivityThread是Android程序的主线程，main方法则是启动的方法，我们看到先是调用了Looper.prepareMainLooper()，初始化主线程的Looper。再调用了Looper.loop()开启主线程轮训。

㈧ 关于 Handler 的这 20 个问题，你都清楚吗

Android 11 开始，AsyncTask 正式谢幕，变成了不推荐使用的 API。官方建议采用 Kotlin 协程替代，或者自行实现。

事实上，无论是 AsyncTask 还是协程，背后都有 Handler 的功劳。无论从普及原理的角度、还是从自行实现的角度，我们都需要吃透这个 Android 系统所特有的线程间通信方式Handler 机制！

初尝 Handler 机制的时候，原以为 Handler 类发挥了很大的作用。当你深入了解它的原理之后，会发现 Handler 只是该机制的 调用入口和回调 而已，最重要的东西是 Looper 和 MessagQueue，以及不断流转的 Message。

本次针对 Handler 机制常被提及和容易困扰的  20  个问题进行整理和回答，供大家解惑和回顾~

简述下 Handler 机制的总体原理？

Looper 存在哪？如何可以保证线程独有？

如何理解 ThreadLocal 的作用？

主线程 Main Looper 和一般 Looper 的异同？

Handler 或者说 Looper 如何切换线程？

Looper 的 loop() 死循环为什么不卡死？

Looper 的等待是如何能够准确唤醒的？

Message 如何获取？为什么这么设计？

MessageQueue 如何管理 Message？

理解 Message 和 MessageQueue 的异同？

Message 的执行时刻如何管理？

Handler、Mesage 和 Runnable 的关系如何理解？

IdleHandler 空闲 Message 了解过吗？有什么用？

异步 Message 或同步屏障了解过吗？怎么用？什么原理？

Looper 和 MessageQueue、Message 及 Handler 的关系？

Native 侧的 NativeMessageQueue 和 Looper 的作用是？

Native 侧如何使用 Looper？

Handler 为什么可能导致内存泄露？如何避免？

Handler 在系统当中的应用

Android 为什么不允许并发访问 UI？

1. 简述下 Handler 机制的总体原理？

Looper 准备和开启轮循：

尚无 Message 的话，调用 Native 侧的 pollOnce() 进入 无限等待

存在 Message，但执行时间 when 尚未满足的话，调用 pollOnce() 时传入剩余时长参数进入 有限等待

Looper#prepare() 初始化线程独有的 Looper 以及 MessageQueue

Looper#loop() 开启 死循环 读取 MessageQueue 中下一个满足执行时间的 Message

Message 发送、入队和出队：

Native 侧如果处于无限等待的话：任意线程向 Handler 发送 Message 或 Runnable 后，Message 将按照 when 条件的先后，被插入 Handler 持有的 Looper 实例所对应的 MessageQueue  中 适当的位置 。MessageQueue 发现有合适的 Message 插入后将调用 Native 侧的 wake() 唤醒无限等待的线程。这将促使 MessageQueue 的读取继续 进入下一次循环 ，此刻 Queue 中已有满足条件的 Message 则出队返回给 Looper

Native 侧如果处于有限等待的话：在等待指定时长后 epoll_wait 将返回。线程继续读取 MessageQueue，此刻因为时长条件将满足将其出队

Looper 处理 Message 的实现：

Looper 得到 Message 后回调 Message 的 callback 属性即 Runnable，或依据 target 属性即 Handler，去执行 Handler 的回调。

存在 mCallback 属性的话回调 Handler$Callback

反之，回调 handleMessage()

2. Looper 存在哪？如何可以保证线程独有？

Looper 实例被管理在静态属性 sThreadLocal 中

ThreadLocal 内部通过 ThreadLocalMap 持有 Looper，key 为 ThreadLocal 实例本身，value 即为 Looper 实例

每个 Thread 都有一个自己的 ThreadLocalMap，这样可以保证每个线程对应一个独立的 Looper 实例，进而保证 myLooper() 可以获得线程独有的 Looper

彩蛋：一个 App 拥有几个 Looper 实例？几个 ThreadLocal 实例？几个 MessageQueue 实例？几个 Message 实例？几个 Handler 实例

一个线程只有一个 Looper 实例

一个 Looper 实例只对应着一个 MessageQueue 实例

一个 MessageQueue 实例可对应多个 Message 实例，其从 Message 静态池里获取，存在 50 的上限

一个线程可以拥有多个 Handler 实例，其Handler 只是发送和执行任务逻辑的入口和出口

ThreadLocal 实例是静态的，整个进程 共用一个实例 。每个 Looper 存放的 ThreadLocalMap 均弱引用它作为 key

3. 如何理解 ThreadLocal 的作用？

首先要明确并非不是用来切换线程的， 只是为了让每个线程方便程获取自己的 Looper 实例 ，见 Looper#myLooper()

后续可供 Handler 初始化时 指定其所属的 Looper 线程

也可用来线程判断自己是否 是主线程

4. 主线程 Main Looper 和一般 Looper 的异同？

区别：

Main Looper  不可 quit

主线程需要不断读取系统消息和用书输入，是进程的入口，只可被系统直接终止。进而其 Looper 在创建的时候设置了 不可quit的标志 ，而 其他线程的 Looper 则可以也必须手动 quit

Main Looper 实例还被 静态缓存

为了便于每个线程获得主线程 Looper 实例，见 Looper#getMainLooper()，Main Looper 实例还作为 sMainLooper 属性缓存到了 Looper 类中。

相同点：

都是通过 Looper#prepare() 间接调用 Looper 构造函数创建的实例

都被静态实例 ThreadLocal 管理，方便每个线程获取自己的 Looper 实例

彩蛋：主线程为什么不用初始化 Looper？

App 的入口并非 MainActivity，也不是 Application，而是 ActivityThread。

其为了 Application、ContentProvider、Activity 等组件的运行，必须事先启动不停接受输入的 Looper 机制，所以在 main() 执行的最后将调用 prepareMainLooper() 创建 Looper 并调用 loop() 轮循。

不需要我们调用，也不可能有我们调用。

可以说如果主线程没有创建 Looper 的话，我们的组件也不可能运行得到！

5. Handler 或者说 Looper 如何切换线程？

Handler 创建的时候指定了其所属线程的 Looper，进而持有了 Looper 独有的 MessageQueue

Looper#loop() 会持续读取 MessageQueue 中合适的 Message，没有 Message 的时候进入等待

当向 Handler 发送 Message 或 Runnable 后，会向持有的 MessageQueue 中插入 Message

Message 抵达并满足条件后会唤醒 MessageQueue 所属的线程，并将 Message 返回给 Looper

Looper 接着回调 Message 所指向的 Handler Callback 或 Runnable，达到线程切换的目的

简言之，向 Handler 发送 Message 其实是向 Handler 所属线程的独有 MessageQueue 插入 Message。而线程独有的 Looper 又会持续读取该 MessageQueue。所以向其他线程的 Handler 发送完 Message，该线程的 Looper 将自动响应。

6. Looper 的 loop() 死循环为什么不卡死？

为了让主线程持续处理用户的输入，loop() 是 死循环 ，持续调用 MessageQueue#next() 读取合适的 Message。

但当没有 Message 的时候，会调用 pollOnce() 并通过 Linux 的 epoll 机制进入等待并释放资源。同时 eventFd 会监听 Message 抵达的写入事件并进行唤醒。

这样可以 空闲时释放资源、不卡死线程，同时能持续接收输入的目的 。

彩蛋1：loop() 后的处理为什么不可执行

因为 loop() 是死循环，直到 quit 前后面的处理无法得到执行，所以避免将处理放在 loop() 的后面。

彩蛋2：Looper 等待的时候线程到底是什么状态？

调用 Linux 的 epoll 机制进入 等待 ，事实上 java 侧打印该线程的状态，你会发现线程处于 Runnable 状态，只不过 CPU 资源被暂时释放。

7. Looper 的等待是如何能够准确唤醒的？

读取合适 Message 的 MessageQueue#next() 会因为 Message 尚无或执行条件尚未满足进行两种等的等待：

无限等待

尚无 Message（队列中没有 Message 或建立了同步屏障但尚无异步 Message）的时候，调用 Natvie 侧的 pollOnce() 会传入参数  -1 。

Linux 执行 epoll_wait() 将进入无限等待，其等待合适的 Message 插入后调用 Native 侧的 wake() 向唤醒 fd 写入事件触发唤醒 MessageQueue 读取的下一次循环

有限等待

有限等待的场合将下一个 Message  剩余时长作为参数 交给 epoll_wait()，epoll 将等待一段时间之后 自动返回 ，接着回到 MessageQueue 读取的下一次循环

8. Message 如何获取？为什么这么设计？

享元设计模式：通过 Message 的静态方法 obatin() 获取，因为该方法不是无脑地 new，而是 从单链表池子里获取实例 ，并在 recycle() 后将其放回池子

好处在于复用 Message 实例，满足频繁使用 Message 的场景，更加高效

当然，缓存池存在上限  50 ，因为没必要无限制地缓存，这本身也是一种浪费

需要留意缓存池是静态的，也就是整个进程共用一个缓存池

9. MessageQueue 如何管理 Message？

MessageQueue 通过单链表管理 Message，不同于进程共用的 Message Pool，其是线程独有的

通过 Message 的执行时刻 when 对 Message 进行排队和出队

MessageQueue 除了管理 Message，还要管理空闲 Handler 和 同步屏障

10. 理解 Message 和 MessageQueue 的异同？

相同点：都是通过 单链表来管理  Message 实例；

Message 通过  obtain() 和 recycle()  向单链表获取插入节点

MessageQueue 通过  enqueueMessage() 和 next()  向单链表获取和插入节点

区别：

Message 单链表是 静态的，供进程使用的缓存池

MessageQueue 单链表 非静态，只供 Looper 线程使用

11. Message 的执行时刻如何管理？

发送的 Message 都是按照执行时刻 when 属性的先后管理在 MessageQueue 里

延时 Message 的 when 等于调用的当前时刻和 delay 之和

非延时 Message 的 when 等于当前时刻（delay 为 0）

插队 Message 的 when 固定为 0，便于插入队列的 head

之后 MessageQueue 会根据 读取的时刻和 when 进行比较

将 when 已抵达的出队，

尚未抵达的计算出 当前时刻和目标 when 的插值 ，交由 Native 等待对应的时长，时间到了自动唤醒继续进行 Message 的读取

事实上，无论上述哪种 Message 都不能保证在其对应的 when 时刻执行，往往都会延迟一些！因为必须等当前执行的 Message 处理完了才有机会读取队列的下一个 Message。

比如发送了非延时 Message，when 即为发送的时刻，可它们不会立即执行。都要等主线程现有的任务（Message）走完才能有机会出队，而当这些任务执行完 when 的时刻已经过了。假使队列的前面还有其他 Message 的话，延迟会更加明显！

彩蛋：. onCreate() 里向 Handler 发送大量 Message 会导致主线程卡顿吗？

不会，发送的大量 Message 并非立即执行，只是先放到队列当中而已。

onCreate() 以及之后同步调用的 onStart() 和 onResume() 处理，本质上也是 Message。等这个 Message 执行完之后，才会进行读取 Message 的下一次循环，这时候才能回调 onCreate 里发送的 Message。

需要说明的是，如果发送的是 FrontOfQueue 将 Message 插入队首也不会立即先执行，因为 onStart 和 onResume 是 onCreate 之后同步调用的，本质上是同一个 Message 的作业周期

12. Handler、Mesage 和 Runnable 的关系如何理解？

作为使用 Handler 机制的入口， Handler 是发送 Message 或 Runnable 的起点

发送的  Runnable 本质上也是 Message ，只不过作为 callback 属性被持有

Handler 作为 target 属性被持有在 Mesage 中 ，在 Message 执行条件满足的时候供 Looper 回调

事实上，Handler 只是供 App 使用 Handler 机制的 API，实质来说，Message 是更为重要的载体。

13. IdleHandler 空闲 Message 了解过吗？有什么用？

适用于期望 空闲时候执行，但不影响主线程操作 的任务

系统应用：

Activity destroy 回调就放在了 IdleHandler 中

ActivityThread 中 GCHandler 使用了 IdleHandler，在空闲的时候执行  GC  操作

App 应用：

发送一个返回 true 的 IdleHandler，在里面让某个 View 不停闪烁，这样当用户发呆时就可以诱导用户点击这个 View

将某部分初始化放在 IdleHandler 里不影响 Activity 的启动

14. 异步 Message 或同步屏障了解过吗？怎么用？什么原理？

异步 Message：设置了 isAsync 属性的 Message 实例

可以用异步 Handler 发送

也可以调用 Message#setAsynchronous() 直接设置为异步 Message

同步屏障：在 MessageQueue 的 某个位置放一个 target 属性为 null 的 Message ，确保此后的非异步 Message 无法执行，只能执行异步 Message

原理：当 MessageQueue 轮循 Message 时候 发现建立了同步屏障的时候，会去跳过其他 Message，读取下个 async 的 Message 并执行，屏障移除之前同步 Message 都会被阻塞

应用：比如 屏幕刷新 Choreographer 就使用到了同步屏障 ，确保屏幕刷新事件不会因为队列负荷影响屏幕及时刷新。

注意： 同步屏障的添加或移除 API 并未对外公开，App 需要使用的话需要依赖反射机制

15. Looper 和 MessageQueue、Message 及 Handler 的关系？

Message 是承载任务的载体，在 Handler 机制中贯穿始终

Handler 则是对外公开的 API，负责发送 Message 和处理任务的回调，是  Message 的生产者

MessagQueue 负责管理待处理 Message 的入队和出队，是  Message 的容器

Looper 负责轮循 MessageQueue，保持线程持续运行任务，是  Message 的消费者

彩蛋：如何保证 MessageQueue 并发访问安全？

任何线程都可以通过 Handler 生产 Message 并放入 MessageQueue 中，可 Queue 所属的 Looper 在持续地读取并尝试消费 Message。如何保证两者不产生死锁？

Looper 在消费 Message 之前要先拿到 MessageQueue  的锁， 只不过没有 Message 或 Message 尚未满足条件的进行等待前会事先释放锁 ，具体在于 nativePollOnce() 的调用在 synchronized 方法块的外侧。

Message 入队前也需先拿到 MessageQueue  的锁，而这时 Looper 线程正在等待且不持有锁，可以确保 Message 的成功入队。入队后执行唤醒后释放锁，Native 收到 event 写入后恢复 MessagQueue 的读取并可以拿到锁，成功出队。

这样一种在没有 Message 可以消费时执行等待同时不占着锁的机制，避免了生产和消费的死锁。

16. Native 侧的 NativeMessageQueue 和 Looper 的作用是？

NativeMessageQueue 负责连接 Java 侧的 MessageQueue，进行后续的 wait 和 wake，后续将创建 wake 的FD，并通过 epoll 机制等待或唤醒。 但并不参与管理 Java 的 Message

Native 侧也需要 Looper 机制，等待和唤醒的需求是同样的，所以将这部分实现都封装到了 JNI 的NativeMessageQueue  和  Native 的 Looper 中， 供 Java 和 Native 一起使用

17. Native 侧如何使用 Looper？

Looper Native 部分承担了 Java 侧 Looper 的等待和唤醒，除此之外其还提供了 Message、MessageHandler 或 WeakMessageHandler、LooperCallback 或 SimpleLooperCallback 等 API

这些部分可供 Looper 被 Native 侧直接调用，比如 InputFlinger 广泛使用了 Looper

主要方法是调用 Looper 构造函数或 prepare 创建 Looper，然后通过 poll 开始轮询，接着 sendMessage 或 addEventFd，等待 Looper 的唤醒。 使用过程和 Java 的调用思路类似

18. Handler 为什么可能导致内存泄露？如何避免？

持有 Activity 实例的内名内部类或内部类的 生命周期 应当和 Activity 保持一致，否则产生内存泄露的风险。

如果 Handler 使用不当，将造成不一致，表现为：匿名内部类或内部类写法的 Handler、Handler$Callback、Runnable，或者Activity 结束时仍有活跃的 Thread 线程或 Looper 子线程

具体在于：异步任务仍然活跃或通过发送的 Message 尚未处理完毕，将使得内部类实例的 生命周期被错误地延长 。造成本该回收的 Activity 实例 被别的 Thread 或 Main Looper 占据而无法及时回收 （活跃的 Thread 或 静态属性 sMainLooper 是 GC Root 对象）

建议的做法：

无论是 Handler、Handler$Callback 还是 Runnable，尽量采用 静态内部类 + 弱引用 的写法，确保尽管发生不当引用的时候也可以因为弱引用能清楚持有关系

另外在 Activity 销毁的时候及时地 终止 Thread、停止子线程的 Looper 或清空 Message ，确保彻底切断 Activity 经由 Message 抵达 GC Root 的引用源头（Message 清空后会其与 Handler 的引用关系，Thread 的终止将结束其 GC Root 的源头）

注意：静态的 sThreadLocal 实例不持有存放 Looper 实例的 ThreadLocalMap，而是由 Thread 持有。从这个角度上来讲，Looper 会被活跃的 GC Root Thread 持有，进而也可能导致内存泄露。

彩蛋：网传的 Handler$Callback 方案能否解决内存泄露？

不能。

Callback 采用内部类或匿名内部类写法的话，默认持有 Activity 的引用，而 Callback 被 Handler 持有。这最终将导致 Message -> Handler -> Callback -> Activity 的链条仍然存在。

19. Handler 在系统当中的应用

特别广泛，比如：

Activity 生命周期的管理

屏幕刷新

HandlerThread、IntentService

AsyncTask 等。

主要利用 Handler 的切换线程、主线程异步 Message 的重要特性。注意：Binder 线程非主线程，但很多操作比如生命周期的管理都要回到主线程，所以很多 Binder 调用过来后都要通过 Handler 切换回主线程执行后续任务，比如 ActviityThread$H 就是 extends Handler。

20. Android 为什么不允许并发访问 UI？

Android 中 UI 非线程安全，并发访问的话会造成数据和显示错乱。

但此限制的检查始于ViewRootImpl#checkThread()，其会在刷新等多个访问 UI 的时机被调用，去检查当前线程，非主线程的话抛出异常。

而 ViewRootImpl 的创建在 onResume() 之后，也就是说如果在 onResume() 执行前启动线程访问 UI 的话是不会报错的，这点需要留意！

彩蛋：onCreate() 里子线程更新 UI 有问题吗？为什么？

不会。

因为异常的检测处理在 ViewRootImpl 中，该实例的创建和检测在 onResume() 之后进行。

㈨ Android Handler那些事儿，消息屏障IdelHandlerANR

Handler 是Android SDK中用来处理异步消息的核心类，子线程可以通过handler来通知主线程进行ui更新。

备注：本文源码截图 基于Android sdk 28

Handler机制 消息发送主要流程如图

应用程序启动后，zygote fork一个应用进程后，和普通java程序一样，程序会首先执行ActivityThread中的main函数。在main函数中，程序首先会创建Looper对象并绑定到主线程中，然后开启loop循环。（ps:主线程loop循环不能退出）

在prepareMainLooper方法中，最终会创建Looper，MessageQueue对象 以及创建native层MessageQueue对象。

使用Handler.sendMessageXXX或这 postDedayXXX发送消息后，最终会调用到SendMessageAtTime方法中。

然后调用MessageQueue.enqueueMessage将消息存到消息队列中。

存入消息后，然后通过调用native方法 唤醒主线程进行消息处理。

当应用程序启动，做完一些必要工作之后，便会开启Loop循环，除非系统异常，否则该循环不会停止。loop循环中，主要做两件事，第一，从消息队列中取消息。第二，进行消息分发处理。

MessageQueue.next() 方法 通过调用 native方法 nativePollOnce(ptr, nextPollTimeoutMillis)实现无消息处理时，进入阻塞的功能。
当nextPollTimeoutMillis 值为0时，该方法会立刻返回；
当nextPollTimeoutMillis 值为-1时，该方法会无限阻塞，直到被唤醒；
当nextPollTimeoutMillis 值大于0时，该方法会将该值设置为超时时间，阻塞到达一定时间后，返回；

在loop循环中 ，通过调用 msg.target.dispatchMessage(msg) 进行消息的分发处理

使用当前线程的MessageQueue.addIdleHandler方法可以在消息队列中添加一个IdelHandler。

当MessageQueue 阻塞时，即当前线程空闲时，会回调IdleHandler中的方法；

当IdelHandler接口返回false时，表示该IdelHandler只执行一次，

a，延迟执行

例如，当启动Activity时，需要延时执行一些操作，以免启动过慢，我们常常使用以下方式延迟执行任务，但是在延迟时间上却不好控制。

其实，这时候使用IdelHandler 会更优雅

b，批量任务，任务密集，且只关注最终结果

例如，在开发一个IM类型的界面时，通常情况下，每次收到一个IM消息时，都会刷新一次界面，但是当短时间内， 收到多条消息时，就会刷新多次界面，容易造成卡顿，影响性能，此时就可以使用一个工作线程监听IM消息，在通过添加IdelHandler的方式通知界面刷新，避免短时间内多次刷新界面情况的发生。

在Android的消息机制中，其实有三种消息: 普通消息、异步消息及消息屏障。

消息屏障 也是一种消息，但是它的target为 null。可以通过MessageQueue中的postSyncBarrier方法发送一个消息屏障（该方法为私有，需要反射调用）。

在消息循环中，如果第一条消息就是屏障消息，就往后遍历，看看有没有异步消息:
如果没有，则无限休眠，等待被唤醒
如果有，就看离这个消息被触发时间还有多久，设置一个超时时间，继续休眠

异步消息 和普通消息一样，只不过它被设置setAsynchronous 为true。有了这个标志位，消息机制会对它有些特别的处理，我们稍后说。

所以 消息屏障和异步消息的作用 很明显，在设置消息屏障后，异步消息具有优先处理的权利。

这时候我们回顾将消息添加到消息队列中时，可以发现，其实并不是每一次添加消息时，都会唤醒线程。
当该消息插入到队列头时，会唤醒该线程；
当该消息没有插入到队列头，但队列头是屏障，且该消息是队列中 靠前的一个异步消息，则会唤醒线程，执行该消息；

调用MessageQueue.removeSyncBarrier 方法可以移除指定的消息屏障

ANR 即 Application Not Response， 是系统进程对应用行为的一种监控，如果应用程序没有在规定时间内完成任务的话，就会引起ANR。

ANR类型

Service Timeout : 前台服务20s, 后台服务200s

BroadcastQueue Timeout : 前台广播 10s，后台广播60s

ContentPrivider Timeout : 10s

InputDispatching Timeout : 5s

比如，在启动一个服务时， AMS端通过应用进程的Binder对象创建Service, 在scheleCreateService()方法中 会调用到当前service的onCreate()生命周期函数；

bumpServiceExecutingLocked()方法内部实际上会调用到scheleServiceTimeoutLocked()方法，发送一个ActivityManagerService.SERVICE_TIMEOUT_MSG类型消息到AMS工作线程中。

消息的延时时间，如果是前台服务，延时20s, 如果是后台服务，延时200s;

如果Service的创建 工作在 上诉消息的延时时间内完成，则会移除该消息，

否则，在Handler正常收到这个消息后，就会进行服务超时处理，即弹出ANR对话框。

复杂情况下，可能会频繁调用sendMessage 往消息队列中，添加消息，导致消息积压，造成卡顿，

1，重复消息过滤

频繁发送同类型消息时，有可能队列中之前的消息还没有处理，又发了一条相同类型的消息，更新之前的数据，这时候，可以采用移除前一个消息的方法，优化消息队列。

2，互斥消息取消

在发送消息时，优先将消息队列中还未处理的信息已经过时的消息 移除，优化队列

3，队列优化-复用消息

创建消息时，优先采用之前回收的消息，避免重复创建对象，引起GC

完~
（如果错误或不足，望指出， 大家共同进步）

㈩ Handler 中的 epoll

在 Linux 中，epoll 机制是一个重要的机制。在 Android 中的 Handler，简单的利用了 epoll 机制，做到了消息队列的阻塞和唤醒。

epoll 机制相关的函数有

因为对于Handler 对烂带于 epoll 没有过于深入的使用，只是利用了 epoll 进行了阻塞和唤醒，还是比较好理解的。

于是，便利用 epoll 机制在mEpollFd上添加(EPOLL_CTL_ADD)了监听的 fd(mWakeEventFd);

在 java 层，next( )@Message 会阻塞到nativePollOnce(long ptr, int timeoutMillis)，特别的是，当没有消息时，timeoutMillis = -1表示一直阻塞。如果有 delay 的消息，则 timeoutMillis 表示 delay的时间。

此时利用epoll 机制在 epoll_wait()上设置超时时间。当 timeoutMillis = -1时会一直等待知道有新消息来。否则当超时时间到达时信历贺，会返回到 next()@Message就可以处理那条 delay 的消息了。

当有新消息来临时并且是立刻执行的,enqueueMessage()@Message 会调用nativeWake()，否则会根据新来的消息的 delay 时滑派间和队列中的 delay 时间进行对比，消息队列是按照msg 的到达时间和 delay 时间进行排序，如果新来的消息在前并且需要 delay 也会进行 wake()

当往 mWakeEventFd 写入一个 1，便会从 epoll_wait() 马上返回。进行新一轮的消息处理。

另外，native 层的 Looper 的 epoll 机制没有这么简单，只是在 Handler 中只是简单地使用了。

Linux中的epoll