Xamarin 与 Ionic：移动端、跨平台、大对决

是否曾面临需要在相互竞争的框架之间做出选择，需要做出一个您/您的客户不会后悔的决定？如果这些框架是用于构建跨平台移动应用，并且是 Xamarin 和 Ionic，那么希望本文能有所帮助。

背景是我最近有幸在两个连续的项目中使用了这些相互竞争的框架。项目 #1 使用了 Xamarin（更具体地说是 Xamarin Forms），这是基于 C# 的框架，用于构建完全原生、跨平台的应用。

项目 #2 使用了 Ionic，这是一个基于 Angular.js、Cordova/PhoneGap、HTML 和 JavaScript 的框架，用于构建看起来和行为都像原生应用，但实际上在嵌入式浏览器中运行的应用。

如果我必须推荐一个，我会考虑客户的预算、期望的最终产品和时间表。我会考虑开发速度、上手时间以及可维护性。基本上，我将根据以下六个标准进行评估。

1. 价格：Ionic++

最明显的框架区别就是价格。Ionic 免费的价格标签似乎是显而易见的。然而，Xamarin 每开发者每年 1000 美元的价格对于大多数公司来说是可以接受的，特别是如果有一个足够有说服力的理由的话。两个非常有说服力的理由是：

• 我们只有 .NET 开发人员；以及
• 我们的架构已经完全是 .NET 了

如果这些要点适用于您，那么价格很可能是有道理的，Xamarin 的选择也很明显。然而，如果您拥有混合的人才和技术，那么免费是很难被超越的。

更新：自 2016 年 3 月 18 日起 Xamarin 已免费。请忽略此区别点。所有剩余的点（最终产品、开发速度、可维护性）在 2017 年 3 月仍然有效。

2. 最终产品：Xamarin++

您的客户将无法准确说出为什么他们更喜欢竞争对手的原生应用，但您最终更有可能输掉。

意外：一个基于 HTML 的应用程序，无论外观如何精美，永远无法像原生应用程序那样看起来、感觉和运行。

Ionic 的外观和感觉有多大的不同？如果您坚持使用默认控件并且不进行过度定制，我保证您的用户不会注意到。然而，当面临选择时，您的客户将无法准确说出为什么他们更喜欢竞争对手的原生应用，但您最终更有可能输掉。

我们很幸运有一位全职设计专业人士为 Ionic 项目提供协助，而他的一些（相当耗时的）建议如果当初选择了 Xamarin 将不会成为问题。此外，UI 总是感觉有点卡顿，即使理论上使用了 GPU 加速 的 CSS3 过渡。

简单来说，如果您想要为用户提供最好、最快、最真实的原生体验，Xamarin 是明确的赢家。

3. 开发速度：Ionic++

如果您需要尽快交付一个应用程序，Ionic 是您的朋友。

两种框架的开发速度在两个主要方面存在差异。首先是从编写一行代码到看到结果所需的时间。对于 Xamarin，将代码推送到 iOS 设备需要几秒钟的编译加上 10 到 15 秒的部署时间。哎哟。

相比之下，Ionic 使用 Ripple 模拟器 提供了零编译、亚秒级的反馈时间。这个功能本身就显著提高了开发速度。也许更重要的是，快速的反馈周期实际上让编码变得更有趣。

第二个开发速度差异在于 UI 调试。Ripple 加上Chrome 工具使得在 Ionic 中调试 UI 变得异常简单。而使用 Xamarin，您只能非常有限地弄清楚运行时某个元素为何会出现在那个位置，更不用说调整它的属性了。简而言之，Ripple + Chrome 工具使得 Ionic 中的 UI 工作显著更容易。

总的来说，Ionic 提供了更出色的开发体验。如果您需要尽快交付一个应用程序，Ionic 是您的朋友。

4. 可维护性：Xamarin++

这是我要批评 JavaScript 的地方，对吗？好吧，在开始之前，我必须承认我一开始就做出了三个架构决策，这些决策使得处理 JavaScript 应用程序对我这样背景的人来说更容易接受，并且，嗯，坦率地说，有偏见。

TypeScript

尽管我欣赏 JavaScript，但我更看重重构、出色的 IDE 体验以及编译器提供的免费单元测试。TypeScript 重新带来了所有这些优点，并因此有可能处理大型代码库和/或更大、更多样化的团队。没有 TypeScript，我个人无法推荐 Ionic 用于任何超出相当简单或单人移动应用范围的项目。

