卓易通：鸿蒙Next系统的蜜糖还是毒药？

哈喽，我是老刘

最近很多人都在问鸿蒙next系统新上线的卓易通和出境易两款应用。

老刘分析了一下这个软件的一些细节，觉得还是蛮有意思的，我觉得可以从使用体验、底层原理和对鸿蒙生态的影响这三个角度来分析一下。

使用体验

性能

看到了一些测评，特别是有人直接就跑分的??
总体来说从跑分来看性能是鸿蒙原生的93%，基本是容器的平均水平，性能损失不大。
但是其它方面的表现就比较糟糕了。

内存

这个Android运行时的容器本身运行需要8G左右内存。

所以没有16G内存的丐版手机，就不要想运行什么大程序了。

功耗

不少网友评价手机容易发烫，就是功耗高的表现。
其实这也很好理解，在一个系统上持续运行另一个系统的容器，同时又想做到性能没有大幅损失，就只能通过持续的高功耗来弥补了。

同时要注意，高内存占用和高功耗不仅仅影响容器内运行的Android应用，也会对原生应用造成影响。
原生应用的可用内存减少，cpu持续被容器占用，会出现使用时比较卡顿甚至异常等现象。
当然手机续航也会大幅下降。

用户体验

也有不少用户反馈bug较多。
我想这一方面和容器本身的兼容性有关，另一方面也和内存、功耗的问题有关。
在高功耗、内存吃紧的情况下很多手机App都会出现一些问题。

总体来说使用体验是能用，但是不好用。
换句话说就是比较适合临时应个急，作为日常使用不推荐，除了bug还会造成续航的下降。

底层原理

前面我们提到整体的性能损失不大，由此也可验证不是采用的虚拟机方案。
但是其实这种技术方案也不完全算是很多人说的容器技术，我的理解是类似WSL2这样的介于容器和虚拟机之间的一种轻量级虚拟技术。
接下来我们把几种在一个系统上运行另一个系统应用的方案对比看一下就比较清晰了。

虚拟机

虚拟机是通过在系统中模拟一个完整的硬件环境来运行目标系统或应用程序。
假设是使用虚拟机来运行Android应用，那就是如下的结构。
运行Android应用时，虚拟机将完整的Android系统部署在虚拟的手机硬件之上，通过动态翻译将指令映射到鸿蒙系统的底层架构。
我们先来看一下一个普通Android App的运行架构

如果在一个虚拟机里面运行，则整体架构如下：

从架构上就可以看出来，虚拟机的优缺点都很明显。
优势

强隔离性：虚拟机通过独立的运行环境与宿主系统隔离，可以提供更高的安全性。
兼容性强：能够在宿主系统上原生支持几乎所有的Android应用，无需对应用进行修改。

劣势

性能开销：由于需要模拟硬件和运行时环境，虚拟机通常会带来较高的资源占用和性能损耗。
启动时间较长：虚拟机初始化过程复杂，启动速度相对较慢。

但是在卓易通这种场景中，我们不需要虚拟出一套不同的手机硬件，因为这样的开销太大了。
能否让虚拟系统和宿主系统共用一套硬件呢？
这种方案也是有的，就是轻量级虚拟化技术。

轻量级虚拟化

这种技术方案的典型代表是微软的Linux子系统，下面简称为WSL2。
简单来说，WSL2 在 Windows 上运行了一个 Linux 内核，但它不虚拟硬件。
WSL2 利用虚拟化技术（如 Hyper-V）提供内核隔离，同时通过与 Windows 系统的深度集成，消除了传统虚拟机与宿主系统之间的隔阂。例如，文件系统操作、网络共享和进程调用的性能和用户体验更加接近原生应用。
架构示意图如下：

它具有如下特点：

虚拟化但非硬件仿真：
使用轻量虚拟化运行 Linux 内核。
不模拟硬件，而是直接利用宿主机的硬件资源。
高效的系统调用桥接：
Linux 应用直接调用 Linux 内核，而 WSL2 的内核通过微软的接口与 Windows 通信。
比传统虚拟机更高效，部分性能接近原生运行。
用户体验类似容器：
提供快速启动、轻量运行的体验。
与 Windows 文件系统无缝交互，支持共享资源。

API兼容层

轻量级虚拟化方案的性能虽然比虚拟机要高很多，但是仍然有中间商。
Hyper-V向上提供的仍然是虚拟的cpu和内存，并且Linux内核本身也会占用大量的cpu和内存资源。
那能否直接在宿主运行时上运行另一个系统的应用呢？
这种方案也是有的。
典型的代表就是Linux上的Wine，可以直接在Linux上运行windows的exe程序。
Wine（Wine Is Not an Emulator）是一个兼容层，它允许在 Linux、macOS 或其他 Unix-like 系统上运行 Windows 程序。
它通过直接将 Windows API 调用转换为对应平台的本地系统调用，从而让 Windows 应用程序能够在非 Windows 系统上原生运行。
架构如下：

Wine 的优点

