最近在复盘 Android 知识，借此机会我想了解一下，同是移动端解决方案，Android 和 iOS 在应对各种场景的策略区别在于哪些地方？
如果能推荐一本深入浅出讲这些缘起、经过、对策的系统架构方面的书，那我的愿望也就达到了。
因为我是做 Android 的，我来简单说说我对 Android 的理解。
- - - - - - - - - - - - - - - - -
就比如，最开始你只有一部手机硬件，你想在屏幕上渲染，于是封装了底层的一层 Surface Flinger。
你还想窗口，于是你继续在上层封装了 WindowManager 和 Window，每个 Window 映射一块 Surface，并且通过进程通信的方式，去与底层的 WindowsManagerService 通信，来间接调用 SF 在 Surface 上做渲染。
然而 Window 要是亲自去绘制，那就太复杂，于是再另外封装一个 View，View 延伸出 ViewGroup，相互之间通过组合模式构成一个树。每个 Window 都持有一个 ViewTree，那么绘制的工作就直接交给 View 来遍历和完成，我 Window 只需做个管理者，拿到绘制结果，向上级 WM 反映，通过 WM 与 WMS 取得联系，并最终通过 SF 渲染出。
然而，你不仅有窗口，你还想要多窗口，于是通过模板方法模式，去暴露出 Activity 模板，让用户自定义实际上是一个个窗口的 Activity，而多窗口之间的切换、通信等关系，则由系统机制来把握。
所以为了渲染、为了窗口、为了绘制、为了多窗口，Android 设计了这么些套路，那么 iOS 又是怎样的呢？它是否存在窗口的概念呢？它是依靠什么来绘制的呢？它是怎么管理多窗口的呢？
如果能推荐一本深入浅出讲这些缘起、经过、对策的系统架构方面的书，那我的愿望也就达到了。
因为我是做 Android 的，我来简单说说我对 Android 的理解。
- - - - - - - - - - - - - - - - -
就比如，最开始你只有一部手机硬件，你想在屏幕上渲染，于是封装了底层的一层 Surface Flinger。
你还想窗口，于是你继续在上层封装了 WindowManager 和 Window，每个 Window 映射一块 Surface，并且通过进程通信的方式，去与底层的 WindowsManagerService 通信，来间接调用 SF 在 Surface 上做渲染。
然而 Window 要是亲自去绘制，那就太复杂，于是再另外封装一个 View，View 延伸出 ViewGroup，相互之间通过组合模式构成一个树。每个 Window 都持有一个 ViewTree，那么绘制的工作就直接交给 View 来遍历和完成，我 Window 只需做个管理者，拿到绘制结果，向上级 WM 反映，通过 WM 与 WMS 取得联系，并最终通过 SF 渲染出。
然而，你不仅有窗口，你还想要多窗口，于是通过模板方法模式，去暴露出 Activity 模板，让用户自定义实际上是一个个窗口的 Activity，而多窗口之间的切换、通信等关系，则由系统机制来把握。
所以为了渲染、为了窗口、为了绘制、为了多窗口，Android 设计了这么些套路，那么 iOS 又是怎样的呢？它是否存在窗口的概念呢？它是依靠什么来绘制的呢？它是怎么管理多窗口的呢？
Select Language