架构

什么是MVC MVC（Model-View-Controller）是Apple官方推荐的iOS应用架构模式，也是最基础、最常见的架构。它将应用分为三个核心组件： Model（模型）：负责数据和业务逻辑 View（视图）：负责界面展示 Controller（控制器）：负责协调Model和View MVC的结构（Apple MVC） graph TD V[ViewUIView] -->|用户事件| C[ControllerUIViewController] C -->|更新UI| V C <-->|读写数据| M[Model数据层] 在Apple的MVC中，View和Model之间不能直接通信，所有交互都必须通过Controller中转。 Model（模型层） Model负责： 数据的存储和管理 业务逻辑处理 网络请求和数据持久化 数据验证 // Model示例 struct User { let id: Int let name: String let email: String var isValidEmail: Bool { let emailRegex = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}" let emailPredicate = NSPredicate(format: "SELF MATCHES %@", emailRegex) return emailPredicate.evaluate(with: email) } } class UserService { func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) { // 网络请求逻辑 } } View（视图层） View负责： ...

什么是MVI MVI（Model-View-Intent）是一种单向数据流架构模式。“Model-View-Intent"这一命名最早出现在Andre Medeiros（Staltz）创建的JavaScript框架Cycle.js中。2016年，Hannes Dorfmann在其博客系列中将MVI系统化引入Android开发，他在文中明确提到同时受到了Cycle.js和Redux（以及更早的Elm架构）的启发——MVI的命名和响应式理念来自Cycle.js，而Reducer纯函数和单一状态源的机制则与Redux一脉相承。随着Swift社区对函数式编程和响应式编程的接受度提高，MVI也逐渐被引入iOS开发。 MVI的核心思想： 单向数据流：数据沿固定方向流动（View -> Intent -> Reducer -> State -> View），没有捷径或后门 不可变状态：整个界面由单一不可变的State描述，每次更新都产生全新的State对象 可预测性：给定相同的当前State和Intent，Reducer总是产生相同的新State MVI的核心概念 Model（状态） 在MVI中，Model不是传统意义上的领域数据模型，而是界面状态模型（State）。它用一个不可变的值类型来描述UI在某一时刻的完整快照，包括数据内容、加载状态、错误信息等。 struct UserListState: Equatable { var users: [User] var isLoading: Bool var error: String? var searchQuery: String static let initial = UserListState( users: [], isLoading: false, error: nil, searchQuery: "" ) } 这里使用var属性配合struct值类型，利用Swift的值语义在Reducer中通过拷贝实现不可变效果，这是Swift中最常用的做法（详见后文"状态的不可变性"一节）。 Intent（意图） Intent代表所有触发状态变化的事件。它不仅包括用户的UI操作，还包括副作用的结果回调（如网络请求完成、数据库查询结果）、系统事件（如生命周期回调、推送通知）等。所有这些事件统一通过Intent进入Reducer驱动状态变化。 enum UserListAction { // 用户意图 case loadUsers case refreshUsers case deleteUser(id: Int) case searchQueryChanged(String) // 副作用结果（也是Intent的一种） case usersLoaded([User]) case loadFailed(String) } 将用户操作和副作用结果统一为同一类型，是MVI的关键设计。这样Reducer就成为状态变化的唯一入口，所有状态转换都在一处完成。 ...

什么是MVP MVP（Model-View-Presenter）是一种将展示逻辑与视图分离的架构模式，起源于上世纪90年代。MVP通过引入Presenter层来解决MVC中Controller职责过重（Massive ViewController）的问题。MVP的核心思想是让View变得"被动"（Passive View），所有的展示逻辑都由Presenter处理，View只负责UI的展示和事件的转发。 MVP的结构 graph LR subgraph View["View (ViewController)"] V1["- 只负责UI展示- 将事件转发给Presenter- 持有Presenter强引用"] end subgraph Presenter["Presenter"] P1["- 持有View的弱引用（通过协议）- 持有Model的引用- 处理所有业务逻辑- 决定何时更新View"] end subgraph Model["Model"] M1["数据和业务逻辑"] end View -->|"用户事件"| Presenter Presenter -.->|"weak引用调用协议方法更新UI"| View Presenter <-->|"获取/更新数据"| Model MVP的三个组件 Model（模型层） 与MVC中的Model相同，负责数据和业务逻辑。 // Model struct User { let id: Int let name: String let email: String let avatarURL: URL? } // Service protocol UserServiceProtocol { func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) func updateUser(_ user: User, completion: @escaping (Result<Void, Error>) -> Void) } class UserService: UserServiceProtocol { func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) { // 网络请求实现 } func updateUser(_ user: User, completion: @escaping (Result<Void, Error>) -> Void) { // 更新用户实现 } } View（视图层） 在MVP中，View是"被动的"（Passive View），它： ...

