UITableView完整截图方案选型：两种实现的性能与最优方案咨询

我有一个视图控制器，UI布局如下：

• 顶部是包含3个UILabel的Header View
• 底部是包含2个UIButton的Footer View
• 中间为UITableView，动态加载，平均约有6个TableView Cell

Footer View中的截图按钮需要实现截取UITableView完整内容的功能，但在iPhone 6等小屏设备上，默认仅显示4个Cell，未滚动时点击截图会丢失最后2个Cell。此前修改UITableView Frame为Content Size的方案在iOS 13后因Content Size返回值不准确失效。

已尝试的两种解决方案 #

方案一：自定义动态高度TableView #

将UITableView嵌入UIScrollView并禁用滚动，强制一次性渲染所有Cell，通过自定义CMDynamicHeightAdjustedTableView类重写intrinsicContentSize等属性实现动态高度适配：

class CMDynamicHeightAdjustedTableView: UITableView {

  override var intrinsicContentSize: CGSize {
     self.layoutIfNeeded()
     return self.contentSize
  }

  override var contentSize: CGSize {
    didSet {
     self.invalidateIntrinsicContentSize()
    }
  }


  override func reloadData() {
      super.reloadData()
      self.invalidateIntrinsicContentSize()
  }
}

担忧点：重写intrinsicContentSize可能影响性能及Apple内部实现。

方案二：监听contentSize更新高度约束 #

为UITableView设置初始高度约束，监听contentSize的KeyPath来更新高度约束，但该监听在界面显示前会触发12-14次：

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    self.confirmationTableView.addObserver(self, forKeyPath: "contentSize", options: .new, context: nil)
}

override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
    if keyPath == "contentSize" {
        if object is UITableView {
            if let newvalue = change?[.newKey], let newSize = newvalue as? CGSize {
                self.confirmationTableViewHeightConstraint.constant = newSize.height
            }
        }
    }
}

咨询问题 #

1. 第二种方案是否会影响性能？
2. 两种方案哪个更优？
3. 是否有其他替代解决方案？

1. 方案二的性能影响 #

界面显示前触发12-14次contentSize监听属于正常现象，是UITableView布局过程中多次计算内容尺寸（如cell高度估算、布局调整）导致的。每次更新约束只是修改一个constant值，属于轻量级操作，结合你平均6个cell的场景，完全不会对性能造成明显影响。唯一要注意的是必须在viewWillDisappear中移除观察者，避免内存泄漏：

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    self.confirmationTableView.removeObserver(self, forKeyPath: "contentSize")
}

2. 两种方案的优劣对比 #

方案一 #

• 优点：实现简洁，通过intrinsicContentSize自动适配高度，无需手动管理约束；嵌入ScrollView后可让Header+TableView+Footer整体滚动，体验连贯。
• 缺点：强制一次性渲染所有cell，若后续cell数量增加（如超过20个），会导致初始加载性能下降；重写系统属性存在Apple后续修改TableView内部逻辑引发兼容性问题的风险。

方案二 #

• 优点：无需修改TableView子类，保留原生复用机制（cell数量增多时依然能高效复用），性能更稳定；仅动态调整高度约束，逻辑直观，兼容性风险低。
• 缺点：需要手动管理观察者的添加与移除，容易遗漏导致内存泄漏；多次触发约束更新，但实际影响可忽略。

结论：若你的tableView长期保持在10个cell以内，两种方案均可；但从兼容性和长期维护性来看，方案二更优——它遵循UITableView原生逻辑，没有对系统控件做侵入性修改。

3. 替代解决方案 #

方案三：截图前强制渲染所有cell #

无需修改tableView布局，在截图时临时调整tableView的frame为contentSize，强制渲染所有cell，截图后恢复原frame即可：

func captureFullTableView() -> UIImage? {
    // 保存原frame
    let originalFrame = confirmationTableView.frame
    // 临时设置frame为contentSize，强制渲染所有cell
    confirmationTableView.frame = CGRect(x: originalFrame.origin.x, y: originalFrame.origin.y, width: originalFrame.width, height: confirmationTableView.contentSize.height)
    // 强制完成布局
    confirmationTableView.layoutIfNeeded()
    
    // 执行截图
    UIGraphicsBeginImageContextWithOptions(confirmationTableView.contentSize, false, UIScreen.main.scale)
    confirmationTableView.layer.render(in: UIGraphicsGetCurrentContext()!)
    let image = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()
    
    // 恢复原frame
    confirmationTableView.frame = originalFrame
    confirmationTableView.layoutIfNeeded()
    
    return image
}

注意：此方法需确保tableView的contentSize准确，若使用自动计算cell高度，需提前完成所有cell的高度计算（如调用reloadData后等待布局完成）。iOS 13+中，只要cell高度计算逻辑正确（比如使用UITableView.automaticDimension并设置estimatedRowHeight），contentSize返回值是准确的——之前的失效大概率是未等待布局完成就获取尺寸导致的。

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