原文链接：developer.android.com/studio/rele…

本次 Android Studio 又发布了大量的内容更新，按照惯例推荐是等两个小版本后再更新会比较稳，当然也鼓励大家尝尝鲜，本次更新推出了大量实用的功能。

另外由于国内对更新内容关注度等原因，这里调整了更新内容的顺序，Firebase Crashlytics 放到了最后。

可调节大小的模拟器

从 Android Studio Electric Eel 开始，现在可以使用一个可调节大小的模拟器，以此来支持多种屏幕尺寸上的应用测试。

在单个可调整大小的模拟器上进行测试，不仅可以帮助开发者快速测试不同界面的适配效果，还可以通过节省开启多个虚拟设备所需的资源和内存，从而提升开发体验的流畅度。

要使用可调整大小的模拟器，需要使用 Android 模拟器版本 31.1.3 或更高版本。

当应用被部署到可调整大小的模拟器时，使用模拟器工具栏中的 Display Mode 下拉菜单，可以在一组常见设备类型之间快速切换。

模拟器屏幕会自动调整大小，因此开发者可以在各种屏幕尺寸和像素密度下轻松测试应用。

视图的视觉检查

Android Studio 现在会自动运行开发者的布局，以检查在不同屏幕尺寸下以视图编写的布局是否存在视觉 lint 问题。

PS：个人觉得这个支持相对鸡肋，用过 XML 布局预览的应该都懂，可能还会产出各种 IDE 的 Errors 信息。

当开发者打开 Layout Validation 时，就可以看到所有布局以多种设备尺寸呈现。

如果有问题，它会出现在 Problems 面板中显示，该面板旨在显示设计工具中的所有问题。

设备镜像

在 Android Studio Electric Eel 现在可以通过 Running Devices 窗口实现设备镜像。

通过将设备的显示流直接传输到 Android Studio，开发者可以直接从 IDE 本身执行常见操作，例如旋转屏幕、更改音量或锁定/解锁设备。

设备镜像在 Electric Eel Canary 中会作为一项实验性功能提供，可以通过 File > Settings > Experimental（ Android Studio > Preferences > Experimental on a Mac），然后选中 Device Mirroring 旁边的框。

首先，确保 AS 已连接到设备，之后连接到的所有设备都反映在 Running Devices 窗口的选项卡中。

开发者可以通过导航到 View > Tool Windows > Running Devices 打开该窗口，当开发者将应用或测试程序部署到连接的设备时， Running Devices 窗口会自动出现并显示镜像设备。

隐私声明

如果启用了设备镜像，Android Studio 会自动为任何已连接和配对的设备启动设备镜像。

这可能会导致与命令连接的设备的信息泄露，因为 adb tcpip 镜像信息和命令是通过非加密通道传递的。

此外，Android Studio 使用非加密通道与 adb 服务器通信，因此镜像信息可能会被主机上的其他用户拦截。

AGP 升级助手升级后报告和回滚功能

AGP 升级助手现在包含升级后报告。

此报告描述已完成的步骤以及升级是否成功，如果在升级后构建或测试项目时出现问题，它还包括恢复升级助手所做的更改的操作。

对 Logcat 的更新

Android Studio Electric Eel 默认启用新版 Logcat，这样可以更方便解析、查询和跟踪日志。

这是该工具自推出以来都是 AS 里最重要的更新，因此请阅读使用 Logcat 查看日志 了解有关如何使用新功能、查询语法等更多详细信息。

桌面 Android 虚拟设备现已可用

现在开发者可以直接使用桌面 Android 虚拟设备 (AVD) 测试应用在 Chromebook 等桌面设备上的运行情况。

用户通常在大屏幕设备上与应用进行不同的交互，桌面 AVD 让你能够看到应用在类似环境中的交互行为。

以下是开发者可以测试的一些独特功能：

• 调整应用大小：通过拖动窗口边缘来调整应用的大小。
• 自由窗口管理：将应用放置在桌面屏幕的不同位置，并最小化、最大化和恢复应用窗口。
• 通知：检查从桌面系统托盘拉出时通知是否正确呈现。

要详细了解桌面 AVD 以及如何将它们整合到测试工作流程中，请参阅 ChromeOS 开发人员博客上的Android Studio 中的桌面 AVD 。

使用 Build Analyzer 检查下载影响

Build Analyzer 现在提供下载依赖项所花费时间，以及每个存储库的下载详细视图。

开发者可以使用此信息来确定意外的依赖项下载是否对构建性能产生负面影响，这在增量构建期间很重要，因为增量构建不应该每次都下载同一个 artifacts 。

具体来说，开发者可以使用这些信息来识别配置问题，例如使用动态版本的依赖导致的问题。

此外，如果看到对特定存储库的大量失败请求，则可能表明应删除该存储库或将其移至存储库配置中的较低位置。

Layout Inspector recomposition 渲染高亮

在 Android Studio Electric Eel 中，代码的 recomposition 会突出显示，以帮助开发者确定 composables 在 UI 中的哪个位置进行重组。

