现在越来越多的APP拥有资讯页,既可以看资讯,也可以看引荐写谈论等等,这部分基本组成都是WKWebView 和 UITableView 嵌套,我对比了下现有的一些干流解决计划,看看各自的优缺陷及其我的优化解决计划>

1、WKWebView 直接作为 UITableView 的tableHeaderView

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

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

这种方法尽管简略粗暴,可是不引荐用在项目里,缺陷很多,内存占用量大,滑动可能还卡顿,甚至一些网页的弹窗之类的居中居上显示的也会由于不在屏幕内看不到,严重影响客户运用

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

据@xuning0大神的说法,这个是简书运用的计划,详细的可以去那个文章去看,主要原理是将tableView贴到webView的scrollView上,并且制止了webView和tableView的翻滚,改用自定义手势和UIDynamicAnimator 进行模仿阻尼翻滚操作

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

3、将webView和tableView加到ScrollView上

腾讯新闻和今天头条都是运用的这个计划,原理如下图

\

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

原理图来自文章

这个原理是将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的高度

这个也是我总结了这么多计划优化出来的最引荐的计划,原理图如下:

\

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

原理是,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混合运用)