我正在参加跨端技术专题征文活动，详情查看：juejin.cn/post/710123…
一、历史的选择
历经多年的手机开发，最终被安卓和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等等，这样技术栈的鄙视链，但是我认为，没有所谓不好的技术，因为技术本身他的团队，还在迭代，还在发展，这就已经说明了问题。鱼和熊掌不可兼得，如果可以，那么一定会淘汰一项技术。
在合适的场景，和对未来的正确估计下(别老想着自己未来是个多好多大的项目)，使用一些合适技术，这样才能更好的体现项目和产品的价值。