Android 的四大 Component 框架，是完全基于 OOP 而实现的，从设计而言，是遥遥领先的。iOS 的架构设计，无非承 Unix 之祖制，就是现在，在 Linux 上大行其道的 Container，也快和 Android App 差不多了，各种空间隔离，不过还没上字节码；iOS 的后台机制，无非是守护进程罢了。

所谓 OOP，其对于对象的抽象，是作为一种回调而不断存在的。写过 Java 的人都知道，最讨厌的是叠床架屋的继承，而 OOP 的强大威力也在于此。Android Component 的各种基类函数，所实现的是生命周期的功能；这样，通过继承基类，一个 App 的大小组件，生命周期，完全被 System 所掌控了。

而 iOS，或者说，XNU 内核；Apple 的 OS 的设计都极其拧巴，底层是先进的 XNU，微内核，消息传递机制，内核地址空间与用户地址空间完全隔离；上面跑的系统组件，WindowManager 之流，姑且用活着的软件才会有bug的理论予以辩护；而 BSD API 和 Mac Catalyst 仿佛两个世界，至于 Metal API 和 OpenGL 或者 Vulkan 比起来仿佛硅基生物与碳基生物的差异。在这里不得不赞扬 Windows NT，夫唯不争，故天下莫能与之争；一个在 2000 年左右就设计完全的现代内核，时至今日，也只需要修修补补；Apple OS 的历史包袱毫无疑问比 Window 多得多。

于是我们可以看到 iOS 的墓碑机制是多么名不副实：所谓墓碑，据说是保存应用暂停时状态的句柄，然而 App 会复活，所以叫避孕套还差不多，反正都是睡觉时用睡完就扔的；然而且慢！我们应该在操作系统理论中学过，保存应用状态的东西叫什么呢？叫进程控制块！这样来看墓碑和 PCB/TCB 又有什么区别呢？操作系统应该起到的封装作用又到哪里去了呢？微内核所谓的优势，“机制与策略相分离”哪里分离了呢？

如果让我来设计的话，在 macOS 的基础上，作为二进制文件而存在的应用程序，已经先天地失去由操作系统管理生命周期的可能性了；那么，应该仿照 native UI 程序，实现进程隔离；参照今日的 systemd 或者 launchd，实现由系统管理的启动和运行配置文件，来控制服务的启停。这样是用数据控制生命周期，和 Android 编程控制生命周期相比就不分优劣了。

实际上今日的现代 Apple 平台统一编程工具，Swift UI，在本质上和 Android Jetpack 已经殊途同归了；都是响应式的 UI 框架，利用 Effect 更新数据界面；Swift 的 App 也写有生命周期回调。

至于 Android 平台的后台机制，或者说极客们控制后台程序的方法，一则拦截启动，二则调度。拦截启动，我们都知道是怎么回事，要么在IFW上拦截，要么通过譬如Knox API 禁用组件。调度就有不同的说法了：Service 是正在运行，还是在内存中被挂起，还是缓存到虚拟内存中，还是完全被杀掉；除此之外还有 Process 和 Application，一共三个层级。不同的调度软件纷纷起不同的名字，什么乖巧啦，什么冻结啦，什么同步啦，真是五光十色，令人目不暇接；实在是标致极了。

正在用Thanox。应该说，UI 设计是满分的；除此之外，功能划分地比较清晰。然而真正有效的、长效的办法，是把这样的机制合并入 AOSP；Android 的魅力正是在于细粒度地控制自己的设备，我们也需要这样。试看今日之城中，究是谁家之天下？