iOS-关于WebView在长时间使用下的卡顿现象测试

Posted 2023-05-14

参考技术A 我的手机里常驻浏览器是海豚，最近在使用的时候发现出现卡顿现象，让使用体验变得非常不爽，大过年的闲来无聊就做了点测试。

症状：当一个WebView在重复打开达数十次甚至上百次时整个页面在滑动时会出现非常明显的卡顿现象。
解决方法：将WebView销毁，重新创建一个即可消除卡顿，除此之外刷新WebView亦或是其他方法都无法消除卡顿。
为了了解其实际情况，我制作了一个简单的Demo，通过Xcode相关工具实际检验来确定卡顿缘由。

我简单地创建了一个对照组，分别是UIWebView以及WKWebView制作的简易浏览器。
最开始我的想法是大量加载界面造成的卡顿可能是Safari内核的问题，UIWebView及WKWebView在大量重复加载后可能都会出现卡顿现象，总不可能海豚浏览器还是在使用UIWebViewd吧哈哈哈……哈哈……哈……
在实验结束后我开始不确定是我的检验手法出现问题还是海豚V9.3.0版本是使用UIWebView搭建的，本来我恶意地猜测是Safari内核有问题或者在WebView内部做了某些限制，在WebView大量重复使用后会限制什么东西，结果没想到最大的可能居然只是UIWebView的问题，真是索然无味。

两个对照组使用同样的样本进行测试，测试设备为iPhone5S，版本为9.3.2，测试样本为一本网络小说的前200章。

初始状态：

以上两张分别是UIWebView在初始状态下默认加载小说首页时静止状态与滑动状态下的资源利用率，可以发现CPU占用不高，此时界面也属于流畅状态。

以上两张分别是WKWebView的静止状态及滑动状态的资源占有率，不得不说苹果对WKKit的优化做足了心，内存占有根本不是一个级别的。
我们在WK的滑动图可以看出，此时两者在滑动状态下的CPU使用率是相近的，而实际上两者在初始状态下滑动手感也并无差别。

五十章节后：

可以看到，UIWebView的内存占用减少了，这是因为进入章节界面后图片的减少，之后的数据中内存占用大多保持在这一程度左右。而CPU在滑动状态下的占用率则是大大提升，并且峰值可以达到40%左右。

而相对的，WKWebView的占用率并没有明显提升。
此时，UIWebView的网页已经可以感觉到少许的卡顿。

一百章节后：

UIWebView的界面已造成明显卡顿现象，同时，CPU的占用率在滑动状态下也达到50%以上（测试下峰值曾达到80%以上）

WK淡定地表示再来一百章。
两百章后：

UIWebView因为疯狂卡顿导致Demo 页面长时间凝滞，无法测试。
而此时WK依旧淡定。

结论：Just Fuck UIWebView.出现的卡顿现象只是UIWebView自身缺陷导致的CPU使用量暴增从而造成的卡顿，在不清楚苹果在当初设计UIWebView的时候做了什么而在WKKit中又修改了什么东西弥补了这部分缺陷的情况下这只是又一次老生常谈，告诉大家抛弃UIWebView投向WKKit的怀抱。

关于ios中后台长时间下载任务的实现与走过的坑

先做一个简单的笔记

 

1.ios7之前实现后台长时间的任务是不可能完成的事情,即使使用timer监测一直索取的方式也不会打破ios系统最多允许应用后台运行10min的限定.

2.ios7之后出现了NSURLSession,这是一个福音.我们进行相应的配置,它就可以实现后台的长时间下载,并且超过系统的允许时间之后,程序被ios系统杀死,这个后台任务又由ios系统接手,并继续进行后台任务.

这是苹果的官方文档介绍:https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html

下边是主要点的截图: