Android Studio Iguana | 2023.2.1 发布，快来看看有什么更新吧

参考原文：https://android-developers.googleblog.com/2024/02/android-studio-iguana-is-stable.html

3月的第一天，Android Studio 又双叒叕更新啦，本次更新看起来并没有什么大突破，最大变动莫过于这个越来越放飞自我的 logo 和命令方式。

鬣蜥是什么鬼。

本次更新主要包含App Quality Insights 中的版本控制、Compose UI 检查和预览的渐进式渲染、Baseline Profiles 向导和支持 Gradle 版本目录等。

App Quality Insights 中的版本控制

现在 App Quality Insights 可以从 Crashlytics 堆栈跟踪到崩溃发生时的相关代码，AGP 会将 git commit 哈希数据附加到崩溃报告中，这样 Android Studio 就可以跳转到相关代码并显示发生问题的版本。

App Quality Insights 就是开发者可以在 Android Studio 中查看来自 Firebase Crashlytics 和 Android Vitals的应用崩溃数据，可以把堆栈跟踪数据和崩溃统计信息从 Crashlytics 和 Google Play 提取到Studio IDE 中的App Quality Insights 工具窗口。

当开发者使用 Android Gradle Plugin 8.3 或更高版本以及最新版本的 Crashlytics SDK 构建应用时，AGP 会将 git 提交信息作为发布到 Play 商店的构建工件的一部分包含在内。

开发者在 App Quality Insights中查看崩溃报告时，可以选择切换到当前 git checkout 中的代码行，或查看当前 checkout 与生成崩溃的代码库版本之间的差异。

要将版本控制系统与 App Quality Insights 集成，需要满足以下最低要求：

Android Studio Iguana
Android Gradle Plugin 8.3
Crashlytics SDK v18.3.7 或者 Firebase Android Bill of Materials v32.0.0

要对 debug 构建类型使用版本控制集成，可以在 vcsInfo 模块级构建文件中启用 include 标志，对于 release版本，默认情况下启用该标志：

android {
    
    
  buildTypes {
    
    
    debug {
    
    
      vcsInfo {
    
    
        include true
      }
    }
  }
}

现在，当开发者构建应用并发布到 Google Play 时，崩溃报告会包括 IDE 堆栈跟踪链接到应用的早期版本所需的数据。

在 App Quality Insights 中查看 Crashlytics 崩溃 variants

为了帮助开发者分析崩溃的根本原因，现在还可以使用 App Quality Insights 按 issue variants 来查看事件，或共享相似堆栈跟踪的事件组，要查看崩溃报告的每个 variant 中的事件，可以从下拉列表中选择一个 variant，要聚合所有 variant 的信息，可以选择 All。

Compose UI 检查

为了帮助开发人员在 Jetpack Compose 中构建更好的 UI，Android Studio Iguana 在 Compose Preview 中引入了新的 UI 检查模式。

UI Check mode 的工作原理类似于 View 的 Visual linting 和 Accessibility checks integrations ，当开发者激活 Compose UI 检查模式时，Android Studio 会自动审核 Compose UI ，并检查不同屏幕尺寸上的 adaptive 和 accessibility 问题：

例如大屏幕上的文本拉伸或颜色对比度低，该模式会突出显示在不同预览配置中发现的问题，并将它们列在问题面板中。

可以通过单击 Compose Preview 上的 UI Check 按钮来尝试该功能：

目前 UI 检查模式的已知问题：

问题面板中选定的问题可能会失去焦点
“Suppress rule” 会不起作用

Compose Preview 的渐进式渲染

Android Studio Iguana 在 Compose Preview 中引入了渐进式渲染，作为提高预览性能的一部分，现在对于任何不在视图中的预览，IDE 会故意降低其渲染质量以节省所用的内存。

Baseline Profiles module 向导

很多时候，第一次在设备上运行 Android 应用时，应用的启动时间可能会很慢，因为操作系统必须运行即时编译来加载某些东西，而为了改善这种情况，开发者可以创建 Baseline Profiles 来帮助 Android 改进应用的启动时间、滚动和导航速度等。

