在 Objective-C 的世界里，+load 方法是一个特殊的存在。它在类被添加到 Objective-C runtime 时执行，甚至早于 main 函数。这使得 +load 成为了一些特定场景下的利器，比如执行一些全局的初始化、注册逻辑或者进行 Method Swizzling 等。开发者们可以利用这个时机，在应用启动的极早期阶段就“悄无声息”地完成一些必要的工作。
然而，随着 Swift 成为苹果生态开发的主流语言，我们发现 Swift 本身并没有直接提供与 Objective-C +load 完全等价的机制。这让一些习惯了 +load 便利性的开发者，或者在迁移一些依赖 +load 功能的旧代码到 Swift 时，遇到了一些挑战。我们如何在 Swift 中“优雅”地找回这种能力呢？
登场了！Rhea - 在 Swift 中解锁 +load 时机
这时候，就轮到我们的主角——Rhea 登场了！
Rhea 是一个轻量级的 Swift 开源库，它巧妙地利用了 Swift 最新的 Macro (宏) 特性，让我们能够在 Swift 代码中简洁、直观地注册需要在特定时机（包括模拟 Objective-C +load 时机）执行的代码块。
想象一下，你只需要这样写：
import Rhea
#load {
// 这段代码将会在类似于 OC +load 的时机执行
print("Swift 代码通过 Rhea 在 load 时机执行了！")
// 在这里进行你的早期初始化、模块注册等操作
}
// Rhea 还支持其他预设时机，例如 premain 和 appDidFinishLaunching
#premain {
print("Swift 代码通过 Rhea 在 premain 时机执行了！")
}
#appDidFinishLaunching { context in
print("Swift 代码通过 Rhea 在 appDidFinishLaunching 时机执行了！")
if let launchOptions = context as? [UIApplication.LaunchOptionsKey: Any] {
// 处理启动选项
}
}
甚至可以自定义事件时机
extension RheaEvent {
static let myCustomEvent: RheaEvent = "myCustomEvent"
}
#rhea(time: .myCustomEvent, priority: .normal) { _ in
print("自定义事件 myCustomEvent 被触发了！")
}
// 在合适的时机触发自定义事件
Rhea.trigger(.myCustomEvent)
还可以使用async参数在子线程回调
#rhea(time: .homePageDidAppear, async: true, func: { context in
// 这里将在子线程回调
print("~~~~ homepageDidAppear")
})
甚至在 XCode 16以上的版本中, 你还可以将其嵌套在类型中, 仿佛 OC 时代的 load 方法一般:
class ViewController: UIViewController {
#load {
print("~~~~ load nested in main")
}
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
}
}
通过 Rhea 提供的 #load宏 (以及 #premain, #appDidFinishLaunching 等)，你可以非常“Swiftly”地将需要在应用启动早期执行的逻辑安排得明明白白。Rhea 负责处理底层的实现细节，让你的代码库可以保持纯粹的 Swift 风格，同时又能享受到类似 +load 的便利, 而且集成后, 只需要 import RheaTime, 不需要其他任何初始化和注册逻辑, 这对于需要进行模块化自动注册、早期配置等场景，无疑提供了一种优雅的解决方案。
听起来是不是很棒？Rhea 让那些原本需要在 Objective-C 中通过 +load 实现，或者通过其他一些复杂技巧才能达成的目标，在 Swift 中变得触手可及。
等等，在 Swift 中大量使用 load 真的“优雅”吗？
就在我们沉浸于 Rhea 带来的这种“优雅”时，一个重要的问题浮出水面：我们真的应该在 Swift 项目中大量推广和使用这种 +load 时机的代码执行方式吗？
答案可能是否定的。
尽管 Rhea 提供了在 Swift 中模拟 +load 时机的强大能力，但滥用这种机制，即使是在 Swift 中通过如此巧妙的库实现，也并非真正的“优雅”之道，反而可能给你的应用带来一些不容忽视的负面影响，其中最显著的就是 应用冷启动速度变慢。
+load 与应用启动时间
Objective-C 的 +load 方法（以及 Rhea 模拟的类似时机）有一个显著特点：它们会在 main 函数执行之前被调用。当应用启动时，动态链接器（dyld）会加载所有依赖的库和类。在这个过程中，如果一个类实现了 +load 方法，那么这个方法就会被执行。
这意味着：
阻塞启动路径：+load 方法是同步执行的。如果 +load 方法中的代码执行时间过长，会直接阻塞后续的启动流程，延长从用户点击 App 图标到看到第一个界面的时间。 累积效应：如果项目中有大量的类都使用了 +load（或者通过 Rhea 注册了 #load 代码块），每一个都会贡献一点点启动时间。当这些时间累积起来，对冷启动性能的影响就会变得非常明显。用户对于启动缓慢的 App 是非常敏感的。 苹果官方也一直在强调优化应用启动时间的重要性。在 WWDC 的分享中，他们明确指出，应用在 main 函数执行前的时间（Pre-main time）是影响启动性能的关键阶段之一。这个阶段包含了 dylib loading (动态库加载)、rebase/binding (符号重定位和绑定)、ObjC setup (Objective-C运行时初始化) 以及 initializers (包括 +load 方法和 C++ 的静态构造函数等)。
简单来说，你在 +load 时机做的事情越多，应用启动就越慢。
其他潜在问题 除了对启动性能的直接影响，过度依赖 +load 时机还可能带来：
环境限制：在 +load 执行时，完整的应用环境可能尚未准备就绪。例如，一些 UIKit 的类可能还不可用或行为不完全符合预期。虽然 Rhea 本身在 Swift 环境下工作，但过早执行复杂逻辑仍然需要谨慎。 调试困难：发生在启动链极早期的代码，如果出现问题，有时会比应用正常运行后的代码更难追踪和调试。 顺序依赖风险：虽然 Objective-C Runtime 对 +load 的调用顺序（父类优先于子类，类优先于分类）有规定，但在复杂的项目中，隐式的执行顺序依赖仍然可能导致问题。Rhea 提供了优先级设置，可以在一定程度上缓解这个问题，但仍需开发者仔细管理。 结论：谨慎使用，而非滥用 Rhea 是一个设计精巧的库，它确实为 Swift 开发者提供了一种在特定场景下模拟 Objective-C +load 等早期时机执行代码的有效手段。对于一些确实需要在极早期进行、且无法通过其他更佳方式实现的轻量级初始化或注册任务，Rhea 可以是一个不错的选择。
然而，这并不意味着我们应该将 +load 模式（即使是通过 Rhea 在 Swift 中实现）作为常规武器库中的常用选项。
真正的“优雅”并不仅仅在于能用某种技巧实现某个功能，更在于理解这种功能背后的代价，并做出明智的取舍。
对于大多数初始化和配置任务，Swift 提供了更推荐、也更符合语言特性的方式：
懒加载 (Lazy Initialization)：对于不需要立即使用的对象，推迟它们的创建和初始化时间。 AppDelegate / SceneDelegate：在 application(_:didFinishLaunchingWithOptions:) 或相关的 SceneDelegate 方法中执行应用级别和 UI 级别的配置。这是最常见也是最推荐的初始化时机。 依赖注入 (Dependency Injection)：通过构造函数注入、属性注入等方式管理和传递依赖，而不是依赖全局状态或早期自动注册。 静态属性和全局常量：对于简单的常量或类型属性，它们的初始化已经足够高效和安全。
总结
总而言之，Rhea 库为你打开了一扇在 Swift 中探索 +load 时机的窗户。但请记住，强大的工具需要被审慎地使用。不要为了追求某种“魔法般”的自动执行，而牺牲了应用的启动性能和用户的初体验。在大多数情况下，选择更符合 Swift 设计哲学、对启动性能更友好的初始化方案，才是真正的“优雅”之道。
