智能手机之普及不用多说,手机APP渗投到各个行业:电商(淘宝、京东等)、金融(各手机行业、P2P借贷等)、医疗(智慧医疗)、交通(滴滴、Uber等)、教育(慕课网等)、餐饮(饿了吗、美团等)……反正只要是个企业,不管规模大小,都已经订制或将要订制本身的APP。这么多APP无外乎就三种模式:Native App、Web App、Hybrid App。css
Native技术主要用于提供原生支持,要作到跨平台,就须要掌握部分Android和iOS的知识,除了多线程,文件存储等基础知识,Android须要很是熟练的掌握WebView、WebSettings、WebChromeClient、WebClient四大对象。iOS须要很是熟练掌握UIWebView对象。html
Native App,原生APP,使用原生(即Android或iOS)开发的APP。html5
优势:web
1,应用的性能好,体验好,适配起来相对容易。在APP竞争如此白热化的当下,体验是决定APP“生死”的必要因素。让用户感受不爽了,只有一个下场,就是“卸载”,“卸载”,“卸载”。让APP常驻用户手机的梦想破灭。编程
2,技术成熟。浏览器
3,和原平生台API无缝对接,打造优质体验。安全
缺点:服务器
一、没法跨平台:Android和iOS都须要开发各自平台的版本——开发成本高;微信
二、升级麻烦:每次升级都要下载安装包,Android还好,反正不须要审核,下载就下载吧,但iOS就麻烦了,发布每一个版本还得通过App Store的审核,这致使第三个问题;网络
三、Android和iOS很难同步发布。
4,成本高。
二、WebApp
所谓的Web App,就是把手机当作一个浏览器(Android使用WebView,iOS使用UIWebView),作几个页面挂在服务器端,相似于一个小网站。这样说虽然不太贴切,但实际上给人的感受就是这样的。虽然开发成本大大下降,但页面访问速度慢、操做体验差。因而第三种模式诞生了。
HTML5技术的兴起给Web App注入了新的生机。
Web App具备开发成本低、周期短、使用方便、维护简单等特色。
随着HTML5被过分热炒和实际开发中遇到的性能以及体验问题,WebApp逐渐势弱。
一样,以AppStore为首的App分发平台固然是不但愿webapp破坏本身创建的生态系统的。
html5迟迟没有得不到一个公认的标准,也阻碍着webapp的发展。可是这些都不足以阻碍webapp的发展。
如今APP的数量已经达到数以百万计,实际上用户根本不须要这么多的App,不少App被用户下载后,一个月都不会被打开一次。
而webapp用户根本不须要安装,只须要打开手机浏览器,输入网址或搜索目标,点击便可到达想要的网页,基本和PC互联网的思路是一致的,这也说明百度一样在移动入口上有这很大的优点。在NativeApp上用户只有安装了App,才能浏览,而webapp是直接经过手机浏览器为入口,或者推送的信息为入口,这么看webapp在流量上是有很大的优点的。
可是目前webapp得不到很好的发展主要有如下几个方面的缘由:
一、无有效且普遍的webapp发行渠道(NativeApp有AppStore等);
二、webapp表现和体验不佳(这点算硬伤吧);
三、适配难度(一套web很难兼容全部的手机,特别是国内某些自觉得很牛B的手机,大可乐算一个吧,哈哈);
四、配套的标准还没有成熟(主要指html5吧)。
网站移动化是必然的,目前知道webapp比较好的解决方案有以下几个:
一、云适配 号称引入一段神奇的代码就能将PC网站移动化。陈本峰老师也是我学习的榜样,html5布道官。了解更多信息能够连接到http://www.yunshipei.com/
二、百度site App 网址:http://siteapp.baidu.com/
三、还知道个作微站的网站,号称把微信、微博入口都已打通,企业用户营销很好的平台:http://www.weizhan360.com/
固然有实力的公司也有许多都有本身的移动团队,从新开发一套本身的移动端网站。如:最近刚刚上市的58同城 http://m.58.com
这里说的几种解决方案,开发者也得根据本身的须要去选择,仍是拿58同城举例子,58同城不可能去云适配,原本PC端的网页就够乱了,这也和58同城分类信息特征有关系,若是云适配,在手机端得不到很好的展现,只会更加的乱了。
技术:
一、 HTML5
熟练掌握HTML5的各个标签,如何编写最优的文档结构。
二、 CSS
熟练掌握CSS2和CSS3的新特性,能按照效果图编写最高性能的样式。
使用SCSS生成CSS,将CSS可编程化。
三、 JavaScript
实现业务逻辑控制。我的理解JavaScript主要包含两大内容:DOM编程和面向对象编程。大部分JS开发人员就只掌握DOM编程,诸如document.getElementById()等,但面向对象是很重要的一个方面。
四、 性能和开发
模块化编程:编写可复用的组建;
CSS渲染:了解浏览器的CSS渲染引擎才能编写更高效率的样式;
JS解析:了解浏览器的JS解析引擎才能优化JS脚本;
HTTP协议:熟练掌握HTTP请求的各个内容;
AJAX:和服务器端的交互大都采用AJAX。
三、HybridApp
Hybrid App发展示状
目前中国70%以上的Native APP都已经混合了Web技术,例如淘宝、大众点评、58同城、去哪儿等超级App都嵌入了大量的HTML5页面,尤为是内容页面中体现。让部分功能在WebView技术基础上缩短开发周期、实现灵活业务调整。然而不少中小技术团队嵌入的Html5部分,用户体验仍是比较差、功能比较弱。让Native App开发团队开发出体验好和功能强的HTML5页面并非简单的事情。
究其缘由,Hybrid App的学习成本较高,须要同时掌握Native技术和Web技术,所以专业作Hybrid开发的程序猿并很少,学习资料天然也少,你们都是摸着石头过河,一点一点的摸索屏幕适配、UI响应速度以及如何使Native语言与Web语言在同一产品中获得很好的协调和配合。
开发一款高性能的Hybrid App,最终仍是要将两种语言化为一体,;例如APICloud的半翻译式原理,将大量网页代码在运行时翻译成可调用原生的API,如此一来既得到了Hybrid App的优点,又不会产生两种语言协调不均形成的用户体验差的问题。Deep Engine强大的混合渲染引擎提供了更完善的性能体验。聚合API中拥有众多Native语言开发的功能模块,在开发中调用Native API无疑更增长产品总体用户体验。
混合APP的将来:
移动应用的大势已来,超级App即将诞生,此时不管是Native App仍是Web App都将不能知足人们对于移动应用的需求,对于企业来讲是开发快、成本低;
对于用户来讲则是性能好、体验佳。Hybrid App的需求必然猛增,而此时咱们应考虑的是如何将原有的App快速转成Hybrid模式。
汽车有混合动力Hybrid,移动应用一样也有混合模式。Hybrid App(混合模式移动应用)兼具“Native App良好用户交互体验的优点”和“Web App跨平台开发的优点”。不少人不知道市场上一些主流移动应用都是基于Hybrid App的方式开发,好比国外有Facebook、国内有百度搜索等。但究竟什么是Hybrid App?如何定义?
咱们来拆解一下里面的含义:
一、mobile application:Hybrid App就是一个移动应用
二、both browser-supported language and computer language:同时使用网页语言与程序语言编写
三、available through application distribution platforms:经过应用商店进行分发
四、a target device:区分目标平台
五、install to run:用户须要安装使用
综合一下就是:“Hybrid App同时使用网页语言与程序语言开发,经过应用商店区分移动操做系统分发,用户须要安装使用的移动应用”。整体特性更接近Native App可是和Web App区别较大。只是由于同时使用了网页语言编码,因此开发成本和难度比Native App要小不少。所以说,Hybrid App兼具了Native App的全部优点,也兼具了Web App使用HTML5跨平台开发低成本的优点。
Hybrid App的兴起是现阶段移动互联网产业的一种偶然。移动互联网的热潮刮起后,众多公司前赴后继的进入。可是很快发现移动应用的开发人员太少,因此致使疯狂的人才争夺。市场机制下移动应用开发人才的待遇扶摇直上,最终变成众多企业没法负担养一个具有跨平台开发能力的专业移动应用开发团队。而HTML5的出现让Web App露出曙光,HTML5开发移动应用的跨平台和廉价优点让众多想进入移动互联网领域的公司开始心动。但是当下基于HTML5的Web App更是雾里看花,在用户入口习惯、分发渠道和应用体验这三个核心问题没解决以前,Web App也很可贵以爆发。正是在这样是机缘巧合下,基于HTML5低成本跨平台开发优点又兼具Native App特质的Hybrid App技术杀入混战,而且很快吸引了众人的目光。大幅的下降了移动应用的开发成本,能够经过现有应用商店模式发行,在用户桌面造成独立入口等等这些,让Hybrid App成为解决移动应用开发困境不错的选择,也成为现阶段Web App的代言人。Hybrid App像刺客同样,在Native App和Web App混战之时,偶然间的在移动应用开发领域占有了一席之地。
Hybrid App一般分为三种类型:多View混合型,单View混合型,Web主体型。
多View混合型:(目前经常使用的方法)
即Native View和Web View独立展现,交替出现。目前常见的Hybrid App是Native View与WebView交替的场景出现。这种应用混合逻辑相对简单。即在须要的时候,将WebView当成一个独立的View(Activity)运行起来,在WebView内完成相关的展现操做。这种移动应用主体一般是Native App,Web技术只是起到补充做用。
AppCan和Rexsee都属于多View混合型,它们能够在HTML5没法胜任的时候采用Native View来进行补充。这种方式虽然对HTML5作了必定性的弥补,可是一个界面中HTML5可能没法胜任的仅仅是其中一部分,却要把整个界面所有推翻,从新使用Native来实现,对于开发成本是极高的,因此实际使用中,不少开发者可能由于各类因素,特别是成本上的考虑会对HTML5的弊端进行妥协。这形成多View的混合型框架在实际应用中跟Web主体型并没有太大的差别。这也是为何有的开发者愿意选择其余框架而不选择多View混合型框架的缘由,它的Native View有如鸡肋般的存在,让开发者无能为力。
集成难度小。开发难度和Native App基本至关。
表明APP产品:支付宝,陆金所,搜易贷,,
单View混合型:(体验与原始至关 )
即在同一个View内,同时包括Native View和Web View。互相之间是覆盖(层叠)的关系。这种Hybrid App的开发成本较高,开发难度较大,可是体验较好。如百度搜索为表明的单View混合型移动应用,既能够实现充分的灵活性,又能实现较好的用户体验。
表明APP产品:手机百度
Web主体型:(体验较差)
即移动应用的主体是Web View,主要以网页语言编写,穿插Native功能的Hybrid App开发类型。这种类型开发的移动应用体验相对而言存在缺陷,但总体开发难度大幅下降,而且基本能够实现跨平台。
Web主体型的移动应用用户体验的好坏,主要取决于底层中间件的交互与跨平台的能力。
这种方式因为太过偏重于HTML5,用户体验性相对比较差,甚至会受困于浏览器之争。
从分析可见,Hybrid App中的Web主体型只要可以解决用户体验差的问题,就能够变成最佳Hybrid App解决方案类型。AppCan在技术架构上和PhoneGap相似是Web主体型中间件,可是经过结合了一些原生交互效果可以达到iOS、Android平台都比较一致的用户体验。此外,AppCan对引擎进行了独特处理,在分辨率及移动端的适配上更加出色。也有一些厂商,采用翻译的方式,将HTML标签解析成Native进行展现,彻底受限于自身的解析能力,损失了HTML5技术的最大优点:灵活,在其基础上开发的App在基因上就带着适配性能差的硬伤。
AppCan的技术彻底可以匹配政府及500强企业的需求,目前包括东方航空、国家电网等大企业都在使用AppCan的技术完成移动信息化的解决方案。投入标杆技术的建设证实,AppCan能够完成跨行业、跨领域的解决方案,那么开发者一样能够利用AppCan技术,实现移动创业并得到收入。
而与单纯提供移动开发能力的厂商相比,AppCan在应用管理及服务上也颇为用心,已经打造出涵盖开发工具、应用创新、技术培训、运营推广四大环节的AppCan.cn一站式移动开发服务平台。移动互联网的红利近在眼前,创业机会转瞬即逝,开发者惟有谨慎选择适合本身的技术、平台,才有望在激烈的竞争中崭露头角。
国外的appMobi、PhoneGap国内的AppCan和Rexsee都属于Web主体型移动应用中间件。其中Rexsee不支持跨平台开发。appMobi和PhoneGap除基础的底层能力更可能是经过插件(Plugins)扩展的机制实现Hybrid。而AppCan除了插件机制,还提供了大量的单View混合型的接口来完善和弥补Web主体型Hybrid App体验差的问题,接近Native App的体验。
表明APP产品:平安银行APP。
多View混合型,单View混合型,Web主体型优劣势对比
多View混合型 |
单View混合型 |
Web主体型 |
|
常见主体 |
Native |
Native |
Web |
开发成本 |
中 |
高 |
低 |
用户体验 |
良 |
优 |
差 |
从分析可见,Hybrid App中的Web主体型只要可以解决用户体验差的问题,就能够变成最佳Hybrid App解决方案类型。
国内外Hybrid App的开发框架众多。如何选择又成为一个难题。下面对开发者比较关心的集中知名跨平台开发移动应用中间件进行列表和对比,以便选择最适合您的移动应用中间件。
PhoneGap是相对比较早进入公众视线的一种选择。可是,开发者简单的基于PhoneGap来开发移动应用确定会发现结果和Web App比较差的用户体验相似。这也是为何基于PhoneGap有实用性的移动应用主要集中在iOS上。但是PhoneGap这种现状弱化了HTML5的跨平台价值。
AppCan在技术架构上和PhoneGap相似是Web主体型中间件,可是经过结合了一些原生交互效果可以达到iOS、Android平台都比较一致的用户体验。可是相比PhoneGap的开源,AppCan相对封闭的路线显得过于谨慎。
Titanium是一种基于翻译机制的跨平台中间件,可以开发出具备Native体验的移动应用,可是由于翻译机制的限制致使移动应用开发不能像真正的HTML5开发同样灵活。哪怕一个按钮也不能像普通HTML同样来编写,而必须按照Titanium约定的特定格式。
Hybrid App这个领域虽然还处于比较初期的阶段,可是已经有不少优秀的公司和技术团队在致力于跨平台开发移动应用中间件技术的研究,给了开发者众多选择。开发者能够根据实际的项目需求来选择中间件。Web App虽被浏览器厂商和搜索引擎公司所推崇,但存在用户体验差、盈利模式不明确等现阶段没法解决的问题,或最终夭折。Hybrid App正在被愈来愈多的公司和开发者所认同,势必会成为新世界的王。
一些混合框架:
Cordova/PhoneGap:侧重于JS与原生的交互,开发简单,但性能差,如触摸时反应不灵敏。
AppCan:性能还行,使用简单,但要提交代码给AppCan的服务器才能打包,相信有追求的企业是不会把本身的代码提交给第三方,把打包权利交给第三方的。
Ionic Framework:在Cordova的基础上增长一些UI/JS方面的东西,样式还不错,但一样具备Cordova的不足。
MUI:缺点是工程大了,反应就迟钝了,不能和原生API很好的契合。资料少。出了bug都不知道去哪里找解决方法。
js UI 框架
jQuery Mobile:上手简单,组件丰富,但性能超级差,闪屏现象严重。
Senche Touch:简单看过,没有使用过,貌似UI很漂亮,学习成本高。
React Native:FB推出的,当年FB是最先尝试Hybrid的,但性能超差,因而APP放弃了Hybrid,走原生的道路。在你们都不看好H5时,FB暗中深刻挖掘H5,三年以后推出了这个框架,很是推荐各位去学习其中的思想。
GMU:百度推出的,这个不错。
js库:
这个就多了,jQuery、Zepto、Swiper、iScroll、RequireJS、AngularJS……
Hybrid App,这种既有跨平台开发周期短、成本低的基因,又能发挥Native App体验和性能的优点,HybridApp混合式移动应用开发逐渐成为企业移动开发的首选。
Hybrid App一般是基于第三方跨平台移动应用引擎框架进行开发,在国内开发者中比较知名的有PhoneGap、Titanium和AppCan这些引擎框架通常使用HTML5和Javascript做为编程语言,调用引擎封装的底层功能如照相机、传感器、通信录、二维码等。
HTML5和Javascript只是做为一种解析语言,真正调用的都是NativeApp同样封装的底层功能,这是和Web App的最大区别和不一样。由于使用了浏览器技术,因此Hybrid App一般具备跨平台的特性,而且开发成本和WebApp接近,开发效率也远高于Native App。
说实在的,从表面上看的话,很难区分一个App究竟是Native App仍是Hybrid App,但实际上咱们更多的是把Hybrid App当作是Webapp的一部分,由于他是一部分Native(比较少),绝大部分的web页面(html5页面)。经过手机抓包工具Fiddler是能够区分一个App究竟是Native App仍是Hybrid App的。Hybrid App和Native App同样都是须要用户在各类App分发渠道上下载并安装到手机上才能用的。Hybrid App的体验固然是没话说,比较棒的,有这Native App的所有优势。html5很好的解决了跨平台性的问题,也解决了开发成本太高的问题。网上有估计到2016年50%+的App将是Hybrid App。譬如如今也有许多很少的表明做,如:fb、掌上百度、以及刚上市的58客户端。
One Web more native 能够很好的形容Hybrid App这种开发模式。
做为一个有着1年多Hybrid App开发经验的屌丝攻城师来讲,在这里想给Hybrid App这种开发模式泼一泼冷水,说一说开发过程当中他的不足之处吧。
首先,一套web兼容n个Native是一件很难的事情,尤为是对一些App更新特别频繁的公司来讲,更是苦难。Hybrid App中的js、css等静态资源的管理就是一个很头疼的问题。譬如咱们1.0版本后,1.1版本html页面有修改变更,js、css资源文件就会有变更,那么咱们的这些资源就得兼容之前的版本,那之前的版本要不要去加载最新版本的资源文件呢?是采用同步加载仍是异步加载呢?资源加载的过程当中若是加载的资源有一部分失败了呢?老版本的包升级更新到新版本资源下载原子性的问题?像这种静态资源文件需不须要内置到客户端里面呢?
固然Hybrid App做为一个新型的开发模式,谁也不能保证一开始就想清楚全部的事情,任何新兴事物都得在发展过程当中,才能逐渐看清楚将来。
若是做为是彻底新开发Hybrid App,关于资源问题可采用以下方案:首先,静态资源必须内置到客户端里面,包括一些重要的静态页面。这样能提升App的流畅性,在如今国内移动网络这么差的状况下,让用户去下载几十K的资源简直是灾难性的。资源都配置一个版本号,资源更新采用同步加载和异步加载并行,对于一些不影响用户功能使用的资源采用异步加载的方式实现,第一次进入页面的时候仍是使用老的资源,异步去加载资源,若是资源加载完成,第二次进入的时候就使用新的资源文件。若是缺乏了这个资源,功能有问题,或者样式有问题,那这些资源就要同步加载,同步加载能够放在启动客户端后加载或者加载进入页面时同步加载。还一个比较难的问题是老版本包资源更新的时候更新资源的原子性,若是某些资源加载失败了,要怎么处理?个人想法是只有资源彻底加载成功后才将本地的版本号修改,标记为成功,那些失败的资源在进入引入改资源的页面或者启动客户端的时候会被再次的加载。
乍一看和Web App没啥差异,但涉及到的技术成本、开发成本、学习成本比Web App高,它综合了Web App的开发速度和Native App的高性能体验。之因此说学习成本高,是由于开发高性能的Hybrid App有难度,网络资料少。我是两年半前开始接触混合模式开发的,当时如何作好屏幕适配、提升UI响应速度、如何最大化使用原生功能等内容,网络几乎没有资料。网上能搜索到的都是很粗略的东西,或者就是Hello World级别的东西,涉及到稍微细节一点的东西几乎没有。因为本系列文章都只讲Hybrid,故在此再也不啰嗦了。
三种开发模式各自的特色以下面的表格所示:
|
Native App |
Hybrid App |
Web App |
原生功能体验 |
优秀 |
接近优秀 |
差 |
性能 |
很是快 |
快 |
慢 |
跨平台开发成本 |
昂贵 |
合理 |
便宜 |
碎片化适配 |
很是严重 |
严重 |
严重 |
编程技术支持 |
短缺 |
很是短缺 |
通用人才 |
版本升级维护 |
保守 |
低延时 |
开放 |
安全 |
强 |
中 |
弱
|
因为移动端是一个重视性能和用户体验的终端,大量采用框架存在一些问题:
一、 扩展、维护、定制成本,这个很是须要考虑,或许框架提供的UI风格和本身设计的UI风格差别大,致使设计围绕框架转,不符合产品的需求。
二、 既然是框架,强调的是覆盖面广度和功能的全面,会有不少无用的东西,带来累赘;
三、 框架自己存在BUG,或许须要开发人员面对一些能力以外的问题。
总之,若是只追求像山寨做坊同样快速产出、不计性能的开发产品,那使用现成的框架是不二选择。但若是追求性能和真正的产品,建议使用库,不要使用框架。可是不少框架的实现思想都很优秀,虽然不建议使用,但咱们应该多接触学习其中的思想,才能写更好的代码。仅仅建议而已,不中听请忽略。
总结:
笔者认为,真正的Hybrid App框架并不局限于PhoneGap、Appcan这样的传统开发框架那么简单,它既不是在HTML5的外表下套个壳,也不是HTML5和Native的各自为政。
作为一种开发模式,Hybrid App框架技术也在不断变革,就像烽火星空的ExMobi那样具有强大的Native布局能力和HTML5的灵活展示能力,可以让Native和HTML5能够友好共存,并以标签化的方式更方便开发者的随意调用和扩展。选择具备强大技术实力的Hybrid App框架对开发者提供的不只仅是便捷,而是一种先进的开发模式和思惟方式。
并且,在很多CIO看来,Hybrid App框架不只仅是提供开发上的能力,它只是总体的企业移动战略中的一部分,应用的管理、设备的管理、应用不一样层面的安全须要以及灵活的部署模式也都是企业移动战略中的核心部分,若是开发者所有本身实现将是很大的工做量,因此选择一个平台型的Hybrid App框架是颇有必要的。烽火星空的ExMobi就是这样的一个基于Hybrid App的移动应用平台,它从开发(IDE环境)、集成(IT系统对接、云服务)、打包(各个操做系统的应用打包)、发布(应用的运行)、管理(日志管理,更新管理)上提供了一套完整的移动化应用解决方案。因此,建议开发者根据本身的实际状况,选择合适的Hybrid App框架。