回顧一下整個MediaProvider的啟動和創建過程，如圖7-3所示。 :-:  圖7-3 MediaProvider的啟動和創建流程 整個流程相對比較簡單。讀者在分析時只要注意installProvider這個函數在目標進程和客戶端進程中被調用時的區別即可。這里再次強調： - 目標進程調用installProvider時，傳遞的第二個參數為null，使內部通過Java反射機制真正創建目標CP實例。 - 客戶端調用installProvider時，其第二個參數已經通過查詢AMS得到。該函數真正的工作只不過是引用計數控制和設置訃告接收對象罷了。 至此，客戶端進程和目標進程通信的通道IContentProvider已經登場。除此之外，客戶端進程和目標CP還建立了非常緊密的關系，這種關系造成的后果就是一旦目標CP進程死亡，AMS會殺死與之有關的客戶端進程。不妨回顧一下與之相關的知識點： - 該關系的建立是在AMS getContentProviderImpl函數中調用incProviderCount完成的，關系的確立以ContentProviderRecorder保存客戶端進程的ProcessRecord信息為標識。 - 一旦CP進程死亡，AMS能根據該ContentProviderRecorder中保存的客戶端信息找到使用該CP的所有客戶端進程，然后再殺死它們。 客戶端能否撤銷這種緊密關系呢？答案是肯定的，但這和Cursor是否關閉有關。這里先簡單描述一下流程： - 當Cursor關閉時，ContextImpl的releaseProvider會被調用。根據前面的介紹，它最終會調用ActivityThread的releaseProvider函數。 - ActivityThread的releaseProvider函數會導致completeRemoveProvider被調用，在其內部根據該CP的引用計數判斷是否需要調用AMS的removeContentProvider。 - 通過AMS的removeContentProvider將刪除對應ContentProviderRecord中此客戶端進程的信息，這樣一來，客戶端進程和目標CP進程的緊密關系就蕩然無存了。 至此，本章第一條分析路線就介紹完畢。 * * * * * **提示**：讀者可能覺得，這條路線是對第6章的補充和延續。不過，雖然目標進程由AMS創建和啟動，而且ContentProvider的發布也需和AMS交互，但是對于ContentProvider來說，我們更關注客戶端和目標進程中ContentProvider實例間的交互。事實上，客戶端得到IContentProvider Bp端對象后，即可直接與目標進程的CP實例交互，也就無需借助AMS了，所以筆者將這條路線放到了本章進行分析。 * * * * *