詳細介紹Android配置信息內容
有一堆接口標準封裝完整的組件放在哪里，想用的時候取上幾個一搭配，整個程序就構建完成了，但前提是要深入理解到底什么是Android配置信息，及他的信息是怎么完成。
在這個配置文件中，不僅會描述一些應用相關的信息，很重要的，會包含一個應用中所有組件的信息。如果你派生Activity或者Service實現了一個相關的類。這只是把它組件化的第一步，你需要把這個類的相關信息寫到Android配置信息中，它才會作為一個組件被應用到，否則只能默默無聞的黯淡度過余生。
擺了一幅圖出來，這次不是偷來的，是敝帚自珍原創，所以沒有意外的畫的很丑，但基本還是可以體現出一些意思。在In Others的部分。這里是一般平臺應用之間通信和交互的模型，每個應用都有很強烈的應用邊界（往往表現為進程邊界...），App 1的還是App 2的，分得很是清楚。
每個應用內部，都有自己的邏輯去切分功能組件，這樣的切分通常沒有什么標準，率性而為。應用間的交互邏輯也比較零散。App 1與App 2交互，往往需要明確知道對方應用的具體信息，比如進程ID，進程名稱之類的，這樣使得應用和應用之間的聯系，變得很生硬。
而上層應用和系統應用的通信，往往有很多特定的模式，這種模式，很可能是無法直接應用在普通應用之間的，換而言之，系統應用是有一定特殊性的。重點，在圖的下半部，描述的是Android的應用情形。在Android中，應用的邊界，在組件這個層面，是極度模糊，什么進程、什么應用，都可以不必感知到。
舉個例子，App 1，實現了A和B兩個組件，App 2，實現了C這個組件。A和C，都想使用B這個組件，那么它們的使用方式是完全一致的，都需要通過系統核心的組件識別和通信機制。
找到和使用組件B。A，雖說和B是一個娘胎里蹦出來的，很不好意思，沒有任何特殊的后面和捷徑，還是要跑規矩的途徑才能用到，一片和諧社會的景象油然而生。在Android中，所有組件的識別和消息傳遞邏輯都必須依賴底層核心來進行（通信可以沒有底層核心的參與，比如一旦Service找到了，就可以和它產生持久的通信...）。
沒有底層核心的牽線搭橋，任何兩個組件都無法產生聯系。比如一個Activity，跳到另一個Activity，必須要向底層核心發起一個Intent，有底層解析并認可后，會找到另一個Activity。
把相關消息和數據傳給它。一個Activity想使用Content Provider中的數據，必須通過底層核心解析相關的uri，定位到這個Content Provider，把參數傳遞給。然后返回Activity需要的Cursor。這樣的設計，保證了底層核心對所有組件的絕對掌控權和認知權，使得搭積木似的開發變成可能。
為了，使得核心系統能夠完整的掌握每個組件的信息，這就需要Android配置信息文件了。配置文件，就是將組件插到底層核心上的這個插頭。只有通過這個插頭插在底層核心的插座上（不要亂想，非十八禁...）。
組件才能夠發光發熱，閃耀光芒。組件的Android配置信息在我看來主要包含兩個方面，一部分是描述如何認知。比如，Activity、Service、Broadcast Receiver都會有名字信息。和希望能夠把握的Intent信息（姑且看成消息好了...）。
Content Provider會有一個描述其身份的uri。當其他組件通過這樣的名字或者Intent，就可以找到它。另一部分是運行相關的信息。這個組件，期望怎么來運行，放在單獨的進程，還是和調用者一個進程，還是找相關的其他組件擠在同一個進程里面。
通過前續內容，也許可以幫助大家對Android組件有個初略的了解。但這些了解都還停留在靜態層面，程序是個動態的概念，關于各個組件具體是怎么聯系在一起的，如何手拉手運行起來完成一項功能的，這便是后話了。
【編輯推薦】
