鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?

前段时间,发表了鸿蒙系统扫盲(三):鸿蒙开发用什么语言?这篇文章,收到一些网友的提问,一一解答了,还有网友对我进行了严厉的批评和尖锐的指责,说我有点颠倒是非,ts的是脚本语言,Java是编译语言,我说ts的性能超过Java,是来搞笑的。

本着严谨学习的态度,我查阅了大量的资料,也向一些大神请教了,觉得有必要再深入,全面但用不要故作高深地、通俗易懂地拓展一下这方面的知识,这是一个开放交流的平台,如果有错误之处,希望大家指出来,一起学习进步!

1.Java是解释型语言还是编译型语言?

首先看一个事例:如果你是一个外交官,你要出访一个国家A,但是你不会A国的语言,这时候你就必须带一个翻译官,你说一句中文,他就会给你翻译成A国语言,讲给对方听,这个场景大伙应该不陌生,这就是解释型语言的运行过程;

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第1张图片

形象化解释型语言整个过程

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第2张图片

解释型语言的编译执行过程

而如果你会A国的语言,可以直接表达出你的想法,这个就是编译型语言的运作过程:

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第3张图片

形象化编译型语言

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第4张图片

编译型语言编译执行过程

很明显,编译型语言的运行效率要远远高于解释型语言,而我们常说的JVM(Java虚拟机)就是翻译官的经典代表,它的一部分职责就是做这个翻译的工作,当然它还有其他工作。而解释型语言的代表就是耳熟能详的C/C++、Rust,以及IOS应用的开发语言,Object-C、Swift等。所以现在应该能理解,为啥苹果就是流畅,安卓不管怎么优化都会卡,这是其中一个重要的原因。

在《编译原理》这门课程中,Java作为解释型语言的一个代表,它是不能脱离JVM而单独运行,但是后来Java为了提高运行效率,陆续推出了JIT技术、AOT等技术,以此来提高Java的运行效率,这也是很多人认为它是编译型语言的原因。

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第5张图片

形象化JIT和AOT技术

JIT技术:类似于你说的一些高频词语,翻译官经常翻译后记住了,后面再有相同或者相似的词语句的时候,不需要再经过翻译,可以脱口而出,提高效率。

AOT技术:类似于一些开场固定话术,常用话术,你在见对方前,先背诵下来,直接说出来,比如“你好”,“很高兴见到你”等词语,可以一定程度上减少翻译官的翻译时间。

可以看到,JIT和AOT技术的引入,确实提高了整体的执行效率,但是,但是,你会一些A国语言,和你完全会这门语言还是有天差地别的区别的!

PS:补充几点

1)JVM的功能很强大,并不只有上面说的那么一点功能,具体不赘述了,容易跑题

2)Java代码本身也不能被JVM所识别,要先编译成字节码,然后才能被JVM识别,然后再由JVM翻译成机器码才能被执行

3)JVM因为功能很强大,所以很消耗资源,谷歌在安卓5.0的时候彻底启用了新的虚拟机,所以从安卓5.0开始,整个安卓的流畅性比4.4以前提高了很多

2.ts的性能能比肩Java?

通过开源鸿蒙的主页,能够看到,TypeScript代码量非常薄,主要的系统代码都在C/C++,Rust这些编译语言为主。

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第6张图片

开源鸿蒙的语言占比

ts的性能在正常情况下,是比不过Java的,这是不争的事实!

不过,不过大家应该听过两个编译器:方舟编译器和毕昇编译器。

方舟编译器:这个大伙应该不陌生,在官网上有介绍,我这里不赘述了。

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第7张图片它按照官方说法,它的作用就是通过AOT技术把部分ets编译成机器可以直接识别的代码,另外一部分不能被编译成机器能识别的,就编译成方舟字节码,通过方舟运行时来执行,由于经过了各种优化,执行效率非常的高,开源鸿蒙里也有对它的详细介绍,链接如下:

方舟运行时子系统介绍

毕昇编译器:这是一个高性能深度优化的C/C++编译器,可以各种提高C/C++的执行效率!

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第8张图片

在华为还在使用安卓系统的时候,通过方舟编译器优化过的同一应用,启动速度和使用的流畅度,都会得到一定的提升,这个网上有很多测试视频,感兴趣的朋友可以去搜搜。

鸿蒙系统扫盲(五):再谈鸿蒙开发用什么语言?_第9张图片

根据上面的资料和总结,整体的系统运行应该是上图所示,首先ets代码量并不多,后端逻辑主要用C/C++去写的,C++这块经过毕昇编译后,效率得到了很大的提升,而ets的执行部分,也是经过了各种优化,效率得到了提升,所以整体的执行效率并不低。

3.纯血鸿蒙系统,内部还有“翻译官”吗?

正如2所说的,方舟编译器不能完全的翻译ets,一些不能翻译的代码,还是会通过“翻译官”翻译给机器,所以还是有的,只是它很轻量级,不像JVM那么重,对性能的影响非常小。

总结:

ets的性能在正常情况下是无法比得过Java的执行效率,而在方舟编译器和毕昇编译器的特别优化下,可以取得更高地执行效率;之所以选择ts作为开发语言,因为每一个系统都需要配套的生态软件才能长久,而Java需要拖一个JVM,会降低运行效率,而C++门槛比较高,所以选择了有一定开发者基数,没有版权问题,且还能通过编译器提高运行效率的语言,所以华为选择了TypeScript。

所有的技术,即使吹的再多,最终都是要回归到用户体验上来的,如果明年的鸿蒙Next版本不能给人丝滑流畅的感觉,那终归还是让人失望的,希望鸿蒙Next明年可以绽放光彩!

你可能感兴趣的:(HarmonyOS(鸿蒙)学习,harmonyos,华为)