Swinject：什么是它，依赖注入原理及工作方式

什么是Swinject和依赖注入

Swinject是一个开源的Swift语言DI容器，旨在简化iOS、macOS和watchOS应用中的依赖注入。该框架使用服务定位器方法：服务在中央容器中注册，容器在请求实例时自动解析依赖图。

依赖注入（DI）是一种设计模式，对象从外部接收其依赖而不是在内部创建它们。这减少了组件之间的耦合，简化了模块化测试，并允许在不更改消费者代码的情况下替换实现。

根据Martin Fowler（2004）的说法，DI是控制反转的一个特例，通过构造函数、属性或方法注入来实现。Swinject自动化了这个过程，消除了手动编写工厂和服务定位器的需要。

在具有三个或更多具有交叉依赖关系的服务的项目中应用Swinject，手动构建对象会导致初始化代码增长和可测试性降低。

Swinject与Apple生态系统紧密集成，支持从3.0开始的所有Swift版本。该框架通过桥接与Objective-C兼容，允许将其部署到以混合语言编写的现有项目中，而无需完全迁移代码。这对于开发历史超过五年的大型应用尤其重要。

Swinject容器如何工作

Swinject容器由Container类实现，该类存储已注册服务的注册表。调用resolve方法时，容器创建对象并根据注册图递归解析其所有依赖。

容器和服务

容器是在其中注册抽象与其实现之间对应关系的中央对象。服务是定义契约的协议，组件是实现该协议的类。注册通过register方法完成，该方法接受服务类型和工厂。

let container = Container()
container.register(Networking.self) { _ in
    NetworkService()
}
let service = container.resolve(Networking.self)

resolve方法返回为指定协议注册的具体实现的实例。如果依赖未注册，容器会抛出致命错误，以便在开发阶段快速发现问题。

注册和命名服务

每个注册都会创建一个带有工厂函数和选定作用域的条目。一个服务可以有多个不同名称的注册，允许按名称选择特定的实现——这对于不同的环境（开发、暂存、生产）很有用。

依赖解析过程（resolution）递归工作：当容器创建Component的实例时，它会分析其初始化器，并为每个参数调用相应类型的resolve。如果依赖也有自己的依赖，则过程将继续，直到整个图完全构建。嵌套深度仅受可用内存限制，但在实践中很少超过五个级别。

Swinject中的依赖注入方式

Swinject支持三种主要的依赖注入方式，每种方式都根据架构上下文适用。

构造函数注入

构造函数注入 — 通过初始化器参数注入依赖。这是首选方式，保证对象从创建时刻起始终处于正确状态。Swinject自动解析传递给构造函数的所有依赖。

class LoginViewModel {
    private let authService: AuthProtocol

    init(authService: AuthProtocol) {
        self.authService = authService
    }
}

container.register(AuthProtocol.self) { _ in
    AuthService()
}
container.register(LoginViewModel.self) { r in
    LoginViewModel(authService: r.resolve(AuthProtocol.self)!)
}

属性注入

属性注入 — 通过对象初始化后设置其属性来注入。当依赖是可选的或无法通过构造函数传递时使用，例如在使用Storyboard时，视图控制器会自动创建。Swinject支持@Inject注解，通过运行时代理自动属性注入，无需显式调用resolve。

使用属性注入时，重要的是确保依赖在首次访问对象之前已设置。否则，属性将保持为nil，导致意外崩溃。Swinject通过隐式解包可选机制和依赖图解析阶段的严格验证解决了这个问题。

方法注入

方法注入 — 通过方法参数注入。适用于仅需执行一个操作且不应作为对象永久状态存储的服务。这是最不常见但对回调有用的注入方式。

Swinject中的作用域及其用途

对象作用域 — 确定Swinject容器内创建的实例生命周期的机制。该框架提供了三个内置作用域，并可通过ObjectScopeProtocol协议创建自定义作用域。

ObjectScope.graph

graph作用域 — 默认值。每次resolve调用都会创建一个新实例，该实例仅在依赖图解析期间存在。这是无状态服务的安全选择，因为它消除了由缓存引起的内存泄漏。

ObjectScope.container

container作用域 — 容器内的单例。实例在第一次resolve时创建一次，并在所有后续请求中返回。适用于具有共享状态的服务：数据缓存、日志记录器、应用程序设置。

ObjectScope.transient

transient作用域 — 每次resolve调用都会创建一个新实例而不缓存。用于不需要重复使用的轻量级对象——例如，用于处理特定HTTP请求的模块。

Swinject在iOS项目中的应用

将Swinject集成到实际的iOS项目始于应用程序启动时容器的初始化——在AppDelegate或场景中。建议通过Assembly来结构化注册：一个独立的类或结构，将相关的服务分组。

根据Swift开发者社区（2025）的调查，43%的iOS开发者在商业项目中使用DI容器来管理网络层、存储库和导航协调器的依赖。Swinject由于最小的语法和与Objective-C的兼容性，仍然是最流行的解决方案。

Storyboard注入 — Swinject的独特能力：容器自动将依赖注入到从Storyboard创建的视图控制器中，无需在AppDelegate中添加额外代码。为此，使用一个特殊的解析器，通过init(container:)方法传递给UIStoryboard，它拦截视图控制器的创建并注入已注册的依赖。

在大型项目中，Swinject可以与导航协调器结合使用：协调器接收容器并创建屏幕，通过resolve解析它们的依赖，从而为整个场景保持单一的配置点。

使用Assembly的架构 — 组织注册的推荐模式。每个Assembly将相关服务分组（例如，NetworkingAssembly、DatabaseAssembly），并可以依赖于其他Assembly。在容器初始化时，所有Assembly加载并注册它们的服务，这提供了清晰的职责分离，并简化了具有数十个服务的大型项目中DI配置的导航。

为了调试DI图，Swinject提供了SwinjectPropertyLoader扩展（从plist文件加载配置）和SwinjectStoryboard（通过特殊版本的UIStoryboard与storyboard集成）。这些工具在将现有项目从手动对象构建过渡到DI的阶段特别有用：开发者可以逐步注册服务，通过测试和解析错误日志来检查依赖图，而不会停止应用程序主要功能的开发。

Swinject还通过SwinjectAutoregistration扩展提供与RxSwift和Combine的集成，根据初始化器参数类型自动解析依赖，无需显式注册工厂。这减少了对简单服务的注册代码量：只需调用container.register(ServiceProtocol.self)而不指定工厂，Swinject就会基于Swift运行时环境提供的Signal反射独立构建工厂。此方法推荐用于构造函数仅接受基本类型且创建时不需要复杂逻辑的服务。