iOS WKWebView 和 UITableView 嵌套解决方案对比

现在越来越多的APP拥有资讯页，既可以看资讯，也可以看推荐写评论等等，这部分基本组成都是WKWebView 和 UITableView 嵌套，我对比了下现有的一些主流解决方案，看看各自的优缺点及其我的优化解决方案

1、WKWebView 直接作为 UITableView 的 tableHeaderView 

这也是大多数开发之类需求第一个想到的方案，简单粗暴，关闭WKWebView的scrollEnabled属性后直接把tableView.tableHeaderView = webView，待webView加载完成后，将tableView的tableHeaderView的高度设置成webView.scrollView.contentSize，这里引用@xuning0 文章中的图作为演示

这种方法虽然简单粗暴，但是不推荐用在项目里，缺点很多，内存占用量大，滑动可能还卡顿，甚至一些网页的弹窗之类的居中居上显示的也会因为不在屏幕内看不到，严重影响客户使用

2、通过给HTML增加一个tableView大小的div实现

据@xuning0大神的说法，这个是使用的方案，详细的可以去那个文章去看，主要原理是将tableView贴到webView的scrollView上，并且禁止了webView和tableView的滚动，改用自定义手势和UIDynamicAnimator 进行模拟阻尼滚动操作

这种方案优点自不用说，内存占用小，嵌套滑动无卡顿，但是缺点还是存在的，禁止了webView的滚动后，网页的适配性就差了，像一些网页中的回到顶部之类的操作，还有二级页面加载及返回等情况，要在scrollViewDidScroll中不停的调js，这对代码的业务控制是个考验，毕竟那个方法调用次数很高

3、将webView和tableView加到ScrollView上

腾讯新闻和今日头条都是使用的这个方案，原理如下图

原理图来自文章

这个原理是将webView和tableView都贴到scrollView上，并且禁止了webView和tableView的滚动，然后将scrollView的contentSize设置成webView.scrollView.contentSize + tableView.contentSize ，滚动scrollView的时候不断的调整webView和tableView的contentOffset及位置

这种方案优点不用说，占用内存小，滑动流畅，也不用自定义拖动手势之类的，代码量相对较少，但是缺点也不少，和方案2一样，都是禁止了webView、tableView的滚动，所以当webView和tableView的contentSize改变时，必须处理好scrollView的contentOffset ，不然会有明显失真滑动，还有像网页内置的返回顶点啊，多级网页加载及返回啊，都要做特殊处理，对网页的格式和方案2一样都是比较严苛的。

4、webView置于tableView下面，设置tableHeaderView的高度

这个也是我总结了这么多方案优化出来的最推荐的方案，原理图如下：

原理是，webView和tableView都加在一个父视图上，然后tableView的tableHeaderView的高度和webView的contentSize一致，并且设置该tableHeaderView 不响应任何点击事件及手势，然后webView设置其contentInset属性，使contentInset.bottom = tableView.contentSize.height - tableHeaderView.bounds.size.height，然后使webView和tableView关联滑动。

这个方案优点很突出，内存占用少，且没有禁用任何滑动事件，对h5的跳转、滑动等适配的很好，当然也有一些缺点，就是不能设置tableView的tableHeaderView了，而且因为设置了webView的contentInset属性，涉及到safeArea的时候可能要手动调整contentInset属性

瑕不掩瑜，该方案是我对比总结出的最优方案，对此，我开发了一个框架，希望能帮助到各位，YBWebViewScrollNestView

参考资料：

1、UIWebView与UITableView的嵌套方案

2、iOS 资讯详情页实现(WebView和TableView混合使用)