什么是MVVM MVVM（Model-View-ViewModel）是一种通过数据绑定实现View和业务逻辑解耦的架构模式。它最初由Microsoft提出，用于WPF开发，后来被广泛应用于iOS开发。 MVVM的核心特点是： ViewModel不持有View的引用 通过数据绑定实现View和ViewModel的同步 View的状态完全由ViewModel驱动 MVVM的结构 flowchart TB subgraph View["View (ViewController)"] V1["绑定ViewModel的属性"] V2["将用户事件传递给ViewModel"] end subgraph ViewModel["ViewModel"] VM1["暴露可观察的属性"] VM2["展示逻辑 + 业务逻辑"] end subgraph Model["Model"] M1["数据模型"] M2["数据访问 (API/DB)"] end View <-->|"数据绑定 (Binding)"| ViewModel ViewModel -->|"获取/更新数据"| Model MVVM的数据流 MVVM的核心原则是：View不直接访问Model，所有交互都通过ViewModel进行。在iOS开发中，由于UIViewController的特殊地位，MVVM的数据流可以更细化为四个角色： flowchart LR subgraph View["View"] V["纯UI展示用户交互触发"] end subgraph ViewController["ViewController"] VC["数据绑定生命周期管理路由/导航"] end subgraph ViewModel["ViewModel"] VM["业务逻辑数据转换状态管理"] end subgraph Model["Model"] M["数据结构数据存储"] end VC -->|"持有"| V VC -->|"持有"| VM V -->|"1. 用户交互"| VC VC -->|"2. 转发事件"| VM VM -->|"3. 业务处理"| M M -->|"4. 数据变化"| VM VM -->|"5. 状态更新"| VC VC -->|"6. 更新UI"| V 各层职责与持有关系 组件 职责 持有关系 View 纯UI展示、触发用户交互事件 不持有其他层 ViewController 数据绑定、生命周期管理、持有View和ViewModel 持有View和ViewModel ViewModel 业务逻辑、数据转换、状态管理 持有Model/Service Model 数据结构、数据存储 不持有其他层 详细数据流说明 View → ViewController（用户交互） ...

什么是TCA TCA（The Composable Architecture）是由Point-Free团队开发的Swift架构框架，受Elm和Redux启发，为Apple平台提供了一套完整的应用构建工具，涵盖状态管理、副作用处理、模块化组合以及测试支持。 GitHub仓库：swift-composable-architecture 适用平台：iOS、macOS、iPadOS、visionOS、tvOS、watchOS 适用UI框架：SwiftUI、UIKit TCA的核心理念是：将应用状态、变更动作、副作用和依赖显式化，构建可组合、可测试的单向数据流架构。整体架构与Swift的语言特性（值语义、async/await、Observation、SwiftUI）紧密结合，强调小而纯的Reducer组合与明确的副作用管理。 为什么需要TCA 在日常iOS开发中，TCA解决了以下核心问题： 状态管理：使用简单的值类型管理应用状态，支持在多个屏幕间共享状态，使一个屏幕的修改能立即反映到另一个屏幕 组合性：将大型功能拆分成可独立开发、独立测试的小组件，提取到独立模块后可轻松组合回完整功能 副作用处理：以最可测试和可理解的方式让应用的某些部分与外部世界通信 测试能力：不仅能测试单个功能，还能编写由多个部分组成的功能的集成测试，以及端到端测试来验证副作用如何影响应用 人机工程学：用尽可能少的概念和组成部分，通过简单的API实现以上所有目标 TCA的架构渊源 TCA的设计灵感主要来自Elm Architecture和Redux，同时与MVI架构思想有诸多相似之处，但在Swift生态中进行了大量增强： 特性 Elm/Redux/MVI TCA 核心思想 Action -> State -> View 单向数据流 同样的单向数据流，但深度融合Swift特性 副作用处理 自定义Middleware或自行实现 内置Effect系统（基于async/await） 依赖注入 需手动实现 内置@Dependency系统 测试支持 需自己构建 提供TestStore，支持穷尽式断言 组合能力 基础支持 Scope、forEach等丰富的Reducer组合手段 导航管理 需自己实现 内置状态化导航系统 状态共享 需自己实现 内置@Shared系统 TCA的核心概念 TCA包含以下核心概念： Feature：一个功能模块的整体单元，由@Reducer标注，内含State、Action和Reducer State：描述功能所需的数据 Action：功能中可能发生的所有事件 Reducer：接收State和Action，更新State并产生副作用（Effect） Store：持有State、驱动Reducer执行的运行时 Scope：从父Store中切出子Store，实现Feature的模块化组合 Effect：封装异步操作的副作用 Dependency：可替换的外部依赖 它们之间的协作关系如下： flowchart LR View -->|"send(Action)"| Store Store -->|"传递 State + Action"| Reducer Reducer -->|"更新后的 State"| Store Reducer -->|"返回 Effect"| Store Store -->|"State 变化驱动"| View Store -.->|"scope"| ChildStore["子Store"] State（状态） State是描述功能模块在某一时刻全部数据的值类型结构体： ...