突出显示的部分在 Layout Inspector 的图像部分显示composables 的渐变叠加，并逐渐消失，以便开发者在 UI 中可以找到具有最高 recompositions 的位置。

如果一个 composable 的 recomposing 高于另一个可组合项，则第一个 composable 会收到更强的渐变叠加颜色。

有关详细信息，请参阅布局检查器中的 Compose 重组计数。

共享问题面板

现在开发者可以在共享问题面板中查看设计工具的所有问题，要查看工具窗口，可以通过 View > Tool Windows > Problems 打开。

实时更新 Compose 预览

从 Android Studio Electric Eel 开始，开发者可以在做出预览更改时立即看到 Compose 的更新。

也就是 @Preview 会注解告诉 Android Studio 这个composables 应该显示在这个文件的设计视图中，

你可以在代码中手动添加参数以自定义 Android Studio 呈现的方式@Preview，甚至可以多次将 @Preview 注释添加到同一函数以预览具有不同属性的 composables。

有关详细信息，请参阅 可组合预览。

Android Gradle 插件和 Android Studio 兼容性

Android Studio 构建系统基于 Gradle，而 Android Gradle 插件添加了几个特定于构建 Android 应用的功能。

下表列出了每个版本的 Android Studio 所需的 Android Gradle 插件版本:

Firebase Crashlytics 的应用质量洞察

随着 Android Studio Electric Eel 的发布，用户现在可以直接在 IDE 中查看和处理来自 Firebase Crashlytics 的 App 崩溃数据。

Android Studio 会将堆栈跟踪数据和崩溃统计信息从 Crashlytics 提取到 IDE 的 App Quality Insights 工具窗口，这样开发者就不必在浏览器和 IDE 之间来回切换，关键功能有：

• 查看代码中具有相关 Crashlytics 事件数据时会高亮显示对应的代码行。
• 查看 Top 崩溃的堆栈，击堆栈跟踪会跳转到代码中的相关行位置。
• 查看有关 Top 崩溃和非致命错误事件的摘要统计信息，可以按设备制造商和 Android 版本进行分组。
• 按问题严重性、时间和应用版本进行过滤。
• 获取打开 Crashlytics 仪表板页面的浏览器链接，其中包含有关该事件的更多详细信息。

通过 Android Studio 和 Crashlytics 的集成，开发者可以在同一个地方编写代码和解决最常见的崩溃问题。

如果你还没有使用 Crashlytics 并想了解有关其产品的更多信息，请参阅 Firebase Crashlytics。

开始

要在 Android Studio 中查看 Crashlytics 数据，首先需要在应用项目中配置有 Firebase 和 Crashlytics。

方法如下：在 Android Studio 中的 Tools > Firebase 打开 Firebase Assistant ，点击 Crashlytics，然后按照教程将 Firebase 和 Crashlytics 添加到项目，另外你可以在Firebase 的 Android 入门指南中阅读有关 Firebase 的更多信息 。

如果已将 Firebase 和 Crashlytics 添加到的应用，请在 IDE 中单击头像图标登录开发者帐户 。

登录后点击 App Quality Insights 工具窗口，就会看到 Issues、Sample Stack Trace 和 Details 面板，里面收集了来自 Crashlytics 的报告。

在 Android Studio 中查阅 Crashlytics 数据

App Quality Insights 工具窗口包含丰富的数据，可让开发者深入了解用户遇到的事件，以及可帮助开发者快速导航至这些事件来源的链接。

1. 如果项目包含多个应用模块，可以从模块下拉菜单中选择要查看的事件数据模块。

2. 使用应用 ID 下拉菜单选择要分析的应用 ID。

3. “issues” 面板显示 Crashlytics 的重要数据，并按影响重要程度进行排序。

4. Sample Stack Trace 显示有关开发者在 issues 面板中点击的事件的详细信息。

   还有受影响的设备类型、 Android 版本和事件发生时间的信息，以及指向 Firebase Crashlytics 中的事件的链接，如果你想更深入地研究并检查其他堆栈跟踪、趋势和自定义日志，这里会非常有用。

5. Details 面板按设备类型和 Android 版本细分崩溃计数，因此你可以确定哪些用户组受影响最大，它还会显示遇到崩溃的应用版本和受影响的用户数量。

6. 使用 severity 过滤器选择或取消 Fatal / Non-Fatal 事件。

7. 使用时间和应用版本过滤器来筛选某些事件子集。

除了能够从堆栈跟踪导航到代码之外，开发者还可以从代码跳转到堆栈跟踪：Android Studio 现在会突出显示与崩溃相关的代码行。

当开发者将鼠标悬停在突出显示的代码行上时，会出现一个弹出窗口，显示所涉及的事件、其频率以及受影响的设备数量。

你可以在 App Quality Insights 中点击 Open 跳转到 App Quality Insights 工具窗口中的事件详情。

要了解更多信息，请参阅 使用 App Quality Insights 分析来自 Firebase Crashlytics 的问题。

最后

本次更新的内容大概就这些，主要需要注意的是，该版本会启用全新的 Logcat ，所以熟悉新的 Logcat 操作很重要，另外模拟器和镜像可以说是最实用的更新，推荐大家尝试一下。