与webview打交道中踩过的那些坑

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

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

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

webview与设备自带浏览器一样吗?

  webview会调用系统自带的浏览器内核来解析页面。这是个真命题吗?市场上的大部分平板电脑自带浏览器为webkit内核,webview使用的也是webkit内核,并且按一个应用的大小来看也不可能自己带一个内核进去。所以是调用系统自带的是没错的了。那我在一台设备上,使用浏览器打开一个页面和使用webview打开同一页面,得到的结果会是一模一样吗?当然是废话了,都说了是调用关系。

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

  有理由怀疑我的代码不符合W3C规范啥的,但业界良心,W3C规范还是不敢违反的。所以得出结论,webview与自带浏览器解析的结果并不是完全一致,不能以为页面在浏览器中正常了,在移动设备上也就正常了。

绝对要慎用的瀑布流

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

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

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

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

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

响应式布局与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无论是2、3、4还是mini都比较稳定,兼容问题基本没有。主要是android,系统版本从2.x到4.x不等,各种牌子:三星、华硕、联想算比较主流的,其他是像昂达、酷派、粤教云。而且各品牌还有多种型号。再加上各厂家对android系统的无节操修改,浏览器内核都改。整个现在那叫一个乱啊。

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

 

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

posted @ 2013-11-07 22:26  吕大豹  阅读(19727)  评论(13编辑  收藏  举报