Xamarin Forms、MVVMCross 和 SkiaSharp：跨平台应用程序开发的三位一体

谈论设定高期望。 神圣的三位一体，仅此而已！

事实是，当您面向多个平台时，移动应用程序的开发成本很高，因为没有共享代码。 Apple 要求您使用 Objective-C 或 Swift 编写代码，Android 要求您使用 Java 编写代码，而 WinPhone 要求您使用 .NET（通常是 C#）进行开发。 再加上每个平台提供的用于处理地图、绘图、图片或 GPS 的大量库——构建单个移动应用程序需要大量的时间和知识。

不用说，大多数初创公司都负担不起三倍的开支，即使是老牌企业也很难证明进入移动领域的价格是合理的。

在本文中，您将了解 Xamarin Forms 如何与 MVVMCross 和 SkiaSharp 相结合，成为构建跨平台移动应用程序的可行方式，而不会影响熟悉度、性能和独特性。 本文将回顾这三种技术，以及它们如何通过允许跨多个移动平台最大限度地重用代码来降低开发成本。

一个重要的问题

跨平台移动应用程序开发的问题是真实存在的，因此，多年来出现了许多不同的解决方案，通过在平台之间共享代码来降低开发成本。 例如，在视频游戏行业，所有主要的游戏引擎都提供了跨平台的解决方案，甚至 Unreal 和 Unity 都针对手机和平板电脑。

在应用程序方面，多年来，人们多次尝试引领这个跨平台市场。 许多人功亏一篑，迷失在深渊中，但其中一些人在多年后仍然幸存下来。 其中包括 Xamarin，它是唯一支持所有三个移动平台的 .NET 解决方案。

不管是不是本地人，我来了

所以在不同的解决方案之间有一场战争，谁说战争就是宣传！

这场战争主要是在大N的前面进行的：本土化！ 你需要对这个词保持警惕，因为它没有明确的含义。 它是当今移动开发世界中使用最多的词，并且非常流行。 事实是，没有人同意它的实际含义。

在选择跨平台框架时，所有“本地”选项都不相同，因此请注意，您可能会将苹果与橙子进行比较。 对于一些人来说，这是关于编程语言，对于其他人来说，是关于能够使用硬件功能，其他人认为这是关于平台 API/UI 的使用，而且通常只是关于不是一个网络应用程序。

辩论的每一方都有争论，我不会深入挖掘，因为它没有用。 为什么没用？ 好吧，让我告诉你一个难以接受的事实：你的最终用户不在乎！

是的，你没看错，只有你的程序员在乎。 您的最终用户永远不会因为底层技术而选择您的应用程序：他们会选择您的应用程序，因为它可以解决他们的问题并提供良好的体验。

因此，让我们看看 Xamarin 如何提供一种有效的方式来为您的用户提供他们关心的内容，而不是争论一个词的含义。

圣父、圣子和圣灵

在我们继续之前，让我们先澄清一下构成我们解决跨平台开发问题的三个要素。

父亲：Xamarin

如前所述，Xamarin 是用于移动和桌面应用程序开发的 .NET 解决方案。 它于 2016 年被微软收购，但可以追溯到大约四年前的 Mono 项目。 如今，它具有三种解决方案：Xamarin.iOS、Xamarin.Android 和 Xamarin.Mac。 其他平台已经默认处理 .NET 应用程序，即 Microsoft 解决方案。 简而言之，Xamarin 提供了到 .NET 中平台 API 的直接链接。 因此，您可以使用 .NET 应用程序的本机功能。 Xamarin 还有一个名为 Forms 的扩展模块，它为 UI 提供了一个抽象层。

儿子：SkiaSharp

SkiaSharp 是 Google 的 Skia 矢量图形库的 .NET 包装器。 Skia 是 Android、Chrome、ChromeOS 和 Firefox 的原生渲染引擎。 使用 SkiaSharp，您可以在您的 .NET 应用程序中使用该库来使其跨平台。 这意味着你的设计师所说的“将使你的应用程序变得更好”的简洁阴影可以只编码一次，而不是针对每个目标平台重复。 就我个人而言，我认为它的最佳功能是能够以一种方式呈现 SVG 图形，从而使您能够防止各种形式因素的重复，同时保持清晰、像素完美的渲染。

