返回博客首页
← 所有文章

NativeScript 和 Xamarin

2016年7月14日 — 作者：Burke Holland

开发移动应用很难。作为一名开发者，如果您想将单个应用部署到多个平台，则必须学习不同的开发环境和语言。幸运的是，Xamarin 和 NativeScript 等框架允许开发者同时针对多个移动操作系统（即 iOS 和 Android），同时仍然使用他们已经了解的编程语言。

那么，开发者的一个大问题就变成了，“我应该选择这些产品中的哪一个？”

在 Progress 的情况下，这个问题实际上归结为我们是否建议开发者使用 Xamarin，或者我们自己的跨平台移动开发运行时，称为 NativeScript。虽然 Progress 构建并支持NativeScript，但我们也像对所有主要的 Microsoft UI 平台一样，构建了Xamarin 的 UI 组件。考虑到 Xamarin 和 NativeScript 可以被视为竞争产品，这似乎有点奇怪。一个由微软拥有；另一个由我们拥有。从逻辑上讲，我们希望开发者使用我们的框架，而不是其他公司的框架。

首先 - 我们当然希望这样。我们真正相信 NativeScript 是构建跨平台原生应用程序的最佳解决方案。

但我们也意识到，并非地球上的每个开发者都有一个正确的解决方案。Xamarin 将成为某些开发者的正确解决方案，而另一些开发者将选择 NativeScript，还有一些开发者将选择其他解决方案。为了让您、您的团队和您的项目更容易选择“正确的解决方案”，我们将分解 Xamarin 和 NativeScript 之间的区别。首先，我们将从简要描述每个项目对自己的描述开始，然后我们将深入探讨技术细节。

nativescript

NativeScript

NativeScript 是您如何在没有 Web View 的情况下构建跨平台、原生 iOS 和 Android 应用。使用 Angular、TypeScript 或现代 JavaScript 获取真正的原生 UI 和性能，同时与 Web 共享技能和代码。通过 JavaScript 获取对原生 API 的 100% 访问权限，并重用来自 NPM、CocoaPods 和 Gradle 的包。开源并由 Progress 支持。



RDXWoY7W_400x400

Xamarin

通过 C# 共享代码库，开发者可以使用 Xamarin 工具编写具有原生用户界面的原生 Android、iOS 和 Windows 应用，并在多个平台之间共享代码。截至 2015 年 5 月，全球超过 120 个国家/地区的 100 多万开发者使用 Xamarin 的产品。

Xamarin 于 2016 年 3 月被微软收购。


真正的原生与混合

NativeScript 和 Xamarin 都生成真正的原生移动应用程序。真正的原生意味着所有 UI 都由原生 UI 控件组成，并且所有底层设备 API 都可访问。

关于 NativeScript 和 Xamarin 在这方面最重要的一点是，它们不像 Cordova（PhoneGap）那样使用Web View。许多框架声称可以使用 Web 技术创建原生移动应用程序。这些框架的工作方式是利用 Cordova 项目，该项目将您的应用程序包装在一个没有 URL 栏或控件的浏览器中。然后，开发者将应用程序构建为网站，但它被打包并且在设备上看起来像一个原生应用程序，并且对原生 API 的访问权限有限。但最终，它只是一个看起来像原生应用程序的移动网站。这通常被称为“混合应用”。

what-is-hybrid

Web 应用在移动设备上的性能问题臭名昭著。这是因为移动浏览器在访问设备资源方面受到有意限制，并且与原生 API 隔离，以确保电池性能和设备安全。混合应用继承了所有这些性能问题。作为最初的混合工具提供商之一，我们艰难地了解到，构建高性能的跨平台混合应用程序仍然非常困难；尤其是在您想要获得“消费级”体验的情况下。

以下是 NativeScript Showcase 应用程序在 iOS 和 Android 上运行的情况。您可以看到复杂的动画正在发生，并且 UI 从未卡顿。这就是真正的原生移动应用程序的强大功能。

gettingstarted_ios-2 gettingstarted_android

