返回博客首页
← 所有文章

构建 NativeScript 应用的未来

2019 年 5 月 13 日 — 作者 Rosen Vladimirov

我们正在积极开发 NativeScript 6.0，现在是回顾过去所做工作并分享下一版本计划的绝佳时机。作为 NativeScript CLI 团队的一员，我想谈谈我们关于改进开发工作流程和构建 NativeScript 应用程序方式的想法。

NativeScript CLI 简史

从 NativeScript 的第一天起，我们就希望提供最好的开发工作流程——快速可靠的构建、LiveSync 功能，允许您几乎立即在设备上看到更改等。当时，我们使用的是 Node.js 0.10、Xcode 5，Android 构建使用的是 ant，Angular 2 还只是一个梦想，Vue.js 也还没有稳定的版本。

在那个时候，我们必须创建一个过程来构建原生移动应用程序，并将项目的 JavaScript 文件包含在其中。

我不会详细介绍整个过程，但这里是一个高级概述

当您创建一个应用程序时，您会得到一个包含 JavaScript/TypeScript 文件（通常命名为 app 或 src）、package.json、node_modules 和几个其他配置文件的目录。当我们为其中一个平台（例如 Android 或 iOS）构建应用程序时，我们需要准备一个实际的原生 Gradle/Xcode 项目，才能构建可以安装在设备上的二进制文件。您想要使用的所有 JavaScript 都必须包含在这个原生项目中，这样当您在设备上运行应用程序时，它就可以找到这些文件并实际执行它们。

在项目准备期间，NativeScript CLI 将您的项目文件（来自 app/src 目录的那些文件）复制到原生项目中。正如您所知，我们还需要复制 node_modules，因此 CLI 会将您项目的所有依赖项及其依赖项及其依赖项等等复制到原生项目中。将所有 JavaScript 文件复制到原生项目后，CLI 会处理它们以替换平台特定的文件（例如，在为 Android 构建时，任何名为 app.android.js 的文件都将被重命名为 app.js）。

有关如何在您的应用程序中使用平台特定文件的更多信息，请参见 这篇博文。

过去，我们不得不处理 iOS 和 Android 工具的新版本，为原生项目的不同配置添加支持，但准备 JavaScript 文件的过程几乎与我们很久以前创建的过程相同。

然而，最近我们一直在研究一种构建 NativeScript 应用程序的替代方法……或者至少是需要包含在应用程序中的 JavaScript 文件。我们称之为 bundle workflow。这是 CLI 在您传递 --bundle 标志时构建应用程序的方式。

"no-bundle" 工作流的问题 ❌

好吧，事实证明我们的实现有一些限制，这些限制会影响应用程序构建、LiveSync 过程（LiveSync 是将您在项目中所做的任何更改自动上传到连接的设备的过程，例如 tns run 命令），甚至运行时的性能。

这里只是一些问题

  • 每个应用程序文件都包含在构建过程中 - 无论它在运行时是否被使用，所有 JavaScript 文件都包含在原生应用程序中。这意味着您的应用程序大小比需要的要大得多，因为所有 node_modules（不包括 devDependencies）都包含在构建中。
  • 构建时间慢 - 所有 JavaScript 文件都用作原生项目中的 assets。原生构建系统 (Xcode/Gradle) 只是没有为处理如此多的资产而设计。想象一下这些资产中包含所有 node_modules 的文件数量。不久前我读到 PlayStore 中资产最多的 Android 应用程序大约有上千个文件。在我们这里，一个简单的 hello world 应用程序就有上千个文件。Xcode 和 Gradle 是强大的工具，但正如我所说，它们不是为了处理大量资产而设计的，因此随着您在代码中添加的每个包，构建应用程序变得越来越慢。
  • 应用程序启动速度慢得多 - 由于启动时必须要求许多文件，因此应用程序启动速度慢得多。每次 require 都是一个 I/O 操作，它使用的是 编组机制，这使得它们速度更慢。
  • NativeScript CLI 在更改应用程序中的 JavaScript 文件时会从头开始重新启动应用程序 (在 tns run 期间) - 即使您更改了未使用的文件，应用程序也会重新启动。
  • 应用程序状态未保留 - 例如，如果您深入五个页面并更改 JavaScript 文件，则需要重新导航到该页面才能看到更改。
  • 无法使用 V8 快照 - V8 快照是一种加速应用程序加载的强大方法，但您只能快照单个文件。在目前的方法中，我们有数千个文件，因此我们无法使用快照。

"bundle" 工作流如何解决这些问题 ✔️

当您传递 --bundle 时，NativeScript CLI 在后台使用 webpack。webpack 等工具显着改善了开发人员体验，这就是捆绑在移动应用程序优化中占据重要地位的原因。

