android线程通信方式

⑴ 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线程）+任务的等待队列的形式，优点是不会有堵塞，减少了对性能的消耗，缺点是不能同时进行多个任务的处理，需要等待进行处理。处理效率低，可以当成一个轻量级的线程池来用）

⑵ android中什么时候会选择用广播来进行线程间的通信

android中什么时候会选择用广播来进行线程间的通信 Android 多线程 通信

线程中通信就不要用广播了吧 进程中通信可以用广播或者aidl

可是，这两天看到的项目都是这么做的；然后，自己分析了下，觉得一下的理由也是可以成立的；

1.正常情况下我们选择handler消息机制来进行单向的线程间的通信；（工作线程向主线程发送消息）

因为主线程有现成的handler，而工作线程没有现成的handler，这样的话，主线程将handler交给工作线程而让工作线程将工作的结果交给主线程；

相反，工作线程中没有现成的handler（事实上是没有消息队列，也就是handler没有绑定到工作线程），那么，如果开辟的话，代码角度上是挺麻烦的（相对应广播机制来说）；

2.广播机制本身就是双向的（工作线程向主线程发送广播，主线程向工作线程发送广播）；

//另外，对于像一个activity中通过fragment来进行界面的处理； 我们大多数情况下是采用广播的机制来实现fragment中adapter的数据的更新；这样做主要是考虑到工作线程的任务加载完成，而具体的对应刷新的activity可能还没有启动；

另外，基于接口隔离原则，如果用handler进行通信的话，则不能很好的满足这一原则；

你要是周期比较长 用广播好些吧

应该与周期关系不是很密切。最主要的原因是两条线成是双向通信。

Handler类似于P2P的通信。
广播则类似于一个server端，用来处理分发不同线程的请求，从控制器的角度来说用广播更好一点。

一般使用Handler的，多用于子线程处理事务，完成时告知主线程这一类的情况。
而类似楼主所说的多条线程之间需要频繁交互的话，广播是个很好的选择，并且结构清晰，只是不知道广播的性能与handler相比会怎么样。

⑶ Android进程与线程区别

所以下来特地去查了以下资料，先说说线程：
（1）在Android APP中，只允许有一个主线程，进行UI的渲染等等，但是不能进行耗时操作（网络交互等等），否则会造成ANR，就是线程阻塞卡死，未响应。
（2）除了主线程之外，耗时操作都应该规范到子线程中,线程之间会有相应的通信方式，但相互独立。
（3）然后看了一下所查资料：
线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位。线程比进程更小，基本上不拥有系统资源，故对它的调度所用资源小，能更高效的提高系统内多个程序间并发执行的。 嗯，从大的说就是这样。
在平时的Android开发过程中，基本上都会用到线程handler，thread等等，具体的实现方法我就不在这里写了。

进程：
根据所查资料：是一个具有独立功能的程序关于某个数据集合的一次运行活动。进程是系统进行资源分配和调度的一个独立单位。可以申请和拥有系统资源，是一个动态的概念，是一个活动的实体，是一个“执行中的程序”。不只是程序的代码，还包括当前的活动。
这应该是一个比较大的概念，存在于一个系统中，与线程的区别是：

1、子进程和父进程有不同的代码和数据空间，而多个线程则共享数据空间，每个线程有自己的执行堆栈和程序计数器为其执行上下文。
2、进程间相互独立，同一进程的各线程间共享。某进程内的线程在其它进程不可见。

3、进程间通信IPC，线程间可以直接读写进程数据段（如全局变量）来进行通信——需要进程同步和互斥手段的辅助，以保证数据的一致性。

4、线程上下文切换比进程上下文切换要快得多。

⑷ Android：主线程如何向子线程发送消息

因为你是在主线程创建的handler实例，比如你是这样实例化handler

然后调用looper.loop()；就开始了消息循环。这就是为什么在主线程发消息住线程还能收到消息的原因。因为发送消息的实例是在主线程实例化的就有了主线程的looper。

⑸ 面试被问到android中两个子线程怎么通信，我懵了。

构造HandlerThread类的对象mHandlerThread，这样生成一个子线程可以调用new MyHandler(mHandlerThread.getLooper())来获取子线程的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机制的原理

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通信方式篇（七）-Binder机制（Native层（下））