您可以在iOS或Android上安装此应用程序，以查看它在您自己的设备上的外观和性能。

NativeScript 的工作原理

首先，让我们看看 NativeScript 如何创建用户界面或应用程序的可见部分。

作为开发者，您可以创建基于 XML 的标记文件来构建用户界面。然后，NativeScript 会解析该文件并创建相应的原生控件。以下是一个简单的表单界面

inset-form以下是用于在 NativeScript 中构建该界面的 XML

<Page xmlns="http://schemas.nativescript.org/tns.xsd">
  <StackLayout>
    <StackLayout class="form form-inset">
      <StackLayout class="form-item">
        <Label text="First Name" class="input-Label" />
        <TextField hint="First Name" class="input" />
      </StackLayout>
      <StackLayout class="hr" />
      <StackLayout class="form-item">  
        <Label text="Last Name" class="input-Label" />
          <TextField hint="Last Name" class="input" />
      </StackLayout>
    <StackLayout class="hr" />
      <StackLayout class="form-item">
        <Label text="Comments" class="input-Label" />
        <TextField hint="Comments" class="input" />
      </StackLayout>
    </StackLayout>
    <StackLayout class="padding">
      <Button text="Submit" class="button button-accent" />
    </StackLayout>
  </StackLayout>  
</Page>


所有应用程序编程都是使用 TypeScript 完成的。这意味着当控件执行事件或进行某些操作（例如 HTTP 调用）时，该逻辑将使用 TypeScript 进行编程。

每个 XML 页面都有一个同名的 TypeScript 文件，NativeScript 将查找该文件。然后，开发者可以使用绑定语法将 XML 中的控件事件绑定到同名 ts（或 js）文件中的函数。例如，如果上面的按钮在被点击时要提交 HTTP 请求，它可能看起来像这样……

main-page.xml
<Button text="Submit" class="button button-accent" tap=”{{ submitForm }}” />

main-page.js
import http from 'http';
function submitForm() {
  http.post(url, function(response) {
    // 处理来自登录服务的响应
  })
}

与使用标准 Web 浏览器时 JavaScript 可以创建、自定义和与任何浏览器 API 或 UI 元素交互的方式相同，NativeScript 使用 JavaScript 创建、自定义和与任何原生 API 或 UI 元素交互。

NativeScript 支持用于设置应用程序样式的标准 CSS 的子集。这将与为 Web 编写的 CSS 语法相同。如果您仔细查看上面表单的 XML 示例，您可能会看到 `class` 属性，就像在 HTML 中一样。以下是为上面表单示例设置样式的 CSS。

.action-bar-light {
  background-color: #ffffff;
  color: #FF404B;
}
.button {
  padding: 10 12 10 10;
  min-width: 52;
  border-radius: 2;
}
.button-accent {
  background-color: #FF404B;
  color: #ffffff;
  border-color: #FF404B;
  border-width: 1;
}
.form {
  margin: 0 0 20 0;
  padding: 0;
}
  
.form .button {
  margin: 0 0 0 10;
  padding: 0;
}
  
.form .form-item {
  padding: 10 16 10 16;
}
  
.form .input {
  padding-top: 2; }
  
.form .input-label {
  font-size: 18;
  padding: 4 0 5 0;
  color: #444;
}
.form-inset {
  margin: 10;
  border-width: 1;
  border-color: #DDDDDD;
}
textfield {
  font-size: 14;
}
.padding {
  padding: 10;
}
.hr {
  height: 1;
  background-color: #CDCDCD;
}

Xamarin

Xamarin 是一个使用 C# 和 .NET 框架构建跨平台移动应用程序的运行时。.NET 框架在 iOS 或 Android 上都不受支持。Xamarin 通过 .NET 的开源移植版本 Mono 为这些平台提供了 .NET 框架的近似实现。

Xamarin 提供两种不同的构建应用程序的方式。使用原生 Xamarin，开发人员可以在单独的项目中针对 iOS 和 Android。但是，由于许多开发人员希望使用同一个项目来针对多个操作系统，因此 Xamarin 为此目的提供了一个名为 Xamarin.Forms 的框架。Xamarin.Forms 是我们使用 UI for Xamarin 控件扩展的内容。但是请注意，来自 Telerik 的 UI for Xamarin 也适用于普通 Xamarin。

