2.1 Bitcomet方案设计与分析

2.1.1 为什么选择使用容器与Anbox

        本Bitcomet方案旨在于实现在Linux中运行Android 11的解决方案。在这个方案中会遇到一些问题，如下图2.1是Android系统框架图、图2.2 GNU/Linux系统架构图，这两张图清晰明了地展现了Android与Linux环境的差异：

        Android与Linux除了内核相似外是完全不一样的系统环境，尤其体现在系统libc库、应用的运行方式、输入输出设备的管理方式、图像合成方式、OpenGL接口、网络管理组件等方面。这些组件绝大部分将会与Linux冲突，导致Linux运行异常或者Android无法直接运行，同时Android的APP也无法在Linux内直接运行。

        旧方案：在过去面向用户的常见方案中，常用虚拟机来实现这个方案。利用虚拟化功能运行一个Android虚拟机，虚拟机内虚拟或者模拟了电脑绝大部分的硬件，这样既能解决两者接口不同，又能简单实现Android在其他系统上的运行。但是随之而来也有许多缺点：虚拟化需要硬件支持、虚拟化对CPU性能有一小部分损耗、虚拟机本身运行一个全新的系统也需要更多硬件资源、在虚拟机与主机系统间切换也无法很好地利用上常见PC系统的多任务多窗口特性。

        相比起虚拟机的实现方法，容器基于Linux内核的命名空间隔离，也能提供一个隔离了Android系统与Linux之间的磁盘、内存等的运行环境。同时容器不需要虚拟化，不需要跑起整个Linux内核，相对应的对硬件资源要求较少，这三个方面看起来有优势。但是容器又出现不一样的问题：相比一般Android模拟器使用的虚拟机，容器又缺少输入输出接口、3D加速与显示输出。

        Bitcomet方案：使用容器提供Android运行的环境来实现，其原因如下：该方案可能会在国产化平台上运行，面向不同的硬件环境下不一定支持虚拟化；对硬件资源需求较少；针对容器缺少的输入输出接口以及3D加速与显示输出，谷歌为解决这些问题在安卓模拟器AVD上设计了一套新的方案。另外Anbox在一部分输入输出及3D加速方面正好是复用了谷歌的安卓模拟器的方案，利用了其提供的QEMU_PIPE、emugl、传感器模拟、音频输出等方面提供的实现。

        以上是复用了谷歌的实现，但是前端不一样，安卓模拟器的前端是方便谷歌模拟器实现的，而Anbox是需要利用上PC系统的多任务多窗口、方便对接输入输出和控制等的特性。因此Anbox这部分针对谷歌的方案进行了参考重写，把Android中各个不同APP的窗口映射到不同的模拟Surface上。但相应的代价是，由于谷歌3D渲染部分是通过把其指令传输出来交给外部OpenGL渲染，这样性能利用是真机渲染的70%-90%（数据来自参考文献[1]），有一定的损耗。

2.1.2 总结

        本项目是这类移植方式中其中一种兼容性较好的方案，其OpenGL ES渲染是通过传输给Anbox并由emugl转换后交给Linux用户空间的OpenGL库实现，OpenGL的对应版本的API是统一的，而Linux平台一般都有GPU驱动+相应库，即使没有也会使用软件OpenGL库，所以这种方案理论上是能适应更多GPU平台的。

        总的来说这类移植方式主要都有一类共通点，为了把输入输出、显示渲染等接口打通到对应平台，而不断衍生的技术都有新的优化与改进，尽量减少通信期间数据的拷贝，降低损耗，提高硬件利用率。