聊聊移动端跨平台开拓的各类技能语言&工具

来源:互联网 / 作者:SKY / 2017-12-01 05:28 / 点击:
最近呈现的 React Native 再次让跨平台移动端开拓这个话题火起来了,曾经各人觉得在手机上可以像桌面那样通过 Web 技能来实现跨平台开拓,却大多由于机能或成果

最近呈现的 React Native 再次让跨平台移动端开拓这个话题火起来了,曾经各人觉得在手机上可以像桌面那样通过 Web 技能来实现跨平台开拓,却大多由于机能或成果题目而放弃,不得不针对差异平台开拓多个版本。

但这并没有阻止人们对跨平台开拓技能的试探,事实谁不想低落开拓本钱,一次编写就随处运行呢?除了 React Native,这几年还呈现过很多其余办理方案,本文我将会对这些方案举办技能说明,供感乐趣的读者参考。

为了利便接头,我将它们分为了以下 4 大门户:

Web 流:也被称为 Hybrid 技能,它基于 Web 相干技能来实现界面及成果

代码转换流:将某个说话转成 Objective-C、Java 或 C#,然后行使差异平台下的官方器材来开拓

编译流:将某个说话编译为二进制文件,天生动态库或打包成 apk/ipa/xap 文件

假造机流:通过将某个说话的假造机移植到差异平台上来运行

Web 流

Web 流是各人都较量相识的了,好比闻名的 PhoneGap/Cordova,它将原生的接口封装后袒露给 JavaScript,可以运行在体系自带的 WebView 中,也可以本身内嵌一个 Chrome 内核 。

作为这几年争论的热门,网上已经有许多关于它的接头了,这里我重点聊聊各人最体谅的机能题目。

Web 流最常被吐槽的就是机能慢(这里指内嵌 HTML 的机能,不思量收集加载时刻),可为什么慢呢?常见的观点是以为「DOM 很慢」,然而从赏识器实现角度来看,着实 DOM 就是将对文档操纵的 API 袒露给了 JavaScript,而 JavaScript 的挪用这些 API 后就进入内部的 C++ 实现了,这中间并没有几多机能耗损,以是从理论上来说赏识器的 DOM 必定比 Android 的「DOM」快,由于 Android 的揭示架构大部门成果是用 Java 写的,在实现沟通成果的条件下,C++ 不大也许比 Java 慢(某些环境下 JIT 编译优化确实有也许做得更好,但那只是少数环境)。

以是从字面意思上看「DOM 很慢」的说法是错误的,这个观点之以是很广泛,也许是由于大部门人对赏识器实现不相识,只知道赏识器有 DOM,以是不管什么题目都只能诉苦它了。

那么题目在哪呢?在我看来有三方面的题目:

早期赏识器实现较量差,没有举办优化

CSS 过于伟大,计较起来更耗时

DOM 提供的接口太有限,使得难以举办优化

第一个题目是最要害也是最难办理的,此刻说到 Web 机能差首要说的是 Android 下较量差,在 iOS 下已经很流通了,在 Android 4 之前的 WebView 乃至都没有实现 GPU 加快,每次重绘整个页面,有动画的时辰不卡才怪。

赏识器实现的优化可以等 Android 4.4 逐步遍及起来,由于 4.4 往后就行使 Chrome 来渲染了。

而对付最新的赏识器来说,渲染慢的缘故起因就首要是第二个题目:CSS 过于伟大,由于从实现道理上看 Chrome 和 Android View 并没有本质上的不同,但 CSS 太机动成果太多了,以是计较本钱很高,天然就更慢了。

那是不是可以通过简化 CSS 来办理?现实上还真有人这么实行了,好比 Famo.us,它最大的特色就是不让你写 CSS,只能行使牢靠的几种机关要领,完端赖 JavaScript 来写界面,以是它能有用停止写出低效的 CSS,从而晋升机能。

而对付伟大的界面及手机下常见的超长的 ListView 来说,第三个题目会更突出,由于 DOM 是一个很上层的 API,使得 JavaScript 无法做到像 Native 那样细粒度的节制内存及线程,以是难以举办优化,则在硬件较差的呆板上会较量明明。对付这个题目,我们一年前曾经实行过嵌入原生组件的方法来办理,不外这个方案必要依靠应用端的支持,或者往后赏识器会自带几个优化后的 Web Components 组件,行使这些组件就能很好办理机能题目。

现阶段这三个题目都欠好办理,以是有人想爽性不消 HTML/CSS,本身来画界面,好比 React canvas 直接画在 Canvas 上,但在我看来这只是现阶段办理部门题目的要领,在后头的章节我会具体先容本身画 UI 的各类题目,这里说个汗青吧,6 年前赏识器还较量慢的时辰,Bespin 就这么干过,其后这个项目被行使 DOM 的 ACE 代替了,今朝包罗 TextMirror 和 Atom 在内的主流编辑器都是直接行使 DOM,乃至 W3C 有人专门写了篇文章吐槽用 Canvas 做编辑器的各种弱点,以是行使 Canvas 要审慎。

其它除了 Canvas,尚有人觉得 WebGL 快,就实行绘制到 WebGL 上,好比 HTML-GL,但它今朝的实现太偷懒了,简朴来说就是先用 html2canvas 将 DOM 节点渲染成图片,然后将这个图片作为贴图放在 WebGL 中,这便是将赏识器顶用 C++ 写的东东在 JavaScript 里实现了一遍,渲染速率必定反而更慢,但倒是能用 GLSL 做殊效来忽悠人。

硬件加快不等同于「快」,假如你觉得硬件加快必然比软件快,那你该抽闲学学计较机系统布局了

着实除了机能题目,我以为在 Web 流更严峻的题目是成果缺失,好比 iOS 8 就新增 4000+ API,而 Web 尺度必要漫长的编写和评审进程,基础赶不上,即即是 Cordova 这样本身封装也忙不外来,所觉得了更好地行使体系新成果,写 Native 代码是必需的。

代码转换流

前面提到写 Native 代码是必需的,但差异平台下的官方说话纷歧样,这会导致同样的逻辑要写两次以上,于是就有人想到了通过代码转换的方法来镌汰事变量,好比将 Java 转成 Objective-C。

这种方法固然听起来不是很靠谱,但它却是本钱和风险都最小的,由于代码转换后就可以用官方提供的各类器材了,和平凡开拓区别不大,因此不消担忧碰着各类诡异的题目,不外必要留意天生的代码是否可读,不行读的方案就别思量了。

接下来看看今朝存在的几种代码转换方法。

将 Java 转成 Objective-C

j2objc 能将 Java 代码转成 Objective-C,听说 Google 内部就是行使它来低落跨平台开拓本钱的,好比 Google Inbox 项目就号称通过它共用了 70% 的代码,结果很明显。

也许有人会认为稀疏,为何 Google 要专门开拓一个辅佐各人写 Objective-C 的器材?尚有媒体说 Google 做了件功德,着实吧,我认为 Google 这算盘打得不错,由于根基上重要的应用城市同时开拓 Android 和 iOS 版本,有了这个器材就意味着,你可以先开拓 Android 版本,然后再开拓 iOS 版本。。。

既然都有乐成案例了,这个方案确实值得实行,并且要害是会 Java 的人多啊,可以通过它来快速移植代码到 Objective-C 中。

将 Objective-C 转成 Java

阅读延展

1
3