出于本文的目的，我们将只关注 Xamarin.Forms，因为该技术与 NativeScript 最密切相关，因为可以使用单个项目来针对多个平台。同样清楚的是，Xamarin 将其 Forms 功能视为 Xamarin 产品的未来。

Xamarin 的工作原理

Xamarin.Forms 解析一个基于 XML 的标记语言，通常称为 XAML。根据 XAML，大多数样式都是通过资源完成的。一些样式将是基于页面的，而另一些将是全局的。

inset-form-xamarin以下是用于在 Xamarin 中创建该简单表单的 XAML。在这个简单的示例中，我选择使用基于页面的样式。

<?xml version="1.0" encoding="utf-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:local="clr-namespace:XamarinTests" x:Class="XamarinTests.XamarinTestsPage">
  <Frame>
    <Label Text="Inset Form" TextColor="Red"></Label>
    <StackLayout HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand" Orientation="Vertical" WidthRequest="20" HeightRequest="20">
      <StackLayout Orientation="Vertical" Padding="10">
        <Label Text="First Name" />
        <Entry Placeholder="Enter Your First Name" />
      </StackLayout>
      <StackLayout Orientation="Vertical" Padding="10">
        <Label Text="Last Name" />
        <Entry Placeholder="Enter Your Last Name" />
      </StackLayout>
      <StackLayout Orientation="Vertical" Padding="10">
        <Label Text="Email" />
        <Entry Placeholder="Enter Youe Email Address" />
      </StackLayout>
      <Button Text="Submit" BackgroundColor="Red" TextColor="White"></Button>
    </StackLayout>
  </Frame>
</ContentPage>

请注意，Xamarin 示例中没有操作栏或边框。这是因为 XAML 不支持这两者。两者都需要扩展类或通过 C# 添加项目。

Xamarin 中的所有应用程序逻辑都是使用 C# 编写的，但由于它是提前编译而不是及时编译，因此对支持的内容有一些限制。例如，泛型在继承 NSObject 时仅部分支持 Xamarin。对可使用的 .NET 程序集也有一些限制。与 NativeScript 一样，Xamarin XAML 页面具有相应的 XML 文件，您可以在其中编写视图逻辑。由于 Xamarin 实现了一个完整的 MVVM（稍后解释）模型，因此以下代码可用于处理上述表单示例中的按钮点击。

MainPage.xaml
<Button text=”Submit” Command=”{{ Binding SubmitCommand }}”></Button>

MainPage.xaml.cs
class MainViewModel : INotifyPropertyChanged {
  public event PropertyChangedEventHandler PropertyChanged;
  public MainViewModel() {
    this.SubmitCommand = new Command((nothing) => {
      // 提交表单
    });
  }
  public ICommand SubmitCommand { protected set; get; }
}

 

毫不含糊的比较

现在我们已经了解了这两个不同框架的实际运作方式，让我们深入进行更细致的比较，并考虑开发周期的更多方面。

编程语言

使用 Xamarin 的开发者使用 C#。而 NativeScript 使用 TypeScript（JavaScript、CoffeeScript、Babel 等）。这是两者之间主要的区别。习惯使用 C# 和 .NET 的开发者通常会更偏好 Xamarin。那些更习惯编写 TypeScript 或 JavaScript 的开发者则会更偏好 NativeScript。

得益于 TypeScript，许多 C# 开发者开始涉足复杂的 JavaScript 应用程序。TypeScript 将原本非常松散的 JavaScript 语言转变为面向对象且强类型的语言，使开发者能够遵循最佳实践，同时利用 JavaScript 在 Web 和移动应用程序上的“随处运行”能力。


集成开发环境（IDE）

对于 Windows 用户，Xamarin 使用 Visual Studio（Windows）和 Visual Studio for Mac。