圣灵：MVVMCross

为了保持一切良好分离和松耦合，我们神圣的解决方案将依赖 MVVMCross。 这个框架实现了一个 MVVM (Model-View-ViewModel) 基础设施，这样一切都可以保持独立。 无需太技术化，应用程序通常分为三个部分：

1. 模型：我们数据的内存表示
2. 视图：我们的 UI，向用户展示数据和操作
3. ViewModel：将我们的模型绑定到我们的视图的层，反之亦然

在软件工程中，我们始终努力将视图与 ViewModel 分开，以便即使我们更改视觉表示也可以重用应用程序逻辑（在 ViewModel 中）。 MVVMCross 通过处理数据绑定并为平台抽象提供模式和工具来帮助我们实现这一目标。

最终用户关心什么

回顾一下，成功的应用程序与糟糕的应用程序有不同的区别。 一个成功的应用程序：

1. 解决了现实生活中的问题
2. 提供愉快的体验

第 1 点显然与您选择的框架无关。 因此，让我们专注于第 2 点。有三个主要方面有助于您的应用程序的乐趣：

1. 熟悉度
2. 表现
3. 独特性

熟悉度

熟悉度与易用性和快速找到应用程序有关。

换句话说，它是以系统范围内的连贯方式使用平台的不同用户界面范例。 例如，按钮位置、列表上下文操作或导航等简单的事情都有助于您的应用程序的熟悉度。

熟悉度是基于 Web 界面的 Web 应用程序或框架的主要弱点。 另一方面，Xamarin Forms 提供到供应商提供的 UI 元素的跨平台映射。

因此，您的用户将获得符合平台总体外观和感觉的体验，因此他们会直观地在您的应用程序中感到轻松自在。

表现

坦率地说，在你的营销宣传中提到“原生”毫无意义。 以 Jasonette 为例，它是“native over HTTP”。 UI 存储在 Web 服务器上……你好往返和减速，所以我们看到不一定假定原生意味着更好的性能！

因此，消除了这个神话，在查看现实生活基准时，Xamarin 成为性能方面最全面的解决方案。 Xamarin Forms 不需要更多的上下文切换，提供与本机语言应用程序相当的性能。

我的结论是，您的实现选择会减慢您的应用程序，而不是 Xamarin 与本机语言。 其他选项在性能方面明显处于劣势。

独特性

如果您想提供可能的最佳用户体验并让您的应用与众不同，那么您的设计师创建外观独特的应用的可能性也非常重要。

很多时候，独特性意味着创建自定义外观控件、动画或手势。 当它在 Xamarin 中不可用时，您可以使用 SkiaSharp（围绕 Google 的 Skia 矢量图形渲染库的包装器）并利用 Xamarin Forms 的自定义渲染器概念尽可能接近硬件，同时始终在单个代码中进行编码语言，这是其他解决方案无法提供的。

作为企业，您关心什么

此时，您很可能认为框架的选择也是一项业务决策。 除了本文范围之外的因素（例如人力资源可用性）之外，Xamarin 还可以提供很多功能，尤其是在与 MVVMCross 结合使用时。 我将详细说明您在决定中要考虑的四个方面：

1. 价格和开发成本
2. 代码重用
3. 组件可用性
4. 支持和社区

价格和开发成本

让我们解决这个问题。 自今年早些时候以来，Xamarin 对自由职业者和初创公司等小型企业免费（使用 Visual Studio 社区版）。 对于较大的组织，它“免费”附带您可能已经拥有的 Visual Studio 许可证。 Xamarin Forms、MVVMCross 和 SkiaSharp 也是免费和开源的！

正如我已经提到的，使用 Xamarin 走 .Net 路线可以让您从头到尾以单一语言开发您的应用程序。 大多数其他解决方案都要求您的程序员了解不同的语言。 以 Cordova 为例，如果您需要访问没有可用插件的供应商 API，您不仅需要精通 HTML、Javascript、CSS，还可能需要精通 Objective-C、Java 和/或 C# .

