iOS WKWebview 白屏检测实现

自ios8推出wkwebview以来，极大改善了网页加载速度及内存泄漏问题，逐渐全面取代笨重的UIWebview。尽管高性能、高刷新的WKWebview在混合开发中大放异彩表现优异，但加载网页过程中出现异常白屏的现象却仍然屡见不鲜，且现有的api协议处理捕捉不到这种异常case，造成用户无用等待体验很差。

针对业务场景需求，实现加载白屏检测。考虑采用字节跳动团队提出的webview优化技术方案。在合适的加载时机对当前webview可视区域截图，并对此快照进行像素点遍历，如果非白屏颜色的像素点超过一定的阈值，认定其为非白屏，反之重新加载请求。

ios官方提供了简易的获取webview快照接口，通过异步回调拿到当前可视区域的屏幕截图。

为了提升检测性能，考虑将快照缩放至1/5，减少像素点总数，从而加快遍历速度。

注意这里有个小坑。由于缩略图的尺寸在 原图宽高缩放系数后可能不是整数，在布置画布重绘时默认向上取整，这就造成画布比实际缩略图大（混蛋啊 摔！）。在遍历缩略图像素时，会将图外画布上的像素纳入考虑范围，导致实际白屏页 像素占比并非100% 如图所示。因此使用floor将其尺寸大小向下取整。

遍历快照缩略图像素点，对白色像素(R:255 G: 255 B: 255)占比大于95%的页面，认定其为白屏。

仅需在合适的view生命周期内回调使用该函数方法即可检测出页面状态是否白屏，且性能损耗可忽略不计。

原文链接： >

最近据后台同事反馈说，某些接口调用的频率有点高，而这块业务还没完全开放，照理说很少会用到，于是让我查查怎么回事。

我看了下日志，把网络请求日志过滤出来，发现的确有问题，每次打开首页后都有许多那块业务相关的网络请求。于是马上联想到可能是因为首页改版之后嵌套使用了 ViewPager，业务未完全开放的那个 fragment 里嵌套了一个 ViewPager，里面有多个 fragment，这样每次打开首页都会去加载该 page，然后是一连串的 fragment 初始化以及网络请求，所以为了解决该问题就不得不使用懒加载。

最终想要实现的效果是：1) 当 fragment 不可见的时候不加载数据；2) 当数据已经加载过之后，除非手动刷新否则不重新请求数据。

首先，默认情况下，由于 ViewPager 会预加载左右两边相邻的 至少 1 个 fragment，通过 setOffscreenPageLimit() 设置预加载 page 数为 0 并不会起作用，这点从 ViewPager 的源码中可以看到：

从以上源码可以看出相邻 fragment 的加载是必然的，但是我们如果可以得知 fragment 可见性，那么就可以在 fragment 可见时才去加载数据。这样虽然不是完全的懒加载，只是数据懒加载，但是同样也可以满足我们的需求了。

那么 fragment 中有没有可以获取当前 fragment 是否可见的方法呢，当然是有的，它就是 setUserVisibleHint(boolean isVisibleToUser) 。

无论你使用的是 FragmentPagerAdapter 还是 FragmentStatePagerAdapter，当它们初始化 fragment 的时候，该方法都会被调用两次。

一次是在实例化的时候，也就是在 instantioateItem() 方法中：

一次是在用户滑动到当前 fragment 的时候，在 setPrimaryItem() 方法中：

另外，当用户从当前 fragment 滑出的时候，setPrimaryItem() 方法也会被调用。

来看下 setUserVisibleHint() 的注释：

系统正是通过该方法来判断当前 fragment 的 UI 是否对用户可见，而该方法被暴露出来的主要目的也是让我们可以提醒系统当前 fragment 已经不可见了，是时候重新更新 fragment 的生命周期了。

不过如果只是实现数据懒加载，我们不需要直接去调用该方法，只要覆写它并实现控制数据加载的逻辑就可以了。

这里我参考了一种比较简便的做法，原文来自 尹star 的 ViewPager+Fragment LazyLoad 最优解 。

实现效果： lazy_load_fragment_demo

项目地址： aJIEw/DemoUI-LazyLoadFragment

可以看到只有第一次进入 fragment 的时候才会加载数据，而且也不会主动加载相邻的 fragment 或者已经加载过的数据了。

首先，由于 setUserVisibleHint() 会在 fragment 实例化时就先被调用 (在 onAttach() 之前)，所以我们最好在 view 创建完毕之后加载数据，因此需要设置一个 view 是否初始化完毕的标志位。另外，当然也需要一个 view 是否可见的标志位，只有等到 view 可见才允许加载。然后还可以选择保存数据的初始化状态，这样可以控制在 fragment 生命周期中的合适时机重新加载数据。所以，我们需要以下 3 个标志位：

