与webview打交道踩过的坑

时间 2019-11-13

标签 webview 打交道繁體版

原文原文链接

随着HTML5被愈来愈多的用到web APP的开发当中，webview这一个神器便日渐凸显出重要地位。简要的说，webview可以在移动应用中开辟出一个窗口，在里面显示html页面，css以及js代码也能够被解析执行，它使用的是咱们熟悉的webkit内核。android和ios都有相应的API，因此写一份代码在多个平台运行的能力就是以webview为基础的。css

　　今天咱们要聊的不是如何使用webview，而是笔者本人做为一名前端工程师，在与客户端开发人员经过webview打交道中遇到的种种神奇事件。html

　　事情还得从去年提及，我仍是一个小白实习生的时候。当经理知道有webview这个神器以后，遂下令让android组和ios组削减工做内容，全部共同的界面均由web组提供。而web组当时处于“传统软件公司无前端”的局面，页面至关臃肿，压根不适于移动设备。因而乎，不明局势的经理指挥一个不明真相的小白实习生，带着还没使利索的jQuery，开始了所谓的Hybrid App开发。一个凄惨的故事拉开序幕，下面是在开发当中踩过的各类坑，记录下来以供备忘。前端

webview与设备自带浏览器同样吗？

　　webview会调用系统自带的浏览器内核来解析页面。这是个真命题吗？市场上的大部分平板电脑自带浏览器为webkit内核，webview使用的也是webkit内核，而且按一个应用的大小来看也不可能本身带一个内核进去。因此是调用系统自带的是没错的了。那我在一台设备上，使用浏览器打开一个页面和使用webview打开同一页面，获得的结果会是如出一辙吗？固然是废话了，都说了是调用关系。android

　　假如真是废话，那我也不必记下这一点了。由于从个人实际操做状况来看，有些时候确实是不同的。浏览器里一个样，webview里又是一个样。ipad上状况好些。在android品牌杂乱的设备上，此现象还真的出现不仅一次。尤为是页面DOM结构比较复杂的时候。ios

　　有理由怀疑个人代码不符合W3C规范啥的，但业界良心，W3C规范仍是不敢违反的。因此得出结论，webview与自带浏览器解析的结果并非彻底一致，不能觉得页面在浏览器中正常了，在移动设备上也就正常了。程序员

绝对要慎用的瀑布流

　　大概是两年前，瀑布流这个概念红遍大江南北，各网站纷纷效仿，相应的文章、jQuery插件层出不穷。后来真正有思想的人开始质疑，提出咱们要学习的不是瀑布流的形式，而是思想，咱们须要的是真正适合本身产品的东西。后来，咱们经理也据说了瀑布流这个东西。。。web

　　加！加瀑布流！咱们不要分页列表那些东西！因而小白实习生网上各类搜索，找到了当时比较流行的叫作infinitescroll的jQuery插件。各类改源码配合实现产品业务、各移动设备兼容性bug处理暂且放一边。这里要提的是与移动应用密切相关的一个问题。浏览器

　　作移动开发的对闪退这种现象估计是咬牙切齿，移动应用的性能问题一直是不容小觑的。就webview来说，当html页面的DOM元素不少，或者说层级关系较复杂时，对其的压力是至关大的。再看看咱们的瀑布流，随着页面的滚动，不断往上append节点，这对webview来讲压力极大，当节点数量到必定程度时，就发现页面滚动不是那么流畅，开始一卡一卡。别急，你在翻转一下屏幕试试，瞬间崩溃，界面这个花了，内容像是绘制不出来同样。由于在作横竖屏翻转时，解析引擎会进行页面的重绘，这么多的节点工做量可不小。ipad由于其优越的图像处理性能表现还不错，android设备上简直一塌糊涂。服务器

　　有什么解决办法呢？我在听一个大牛的经验分享会上曾听到，在页面滚动的时候能够经过计算，动态remove节点，保证用户能看到的地方是有内容的，其余滚动卷去的部分就直接remove掉，等滚动回来的时候再加回来。这样保证页面上的节点不会太多，性能天然提高。我没有尝试这种方案，其中的注意事项也很差说。不过大牛成功了，必然是可行的。前端工程师

　　总之得出一个结论，在移动设备上，要用瀑布流，必定要慎用，必须先有性能的解决办法。

　　今天咱们要聊的不是如何使用webview，而是笔者本人做为一名前端工程师，在与客户端开发人员经过webview打交道中遇到的种种神奇事件。

webview与设备自带浏览器同样吗？

　　假如真是废话，那我也不必记下这一点了。由于从个人实际操做状况来看，有些时候确实是不同的。浏览器里一个样，webview里又是一个样。ipad上状况好些。在android品牌杂乱的设备上，此现象还真的出现不仅一次。尤为是页面DOM结构比较复杂的时候。

