Mono 生态系统未来可能的进化方向

Mono 项目从一个开源 C# 编译器起家在十多年中发展成为了一个良好的开发平台[1]。它的很多部件，都在特定时间因为某些原因开发和加入（例如项目的紧迫性，母公司的要求，和纯粹的实验性质研究），但宗旨都是让 Mono 开发者更好的和非 Windows 操作系统底层的 API 互动。

上图列举了当前 Mono 项目的一些重要部件。

基础部件

作为支持 Mono 程序运行的基础，CLR 运行时，BCL 基础类型库，AOT 超前编译以及其他未列出的辅助工具（例如 xbuild 编译引擎）都非常重要，缺一不可。

应用开发框架和函数库

要和 Linux 和其他操作系统原生 API 交互，并将这些功能暴露给应用程序，其他部件也一一被开发出来。比较值得注意的包括，

• 封装 GTK+ API 的 GTK#，用于开发跨平台的可视化应用。
• 封装 Cocoa API的MonoMac，用于开发原生 Mac OS X 应用。
• 模拟微软 WinForms API 的 Mono 版本 WinForms。
• 用于执行 Web 应用的 XSP 服务器（以及适配 Apache 服务器的 mod_mono）。
• 封装 POSIX API 的 Mono.POSIX 函数库。
• 封装 LDAP 操作的 Novell.Directory 函数库。

当然除此之外还有各种辅助函数库，就不赘述了[2]。

如果拿 Mono 的生态图和微软的 .NET 生态系统对比，我们又可以有一些有趣的发现，

1. 顶层的应用开发框架和函数库层面两者有着明显的差异（也对应他们支持的不同操作系统）。
2. 底层的基础部件上，两者居然有非常大的相似性。

目光集中在这些相似的部件上，那么我们可以进一步发现，

• Mono 和 .NET 遵循相同的 ECMA 标准，而且 Mono 项目一直注意保持和 .NET API 的兼容性。在 Mono 的缺陷报告中包含很多案例（我也提交过一些报告，都得到的修复）[3]。
• Mono 的 C# 编译器也比较贴近微软的实现（功能层面），甚至性能还好于Roslyn [4]。
• Mono 很早（数年之前）就提出并实现了 AOT 超前编译，而微软的类似技术 .NET Native 还停留在测试阶段。

可能的合并

自从去年微软先后开源 Roslyn 和 .NET Core，Mono 项目便在积极研究怎样合理的使用微软的代码[5]。这基于几个原因，

• 更好的兼容性。从 Mono 4.0 开始两个生态系统的核心部件（例如 BCL）使用相同的源码。
• 社区重心的调整。当微软乐于提供开源而且跨平台的核心部件（CLR、BCL、编译器甚至 MSBuild），重复劳动就可以消除。开源社区可以把精力放到其他方面，例如改进甚至新建应用开发框架和函数库。

大概在 Mono 4.0 和后续版本中，我们就可以看到这个生态系统转变为，

Xamarin 的产品线

Xamarin 公司的商业化产品实际上已经构建了一个独立的生态系统，未来这个生态系统怎样进化还需要继续观察。

引用

[1] Mono 项目的简单历史资料可见于 Wikipedia。

[2] Mono 各个部件的详细信息请参见 Mono 项目主站。

[3] Mono 的权限跟踪系统在 这里。

[4] Mono 集成 Roslyn 项目的计划在 这里。

[5] Mono 集成其他微软开源代码的计划在 这里。