前言
本文主要是经过部分调研,几种技术栈的初步调研与入门使用。以及部分网络资料的整理下得出的带有一部分主观判断的结论,并因互联网发展迅速的关系可能会有一定的时效性,因此在阅读本文的时候请读者酌情根据当前情况进行自己的思考与结论。
关于Apicloud
apicloud是国内一家闭源的html5移动端app解决方案提供商。用纯html的方式生成页面并通过原生注入jsbridge来与js进行交互。处理原生事件与页面切换。对于开发人员来说,是纯html+一个api事件。无需接触到任何底层,并如果有特殊需求可以自行开发原生应用模块来进行拓展。
因为闭源的关系,国内社区并不是很火。因此名气不是很大。
类似产品有AppCan、Dcloud、WeX5
技术比较
首先是一个对比表来区别几种技术栈。
技术特点 | Native | ReactNative | Weex | Apicloud |
---|---|---|---|---|
学习成本 | 高 | 中 | 中 | 低 |
开发成本 | 高 | 中 | 低 | 低 |
调试难度 | 难 | 难 | 简单 | 中 |
控制台输出 | 支持 | 支持 | 支持 | 不支持 |
断点调试 | 支持 | 支持 | 支持 | 不支持 |
开发工具 | 官方提供IDE | 官方提供终端 | 官方提供终端 | 官方提供IDE |
模拟器/真机 | 必须 | 必须 | 非必须 | 必须 |
开发硬件需求(ios) | Mac | Mac | 无 | 无 |
应用硬件需求(ios) | All | Android 4.1 (API 16), iOS 8.0+ | Android 4.1 (API 16), iOS 8.0+ and WebKit 534.30+ | (未找到) |
可拓展性 | 高 | 中 | 中 | 低 |
优化难度 | 低 | 中 | 中 | 高 |
渲染流畅 | 高 | 高 | 高 | 中 |
渲染方式 | 原生图形库 | Virtual DOM | Virtual DOM | Webview |
布局方式 | XML | React | Vue | Html |
样式写法 | 属性 | 基于css的对象 | 阉割版css | 原生css |
代码结构 | 基于类 | 基于类 | 基于类 | 基于Page |
代码架构 | MVC | MVVM | MVVM | 无 |
技术栈 | JAVA+Android SDK; OC/Swift + cocoa |
React+ReactNative | Vue+Weex | Html+Apicloud api |
社区活跃度 | 活跃 | 活跃 | 一般 | 不活跃 |
开源闭源 | 开源(安卓,核心代码闭源); 闭源(ios) |
开源 | 开源 | 闭源 |
开源协议 | Apache(安卓) | BSD | Apache | / |
支持公司 | 谷歌苹果 | 阿里巴巴 | 活了3年的小公司 | |
坑量 | 少 | 多 | 多 | 少 |
遇坑概率 | 小 | 大 | 大 | 小 |
专业著作 | 《Android从入门到翻墙》; 《IOS从买Mac到装Windows》 |
《ReactNative从入坑到弃坑》 | 《Weex从信任到骂KPI》 | 无 |
以上大概是我个人总结出来的各个技术栈的区别。
关于KPI
为什么要在这里提一下KPI呢。就不得不说一说阿里传统。阿里的工资水平是基于 关键绩效指标 来进行升迁评估。因此为了个人、小组的工资待遇,必须要给上级做出点成绩来。也就是说要考虑到阿里的项目是不是基于这个原则来开源的项目。
(PS: 据网络流传阿里内部自己都不用weex)
这就是为什么业内普遍对weex很冷淡,而weex本身也没有花太多力气去推广。
关于技术选择
为什么说是技术选择呢?因为技术不是产品,技术是一种创新的态度。产品,要求的是稳,快。而技术,要的是新。如果是考虑技术的话。我会选择ReactNative 或者 Weex。这两者都是基于现代前端的MVVM架构诞生的以HTML技术编写原生应用的产品。它们不是用的手机端的html解释器与渲染引擎,而是以标签与嵌套描述原生组件的技术。因此它们的渲染效率可以直追原生应用。
但是,它们尚不是一个很成熟的技术,不像原生技术有多年沉淀,不像html有厚重的历史。它们作为前端最前沿的技术(应当还要算上NativeScript
),它们还比较年轻,换种说法就是坑比较多。在网上找找,大部分文章都是ReactNative踩坑大全、Weex踩过的坑。不可否认它们能够做出比较成熟,渲染效率也不错的APP应用。但是如果是作为一个产品的话,我们不得不计算上使用这个技术所需要花费的时间成本。
关于产品选择
如果只是为了实现一个产品的话。那么我推荐使用Apicloud
等以html渲染方式的技术。其内核是cordova
,前身是phonegap
,也是前段跨平台编写原生应用的老前辈了。技术也是已经达到了一个相对成熟的地步。因为野心不大,所以坑少。牺牲一部分不明显的渲染效率来换取稳定且成熟的实现方式,我认为是一种很明智的选择。举个最简单例子。一个页面,原生渲染需要消耗10ms,而cordova需要消耗50ms。其中渲染效率相差整整5倍,然而实际上用户并不能感受到这之间明显的差别。当然如果是需要比较复杂的动画效果的话,这个问题可能会被放大。(人眼辨别连续运动的物体只需要每秒24帧,但是却可以很明显的感觉到每秒60帧与每秒30帧的区别)
其问题还在于,对于喜欢折腾的技术人员来说,使用旧技术去做产品是一件很无趣的事情。如果是我自己的项目,我绝对不会去使用该类技术。因为真的很无聊。
代码风格
代码风格很重要,因为很明显的可以影响程序员的编写效率。一个好的框架可以极大程度上改变工作的进度。
这里截取一部分代码,来感受下各个技术栈之间的差异。
React: F8App
1 | var React = require('React'); |
React 应用是基于组件(或者说类),其特点是不直接接触html代码,而是返回一个虚拟dom,根据虚拟dom来修改前端显示。其所有的组件(包括根容器)都是基于React.Component
这个类进行实现的,开发者要做的都是复写他的方法(主要是render
方法)
Weex: yanxuan-weex-demo
1 | <template> |
Weex2.x 是基于Vue作为前端驱动。一个vue文件是由template
, script
, style
三个标签组成的。相比React
更加趋近与网页端的写法。最后返回给解释器一个大对象,来对dom进行操作。当然我个人是不喜欢这种返回一个大对象的方式的。曾经也有一个类似操作一个大对象的前端工具叫grunt
,然后被gulp
取代了。。。
Apicloud: Answer
1 |
|
而Apicloud
这种技术就是基于html实现的,而每个html对应一个网页对应一个窗口。和普通的网页编写非常类似。这也就是为什么该项技术成熟的原因。因为完全就是玩个的编写方式。当然区别就是提供了一个可以供js调用的原生服务的接口。
总结
具体选择哪项技术,要根据自己的实际需求来决定。任何脱离实际需求的选择都是耍流氓。
但是,如果决定选择ReactNative或者Weex这样注定是未来趋势的新技术的话。就必须做好不断踩坑的打算,毕竟我们需要给予这些技术以发展的时间。当然,reactjs与vue已经是相对成熟的技术了,如果是为了学习的话。顺便学习一门新的技术也是一个不错的决定。