通过Storyboard与代码添加UITableView代理、数据源的差异及性能对比

核心实现区别 #

• 开发流程与直观性
  Storyboard方式通过拖拽连线完成关联，在可视化界面里就能直接看到UITableView和ViewController的代理绑定关系，适合快速搭建UI原型，省去手动编写关联代码的步骤。而代码方式需要在viewDidLoad（或其他合适的生命周期方法）里手动执行：

  tableView.delegate = self
  tableView.dataSource = self
  

  完全通过代码控制关联逻辑，没有可视化界面的依赖。

• 关联时机
  Storyboard的代理关联是在ViewController通过init?(coder:)解码初始化的阶段完成的，这个时机早于viewDidLoad。而代码设置的时机由你自己决定，可以在viewDidLoad、viewWillAppear甚至运行时的任意时刻执行。

• 动态扩展性
  代码方式支持动态切换代理对象——比如某些场景下你需要临时将tableView的代理切换到另一个专门处理特定逻辑的对象，只需要重新赋值delegate/dataSource即可。而Storyboard的关联是静态的，默认情况下无法在运行时自动变更，必须通过代码重新覆盖才能修改。

• 可读性与维护性
  对于依赖Storyboard的项目，新开发者可以直观通过连线找到代理关系；但如果Storyboard包含大量控件或多个tableView，查找关联可能会比较繁琐。代码方式的关联逻辑直接写在代码中，通过搜索就能快速定位，更适合大型项目或偏好代码优先的团队协作场景。

性能差异：几乎可以忽略 #

两种设置方式在性能上没有实质性差异。不管是Storyboard连线还是代码赋值，最终都是将ViewController的引用赋值给UITableView的delegate和dataSource属性，底层的方法调用逻辑完全一致。

唯一可能存在的微小差异是Storyboard的关联在解码阶段完成，而代码设置在后续生命周期执行，但这个差异的量级极小，不会对应用的运行性能产生可感知的影响。真正影响UITableView性能的是你实现的代理方法逻辑——比如cellForRowAt中的复用优化、heightForRowAt的计算复杂度等，和代理的设置方式无关。

内容的提问来源于stack exchange，提问作者Zenil Lakhani