市场place
作者 NativeScript.org
多环境构建
由 cowfox 编写 | v0.8.2
在构建过程中使 Nativescript 支持多个环境的更好解决方案。
npm i --save nativescript-multiple-environments-building

多环境构建

NPM version Downloads

此钩子旨在为构建具有多个环境的 NativeScript 应用程序提供更好的支持，例如

  • 在不同环境中轻松使用不同的 App Bundle ID。
  • 快速将 package.json 中的 Version # 应用到实际目标（iOS 上的 Info.plist 和 Android 上的 AndroidManifest.xml）。
    • 使用新的 autoBuildNumber 配置，您可以在 RELEASE 模式下轻松自动生成 Version Code 并使用它。
  • 安全配置不同环境下的文件复制策略，例如
    • 使用不同的 Info.plist 或 strings.xml 设置不同的 App Name 或其他配置。
    • 为 Google 服务使用不同的 GoogleService-Info.plist。
  • 为每个环境简单地生成专门的 App 图标 图像。

感谢 federicorp，这位令人惊叹想法的原始创造者（通过 @nativescript-dev/multiple-environments），以及 jitendraP-ashutec，他帮助添加了对 iOS 和 Android 的环境规则文件的分离支持（通过 @nativescript-dev/multiple-environments）。

安装

npm i nativescript-multiple-environments-building --save-dev

如何使用？

将两个 环境规则 文件添加到项目的根文件夹中，它们将分别包含 iOS 和 Android 的配置。

  • environment-rules.ios.json - 用于 iOS。
  • environment-rules.android.json - 用于 Android。

一个示例 环境规则 文件如下所示

{
    "version": "1.6.6",
    "buildNumber": "66",
    "versionCode": "1060666",
    "autoVersionCode": true,
    "default": "staging",
    "extraPaths": [
        "environments"
    ],
    "directCopyRules": {
        "Info.plist": "App_Resources/iOS/Info.plist",
    },
    "appIconPath": "environments/app-icon/icon.png",
    "envFilesMatchRules": "staging|release",
    "environments": [
        {
            "name": "staging",
            "appBundleId": "org.nativescript.appId.staging",
            "matchRules": "(.*\\.staging\\..*)"
        },
        {
            "name": "release",
            "appBundleId": "org.nativescript.appId.release",
            "matchRules": "(.*\\.release\\..*)"
        }
    ]
}

使用它，在 {NS} 执行 prepare 过程时，使用 --env.use.ENV_NAME 指定实际环境进行处理。例如

# Debug iOS app with `staging` env. configs.
ns debug ios --env.use.staging

# Build a final release
ns run ios --bundle --env.aot --env.uglify --env.use.release

环境规则

当前 环境规则 文件支持以下配置

  • default - 如果 cmd 不包含 --env.use.ENV_NAME，则使用的默认 Env. Name。
  • extraPaths - 检查 env. 文件并需要时执行文件复制的附加路径。例如，添加 environments 将帮助为 Angular 选择正确的 environment.ts。
    • 默认情况下，它会检查 App_Resources 文件夹。而 extraPaths 将帮助覆盖其他位置。
    • extraPaths 中的路径相对于 项目根文件夹。
  • environments - 它为每个环境定义，包括
    • name - 由 --env.use.ENV_NAME 使用的 Env. Name。
    • appBundleId - 目标 App Bundle ID。
    • matchRules - 帮助找到 源环境文件 并执行文件复制的匹配规则。
      • 例如，(.*\\.staging\\..*) 将帮助定位文件 Info.staging.plist。
  • directCopyRules - 在正常文件复制 AFTER 执行的 直接复制规则。通常，它用于帮助在 iOS 上准备文件。
    • 每个 pair 包括两个部分：源文件名和目标路径（相对于 项目根文件夹）。
    • 例如：{ "Info.plist":"App_Resources/iOS/Info.plist" }表示在从其env.版本（如Info.dev.plist）复制后，将Info.plist复制到App_Resources文件夹。
    • 注意：直接文件复制仅在完成常规文件复制后发生。换句话说，如果源文件名不是常规文件复制的输出文件，则会被忽略。
  • appIconPath - 用于ns resources generate icons命令的文件路径。当应用程序在IOS上的不同环境下有不同的App Icon时，这非常有用。
    • 尽管如此，该路径是相对于项目根文件夹的。
    • 注意：在Android上，不同环境下的不同App Icon仍然可以位于App_Resources文件夹中，可以在prepare过程之后安全删除。
  • envFilesMatchRules - 用于在prepare之后识别所有可删除的env.文件的特定匹配规则。
    • 例如，如果matchRules使用单词（dev和release）来帮助识别env文件，则envFilesMatchRules的值应该是dev|release。
    • 注意：这应该是一个仅适用于Android的配置。在iOS上，它更依赖于directCopyRules配置来帮助实现目标。
    • 如果没有设置，它将使用默认值 - development|dev|edge|test|uat|beta|staging|sta|release|prod|production。
  • version - 版本号，与package.json中的版本号相同。
  • buildNumber - 每次构建应用程序时都会更改的构建号。
  • versionCode - 用于填充CFBundleVersion（在iOS上）或VersionCode（在Android上）的版本代码。
  • autoVersionCode - 用于指示是否使用内置逻辑根据版本号和构建号自动生成Version Code的标志。

