简要的说，webview能够在移动应用中开辟出一个窗口，在里面显示html页面，css以及js代码也可以被解析执行，它使用的是我们熟悉的webkit内核。android和ios都有相应的API，所以写一份代码在多个平台运行的能力就是以webview为基础的。
在页面滚动的时候可以通过计算，动态remove节点，保证用户能看到的地方是有内容的，其他滚动卷去的部分就直接remove掉，等滚动回来的时候再加回来。这样保证页面上的节点不会太多，性能自然提升。我没有尝试这种方案，其中的注意事项也不好说。不过大牛成功了，必然是可行的。
总之得出一个结论，在移动设备上，要用瀑布流，一定要慎用，必须先有性能的解决办法。
响应式布局与viewport
也会知道在页面<head>中要添加如下内容：
<meta name="viewport" content="width=device-width,initial-scale=1.0"/>
个人觉的在页面设计的时候就应该考虑到，若要进行横竖屏翻转，页面尽量设计的精简清爽。不过话说回来，移动应用上的页面，精简是一直需要且必须的。
比较典型的一个，我们的页面中有富文本编辑器，当时选择的是国内的一款开源编辑器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写多了真是有种犯罪感啊！现在看着项目，真的有种假如上天给我再来一次机会的呐喊，不过一切都过去了。经验教训一大把，在此挑些典型的与大家共享。可能在专做移动开发的前端眼里，这些都是小儿科，但作为一个从小白走过来的程序员，这些经验还是相当重要。