本篇文章针对向ServiceManager注册服务 和 获取服务两个流程来做总结。在这两个过程中，ServiceManager都扮演的是服务端，与客户端之间的通信也是通过Binder IPC。

在此之前先了解下Binder的进程与线程的关系：

用户空间 :ProcessState描述一个进程，IPCThreadState对应一个进程中的一个线程。
内核空间 ：binder_proc描述一个进程，统一由binder_procs全局链表保存，binder_thread对应进程的一个线程。
ProcessState与binder_proc是一一对应的。

Binder线程池 ：每个Server进程在启动时会创建一个binder线程池，并向其中注册一个Binder线程；之后Server进程也可以向binder线程池注册新的线程，或者Binder驱动在探测到没有空闲binder线程时会主动向Server进程注册新的的binder线程。对于一个Server进程有一个最大Binder线程数限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。对于所有Client端进程的binder请求都是交由Server端进程的binder线程来处理的。我的理解是：binder线程是进程进行binder ipc时的一条数据处理路径。

MediaPlayerService向ServiceManager注册过程如下：

相关类：

整个过程总结如下：
1 获取BpServiceManager 与 BpBinder
由defaultServiceManager()返回的是BpServiceManager，同时会创建ProcessState对象和BpBinder对象。然后通过BpBinder执行transact，把真正工作交给IPCThreadState来处理。

2 BpBinder transact
Binder代理类调用transact()方法，真正工作还是交给IPCThreadState来进行transact工作。

3 通过IPCThreadState 包装并转换数据并进行transact事务处理
每个线程都有一个IPCThreadState，每个IPCThreadState中都有一对Parcel变量：mIn、mOut。相当于两根数据管道：

最后执行talkWithDriver。

writeTransactionData：将BC Protocol + binder_transaction_data结构体 写入mOut， 然后执行waitForResponse：

由talkWithDriver将数据进一步封装到binder_write_read结构体，通过ioctl（BINDER_WRITE_READ）与驱动通信。同时等待驱动返回的接收BR命令，从mIn取出返回的数据。

mIn包装的数据结构(注册服务handle = 0 ，code 为ADD_SERVICE_TRANSACTION)：

4 Binder Driver
把binder_write_read结构体write_buffer里数据取出来，分别得到BC命令和封装好数据的事务binder_transaction_data, 然后根据handler，在当前binder_proc中，找到相应的binder_ref，由binder_ref再找到目标binder_node实体，由目标binder_node再找到目标进程binder_proc。然后就是插入数据：当binder驱动可以找到合适的线程，就会把binder_transaction节点插入到servciemanager的线程的todo队列中，如果找不到合适的线程，就把节点之间插入servciemanager的binder_proc的todo队列。

5 ServiceManager
经过Binder Driver的处理，数据已经到了ServiceManager进程，在BR_TRANSACTION的引导下，在binder_loop（）中执行binder_parser（）取出数据，执行do_add_service（）操作，最终向 svcinfo 列表中添加已经注册的服务（没有数据的返回）。最后发送 BR_REPLY 命令唤醒等待的线程，通知注册成功。结束MediaPlayerService进程 waitForResponse()的状态，整个注册过程结束。

获取服务的过程与注册类似，首先 ServiceManager 向 Binder 驱动发送 BC_TRANSACTION 命令携带 CHECK_SERVICE_TRANSACTION 命令，同时获取服务的线程进入等待状态 waitForResponse()。Binder 驱动收到请求命令向 ServiceManager 的发送 BC_TRANSACTION 查询已注册的服务，会区分请求服务所属进程情况。

查询到直接响应 BR_REPLY 唤醒等待的线程。若查询不到将与 binder_procs 链表中的服务进行一次通讯再响应。

以startService为例来简单总结下执行流程：

3.1 从方法执行流程来看：

Client ：

1 AMP.startService 标记方法以及通过Parcel包装数据；

2 BinderProxy.transact 实际调用native的 android_os_BinderProxy_transact 传递数据；

3 获取BpServiceManager 与 BpBinder 同时会创建ProcessState。然后通过BpBinder执行transact，把真正工作交给IPCThreadState来处理；

4 IPC.transact 主要执行writeTransactionData，将上层传来的数据重新包装成binder_transaction_data，并将BC Protocol + binder_transaction_data结构体 写入mOut；

5 IPC waitForResponse talkWithDriver + 等待返回数据；