NativeScript 作为一个开源项目，更青睐跨平台的 Visual Studio Code 编辑器，但通过 Progress 提供的商业扩展 Telerik Platform 也提供了 Visual Studio 集成。从技术上讲，NativeScript CLI 允许在任何 IDE 中进行开发，包括 Atom、WebStorm、Sublime Text 2 等。

操作系统支持

Xamarin 支持构建适用于 iOS、Android、Windows Phone、Windows 通用平台和 Windows 10 的移动应用程序。

NativeScript 支持 iOS 和 Android，并且我们也 开始着手开发 Windows 10 支持。

NativeScript 对新操作系统提供零延迟支持。这意味着，在新的操作系统发布当天，NativeScript 就能支持它。这是因为 NativeScript 只是在底层原生操作系统上执行 JavaScript，并且我们的基于反射的元数据可以快速重新生成以公开新的原生 API。

Xamarin 需要发布版本才能支持新的操作系统和 API。这是因为 Xamarin 开发者必须在运行时之上为这些 API 创建映射和适配器。通常情况下，Xamarin 会在发布当天准备好此版本。

设计时体验

当我们说“设计时”时，指的是开发者实际构建应用程序的时间。

由于 NativeScript 实际上是在交付你编写的 JavaScript 代码，因此它能够在你保存文件时实时更新应用程序，而无需重新构建应用程序。我们将其称为“LiveSync”（实时同步）。

nativescript-build-cycle

每次在 Xamarin 应用程序中进行更改后，都必须完全重新构建才能在模拟器中看到反映的更改。例如，我注意到一个单词拼写错误，然后修复了错误。

xamarin-build-cycle

Xamarin 的工具中确实内置了一个可视化设计器。可视化预览是静态的。就像 NativeScript 一样，必须在设备或模拟器上测试交互性。

构建过程

NativeScript 和 Xamarin 都支持在 Windows 上构建 Android 应用程序。它们也都可以直接在 Mac 上构建 iOS 应用程序。由于 Apple 将 iOS 应用程序的构建限制在 macOS 机器上，因此 NativeScript 和 Xamarin 都无法在 Windows 上直接构建 iOS 应用程序。但是，这两个框架都提供了解决此问题的方案。

虽然可以使用 Xamarin 在 Windows 机器上编写 iOS 应用程序代码，但 Xamarin 需要 SSH 访问 macOS 机器才能实际构建 iOS 应用程序。这是无法避免的。使用 Xamarin，开发者必须能够访问 Mac 才能构建 iOS 二进制文件。

对于 NativeScript，来自 Telerik 的 AppBuilder 扩展 提供了一种云构建服务，无需开发者拥有 Mac。这本质上是我们拥有并作为服务提供给开发者的联网 Mac。然后，开发者在 Windows 机器上构建，代码在我们服务器上编译并以 IPA 格式发送回给你，准备安装到 iOS 上。

NativeScript 还提供可以从 iOS 和 Android 应用商店下载的配套应用程序。这些配套应用程序允许开发者将他们的应用程序加载到他们的设备上，而无需实际安装。这在开发过程中非常有用。

appbuilder-build-cycle

 

需要注意的是，对于 iOS，Xamarin 不会生成 Xcode 项目。NativeScript 会生成完整的 Xcode 项目，如果需要，可以在设计时完全访问原始 iOS 项目。

 

调试

Xamarin 和 NativeScript 都提供了丰富的逐步调试体验。Xamarin 通过 Visual Studio 和 Xamarin Studio 提供调试功能。Xamarin 还提供了一个 性能分析器。NativeScript 为 Visual Studio Code 提供了一个扩展，以及用于 Visual Studio 的 Telerik Platform 扩展，该扩展在 Visual Studio 内部提供了相同的逐步调试功能。

你可以观看此视频，以预览在 Visual Studio Code 中调试 NativeScript 应用程序的效果。

由于 NativeScript 实际上在构建过程中创建了完整的 iOS 和 Android 项目，因此可以使用原生 Android 和 iOS 分析工具。

速度