Webpack 本身用于 Angular 和 Vue.js，因此尝试一下并提供 NativeScript 与这些框架之间更好的集成很有意义。在过去一年半的时间里，我们付出了很多努力将 webpack 集成到我们的构建过程中，因为它似乎解决了前面列出的所有问题

  • 每个应用程序文件都包含在构建过程中 - webpack 使用“树摇”机制，只包含代码中实际使用的文件。
  • 构建时间慢 - 使用 webpack，包含在原生构建中的生成的 JavaScript 文件只有几个，在大多数情况下只有五个或六个。原生构建工具可以轻松地处理这种情况，因此构建过程快得多。
  • 应用程序启动速度慢得多 - 使用 webpack，应用程序启动时需要的文件只有几个，因此应用程序启动速度快得多。
  • NativeScript CLI 在更改应用程序中的 JavaScript 文件时会从头开始重新启动应用程序 - webpack 有 热模块替换 的概念，它解决了这个问题，并允许您替换模块而不重新启动应用程序。
  • 应用程序状态未保留 - 在另一种工作流程中，当更改 JavaScript 文件时，应用程序会重新启动。由于热模块替换，我们能够替换已更改的模块，并确保应用程序导航和状态得到保留。
  • 无法使用 V8 快照 - 使用 webpack，只生成几个文件，并且所有 node_modules 都可以快照，这使得应用程序速度更快。

webpack report

改进 NativeScript 5.x 中的开发工作流程

在最近的几个版本中，该团队一直致力于提供出色的开发体验。如上所述，使用 bundle workflow（特别是 webpack）时，我们能够解决上面列出的大多数问题。但是，在过去的几个版本中，我们能够将 bundle workflow 推到我们从未想象过的水平。只需观看这个视频，演示默认工作流程和 webpack 工作流程之间的区别


NativeScript 5.0 更改

我们很高兴宣布 热模块替换的 Beta 支持。能够更改 JavaScript 文件并在不到一秒钟的时间内在设备上看到更改是一个巨大的胜利。

NativeScript 5.3 更改

我们引入了 对热模块替换的正式支持。此外，我们提供了一种方法，通过在 nsconfig.json 文件中将 useLegacyWorkflow 设置为 false 来默认启用 HMR 开发体验。更多信息可以在 文档 中找到。

NativeScript 5.4 更改

目前，bundle workflow 为您提供了最佳体验，因此我们希望确保我们的用户默认使用它。我们计划在新的项目中开箱即用地引入 HMR 开发体验。换句话说，tns create 将自动在 nsconfig.json 文件中将 useLegacyWorkflow 设置为 false。 开发人员无需执行任何其他操作即可启用 bundle 工作流程。

对于您所有旧的项目，CLI 会提示您使用 bundle workflow。我们强烈建议您开始使用它，如果您遇到任何问题，请在 NativeScript CLI 的存储库 中报告。

注意：如果您目前没有使用 bundle workflow，则可以执行 tns update --workflow 以使您的项目与 bundle workflow 兼容。

支持两种构建工作流的问题

如上所述，我们目前支持两种不同的构建/开发工作流程。它们各自都有自己的特定行为，这使得我们很难覆盖所有场景。请考虑以下表格，它说明了我们的 QA 在测试发布版本时发现的问题（绿色表示正在运行，红色表示未按预期运行的命令）

tns workflows

我们有很多自动化测试，但是使用两个不同的工作流程为两个不同的平台 (Android 和 iOS) 修复和支持所有这些命令对我们来说变得非常困难。因此，我们一直在考虑如何为我们的用户提供最好的体验，并减少支持的场景，即我们希望拥有一个很棒的工作流程，而不是几个很酷的工作流程。

准备 NativeScript CLI 6.0 版本

基于上述所有内容，我们已决定从 6.0 版本开始，NativeScript CLI 将只支持我们的 bundle workflow。我们希望专注于使其成为 NativeScript 的最佳体验。仅支持 bundle workflow 将使我们能够从 NativeScript CLI 的代码中清除许多肮脏的 hack。

我们还将删除几个开发插件 nativescript-dev-sass、nativescript-dev-typescript、nativescript-dev-less 等，因为 webpack 已经有了处理此类文件的方法。

所有这些将使我们能够开始处理我们目前无法处理的其他高度需求的功能，例如

  • Visual Studio Code 扩展中的 Intellisense 支持
  • 通过 Wi-fi 进行 LiveSync
  • 可靠的单元测试和 e2e 测试故事
  • 改进本地环境的自动设置

这对您和您的应用程序意味着什么

如果您目前正在使用 bundle workflow，那么您的工作流程将不会有任何变化！

如果没有，我们强烈建议您开始使用它，因为在 NativeScript 6.0 版本中，将没有其他方法来构建和运行您的应用程序。bundle workflow提供了最佳的开发和生产体验，因此我们鼓励您尽快开始使用它，并在遇到任何问题时告知我们。

您能提供帮助的方式

像往常一样，您的反馈至关重要，所以请告诉我们您的想法 - 也许我们遗漏了什么，也许您知道一些关于webpack的问题，阻止您使用它 - 只需创建一个新问题，我们会与您一起调查它！