无线web开发经验（1）—— 概述
无线Web开发简介
无线Web开发是基于智能手机上的游览器进行的Web开发。现在智能手机主要有Android和IOS两种操作系统的，因此基于手机Web的开发，主要是基于Android和IOS两种操作系统上的web开发。
基于两种操作系统的Web开发的共同点：
- 两者的浏览器引擎是基于webkit的，因此基于手机上的Web开发，主要是基于webkit的游览器开发，对于其他浏览器，例如firefox、ie和opera等游览器，可以不用做兼容考虑。
- 两者都是按照HTML5规范开发，因此对于HTML5的特性支持性都比较好。
不同点：
- android的厂商碎片化比较严重，加上由于webkit的开源特性，导致市面上有非常多的修改版webkit游览器， 这些修改版的webkit，厂商会根据自己的需求对webkit进行修改，导致对HTML5的特性碎片化严重。 同时HTML5标准不同厂商的实现不同，造成对于HTML5特性的支持度不同。 以input type=date 日期控件为例，有些厂商实现了该标准，有些厂商没有实现该标准，就算实现了标准的厂商， 对于日期控件的展现、交互也不尽相同。
- android的版本碎片化。
- ios由于其封闭性，并且苹果公司严格按照html5的规范来进行实现，因此在ios上html5的规范实现的较好。
- ios和android对于html5的规范实现在界面层和交互层的实现是不同的，就拿上面的列子来说 type date的日期控件，ios和android的交互实现，完全不同。虽然都按照w3c的标准进行了实现。这个也是在日常web开发中需要注意的。
手机性能
智能手机，其硬件发展的非常迅速，不过无论其硬件发展多块，由于手机的特点，性能和功能是一个平衡点。因为谁也不会用一个性能超好，但是手机非常烫并且只能用1个小时的机器。因此在很多方面，手机上的性能是受到一定限制。web这块受这个影响叫native的方面要大很多。因此web这块不是编译型语言，只能动态在手机上运行，再加之webkit核心所占的内存较大，是单进程单线程应用，其受CPU、内存的影响更大。
页面渲染
手机Web开发在性能上影响较大的是页面渲染问题，而js脚本性能问题不再突出，这个主要归功于在android上使用了v8引擎，大大提升了脚本的执行性能。这个和PC上的情况完全不同，因为在PC上，由于其高性能的硬件，加上强劲的显卡，使得页面渲染的性能非常之高。而在手机上完全不同，有限的硬件性能，加上没有显卡这类专门处理显示的硬件，使得所有页面渲染的工作都由CPU来执行。加上CPU本身的执行频率有限，就会造成页面渲染缓慢。因此在手机上，会发现当页面出现大量的渲染变化的时候，会出现卡顿现象。比如长列表滑动，页面切换动画等等。这些条件都限制了HTML5的功能发挥，因此在涉及到动态变化的时候，更加需要小心处理。
键盘
键盘也是和PC不同之处，在刚刚做手机Web开发的时候，会经常忘记的。由于现在的手机使用了软键盘，因此软键盘在某些时候，会成为页面的一部分。键盘是一个非常特别的设备，说特别是因为，不同的手机对于键盘对于html页面的布局的实现不同。下面通过以下几个方面，阐述手机键盘的特点：
-
键盘的布局 由于手机界面非常小，因此键盘会占住手机屏幕的一大部分，对于键盘对html的页面布局影响，如果从来没有做过的人，也许不会注意到，android和ios的处理方式，android中各个厂商处理的方式又有所不同。ios对于从下方推出键盘的时候，如果输入控件在页面推出之后，在键盘的高度的上方的话，则键盘是以一个浮层的方式弹出，并且将那个触发的控件推到键盘的上方。如果那个控件在页面底部，如果推出的键盘会覆盖该控件，系统会将整个页面向上推，直到将那个控件推到键盘上方为止。而android的实现的不同，有部分的android的实现和ios一样，有些android的机型的实现却不同，如果发现触发的input控件比键盘的高度底的时候，会自动将整个document的高度增加，增加到这个控件的高度超过键盘的高度为止。由于实现的不同，会造成以下两个问题，
-
对于某些js模拟弹窗类型，会造成定位问题。一个比较经典的案例，就是toast的提示，toast会出现在手机靠底部的位置，通常使用的是fixed的属性，如果按照ios的方式，将整个文档往上推，则不会出现问题，不过如果是将整个document动态增高，就会出现toast出现在键盘的下面，位置不好的话，会正好出现在键盘的中间，由于键盘是在整个浏览器的上层，因此通过z-index的方式是无法将定位的元素覆盖在键盘之上的。解决方案是出现toast的时候，监听所有控件的事件，出现focus的时候，动态计算当前的位置，重新设置。
-
如果触发的input在过于复杂的布局中，某些android机在计算input的实际位置的时候，会出现计算错误，特别是通过css设置过trasnlate等高级特性的时候，曾经碰到一个机器，由于计算的错误，键盘弹起的时候，没有将input框拉伸到键盘的上方，完全被键盘盖住，造成输入问题。因此，由于各种比较龊的android的手机存在的时候，input竟可能不要嵌入过于复杂的层次中，加上比较复杂的css的位置属性，以免造成计算错误。
-
键盘的类型 在手机上有各种键盘类型，比较常用的键盘有全键盘，数字键盘，符号键盘，email键盘，搜索键盘，金额键盘，电话键盘等。不过由于web的限制，能真正使用的可以说非常的有限，并且在ios和android上的实现不同。而且弹出的键盘类型也不尽相同。总结一句话，键盘的弹起，完全依赖系统和厂商的实现。键盘的类型是无法定制的。
-
键盘的事件 弹起和收起键盘。这个也是非常纠结的问题。在ios6之前，当控件获得focus的时候，如果不是用户触发的事件，键盘是不会弹起的，在ios6之后，设置了一个属性可以做到，在android上，只要不是用户触发的事件都无法触发。暂时还没有解决方案。键盘的收起，可以通过js的blur的方式来实现。
页面滚动
页面滚动是非常常用的功能，不过在原生手机上，无法支持局部滚动的，不过ios5之后，出现了一个支持局部滚动的CSS属性，-webkit-overflow-scrolling: touch的属性，不过里面有一定的缺陷，在某些滚动中，会失效，因此建议不使用。
就页面需要说一个非常的规则，因为这个会直接影响web的开发。就是在页面进行惯性滑动的时候（手指松开的滑动），处于性能的考虑，浏览器是会把页面上的渲染进行锁定的状态。也就说，当页面进行滑动的时候，js动态修改上面的元素是无效的。直到页面滚动停止，这是个非常特殊的规则。在IOS和android上都会存在，在ios上显得突出。在日常评估的时候，一定需要这个特性，这个特性决定了某些滑动中的功能是无法实现的，比如说某个元素到某个位置从static编程fixed的状态，或者进行状态转换。在滑动的时候，即使js动态设置了，页面也不会响应，直到滚动结束。因此在native中很多触摸控制的效果，在web上却无法完美实现。
附注：对于ios的滚动的系统细节实现可以参考此地址:http://www.iunbug.com/archives/2012/09/19/411.html
页面滚动有个其他的问题，就是在ios的系统里，就算网页头了，还能继续往上面拉，有一个力反馈的效果，并且这个效果是无法取消的，看上去很酷和很美。但是在实际项目中，几乎是用不到这个看上去很美的效果，反而会造成很奇怪的感觉，特别是做成webapp的时候，一个完整的界面有导航头的时候，还能在往上拉动，极其诡异的感觉对于用户而言。并且这个滚动是系统实现的，没有方法去除，因此判断一个app是web还是native的，就可以通过这种方式来判断，拉到顶，再往上拉，如果能网上拉，并且出现的不是上拉刷新，而是一个ios的默认背景，则就是web了，不过反之不一定是native，因为web可以直接禁用滚动，通过css3或js来实现模拟滚动，不过这类滚动会造成很严重的性能问题，特别是对整个长页面的滚动。
