跨端框架汇总及点评
跨端框架汇总及点评
本文档用以记录目前我使用或了解过的跨端框架,并作简单介绍以供技术选型使用
Cordova/Quasar/Ionic
官网
说明
Cordova 是 Apache 旗下的一个开源的移动开发框架。使用 WEB 开发技术（HTML5、CSS3、JavaScript）进行跨平台开发。
点评
不推荐
Hybrid 架构,坑较多,目前新项目一般不建议使用该框架开发,cordova 在国内的本地化并不是很好,其插件市场上相当一部分插件已经停更许久,若入手开发会面临对接入第三方 SDK 需要自己手动对接的情况.
唯一优点是因为是纯 Hybird 架构,打出来的包体积会很小可以控制在 KB 级别,如果对包体积实在在意并且项目目前以及未来都不会有原生能力需求,可以考虑该框架.
但凡未来有可能调用原生能力,我都不建议使用 cordova 进行开发.
taro
官网
说明
Taro 是一个开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发 微信 / 京东 / 百度 / 支付宝 / 字节跳动 / QQ 小程序 / H5 等应用。现如今市面上端的形态多种多样，Web、React Native、微信小程序等各种端大行其道，当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高，这时候只编写一套代码就能够适配到多端的能力就显得极为需要。
点评
重点推荐.
RN 的多端实现版,可以这么理解,没有云打包,无可用多端 UI 框架,适合自研项目.
taro 当前已经更新至 3.0 版本,本身没有什么问题,唯一需要注意的是 taro目前主要重心在小程序端.
其 APP 端是基于 RN 实现的,想法与结果都很美好,但是目前 taro 的生态还不是很好,目前 taro 还没有一款拿得出手的多端同步 UI 框架,其官方的 taro-ui 目前还不支持 RN 端(截至 2021 年 1 月).
taro 是完全开源的,得益于 react 和 ts 的舒适性,taro 非常适合互联网公司做长期项目,但是由于目前生态不完善,在开发多端应用(含 RN)时需要完全从 0 开始实现自己的 UI 界面,这对于一些外包性的项目来说肯定是不可接受的,但是如果是从零开始的自研产品,我是强烈推荐使用 taro 开发的.
taro3 也支持 vue 等其他实现,但是考虑到兼容 RN 的因素,不推荐使用.我建议要是用 vue 还是直接上 uni-app 吧
uni-app
官网
说明
uni-app 是一个使用 Vue.js 开发所有前端应用的框架，开发者编写一套代码，可发布到 iOS、Android、Web（响应式）、以及各种小程序（微信/支付宝/百度/头条/QQ/钉钉/淘宝）、快应用等多个平台。
点评
重点推荐
APP 端基于 WEEX,提供云打包,UI 框架很多,半开源,适合互联网项目/外包项目.生态比 taro 好太多了.还可以通过对接 UNISDK 使自己的原生应用获得小程序能力,这点是最骚的.
uni-app 的使用体验非常棒,得益于 dcloud 提供的一条龙服务(serverless(uni-cloud)/统计(uni 统计)/推送(uni-push)/云打包/小程序 SDK),可以真正意义上实现快速上线.
dcloud 的插件市场中的插件目前达到了 3000 多个,虽然质量参差不齐,但是主流的插件或者 UI 框架还是很多的并实用的.与之相对的吐槽下 taro 目前的 130 来款插件的物料市场=.=
uni-app 的 APP 端提供了 weex 实现但不是默认启动的,uni-app 提供了 vue 及 nvue(两种渲染模式),默认的 uni-app 页面还是使用的 webview 作为实现,官方推荐 nvue 作为主要页面优化性能用,因为纯 nvue 的项目开发体验基本就跟写 weex 差不多了,你懂我意思.
uni-app 目前的坑在于,其 APP 端的原生插件还是需要自行对接,如果插件市场没有的话.毕竟 uniapp 的生态体量还是比不过 RN 的.比较 RN 只用关注一端.
flutter
官网
说明
Flutter 是谷歌的移动 UI 框架，可以快速在 iOS 和 Android 上构建高质量的原生用户界面，前端对于 Flutter 的热忱度之高一度让人有点惊讶，事实上在 Flutter 社区内见到的客户端开发者远多于前端开发，不过前端对于跨端解决方案确实有着天然的渴求。
点评
强烈推荐,但不建议完全采用 flutter 开发商业项目.
flutter 就是未来,牛逼就完事了.目前 flutter 的前景应该是跨端框架中最光明的,超高的性能,流程的体验,这才是真正的跨端跨平台开发呀~!×100
目前 flutter 的缺点可能就是嵌套地狱了(谁用谁知道),但是如果做好拆分和封装的话还是可以接受的,另外就是生态方面了,使用 flutter 是会不可避免的接触到原生能力的,不过这都不是事,应该不会有人用 flutter 做外包吧?
flutter 可以不使用,但是我还是建议了解并学习下做好知识储备.
reactnative
官网
说明
使用 JavaScript 和 React 编写原生移动应用：rn 用时间证明了，做安卓+ios 还可以，其他就算了，当然今年 RN 发展很不顺利，被很多大公司移除掉了，继续关注后续发展。
点评
强烈推荐
如果是纯 APP 端项目(不会有 web 或小程序版),别多想!搞他就完事了!RN 在移动端的生态是无人能及的,数之不尽的插件能力,尽管一些大厂因为种种问题放弃 RN,但 RN 的优秀还是值得肯定的,毕竟大多数公司可能永远都不会遇到大厂所碰到的问题.
electron
官网
说明
Electron 这个玩意简直是做团队内部工具的利器，也是前端老手秒上手的东西，可以给团队做些玩意了，桌面端追求开发速度用 Electron 使用 JavaScript, HTML 和 CSS 构建跨平台的桌面应用.
点评
推荐
对于开发桌面端应用 electron 是一个非常不错的选择,相对于 QT 等其他框架,虽然 electron 存在包体积过大,性能需要高度优化等问题,但毕竟当前绝大多数的桌面端应用对性能是不敏感的.高效的开发剩下的那点时间做点什么不好?
apicloud
官网
说明
闭源商业公司项目,仅推荐部分没有程序员或者只有一两个 web 程序员的传统企业使用
点评
一般不推荐
Hybird 架构/官方维护各种原生 SDK/闭源
apicloud 和 dcloud 的事懂的都懂,apicloud 的项目一般出现在外包领域中,目前 apicloud 把自己定位在面向传统企业做项目(从其官方提供的一系列如运行控制的功能可以看出其目前定位),使用 apicloud 开发并发量不大的传统项目.
apicloud 的优点目前仅剩的就是官网维护了一大批热门的冷门的原生 SDK 插件了,使用 apicloud 做项目企业不用招聘原生开发人员.
推荐的做法是企业直接找 apicloud 官方开通会员,然后直接跟他们官方直接沟通对接,使用 apicloud 开发的企业可能面临的问题是留不住开发人员,毕竟这玩意闭源还傻瓜,对程序员的职业进阶一点好处都没有.