Visual Studio + ReSharper

您以为 Visual Studio 和 ReSharper 只用于 .NET 应用？错了，它们在 Bower 和 NPM 包管理、代码导航、重构以及出色的静态分析方面给予了我们巨大的帮助，再加上您期望从 .NET 应用获得的完整的、出色的调试体验。微软以提供一个出色的 IDE 来支持一个历史上非微软的技术栈，彻底地让我们感到惊喜（敢说惊喜吗？）。

Wallaby.js

我们的应用程序有一个相当复杂的核心引擎，以及大量的单元测试。 Wallaby 允许我们在输入时、甚至在保存之前持续运行我们的单元测试。团队中的每个人都能立即知道他们是否破坏了某个测试，并将代码覆盖率放在每个人的首位。Karma 也可以，但我认为 Wallaby 使完全使用 JavaScript/TypeScript 变得愉快。

总体可维护性

虽然这三个决策使我们的 JavaScript 应用程序更具可维护性、可重构性，并且不易产生技术债务；但 Xamarin 仍然感觉更易于维护。Angular 在魔法字符串方面非常依赖，这是无法避免的。我和我的同事们在修改彼此的代码或重构现有代码时，当我们有一个真正的编译器检查我们 95% 的工作时，我们感到产生晦涩错误的恐惧感要小得多。

5. 单元测试体验：矛盾

一个好的框架需要出色的单元测试体验，如果您想将质量融入您的应用程序。不幸的是，尽管 Wallaby 非常棒，即使使用了 Karma，我也无法弄清楚如何在单元测试中设置断点调试和检查变量。另一方面，在 Xamarin 中，单元测试是一等公民。它简单而强大，并且配合 nCrunch，反馈速度几乎和 Wallaby 一样快。

为什么矛盾？因为我喜欢这个

// describe + it blocks offers a hard to match level of expressiveness
describe('when you calculate dimension effects for a question', () => {
  // notice this generic helper function relevant to most/all of the tests
  var makeDimensionEffects = () => { ... };
 
  // nested describe -> I LOVE THIS
 describe('with a transformation', () => {
    // this 2nd helper is relevant to only nested tests
    var makeQuestionWithTransformation =  = () => { ... };
 
   it('should error gracefully if blah blah blah', () => {
     expect('actual').toBe('expected');
   });
 });
 
});

即使有了 SpecFlow，而我又是 SpecFlow 的忠实粉丝，.NET 在提供相同的强大功能、灵活性和表现力方面仍然有所欠缺。

6. 上手时间：Xamarin++

上手时间的长短显然取决于您的背景。然而，使用 Xamarin 更容易陷入“成功陷阱”。从架构上讲，我们在 Ionic 中犯了一系列错误，这些错误后来给我们带来了很多麻烦（注意到我什么时候开始用第三人称谈论发生的不好的事情，很狡猾，对吧？）。这些错误主要表现为糟糕的内存管理，尽管我们还搞砸了我们的 ngCache 数据结构，导致在负载下性能不佳。

现在有人可能会争辩说，使用任何新框架都容易搞砸内存管理。然而，在 Ionic 所基于的 Angular 中，似乎特别容易产生内存泄漏。当我们完成了最小可行产品 (MVP) 并意识到我们实现了所有反模式时，我们遇到了一个真正的混乱需要从中恢复。

相反，我们的 Xamarin MVP 只有一个主要的内存问题，并且我们毫无问题地解决了它。显然，如果您团队中有任何具有 Angular 经验的人，这可以减轻这种担忧，但如果没有，并且您正在选择 Ionic，请做好心理准备。

摘要

那么，如果我今天必须推荐一个框架呢？显然，安全（也是正确的）答案是：取决于。它取决于团队、现有架构、谁来维护应用程序、预算和时间表，以及一系列其他问题。

然而，为了挑衅一下，我将避免给出安全答案。

对我而言：我重视质量高于速度。仅仅因为您可以使用免费工具（#1）构建东西，并且做得更快、更快乐（#3）；这都不能替代构建一个真实、顶级、响应迅速的移动 UI（#2），在一个干净、可重构的代码库（#4）上，它将在发布时准备好进入市场（#6）。

但也许上市时间对您来说更重要。每个情况都不同。希望这有助于阐明哪种决定对您来说是正确的。

CodeProject