Intel® Hardware Accelerated Execution Manager

Yuriy Loginov

0/5 (0投票)

2013年11月25日

CPOL

9分钟阅读

27317

Intel 的 HAXM 大大缩短了模拟器的启动时间，在我进行的测试中，基于 Atom x86 的模拟器的性能是其 ARM 对应产品的两倍。

引言

我正在为 Android 开发一款带有计算机 AI 组件的纸牌游戏应用程序。通常，在编写代码时，在实现功能或修复 bug 后，我喜欢运行代码以确保其按预期工作。因此，我发现自己经常将应用程序上传、安装并运行在模拟器上。此外，在进行用户界面 (UI) 更改时，我通常需要启动多个模拟器来确保 UI 在各种屏幕尺寸和分辨率上都能正常工作。由于我的 UI 主要是在代码而非 XML 中实现的，因此使用启动缓慢的模拟器会使这项任务变得相当耗时。

经过近一年的开发，我已经习惯了模拟器相对较慢的加载时间，但我一直希望它能更快。所以，当有机会查看 Intel Android 开发者中心时，我对 HAXM 感兴趣，因为它承诺可以加快模拟器的启动时间。在继续安装之前，我决定对当前设置的加载时间进行基准测试。目前我使用的是搭载 9 GB RAM 和 GeForce GTX 260 的 Intel i7 920 @ 2.67 GHz 处理器，运行 Windows 7。我的应用程序大约为 2 MB，包括所有资源。

我加载了我的项目，很快意识到我的 API 级别低于最低要求。这意味着我必须将 API 升级到 17 级。我对这一点有些担心，因为我想让我的应用程序运行在尽可能低的 API 级别，以确保它与大多数设备兼容，但经过一些考虑，我意识到如果我使用 API 来运行模拟器而不引用其任何功能，升级也不会造成任何损害。从 16 级升级到 17 级大约需要 15 分钟才能完成，我不得不重启 Eclipse 才能将 Android 虚拟设备 (AVD) 定位到新的 API。一旦升级完成，我就可以开始运行测试了。（请注意，测试结果会因您的 AVD 配置和底层硬件而异。）

测试 #1 - 启动 AVD，上传并安装应用程序

启动新设备并上传应用程序花费了 2 分钟 15 秒。仅设备启动就花费了将近 2 分钟。这可能看起来很糟糕，但我认为大多数开发人员实际上并不会每次都重新启动设备，只是上传应用程序。

测试 #2 - 在运行中的 AVD 上上传并安装应用程序

现在 AVD 已经启动并运行，我做了一个微小的代码更改，以便下次运行应用程序时强制上传。上传和安装花费了 25 秒。

测试 #3 - 以调试模式运行应用程序

对于此测试，代码未更改，我只是按 F11 启动了应用程序。我在 onCreate 方法中设置了一个断点，这是应用程序启动时加载的第一个活动。此测试耗时 8 秒，表现可观。

测试 #4 - 代码更改后以调试模式运行应用程序

在进行微小的代码更改以强制重新上传后，我使用 F11 从 Eclipse 启动了应用程序。这次在命中与上述测试相同的断点之前花费了 21 秒。我惊讶地发现这次运行比测试 #2 更快，但我猜想断点在 UI 加载之前就被命中，这可以解释更快的速度。

现在是时候设置 Intel 的 HAXM 了。我遵循了网站上的说明，发现它们相当直接。下载很快，但我发现必须在 SDK 管理器之外手动完成安装很不方便。说明提到安装文件已下载到主 SDK 目录下的 extras 目录中，但由于我很久以前就设置了 SDK，所以我不得不花时间寻找下载的文件。我发现文件位于：C:\Users\yloginov\AppData\Local\Android\android-sdk\extras\intel\Hardware_Accelerated_Execution_Manager。我完成了设置，并确保 HAXM 服务正在运行。

安装完成后，我回到 AVD 管理器，创建了一个以 Intel Atom (x86) 处理器为目标的设备。

现在我用新的 AVD 重新运行了测试。

测试 #1 - 启动 AVD，上传并安装应用程序

这次花费了 38 秒！哇。这才是我想看到的。在 log cat 输出中，我注意到一行写着“HAX 正在工作，模拟器在快速虚拟模式下运行”。我想这就是之前缺失的东西。

