Hybrid框架UI重构之路:1、师其长技以自强

这两年在支撑公司的Hybrid框架的运维发展,让人确认这种移动开发方式确实是一条不错的路。混合应用这种开发方式下降开发难度,极大的提升开发效率,最重要的一点效果能够接近原生应用。框架的自己是须要持续不断发展的,这里开始我讲述我重构Hybird框架的UI的这三个月(2014-11——2015-1),而在重构以前,预先调查了目前所了解的几个混合应用的框架,师其长技以自强。css

PS:Hybrid应用是web页面与原生壳(Android、IOS)的结合最后打成安装包的应用。
 
重构的前奏曲:
ApiCloud

这个移动端混合应用框架产品我是最熟悉的,为了理解深刻理解还作了一个示例应用。apiCloud的开发环境仍是不错的,有自定义的IDE,但没有模板工程,同时也有svn控制项目,与其Web站点相同步。而他将他的api分为“云”端api,“终”端api。他的原生的壳作得很是好,插件分模块(可选),且支持用户自定义原生插件,但我对他的UI控件、组件的实现方式不是那么赞同。由于这次我是针对自身Hybrid框架的UI部分进入重构的,因此我更关注的是这方面的东西。html

apicloud的控件是绝大部分原生实现的,没错,是原生显示的,不管是菜单、列表仍是页面效果,都是原生实现的。不是说原生实现的很差,相反,原生实现的控件的兼容性更好,更流畅,也有更好的体验。但问题来了,原生实现的控件是固定的,除了提供出来的接口去设置控件的样式、状态,没有其余办法修改,这就致使一个问题,如今互联网的应用的需求变幻无穷,可能在使用控件时候须要作一些小调整(加一行日期或说明什么的),但原生没法改变,动都动不了。前端

我曾经咨询过apicloud这种问题怎么解决,他们告诉的解决办法是本身能够写web前端代码实现(没法改原生提供的),但我想说的是,用户都是很“傻”的,若是你提供了东西,他们就会想去用,一旦用不了要本身实现就会很烦。因此我想说,原生实现的固定性致使即便有原生以前提到的优势,我UI部分的控件我也不想用原生实现,web实现更适合微调和自定义(作过框架运维的我深入体会,到,UI的可微调是很重要的)。而UI控件原生实现有另一个问题,就是定位的问题,是绝对定位,使用控件时候须要设置x、y轴,这会出现——例如页面有三个块A、B、C,A、C是使用原生实现的控件,B是本身的HTML块,那问题来了,C须要设置x、y的值,当B是动态高度怎么办(我到如今也没搞明白怎么弄,我以为终端仍是要本身实现C)。web

apicloud因为控件都是原生实现的,他就干脆连UI使用什么依赖库都不建议。官方是说用户能够本身使用任意的前端框架,看似是为了放大自由度,但我以为是在减轻产品UI部分的负担,不提供、不建议UI使用的css、js,产品的运维成本将会大大下降(我如今运维的框架80%都是UI的问题),这点不得不说是apicloud的聪明之处。api

Appcan

Appcan是我最喜欢的Hybrid框架,最近还开源了。不管是开发环境,仍是框架自己,在我看来是最符合用户需求的。特别是提供了四种示例模板,新闻、OA、阅读、电商,新闻是最有表明性的,以外还有众多的示例页面。固然控件是由web实现的,虽然样式的命名实在是看不懂,但贵在可微调。前端框架

在这里必须讲一下appcan、apicloud共有的优势,也是一个重要的特色,就是页面加载速度很是快。这点其实很是重要。服务器

例若有A、B两个页面,A切换到B,正常的切换是直接切整一个B的页面,header、content、footer以及全部依赖的文件,而appcan实际上是将页面分为两个部分,header、footer和 content,当A切换到B时,先加载header、footer部分并切换页面,页面切换完后再加载content部分。这样作会给用户一个假象,就是B页面加载速度很快,尽管B页面真正加载还须要一段时间(等待content完成)。app

对于appcan的原生,我也不甚了解,就很少说。框架

Exmobi

这个框架是另一个同事去探究的,我关注的是他的UI部分,但并无多大的惊喜,他是参照某个移动端框架(Jingle)作的,虽然是示例工程改头换面了一下,但抄的影子仍是太深了。而在这里也是提醒个人一点,好的东西能够抄(抄是没有问题的,别人实现了,你为何还要实现一次,浪费时间),但必须符合本身的需求,别让本身的思路被引导了。运维

Jingle

这是国内一个前端人员作的UI框架,仅有UI部分,对于这个框架我有仔细研究,甚至还通读了源码。其代码结构、模块划分、控件的写法都是比较完善的,学习他的框架学到的东西更超出了UI框架自己。他提供的UI的东西并不复杂,相比appcan是一种精简版。而里面最重要的一点是单页模式。在这里简单说说单页模式是什么。

单页模式

单页模式(Single-Page Application)即在一个HTML5移动应用中只包含一个HTML页面,而不一样视图的显示实际是在一个页面中采用动态显隐实现,而其中最重要的技术的就是Ajax,不一样视图的获取都是经过Ajax从本地或远程服务器中获取。

也就是说,不一样的视图都是一个HTML片断,而不是完整的HTML页面。

在 SPA 模式中,主页面(完整HTML页面)是能够独立加载、更新和替换的一些可视元素的组合(HTML片断)。经过这种方式,能够没必要在每次用户操做后从新加载整个页面。在任什么时候候,都只显示与应用程序当前阶段相关的可视元素和内容。其余全部内容均被隐藏;但只要应用程序流程中须要用到它,它就会显示出来。

优势
1.共用的依赖库没必要重复加载,只需在主页面加载一次,其余(HTML片断)不须要,这也间接提高页面加载速度。
2.使用CSS3作页面之间的切换,速度比原生切换webview快不少。
 
缺点
1.由于全部的HTML最终都是加载在主页面,因此可能存在js、css命名冲突。(因此JS和CSS的命名都须要进行有效管理,这一点须要时刻注意)
2.单页模式会使一个界面不断加载新的元素而致使界面逻辑复杂和页面膨胀
3.其实有一个很严重的一点,就是内存泄露的问题。
 
多页模式

多页模式(Multi-page Application)是相对于单页模式而言,应用中的每个页面都是一个独立HTML页面,而不是HTML片断。

缺点
1.每一个页面可能都会重复加载一些数据(JS、CSS、部分HTML代码等)
2.页面切换速度慢
 
总结

不一样的框架,有不一样的优势,在这里找到了几点可用于自身的东西,也是但愿能加强自身。

 

本文为原创文章,转载请保留原出处,方便溯源,若有错误地方,谢谢指正。