根据使用 Xamarin 构建应用程序的方式，性能比较会有所不同。但是，由于这两个框架都生成原生应用程序，因此性能通常为每秒约 60 帧。这意味着没有明显的性能问题。

我们衡量性能的方式远远超出了人眼所能感知的范围。在某些方面 Xamarin 更快（启动时间），而在某些方面 NativeScript 更快（GPU 使用率和内存）。

例如，以下是使用一个带有单个按钮的空白应用程序衡量启动时间的基准测试。启动时间定义为用户启动应用程序后到看到第一个屏幕之前的时间量。

平台  运行 1 运行 2  运行 3 
 原生 111 毫秒   105 毫秒  108 毫秒
 Xamarin.Forms  484 毫秒  471 毫秒 469 毫秒 
 NativeScript 674 毫秒  672 毫秒  670 毫秒 

 

在这些测试中，你可以看到 Xamarin 的启动时间比 NativeScript 快约 200 毫秒。

另一个重要的基准测试是这些框架执行“封送处理”的速度。这意味着，当你在 C# 中创建字符串或整数时，Xamarin 需要多长时间才能在底层操作系统上实际创建该字符串？NativeScript 使用 JavaScript 执行相同操作需要多长时间？我们将其称为“封送处理”。

你可以从下表看到，NativeScript 在将 JavaScript 封送处理到原生代码方面明显更快。这是 NativeScript 的核心关注点之一——成为原生代码之上最快的运行时。在这些测试中，我们测量了 NativeScript 和 Xamarin 创建和填充大型数组所需的时间。

平台 运行 1 运行 2 运行 3
原生 768 毫秒 774 毫秒 759 毫秒
NativeScript 1135 毫秒 1129 毫秒 1138 毫秒
 Xamarin 3763 毫秒 3906 毫秒 3789 毫秒

 

你可以看到，在处理大型数据集时，NativeScript 的速度大约是 Xamarin 的 3 倍。

在这篇文章的前面，我提到过，对于用户来说，性能方面最重要的因素是帧率，并且 NativeScript 和 Xamarin 通常都能保持良好的帧率。

即使电视、电脑和手机上的运动看起来很流畅，但这些设备实际上是在非常快速地连续绘制静态图像（称为帧）。人眼每秒只能处理这么多帧。在某个时刻，它将无法再看到单个帧，而是会将运动视为流畅。这发生在大约 18 帧/秒（fps）时。但是，对于 18 fps 之后每增加的 fps 数量，运动和图片都会变得更流畅、更清晰。这在 60 fps 时达到峰值。当我们能够保持恒定的 60 fps 速率时，UI 会显得非常流畅。

当原生应用程序变得复杂时，有时它们会掉帧。这意味着帧率会随着动画或处理变得激烈而波动。这会导致 UI 显得不流畅。这通常发生在长列表项滚动时。

为了测试这一点，我们构建了一个包含图像（从 Reddit 获取）的无限滚动列表项，然后在 NativeScript 和 Xamarin.Forms 上对其进行了测试。你可以看到下方列表项滚动时的帧率结果。虽然 NativeScript 始终保持接近 60 fps，但 Xamarin.Forms 则变化很大。这导致用户体验不流畅。

xamarin-vs-nativescript-fps

这突出了我们构建 NativeScript 的另一个原因：**开发者需要一个重视速度的框架**。在 Progress 长期使用混合框架后，我们希望构建一个首先要做到极速的框架。在创建 NativeScript 的过程中，所有其他目标都退居次要地位。

应用程序框架

在 Xamarin 和 NativeScript 之间需要考虑的最重要因素之一是所谓应用程序框架的存在。这些框架是为了组织代码而开发的，通过将复杂的编程任务（如路由、依赖注入和状态管理）抽象到一个通用的代码库中，使这些任务变得更容易。应用程序框架的良好示例包括 WPF 的 Caliburn.Micro 以及 Web 开发的 Angular 或 Ember。

Xamarin 提供了 MVVM 的实现。这意味着开发者可以将 UI 绑定到模型上的属性和方法，当其中一个发生更改时，另一个也会发生更改。以下是如何将简单的文本输入绑定到视图模型上的 `FirstName` 属性的示例。

