在最近一个资讯类项目里我遇到了一个不算冷门的诉求信息流列表里有些卡片的内容是一段带完整排版的网页而不是普通文本。后端直接丢过来一个URL或者一段拼接好的HTML字符串要求原样展示卡片高度还得随内容自动伸缩不能出现内嵌滚动条。第一反应当然是 WKWebView但真做起来才会发现把 WKWebView 塞进 UITableViewCell跟在普通 ViewController 里使用完全是两码事。这个需求踩坑不少也沉淀了不少经验今天系统性拆一遍给后面要接类似活儿的同学做个参考。1. 需求来龙去脉与技术选型1.1 为什么非要用 WebView先说说业务是怎么来的。资讯类App的信息流里除了常规的图文卡片还会混入一些专题页、富文本广告、商品图文详情、甚至活动H5。这些内容有共同特点排版复杂包含表格、多级引用、视频、图片懒加载、动态样式。如果用原生控件去渲染最接近的方案是 TextKit 或者 NSAttributedString 的 HTML 解析但实际体验下来复杂HTML的解析结果经常和老页面差距很大尤其是 CSS 布局、字体间距、图片圆角这些细节几乎没法还原。服务端的运营同学也不愿意为每个客户端单独出一套模板维护成本太高。于是 WKWebView 成了唯一现实的选择。它内部就是完整的浏览器引擎给定一份 HTML 或者 URL页面长什么样客户端就能渲染成什么样不做二次解释。更重要的是WKWebView 使用独立进程渲染JS 崩溃不会拖垮 App 主进程这在稳定性上比当年的 UIWebView 靠谱太多。Cell 内嵌这种需求本质上是把一个小浏览器塞进了复用队列好处是内容完全不受限坏处是 WebView 的异步加载模型和 TableView 的同步布局模型产生了冲突后面所有问题都从这个冲突里衍生出来。1.2 几种可选方案对比选型阶段我对比过几个路径列成表格更直观方案优点缺点结论UIWebView老项目改造容易已废弃内存占用高JS执行效率低直接排除WKWebView JS测高渲染能力强系统级组件稳定高度异步获取复用状态复杂采用当前主流第三方富文本渲染库高度同步计算滚动性能好复杂CSS支持差图片排版受限适合简单场景原生 TextKit无WebView内存开销遇到复杂标签基本失控只做摘要可以最终定下来走 WKWebView 这条路因为它是在渲染效果和开发成本之间平衡点最高的选择。第三方库渲染复杂网页时经常会出现字体对不齐、图片间距错乱的情况而且一旦网页模板升级原生解析库就要跟着适配永远在补窟窿。WKWebView 则是纯浏览器渲染网页模板想怎么改都行前端自己测试即可客户端不需要参与。方案定了接下来就是直面真正的难题高度怎么算复用怎么不乱滚动怎么不打架。下面逐个拆。2. 拆解核心难点单元格高度与复用2.1 高度不定是所有麻烦的根源UITableView 是一个同步布局模型tableView 在绘制每一行之前必须知道这一行有多高。虽然 iOS 11 之后有 UITableView.automaticDimension 和 estimatedRowHeight系统可以在拿到确切高度之前先估算一个值但最终还是要使用约束链或者 heightForRowAt 返回一个确定的高度来完成布局。问题恰恰在于WKWebView 内的网页高度是异步的。WebView 发出加载请求服务端返回HTML浏览器解析 DOM、加载 CSS、执行 JS、渲染图片这一整串过程少则几百毫秒多则几秒然后你才能通过 JavaScript 拿到 document 的 scrollHeight。也就是说初始化 Cell 时你根本不知道最终高度只能先给一个占位值等网页渲染完成之后反手再把真实高度抛回给 TableView请求它重新布局。这个异步高度回写机制是整套方案的核心。占位高度不能给 0给 0 会导致 cellForRow 阶段约束计算出 0 高度WebView 的 frame 宽度变成 0 或者极小值网页按 0 宽度去做 Viewport 渲染很容易出现白屏。经验值是用 60pt 做占位既能撑住 cell 不塌陷又不会让列表在加载时出现明显的大空白。待真实高度回来后再通过 reload 行更新。2.2 复用机制会把旧页面带到新行UITableView 的 cell 复用是它高性能的基石但也正是它让 WebView 内嵌变得棘手。当你快速滑动列表一个显示过第 3 行内容的 cell 离开屏幕后会被丢进复用池等它重新出山去承载第 19 行数据时cell 里的 WKWebView 仍然停留在第 3 行那个网页的最后状态。如果你直接绑新数据并 loadHTMLString用户会看到一瞬间的旧内容如果只是 bind 模型而没有判断当前加载状态新行内容甚至可能永远不被加载因为 WebView 的 url 还是旧的你以为绑定了新数据实际上页面没动。更隐蔽的一个问题是 WKWebView 的加载状态不能靠 url 完全判断。同样一个 URL后端数据可能已经变了但 WebView 可能走了缓存也可能没走加载同一个 URL 时如果判断 url 相同就跳过就会出现内容陈旧。所以我在代码里不比较 URL而是比较内容标识 contentKey。这个 key 由后端下发每个网页内容生成一个唯一值URL 变了、或 HTML 内容有任何变化key 都会变。用 key 而不是 URL 作为是否已经加载过的判断依据可以规避缓存导致的同 URL 不同内容问题。2.3 滚动冲突与手势问题Cell 里的 WKWebView 自带一个 UIScrollView如果不处理用户在列表上上下滑动时手势会被内层 WebView 的 scrollView 吞掉列表滚动立刻变得卡顿甚至滚不动。解决办法是禁用内层滚动webView.scrollView.isScrollEnabled false webView.scrollView.bounces false webView.scrollView.contentInsetAdjustmentBehavior .neverisScrollEnabled false 之后滚动手势会穿透到外层 TableView列表滚动恢复正常。但这里有个细节千万不要尝试给 webView.scrollView.delegate 随意赋值去拦截手势。WKWebView 内部自己管理 scrollView 的 delegate实际上是 UIScrollViewDelegate 的内部代理链如果你强行替换很容易在滑动网页或触发一些网页内手势时产生系统日志警告甚至手势失效。我踩过这个坑后来把代理逻辑全部移除只通过网络滚动监听的方式做联动才稳定下来。另外禁用滚动不代表网页内的超链接点击、长按图片、文字选择失效。那些是 WebView 内建的 gesture recognizer跟外层 tableView 的 panGestureRecognizer 之间可能产生冲突尤其是在用户试图滑动列表但手指落在链接上的时候。一般场景下系统会自己权衡优先级不用太担心。如果你的页面里嵌了可横向滑动的轮播图组件那横向手势还要单独处理这里先不做展开。3. 落地实现代码主流程3.1 数据模型与高度缓存先聊数据层。Cell 的数据模型不需要复杂关键是带一个 contentKeystruct WebContentModel { let contentKey: String let htmlString: String? let urlString: String? }和它配套的是一个高度缓存。为什么一定要缓存因为 WebView 加载是不可控的如果一个网页内容每次被展示都要重新走一遍加载 - 执行JS - 报告高度 - 刷新列表的流程用户滑动时会频繁看到卡片高度跳来跳去列表滚动的流畅度也会被反复 reload 击穿。有了缓存第一次计算完成后凡是遇到相同 contentKey直接返回已存高度Cell 不需要重新加载列表滚动如丝般顺滑。这里我给一个单例缓存的设计final class WebContentHeightCache { static let shared WebContentHeightCache() private var cache: [String: CGFloat] [:] func height(for key: String) - CGFloat? { return cache[key] } func setHeight(_ height: CGFloat, for key: String) { guard height 0 else { return } cache[key] height } func clear() { cache.removeAll() } }这个类简单到我一度怀疑是不是过度设计但实际项目中它帮了大忙。列表里有几十个内嵌网页卡片如果没有缓存每次 reload 都会触发网络加载或本地HTML渲染性能差别是数量级的。3.2 Cell中的WebView初始化与布局约束Cell 的布局是整套方案最容易埋雷的地方。先看代码final class EmbedWebCell: UITableViewCell { private var webView: WKWebView! private var heightConstraint: NSLayoutConstraint! private var loadedKey: String? private var currentKey: String? var onHeightUpdate: ((String, CGFloat) - Void)? override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) { super.init(style: style, reuseIdentifier: reuseIdentifier) setupWebView() } required init?(coder: NSCoder) { fatalError(init(coder:) has not been implemented) } private func setupWebView() { let config WKWebViewConfiguration() let prefs WKPreferences() prefs.javaScriptCanOpenWindowsAutomatically false config.preferences prefs config.allowsInlineMediaPlayback true webView WKWebView(frame: .zero, configuration: config) webView.navigationDelegate self webView.scrollView.isScrollEnabled false webView.scrollView.bounces false webView.scrollView.contentInsetAdjustmentBehavior .never webView.translatesAutoresizingMaskIntoConstraints false webView.isOpaque false webView.backgroundColor .white contentView.addSubview(webView) heightConstraint webView.heightAnchor.constraint(equalToConstant: 60) heightConstraint.priority .defaultHigh NSLayoutConstraint.activate([ webView.topAnchor.constraint(equalTo: contentView.topAnchor), webView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), webView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), webView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), heightConstraint ]) } func bind(with model: WebContentModel) { currentKey model.contentKey guard loadedKey ! model.contentKey else { return } if let html model.htmlString { webView.loadHTMLString(html, baseURL: nil) } else if let urlString model.urlString, let url URL(string: urlString) { let request URLRequest(url: url) webView.load(request) } loadedKey model.contentKey } }几个关键点逐个解释。heightConstraint 的优先级我特意设置为 .defaultHigh750而不是必须1000。原因是同时存在 webView 的 top、bottom 和 height 三个约束当 height 作为一个需求值参与约束求解时万一某个极短瞬间估算高度刚刚修改、而 cell 约束链还没来得及重新计算自动布局系统可能会报约束冲突控制台一片红字。设置成 750 之后Auto Layout 会优先满足 top 和 bottom 的关联然后尽可能去贴合 height既不会出现约束错误又能让 cell 高度跟随 heightConstraint 变化。这是很多实现里没注意到的细节但实战里非常管用。webView.backgroundColor 设置成白色、isOpaque 为 false是为了避免黑色背景在加载瞬间闪烁。WKWebView 默认在页面没有背景色时可能会用透明或者黑色的背景视觉上像闪了一下。明确设置背景后哪怕内容还没渲染出来Cell 至少看起来是干净的白卡片。3.3 通过JavaScript获取页面真实高度页面加载完成的时机要通过 WKNavigationDelegate 回调拿到然后再用 JavaScript 取高度。理论上didFinish 表示主页面加载完成但此时网页里的图片可能还在异步加载所以单纯在 didFinish 里取一次高度往往不够这个问题我放在后面的坑点里细说。先看最基本的实现extension EmbedWebCell: WKNavigationDelegate { func webView(_ webView: WKWebView, didFinish navigation: WKNavigation!) { reportContentHeight() } func webView(_ webView: WKWebView, didFail navigation: WKNavigation!, withError error: Error) { loadedKey nil } func webView(_ webView: WKWebView, didFailProvisionalNavigation navigation: WKNavigation!, withError error: Error) { loadedKey nil } private func reportContentHeight() { let js (function() { var body document.body; var html document.documentElement; return Math.max( body.scrollHeight, body.offsetHeight, html.clientHeight, html.scrollHeight, html.offsetHeight ); })(); webView.evaluateJavaScript(js) { [weak self] result, error in guard let self self, let key self.currentKey else { return } if let height result as? CGFloat, height 0 { DispatchQueue.main.async { self.heightConstraint.constant height self.onHeightUpdate?(key, height) } } } } }JS 里取高度为什么要用 Math.max 套这么多样式值因为不同网页、不同 CSS 写法body.scrollHeight 和 document.documentElement.scrollHeight 的结果不一定一致。有的页面内容放在 body 上有的放在 html 上有的页面 body 有 margin 导致 offsetHeight 偏小。用 Max 合并多个标准高度值兼容性最好实测下来绝大多数页面的返回值都正确。注意一个细节evaluateJavaScript 的调用一定要在主线程回调默认也在主线程队列之所以再包一层 DispatchQueue.main.async是因为在实际项目中偶尔会遇到回调被派发到非主队列的情况加一层保险避免在后面更新约束时踩线程警告。3.4 用回调刷新TableViewCell 内部不应该持有 TableView那样会造成耦合也不利于复用。正确的做法是给 Cell 一个闭包回调高度计算完以后对外通知。Controller 拿到 key 和高度先更新缓存再找到 key 对应的 indexPath执行局部刷新。func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) - UITableViewCell { let cell tableView.dequeueReusableCell(withIdentifier: EmbedWebCell, for: indexPath) as! EmbedWebCell let model items[indexPath.row] cell.onHeightUpdate { [weak self] key, height in guard let self self else { return } WebContentHeightCache.shared.setHeight(height, for: key) guard let row self.items.firstIndex(where: { $0.contentKey key }) else { return } let target IndexPath(row: row, section: 0) UIView.performWithoutAnimation { self.tableView.reloadRows(at: [target], with: .none) } } cell.bind(with: model) return cell } func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) - CGFloat { let key items[indexPath.row].contentKey return WebContentHeightCache.shared.height(for: key) ?? 60 }这里有几个容易犯的错。第一reload 前必须确认 key 对应的 row 仍然存在。如果列表数据源发生过增删操作之前的 row 索引可能失效强行 reload 会触发Invalid update崩溃。所以每次回调里都通过 firstIndex 重新找一次 row不要直接拿回调时的旧 IndexPath 去刷新。第二用 UIView.performWithoutAnimation 包住 reloadRows是为了避免刷新时系统自带动画把 cell 从旧高度弹跳到新高度那种跳动感在信息流里非常明显。无动画刷新虽然突兀了一点但至少干净。第三闭包在 Cell 复用时有可能被释放。所以 onHeightUpdate 每次在 cellForRowAt 时都会被重新赋值。这里不需要 weak cell因为闭包被 cell 持有只要没有循环引用就行。我在这段代码里闭包捕获的是 selfController所以必须用 weak self否则 Controller 被 cell 的闭包持有形成循环引用。4. 复用策略与生命周期管理4.1 prepareForReuse里的清理工作复用池把 Cell 再交给你的时候第一件事是清理旧状态。我的做法是override func prepareForReuse() { super.prepareForReuse() webView.stopLoading() loadedKey nil currentKey nil heightConstraint.constant 60 webView.load(URLRequest(url: URL(string: about:blank)!)) }stopLoading 是为了避免上一个页面的网络请求还在跑就被迫切去新页面。loadedKey 和 currentKey 都清空防止误判内容已加载。占位高度恢复 60让 cell 在没有新高度回来之前维持基本形态。about:blank 的作用是把 WebView 当前页面内容清空避免快速滚动时出现上一行的页面残留在新一行的视觉错乱。代价是每次复用都会先白一下。这是取舍问题如果要彻底避免旧内容闪现about:blank 几乎是必须的如果你能接受轻微白屏也可以用空字符串 loadHTMLString(, baseURL: nil) 代替。我实测下来about:blank 更稳因为它不会触发一些网页自身的隐藏逻辑。不过这里要提醒一点prepareForReuse 里的 about:blank 加载是异步的它可能在你 bind 完新内容之后才真正执行完导致新内容被空白页顶掉。所以 bind 里的 guard 判断不能只依赖 loadedKey这是一个时序坑。我的解法是在 prepareForReuse 里直接把 loadedKey 置为 nil这样下次 bind 一定会触发新的 load就没有旧内容残留的空间了。4.2 避免重复加载同一个URL放过我了加载一次就好的需求之后bind 里的这个 guard 就非常重要guard loadedKey ! model.contentKey else { return }同样的内容不管是正常重新进入屏幕还是因 reloadRows 引发的 cellForRowAt 重新调用都不会再触发一次网络加载。配合高度缓存Cell 就能做到高度稳定 内容稳定 零重复请求。但注意我这里用的是 contentKey 而不是 URL。原因前面提过同一 URL 指向的网页内容可能已经变化而后端可能返回 304 让 WebView 直接用缓存。你无法通过 URL 判断页面是否更新。所以 contentKey 必须由后端在下发数据时给出它是内容的语义化唯一标识。如果没有 contentKey就只能退而求其次用 htmlString 的 hash 或者 URL 更新时间的拼接效果会差一些但也能用。4.3 内存优化控制在4个WebView以内WKWebView 虽然是独立进程但每一个实例都会占用不少内存。实际项目中我观察到同时活跃的 WKWebView 实例如果超过一定数量系统会对较新的 WebView 做加载限流页面会一直转圈直到某个旧实例被销毁。经验上限是 4 个超过之后加载行为变得不可预测。在 UITableView 的复用机制里理论上一屏只显示两三个内嵌网页 Cell不会超过 4 个。但如果你在列表之外还有别的页面持有 WKWebView或者 cell 高度特别小导致一屏显示了 5 个以上网页 Cell问题就来了。我的处理策略是所有内嵌 WebView 使用同一个 WKWebViewConfiguration 创建共享进程池。然后尽量避免在同一个 Controller 里同时存在多个独立的 WKWebView 页面。如果业务上必须让多个页面共存就要考虑滑动停止后才触发加载的懒加载策略不要一出屏幕就立刻 preload 所有 cell。另外WKWebView 的 configuration 里可以注入一些禁用项来降低内存占用比如关闭媒体播放、限制 JavaScript 功能。但如果你的页面本身依赖动态交互这个优化要谨慎。我在项目中只是关闭了 javaScriptCanOpenWindowsAutomatically其余保持默认内存整体可控。5. 常见问题排查与避坑实录5.1 白屏与高度为0这个是新手遇到最多的现象。页面加载不出来Cell 变成白卡片或者黑卡片。我排查过好几轮原因基本集中在三处。第一WebView 在 Auto Layout 还没有确定宽度的时候就开始加载。比如 cell 刚从复用池出来width 约束还没算好webView.frame.size.width 可能是 0页面按 0 宽度去做 viewport 渲染结果所有内容被排挤到看不到的位置。解决思路是保证 WebView 先有明确的 frame 再触发加载或者在 load 之前强制 layoutIfNeeded。第二loadedKey 判断失误。比如同一个 key 的页面之前加载失败了loadedKey 却已经被赋上了下次 bind 走了 guard 直接 return导致页面迟迟不加载。所以我在 didFail 和 didFailProvisionalNavigation 里都会把 loadedKey 置回 nil。第三JS 高度报告返回了 0。evaluateJavaScript 的返回值如果转换失败result 为 nilheight 默认为 0这时候 heightConstraint 被更新成 0Cell 直接塌掉。这里必须做height 0 才更新的判断。返回 0 时保持占位高度可以在 didFinish 之后延迟 0.2 秒再补一次高度计算。5.2 高度跳动与闪屏很多同学做完基础版后会发现列表滚动时高度在反复横跳刚加载完的卡片突然从 300 跳到 400或者从 200 跳到 150。根因有两个。一个是没有高度缓存。每次 reloadRows 或者每次重新进入屏幕都重新加载、重新计算哪怕内容一模一样。解决办法就是缓存前面已经给了实现。另一个是更新高度太频繁didFinish 回调一次图片加载完又回调一次JS 监听 DOM 变化再回调一次。每次回调都触发 reload滚动当然跳。解决办法是把回调收敛如果是比较稳定的页面只在 didFinish 里取一次高度如果必须处理图片延迟高度则可以做多次回调但只保留最后一次的合并逻辑并且每次回调之前先比较新旧高度差值小于 5pt 就忽略。另外刷新时无动画很重要这是肉眼感知跳动的主要原因。UIView.performWithoutAnimation 是必选项。5.3 图片懒加载导致内容高度一直不对这是内嵌网页最隐蔽的坑。很多移动端 H5 页面会做图片懒加载img 标签不直接给 src而是给>(function() { var imgs document.getElementsByTagName(img); for (var i 0; i imgs.length; i) { var img imgs[i]; if (img.getAttribute(data-src) !img.getAttribute(src)) { img.setAttribute(src, img.getAttribute(data-src)); } } })();这个 JS 要在 didFinish 之后执行一次高度计算之前执行。替换 src 后图片自然加载加载完成后再通过 img.onload 回调重新取高度。如果你用 IntersectionObserver 做懒加载的 H5在禁滚动的 WebView 里这个 observer 永远不会正确触发因为它依赖可视区域变化。让前端在页面内检测宿主环境是一个更优雅的解法但客户端没法强制只能后端或前端配合。5.4 转屏后高度错乱默认 portrait 下取的高度横屏时宽度变化网页重新排版内容高度必然变化。如果列表已经滚到某个位置用户旋转屏幕Cell 还拿着旧高度页面底部要么空白要么被裁掉。解决方案是在 Cell 的 layoutSubviews 中监听宽度变化。宽度变化后WebView 自身的 frame 会变化网页会重新布局此时重新执行一次高度计算 JS把新高度回传给 Controller。注意这里不能在 layoutSubviews 里每次都执行计算要加一个宽度标记private var lastLayoutWidth: CGFloat 0 override func layoutSubviews() { super.layoutSubviews() let currentWidth bounds.width if abs(currentWidth - lastLayoutWidth) 0.5 { lastLayoutWidth currentWidth if loadedKey ! nil { reportContentHeight() } } }这样横竖屏切换时Cell 会自动重新测高并刷新不会出现内容错位。5.5 fixed定位元素被裁切最后是一个很容易被忽略的体验问题。如果 H5 页面里存在 position: fixed 的元素比如悬浮按钮、返回顶部、底部工具栏在普通浏览器里它固定悬浮在视口上没问题但把页面塞进 Cell 后这个 fixed 元素的定位容器是 WebView 的可视区域而 WebView 的滚动被禁止了可视区域就只有 Cell 那么大。一个高 300 的页面、fixed 元素放在 bottom: 0它就贴在 Cell 最底部可能遮住内容如果页面高 1000fixed 元素就会被裁切掉大半用户根本看不到也就点不到。这个没法在客户端优雅解决。要么让前端针对内嵌场景把 fixed 改成 absolute要么在业务上禁止这类页面进入 Cell。我在项目中联系前端加了一个宿主环境判断参数WebView 加载时注入到 URL query 里H5 根据参数切换布局策略这才彻底解决。小结把 WKWebView 塞进 UITableViewCell核心不是 WebView 本身而是要让异步的网页加载和 TableView 同步的布局模型握手成功。高度缓存、内容标识、回调刷新、复用清理这四个环节环环相扣少一个都会在真实场景里暴露问题。我个人在实际项目中还有一个习惯先写一个纯 WKWebView 的 Demo 页面验证网页渲染效果再放进 Cell 里做高度联动一层一层往上叠不要一上来就直接在 Cell 里写逻辑否则遇到白屏问题时会很难定位是 WebView 配置问题还是 Cell 布局问题。这个需求做完之后最深的感受是Cell 内嵌网页并不难难的是把滑动列表的性能、稳定性和页面高度变化同时照顾好一旦这几个关键点想清楚剩下的事就都是体力活了。