如有错误请指正。我的理解是 Mac OS X 有一个 WindowServer 进程，它从所有应用程序合成窗口，并在屏幕上绘制最终的合成图像。那么问题是 WindowServer 进程从哪里获得其他应用程序的“windows 数据”(以某种形式，如位图)。它是通过应用程序和WindowServer进程之间的共享内存机制实现的吗？关于此的任何信息或指示/文档都会有所帮助!
另外，iOS在这方面的实现是否类似？
谢谢!
最佳答案
将窗口位图编码到 WindowServer 进程的机制是一个未记录的实现细节，实际上是“不透明的”，因此即使您现在努力弄清楚它是如何工作的，它也可能会随着发布而改变释放。也就是说……
如果我不得不猜测它是如何工作的，我的猜测是有一 block 共享内存支持每个窗口，当你的窗口去绘制它的 View 层次结构时，[NSGraphicsContext currentContext] 设置为指向由该共享内存块支持的 CGContext。当窗口绘制序列完成时，我猜一个或多个 mach 消息从您的进程发送到 WindowServer 进程，告诉它是时候呈现刚刚绘制的框架了。
在 iOS 上，Springboard 进程似乎扮演了窗口服务器的角色，我想它的工作方式类似，但是同样，所有这些细节都是未记录的实现细节，因此不透明。由于 CoreGraphics 存在于 OSX 和 iOS 中，因此机制相似是理所当然的。
您可以使用 vmmap 和调试器(或 dtrace)找到该假设的一些证据。例如，您可以在所有可以将虚拟内存区域映射到您的进程(mmap、vm_allocate 等)的不同函数上设置断点(或 dtrace 探测器)，然后在打开新窗口的过程中对 vmmap 输出进行前后比较。您会看到有新的 VM 区域已映射到您的进程中，但您不会在断点/dtrace 探测上看到任何相应的命中(即您的进程中没有任何内容映射这些区域).这是窗口服务器进程已将共享内存区域映射到您的进程的证据。有关这些区域的元信息使用 mach 消息(最有可能)传达给您的进程。在一个简单的示例应用程序上尝试此操作，打开一个新窗口并查看 vmmap 输出中的差异，显示该区域很可能是我们最近创建的窗口的后备存储:
CG backing stores 00000001c73f2000-00000001c74cc000 [ 872K] rw-/rw- SM=SHM
关于macos - "window compositor"(WindowServer 进程)在 Mac OS X(和 iOS)中是如何实现的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17937263/