初步列下思路，日后整理
需求：
在Android FW中，为第三方APP设计提供功能的API
策略：
1. 使用jar或者aar的形式提供，千万不要提供AIDL文件供对方使用
原因如下：
- Android sdk中没有直接提供AIDL给我们，因为AIDL API并没有这样形式给我们使用。因为AIDL的方式，没有标准的API容易使用。
- 在client和server代码都是自己可以负责控制的情况下，AIDL适合于这个场景
- AIDL是具体实现方式，不应该作为API暴露给客户代码。如果某个API使用AIDL实现，客户代码也依赖于这个AIDL。后面AIDL不能满足于客户需要了，比如该API功能由于性能问题，不能跨进程实现。这个时候，就必须要改动客户代码。那么，设计就失败了。
2. API应该根据功能的聚合，分为各个模块。
可以参照Android FW的：ActivityManager, PackageManager, WifiMananger, LocationManager。分为：AAAMananger, BBBMananger...
3. 在实现AAAManager对应的服务端AAAService的过程中，需要注意的是：如果是不耗时的API, 比如状态取得，可以设计为同步API；如果是耗时API，比如打开/关闭功能的，可以设计为异步API.
4. 在设计AAAService的过程中，需要为异步API，设计一个专门的HandlerThread。
千万不能直接在BinderThread里面进行业务操作，原因：
- BinderThread是系统Thread，应该只干和Binder相关的工作，即跨进程相关的事情。
- 一个进程的BinderThread有数量限制，为16个。从Binder_1, ....Binder_10, Binder_A,...Binder_F. 如果直接在BinderThread里面进行耗时操作，很容易导致Binder资源耗尽。Android系统大部分的跨进程通信的基础都是binder，如果binder资源耗尽，FW连广播都无法正常发送给该应用程序。
- 在专门的HandlerThread里面，轮流有序进行耗时API的操作。可以避免多个BinderThread对业务共享资源的竞争，避免thread的调度开销，提高资源的利用率。