什么是VIPER VIPER是一种更加细粒度的架构模式，由Mutual Mobile公司提出。VIPER将应用分为五个层次： View（视图）：负责UI展示 Interactor（交互器）：负责业务逻辑 Presenter（展示器）：负责视图逻辑 Entity（实体）：数据模型 Router（路由）：负责页面导航 VIPER的核心思想是单一职责原则，每个组件只负责一件事。 VIPER的结构 flowchart TB subgraph Module["Module"] View["View"] Presenter["Presenter"] Interactor["Interactor"] Router["Router"] Entity["Entity"] View -->|用户事件| Presenter Presenter -->|更新UI| View Presenter -->|业务请求| Interactor Interactor -->|业务结果| Presenter Presenter -->|导航请求| Router Interactor -->|读写数据| Entity Router -.->|创建并导航到其他模块| View end 数据流向说明 用户交互流：View → Presenter → Interactor → Presenter → View 导航流：View → Presenter → Router → 新的 View 数据流：Interactor → Entity（数据存储）→ Interactor → Presenter → View（数据展示） VIPER的五个组件 View（视图层） View负责： 展示UI 接收用户输入并传递给Presenter 实现Presenter定义的协议 // View协议 protocol UserListViewProtocol: AnyObject { func showLoading() func showUsers(_ users: [UserViewModel]) func showError(_ message: String) } // ViewController实现 class UserListViewController: UIViewController, UserListViewProtocol { var presenter: UserListPresenterProtocol! private var users: [UserViewModel] = [] override func viewDidLoad() { super.viewDidLoad() presenter.viewDidLoad() } func showUsers(_ users: [UserViewModel]) { self.users = users tableView.reloadData() } func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { presenter.didSelectUser(at: indexPath.row) } } Interactor（交互器） Interactor负责： ...

什么是架构 软件架构是指软件系统的高层结构，定义了系统的各个组成部分及其之间的关系。一个好的架构能够帮助我们： 职责分离：将不同的功能模块分开，降低耦合度 可测试性：使代码更容易进行单元测试 可维护性：便于理解和修改代码 可扩展性：方便添加新功能 团队协作：不同开发者可以并行开发不同模块 架构的两个层次 在讨论iOS架构时，需要区分两种不同层次的架构： 类型 关注点 代表模式 页面架构 单个页面内的代码组织 MVC、MVP、MVVM、MVI、TCA、VIPER 工程架构 整个App的模块划分与通信 组件化、插件化、微服务化 两者并不冲突，大型项目通常会同时采用：工程层面使用组件化拆分业务，每个组件内部使用MVVM等页面架构。 页面架构模式 MVC (Model-View-Controller) MVC是Apple官方推荐的架构模式，也是iOS开发中最基础的架构。 flowchart LR Controller <-->|读写| Model Controller -->|更新| View View -.->|用户交互| Controller 特点： Controller作为中介者连接Model和View View和Model不直接通信 在iOS中，ViewController往往承担了过多职责 MVP (Model-View-Presenter) MVP是MVC的演进版本，将业务逻辑从Controller中抽离到Presenter。 flowchart LR Presenter -->|更新| Model Presenter -->|更新| View Model -.->|数据| Presenter View -.->|事件| Presenter View --- ViewController 特点： Presenter持有View的引用（通常是协议） View变得非常"被动"，只负责展示 便于单元测试 MVVM (Model-View-ViewModel) MVVM通过数据绑定实现View和ViewModel的同步更新。 flowchart LR ViewModel <-->|读写| Model ViewModel <-->|数据绑定| View 特点： ...

