Android基础部分（补充ing）

#首先是四大模块：

##Activity，Service（服务）,Content Provider（内容提供者），BroadcastReceiver（广播接收器）。

#其次是一些主要的内容：

##Activity、Layout、Binder、Intent、ContentProvider、service。

Activity：Activity（活动页/项）可以类比为网页中的一个JSP页面，安卓应用有一个manifest.xml的描述文件，该文件中定义了比如点开App后需要展示的页面是哪一个Activity，还有权限之类的应用描述。Activity之间切换用的是startActivity方法，可以使用Intent对象包装一个数据体交给被切换到的Activity，当然，通过onActivityResult方法可以要求被调用的Activity返回指定数据（大多数情况下都是用Dialog（弹出框）来完成，并不会特地去跳转个页面），至于注意点，第一：线程相关，Android在准备完App的启动环境后会有一个UI线程，也就是所谓的主线程，然后随着第一个页面的创建，会在Activity的生命周期开始处调用onCreate方法，以将我们自己的需要在Activity创建阶段完成的代码跑完。此时内存中已经形成了该Activity对应的内存Dom结构（因为你  可以findview了），系统会异步去渲染界面。回到主题，线程部分需要注意的是仅仅只有创建该Activity所对应的UI线程可以对该Activity在内存中的dom节点下的内容进行修改（子线程不包括在内），如果想要在子线程中修改，只能将修改相关的代码（尽可能少的其他操作）包装成一个runnable，然后交给UI线程去执行（应该是有线程的合并，这样就可以做到动态的将外部的代码  在UI线程中动态执行的效果）。方法有两个，一个是子view的post方法，一个是Handler对象的post方法，还有一个是Handler利用Message进行callback（其实相当于将runnable中的内容抽象成了数据区和代码区，使用Message将子view中需要传出 的  数据包装一下，然后交给需要进行UI变更的UI线程的代码区）。至于三个方案的原理就不多说了，就是个生产者消费者的模式。

Layout：Layout（布局描述文件）可以类比为网页中的一个Html模板页（或者说是一个静态的Html界面）。由于使用Activity去创建一个UI界面相对来说比较麻烦，第一是组件的位置，第二是很难及时的查看实时效果。所以就有了这样的布局描述文件，通过使用xml的节点结构，辅以对应的解析工具就可以直接展示通过Layout的xml文件所描述的界面的样子。并且，还可以直接对界面进行修改，来同步修改xml文件，另外，由于xml文件结构分明，所以使用它来描述一些界面会比用代码来的简洁。Layout可以通过在Activity中的setContentView被解析到对应的Activity中并渲染。安卓提供了很多常用的组件和布局。

Binder：Binder（跨进程的内存直接访问）可以类比成一个代理商，共有四个部分组成首先是Client（作为客户端的进程）和Server（作为服务端的进程），然后是ServerManager（相当于一个调度机构吧），最后是支撑它们的Binder驱动（一个虚拟设备）。流程：首先，由Server端向ServerManager进行服务的注册（这其中包含一些描述信息，当然，也包含Server对象自身的引用），ServerManager会根据Server留下的注册信息和Server对象的引用，生成一个代理对象并保存好，接着，Client端在需要的时候开始向ServerManager请求对应的服务（会先查询服务是否已注册），如果该服务存在，则将代理对象返回给Client端，Client调用代理对象的对应的业务方法，完成对应的业务（代理模式，对于Client端来说，自己调用的是ServerManager给的对象 的业务方法，但实际上，该方法是由Server的对象代理得来的，所以真正执行业务方法的，是Server端，当然，ServerManager也可以在包装代理对象时添加一些操作）。从以上流程来看，如果Server端需要较多的数据来完成业务方法（比如需要处理一个内存块），并且该业务方法还会返回较多的数据（比如经过业务方法处理后的内存块），由于进程间内存空间的隔离（底层操作系统的内存保护机制），那么上述的流程中就会出现如下的文件流动过程：第一块（需要被处理的内存块）：由Client进程的内存空间（用户区）copy到ServerManager的内存空间（内核区），再由ServerManager的内存空间（内核区）copy到Server进程的内存空间（用户区）（共两次拷贝），第二块（经过业务方法处理后的内存块）：由Server进程的内存空间（用户区）将修改后的文件copy到ServerManager的内存空间（内核区），再由ServerManager的内存空间（内核区）copy到Client进程的内存空间（用户区）（共两次拷贝），也就是一共四次拷贝（当然，如果不返回内存块或者  不需要内存块的话，就不是四次了），然而，如果上述流程有了 Binder驱动的参加，就会有不一样的效果，这里，Binder提供了内存映射。也就是无需拷贝，通过映射来完成内存块的传递。这里直接讨论Client--->Server--->Client，首先由Client的内存空间（用户态）将需要经过业务方法处理的内存块映射到ServerManager的内存空间（内核区），然后从ServerManager的内存空间（内核区）映射到Server进程的内存空间（用户区），Server进程在自己的内存空间处理完数据后，由于共享部分（就是传递的内存部分）内存块是映射来的，相当于C中的指针或者JAVA中的引用，所以Client端在得知ServerManager代理的业务方法处理完后，从共享区（  在Client端自己的内存空间）就可以直接读取到结果。

如有错误，欢迎指正。毕竟涉及的内容有点多了。谢谢。