目录
协议：数据的组织与传输约定
本文分析下Android的消息处理机制，主要是针对Hanlder、Looper、MessageQueue组成的异步消息处理模型，先主观想一下这个模型需要的材料：
Dialog是APP开发中常用的控件，同Activity类似，拥有独立的Window窗口，但是Dialog跟Activity还是有一定区别的，最明显的就是：默认情况下Dialog不是全屏的，所以布局实现不如Activity舒服，比如顶部对齐，底部对齐、边距、宽度、高度等，如果将Dialog定义成全屏的就会省去很多问题，可以完全按照常用的布局方式来处理。网上实现全屏Dilaog的方式有不少，一般情况下也都能奏效，不过可能有不少小点会导致疑虑，比如：为什么有些窗口属性（隐藏标题）必须要在setContentView之前设置才有效，相反，也有些属性（全屏）要在之后设置才有效。实现全屏Dialog呢，其实方法不一，这里挑几个简单的，然后说下原因，由于Android的窗口管理以及View绘制是挺大的一块，这里不过多深入。先看实现效果：
SystemServer的启动
关于Context，首先看一下官方的说法：
本篇是第二篇，主要是涉及Binder线程与进程的唤醒，传输数据的封装与解析等知识点，在数据传输的时候，Java层与Native层的Parcel转换是一个知识点，另外Java层Binder在Native层的实现也是一个知识点，另外Binder实体的打扁与展开也是个知识点。上一篇分析了数据传输，一次拷贝，这些拷贝的数据都是被拷贝到内核空间，如果内核空间的数据无限增加肯定是不合理的，那么究竟内核空间数据是如何释放等等。
很多文章将Binder框架定义了四个角色：Server，Client，ServiceManager、以及Binder驱动，但这容易将人引导到歧途：好像所有的Binder服务都需要去ServiceManager去注册才能使用，其实不是这样。例如，平时APP开发通过bindService启动的服务，以及有些自己定义的AIDL远程调用，都不一定都ServiceManager注册这条路，个人理解：ServiceManager主要功能是：管理系统服务，比如AMS、WMS、PKMS服务等，而APP通过的bindService启动的Binder服务其实是由SystemServer的ActivityManagerService负责管理。这篇主要关注Android APP Java层Binder通信一些奇葩点：