架构设计 | Last Stand

iOS 架构设计面试题

MVC架构详解

什么是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 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 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 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（The Composable Architecture）详解

什么是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 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架构概述

什么是架构软件架构是指软件系统的高层结构，定义了系统的各个组成部分及其之间的关系。一个好的架构能够帮助我们：职责分离：将不同的功能模块分开，降低耦合度可测试性：使代码更容易进行单元测试可维护性：便于理解和修改代码可扩展性：方便添加新功能团队协作：不同开发者可以并行开发不同模块架构的两个层次在讨论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）业务层包含各个业务组件，每个组件是一个独立的业务单元： ...