Post

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 集成其他微软开源代码的计划在 这里。

© Lex Li. All rights reserved. The code included is licensed under CC BY 4.0 unless otherwise noted.