类 ViewModel : INotifyPropertyChanged {
  String firstName;
  public event PropertyChangedEventHandler PropertyChanged;
  public ViewModel() {
    this.FirstName = “Jane Doe”
  }
}

<Entry text=”{Binding FirstName}”>
  <Entry.BindingContext>
    <local:ViewModel />
  </Entry.BindingContext>
</Entry>

MVVM 本身并不是一个真正的应用程序框架，而是一种绑定模式。它没有解决许多大型应用程序的关注点，例如依赖注入、组件组合、推荐的代码结构等。这就是所谓应用程序框架的用武之地。对于 Xamarin，一个这样的框架是 MVVM Light。

MVVM Light 和 MVVM Cross

Xamarin 应用程序可以利用 MVVM Light 和 MVVM Cross 框架，这些框架提供了上述必要的框架功能部件。这两个框架都是开源的，并由社区贡献者维护。

使用 MVVM Cross 或 MVVM Light 时，绑定与上述示例中的绑定基本相同。这些框架扩展了开箱即用的 MVVM 模型，以提供完整的应用程序框架。MVVM Light 更常用于原生 Xamarin 而不是 Xamarin Forms，因为 Forms 开箱即用地提供了更多必要的应用程序框架部件。做过大量 XAML 开发的开发人员可能更熟悉 MVVM Light，因为它通常与其他基于 XAML 的平台一起使用。

Angular 2

Angular 2 是 Google 开发的用于 TypeScript 应用程序的应用程序框架。Angular 也是开源的，虽然他们接受社区贡献，但大部分工作是由 Google 的专门团队完成的。

虽然 Angular 通常被认为仅适用于 Web，但 NativeScript 将 Angular 2 作为一等公民支持，我们建议开发人员在构建 NativeScript 应用程序时使用它。在 Angular 2 中实现上述示例中的相同表单功能如下所示…

import {Component} from '@angular/core';
@Component({
  selector: 'my-app',
  template: '<TextField [(ngModel)]="firstName"></TextField>'
})
export class MyApp {
  firstName: string = "Jane Doe";
}

请注意，在 Angular 2 中，没有需要继承的笨拙的接口或类。它只是一个组件注释和一个标准的类对象。Angular 的绑定几乎是神奇的，这也是它在开发人员中如此受欢迎的原因之一。

Angular 还提供了一种构建可以在页面之间共享的部分 UI 组件（指令）以及依赖注入模型（可注入对象）的方法，以及庞大的开发者社区。

使用 Angular 2 的另一个好处是它也可以在 Web 上运行。这意味着您可以在 Web 和 Angular 应用程序之间共享大量代码。我建议观看 ng-conf 演示文稿 来自 TJ VanToll 和 Jen Looper，它演示了如何在 20 分钟内完成此操作。这是多平台开发的演变，它由 Angular 2 和 NativeScript 提供支持。

插件生态系统

任何框架开发中最关键的部分之一是插件的可用性，这些插件可以扩展框架以使其执行，好吧，任何您可能想要的功能。在移动设备上，这一点尤其重要。

例如，iOS 或 Android 都不提供开箱即用的侧抽屉实现。这意味着 NativeScript 或 Xamarin 也不提供。但是，这两个框架都有一个插件模型，允许开发人员构建像侧抽屉这样的插件，然后您可以下载并在项目中使用。

NativeScript 插件

NativeScript 插件通过 npm 包交付。例如，如果我想在上述简单表单示例中添加侧抽屉，我可以安装 Telerik UI For NativeScript，其中包括侧抽屉、高级列表视图、图表等。这是从命令行完成的。

$ tns plugin add nativescript-telerik-ui

目前 有近 500 个 NativeScript 插件可用，并且这个数字每个月都在增长。这包括 Firebase、Azure、Couchbase、TouchID、音频、视频等内容的集成。

Xamarin 插件