讨论

directCopyRules的使用

鉴于ns prepare过程会将App_Resources/iOS文件夹内的所有文件添加到Xcode项目中，这将包括其他环境的所有env.文件，directCopyRules中的规则将有助于执行App_Resources/iOS文件夹之外的文件复制。

对于Android，由于在ns prepare过程之后仍然可以安全地删除这些env.文件，因此将删除过程简单地添加到after-prepare钩子中。

换句话说，directCopyRules可能会在iOS端使用，除非您仍然有其他针对Android的需求。

App Icon生成

App Icon的生成是通过内置的{NS}命令ns resources generate icons完成的。

默认情况下，如果icon.png文件位于App_Resources文件夹中，并且适用于iOS和Android，则该过程可以帮助为iOS和Android准备App Icon文件。然而，实际上，新的Android OS版本实际上并不使用icon.png作为App Icon。相反，它使用一个mipmap样式（通过一个xml文件来定义前景和背景）。幸运的是，新的方法仍然属于基于env.的文件复制。

ic_launcher.xml文件示例

<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@color/ic_launcher_background"/>
    <foreground android:drawable="@mipmap/ic_launcher_foreground"/>
</adaptive-icon>

注意：为了确保ns resources generate icons命令正常工作，请务必不要从App_Resources文件夹中删除默认的icon.png文件。否则，生成过程可能会失败！！！

App版本化

新增的 版本信息 相关 环境规则 文件，现在您可以以下方式管理 应用版本

  • 手动方式 - 在每次应用构建之前，将自由值输入到 环境规则 文件中的相应字段。
    • 这种方式下，将 autoVersionCode 标志设置为 false 并完全忽略 buildNumber。
  • 自动方式 - 将 autoVersionCode 设置为 true，在应用构建之前，它将根据给定的 版本号 和 构建号 的值自动生成一个新的 版本号。
    • 例如，版本号 (1.16.6) 和构建号 (22) 将生成新的 版本号 为 1160622。

关于 buildNumber，

  • 它是一个介于 0 和 99 之间的数字。
  • 当应用开始构建时，如果版本号没有改变，它会自动增加 1。
    • 如果更改，它将从 1 重置 - 这意味着“新版本的 第一次 构建”。

注意:

  • 为了使 版本号 生成过程正常工作，版本号和构建号中的 miner 和 patch 部分，不应超过 99。这个限制应该覆盖大多数情况 - 通常您可能已经增加了版本号的上部。
  • 构建号 和 版本号 的整个更新逻辑仅用于 发布 模式！！使用它，在 开发 模式下不会带来太多麻烦。
  • 在新的 Android 构建结构中，可以将“版本信息”添加到 gradle 文件中。换句话说，我们可以在 prepare 过程之前简单地更新它们。
// Example of adding "version info" to `gradle` file
android {
  defaultConfig {
    // Version Information
    versionCode 1060606
    versionName "1.6.6"
  }
}

此外，iOS 和 Android 分别管理它们的 版本信息。在正常情况下，如果您同时针对两个平台构建应用，生成的 版本号（以及 构建号）应该对每个发布都是相同的。但是，如果它不（由于某些意外原因），可以通过在 环境规则 文件中 手动 更改为正确值来非常容易地修复它。

专为 NativeScript 社区制作，充满爱心