前端最常用的移动App开发方式及技术栈详解
前端最常用的移动App开发方式及技术栈详解混合App相关技术共同点:把网页打包成移动 App,使 Web 程序可以访问手机原生能力。CordovaCordova 是Apache软件基金会的一个产品。其前身是PhoneGap,由Nitobi开发,2011年10月,Adobe收购了Nitobi,并且PhoneGap项目也被贡献给Apache软件基金会。Apache在2012年12月,发布了Cordov
前端最常用的移动App开发方式及技术栈详解
混合App相关技术
共同点:
- 把网页打包成移动 App,使 Web 程序可以访问手机原生能力。
Cordova
Cordova 是Apache软件基金会的一个产品。其前身是PhoneGap,由Nitobi开发,2011年10月,Adobe收购了Nitobi,并且PhoneGap项目也被贡献给Apache软件基金会。Apache在2012年12月,发布了Cordova,截止到2015年12月,最新版面是3.0。
该框架的目标用户群体是原生开发者,其设计初衷是希望用户群体能够通过跨平台开发的方法降低原生开发的成本。为此,开发人员需要安装原生开发环境,配置工程,使用HTML5、CSS3、JS和原生SDK生成应用。
优点
:
Cordova的优势很明显,可以使用的框架、原生接口、支持平台都很多。
缺点
:
- 外国人写的东西,公司使用后,出现的技术问题难以解决。同时,
- 在使用 jQuery Mobile、Sencha Touch等前端框架的时候,特效启动慢、页面切换慢、数据请求慢。
APPCan
APPCan 成立于2010年,2011年推出产品并测试,2012年正式推出品牌,2013年商业模式成型,2014年开发者注册约70w。AppCan不是开源平台,同时,企业版和部分插件是收费的。换句话说,AppCan只是一个卖软件的商业公司。我们认为:这会对其市场的占有率有着直接影响,闭源而没有垄断,所以前景不会太好。
DCloud
DCloud 大部分产品开源,W3C会员单位,HTML5中国产业联盟的发起公司之一,在HTML5这个行业有一定的江湖地位。旗下四款产品:HBuilder、5+ Runtime、MUI、流应用都是弥补并扩展HTML5特性的产品。该公司的理念就是解决HTML5的性能、工具、能力三方面的问题。
MUI是一款不错的前端框架,性能比 jQuery Mobile、Bootstrap好很多,主要区别:
- 设计思路不同,MUI坚持用原生JS做,不依赖jQuery或者Angularjs。
- MUI调用了5+ Runtime的底层原生加速,比不带原生加速的框架更快。
缺点
:
DCloud毕竟是个新平台,发展才2年,新产品内部存在的Bug还需要很多的测试。在其官方社区中,不少开发者也在呼吁DCloud尽快完善文档和框架。
API Cloud
API Cloud 提供原生应用的功能模块(设备访问,界面布局,开放SDK等),开发者可以通过JS调用。前端工程师负责页面布局,UI展现,及简单的交互,原生模块负责性能方面和功能实现,两者结合形成一个完整的应用。同时APICloud提供了云数据库的功能,前端不必了解PHP,Node.js等后端语言,通过JS接口或Restful API实现数据库的增删改查。
缺点
:
APICloud的更新速度很快,版本不太稳定。而且,它是为不懂APP开发的人士准备的,不适合科技公司和程序员。
混合开发四种方式对比
cordova | appcan | DCloud | APICloud | |
---|---|---|---|---|
目标 | 为原生开发者解决平台差异性问题 | 提供跨平台移动应用快速开发一体化解决方案 | 解决HTML5的工具,性能,能力三个重要问题 | 重新定义移动应用开发。提供云/端两项服务 |
功能 | 简单 | 丰富 | 丰富 | 丰富 |
支持平台 | 大部分平台 | ios/andriod | ios/andriod | ios/andriod |
开发环境 | 不同平台需要不同环境 | EClipse | HBuilder | sublime/eclipse/webstorm |
开发语言 | html5/css3/js | html5/css3/js | html5/css3/js | html5/css3/js |
UI框架 | 第三方 | 第三方 | mui/第三方 | 自带 |
打包方式 | 离线 | 在线 | 在线/离线 | 在线 |
优点 | 跨平台、框架多,插件多,发展早,社区资源多 | 做了性能优化,app比较流畅 | 对html5的性能,工具,能力都做了相关的产品 | 即使不懂原生开发,不懂后台语言,也可以完成APP |
缺点 | 在webview性能低下的情况下,使用第三方UI框架,用户体验会变差 | 闭源收费,过多封装,自由度不足 | 新产品,还需改进。需要具备原生开发的经验 | 版本更新过快,不稳定,外包公司过度依赖,会降低技术实力 |
跨平台开发
用一种语言写一套代码,在ios,andriod上都可以运行。
特点
:
使用类似于 Web 技术的方式来开发 Native App。
优点
:
效率体验接近Native App,发布和开发成本低于Native App
-
开发成本大于Hybrid模式,小于原生模式,大部分代码可复用
相比于原生模式,这种模式是统一用JS写代码,所以往往只需要一名成员投入学习,即可完成跨平台app的开发,而且后续代码封装的好,很多功能可复用。
-
性能体验高于Hybrid,不逊色与原生
这种模式和Hybrid不一样,Hybrid中的view层实际上还是dom,但是这种模式的view层是虚拟dom,所以性能要高于Hybrid,距离原生差距不大。
这种模式可以认为是用JS写原生,即页面用JS写,然后原生通过Bridge技术分析JS,将JS内容单独渲染成原生Android和iOS,所以也就是为什么性能不逊色原生。
-
开发人员单一技术栈,一次学习,跨平台开发
这种模式是统一由JS编写,有着独特的语法,所以只需要学习一次,即可同时开发Android和iOS。
-
社区繁荣,遇到问题容易解决
这应该是React Native的很大一个优势,不像Hybrid模式和原生模式一样各自为营,这种模式是Facebook统一发起的,所以有一个统一的社区,里面有大量资源和活跃的人员,对开发者很友好。
缺点
:
学习有一定成本,且文档较少,免不了踩坑
-
虽然可以部分跨平台,但并不是Hybrid中的一次编写,两次运行那种,而是不同平台代码有所区别
这种模式实际上还是JS来写原生,所以Android和iOS中的原生代码会有所区别,如果需要跨平台,对开发人员有一定要求。
当然了,如果发展了有一定时间,组件库够丰富了,那么其实影响也就不大了,甚至会比Hybrid更快
-
开发人员学习有一定成本
虽然社区已经比较成熟了,但是一个新的普通前端学习起来还是有一定学习成本的,无法像Hybrid模式一样平滑
-
学习成本大,对开发人员技术要求比较高
-
不懂原生开发很难驾驭好
-
说是使用 Web 技术进行开发,还是多少得学点儿原生 App 开发,才能处理好跨平台。
-
前期投入比较大,后劲很足。
React Native
- 公司:Facebook
- 技术栈:React
- 开源的一套新的App开发方案React Native。使用JSX语言写原生界面,js通过JSBridge调用原生API渲染UI交互通信。
- React-Native 就是用js的方式 去开发 原生应用, 一套代码生成 安卓,ios应用。
Weex
-
公司:Apache 开源基金会
-
Weex 致力于使开发者能基于通用跨平台的 Web开发语言和开发经验,来构建 Android、iOS 和 Web 应用。简单来说,在集成了 WeexSDK 之后,你可以使用 JavaScript 语言和前端开发经验来开发移动应用。
-
Weex的定位则是替代h5使用场景,在保证动态性的情况下,提升性能,开发者大多为前端工程师。
Flutter
- 公司:Google
- 它提供了官方的原生 UI 组件
- 比 RN、Weex 之类的体验更好
- 开发语言:Dart
- 商业应用:闲鱼
- 跨平台原理:高性能渲染引擎来绘制widget。
多端开发
taro
taro是一套遵循 React 语法规范的 多端开发 解决方案。使用 Taro,开发者可以只书写一套代码,再通过 Taro 的编译工具,将源代码分别编译出可以在不同端(微信/百度/支付宝/字节跳动/QQ/京东小程序、快应用、H5、React-Native 等)运行的代码。
uni-app
uni-app 是一个使用 Vue.js 开发所有前端应用的框架,开发者编写一套代码,可发布到iOS、Android、H5、以及各种小程序(微信/支付宝/百度/头条/QQ/钉钉)等多个平台。
开发方式小结
对比
Native App | Web App | Hybrid App | React Native App | |
---|---|---|---|---|
原生功能体验 | 优秀 | 差 | 良好 | 接近优秀 |
渲染性能 | 非常快 | 慢 | 接近快 | 快 |
是否支持设备底层访问 | 支持 | 不支持 | 支持 | 支持 |
网络要求 | 支持离线 | 依赖网络 | 支持离线(资源存本地情况) | 支持离线 |
更新复杂度 | 高(几乎总是通过应用商店更新) | 低(服务器端直接更新) | 较低(可以进行资源包更新) | 较低(可以进行资源包更新) |
编程语言 | Android(Java),iOS(OC/Swift) | js+html+css3 | js+html+css3 | 主要使用JS编写,语法规则JSX |
社区资源 | 丰富(Android,iOS单独学习) | 丰富(大量前端资源) | 有局限(不同的Hybrid相互独立) | 丰富(统一的活跃社区) |
上手难度 | 难(不同平台需要单独学习) | 简单(写一次,支持不同平台访问) | 简单(写一次,运行任何平台) | 简单(学习一次,写任何平台) |
开发周期 | 长 | 短 | 较短 | 中等 |
开发成本 | 昂贵 | 便宜 | 较为便宜 | 中等 |
跨平台 | 不跨平台 | 所有H5浏览器 | Android,iOS,h5浏览器 | Android,iOS |
APP发布 | App Store | Web服务器 | App Store | App Store |
选择
目前有多种开发模式,那么平时开发时如何选择用哪种模式呢?如下
-
选择纯Native App模式的情况
- 性能要求极高,体验要求极好,不追求开发效率
- 正常来说如果要求不是特别高,会有Hybrid
-
选择Web App模式的情况
- 不追求用户体验和性能,对离线访问没要求。正常来说,如果追求性能和体验,都不会选用web app
- 没有额外功能,只有一些信息展示。因为web有限制,很多功能都无法实现,所以有额外功能就只能弃用这种方案了
-
选择Hybrid App(混合开发)模式的情况:大部分情况下的App都推荐采用这种模式
这种模式可以用原生来实现要求高的界面,对于一些比较通用型,展示型的页面完全可以用web来实现,达到跨平台效果,提升效率。当然了,一般好一点的Hybrid方案,都会把资源放在本地的,可以减少网络流量消耗
-
选择React Native App模式的情况
追求性能,体验,同时追求开发效率,而且有一定的技术资本,舍得前期投入
React Native这种模式学习成本较高,所以需要前期投入不少时间才能达到较好水平,但是有了一定水准后,开发起来它的优势就体现出来了,性能不逊色原生,而且开发速度也很快
-
选择其它方案
小程序:(目前移动 App 中开发难度最低的,体验也是仅次于原生+跨平台NativeApp)
更多推荐
所有评论(0)