Xamarin 和 Xamarin Forms 都有许多插件。Xamarin Forms 插件尽可能通过 NuGet 分发。目前，许多 Xamarin Forms 插件是商业化的，包括 Telerik UI for Xamarin。商业插件通常通过下载动态链接库 (DLL) 并将其手动添加到 Xamarin 项目中来安装。

Xamarin 可用插件的确切数量难以衡量，因为它们分散在 开源插件 (37)、NuGet 上提供的插件 (2341)、Xamarin 插件页面 上列出的插件 (547) 和一些未列在任何这些位置的商业插件中。

我个人在浏览 Xamarin 插件环境方面遇到了很大的困难。我在 Nuget 上找不到适用于 Xamarin.Forms 的侧抽屉。我在他们的官方插件网站上找到一个，但它被列为仅限 iOS。好消息是我知道 Telerik UI For Xamarin 有一个适用于 Xamarin.Forms 的侧抽屉组件，并附带一个 Windows 安装程序，这使得使用 Visual Studio 的组件变得相对容易。

但是我应该选择哪一个！？

作为开发人员，我们常常发现很难为解决特定问题而端到端地规定给定的技术栈——答案通常是“视情况而定”。当问题像创建本机跨平台移动应用程序一样棘手时，这种选择正确技术的犹豫就会加剧。您选择的跨平台方法应取决于应用程序的需求、您的技能、工具集、应用程序的可维护性以及最终客户的需求。为了帮助您做出这个决定，我们制作了这张方便的过度简化的流程图。

nativescript-xamarin-flow-chart

 

如果您有以下情况，则应选择 NativeScript

  • 您在 Web 技术方面有投入。您习惯于编写 TypeScript/JavaScript
  • 您已投资于 Angular 2 或您希望将现有资产从 Angular 1 迁移到 Angular 2
  • 如果您在一个完全使用 Windows 的商店中工作，则不想为 iOS 构建过程购买 Mac
  • 您更喜欢 Node 和 NPM 的开源协作世界
  • 您更喜欢庞大的 NPM 包存储库作为组件/插件的后备，而不是 NuGet。
  • 自定义字体和跨平台动画对您的应用程序很重要。
  • 您希望使用 CocoaPods 等第三方开源组件。
  • 您习惯于使用 CLI 工具。
  • 您希望在 Web 项目和移动项目之间重用代码。

如果您有以下情况，则应选择 Xamarin

  • 您更喜欢 C# 并且宁愿不涉足 TypeScript 或 JavaScript
  • 您更喜欢 NuGet 作为您选择的包管理器
  • 您没有投资于 Angular 也没有计划这样做
  • 您喜欢在 Windows 上使用功能齐全的 IDE（如 Visual Studio）或在 Mac 上使用 Xamarin Studio 的便利性。
  • 您的开发人员熟悉 XAML 和 MVVM 概念。
  • 您不介意为完善的第三方 UI 组件付费以获得现成的控件。NativeScript 也有付费的商业控件，但数量远不及 Xamarin。
  • 您不介意将 Mac 作为构建主机。
  • 您不喜欢命令行，宁愿以可视化方式执行操作。

无论您做出什么选择，我们都在这里提供帮助。如果您选择使用 Xamarin，请查看我们优质的 UI for Xamarin 控件，这极大地简化了向您的 Xamarin 应用程序添加复杂控件（如侧抽屉、复杂的可编辑列表视图、图表和图形）的过程。如果您选择使用 NativeScript，请访问 nativescript.org 并完成我们的 入门教程 之一，这将使您能够快速开始使用 NativeScript。如果您需要 NativeScript 的完善组件，请确保查看 NativeScript UI。

最终，必须在不同的技术之间做出选择是一件好事。开发人员拥有的选择越多，他们最终成功的可能性就越大，这才是最终真正重要的。

您是否觉得我们在这里遗漏了什么或在比较中不公平？请在评论中告诉我们！我们希望培养一个公开的讨论，揭示事实，您的意见是帮助我们做到这一点的最佳方式。

特别感谢许多为本文提供意见的人。这里的大多数有用见解都来自他们。