代码改变世界

谈一谈手机WebApp的fixed属性(手机上的固定栏)【转】

2013-10-30 14:59  sniper007  阅读(2588)  评论(0编辑  收藏  举报
1、iphone/android原生app常见结构
似乎,所有的手机应用,都遵循这样的布局:固定的顶部+固定的底部+可滚动在中间区域。这种“雷同”的模式让人恶心,却不得不承认这是一种很规矩却又很实用的体验,或者说已经固化成一种设计模式。这一点好比我之前提到的一篇文章《twitter UI已成习惯》http://jslover.com/?p=305 .
如 果是webapp,我们也希望这样做吗?如果是通过手机浏览器访问,由于浏览器的地址栏、状态栏等本身就占据了一定的高度,所以如果继续在内容页实现这种 上下“fixed”的设计,显然是一种累赘的设计,不过如果想做的更“像APP”,通过一些hack来全屏浏览器,然后再加上这个“fixed”的显示, 还是不错的。另外,如果是将我们的webapp打包成手机安装应用,那么这种“fixed”的设计将成为必须,否则,将“不太像”一个app.
2、通过position:fixed
在pc上,ie6以上的浏览器都是兼容这个属性的,而且ie6也有比较完美的解决方案,见《IE6中fixed抖动问题的解决》http://jslover.com/?p=66
而在手机上,情况就不容乐观了,iso5据说可以支持,没测试过,iso4是不支持这个属性的的,android2.1测试是通过的。
即使手机浏览器完全支持了这个属性,体验上还是不完美的,看下面这个截图就清楚了:
上面这个截图,顶部的导航栏是通过”position:fixed”实现固定位置,不过,可以看的出来,滚动条的区域还是针对整个页面的,在web上无所谓,在手机上,看到滚动条”爬到”导航栏上面一定很纠结吧。
3、使用iscroll
根据我们上面遇到的问题,如果不考虑性能问题,iscroll的解决方案决定是最完美的,几乎完全一致地模拟了原生app的滚动条效果.
iscroll 的实现原理也很简单,上中下三个区域都用绝对定位,header部分top:0,footer部分bottom:0,中间区域top:header的高 度,bottom:footer的高度。然后就是对中间区域进行滚动条事件的模拟。经过测试,在iso上运行顺畅,在android浏览器上存在性能问 题,偶尔会出现浏览器卡死现象。但如果通过webview打包成app,在两个平台上都表现良好,未发现卡死现象。
4、通过appcan框架
appcan 对fixed的处理,其实也不完美,首先是使用css的fixed属性。当然对于不兼容的浏览器框架中封装了一个 zy_fix(..)的function,这个还得依赖于appcan的“壳”,zy_fix对过调用框架的 uexWindow.openSlibing(..)动态生成了一个新的“webview”控件,通过“壳”级别来控制。可惜,它的处理方式还是有些令人 失望,问题和上面的第2点似乎,中间区域的滚动条是针对整个界面的,内容区域都是可能通过“margin”来控制,不过滚动条的显示就没辙了。
appcan官网:http://appcan.cn
5、自定义webview
这种当然也是只能针对打包成app的情况,需要有android/iso开发人员配合。
应用默认初始化3个webview,上面不需要滚动,中间区域可以完美实现滚动。3个webview之间要提供相互访问JS和DOM的接口,当然最好还能动态改变这些webview是否显示等。
纵合以上,如果是基于手机浏览器的在线webapp,不建议使用fixed的设计。如果一定要使用,android版使用”position:fixed”。iso使用iscroll。
如果是打包成app,性能优先,考虑使用第5种方式。开发效率优先,使用第3种方案,毕竟iscroll在android平台上(打包后的应用)效果尚可,在iso上近乎完美。