老项目的首页 ViewController。文件大小：33,623 字节。

不是压缩前的图片资源。不是第三方库，就是一个纯 Swift 文件。一个 ViewController。

打开它之后你会发现，这 33KB 不只是 UI 代码。照片授权状态在这里判断，全局单例在这里读写，导航跳转在这里拼装。 数据刷新在这里触发，订阅按钮的显隐在这里计算。 还有一个 UICollectionView，同时承载三组不同布局的卡片列表。所有的 delegate 和 data source 方法也全部塞在同一个类里。

这就是典型的"一把手 ViewController"——什么都能干，什么都自己干。

┌─────────────────────────────────────────────────────────────────┐
│ 拆之前 拆之后 │
│ │
│ CleanAI_Home_ViewController.swift Home/ │
│ ├── Controllers/ │
│ ┌──────────────────────┐ │ └── DashboardVC │
│ │ • UICollectionView │ ├── State/ │
│ │ delegate + dataSource│ │ ├── HomeFeature │
│ │ • 照片权限判断 │ │ └── ScanPresenter │
│ │ • 全局单例读写│ ├── Routing/ │
│ │ • 导航跳转 │ │ └── Coordinator │
│ │ • 数据刷新 + 缓存 │ └── Views/ |
│ └───┘ └───┘ ├── FeatureCard |
| ├── SummaryHeader |
| ├── LimitedAccess |
| └── TipViews ×4 |
|
| 每个文件只做一件事 |
└─┘ ┴─┘

老 VC 的职责混乱痛点

• 数据层混乱: 全局单例随意操作导致状态难以追踪
• 权限逻辑四散: 联系人、照片、通知权限检查分散在各处判断逻辑中
• UI布局复杂: 按钮约束与业务逻辑混杂
• 订阅状态耦合: SubscriptionShare.shared.isPro影响多处UI显示逻辑
• 导航控制失序: 随处可见的.setNavigationBarHidden
• UICollectionView过载: 一個delegatedataSource管着三组不同布局卡片
• 数据刷新黑箱化: .refreshHomeAfterPhotoDataChanged { publishHomeStates } updateVisibleTopCell
• 事件响应无序: 埋点上报、通知监听等事件处理逻辑随机插入代码中间
• <强>*痛点主要*: 已经形成"改动一处可能影响其他8个功能模块"的脆弱架构!

拆解第一步先这方面，先抽 State

🚨当前问题这方面，首页有8种清理功能。但它们分散在:

• - dataSource 的 section 和 row 中作为索引使用;话说回来，
• - cell 的类型判断中的if-else语句;
• - 埋点字符串拼接时硬编码;

// 新项目: 首次建立清晰界面!enum HomeFeature: CaseIterable,Hashable {
case similarPhotos;说起来，case duplicatePhotos;case similarVideos;case largeVideos;// ...
var title: String {
switch self {
// ...
}
}
}

🚨当前问题这方面。跳转逻辑集中在,包含:

• - 各种功能对应不同页面推送方式;
• - 参数传递复杂且易错;说起来，

// 新项目: 路由集中管理!final class HomeRouteCoordinator {
func navigate(to feature: HomeFeature。counts:) {
switch feature {
// ...
}
}

再看🚨当前问题，

• - UI布局直接用SnapKit拼出来;- 混合业务逻辑和子视图约束定义;

// 新项目：独立视图组件！final class HomeFeatureCardView {
private let iconView = UIImageView
private let titleLabel = UILabel
var onTapped:->Void)?

}


原本应该是完整HTML标签嵌套输出但因长度限制只截取部分关键代码段