问题—— 在许多项目中，ViewController常常成为代码堆积的重灾区：既要处理页面跳转和界面渲染，又要承担数据源回调、网络请求、缓存读写、数据过滤甚至格式化计算等任务。随着需求快速迭代，控制器文件不断膨胀，导致可读性下降、修改成本增加，进而引发缺陷和交付延迟。 原因—— 1. 职责边界模糊：部分团队为赶进度，习惯将逻辑直接塞入控制器，形成路径依赖。 2. 模块缺失：缺乏专门的数据源对象、服务层或网络管理模块时，控制器被迫充当“临时集成层”。 3. 复用不足：通用逻辑未被抽离，导致重复代码堆积，技术债持续增加。 影响—— 短期来看，控制器臃肿会加大问题排查和代码评审的难度，新成员上手困难；中期来看，功能扩展会增加回归测试压力，甚至因耦合过深阻碍架构升级；长期来看，难以形成可复用的能力资产，影响团队协作和工程质量。 对策—— 业界经验表明，解决方案在于将不同职责交还给对应模块，让ViewController回归“组织与协调”的核心功能。 1. 数据源专职化： 将UITableView或UICollectionView的数据源与代理回调拆分为独立对象，通过配置注入控制器。这样既能复用同一套逻辑，又能减少视图调整时的代码修改，使控制器更简洁。 2. 剥离弱业务逻辑： 日期计算、图片处理、缓存策略等非核心逻辑应从领域模型中剥离，封装为Utility或扩展方法。例如，控制器只需触发数据获取，而过滤和时间判断等细节由工具模块处理，保持页面层清晰。 3. 引入服务层Store： 将数据读写、缓存、错误处理等底层细节交由Store统一管理，控制器只需接收可直接展示的结果。这不仅能降低复杂度，还便于测试和维护。 4. 统一网络管理： 网络请求应由专门的NetworkManager封装，集中处理参数拼装、超时策略、错误码映射等问题。控制器只需触发请求和处理结果，避免各页面策略不一致。 前景—— 控制器“瘦身”不是单一技巧，而是涉及职责划分、能力沉淀和测试体系建设的系统工程。随着应用复杂度提升和团队协作常态化，该优化将推动代码从“页面驱动”转向“能力驱动”，为组件化、模块化和持续集成奠定基础。业内认为，标准化封装数据源、网络、存储等模块，将成为提升交付效率的关键。
代码混乱往往源于职责不清。视图控制器的“瘦身”之路，表明了软件工程对秩序与边界的追求。技术债务不会自动消失，唯有在架构设计时明确分层意识，才能在迭代中游刃有余。对工程师而言，写出可读、可测、可复用的代码，既是专业能力的体现，也是对团队和产品最切实的负责。