较高的性能：
无虚拟化开销：Wine 直接将 Windows API 调用转换为宿主操作系统的调用，因此它没有虚拟机或容器那样的额外性能开销。这使得 Wine 运行 Windows 应用程序时通常具有接近原生 Windows 系统的性能。
运行效率：由于没有模拟硬件或操作系统，Wine 的效率通常比虚拟机（如 VMware 或 VirtualBox）和 WSL2 更高。
较小的资源消耗：
低资源占用：Wine 不需要像虚拟机那样模拟整个硬件环境，也不需要运行完整的操作系统。因此，它消耗的资源（如 CPU 和内存）相对较少，特别适用于资源有限的系统。
启动速度快：Wine 启动 Windows 应用程序的速度比虚拟机或 WSL2 要快，因为它不需要启动一个完整的虚拟操作系统。
Wine的缺点
兼容性问题：
并非所有 Windows 应用程序都兼容：Wine 并不是完美的 Windows 兼容层，并非所有 Windows 应用程序都能顺利运行。尽管 Wine 对许多应用有良好的兼容性，但一些复杂的应用（尤其是需要底层硬件访问的程序，如一些游戏或专业软件）可能无法正常工作。
有限的驱动和 API 支持：Wine 并不完全实现 Windows 的所有 API，它仅支持大多数常见的 Windows 调用。对于一些高级功能或特殊硬件支持（如 DirectX 或某些图形加速功能），Wine 的支持可能不足。
图形和多媒体支持较弱：
图形性能问题：尽管 Wine 支持 DirectX 和 OpenGL 的映射，但与 Windows 原生运行时相比，图形性能可能较差，尤其是在图形密集型应用程序（如 3D 游戏、图形设计软件等）上。Wine 的 DirectX 到 OpenGL 转换可能会影响渲染性能。
有限的硬件加速支持：Wine 不能直接访问硬件加速功能（如 GPU 加速），因此在需要高度图形渲染的应用程序中，它的表现可能不如 Windows 原生环境。

卓易通的方案

前面介绍了目前主流的跨平台运行App的方案，那么本文的主角卓易通采用的是哪一种呢？
卓易通采用了华为自家的iSulad容器。
事实上卓易通技术方案和前面介绍的WSL2比较类似。

可以看到，因为鸿蒙内核兼容Linux ABI（应用程序二进制接口），而Android内核又是基于Linux内核修改的。
所以可以直接在鸿蒙内核上跑一个定制的Android 运行时。
当然这里没有完整的Android内核功能，所以前面说的一些兼容bug也有可能是这个原因导致的。
可能很多不是从事Android开发的同学对这个运行时没有什么概念，来看下面这幅图：

图中用红色框起来的部分都是本文提到的Android运行时的内容。
或者我们可以这么理解，一个Android App能运行起来，这里面的大部分内容都需要。
所以也就能理解，为啥只是把卓易通跑起来就需要大约8G的内存了吧？
而这里面有很多东西是需要常驻后台，实时响应用户及APP请求的，这也是为什么卓易通会造成持续的功耗和发热。

前面我们介绍了想在一个系统上运行另一个系统的应用都有哪些方案。
并且基于此介绍了卓易通的技术方案的特点。
相信到这里大家对卓易通到底是啥东西有一定的了解了。
那么接下来我们来看看推出卓易通和出境易两款应用，通过虚拟化方案兼容Android生态后对鸿蒙生态会有哪些可能的影响？

蜜糖还是毒药？

妥协

鸿蒙目前声称有1.5万应用。
这些应用相对于其对应的Android版本来说，有多少比例的功能看看微信就大概能知道。
而即便不考虑功能的覆盖率，1.5万的数量对于用户来说还是太少了，完全无法支撑日常的使用。
下图是2023年的数据，这个数据中还不包含大量没有上架应用商店的App。

以我自己为例，老刘手机上安装了很多开源或者开发工具配套App，这些应用大多都没有上架应用商店。
这里面的原因就不多说了😮‍💨
总之想支撑大量用户日常使用，没有足够基数的应用数量是不行的。
所以兼容Android应用，让运行鸿蒙 next系统的手机至少能满足日常的使用，就是一个不得不做的妥协。

副作用

本来对于公司或者团队来说，现在的形式不缩减人手就不错了，还要额外增加一个鸿蒙开发的成本？
除非可以看到明确的收益，比如足够大的用户数量，否则是没有动力去开发的。
现在有了卓易通可能开发的动力就更小了。
这让我想起来当年黑莓手机也能兼容Android应用，最后自身生态也没有发展起来。

这里还不得不提一个迷之操作：
纯血鸿蒙上架的应用卓易通里面无法安装，而出境易则只能安装白名单内的应用。
相当于我好不容易开发了一个鸿蒙版App，但是因为人手不足功能一时不全，现在用户还没法用我的Android版。
那我干脆就不开发鸿蒙版好了，这样用户至少还能用一下完整功能的版本。
所以这个决策就给人一种不得不妥协又放不开的感觉。

鸿蒙生态的未来

老刘作为一个在一线的开发者，我做过架构师也带团队，所以我一直以来都很关注成本问题。
当前的形式下，很多公司的客户端团队Android和ios都只剩一个人了。
即使还保留建制的团队，再增加一个鸿蒙开发组也很难。
所以想要让鸿蒙生态快速增长，最有效的办法就是大力发展Flutter这样的跨平台框架在鸿蒙上的兼容性。
如果一个团队、一套代码可以同时开发Android、iOS和鸿蒙三套系统，并且都能提供原生级的用户体验，那是不是前面的问题都可以有效的解决呢？
目前据我所知有不少基于Flutter鸿蒙定制版本的应用已经上架了。
这里也希望基于鸿蒙系统的Flutter生态能快速健全起来。

总结

本文介绍了纯血鸿蒙版本卓易通和出境易两款应用中运行Android App的体验和运行原理。
同时分析了在这个虚拟环境下运行Android应用对于鸿蒙生态的一些看法。
个人观点Flutter这样的跨平台框架才是鸿蒙生态快速增长的关键。
如果看到这里的同学有学习Flutter的兴趣，欢迎联系老刘，我们互相学习。
点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》

卓易通：鸿蒙Next系统的蜜糖还是毒药？