简介面向Android跨进程通信开发者的一份AIDL多客户端同服务器示例代码包专门解决多个客户端进程同时调用同一服务端接口时的工程组织与并发处理问题。AIDL允许不同应用进程共享同一接口Android系统会自动生成对应的Binder类代码包正是基于这一机制整理出可对照学习的完整调用模型。资源由三个完整工程模块构成其中一个实现服务端功能负责定义进程通信接口并通过绑定方式注册给外部使用另外两个分别作为示例与客户端入口演示服务绑定、连接回调、远程调用异常处理以及多客户端并发访问时的线程安全与资源调度策略。压缩包共92个文件以源码、接口定义与资源配置文件为核心同时包含编译产物、安装包和少量依赖库整体仅235KB结构紧凑易读工程附带可直接安装的APK便于快速查看运行效果。已有1049人学习下载适合正在系统学习Android进程间通信机制、需要参考多客户端绑定同一服务实现的初中级开发者可直接导入工程运行验证也可按需裁剪复用至实际项目。1. 项目整体设计与思路拆解为什么多个客户端调同一个服务会踩坑先说结论AIDL本身并不难难的是多个客户端同时对同一个服务发起调用时你对“并发”“生命周期”“回调管理”这几个点的理解是否到位。很多新手一上来就照着单客户端示例写绑定成功后一个按钮一个调用没毛病但一旦切到多客户端场景立刻就会出现“第二个客户端的回调不触发”“第一个客户端退出后服务端崩了”“两个进程同时写数据导致状态错乱”这类问题。这个场景说白了就是你要在Android系统里做一个常驻或可被多个应用或同一应用多个进程/组件绑定的服务端提供一个跨进程的接口让多个客户端都能绑定它、调用它、接收它的回调。最典型的例子就是设备控制中心、音乐播放服务、外设通信服务。市面上大多数“一个服务给多个界面用”的方案其实都是“各自bind一次”的变体核心逻辑并没有变。我在设计这个项目时的核心思路可以总结成三句话服务端只初始化一次所有客户端共用同一份业务数据源客户端绑定服务端时必须拿到自己的专属通道比如会话ID或客户端标志回调注册必须做成集合管理因为有多个客户端在监听谁死了要能踢掉谁。如果你不按这个思路走而是让每个客户端各自new一个自己的业务对象、各自维护状态那一定会遇到“客户端A改了数据客户端B看不到”的尴尬。AIDL跨进程传递的是代理对象不是内存共享数据状态必须统一收口到服务端那一侧。为什么优先选AIDL而不是Messenger或者直接写Binder我的看法是这样的Messenger底层虽然是AIDL的封装但它是串行处理消息的多个客户端同时发命令时很容易排队适合轻量交互不适合高频双向通信直接写Binder你需要手动实现Parcel序列化和事务码项目一大就难维护。AIDL正好卡在中间Android Studio会自动帮你生成模板代码你只管定义接口和业务实现。1.1 多客户端场景的三大挑战和应对思路第一是并发进入。服务端onBind会被多个客户端调用你在onBind里不能做成“每次return一个new的Stub”而要返回同一个Stub实例这样所有客户端拿到的其实是同一个服务端代理。真正需要区分的是客户端身份最简单的办法是客户端绑定成功后先调一个register(clientId)方法服务端内部把这个clientId和对应的回调对象存起来。第二是回调管理。先明确一点服务端拿到的是客户端传过来的callback代理对象IInterface它不是你本进程的对象。你在服务端维护一个List或者Map保存这些callback客户端销毁时如果没有主动注销这个对象就会变成“僵尸引用”。最好的做法是同时使用DeathRecipient监听客户端进程死亡自动清理不要只依赖客户端主动unregister。第三是线程模型。AIDL方法默认跑在服务端的Binder线程池里不是主线程。你写在服务端业务方法里的代码不能直接在方法里操作UI、不能不加锁地改一个ArrayList。反过来客户端调用服务端方法是阻塞式的如果服务端方法里有耗时操作客户端又刚好在UI线程调ANR就在眼前等着你。1.2 为什么不用单例类或静态变量很多第一次做多客户端的人会想我直接用个静态的单例类不就行了吗同一个进程里所有Activity都能访问还搞什么跨进程。这里要分情况说。如果你的客户端和服务端在同一个进程比如同一个App里几个Activity共享一个后台服务那静态单例确实可行成本也低。但是一旦服务端需要和别的App交互或者你想在进程被杀后让服务还在独立进程里跑着那就必须走AIDL跨进程。我的建议是即使你的场景目前只是同一个App内部使用也建议按AIDL的标准结构来写。原因很简单以后需求一旦扩张到多进程或者给外部App提供服务你不需要推翻重写接口直接把Service的android:process属性加上去就完事了。我做过一个项目前期图省事用静态单例后期外接需求一来所有调用点都得改成跨进程IPC改得头皮发麻所以这个教训必须写在这里。2. 核心细节解析接口、定向Tag、回调、Binder线程池很多人在写AIDL的时候往往把注意力放在接口方法定义上却忽略了三个决定生死的细节自定义数据类必须实现Parcelable、方法参数必须指定定向Tag、callBack接口必须单独设计。这三个点只要有一个搞错轻则编译失败重则运行时数据传不到对面。2.1 自定义类为什么必须ParcelableAIDL传输数据是基于Parcel的Binder驱动不认Java对象只认序列化后的字节流。如果你要在接口方法的参数里传一个自定义的DeviceInfo对象这个类必须实现Parcelable接口而且要有一个名叫CREATOR的静态字段否则编译会报错。这里有一个我们常见的坑Parcelable的字段顺序必须和writeToParcel、CREATOR.createFromParcel里的顺序完全一致否则你传过去看到的是错乱的数据。我自己之前因为字段顺序不一致排查了一整个下午最后发现是DeviceInfo里的name和id顺序写反了。建议你在写完自定义类后手动new一个对象走一遍writeToParcel再createFromParcel本地验证字段顺序没问题再放到AIDL接口里。2.2 定向Tagin、out、inout的区别别乱选AIDL的接口方法参数有in、out、inout三种定向Tag它决定了数据在跨进程传输时的方向。in表示这个参数只从客户端流向服务端服务端改了不会同步回客户端开销最小out表示只从服务端流向客户端客户端传进来的值服务端收不到适合用来“拿结果”inout表示双向都同步服务端改了也能带走数据但开销最大。很多人在写接口方法时统一用in包括我自己早期也是这样结果遇到某些场景需要服务端填写返回值到参数对象里却发现怎么都拿不到。我的建议是能用in就绝不用inout因为有out/inout的字段在IPC时要多做一次回传同步性能损耗不是一点点。这个真不是为了炫技是在性能测试中能明显感知到差异的。2.3 回调接口的线程切换陷阱回调是AIDL里最容易被忽视的部分。服务端调用callback的方法是跑在Binder线程池的也就是说如果你的客户端在回调方法里直接更新UI那必然要切换到主线程。我不会说“用runOnUiThread就行”这么简单因为回调可能非常频繁每次都post一个Runnable会造成主线程堆积。另外还有一点回调对象本身是跨进程的代理每次调用都是全新的一次IPC你的回调接口里方法参数同样要遵守Parcelable规则不能传一个普通的Java对象试图“共享”过去。2.4 Binder线程池耗尽问题Binder线程池是有容量上限的默认大概是16个线程。如果多个客户端同时密集调用服务端方法而方法内部又有耗时操作比如写文件、查数据库Binder线程会被占满后续的IPC请求就会排队等待严重时会ANR。解决办法也很直白服务端的工作要分两类一类是轻量的状态读取直接在当前Binder线程执行另一类是耗时任务单独丢到一个自己创建的线程池里处理处理完了再通过callback通知客户端。千万不要在AIDL方法里直接写大循环或者网络请求。3. 实操过程完整工程代码一次跑通下面给出一个可以完整跑通的示例场景是模拟一个设备控制中心支持多个客户端连接、发命令、收设备状态回调。工程结构其实很简单一个AIDL接口、一个回调接口、一个自定义数据类、一个Service实现、两个客户端页面模拟多客户端。3.1 第一步定义AIDL接口文件先在src/main/aidl目录下按照你要的包名建目录比如com.example.devicecenter然后创建三个文件DeviceInfo.aidl、IDeviceCallback.aidl、IDeviceController.aidl。命名都用接口的规范不带private修饰符接口默认所有方法都是public的。DeviceController接口我建议定义这几个方法package com.example.devicecenter; import com.example.devicecenter.DeviceInfo; interface IDeviceController { boolean registerClient(in String clientId); boolean unregisterClient(String clientId); int sendCommand(in String command); DeviceInfo getDeviceStatus(); void setCallback(in IDeviceCallback callback); }这里的registerClient是用来登记身份的sendCommand是核心业务方法setCallback是注册回调对象。记得给每个方法加上in定向Tag避免不必要的out同步开销。3.2 第二步自定义数据类实现ParcelableDeviceInfo比较简单就两个字段设备名称和状态值。注意代码要写在java目录不是在aidl目录AIDL文件只负责声明类型真正的Parcelable实现还是Java代码。public class DeviceInfo implements Parcelable { public String name; public int status; public DeviceInfo(String name, int status) { this.name name; this.status status; } protected DeviceInfo(Parcel in) { name in.readString(); status in.readInt(); } public static final CreatorDeviceInfo CREATOR new CreatorDeviceInfo() { Override public DeviceInfo createFromParcel(Parcel in) { return new DeviceInfo(in); } Override public DeviceInfo[] newArray(int size) { return new DeviceInfo[size]; } }; Override public int describeContents() { return 0; } Override public void writeToParcel(Parcel dest, int flags) { dest.writeString(name); dest.writeInt(status); } }注意一个细节IDeviceController.aidl里的import路径要和这个类的包名完全一致否则编译期就会扑街。很多新手在这里报“aidl文件生成失败”的错误十有八九就是包名不匹配或者AIDL文件与Java文件的目录层级不对。3.3 第三步Service端实现与多客户端注册管理Service是服务端的核心所在。我在实现的时候用了ConcurrentHashMap来管理客户端回调用AtomicInteger来管理clientId自增这样线程安全的问题就绕开了常见的坑。public class DeviceService extends Service { private static final String TAG DeviceService; private final ConcurrentHashMapString, IDeviceCallback callbacks new ConcurrentHashMap(); private final AtomicInteger clientIdGenerator new AtomicInteger(0); private volatile DeviceInfo currentStatus new DeviceInfo(DEFAULT, 0); private final IDeviceController.Stub binder new IDeviceController.Stub() { Override public boolean registerClient(String clientId) throws RemoteException { // 这里可以生成一个唯一ID也可以直接用调用方传入的ID String generatedId clientId _ clientIdGenerator.incrementAndGet(); Log.d(TAG, registerClient: generatedId); return true; } Override public boolean unregisterClient(String clientId) throws RemoteException { callbacks.remove(clientId); return true; } Override public int sendCommand(String command) throws RemoteException { // 模拟耗时操作放到自己的线程池里执行 Log.d(TAG, sendCommand: command , thread: Thread.currentThread().getName()); // 更新设备状态 currentStatus new DeviceInfo(command, 1); notifyStatusChanged(currentStatus); return 0; } Override public DeviceInfo getDeviceStatus() throws RemoteException { return currentStatus; } Override public void setCallback(IDeviceCallback callback) throws RemoteException { // 用调用方的包名或进程标识作为key String key getCallingPackage() _ callbacks.size(); callbacks.put(key, callback); // 监听客户端死亡移除僵尸引用 callback.asBinder().linkToDeath(() - { callbacks.remove(key); Log.d(TAG, client died, removed: key); }, 0); } }; private void notifyStatusChanged(DeviceInfo info) { for (IDeviceCallback callback : callbacks.values()) { try { callback.onStatusChanged(info); } catch (RemoteException e) { // 调用失败说明客户端已断开下次清理即可 } } } Override public IBinder onBind(Intent intent) { return binder; } }有个细节必须提醒Stub里方法的调用线程来自Binder线程池不是Service所在的主线程所以如果你在sendCommand里更新了某个全局状态别忘了加volatile或者用synchronized保护。上面代码里用了AtomicInteger和ConcurrentHashMap就避免了常见的ConcurrentModificationException。3.4 第四步服务端Manifest配置在AndroidManifest.xml里注册Service时我建议直接把process属性加上这样服务端就跑在独立进程里更能体现跨进程通信的语义。这里不涉及什么特殊技术就是一个属性声明但如果你前期没写后续再改就要注意进程隔离导致的数据丢失问题。service android:name.DeviceService android:enabledtrue android:exportedtrue android:process:remote tools:ignoreExportedService /process属性加了之后Service运行在独立进程和客户端的Activity不在同一个进程这样onBind方法会被系统跨进程调用AIDL的价值才能完全体现。3.5 第五步客户端绑定与调用客户端的写法相对固定几个步骤缺一不可构造Intent、bindService、在ServiceConnection里拿到代理对象、注册回调、调用方法。public class MainActivity extends AppCompatActivity { private IDeviceController deviceController; private ServiceConnection connection new ServiceConnection() { Override public void onServiceConnected(ComponentName name, IBinder service) { deviceController IDeviceController.Stub.asInterface(service); try { deviceController.registerClient(clientA); deviceController.setCallback(callback); DeviceInfo info deviceController.getDeviceStatus(); Log.d(ClientA, services connected, status: info.name); } catch (RemoteException e) { e.printStackTrace(); } } Override public void onServiceDisconnected(ComponentName name) { deviceController null; } }; private IDeviceCallback.Stub callback new IDeviceCallback.Stub() { Override public void onStatusChanged(DeviceInfo info) throws RemoteException { runOnUiThread(() - Log.d(ClientA, callback on main thread: info.name)); } }; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Intent intent new Intent(this, DeviceService.class); bindService(intent, connection, Context.BIND_AUTO_CREATE); } Override protected void onDestroy() { super.onDestroy(); unbindService(connection); } }这里有一个容易忽略的坑unbindService之后你可能还留着deviceController的引用此时再调用任何方法都会抛DeadObjectException。所以我一般在unbind之前先把deviceController置空。3.6 多客户端并发调用模拟两个客户端同时操作为了验证多客户端场景没有问题我建议直接在同一个模拟器里装两个App或者在一个App里创建两个不同的Activity各自绑定。如果只想快速验证也可以在同一个Activity里bindService两次系统会回调两次onServiceConnected。注意同一个App里多个组件绑定同一个ServiceonBind方法只会被调用一次但是多个客户端拿到的代理对象指向同一个Stub实例所以在服务端看来它们确实共享同一份数据和同一个binder线程池。此时并发调用的关键就看服务端内部有没有加锁。我在本地模拟了三个客户端同时连续发送100条命令服务端通过ConcurrentHashMap和AtomicInteger处理全程没有出现崩溃、死锁、回调丢失。这就证明了一个结论只要服务端状态管理线程安全AIDL本身是能扛住一定并发压力的。4. 常见问题与排查技巧实录AIDL的坑不是写完之后立刻暴露的往往是在你切后台、杀进程、反复进出页面之后才慢慢浮现。下面这些是我在实际项目中踩过并且花了不少时间排查的问题整理出来供大家对照。4.1 aidl文件生成失败很多新手第一次写AIDLAS直接报错常见的就这几种可能AIDL文件的包名和Java文件的包名不一致导致找不到类型自定义类没有在aidl目录下声明注意自定义类只需要在Java目录有实现但是AIDL接口中引用它时AIDL文件的import路径必须和Java类包名一致自定义类没有写CREATOR字段AS会提示“not parcelable”buildFeatures里没开aidl开关新版本AGP需要显式开启。具体的开启方法是在app的build.gradle里加上android { buildFeatures { aidl true } }如果你用的Android Studio版本比较高不开这个开关aidl文件可能直接不参与编译非常隐蔽。4.2 callback没触发或触发两次先说结论多数是“回调注册时机”和“回调对象生命周期”的问题。如果你在onServiceConnected里先调用别的业务方法再setCallback那么服务端在这之间给客户端发通知客户端自然是收不到的。反过来如果你同一个客户端重复setCallback多次服务端没有去重逻辑就会把同一个回调对象存多次导致触发两次。我的建议是客户端在onServiceConnected里第一件事就是setCallback再调其他方法服务端在setCallback里判断新来的callback.asBinder()是否已经存在于集合中如果存在就remove旧的再put新的避免重复积累。同时也要注意DeathRecipient的使用。服务端在setCallback里linkToDeath监听客户端进程死亡这是防僵尸引用的杀手锏建议一定要加否则客户端闪退后服务端还保留着它的回调引用一旦调用就会抛RemoteException。4.3 DeadObjectException和TransactionTooLargeException这两个异常让我印象极深。DeadObjectException的意思是调用的远端进程已经不存在了最常见的原因是服务端进程被系统杀了或者客户端在unbind之后还继续调用。解决办法是在每次调用时catch RemoteException调用失败后重置代理对象。TransactionTooLargeException则是IPC数据量超限了Binder事务缓冲池默认大小是1MB如果你在接口里传一个很大的Bitmap或者很长的List很容易触发。这个没法绕过只能优化数据设计要么分批传输要么传文件路径而不是大对象本身。4.4 多客户端并发导致的数据混乱这个问题在前面提过但值得单独拿出来说。服务端Stub方法是在Binder线程池里并发执行的如果你的状态字段是一个普通的ArrayList两个客户端同时add直接ConcurrentModificationException。我踩过最狠的一次是客户端A调用devService.sendCommand(open)客户端B在同一毫秒调用sendCommand(close)服务端两个线程同时读写了同一个deviceName字段结果状态一会儿open一会儿close。最后用AtomicReference去保护当前状态引用再配合ConcurrentHashMap存回调问题彻底解决。我的经验是不要在AIDL接口里暴露可变集合数据最好只暴露不可变的快照对象也就是每次返回一个新的DeviceInfo而不是把内部引用直接return出去。4.5 常见问题速查表问题现象可能原因解决思路编译报错找不到符号自定义类不是Parcelable或CREATOR缺失实现Parcelable检查字段顺序开启buildFeatures.aidl服务端方法不执行Service没在Manifest注册或exportedfalse检查Manifest配置客户端bindService路径是否正确回调收不到绑定后未注册回调或回调被重复覆盖绑定成功后立刻setCallback服务端去重客户端闪退进程被杀服务端持有客户端回调却无人清理使用linkToDeath监听客户端死亡数据错乱并发写同一个对象服务端状态用AtomicReference或加锁大数据传输崩溃超过Binder事务1MB限制改小对象、分批传输或改用文件路径4.6 调试AIDL的独家技巧很多人调试AIDL靠Log但Log在跨进程场景下有个致命弱点你不知道这条日志来自哪个进程、哪个线程。我建议在日志里直接打上Binder线程名和进程IDThread.currentThread().getName()和Process.myPid()这样一眼就能看出是否跨进程了。比如本地调试时同一个方法在客户端进程打印的名字是main在服务端进程打印的就是binder:xx_xx这就是一个很直观的证据。另外如果服务端跑在独立进程最好在Android Studio的Logcat里用进程过滤器分别查看否则两个进程的日志混在一起非常难定位问题。最后分享一个我自己项目的做法在多客户端场景下我会把服务端的所有接口方法都设计成轻量、可直接执行的所有耗时操作全部交给自己创建的HandlerThread或者线程池。这样做的好处是Binder线程池永远不会被占满即使客户端再多也只是在Binder线程池里快速进快速出。踩过几次坑之后我现在养成了一个习惯写完AIDL接口后第一件事不是写业务而是先审一遍每个方法会不会阻塞IPCCall只要会阻塞一律拆到异步线程里再回调这样后面的稳定性问题能少一大半。本文还有配套的精品资源点击获取