从 Android Studio Iguana 开始，开发者可以使用新模块向导（File > New > New Module）中的Baseline Profiles 生成器模板为应用生成 Baseline Profiles，该模板会将开发者的项目配置为支持 Baseline Profiles，并采用最新的 Baseline Profiles Gradle 插件，插件会通过使用单个 Gradle 命令自动执行所需任务来简化设置。

此外，模板还创建了一个运行配置，开发者只需从 “Select Run/Debug Configuration” 下拉列表中单击一下即可生成 Baseline Profiles。

Baseline Profiles 通过避免对包含的代码路径进行解释和 just-in-time (JIT) 编译步骤，将代码执行速度从首次启动时提高了约 30% 。

通过在应用或库中传送 Baseline Profiles ，Android 运行时 (ART) 可以通过提前 (AOT) 编译优化指定的代码路径，从而为每个新用户和每个应用更新提供性能增强。此配置文件引导优化 (PGO) 可让应用从首次启动起优化启动、减少交互卡顿并提高用户的整体运行时性能。

用该模板设置的项目可以更方便可以支持 Baseline Profiles，它使用新的 Baseline Profiles Gradle 插件，这个插件可以通过一项 Gradle 任务以所需的方式自动完成项目设置过程。

该模板还创建一个运行配置，只需从 Select Run/Debug Configuration 下拉列表中单击一下即可生成Baseline Profile 。

详细可见：https://developer.android.com/topic/performance/baselineprofiles/overview

使用 Espresso 设备 API 测试配置更改

当设备发生常见配置更改（例如旋转和屏幕展开）时，可以使用 Espresso 设备 API 来对应用进行测试，Espresso 设备 API 允许开发者在虚拟设备上模拟这些配置更改并同步执行测试。

这些 API 构建在 Android Emulator 34.2 中引入的新 gRPC endpoints 上，可实现安全的双向数据流和精确的传感器模拟。

要使用 Espresso 设备 API，需要满足以下条件：

Android Studio Iguana 或更高版本
Android Gradle Plulgin 8.3 或更高版本
Android 模拟器 33.1.10 或更高版本
运行 API 级别 24 或更高级别的 Android 虚拟设备

为 Espresso 设备 API 设置项目

要设置项目支持 Espresso 设备 API，可以执行以下操作：

要让测试将命令传递到测试设备，需要在 androidTest 的源码 manifest 文件添加 INTERNET 和 ACCESS_NETWORK_STATE 权限：

  <uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />

在 gradle.properties 文件中启用实验标志 enableEmulatorControl ：
```
  android.experimental.androidTest.enableEmulatorControl=true
```

在模块级构建脚本中启用 emulatorControl ：

 testOptions {
      
      
    emulatorControl {
      
      
      enable = true
    }
  }

在模块级构建脚本中，将 Espresso 设备库导入：

  dependencies {
      
      
    androidTestImplementation 'androidx.test.espresso:espresso-device:3.5.1'
  }

针对常见配置更改进行测试

Espresso 设备 API 具有多种屏幕方向和可折叠状态，可以使用它们来模拟设备配置更改。

测试屏幕旋转

首先，为了获得一致的启动状态，将设备设置为纵向模式：

  import androidx.test.espresso.device.action.ScreenOrientation
  import androidx.test.espresso.device.rules.ScreenOrientationRule
  ...
  @get:Rule
  val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)

创建一个测试，在测试执行期间将设备设置为横向：

  @Test
  fun myRotationTest() {
      
      
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    ...
  }

屏幕旋转后，检查 UI 是否按预期适应新布局：

  @Test
  fun myRotationTest() {
      
      
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
  }

测试屏幕展开

以下示例展示了如何测试在可折叠设备上且屏幕展开时会发生什么情况：

首先，通过调用 onDevice().setClosedMode() 来测试处于折叠状态的设备：

  @Test
  fun myUnfoldedTest() {
      
      
    onDevice().setClosedMode()
    composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
    composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
    ...
  }

调用 onDevice().setFlatMode()，转换到完全展开状态：

  @Test
  fun myUnfoldedTest() {
      
      
    onDevice().setClosedMode()
    ...
    onDevice().setFlatMode()
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
  }

指定需要测试的设备

如果运行的测试在不可折叠的设备上执行折叠操作，则测试通常会失败，要仅执行与正在运行的设备相关的测试，可以使用 @RequiresDeviceMode 注释。