6 talkWithDriver 将数据进一步封装成binder_write_read，通过ioctl（BINDER_WRITE_READ）与驱动通信；

Kernel :

7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；

8 binder_ioctl_write_read 把用户空间数据ubuf拷贝到内核空间bwr；

9 binder_thread_write 当bwr写缓存有数据，则执行binder_thread_write；当写失败则将bwr数据写回用户空间并退出；

10 binder_transaction 找到目标进程binder_proc并插入数据到目标进程的线程todo队列，最终执行到它
时，将发起端数据拷贝到接收端进程的buffer结构体；

11 binder_thread_read 根据binder_transaction结构体和binder_buffer结构体数据生成新的binder_transaction_data结构体，写入bwr的read_buffer，当bwr读缓存有数据，则执行binder_thread_read；当读失败则再将bwr数据写回用户空间并退出；最后，把内核数据bwr拷贝到用户空间ubuf。

12 binder_thread_write + binder_ioctl BR命令和数据传递

Server:

13 IPC.executeCommand 解析kernel传过来的binder_transaction_data数据，找到目标BBinder并调用其transact()方法;

14 IPC.joinThreadPool 采用循环不断地执行getAndExecuteCommand()方法, 处理事务。当bwr的读写buffer都没有数据时,则阻塞在binder_thread_read的wait_event过程. 另外,正常情况下binder线程一旦创建则不会退出.

15 BBinder.transact 到Binder.exeTransact 调用 AMN.onTransact

16 AMN.onTransact 把数据传递到AMS.starService去执行

17 AMS.starService Server处理了Client的请求了

然后原路replay回去，talkWithDriver 到Kernel ，然后找到Client进程，把数据拷贝到read_buffer里，最终唤醒IPC，把反馈传递回AMP.startService。完成启动服务。

3.2 从通信协议流程来看：

非oneWay:

oneway:

oneway与非oneway区别: 都是需要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE. 主要区别在于oneway的通信收到BR_TRANSACTION_COMPLETE则返回,而不会再等待BR_REPLY消息的到来. 另外，oneway的binder IPC则接收端无法获取对方的pid.

3.3 从数据流来看

从用户空间开始：

进入驱动后：

回到用户空间：

参考：
http://gityuan.com/2016/09/04/binder-start-service/
http://gityuan.com/2015/11/28/binder-summary/
http://gityuan.com/2015/11/14/binder-add-service/
http://gityuan.com/2015/11/15/binder-get-service/

⑼ Android之Binder通信篇

Binder跨进程通信的本质是依赖内核驱动将属于不同Binder进程的数据，从原始进程复制到目标进程，这样就完成了跨进程通信了。

Binder通过独特的内存映射机制，在跨进程通信时，可以做到一次拷贝，两个空间同时使用！如下图：

Binder跨进程通信是要传递数据的，既然有数据必然要占用内存空间，Android系统规定每一个进程都有一块Binder内存区，也就是图1中的 共享内存 ，系统最多只能给该区域分配4M的物理内存，由于申请这块内存是通过系统的mmap函数完成的，所以整个映射机制又被称为mmap机制
为了把这部分说明白，就再盗图一张，命名图2吧！

对于Binder驱动，通过 binder_procs 链表记录所有创建的 binder_proc 结构体，binder 驱动层的每一个 binder_proc 结构体都与用户空间的一个用于 binder 通信的进程一一对应，且每个进程有且只有一个 ProcessState 对象，这是通过单例模式来保证的。在每个进程中可以有很多个线程，每个线程对应一个 IPCThreadState 对象，IPCThreadState 对象也是单例模式，即一个线程对应一个 IPCThreadState 对象，在 Binder 驱动层也有与之相对应的结构，那就是 Binder_thread 结构体。在 binder_proc 结构体中通过成员变量 rb_root threads，来记录当前进程内所有的 binder_thread。

Binder 线程池：每个 Server 进程在启动时创建一个 binder 线程池，并向其中注册一个 Binder 线程；之后 Server 进程也可以向 binder 线程池注册新的线程，或者 Binder 驱动在探测到没有空闲 binder 线程时主动向 Server 进程注册新的的 binder 线程。对于一个 Server 进程有一个最大 Binder 线程数限制，默认为16个 binder 线程，例如 Android 的 system_server 进程就存在16个线程。对于所有 Client 端进程的 binder 请求都是交由 Server 端进程的 binder 线程来处理的。