objective-c - 构建仅后台 COCOA 应用程序作为启动守护进程的缺点？

Question

构建一个没有任何 GUI 的仅后台 COCOA 应用程序并将其作为启动守护进程运行是否有任何缺点？这将使用:

import <Foundation/Foundation.h>
import <AppKit/AppKit.h>
import <CoreData/CoreData.h>

使用此工具而不是构建 Objective-C 命令行工具的主要优点是，它提供了隐式运行循环，其优点包括在应用程序完成启动或终止期间定义良好的回调。这需要在命令行应用程序中显式实现。

是否存在功能中断等缺点？守护进程的启动会被推迟吗？

Answer 1

对于守护进程来说，使用任何非守护进程安全的框架都有严重的缺点。来自 Technical Note TN2083: Daemons and Agents – Layered Frameworks :

Layered Frameworks

Most Mac OS X functionality is implemented by large system frameworks. Many of these frameworks use Mach-based services that they look up using the bootstrap service. This can cause all sorts of problems if you call them from a program which references the wrong bootstrap namespace.

Apple's solution to this problem is layering: we divide our frameworks into layers, and decide, for each layer, whether that layer supports operations in the global bootstrap namespace. The basic rule is that everything in CoreServices and below (including System, IOKit, System Configuration, Foundation) should work in any bootstrap namespace (these are daemon-safe frameworks), whereas everything above CoreServices (including ApplicationServices, Carbon, and AppKit) requires a GUI per-session bootstrap namespace. …

In summary, the concrete recommendations are:

• When writing a daemon, only link to daemon-safe frameworks (see Framework Cross Reference).

• When writing a GUI agent, you can link with any framework.

• If you're writing a daemon and you must link with a framework that's not daemon-safe, consider splitting your code into a daemon component and an agent component. If that's not possible, be aware of the potential issues associated with linking a daemon to unsafe frameworks (as described in the next section).

Living Dangerously

If your daemon uses frameworks that aren't daemon-safe, you can run into a variety of problems.

• Some frameworks fail at load time. That is, the framework has an initialization routine that assumes it's running in a per-session context and fails if it's not.

  This problem is rare on current systems because most frameworks are initialized lazily.

• If the framework doesn't fail at load time, you may still encounter problems as you call various routines from that framework.

  • A routine might fail benignly. For example, the routine might fail silently, or print a message to stderr, or perhaps return a meaningful error code.

  • A routine might fail hostilely. For example, it's quite common for the GUI frameworks to call abort if they're run by a daemon!

  • A routine might work even though its framework is not officially daemon-safe.

  • A routine might behave differently depending on its input parameters. For example, an image decompression routine might work for some types of images and fail for others.

• The behavior of any given framework, and the routines within that framework, can change from release-to-release.

The upshot of this is that, if your daemon links with a framework that's not daemon-safe, you can't predict how it will behave in general. It might work on your machine, but fail on some other user's machine, or fail on a future system release, or fail for different input data. You are living dangerously!

阅读整个技术说明以获取完整的详细信息。