　　有理由怀疑个人代码不符合W3C规范啥的，但业界良心，W3C规范仍是不敢违反的。因此得出结论，webview与自带浏览器解析的结果并非彻底一致，不能觉得页面在浏览器中正常了，在移动设备上也就正常了。

绝对要慎用的瀑布流

　　大概是两年前，瀑布流这个概念红遍大江南北，各网站纷纷效仿，相应的文章、jQuery插件层出不穷。后来真正有思想的人开始质疑，提出咱们要学习的不是瀑布流的形式，而是思想，咱们须要的是真正适合本身产品的东西。后来，咱们经理也据说了瀑布流这个东西。。。

　　加！加瀑布流！咱们不要分页列表那些东西！因而小白实习生网上各类搜索，找到了当时比较流行的叫作infinitescroll的jQuery插件。各类改源码配合实现产品业务、各移动设备兼容性bug处理暂且放一边。这里要提的是与移动应用密切相关的一个问题。

　　总之得出一个结论，在移动设备上，要用瀑布流，必定要慎用，必须先有性能的解决办法。

响应式布局与viewport

　　咱们知道移动设备在渲染页面的时候，会先在一个虚拟画布上渲染，而后再缩放到设备的尺寸，好比IOS是在宽度为980px的虚拟画布上渲染。咱们看一些响应式设计的文章，也会知道在页面<head>中要添加以下内容：

<meta name="viewport" content="width=device-width, initial-scale=1.0"/>

来保证页面会按照设备的宽度进行渲染而不是使用虚拟画布。而后即可以使用响应式设计的相关技术，弹性盒子、媒体查询等，让页面适应设备宽度显示。

　　然而我遇到了一个问题，由于页面结构较复杂，在横竖屏翻转的时候出现了花屏，各类显示不全，各类抽风抖动。固然是在android设备上。。。缘由就是设备的宽度发生变化webview要进行页面重绘，然而在重绘的过程当中，因为页面太复杂而不堪重负，绘到一半无论了。

　　由于当时该页面的设计，会显示图片、音频、视频等媒体，而且是多个同时显示，进行页面精简不可行。说来惭愧，面对紧迫的时间，我只好悄悄把上面的<meta>标签删掉，让页面仍是在虚拟画布上渲染，这样渲染好的页面在进行横竖屏翻转的时候，貌似是不会进行重绘的，只会由系统缩放一下，花屏的现象也不会发生了。只不过在竖屏下，页面元素明显小了。算是个下策。

　　像这样的状况，我的觉的在页面设计的时候就应该考虑到，若要进行横竖屏翻转，页面尽可能设计的精简清爽。不过话说回来，移动应用上的页面，精简是一直须要且必须的。

尽可能不要用别人的插件

　　不怕丢人的认可，咱们作web App用的是jQuery，原谅我当时是个小白吧。。。若是早些知道咱们的东西只需支持现代浏览器，不管如何也得试试zepto或是其余的小而轻的库。不过既然用了，仍是来面对这个现实吧。

　　小白的特征之一就是从素材网站收藏了好多jQuery插件，而后在项目中不假思索就用。咱们的页面是先在PC上用，而后才被告知要被webview引用的。这下麻烦来了，原先使用的好好的插件，一但跑在移动设备上，各类羊癫疯发做。而后开始竭尽全力的改源码，过程简直不堪回首。

　　比较典型的一个，咱们的页面中有富文本编辑器，当时选择的是国内的一款开源编辑器KindEditor。我没有诋毁这个项目的意思，它在PC上使用仍是蛮好的。一上了平板，直接傻了，基本上废了。环视网上，没有一款为移动设备设计的编辑器。因此编辑器这东西，仍是让本地代码来作比较合理。

　　另外一个插件用的比较痛苦的是H5视频播放的，用了mediaelement，它在官网宣称支持各浏览器各平台，然而真正效果却并不是宣称的那样。在android4.0以上的设备中都有各类兼容性问题。又是一顿改源码。。。

　　因此得出的结论就是，若是某个组件能够本身写出来，千万别从网上找别人的，到头来本身还得麻烦。假若真的准备要使用，必定先作一个全方位的测评。包括可否与你的业务逻辑完美融合，可否支持你所须要的设备。

:hover伪类在移动设备上的特殊现象

　　咱们在作鼠标悬停效果时，常常会用到:hover，不管用在<a>标签或是其余标签，现代浏览器都能正常兼容。好比我有一个图标，在鼠标移上去以后想要一个阴影效果，可能会这样写：

.icon:hover{box-shadow:2px 2px 2px;}

在移动设备上，是没有鼠标指针的。当用手指点击图标的时候，能够出现阴影效果，这种效果也是能够接受的。可是当点击完成后，手指离开了屏幕，图标的hover效果却没有消失，依然是带着阴影，就好像是有一个隐形的鼠标指针停留在图标上同样，实在是让人不能理解。当再点击页面的其余部分时，图标的hover效果就消失了，好像是隐形的鼠标指针移到了别的地方。

