本文分析下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通信一些奇葩点：
Binder承担了绝大部分Android进程通信的职责，可以看做是Android的血管系统，负责不同服务模块进程间的通信。在对Binder的理解上，可大可小，日常APP开发并不怎么涉及Binder通信知识，最多就是Service及AIDL的使用会涉及部分Binder知识。Binder往小了说可总结成一句话：一种IPC进程间通信方式，负责进程A的数据，发送到进程B。往大了说，其实涉及的知识还是很多的，如Android 对于原Binder驱动的扩展、Zygote进程孵化中对于Binder通信的支持、Java层Binder封装，Native层对于Binder通信的封装、Binder讣告机制等等。很多分析Binder框架的文都是从ServiceManager、Binder驱动、addService、getService来分析等来分析，其实这些主要是针对系统提供的服务，但是bindService启动的服务走的却还是有很大不同的。本篇文章主要简述一些Binder难以理解的点，但不会太细的跟踪分析，只抛砖，自己去发掘玉：
Android应用运行在后台的时候，经常被系统的LowMemoryKiller杀掉，当用户再次点击icon或者从最近的任务列表启动的时候，进程会被重建，并且恢复被杀之前的现场。什么意思呢？假如APP在被杀之前的Activity堆栈是这样的，A<B<C，C位于最上层