什么是客户端微服务化 微服务化是将后端微服务的思想应用到客户端，将App内部按业务域拆分为多个独立服务。每个服务拥有独立的数据存储和业务逻辑，服务间通过定义良好的接口通信。 微服务化的核心关注点是： 业务域的逻辑划分：按领域边界划分服务，而非按代码结构 运行时隔离：服务在运行时保持独立，数据不互相污染 服务自治：每个服务独立演进，对外提供稳定的契约 客户端微服务化 vs 后端微服务 维度 后端微服务 客户端微服务化 部署 独立部署、独立运行的进程 同一App内的独立服务 通信 HTTP/RPC/消息队列 进程内通信（协议、事件总线） 数据库 每个服务独立数据库 每个服务独立数据存储空间 扩缩容 水平扩展多实例 不适用 故障隔离 进程级隔离 逻辑隔离（防御性编程） 核心目标 独立部署、水平扩展 业务域划分、运行时隔离 微服务化与组件化的关系 微服务化和组件化是不同维度的概念： flowchart TB subgraph 组件化视角["组件化视角 (物理结构)"] C1["首页组件"] C2["商城组件"] C3["用户组件"] C4["订单组件"] end subgraph 微服务化视角["微服务化视角 (逻辑划分)"] S1["用户服务"] S2["交易服务"] S3["内容服务"] end C3 -.->|"实现"| S1 C4 -.->|"实现"| S2 C2 -.->|"实现"| S2 C1 -.->|"实现"| S3 维度 组件化 微服务化 关注点 代码的物理隔离、编译解耦 业务域的逻辑划分、运行时隔离 划分依据 功能模块、代码边界 业务领域、数据边界 解决的问题 编译依赖、团队协作、代码复用 业务自治、数据隔离、服务演进 粒度 可大可小（页面、功能模块） 通常较粗（业务域） 实践中两者结合使用： ...

什么是插件化 在iOS开发中，插件化通常指的是编译期插件化，即通过壳工程（Shell Project）按需装配不同的业务组件，生成不同功能的App。这与Android的运行时插件化（动态加载代码）有本质区别。 iOS插件化 vs Android插件化 特性 Android插件化 iOS插件化 实现方式 运行时动态加载APK/DEX 编译期按需集成组件 代码热更新 支持 不支持（App Store限制） 主要目的 绕过包大小限制、热修复 多App复用、编译提效 技术难度 高（Hook系统API） 中（工程配置） iOS的"插件化"主要体现在： 壳工程设计：一套代码支撑多个App 配置驱动集成：通过配置文件决定集成哪些组件 二进制化提效：稳定组件编译为二进制，减少编译时间 flowchart TB subgraph 组件库["组件仓库"] A[用户组件] B[商城组件] C[直播组件] D[社区组件] E[基础组件] end subgraph 壳工程["壳工程 (Shell Project)"] Config["配置文件"] Shell["壳工程代码"] end subgraph Apps["生成的App"] App1["App A(用户+商城+基础)"] App2["App B(用户+直播+基础)"] App3["App C(全量组件)"] end A & B & C & D & E --> Config Config -->|"按需装配"| App1 Config -->|"按需装配"| App2 Config -->|"按需装配"| App3 两种插件化实现方式 根据组件间通信方案的不同，iOS插件化有两种主要实现方式，它们的核心区别在于是否强制要求编译期隔离： ...

什么是组件化 组件化是一种工程架构思想，将一个大型App拆分为多个独立的业务组件（Module），每个组件可以独立开发、独立测试、独立编译，组件之间通过中间层进行解耦通信。 组件化解决的问题 问题 未组件化 组件化后 编译速度 全量编译，耗时长 只编译修改的组件，支持二进制化 团队协作 代码冲突频繁 独立仓库，减少冲突 代码复用 复制粘贴，难以维护 组件复用，统一维护 耦合度 类之间直接依赖，牵一发动全身 通过中间层通信，解耦 测试 难以单元测试 组件可独立测试 组件化与页面架构的关系 组件化是工程架构，关注的是App整体的模块划分和通信方式；而MVC、MVVM、TCA等是页面架构，关注的是单个页面内的代码组织。 两者并不冲突，在大型项目中通常会同时采用： 工程层面：使用组件化拆分业务模块 组件内部：每个组件使用MVVM/TCA等页面架构 flowchart TB subgraph App["App壳工程"] subgraph Module1["首页组件"] M1V["View"] M1VM["ViewModel"] M1M["Model"] end subgraph Module2["商城组件"] M2V["View"] M2VM["ViewModel"] M2M["Model"] end Router["路由/中间件"] end Module1 <--> Router Module2 <--> Router 组件化的分层架构 典型的组件化架构采用三层结构： flowchart TB subgraph 业务层["业务层 - Business Layer"] A[首页组件] B[商城组件] C[用户组件] D[消息组件] end subgraph 中间层["中间层 - Mediator Layer"] E[路由Router] F[服务Service] end subgraph 基础层["基础层 - Foundation Layer"] G[网络库] H[图片库] I[数据库] J[工具库] end A & B & C & D --> E & F E & F --> G & H & I & J 业务层（Business Layer） 业务层包含各个业务组件，每个组件是一个独立的业务单元： ...