UITableView空调用beginUpdates/endUpdates有何作用？能否删除？

核心结论 #

不建议无验证批量全局删除，但在目前新iOS系统下，绝大多数这类空调用都是无意义的历史遗留代码。 #

这类空写法的潜在历史作用 #

这是iOS开发圈早年非常常见的「魔法补丁」写法，基本都是为了绕开苹果旧版系统的UITableView缺陷，常见作用有三个：

• 强制触发行高重算。在iOS7~iOS10阶段，AutoLayout动态行高（UITableViewAutomaticDimension）的逻辑非常不稳定，当cell内部内容更新（比如异步加载完图片、文本内容变更）导致约束变化时，系统不会自动刷新行高，很多开发者发现插入一对空的beginUpdates/endUpdates，会让tableView自动对所有可见行重新触发行高计算代理方法，平滑更新行高且不会像reloadData那样闪烁、丢失滚动位置，比逐行reload省事，就到处复用。
• 修复系统版本的UITableView内部状态错乱。iOS8、iOS9版本存在大量tableView的底层bug：比如编辑模式切换后选中态错位、reload单行后contentOffset随机跳动、组头/组脚位置偏移、滚动中插入行UI错位等，很多开发者调试时偶然发现加这对空调用能把tableView的内部布局状态重置到正常，就直接当万能fix加在各类操作后面，基本都不会写注释说明原因。
• 无闪烁触发表格布局刷新。比如修改tableView的contentInset、父视图尺寸变化（横竖屏切换、导航栏显隐）后，调用这对方法可以触发表格重新布局，不会触发全量cell重绘，也不会打断当前的滚动状态。

删除建议 #

1. 如果你的应用最低支持版本是iOS11及以上，这些空调用99%已经没有实际作用。苹果从iOS11开始重写了tableView的自动行高逻辑，早年的大部分内部状态bug也已修复，这类空调用只会额外触发一次无意义的行高计算，带来微小的性能损耗，验证后可以删除。
2. 删除时不要全局替换直接清掉，要针对加了这段代码的页面做针对性验证：
   • 重点测试动态行高场景：带富文本、折叠/展开、异步内容加载的cell，更新内容后看行高是否显示正常
   • 测试编辑交互：左滑删除、多选、拖拽排序后是否有UI错位、选中态异常
   • 测试页面切换、横竖屏切换、导航栏显隐场景下，tableView的滚动位置是否会跳动
   • 如果你的应用还需要兼容iOS10及更早版本，这类代码大概率是当时踩坑留的补丁，建议保留或者替换为更明确的逻辑，不要贸然删除。
3. 如果验证发现某段空调用删除后确实会复现问题，不要继续保留无注释的空写法，替换为明确的逻辑：比如需要刷新行高就明确调用performBatchUpdates:completion:（iOS11+）或者reload对应行，补上注释说明修复的是什么场景的问题，别给后续维护的人留困惑。

内容的提问来源于stack exchange，提问作者David Hoerl