初步列下思路，日後整理
需求：
在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的調度開銷，提高資源的利用率。