一、历史的选择
历经多年的手机开发,最终被安卓和ios一通天下。我还记得很多年前,我特别想买的一款诺基亚塞班系统的手机,后来一个亲戚买了之后,各种app不支持,手机还是好的,还挺新,但是不好使了。还记得那些年的Windows Phone,我一直觉得和现在的window10设计还是一致的。
历史的选择,让我们进入移动互联网的时代,也有了我们这个行业的大规模发展。而JavaScript的卓越发展,几乎也是一场侵占的历史,从大家开始认为这门脚本语言,它不一定运行在浏览器上开始,它就做出了,它的飞速发展。例如JavaScript+C++ = node,也或许也诞生了 electron、JavaScript+java = 安卓、JavaScript+object-c = ios。
2008年8月,世界上一段PhoneGap代码诞生了,出现的原因是一名iOS程序员无法忍耐Object-C生硬而又陌生的语法。而这名程序员又恰恰注意到了Web脚本伟大的前景,他发现Object-C显然不如简单的HTML+JavaScript容易理解,而相对于熟练的Object-C程序员,显然熟练的前端开发者更容易找到也更容易培训。于是他就认识到世界上需要这样一种中间件,让Web开发者所熟悉的HTML、CSS、JavaScript技术能够简单地部署在移动设备上,并且能够同iPhone实现简单的功能交互(比如摄像头和重力感应)。
最早的跨平台开发(摘自《Apache Cordova移动应用开发实战》王亚飞,王洪飞编著)
二、乐此不疲的想做一款自己的app
我们不难发现,选择很多app都似乎比你更了解你自己,那么它到底做了些什么呢?我们来瞅瞅....
大家都在说,小米的miui12动了互联网的蛋糕,它指定了规则,让大家一下子有一点懵,那么我们就用miui看看一般手机app,都获取了些什么。
那么我们排除这些用户隐私的内容外,我们还能用app做一些什么网页完不成的任务呢?
获取当前应用的版本号 | 获取网络连接信息 | 获取GPS数据 | 可视化消息提醒 |
---|---|---|---|
获取设备信息 | 在设备上读/写 | 文件上传或者下载 | 调用设备上的摄像头 |
控制应用的启动画面 | 获取设备上联系人的信息 | 二维码扫描和创建 | 调用系统默认键盘 |
可以调整设备亮度 | 设备屏幕方向 | Hardware Nofifications(硬件消息提醒)让设备蜂鸣或振动 | 可以获取电池状态信息 |
检测app是否被安装 | 微信分享、登录、支付 | 手电筒插件 | 等等 |
当然了可能对于大多公司来说,及时的推送(骚扰消息),作为一个公司战略而且,有一个能上架推广的app,就像有一个官网一样重要,它可能没有价值,但是可以唬住一些合作方。
三、技术的选择
思考维度
如果你所处的环境公司的金币就像开了无限一样,那么我不建议你看下去,毕竟有钱的公司,用户的体验才是最重要的。
现在学ios,就是49年入国军
这句话,似乎总是开发们互相嘲讽玩笑,但是它也是一种技术成本压缩下的无奈,因为毕竟不是每一家公司都有这个实力和经费,去养活一个Android团队和一个ios团队,当然也可能就是两个开发,但是这个也是一个要算计的成本。
而这一切,也和混合开发技术的诞生有关。当然较为有钱的公司,会选择,养活少量的Android团队和ios团队,让他们做一个大致的框架,然后通过webView(如果你不能理解这个控件,那么你就认为是iframe也不打紧),这样的技术手段,做一些通讯,来实现一个app,这也是混合开发的一种。
技术优势
那么我们就该讨论一下,这种技术的优势。
研发效率:最大化代码复用,降低开发成本,效率提升是贯穿整个业务技术方向,以后app上线之后,可持续降低后续的维护成本,加快迭代速度,这是一个持续的效率收益。
自我价值:学习之后,无疑是提高了前端团队的技术地位,也是评估跨端技术的一个重要考核点。跨平台可以降低用人成本,避免了同时养两个(Android/iOS)开发团队的现状。对于开发者而言,跨平台可以降低学习成本。
多端致性:好产品在多端UI设计上,往往是整体风格统一,所以业务方采用原生各自独立开发完成后,还需额外花不少时间来修改UI以保证多端一致性。
用户体验:技术的而言,就如鱼和熊掌不可兼得的关系,在方便开发的同时,也同时牺牲了性能的体验。如果你发现鱼和熊掌可以兼得,那么就会有一项技术,退出了它历史的舞台。
大体来说跨平台开发可以由以下三点用来概况。
Web技术: 主要依赖于WebView的技术,功能支持受限,性能体验很差,比如PhoneGap、Cordova、小程序。
原生渲染: 使用JavaScript作为编程语言,通过中间层转化为原生控件来渲染UI界面,比如React Native、Weex。
自渲染技术: 自行实现一套渲染框架,可通过调用skia等方式完成自渲染,而不依赖于原生控件,比如Flutter、Unity。
四、现有技术方案
2011年 Cordova
技术的诞生
Cordova提供了一组设备相关的API,通过这组API,移动应用能够以JavaScript访问原生的设备功能,如摄像头、麦克风等。 Cordova还提供了一组统一的JavaScript类库,以及为这些类库所用的设备相关的原生后台代码。 Cordova支持如下移动操作系统:iOS, Android,ubuntu phone os, Blackberry, Windows Phone, Palm WebOS, Bada 和 Symbian。
2008年8月,PhoneGap在旧金山举办的iPhoneDevCamp上崭露头角,起名为PhoneGap是创始人的想法:“为跨越Web技术和iPhone之间的鸿沟牵线搭桥”。当时PhoneGap隶属于Nitobe公司,而从Nitobe的博客上你可以看到最初创作者对他的评价“他有点像为iphone而开发的AIR”(Air桌面技术使得web开发人员使用。
HTML,CSS,Javascript开发桌面应用程序)。2009年2月25日,PhoneGap0.6发布,是PhoneGap历史上第一个稳定版本,分别支持IOS,Android,BlackBerry平台。在那个时候,PhoneGap已经决定了它所担当的历史任务,直到现在。慢慢的PhoneGap开始支持更多平台。而在此时,被乔布斯宣布死亡的Flash持有者adobe开始意识到,这个项目似乎是自己放弃Flash而寻找替代的一个产品。于是2011年10月4日,Adobe宣布收购Nitobe,在收购之后Adobe其实并没有做太多的贡献,只是把原来的PhoneGap和PhoneGap Build 提供服务并做好宣传工作。
后来Adobe将Phonegap捐献给Apache基金会,作为开源项目。但项目初期依然只是Adobe公司内部员工来维护该项目,而由于Adobe公司依然保留着PhoneGap的商标所有权,导致在那以后的一段日子里,PhoneGap一直被认为是Adobe公司的私有财产。直到PhoneGap1.4发布时,Cordova这个名字才真正被Apache公布(期间有过一次更名叫Apache Callback)。看到这段历史你可能会想到另一端历史Javascript和ECMAscript,你会发现Cordova之于PhoneGap和ECMAscript之于Javascript是多么的相似。
商用情况
优缺点
优点 | 缺点 |
---|---|
开发成本比较低、能够与老业务(当已有h5端、或未来有h5端)做一次完美的融合。 | 任何快速便捷的方案,它必将牺牲掉技术本身的体验效果,cordva技术也不例外。 |
也可以去使用插件式的方法去调用更多的原生api。 | 对于一些老安卓设备,版本比较低的设备,他的兼容性不是很友好,可能会出现一些问题。 |
可以多渠道快速的拓展,达到试点的目的。 | 社区完善程度不够,插件还是偏民间开源项目。 |
使用场景
技术的优缺点似乎还是很明显的,如果你目前处于初创团队,你的团队中,不仅原生开发少,而且前端人手,也不富裕的情况下。你的运营似乎也不大清楚,app对团队发展是否有战略性价值。此时,你的团队有一套的自己的h5代码(技术栈不限制,不论react、vue、jq、Angular)。
有一项开源的方案,叫做Ionic,其实就是cordva+Angular一套方案,灵活的使用一下webpack,做一套自动化的cordva+X即可。
那么我建议最初的情况下,使用这项技术去试点,去拓展,虽然用户体验会降低,但是通过数据渠道包采集,才能了解市场运营的能力,也方便之后的迭代。
ps: 也可能你是自己的私活,套壳技术也可以增加的私活费用。
官网地址
2015年 React Native
技术的诞生
React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架,是Facebook早先开源的JS框架 React 在原生移动应用平台的衍生产物,目前支持iOS和安卓两大平台。RN使用Javascript语言,类似于HTML的JSX,以及CSS来开发移动应用,因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。
商用情况
优缺点
优点 | 缺点 |
---|---|
开发成本中等,语法与react写法没有太大区别,本身的控件提供较为完善 | 仅支持ios与Android端,web端无法使用,增大了代码的复用。 |
社区完善,插件也比较丰富,有facebook作为大厂背书。 | 大版本升级如换血,可能会花费一些时间。 |
体验较好。 |
使用场景
不难看出,在过去的几年里,RN这项技术,收到了广泛的前端跨平台技术的追捧。这点从招聘上来看,这一点就很广泛,它的工资普遍比普通的前端而言会略高一点,它也希望你懂关于原生组件混合开发,而在这些年成长的努力下,其实这套组件的调用上而已,已经比较稳定,加上Facebook目前还不会打自己脸的情况,这项技术的发展还是比较好的。
在前端团队人手不紧张的情况下,而你恰巧也懂react,(其实你就算只懂vue,学起来也很快),这项技术的稳定发展,还是值得你去使用的。
官网地址
约2015年后 uni-app
技术的诞生
很多人以为小程序是微信先推出的,其实,DCloud才是这个行业的开创者。 W3C和HTML5中国产业联盟,推出了HBuilder开发工具,为后续产业化做准备。
2015年,DCloud正式商用了自己的小程序,产品称为“流应用”,它不是B/S模式的轻应用,而是能接近原生功能,性能的动态App,并且即点即用。
为引入技术发扬光大,DCloud将技术标准捐献给工信部所属的HTML5中国产业联盟,并推动各家流量巨头接受该标准,开展小程序业务。
一个使用 Vue.js 开发所有前端应用的框架,开发者编写一套代码,可发布到iOS、Android、H5、以及各种小程序(微信/支付宝/百度/头条/QQ/钉钉/淘宝)、快应用等多个平台。
nvue基于weex那一套的增强版。
这里呢为什么讨论是uni-app而不是weex,weex在那时候,还是现在rn的推出后,红火了一波,毕竟是阿里出品,也给更多的vue玩家打了一针强心剂。
但是就很不幸,weex可能就是历史上一个KPI的耻辱项目,也就是后面他就没了,而uni-app做的也就是捡起来的这件事。
这一项目的特点,也就和最大程度的跨平台息息相关。
4.3.2 商用情况
优缺点
优点 | 缺点 |
---|---|
开发成本更贴近vue技术栈的前端开发 | 复用性也同时带来了,兼容性的问题,每一个小程序的厂商,和各个端的厂商,总有那么几个api调用会有问题。 |
社区完善,插件也比较丰富,有dcloud作为主力推广。 | 体验一般。 |
复用性从理论上极高,支持多端打包运行发布。 |
使用场景
对更多公司而言,使用uni-app的最大特点就是可以最大程度的去跨平台,加上它很适合很多新人上手,使用起来也很简单方便,HBuilder也是做的很不错的开发工具,它的优点强大,也正是它最大的缺点。就是有太多的不可控因素,毕竟对很多开发而言,api的兼容性可能是你会遇到的重大问题。
我的建议是,技术上和公司的发展息息相关,如果未来技术上,可能重点的铺开的试点,而不是作为很多私有api的不同(有去做兼容的时间,可能你重开一个项目的时间都够了),这样的情况下使用这项技术也是一个不错的选择。
官网地址
2018.6.7 taro
技术的诞生
Taro 是一个开放式跨端跨框架解决方案,支持使用 React/Vue/Nerv 等框架来开发微信/京东/百度/支付宝/字节跳动/ QQ 小程序/H5 等应用。现如今市面上端的形态多种多样,Web、React Native、微信小程序等各种端大行其道,当业务要求同时在不同的端都要求有所表现的时候,针对不同的端去编写多套代码的成本显然非常高,这时候只编写一套代码就能够适配到多端的能力就显得极为需要。
有意思的故事说,为什么叫做taro呢?那是因为Taro['tɑ:roʊ],泰罗·奥特曼,宇宙警备队总教官,实力最强的奥特曼。
商用情况
优缺点
优点 | 缺点 |
---|---|
社区比较完善。 | 和uni-app复用性也同时带来了,兼容性的问题,每一个小程序的厂商,和各个端的厂商,总有那么几个api调用会有问题。 |
复用性从理论上极高,支持多端打包运行发布。 | 体验一般。 |
插件市场比较欠缺。 |
使用场景
总的来说,它所可能遇到的问题,几乎和uni-app,你也可以把它当做react版的taro的思路。对于新手用户,可能对于首次电脑的配置,你可能要费一点心思,它的版本构建上,更加偏向指令化的设计。
对于ui框架来说,目前还没有一套真正可以跑全端的开源ui项目,而在版本上也依赖性毕竟强。但是好在团队比较友好,有专门的对外体验群,issue的恢复也足够的即使,加上最近3.0的上线,也会成为一种不错的选择,而且体验上会比uni-app更加好。
技术上的选择,可能和之前说过的uni-app,他们存在同样的毛病,这一点也是在所难免,但是你如果在时间也算富裕,体验又有点追求的,可能在uni-app于它的选择中,也会偏向与它。
官网地址
2018 Flutter
技术的诞生
Flutter是谷歌的移动UI框架,可以快速在iOS和Android上构建高质量的原生用户界面。 Flutter可以与现有的代码一起工作。在全世界,Flutter正在被越来越多的开发者和组织使用,并且Flutter是完全免费、开源的。
相比较目前的混合开发方案,Flutter 提供了大量的文档,能非常快速且友好的让你加入到这个大家庭。它并不止 WebView,也用通过解释 JS 后去操作系统的原生控件,Flutter 核心只有一层轻量的 C/C++代码(Engine),Flutter 在 Dart 中实现了其他大部分系统(组合、手势、动画、框架、widget 等),因此,开发人员可以轻松地进行读取、更改、替换或移除等操作。这为开发人员提供了对系统的巨大可定制性。
针对移动端,Flutter 提供了符合 Android 风格的 Material 和符合 iOS 风格的 Cupertino,同时对不同平台也做了不同的兼容,更好地保留了平台的特性,如 ScrollView,在 iOS 平台中,滑动的时候就拥有回弹的效果,在 Android 平台中,表现出来的就是阻尼的效果。当然,有的时候 Flutter 的 Framework 提供的 UI 格并不能满足我们的需求,我们还可以去自定义控件。
Flutter 在开发中支持 Hot Reload,相比较原生,这样的方式能更高效地开发,真正做到所写即所得。
商用情况
优缺点
优点 | 缺点 |
---|---|
用户体验上混合开发中最佳。 | 前期学习成本太高。 |
社区完善。 | |
有Google作为主力推广。 |
使用场景
Flutter无疑是这几年混合开发技术上,最热门的话题。它的热度评论,也算是一种火爆,民间也传言,看跨平台技术,看一看闲鱼团队。首先,我这里要说一声抱歉,我除了跑完了完整的demo之后,并没有使用这项技术作为商用技术的手段。为什么呢?那么我们来分析一下。
无疑问的说,混合开发的用户体验,Flutter是目前最好的技术体验,至于原因,大家也知道,是因为它的引擎中的自渲染。但是它的学习成本,就另一个角度的代表了用人的成本,
对于个人发展而言,比如说,我使用以上任何一个技术,不管这样的技术如何迭代,我之后是否换公司,我所思考的深度,还是在三大框架与jq之间,即使未来不做混合开发,其实问题也不大。但是flutter这项技术采用了dart.js,当然了它还是代表了JavaScript中的特性,但是写法上却和我们普通的网页布局,有所不同。如果有一天被淘汰,可能对于我们前端未来的发展有限,可能就是说,会是加分项,但是不会也不太会是减分项。
而对于公司而言,可能老项目组人员的替换上,新入职的标准就要加上会使用flutter,或者给新人足够的时间去适应,也是无形中增加了成本。
官网地址
五、总结
大家可以不难看到,跨平台技术,从2008年,想减轻一些原生开发的工作量,到现在2020年,我们马上要步入的5G时代而言,其实着重点可能会产生一些不一样的地方。可能之前只是考虑如何只做一个app,现在可能会考虑到公司用户流量的入口(但凡有点名气的公司,都有一套小程序),如何多样化,宁可多做,也不愿意错过任何一个时代的风口。
技术的本身都是有着它足够的价值,可能有人会觉得react>vue>jq等等,这样技术栈的鄙视链,但是我认为,没有所谓不好的技术,因为技术本身他的团队,还在迭代,还在发展,这就已经说明了问题。鱼和熊掌不可兼得,如果可以,那么一定会淘汰一项技术。
在合适的场景,和对未来的正确估计下(别老想着自己未来是个多好多大的项目),使用一些合适技术,这样才能更好的体现项目和产品的价值。