关于鸿蒙和方舟的一些思考

关于鸿蒙和方舟的一些思考

华为的鸿蒙系统已正式发布，发布会上公布了很多信息，但是对于重要的细节部分还是缺少很多信息（毕竟没有用例，没有数据，没有代码），导致现在我对这个系统还没有清晰的概念模型（感觉更像是个“集大成者”，什么都有涉及）。这篇文章就根据已有的信息来谈论鸿蒙系统以及方舟编译器，也对发布会上我认为不当的措辞提出质疑。

措辞的问题

1. 首先是关于Linux。发布会上说Linux是个“臃肿的内核”，目前PC和服务器所用的GNU/Linux中的内核确实臃肿，但是Linux内核本身是个可裁剪可定制的内核，也有用于嵌入式平台的版本（uclinux）。所以此言有误。其次，Linux内核的臃肿并非没有意义，我曾经用2009年买的电脑装 Fedora 21 然后一直升级到 Fedora 28，Linux内核里有很多旧驱动来使它可以运行于旧的设备上。嫌它臃肿的，可以自行下载源码来裁剪，毕竟它是自由软件，而不仅仅是开源软件。

2. 应用卡顿有很多原因（例如，后台应用抢占计算资源，算法优化问题，UI线程阻塞等等），垃圾回收（GC）只是其中一个次要原因，首先GC并不是每次都会暂停所有线程（并行回收了解下），其次大部分GC都在几毫秒或十几毫秒完成（印象中，未核实），通常60毫秒的停顿才感知到掉帧。如果GC导致应用卡顿，手机的厂商就该反思了。如果后台服务过多或程序本身有问题，不管什么系统什么语言都会卡顿，GC绝不是主要原因。

优点

1. “第一个适用于所有场景的基于微内核的分布式操作系统”，把这句话拆开来，鸿蒙都不是第一个，但是多个条件组合时，它就是第一个。每个条件都有其优点和缺点，不知道鸿蒙如何扬长避短。

2. 兼容 Linux 和 Android，虽然不是第一个做到这一点的系统了（例如，Sailfish OS，以及GNU/Linux可以通过适配层和模拟器来运行，等等）。

3. 国产（不知道是不是完全自主的），这也可以算是个优点吧。

缺点

1. “一次开发到处运行”，方舟编译器是编译为机器码的，不具备可移植性，这应该是二十多年前Java那句“一次编译到处运行”的退步，确实提高了性能，但却是以牺牲移植性为代价，而且还引入潜在的语言级别的兼容问题。应该算是“对用户友好，但对开发者不友好”的一点吧。（一想到以后要给多个厂商多个平台打多个包，就心累）

2. 性能的瓶颈。方舟编译器编译Java代码采用的内存管理是引用计数（RC）和“智能环消除”（这应该是一种类似GC的动态内存管理技术吧），性能上是不如C++那种静态内存管理和RC配合的方式，也不如Rust那样的XX管理方式。有点像是"方舟编译器带着Java追赶C++"的感觉。

3. 上游问题。Java目前已经发布了Java 13，Android仅高版本支持部分Java 8的API，也仅支持到Java 8的语法特性。方舟编译器支持的Java 版本什么版本？跟在Google后面还是跟在Oracle后面？还是自己研发Java？目前Java 半年发布一个版本，Android一年一个大版本，能否跟得住上游的迭代是个维护时的问题。

4. 静态编译的问题。动态语言和静态语言之争由来已久，也不是静态一定强于动态。各个领域，静态化优点在于性能，动态化在于灵活性，一味地静态化势必有其局限性和缺陷。

5. 碎片化问题。如果鸿蒙仅仅是像Android一样开源，最后还是要面临和Android一样系统碎片化无法控制的问题。

疑问

1. 不知道方舟编译器编译C/C++的质量如何。

2. 多端应用管理，例如，同时安装Linux版的火狐和Android版的火狐，其他应用如何分别和这两个应用通信，并确保安全性。

3. 所有者的问题。GNU/Linux安装完后用户有绝对的控制所有权（换句话说，就是自由），Android用户只有部分自由（即便root了也没有完全的控制权），那么鸿蒙的用户呢？（比如我想删除一个占用计算资源的后台运行的广告服务，会有这个权限吗？）

4. 没有虚拟机以后Java的堆栈跟踪怎么办？应用热启动怎么办？

5. 骡子和马的问题，GNU/Linux 可以做到在GNU/Linux上开发GNU/Linux，那么能否在鸿蒙上开发鸿蒙。

感想

从发布会上给出的信息看，鸿蒙有很多优点，但是业余看着懵（专业的东西太多），专业的看着也懵（没有说明的太多），说了“我们很优秀”，但没有说明“我们怎么优秀，哪里优秀”。作为一个开发者，感觉华为把很多压力推给了开发者（比如厂商适配，应用适配，开发环境的改变）