架构 on Last Stand

MVC架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是MVC

MVC（Model-View-Controller）是Apple官方推荐的iOS应用架构模式，也是最基础、最常见的架构。它将应用分为三个核心组件：

Model（模型）：负责数据和业务逻辑
View（视图）：负责界面展示
Controller（控制器）：负责协调Model和View

MVC的结构（Apple MVC）

graph TD
V[View
UIView] -->|用户事件| C[Controller
UIViewController]
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架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是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架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是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架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是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）详解

Sat, 02 May 2026 22:32:27 +0800

什么是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架构详解

Sat, 02 May 2026 22:32:27 +0800

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

Sun, 21 Jun 2026 22:41:52 +0800

什么是架构

软件架构是指软件系统的高层结构，定义了系统的各个组成部分及其之间的关系。一个好的架构能够帮助我们：

职责分离：将不同的功能模块分开，降低耦合度
可测试性：使代码更容易进行单元测试
可维护性：便于理解和修改代码
可扩展性：方便添加新功能
团队协作：不同开发者可以并行开发不同模块

架构的两个层次

在讨论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

特点：

微服务化架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是客户端微服务化

微服务化是将后端微服务的思想应用到客户端，将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

维度	组件化	微服务化
关注点	代码的物理隔离、编译解耦	业务域的逻辑划分、运行时隔离
划分依据	功能模块、代码边界	业务领域、数据边界
解决的问题	编译依赖、团队协作、代码复用	业务自治、数据隔离、服务演进
粒度	可大可小（页面、功能模块）	通常较粗（业务域）

实践中两者结合使用：

插件化架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是插件化

在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插件化有两种主要实现方式，它们的核心区别在于是否强制要求编译期隔离：

组件化架构详解

Sat, 02 May 2026 22:32:27 +0800

什么是组件化

组件化是一种工程架构思想，将一个大型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）

业务层包含各个业务组件，每个组件是一个独立的业务单元：

架构

Thu, 10 Oct 2024 00:00:00 +0800

前言

在项目中经常存在如下问题：

1.模块拆分不合理
2.变量和函数命名不知所云
3.缺少注释或者是写了一堆描述不清的内容
4.重复的代码遍布各个角落等

因为这些不良的编程习惯，导致了项目越来越难以维护，程序性能越来越低，大大降低了日常的工作效率以及提高了公司的开发成本。

下面就以CSS在Vue3项目中的架构为切入点，通过减少CSS代码的冗余度和增强CSS代码的维护性、扩展性来提高我们的编程能力和项目架构能力。

CSS的设计模式

在学习CSS架构之前，我们先简单看一下常见的5种CSS设计模式，这些设计模式都为我们的CSS架构提供了一定的开发思路。

1.OOCSS模式

OOCSS(Object-Oriented CSS)字面意思是面向对象的CSS，在开发中它有如下的规范约定

减少对 HTML 结构的依赖

# bad
# 1.匹配效率低，影响css性能
# 2.和html耦合度高，维护性和扩展性低
.container-list ul li a {}

<div class="container-list">
 <ul>
 <li>
 <a>...</a>
 </li>
 </ul>
</div>

# good
.container-list .list-item {}

<div class="container-list">
 <ul>
 <li>
 <a class="list-item">...</a>
 </li>
 </ul>
</div>

增加样式的复用性

.label {
 # 公共代码
}
.label-danger {
 # 特定代码
}
.label-info {
 # 特定代码
}
<div>
 <p class="label label-danger"></p>
 <p class="label label-info"></p>
</div>

2.BEM模式

BEM 是进阶版的OOCSS，是一个分层系统，它把我们的网站分为三层，这三层正好对应着 BEM 三个英文单词的简写 block, element, modifier，分为为块层、元素层、修饰符层。