关于移动端单页面框架的思考

可以说从12年开始,移动端单页面开发就已经被各个公司实践了,当时我的上家公司也进行了实践。和大多数的结果一样,理想很丰满,现实很骨感。主要是因为在手机端受限的东西太多:内存不够用、性能跑步起来、表现上卡以及五花八门各种各样手机上的浏览器表现差异实在是无话可说,各种bug层出不穷。时光匆匆,2年过去了,主要的两大手机系统iosandroid都已升级了多次,此时再来看,我们可以在移动端单页面方面做些什么呢?是不是相比较于以前好多了呢?

现在各个公司已没有了当年的那种对于移动端单页面的“冲动”,都是理性来做;看了一些主要的这方面的网站,可以说,都是趋向于简单,实用,没有那么多华而不实的东西了。如今手机配置已经不错了,系统对于HTML5和CSS3的支持也比较好了,那又有什么框架我们可以去选择呢?貌似也没有多少,jquerymobile, jqmobi(app framework), sencha touch, jQTouch, 国内的百度,阿里,腾讯等也有有开源自己的一些框架(或UI集成框架);当然还少不了近2年比较火的MVCMVVM类框架:backbone.js, angular.js, ‘vue.js’等等,还是比较多的。当然,zepto, fastclick, hammer, deeptissuejs 这些基础操作库,提高点击速度以及各种手势库了。

这里就遇到一个难题,我该如何选择?这么多框架(库),世上没有最好的框架,只有最合适的,假设你需要带UI框架,而且改改CSS就符合了,没问题;或者不带UI框架,也可以。但是可能对于大多数的项目而言,可能UI是设计师设计出来的,你选择UI框架可能风格不符,代价可能太大;也有可能是选择的框架太重,例如angular,在PC上都有各种性能问题,跑在移动端,可能会有更多的问题。

单页面的好处是不言而喻的,节省资源,响应更快,对用户十分好等等;但是单页面就意味着不能及时销毁释放很多东西,这回占据很多资源,慢慢的性能就不行了,当然还可以通过自己维护销毁,这样能节约部分的。所以__该刷新时就刷新__,也可以算是局部单页面,现在的主流的做法就是这样。

如果要选择去做移动端产品,感觉还是应该趋向于简单化,交互简单,去框架化,基于简单的骨架就能达到目的即可,不受限于何种渲染方式,选择何种模板引擎,选择什么CSS框架,选择什么JS库,希望可以自由搭配,哪个好就用哪个。给予这种思路,既然是单页面,那肯定少不了路由,所有需要路由系统,路由系统就需要history为基础,在history里,可以利用最新的hispory,配合后端相同路由达到目的;同时为了切换效果,还需要加上转场效果,jquery mobile这样的框架都有类似效果,一般做法都是利用CSS3来达到转场效果。之前的项目中有用到angular的路由,觉得不错,配置上路由,以及对应的模板和controller,简单实用。

基于种种思路,自己琢磨写一个骨架,名字简单M,取mobile第一个字母,使用时基本是配置其router,开始history即可。剩余的就是在配置的router中,有获取模板配置方法,也有完成显示后回调方法;同时考虑到动态性,可以设置是否缓存模板,且基于性能考虑,加入了销毁时方法,可以移除一些监听操作什么的。

项目地址:M

对应的简单的示例Demo:单页面骨架

发布于: 2014年 12月 31日