测试运行程序会自动跳过不支持的设备，开发者可以将设备要求规则添加到每个测试或整个测试类。

例如，要指定测试只能在支持展开为平面配置的设备上运行，可以将以下 @RequiresDeviceMode 代码添加到测试中：

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
    
    
  ...
}

支持 Gradle 版本目录

Android Studio Iguana 通过增强对基于 TOML 的 Gradle 版本目录的支持，简化了依赖管理：

**集中依赖管理：**将项目的所有依赖项组织在一个文件中，以便于编辑和更新。
**节省时间的功能：**无缝代码提示、代码内的智能跳转、通过更方便的项目结构对话框快速编辑项目依赖项的能力。
**提高效率：**告别分散的依赖项和手动版本更新，版本目录为开发者提供更好管理和更高效的开发工作流程。

新建的项目将自动使用版本目录进行依赖管理，如果已经有现有项目，可以参考 https://developer.android.com/build/migrate-to-catalogs 来进行迁移。

创建版本目录文件

首先创建一个版本目录文件，在根项目的 gradle 文件夹中，创建一个名为 libs.versions.toml 的文件，Gradle 默认会在 libs.versions.toml 文件中查找目录，因此建议使用此默认名称。

注意：你可以更改目录文件名；但是这需要更改 build 文件，因此不建议这样做。

在 libs.versions.toml 文件中添加以下内容：

[versions]

[libraries]

[plugins]

这些部分内容的使用方式如下：

在 versions 代码块中，定义用于保存依赖项和插件版本的变量，可以在后续代码块（libraries 和 plugins 代码块）中使用这些变量。
在 libraries 代码块中，定义依赖项
在 plugins 代码块中，定义插件

迁移步骤

迁移过程如下：

将新条目添加到目录。
同步 Android 项目。
将以前的字符串声明替换为目录类型安全访问。

迁移依赖项

在 libs.versions.toml 文件的 versions 和 libraries 部分，为每个依赖项添加一个条目，同步项目，然后将 build 文件中的声明替换为相应的目录名称。

dependencies {
    
    
    implementation 'androidx.core:core-ktx:1.9.0'

}

[versions]
ktx = "1.9.0"

[libraries]
androidx-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "ktx" }

在为目录中的依赖项块命名时建议采用 kebab case（例如 androidx-ktx），以便在 build 文件中获得更好的代码补全帮助，然后按照在 TOML 文件中定义的名称定义依赖项：

dependencies {
    
    
   implementation libs.androidx.ktx
}

迁移插件

在 libs.versions.toml 文件的版本和插件部分，为每个插件添加一个条目，同步项目然后将 build 文件中 plugins{} 代码块内的声明替换为相应的目录名称：

// Top-level `build.gradle` file
plugins {
    
    
   id 'com.android.application' version '7.4.1' apply false

}

// Module-level `build.gradle` file
plugins {
    
    
   id 'com.android.application'

}

[versions]
androidGradlePlugin = "7.4.1"

[plugins]
android-application = { id = "com.android.application", version.ref = "androidGradlePlugin" }

与依赖项一样，对于 plugins 代码块目录条目，建议使用 kebab case（例如 android-application）格式。

以下代码展示了如何在顶级和模块级 build.gradle.kts 文件中定义 com.android.application 插件，对于来自版本目录文件的插件可以使用 alias，对于并非来自版本目录文件的插件使用 id：

// Top-level build.gradle
plugins {
    
    
   alias libs.plugins.android.application apply false

}

// module build.gradle
plugins {
    
    
   alias libs.plugins.android.application

}

注意：如果使用的是低于 8.1 的 Gradle 版本，则需要在使用版本目录时为 plugins{} 代码块添加注解 (@Suppress("DSL_SCOPE_VIOLATION"))

最后

最后，下图是目前 Android Gradle plugin 和 Android Studio 版本兼容要求，还有 Android Studio 和 AGP 的最低版本支持特定的 API 级别，使用低于项 Android Studio 或 AGP 版本要求的 targetSdk 和 compileSdk 可能会有一些意想不到的坑存在。

Android Studio Iguana 现在会明确警告开发者如果你的依赖 API 太老，如果项目的预期 compileSdk 太高，它还会建议迁移到支持项目使用的 compileSdk 的 Android Studio 版本，另外还可能建议你升级 AGP。