使用的语言种类繁多，需要更多的上下文切换和更多的工具来掌握，从而降低效率。 另一方面，Xamarin 是一个一体化解决方案：您可以通过 Visual Studio 在所有平台上构建、部署和调试。

尽管它与 Xamarin 没有直接关系，但您还可以通过选择 .Net 解决方案获得 C# 中的许多加快开发速度的功能。 也就是说，您将受益于 C# 4.5+ 中的强大功能，例如使用 async/await、闭包和反射的简单多线程，所有这些都已被证明可以提高效率。

代码重用

您可能已经考虑过代码重用，并且很可能您认为所有解决方案在这方面都有些等价。 对不起，伙计，但你错了！

你们当中的程序员可能想知道为什么我会建议在 Forms 中内置的 MVVM 层上使用 MVVMCross？ 好吧，这里有一点需要考虑：你真的只开发移动应用程序吗？

通过使用 MVVMCross 隔离您的应用程序逻辑并使用它提供的控制反转，您可以在移动设备上重用最大数量的代码，也可以在 Windows 和 Mac 上重用（因为 Xamarin.Mac 是您的朋友）。

它不仅可以为您节省资金，还可以提出良好的工程实践，从而降低您的代码维护成本。

组件可用性

也许你不像我，但我讨厌重新发明轮子。 因此，访问可以轻松集成到应用程序中的现有组件对于加快上市时间至关重要，而且通常同时会降低成本。

选择 Xamarin 和 MVVMCross 为您提供了两种选择现有组件的选项。 首先，越来越多的组件可用于带有或不带有 Forms 的 Xamarin。 Xamarin 在 Visual Studio 中集成了一个组件商店，您可以在其中找到常见应用程序问题的各种解决方案，并且其他公司直接销售，因此请务必在开始编写自己的组件之前进行搜索（或考虑在构建后销售这些组件）。

其次，您需要搜索 Nuget 包，因为很可能有人已经编写了代码来满足您的需求。 在这些软件包中，您会发现一个不错的跨平台 MVVMCross 插件列表，它们将解决电子邮件、GPS 或本地化等常见问题。

如果您已经使用过 C#，那么您可能拥有自己喜欢的组件。 当然，你不想让他们走，他们觉得很舒服。 请放心，您可以为现有组件创建 C# 绑定，然后像我们与 Xamarin 捆绑一样使用它们，即使在自定义渲染器的帮助下在表单中也是如此。

说到这一点，您可能想在创建自己的之前查看 Xamarin 绑定 Github 存储库。

支持和社区

最后，获得支持和示例是选择框架的一个非常重要的因素。 Xamarin 已经存在了一段时间，所以今天的社区规模相当大。

在 Google 上查找信息通常会找到相当多的答案（提示：也可以尝试搜索 monotouch 和 monodroid，Xamarin 的祖先），Xamarin 在他们的网站上提供了很多示例和出色的文档。

此外，由于 Xamarin 确实只是对供应商 API 的绑定，Apple 和 Google 的文档始终是相关的，并且会回答您的许多问题。 然后，您可以创建自己的 MVVMCross 服务来抽象共享代码中的供应商 API。

至于 Xamarin 的未来，在去年 3 月被微软收购后，我敢打赌，除了向前发展，它不会有任何进展。 自从那次销售和匹配转向免费模式以来，社区不断扩大，支持得到改善，产品甚至可能以更快的速度不断改进！

Xamarin 的未来看起来一片光明。

让我们准备开始吧。让我们准备开战吧！

我意识到我可能会用这篇文章打开一罐蠕虫。 现在不要误会我的意思，还有其他值得考虑的选择，我邀请您这样做，因为我的担忧可能与您的不同。

请记住，如果您有六周的时间表，而四个月后您仍然没有准备好应用程序，那么您就没有获胜。 这将留下两个半月的时间和大量资金来培训内部人员或雇用知识渊博的人。 在那一点上坚持构建一个“原生”应用程序可能对你的项目的命运非常不利。

Xamarin 和这些配套技术提供了您的用户所关心的和您需要的。 我希望这篇文章能帮助您对下一个移动应用程序可能选择的框架做出明智的决定。