简短回答：因为ARM->x86指令翻译。Emulator的工作方式与虚拟机类似，虚拟机的任务是启动一个完整的操作系统，然后运行测试应用程序。ARM->x86转换可能非常耗时，对您的应用程序来说更少，但对操作系统启动时更为耗时（这与复杂性和涉及的指令数量成正比）。

一些人建议在x86模拟器上运行代码。这意味着不需要加载基于ARM的操作系统，而是加载一个在x86机器上运行速度更快的x86变体，因为不需要ARM->x86转换。然而，这并不是一个完美的解决方案：

使用NDK并带有为ARM编译的本机库（*.so）的Android应用程序将无法在x86仿真器上运行，因此此类程序将无法运行。但是，如果您达到了这一点，并开始处理NDK/本机JNI代码，那么您可能已经对仿真器了解足够了。

我建议使用OpenGL设置。我有一个双核（四线程）i3-2350M运行在它的内部GPU上，如果我使用SwiftShaders，我会获得糟糕的性能，但将其更改为“桌面原生OpenGL”（扩展控制>设置>OpenGL ES渲染器）会使其运行平稳。

如果设备无法启动，请在设备配置中使用OpenGL ES API级别设置和GPU仿真设置。

我不知道为什么，但在我2011年的英特尔处理器上，它有着天壤之别。

我注意到，如果没有连接Dalvik调试监控服务器（DDMS），仿真器启动速度会快得多。因此，如果您从Virtual Device Manager“SDK Setup.exe”启动仿真器，而Eclipse未启动，则仿真器的工作速度更快。

如果您从Eclipse:DDMS启动模拟器，那么有时模拟器非常慢，但有时速度更快。

尝试禁用防病毒软件。也许它会让模拟器更快一点。

好吧，既然有人建议将Android x86作为替代测试模拟器，我也将介绍我的最爱。这可能不是每个人的选择，但对我来说，这是完美的！

使用Bluestacks播放器。它运行Android 2.3.4，非常流畅和快速。有时它甚至比普通设备更快。唯一的缺点是，你只能在API级别10上测试应用程序，并且只能在一个屏幕大小上测试，但它非常适合测试是否正常工作。只需通过运行

adb connect 127.0.0.1 

编译后，它立即安装。考虑到我有一个相当普通的计算机硬件（双核和4GB的RAM），这非常令人印象深刻。

Emulator启动选项中描述的选项-cpu delay＜delay＞可以帮助您。