有一堆接口标准封装完整的组件放在哪里，想用的时候取上几个一搭配，整个程序就构建完成了，但前提是要深入理解到底什么是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组件有个初略的了解。但这些了解都还停留在静态层面，程序是个动态的概念，关于各个组件具体是怎么联系在一起的，如何手拉手运行起来完成一项功能的，这便是后话了。
【编辑推荐】