然后接下来分为两种情况，一种是 view 初始化完毕但是此时还不可见的情况。很显然，我们只要判断 setUserVisibleHint() 中参数的值就可以了：

还有一种情况是，如果当前 fragment 是整个 ViewPager 的第一个 fragment，那么 setUserVisibleHint(true) 会在 view 初始化之前就在 setPrimaryItem() 中被调用，此时 view 已经可见了，但是我们要等到 view 初始化才加载数据，所以我们要在某个地方判断 view 是否已经初始化并且去加载数据。

最好的地方是在 onActivityCreated() 中。根据 fragment 生命周期我们知道，onActivityCreated() 会在 onCreateView() 之后调用，此时 view 已经初始化完毕，我们可以在这里将 isViewInitiated 标记为 true，同时在这里为第一个显示的 fragment 加载数据：

最后，我们还需要判断下数据是否已经加载过，避免重复加载。

我们将以上所有判断逻辑写在 prepareFetchData() 中，判断条件为 view 已经初始化、可见且数据未加载：

最后再定义一个抽象方法 fetchData()，让子类去实现：

这样一个完整的数据懒加载就实现完毕了。

我们可以看下以上 *** 作的日志来验证下我们的想法。

第一次打开，FirstFragment 作为第一个可见的 fragment 立马被初始化：

此时 isVisibleToUser 会在 isViewInitiated 之前设为 true，所以 FirstFragment 会在 onActivityCreated() 中真正开始获取数据。

另外，由于预加载的存在，SecondFragment 也会被创建，但是此时还不可见：

当滑动到 SecondFragment 的时候，SecondFragment 状态变为可见，setUserVisibleHint(true) 被调用，所以开始获取数据：

而此时 FirstFragment 由可见变为不可见：

ThirdFragment 则开始第一次被创建，同样此时并不可见：

当滑动到 ThirdFragment 的时候，状态变为可见，所以也就开始获取数据：

此时 SecondFragment 由可见变为不可见：

而 FirstFragment 由于超出了 ViewPager 可以保存的 Fragment 的数量，所以被销毁：

此时 SecondFragment 重新变得可见：

而 FirstFragment 也开始重新被创建：

此时 FirstFragment 重新变得可见，虽然 FirstFragment 之前被销毁了，但是由于之前获取的数据会被恢复，所以现在不会重新去获取数据：

当然我们也可以选择在 onDestroy() 中将 isDataInitiated 置为 false，这样每次 fragment 重新创建都会重新获取数据。当然前提是你使用的是 FragmentStatePagerAdapter ，因为如果使用 FragmentPagerAdapter ，不会每次都调用 onDestroy()，fragment 实例会被保存。而 SecondFragment 再次变得不可见，ThirdFragment 被销毁，过程与 3 中移动到 ThirdFragment 类似，这里就不截图了。

通过以上日志，验证了我们的想法是对的。

另外，如果是 ViewPager 嵌套 ViewPager 其实效果也是一样的，如果不做特殊处理，相邻的 fragment 的会被加载，导致该 fragment 中的 ViewPager 会去加载其中的 fragment。

有时我们用 webView 展示 html 是需要自定义头部视图与底部视图，原生没有像 tableView 那样提供相应的方法。我们只能自己写了。

设置 contentInset，而不是 contentSize。

配置区头：

设置 contentSize 的时机是在 - (void)webViewDidFinishLoad:(UIWebView )webView 网页加载完成之后，此时 html 网页是和头部视图重叠在一起，需要 1s 左右时间更新视图，体验不好。而使用 contentInset 不会发生这种现象。

在 webView 加载完成后，获取 UIWebBrowserView 的 size 并重新设置 webView 的 contentSize。

UIWebBrowserView 是负责展示 html 内容的。

当你重新设置了layout(必须是这个)属性，需要调用layoutIfNeeded方法

严谨一点的解释：

setNeedLayout和layoutIfNeed，还有一个关联的方法是layoutSubviews，在我们没有任何干预的情况下，一个view的fram或bounds发生变化时，系统会设置一个flag给这个view，当下一个渲染时机到来时系统会重新按新的布局来渲染视图。setNeedLayout就是我们主动为这个视图设置一个flag，告诉系统这个视图再下一个时机到来时要重新渲染，而layoutIfNeed则是告诉系统，如果设置了flag那么不用等待时机到来了，直接渲染吧。而layoutSubviews这个方法是系统调用的，我们不需要主动调用，我们只需要调用layoutIfNeed就可以了，让系统判断是否在当前时机下立即渲染。

以上就是关于iOS WKWebview 白屏检测实现全部的内容，包括:iOS WKWebview 白屏检测实现、RecycleView可优化的点、Fragment 数据懒加载及原理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！