1. 项目概述组件化通信的“无感”与“反向”调用在Android组件化架构的深水区我们常常会遇到一个经典的“鸡生蛋还是蛋生鸡”的困境。一方面我们追求极致的解耦希望宿主应用主App对业务组件Module的内部实现一无所知最好连组件的接口都不需要依赖或实现真正做到“即插即用”。另一方面业务组件在运行时又不可避免地需要与宿主进行交互比如获取全局的用户信息、调用宿主封装的统一网络库、或者请求宿主打开一个特定的页面。传统的接口下沉、依赖注入如Dagger或事件总线如EventBus方案要么让宿主背负了沉重的接口依赖包袱要么在类型安全和生命周期管理上存在短板。这个项目标题——“Android多模块组件化开发宿主无需实现组件接口且组件能够调用宿主方法并传值回来”——精准地戳中了这个痛点。它描述了一种理想的通信状态单向透明依赖与双向能力调用。简单来说就是组件可以单向依赖宿主或一个公共基础库但宿主对组件“零感知”同时组件能像调用本地方法一样安全、便捷地调用宿主的能力并得到异步或同步的返回值。这不仅仅是技术上的炫技它有极强的现实意义。想象一下你有一个庞大的电商App商品、订单、支付、用户中心都被拆成了独立组件。支付组件在处理完支付后需要通知宿主更新用户资产、刷新订单列表甚至触发一个全局的弹窗提示。如果每增加一个这样的交互都需要宿主去实现一个对应的接口那么宿主的代码会迅速膨胀且与组件耦合度急剧上升违背了组件化的初衷。我们的目标是让宿主成为一个稳定的“能力平台”组件则是其上灵活运行的“小程序”小程序可以随时调用平台的能力而平台无需关心有多少个小程序、它们具体要做什么。2. 核心设计思路服务发现与协议约定要实现“宿主无感组件可调用”核心在于解耦通信的“契约”与“实现”。我们不能让宿主去实现一个由组件定义的接口那意味着宿主依赖了组件而应该让组件去访问一个由宿主或中间层提供的、标准化的“服务”。这个思路借鉴了微服务架构中的“服务发现”与“API网关”概念。2.1 传统方案的瓶颈分析在深入新方案前我们先看看常见方案的不足接口下沉Interface Module创建一个公共的interface模块定义所有通信接口。宿主和组件都依赖此模块并各自实现。问题在于宿主需要实现所有组件可能用到的接口导致宿主代码与接口模块强绑定任何接口变动都可能波及宿主。EventBus/消息总线组件发送事件宿主监听并处理。这种方式实现了完全解耦但丢失了类型安全和调用语义。事件是“广播”出去的难以实现一对一的请求/响应模式特别是需要返回值时非常别扭且难以调试和追踪调用链路。ARouter等路由框架的拦截器Interceptor常用于页面跳转的AOP处理虽然能进行一些逻辑拦截但其设计初衷并非用于通用的方法调用与返回值传递用于复杂业务通信显得不够直观和直接。2.2 新方案的核心能力网关Capability Gateway我们的设计围绕一个核心概念展开能力网关。它不是一个具体的类而是一种设计模式。其核心组件包括服务协议Protocol定义能力的抽象描述通常是一个简单的interface或data class存放于基础库Base Module中。宿主和组件都依赖此基础库。关键点协议只定义能力“是什么”方法签名、参数、返回值类型不定义“谁来实现”或“怎么调用”。服务提供者Provider在宿主中会有一个全局的注册中心用于注册各种协议的具体实现。这个提供者对外暴露的是基于协议的能力。服务调用者Invoker在组件中通过一个统一的“网关客户端”发起调用。客户端根据协议描述找到宿主中对应的提供者执行方法并返回结果。通信桥梁Bridge负责连接宿主内的提供者和组件内的调用者。由于它们处于不同的ClassLoader如果是动态加载或模块如果是静态编译中需要一种机制来序列化请求、传递参数、执行方法并返回结果。这里通常利用Android的Binder机制如AIDL或反射但我们会对其进行高度封装对使用者透明。整个流程可以类比为“快递服务”组件寄件人不需要知道宿主收件人小区的具体楼栋和门牌号它只需要填写一份标准快递单协议交给快递柜能力网关。快递柜系统通信桥梁根据快递单信息自动派件给小区内的具体收件人服务提供者并将签收结果返回值通过快递柜返回给寄件人。3. 关键技术实现与选型理论清晰后我们来看具体实现。这里提供两种主流且经过实战检验的实现路径基于反射注解的轻量级方案和基于AIDL的高性能标准化方案。3.1 方案一轻量级反射与注解驱动此方案适合大多数静态编译的组件化项目追求简单、直观对性能要求不是极端苛刻的场景。3.1.1 定义通信协议Protocol首先在基础模块base或core中定义协议。协议应尽可能简单使用Parcelable或Serializable对象进行数据传递。// 在 base 模块中 interface UserServiceProtocol { fun getCurrentUser(): UserInfo? fun updateUserAvatar(avatarPath: String, callback: UpdateCallback) } data class UserInfo(val userId: String, val userName: String) : Parcelable interface UpdateCallback { fun onSuccess(url: String) fun onFailed(error: String) }注意回调接口UpdateCallback也必须定义在基础模块中并确保可序列化。对于复杂回调可以考虑使用Parcelable。3.1.2 宿主侧服务注册与管理在宿主App的Application或一个专门的初始化类中建立服务注册中心。// 在 host 模块中 object ServiceRegistry { private val serviceMap ConcurrentHashMapClass*, Any() fun T registerService(protocolClass: ClassT, implementation: T) { serviceMap[protocolClass] implementation as Any } Suppress(UNCHECKED_CAST) fun T getService(protocolClass: ClassT): T? { return serviceMap[protocolClass] as? T } } // 在宿主Application中初始化 class MyApplication : Application() { override fun onCreate() { super.onCreate() // 注册宿主提供的服务实现 ServiceRegistry.registerService(UserServiceProtocol::class.java, UserServiceImpl()) // 可以注册更多服务... } } // 宿主对协议的具体实现 class UserServiceImpl : UserServiceProtocol { override fun getCurrentUser(): UserInfo? { // 从本地SP或内存缓存中获取用户信息 return ... } override fun updateUserAvatar(avatarPath: String, callback: UpdateCallback) { // 执行上传头像的网络请求 thread { try { val resultUrl uploadToServer(avatarPath) runOnUiThread { callback.onSuccess(resultUrl) } } catch (e: Exception) { runOnUiThread { callback.onFailed(e.message ?: Unknown error) } } } } }3.1.3 组件侧透明化调用封装在组件中我们不能直接引用ServiceRegistry因为组件不应依赖宿主模块我们需要一个外观类Facade来封装调用逻辑。这个外观类可以放在基础模块或者每个组件自己维护一个轻量级SDK。// 在 base 模块中或组件的独立工具模块中 object CapabilityGateway { /** * 同步调用宿主服务 * param protocolClass 协议接口的Class对象 * param block 在获取到服务实例后执行的代码块 */ fun T, R callServiceSync(protocolClass: ClassT, block: (T) - R): R? { val service try { // 关键步骤通过反射调用宿主注册中心。这里需要约定好注册中心的类名和方法名。 val registryClass Class.forName(com.example.host.ServiceRegistry) val getServiceMethod registryClass.getDeclaredMethod(getService, Class::class.java) getServiceMethod.invoke(null, protocolClass) as? T } catch (e: Exception) { Log.e(CapabilityGateway, Get service failed for ${protocolClass.simpleName}, e) null } return service?.let { block(it) } } /** * 异步调用宿主服务带回调 * 使用协程或普通线程池简化异步操作 */ fun T callServiceAsync( protocolClass: ClassT, dispatcher: CoroutineDispatcher Dispatchers.IO, block: suspend (T) - Unit ) { CoroutineScope(Dispatchers.Main).launch { val service withContext(dispatcher) { try { val registryClass Class.forName(com.example.host.ServiceRegistry) val getServiceMethod registryClass.getDeclaredMethod(getService, Class::class.java) getServiceMethod.invoke(null, protocolClass) as? T } catch (e: Exception) { null } } service?.let { block(it) } } } }3.1.4 在组件中使用在支付组件的某个ViewModel或Fragment中调用宿主服务变得非常简单// 在 payment 组件中 fun refreshUserInfo() { // 同步调用示例 val currentUser CapabilityGateway.callServiceSync(UserServiceProtocol::class.java) { service - service.getCurrentUser() } currentUser?.let { updateUI(it) } // 异步调用示例 CapabilityGateway.callServiceAsync(UserServiceProtocol::class.java) { service - service.updateUserAvatar(localPath) { resultUrl - // 此回调在宿主中触发但执行在组件的UI线程通过runOnUiThread showToast(头像已更新: $resultUrl) } } }3.1.5 方案一实操心得与避坑指南性能反射调用有一定性能开销但对于不频繁的UI级交互如按钮点击后调用完全可以接受。避免在循环或高频逻辑中使用。健壮性反射调用需要处理各种异常ClassNotFoundException,NoSuchMethodException,InvocationTargetException等务必在封装层做好异常捕获和降级处理如返回null或默认值。混淆这是最大的坑ProGuard或R8会混淆类名和方法名导致反射失败。必须在宿主和组件的混淆规则中对协议接口类、注册中心类及其公开方法添加keep规则。# 在宿主和组件的proguard-rules.pro中 -keep class com.example.base.** { *; } # 保持基础模块所有类 -keep class com.example.host.ServiceRegistry { *; } # 保持宿主注册中心 -keepclasseswithmembers class * { public methods; } // 谨慎使用或针对特定接口类类型安全虽然协议接口提供了编译时类型安全但反射调用环节是类型擦除的。确保传递的参数和返回值类型是Parcelable或基本类型避免复杂泛型。初始化时机确保宿主的服务注册在组件首次调用前完成。通常放在Application.onCreate()中是安全的。3.2 方案二基于AIDL的标准化通信当你的组件可能需要动态加载插件化或者对性能有更高要求希望通信过程更标准化、可监控时AIDL是更强大的选择。它利用了Android系统级的Binder IPC机制天生支持跨进程也适用于同一进程内是系统组件通信的基石。3.2.1 定义AIDL接口在基础模块中创建AIDL文件。AIDL接口定义了一套严格的跨进程通信契约。// IHostCapabilityManager.aidl package com.example.base; import com.example.base.UserInfo; import com.example.base.IUpdateCallback; interface IHostCapabilityManager { // 同步方法 UserInfo getCurrentUser(); // 异步方法通过回调接口传递结果 void updateUserAvatar(in String avatarPath, in IUpdateCallback callback); } // IUpdateCallback.aidl package com.example.base; interface IUpdateCallback { void onSuccess(in String resultUrl); void onFailed(in String error); }定义好AIDL后Android Studio会自动生成对应的Java/Kotlin Stub和Proxy类。UserInfo也必须是一个Parcelable对象。3.2.2 宿主侧实现并发布Service宿主需要实现AIDL接口并通过一个Service将其发布出去。// 在 host 模块中 class HostCapabilityService : Service() { private val binder object : IHostCapabilityManager.Stub() { override fun getCurrentUser(): UserInfo { return UserServiceImpl().getCurrentUser() ?: UserInfo(, Guest) } override fun updateUserAvatar(avatarPath: String, callback: IUpdateCallback) { UserServiceImpl().updateUserAvatar(avatarPath, object : UpdateCallback { override fun onSuccess(url: String) callback.onSuccess(url) override fun onFailed(error: String) callback.onFailed(error) }) } } override fun onBind(intent: Intent?): IBinder binder }在AndroidManifest.xml中注册该Service并可以设置一个自定义的action以便组件绑定。service android:name.HostCapabilityService android:exportedtrue !-- 允许其他应用绑定同一应用内组件更安全 -- intent-filter action android:namecom.example.host.action.CAPABILITY_SERVICE / /intent-filter /service3.2.3 组件侧绑定服务与调用组件需要绑定宿主发布的Service并通过获得的Binder代理对象进行调用。// 在组件模块中 class HostServiceConnector(private val context: Context) { private var capabilityManager: IHostCapabilityManager? null private var isBound false private val connection object : ServiceConnection { override fun onServiceConnected(name: ComponentName?, service: IBinder?) { capabilityManager IHostCapabilityManager.Stub.asInterface(service) isBound true Log.d(Connector, Host capability service connected.) } override fun onServiceDisconnected(name: ComponentName?) { capabilityManager null isBound false Log.d(Connector, Host capability service disconnected.) } } fun connect() { val intent Intent().apply { action com.example.host.action.CAPABILITY_SERVICE // 对于同一应用内的组件最好使用显式Intent更安全 setPackage(context.packageName) } context.bindService(intent, connection, Context.BIND_AUTO_CREATE) } fun disconnect() { if (isBound) { context.unbindService(connection) isBound false } } fun getCurrentUser(): UserInfo? { return if (isBound) { try { capabilityManager?.getCurrentUser() } catch (e: RemoteException) { null } } else { null } } // 提供异步调用方法 fun updateUserAvatar(path: String, onSuccess: (String) - Unit, onFailed: (String) - Unit) { if (!isBound) { onFailed(Service not connected) return } try { val callback object : IUpdateCallback.Stub() { override fun onSuccess(resultUrl: String) { // 注意回调执行在Binder线程池需要切回主线程更新UI Handler(Looper.getMainLooper()).post { onSuccess(resultUrl) } } override fun onFailed(error: String) { Handler(Looper.getMainLooper()).post { onFailed(error) } } } capabilityManager?.updateUserAvatar(path, callback) } catch (e: RemoteException) { Handler(Looper.getMainLooper()).post { onFailed(e.message ?: Remote call failed) } } } }在组件的Activity或Application中管理连接器的生命周期class PaymentActivity : AppCompatActivity() { private lateinit var connector: HostServiceConnector override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) connector HostServiceConnector(applicationContext) connector.connect() } override fun onDestroy() { super.onDestroy() connector.disconnect() } private fun someMethod() { val user connector.getCurrentUser() connector.updateUserAvatar(path/to/avatar, onSuccess { url - showToast(Success: $url) }, onFailed { error - showToast(Error: $error) } ) } }3.2.4 方案二实操心得与避坑指南性能与稳定性AIDL基于Binder是Android系统最优化的IPC机制性能远高于普通反射。同时系统负责管理Service的生命周期和连接状态比手动反射更稳定。异步回调与线程AIDL的回调方法onSuccess,onFailed默认在Binder线程池中执行绝对不能在其中直接操作UI。必须通过Handler或runOnUiThread切换到主线程。Service绑定管理绑定和解绑Service必须成对出现最好在组件的onCreate/onDestroy或onStart/onStop中管理防止内存泄漏和连接泄露。安全性如果组件是动态加载的插件确保宿主Service的intent-filter和权限设置得当。对于同一应用内组件使用setPackage(context.packageName)的显式Intent是最佳实践避免被其他应用误绑定。接口版本管理AIDL接口一旦发布修改如增删方法需要谨慎要考虑向后兼容性。可以通过增加新方法、保留旧方法的方式演进。复杂数据传递AIDL支持的数据类型有限基本类型、String、CharSequence、Parcelable、List/Map等。传递自定义对象必须实现Parcelable接口。对于非常复杂的对象考虑将其拆解或序列化为JSON字符串传递。4. 两种方案的对比与选型建议为了更直观地帮助你选择我将两种方案的核心差异总结如下表特性维度方案一反射注解方案二AIDL实现复杂度低。只需定义接口、实现注册、封装反射调用。中高。需定义AIDL、实现Service、管理绑定生命周期。性能一般。反射调用有开销适用于低频操作。高。系统级Binder IPC性能最优。跨进程支持不支持。依赖同一虚拟机内的ClassLoader。原生支持。是Android标准的跨进程通信方案。类型安全编译时接口定义安全运行时反射环节有风险。高。AIDL编译器会生成强类型Stub/Proxy序列化严格。健壮性依赖混淆配置异常处理需完善。高。系统管理连接异常传递清晰RemoteException。适用场景静态编译的组件化模块间通信追求快速落地。插件化、需要高稳定性/高性能通信、或未来可能跨进程的场景。调试难度较难。反射错误日志可能不直观。相对容易。可使用adb shell dumpsys activity services等工具查看服务状态。生命周期管理简单无显式生命周期。需要主动管理Service的绑定与解绑。选型建议如果你的项目是纯静态编译的组件化模块都在同一个APK内通信频率不高且希望架构简单、快速上线方案一反射是更轻快的选择。重点做好混淆配置和异常包装即可。如果你的项目涉及插件化动态加载或者你对通信的稳定性、性能有较高要求或者预见未来部分功能可能独立为进程如保活、大内存计算那么方案二AIDL是更专业和可持续的选择。虽然前期搭建稍复杂但它提供了更坚实的通信基础。5. 高级优化与扩展思考无论选择哪种基础方案在实际大型项目中我们还需要考虑更多工程化问题。5.1 服务降级与熔断在微服务架构中服务可能不可用。我们的“能力网关”也应具备类似容错能力。降级当调用宿主服务失败时应有一个默认的降级策略。例如获取用户信息失败则返回一个匿名的Guest用户对象调用支付状态更新失败则记录日志并提示用户“网络不畅请稍后查看”。熔断如果某个服务连续失败多次可以暂时“熔断”在一段时间内不再尝试调用直接返回降级结果避免资源浪费和连锁故障。可以引入简单的计数器来实现。在网关封装层加入这些逻辑object RobustCapabilityGateway { private val failureCount ConcurrentHashMapString, AtomicInteger() private const val FAILURE_THRESHOLD 3 private const val CIRCUIT_BREAKER_TIME 30000L // 30秒 fun T, R callServiceWithFallback( protocolClass: ClassT, fallback: () - R?, block: (T) - R? ): R? { val key protocolClass.name val failures failureCount.getOrPut(key) { AtomicInteger(0) } // 检查熔断器 if (failures.get() FAILURE_THRESHOLD) { Log.w(RobustGateway, Circuit breaker open for $key, using fallback.) return fallback() } return try { val result CapabilityGateway.callServiceSync(protocolClass, block) // 调用成功重置失败计数 failures.set(0) result } catch (e: Exception) { // 调用失败计数1 val count failures.incrementAndGet() Log.e(RobustGateway, Call failed for $key, count$count, e) if (count FAILURE_THRESHOLD) { // 触发熔断设置一个恢复定时器 CoroutineScope(Dispatchers.IO).launch { delay(CIRCUIT_BREAKER_TIME) failures.set(0) // 30秒后重置熔断器 Log.i(RobustGateway, Circuit breaker reset for $key) } } fallback() // 返回降级结果 } } }5.2 通信监控与日志在调试和排查问题时清晰的通信日志至关重要。可以在网关的入口和出口处添加日志埋点记录调用的协议、参数、耗时、成功与否。fun T, R callServiceWithLogging(protocolClass: ClassT, block: (T) - R?): R? { val startTime System.currentTimeMillis() val protocolName protocolClass.simpleName Log.d(GatewayLog, Calling service: $protocolName) return try { val result CapabilityGateway.callServiceSync(protocolClass, block) val cost System.currentTimeMillis() - startTime Log.d(GatewayLog, Service [$protocolName] succeeded in ${cost}ms) result } catch (e: Exception) { val cost System.currentTimeMillis() - startTime Log.e(GatewayLog, Service [$protocolName] failed in ${cost}ms: ${e.message}) null } }更进一步可以将这些日志上报到监控平台绘制服务调用成功率和耗时图表为性能优化和稳定性建设提供数据支撑。5.3 面向接口的测试解耦的一大好处是便于测试。对于组件侧的代码我们可以轻松地为“能力网关”创建Mock实现从而在单元测试中模拟宿主的各种响应而不需要启动整个宿主App。// 在组件的测试代码中 class PaymentViewModelTest { Test fun testRefreshUserInfoWithMock() { // 1. 创建Mock网关 val mockGateway object : ICapabilityGateway { // 定义一个网关接口 override fun getCurrentUser(): UserInfo? UserInfo(test_user, Mock User) } // 2. 注入到被测ViewModel可通过构造函数或依赖注入框架 val viewModel PaymentViewModel(mockGateway) // 3. 执行测试逻辑 viewModel.refreshUserInfo() // 4. 验证结果 assertEquals(Mock User, viewModel.userName.value) } }这种测试方式使得组件的单元测试可以独立、快速运行极大提升了开发效率。6. 常见问题排查与实战技巧在实际落地过程中你肯定会遇到各种“坑”。这里记录了一些典型问题及其解决方案。6.1 问题反射调用时报ClassNotFoundException或NoSuchMethodException排查步骤检查类名确认通过Class.forName()传入的宿主注册中心类全限定名是否正确包括包名。检查混淆这是最常见的原因。确保在proguard-rules.pro中为宿主注册中心类、所有协议接口类添加了-keep规则。可以尝试在打包后的APK用反编译工具如jadx打开中直接搜索该类名看是否被混淆了。检查依赖确保组件模块的编译类路径compile classpath或运行时类路径能访问到宿主模块的类。在静态编译中这通常意味着宿主模块需要被声明为api依赖如果使用Gradle或者打包进APK。6.2 问题AIDL调用成功但回调方法不执行或不在主线程排查步骤确认回调对象存活确保传递给AIDL方法的回调对象IUpdateCallback.Stub()没有被GC回收。如果是匿名内部类请确保其被宿主Service的Binder对象持有。检查线程切换牢记AIDL回调运行在Binder线程池。任何更新UI的操作必须在主线程执行。检查你的回调实现中是否使用了Handler(Looper.getMainLooper())或runOnUiThread进行切换。宿主端回调执行在宿主Service的实现中确保你触发了回调。例如网络请求是异步的要在请求的成功/失败回调中调用callback.onSuccess()或callback.onFailed()。6.3 问题传递自定义Parcelable对象时崩溃排查步骤CREATOR字段确保你的Parcelable类中有一个名为CREATOR的静态字段且其类型是Parcelable.CreatorT。这是Android系统反序列化对象的钩子。类加载器在writeToParcel和CREATOR.createFromParcel中读写字段的顺序必须完全一致。一个字段写漏或读错顺序都会导致崩溃。跨模块引用确保该Parcelable类在基础模块中定义并且宿主和组件依赖的是同一个基础模块版本。如果组件和宿主依赖了不同版本的基础模块即使类名相同也会被视为不同的类导致ClassCastException。6.4 技巧使用Kotlin的扩展函数和DSL优化调用体验对于方案一我们可以利用Kotlin的特性让调用更优雅// 定义扩展函数 inline fun reified T : Any, R callHostService(noinline block: (T) - R): R? { return CapabilityGateway.callServiceSync(T::class.java, block) } // 使用起来非常简洁 val user callHostServiceUserServiceProtocol { it.getCurrentUser() }对于方案二可以创建一个DSL来简化异步调用class HostServiceDSL(private val connector: HostServiceConnector) { suspend fun T withService(block: suspend (IHostCapabilityManager) - T): T? { return withContext(Dispatchers.IO) { try { val manager connector.getManager() // 假设connector提供同步获取manager的方法 manager?.let { block(it) } } catch (e: RemoteException) { null } } } } // 使用 val dsl HostServiceDSL(connector) viewModelScope.launch { val user dsl.withService { it.getCurrentUser() } user?.let { updateUI(it) } }6.5 技巧使用ContentProvider进行“无绑定”服务发现进阶这是一个更巧妙但稍复杂的方法适用于不想管理Service绑定生命周期的情况。宿主可以创建一个ContentProvider在其onCreate()中初始化服务注册中心。组件则通过ContentProvider的call()方法传递协议名和序列化的参数来调用宿主服务。宿主ContentProvider的call()方法内部解析请求从注册中心找到服务并执行然后返回序列化结果。这种方式对组件来说是完全无绑定的但需要自己设计一套请求/响应的序列化协议复杂度较高可作为知识扩展。7. 总结与个人体会走到这里我们已经完整地拆解了“宿主无感组件可调用”这一组件化通信难题的两种主流解法。从最直观的反射封装到系统级的AIDL通信再到容错、监控、测试等工程化扩展这套架构的核心思想始终是**“约定优于配置契约隔离实现”**。我个人在多个大型项目中实践过这两种方案。早期项目为了快速验证采用了反射方案它让我们在两周内就实现了核心业务的组件化拆分和通信。随着项目复杂度提升和插件化需求的出现我们逐步迁移到了AIDL方案。迁移过程并不轻松需要重写通信层和重新设计接口但带来的长期收益是显著的通信更稳定性能监控数据更完善也为后续的动态化打下了基础。一个很深的体会是技术选型没有银弹。反射方案在简单场景下的“快”就是它的最大优势而AIDL方案的“稳”和“强”则支撑了更复杂的架构演进。关键在于你要非常清楚自己项目当前和未来一段时间的核心诉求是什么。如果追求快速迭代和验证别怕用反射如果追求长期稳定和扩展性早点上AIDL是更负责任的做法。最后无论用哪种方案良好的接口设计、清晰的文档哪怕只是协议接口的注释和充分的测试都比具体的技术实现更重要。因为组件化通信的本质是团队协作的契约。把这些约定理清楚、写明白、测透彻才能让各个模块像精密的齿轮一样既独立运转又协同工作。
