Android WebView 在开发过程中有哪些坑?

最近在做 WebView 调用手机系统相册、文件夹来上传图片和文件的时候,遇到了一个问题: Android 5.0+ 重写 onShowFileCho…
关注者
1,313
被浏览
172,480

46 个回答

做过几年浏览器开发,确实踩过一些坑,可惜当时习惯不好,解决完也没记录下来,可能再次提到具体问题,我才能想起来。

顺着 @李明亮 同学的回答,我补充下。

1. onPageFinished这个也是把我坑好久,进度条该结束的时候不结束,不该结束的时候提前结束,我总结根本原因还是不同版本浏览器内核的实现差异导致的,也深入过内核代码发现确实结束的回调时机有差异,除非自己做内核,否则除了尽可能的兼容处理外, 尽量保证它提前结束,因为迟迟不结束比提前结束体验要糟糕得多。

2. webView耗电的问题,我们之前发现的一个情况是,webView切换到后台时,如果当前页面有JS代码仍在不时的run, 就会导致比较严重的耗电,所以必须确保切换到后台后暂停JS执行,同时切回来的时候恢复它。

3. webView闪屏的问题,也是确实存在的,试验过,确实跟硬件渲染有关。

4. 数据积累也是头疼的问题,经常有用户抱怨它的空间被占满了,其实是webkit本身没有管理好缓存,不得不让浏览器开发人员涉法处理。

5.默认的webview滚动条确实很粗,但还是可以修改的。

想起来的的后面再补充:

webview原生支持js与native代码交互,可惜在4.2以下版本上有安全漏洞,当时被乌云报出来,事情还挺大,各大浏览器厂商都紧急应对,我们也还是想了其他办法,解决了这个问题。

其实所谓的WebView的各种坑,大部分是Webkit等内核的坑,其实只是它正常发展成熟过程中的一些遗留问题,随着版本的迭代演化,也在不断改进。 遗憾的是Android版本的严重碎片化,使得这些问题我们不得不面对。

作为Ninja浏览器(

mthli/Ninja · GitHub

)的开发者,我想我遇到的问题应该具有一些代表性吧。下面说说我比较困惑的几个地方。

  1. WebViewClient.onPageFinished()。你永远无法确定当WebView调用这个方法的时候,网页内容是否真的加载完毕了。当前正在加载的网页产生跳转的时候这个方法可能会被多次调用,StackOverflow上有比较具体的解释(How to listen for a Webview finishing loading a URL in Android?), 但其中列举的解决方法并不完美。所以当你的WebView需要加载各种各样的网页并且需要在页面加载完成时采取一些操作的话,可能WebChromeClient.onProgressChanged()比WebViewClient.onPageFinished()都要靠谱一些。
  2. WebView后台耗电问题。当你的程序调用了WebView加载网页,WebView会自己开启一些线程(?),如果你没有正确地将WebView销毁的话,这些残余的线程(?)会一直在后台运行,由此导致你的应用程序耗电量居高不下。对此我采用的处理方式比较偷懒,简单又粗暴(不建议),即在Activity.onDestroy()中直接调用System.exit(0),使得应用程序完全被移出虚拟机,这样就不会有任何问题了。
  3. 切换WebView闪屏问题。如果你需要在同一个ViewGroup中来回切换不同的WebView(包含了不同的网页内容)的话,你就会发现闪屏是不可避免的。这应该是Android硬件加速的Bug,如果关闭硬件加速这种情况会好很多,但无法获得很好的浏览体验,你会感觉网页滑动的时候一卡一卡的,不跟手。
  4. 数据积累问题。开启缓存什么的有利于网页的浏览体验,但你会发现即使是清除了必要的内容,比如Cache、Cookie、Form Data、History、Password等等东西,你的应用程序所占用的存储空间还是会越来越大,到最后只好手动到系统设置的应用信息界面里清除数据了 :(
  5. 滚动条问题。Android System WebView的横向滚动条真是好粗的有木有...

以上是我能想到的啦,没想到的大概是不重要所以自动忽略啦~

另外针对Android System WebView的相关开发,推荐看看Google官方的示例教程

GoogleChrome/chromium-webview-samples · GitHub

PS:我开发Android刚刚满一年,如有疏漏请多多指教 :)