linux上的一个玩具

（为什么这篇吹水的这么多人看，不理解）

窗口管理

WindowManger的流程大概大概过了一遍。
Activity持有了PhoneWindow，PhoneWindow通过token和WMS进行交互，比如需要生产的window是不是全屏幕啊，WMS渲染了尺寸，通过了一波计算确定了PhoneWindow能显示的大小，通过binder调用，把显示的参数放在display中回到PhoneWindow中，PhoneWindow本质上也是一个view。把东西处理完，送到surface中，surface处理后输出到硬件渲染。

有几个关键点：

1，WMS计算屏幕大小是在一个进程中的多线程处理的。
2，Window本身就有许多参数，可以控制屏幕大小，显示层级的。
3，WMS还会接受硬件输入，把点击事件传递到对应的window中。

窗口渲染

App进程启动之后，会通过binder调用，在ActivityStack中把窗口的信息app token 之类的东西给到wms，wms根据物理尺寸的大小，算出app内部的窗口大小，再给回到App进程。获得高、宽、分辨率得信息之后，App开始在自己的进程，窗口内绘制UI。绘制的UI存在surface中。UI通过新建一个SF client，当有UI刷新的时候，会通过client，通知SF刷新。SF本身有定时刷新的机制，叫做VSync（会刷新物理屏和wifi屏）。App进程中，Choreography会接受硬件的时钟，定时的在UI线程中绘制doFrame。
那么问题来了
1，App是直接binder调用SurfaceFlinger，通知UI变更的吗？
2，SurfaceFlinger 和 Choreography 中都有时钟定时刷新的机制，那么是谁通知谁刷新？

扯远了说

android整一套的activity，application，server都是存在ActivityThread中的，ActivityThread.main 就是android应用启动的方法，作为一个可执行文件，从zygote中fork出来，解析，动态加载了APK中的资源。
AMS和WMS都是一个独立的进程，需要拉起一个activity，或者server的时候，都会走binder调用，系统会把一些背景资源（context）封装好，然后走activity的生命周期的东西。
WMS就是android的窗口管理了，定义了屏幕的尺寸，决定了窗口的层级（Z轴），输送surface给渲染，传递点击事件给顶层激活的窗口。

回过头来看，android系统本身就是一整套插件加载机制。现在如火如荼的热加载，不过是照大猫画小猫而已。要是我从头来实现一套系统，我最想保留的还是context，把大部分东西都隔离了，把功能作为插件提供给第三方开发者，这样最好。

关于权限：

Zygote是有root权限，但是在拉起的过程中，大部分高级权限被限制了，所以即使应用获和zygote一样的权限，也没系统级别的能力。

TODO

我还可以写更多，这里留个伏笔