测试 #2 - 在运行中的 AVD 上上传并安装应用程序

这次测试耗时九秒，比之前的时间有了显著的改进。

测试 #3 - 以调试模式运行应用程序

这次大约花费了三秒钟。我按 F11，启动了秒表，看了看屏幕，就已经到了断点。

测试 #4 - 代码更改后以调试模式运行应用程序

八秒！又一次巨大的改进！

现在我正在使用 HAXM，我的模拟器运行速度飞快，这让我很高兴。总的来说，性能提升非常明显，肉眼可见。如果您需要升级 API 来运行 HAXM，我建议您谨慎操作，并在继续 HAXM 安装之前确认您的项目能够编译。最终，尽管我花了几个小时来让这一切运行起来，但我认为这是值得的！另一个值得注意的好消息是 HAXM 也在 MAC 上运行。

HAXM 的可用性

在安装 Intel 的 HAXM 之前，在模拟器上上传和安装应用程序是我开发工作流程中的一个瓶颈。我会实现一个功能，并兴奋地在模拟器上进行测试，但之后不得不等待 20 多秒才能加载。这可能看起来不长，但当您状态正佳、代码源源不断时，它真的会打击您的积极性。如果我想休息一下喝杯咖啡，我会的，我不希望我的构建工具每次编译和运行代码时都给我提供一杯咖啡。我希望能够编写一些代码，按下运行按钮，立即看到我所做的更改。Intel 的这个 HAXM 工具可以让您做到这一点。当您部署的代码出现错误，但您知道只是一个愚蠢的错误，并且只需一秒钟即可修复时，它就会大显身手。在普通模拟器上，您进行更改，然后再次等待上传。使用 HAXM，您可以跳过等待部分。对于调试源代码也是如此。如果您在以调试模式启动应用程序之间进行小的更改，您可以消除烦人的上传时间，直接进入 bug 修复。

我的应用程序在运行时通过实例化 View 来创建大量 UI 和动画，而不是在 XML 中定义它们。通常，如果您使用 XML 定义布局，您可以在 Eclipse 中看到更改，而无需启动模拟器。然而，当布局是通过编程方式创建时，情况并非如此。我选择不使用基于 XML 的视图，因为以编程方式声明的视图为您提供了更多的控制权，并且运行速度更快，因为无需解析 XML 文件。这种方法的缺点是，我每次想看看 UI 外观时都必须运行应用程序。如果您只做小的调整，例如将按钮的高度从 50 DPI 更改为 60 DPI，这会尤其令人烦恼。这开始时使我减慢了很多，但在安装 HAXM 之后，这基本上不再是问题。现在我可以随心所欲地更改布局，几乎可以立即看到更改。有一件事要注意是，不要在短时间内过于频繁地将 .apk 文件上传到模拟器。Eclipse 会显示您的项目中存在错误，即使实际上没有。我怀疑这与内存分配有关，但还没有足够的研究来确定。

与大多数 Android 开发人员一样，我担心我的应用程序在各种设备上的外观。随着发布日期的临近，这种担忧通常会增加。幸运的是，AVD 让我们无需实际拥有硬件即可预览我们的应用程序。这听起来不错，但有一个缺点：启动一个全新的模拟器需要很长时间。在我的机器上，从头开始启动一个模拟器花费了超过两分钟。通常我喜欢在所有屏幕密度上测试我的应用程序，并且最好是在同一密度下的不同分辨率上进行测试。这意味着我至少需要六个不同的模拟器，并且随着新设备的上市，这个列表会不断增长。当然，一个选择是一次性启动所有模拟器，但这需要一台拥有大量 RAM 的强大机器。这意味着我们大多数人不得不满足于只运行几个 AVD，然后关闭它们以便腾出空间给新的一组 AVD。Intel 的 HAXM 大大缩短了模拟器的启动时间，在我进行的测试中，基于 Atom x86 的模拟器比它们的 ARM 对应版本快了两倍。这是一个非常扎实的提升，不容小觑。

要安装 Intel® HAXM，请访问 Intel Android 开发者中心.

其他相关文章

要详细了解 Intel 的 Android 开发工具，请访问 Intel® Android 开发者专区。