　　ipad和android设备上都有此现象。为了不此问题，css中的:hover伪类就必须利用媒体查询，只在桌面浏览器中生效。

ipad关闭屏幕形成的问题

　　ipad出于节约电量的设计，关闭屏幕后浏览器中的一些线程也会暂时关闭，等到开启屏幕时再起。若是有须要持续执行的js代码，关闭屏幕后便没法工做了。好比，要用setInterval函数实现一个计时功能，每隔一秒进行时间更新。当屏幕关闭后，计时函数就不能工做了，即关闭屏幕5秒种，你的计时器也将中止5秒。

　　若是是实现一些网页动态效果，这倒没什么影响。但若是你的计时器涉及到了业务逻辑，好比计的是一次考试的时间，那影响就大了。一个考生关闭屏幕后将可使时间静止。这是不但愿发生的。因此，若是代码中有用js进行计时，或其余需持续执行的任务。须要考虑到此问题。

　　对于计时器，咱们能够隔一段时间与服务器进行时钟同步，从而解决客户端因关闭屏幕形成的计时偏差。

　　顺便再加一句，使用ipad上的safari浏览器，在切换到别的标签页时，原标签中的线程也会被停掉，跟关闭屏幕同样的效果。

定位属性与重绘的纠葛

　　在移动设备横竖屏翻转的时候，会进行页面的重绘，ipad图像处理性能较强，问题不大，可是形形色色的android设备性能不一，一些较差的在转屏时常常会显示不出来界面，或是出现花屏。比较明显并且严重的状况是，当页面上的元素使用了position:fixed或是position:absolute时，转屏后该元素的定位将会错乱，多是转屏时页面所处的环境变更太大，渲染引擎计算的时候性能消耗太多，老是没法将这类元素正确显示出来。

　　个人处理办法是本身让webview把这个元素再重绘一下，操做元素的属性、className，或者是设置visibility都可触发重绘行为。但这种方式也不是屡屡见效，有时候也无济于事。没办法，android就是这么奇葩，太不稳定。因此实在不行我也会这么写：

$(‘html’).css(‘visibility’,’hidden’);
setTimeout(function(){
         $(‘html’).css(‘visibility’,’visible);
},100);

　　我怀疑webview的重绘是否真的进行了，因此直接让页面闪烁一下，这样效果会好不少，通常状况都能重绘正确。

　　再糟的状况，实在用HTML解决不了了，能够去找客户端的同窗，让他们操做webview，webview也能够进行重绘或者是直接reload。

不得不说的touch事件

　　在桌面浏览器上，基本的功能都是靠监听click事件来完成的，移动设备上没有鼠标指针压根就没有click这事件，不过对于这么重要的东西，引擎固然是作了相应处理。click事件在pad上能够很好的被响应。

　　但正如上面提到的，小白老是会使用一些现成的插件。。我用了一个弹出窗口插件，在桌面上能够用鼠标拖动，可是在pad上却没法拖动了。移动设备上的引擎虽然对click作了很好的处理，可是对mousedown、mousemove、mouseup却没有理会，因此须要在代码中对应的加上touchstart、touchmove、touchend事件。

　　有些现象是能够想出缘由来的，但有些现象是那种根本就不讲道理的，我这里也不知道如何描述。大概就是当touch事件和click事件同时被监听，再加上页面结构复杂等其余因素，就会出现各类抽风行为。

　　首先精简页面结构是最最重要的，没有之一。其次对于不一样设备的奇异现象，我也只能想办法进行各类hack了。

明确要支持哪些设备

　　这一点跟技术无关了，是一个决策问题。ipad不管是二、三、4仍是mini都比较稳定，兼容问题基本没有。主要是android，系统版本从2.x到4.x不等，各类牌子：三星、华硕、联想算比较主流的，其余是像昂达、酷派、粤教云。并且各品牌还有多种型号。再加上各厂家对android系统的无节操修改，浏览器内核都改。整个如今那叫一个乱啊。

　　因此在项目初期，明确要支持哪些设备是很是重要的。这样就能够针对这些设备进行兼容性的测试。而不是今天客户说要用哪一个设备，咱们就想办法兼容哪一个设备，真是会累死。还真有这样的客户，说咱们就只使用千元如下的平板，性能那真是一个蛋疼。

　　经历了一番痛苦的挣扎，秉着能解决就解决，解决不了就hack的原则，项目还真定期完成了。hack写多了真是有种犯罪感啊！如今看着项目，真的有种假如上天给我再来一次机会的呐喊，不过一切都过去了。经验教训一大把，在此挑些典型的与你们共享。可能在专作移动开发的前端眼里，这些都是小儿科，但做为一个从小白走过来的程序员，这些经验仍是至关重要。