你造了什么孽弄出这么多页面Bug？由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“残疾人前世造了什么孽”。
泽思网络 – 上海APP开发商
www.daodoc.com 你造了什么孽弄出这么多页面Bug？ ——浅谈Web App开发的可用性问题
现阶段的移动端Web App还处于初级阶段，优势和缺陷都很明显，虽有众干爹打造生态圈，但相比于PC浏览器及native容器，作为Web App承载平台的移动端浏览器性能仍显疲软，同时受到碎片化严重的固件版本及处于草案的HTML5规范影响。从远景看，随着规范确定及固件版本升级，移动端浏览器在脚本解析，页面渲染及本地能力使用上的性能会大幅提升，低版本长尾用户比例趋近于零，这时的Web App形态也许会达到现有Hybrid App的水平，接近Native App。
一． 真的跨平台吗？
当众多业界高富帅专家指点华丽PPT一遍遍吹捧着使用HTML5跨平台开发Web App高效省力时，一群群苦逼工程师仍在调试各平台下满眼是坑的所谓Web App。
先看Android平台，版本碎片化到蛋碎了一地
搭载早期固件版本的Android机型如G2，G3在硬件上和现在动辄双核4G的机皇相比如同鸟枪对大炮，即使是偏后期的V2.1中也有大量的电阻屏屌丝机，硬件上的先天不足直接影响了浏览器性能。
再看作为JavaScript核心的ECMAScript在Android平台上的支持程度： ECMAScript版本升级与Android大版本升级时间点很接近，V2.1对ES5中新增方法的支持程度就不靠谱了，别忘了V2.1-update1。除了ECMAScript，在BOM，DOM能力上低版本Android同样短板，没有本地（离线）存储没有地理定位没有原生JSON没有hashchange没有history，各种没有。当Web App运行在这些低版本平台时，标志性的手触交互，页面切换效果都会大打折扣，甚至不可用。泽思网络 – 上海APP开发商
www.daodoc.com 以上是由于Android固件版本软件上以及承载平台硬件上的先天不足，会对Web App的展现效果造成影响，下面更不靠谱的来了。Android及Webkit开源的特性衍生出第三方ROM，第三方浏览器等刷机爱好者喜闻乐见的产品，但这对Web App开发者来说就是个悲剧！究竟是造了什么孽能让Android的自带浏览器带上IE8的UA，让开发者编写的滑动效果被识别为浏览器自身组件行为，让touch、scroll事件变的各种诡异！400分的浏览器有毛毛用啊！
在此诚挚的祝福众多第三方ROM，第三方浏览器，厂家定制外包合作商，没有你们，很多Web App开发者将面临失业问题。
对Android平台的总结：
固件版本碎片化严重，早期版本浏览器能力不能够承载现有Web App形态 硬件水平悬殊很大，硬件支持上的疲软也会影响到用户体验（卡，虚，闪）各固件版本的API都有所差别，较复杂的交互或功能在不同固件版本下会遇到兼容问题
第三方定制导致众多未知兼容性问题。
iOS一样不是什么好鸟，固件碎片化情况同样存在。
iOS对ES5的全面支持是在iOS4中的某个版本才完成的，低版本上也会存在不支持原生JSON这样的缺陷。水果公司的策略屏蔽了第三方浏览器修改内核的问题，但手势冲突的问题依旧存在。
对iOS平台的总结：
固件版本碎片化同样存在，现有Web App形态需要做效果或功能降级运行在早期版本。
即使是iOS依旧存在硬件差距问题，别忘了iPod Touch，电量不足的iPod Touch泽思网络 – 上海APP开发商
www.daodoc.com 在页面渲染及事件监听上会出现问题。
低版本的iOS在兼容性修复成本上甚至高于Android，3.X的事件冒泡逗你玩。所谓的跨平台开发，一劳永逸是相对的，别老拿iPhone说事，何况iPhone上的Web App也还是个半吊子。
二．你造了什么孽弄出这么多页面Bug？
且不谈大家对Web App概念的理解是什么，你的产品真的需要这些仿App风格的UI及交互吗？过类App的展现引导会起到放大核心功能的效果，但附加的页面可用性风险是否会大于App带来的收益呢？这就是不能用与好用的取舍，连可用都达不到，好用易用从何谈起。曾经纠结是否单页应用才算真正的Web App，无线搜索则是典型的不能做到单页模式，单这何尝又不是一个优点呢，可以从一个Web App迅速跳转到另一个Web App而不是依靠不靠谱 的URL Scheme.竞品调研是必要的，但尼玛别老调研完Native App再套用在Web App产品上。Web App首先仍基于浏览器，没有系统级的UI组件支持，过多的交互不仅会给来编码上的负担埋下可用性隐患，同时粗糙的仿制品每一步交互都会导致用户流失。简单快捷的交互体验及UI风格依旧是移动端的主流，用户的流量监控器不是白瞎的。
Android机型如此之多，再加上屏幕尺寸，第三方浏览器，固件版本这些维度的影响，你的测试机够用吗？无论众测内侧公测，总是有测不出的bug。面对Android众们，我们需要一种小流量线上检测机制，一个可靠的用户反馈通道。
同为开发者，一年前也做过二逼青年，一门心思写出炫闪酷的效果，结果测试时bug遍地开花。高效健壮的码才是好码，同时码只是最终解决问题的手段。帮助PM意识到需求的风险，帮助UE了解各平台上视觉及交互的实现效果，帮助QA了解可用性问题、提高测试效率，这些，在一个成功项目中的价值高于写一手好码。泽思网络 – 上海APP开发商
www.daodoc.com 从项目源头上控制住风险，在项目中暴露风险，随着项目经验的积累我们会做的更好。对于前文中一些棘手的case，真的要放弃这部分问题平台上的用户体验吗？答案当然是不！
三． 这些你做了吗？
技术层面上，确保页面可用性有如下手段： 1.JavaScript基础库
使用基础库来约束编码规范，Zepto，JqMobi都是首选的移动端轻量级基础库。风险点在于目前并没有一个能够完全支持所有高端机版本的基础库，通常是Android2.2+，iOS4.0+。
2.保证核心功能可用性
在Android机型嗅探搜索首页中外链Zepto库的加载情况，因为纯网络原因造成的外链加载失败占比达到了0.2%，同时未开启JavaScript功能的用户也占到了0.2%。上述情况下，一些Web App常用的技术手段如异步加载，手势交互的可用性几乎为零，所以在编码设计阶段就要考虑到这类极端case下的降级入口，如表单提交不依赖脚本，在JavaScript不可用时提示用户打开JavaScript功能以获得更好的体验等。
3.页面可用性检测工具
html5test，Ringmark都是市面上很好用的在线浏览器能力检测工具，可以用来在开发前评估核心功能覆盖面和实现代价，他们的价值不仅仅是为那些跑分览器打分。
前文提到，面对Android平台的多维度复杂性，需要一种小流量，线上检测页面可用性的机制。Modernizr是一种检测浏览器HTML5/CSS3支持程度的JavaScript库，利用库中检测接口，扩展数据采集及反馈功能后，配合小流量抽样可以覆盖到全用户机型。泽思网络 – 上海APP开发商
www.daodoc.com 以上两种检测方法都是通过检测客户端浏览器能力来确保页面可用性的基础服务，第二种作用尤为重要，通过类似的手段，我们已经发现了很多问题，在随后的文章中我们会陆续整理出和大家分享。
策略层面上，有以下方法： 1.服务器端适配手段
如Android 2.1以下版本，其浏览器已无法继续承载Web App的功能需求，可以通过适服务器端适配策略将这部分长尾版本降级到一个保证核心功能可用的版式，既能保证这部分用户的页面可用性，也解开了对Web App整体发展的束缚。
2.客户端容错机制
在前端可以通过API嗅探，在页面功能解耦的前提下，细颗粒度关闭不被支持的功能，保证页面其他功能可用。
3.高端机平台区分
现有主流高端机平台上的开发如无较大功能差异，Android及iOS都基于一份代码开发，测试、维护，只在局部做平台兼容。考虑到Windows Phone的市场保有量大幅增长，对Windows Phone的兼容工作也需纳入计划，是时候评估在现有版式上作兼容亦或新增版式的代价了。
Web App仍处在初级阶段，离高富帅预估的Web App爆棚期也还有一段时间，我们的确需要一个活跃的开发者社区甚至平台去孵化更多的Web App，冷静下来看清现状才能走的更踏实不是吗？共勉。
