android FrameWork家族是怎么组成的？

         先讲一个自己的面试故事， 曾经去面试一家穿戴计算的创业团队，第一轮技术面试还是比较顺利，因为问的都是比较常用和肤浅的技术知识。 第二轮类似技术总监级的面试官问我两个问题彻底把我问翻来， 第一个是java的int有几个字节？(如果刚出学们的时候肯定会毫不犹豫的回答他)， 工作来四五年了， 突然问我这个问题有点蒙， 还真没一下子回答上来。  第二问题：activity在启动的时候至少有几个进程？这个问题有技术含量， 没有答上来。最终面试失败。

        当我学习完android的framework的时候才真正找到答案， 如果现在让我回答这个问题， 我会很自信的告诉他三个进程。 可能是他看到我简历上写有自己业余研究过android框架， 估计想考考我。 现在回想， 如果这个问题都回答不上来，还真的是对不住那段简历呵。

        我根据自己的理解来告诉大家 为什么是三个进程，activity只是作为一个承载UI和反馈系统调度的代理， 或者说办事员。系统首先要为activity启动一个主线程，即赋予它生命， 而为了管理它的生命轨迹， 系统又为它启动一个监护进程, 可以理解是一个监护者，也只是一个马仔， 专听命于ActivityManagerService大佬， 系统为了管理activity在不同年龄段的面貌， 又弄了一个马仔进程， 专门监护activity的外形， 而这个马仔仅仅听命于WindowManagerService大佬。  所以当系统启动一个activity的时候， 除来给activity赋予生命进程外还弄来两个马仔进程， 专门监控activity的生命轨迹和面貌， 以保证activity这个奴隶时刻要在两个大佬们的指挥下度过失去自由被催的一生。 好可怜啊, 嘿嘿...

         好了， 转入正题之前，先抄别人一句很有高度的心得： Android系统相对于linux内核而言也仅仅是一个linux应用程序而已，因此android系统也会在linux的init.rc中被声明，  从而linux系统内核启动后就能直接运行android 内核。    怎么样？ 读三遍后，是不是一下子就藐视了这个被妖魔化的机器人了呢？

       先认识一下FrameWork的阶级分层，  三个主要部分： 服务端， 客户端 ， Linux驱动。

       再认识一下各个阶级的主要成员：

       服务器端主要有两个大佬： WindowManagerService （管理窗口的叠放次序，隐藏或则显示窗口）  AcitivityMangerService（管理应用程序中的activity）.

 其中WindowManger 还有两个著名得力的助手（内部类），KeyQ (自从它一出生就每时每刻的收集用户的操作事件， 放到事件队列中)， InputDispatcherThread(自从一出生就时时刻刻从事件队列将用户事件发送到客户端)。

       客户端比较热闹， 苦力比较多。 这也完全符合社会发展规律， 干活的总比指挥干活的人多。

       总的来说, 这个大家族有三户人家组成： 最大的Window姓氏的家族  Window ,  PhoneWindow（可以理解为window的表哥），WindowManager(可理解为Window家族的权利掌管者) ， W (理解为Window家族非常忠心的家奴)。    Activity姓氏家族(最受压迫的家族)   Activity, ActivityThread（是整个客户端阶层的命脉， Activity的独生子）。   View最注重仪表的姓氏家族， DectorView（是客户端阶层的形象代言， 非常漂亮哦）， ViewRoot（保证了客户端外在形象的生动流畅，非常有责任心.）

        至于 他们之间的协作关系， 下次再讲， 天色已晚， 先睡觉了。。。。

推荐一篇文章：

一个草根程序员创业之路的所感所悟-2016