Android 组件化面试必备，Android-Binder机制及AIDL使用

通过ARouter在module间共享对象，实现module间通信。

比如：我们有一个账号模块 business:account ,提供了登录、登出、用户信息查询等业务。

同级的其他模块，如何跟账号模块通信？获取用户的登录状态以及用户相关信息？

public class AccountBean {

private String name;

private int age;

//…

}

public interface IAccountService extends IProvider {

void login(Context context);//登录

void logout(Context context);//登出

AccountBean getAccountBean();//获取账号信息

}

对外的数据结构和接口定义。

@Route(path = BusinessRoutePath.ModuleAccount.ACCOUNT)

public class AccountServiceImpl implements IAccountService {

//…

}

bussiness:account模块中的实现。

IAccountService accountService = ARouter.getInstance().navigation(IAccountService.class);

accountService.login(activity);

AccountBean bean = accountService.getAccountBean();

但是问题来了：

同层的其他模块，如何，能拿到ARouter的path？

同层的其他模块编译时，如何，共享AccountBean类、IAccountService接口？

这就是模块之间的编译隔离，带来的问题。

我们很自然的想到了framework模块，或者base层的其他模块。

我们只要将这些path定义、AccountBean类、IAccountService接口，下沉到base层,就可以实现编译上的代码共享。

如此一来，就带来了，另一个问题：代码的中心化问题。

​

2、代码的中心化

简单的path字符串定义，放在framework倒是还好。

如果所有business模块对外提供的接口和数据结构，都定义到framework的话，问题就有点严峻。

将会破坏：组件的 可替代性、可重用性、组件间耦合度

因为framework是基础模块嘛，所有business模块都依赖的模块，如此，不管你的business1模块是否依赖business2模块的对外接口，都会存在这一层依赖。

模块间的代码边界出现一些劣化。缺少了编译上的隔离。许多模块将会变得不够“独立”了。

可替代性、可重用性 越来越弱，想要替换或者复用某个business组件将变得越来越难。