How Do Mobile Emulators Even?
by Jen Looper
Every mobile developer’s professional life is dominated by those little moments where fingers hover over the keyboard while the developer waits patiently for a window to appear on the screen containing a version of the mobile app over which he or she has been laboring. Over the course of a day, these individual, hopeful pauses will culminate in a series of sighs of relief (or alternately, curses) as the mobile emulator does its job.
A great emulator is critical to the creation of a great mobile app. But what are emulators, even, within a mobile context? How do they work? Why are some better than others? Why are Android and iOS emulators so different? And what’s the difference between a simulator and an emulator? Let’s take a look.
To get a better idea of the difference, I went straight to Telerik engineering – always a good solution when in doubt. Principal Front-End Developer Kamen Bundev explained not only the difference, but gave a short history:
“An Emulator is a version of the OS compiled for the desktop CPU, running in a Virtual Machine. In the early days of Android, the OS was not even compiled for x86 and the Virtual Machine was emulating the whole ARM CPU architecture, thus it was tens of times slower. Now, both Apple and Google provide x86 VM images, so the VM, if the CPU supports this, directly passes most of the calls to the underlying CPU and GPU, thereby emulating the platform much faster.”
Since an Emulator is a full OS virtual machine, our app needs to be deployed on it as on a real device, meaning an emulator takes more time to deploy than a simulator.
The eternal tradeoff between using a simulator versus an emulator, then, is one of speed versus accuracy. A simulator is only an approximation of a mobile device. An emulator is more full-featured – it may include the ability to leverage the hardware of a mobile device from within the emulator. Meanwhile, a simulator is often simply a shell – your app runs on your computer as a local program that is nested in a frame showing how it will look on various devices.
Sometimes a simulator is almost enough for the purposes of some mobile apps (such as ebooks, 2D games, basic line of business or educational apps). One of my earlier experiences with production mobile development, in fact, was with the very nice Corona SDK simulator which provided an extremely fast way to get a rough snapshot of an app in development, content-scaled for many different devices:
A simulator, however, will only get you so far in your quest to get your app into a production environment and onto clients’ devices.
In addition, by presenting the simulator within a web page, the user can leverage the built-in developer tools such as those offered by Chrome or Safari to inspect the code and detect problems in the console.
Other frameworks that produce hybrid mobile apps have similarly solid simulator options, running as small browser windows. Ionic and Telerik AppBuilder (pictured above) are good examples. Mobile apps built with web technologies are probably the easiest to simulate.
Full-featured IDEs, as well, might offer built-in simulators and emulators that ease the mobile developer’s workflow. An excellent example is Visual Studio’s well-known emulator which is also available as a plugin for other IDEs such as Eclipse. Another good example is AppBuilder’s Desktop Client simulator which is built in and available to and available to LiveSync after you save:
What about non hybrid mobile apps, those that don’t run from within a Web View? How can the developer efficiently emulate an app without running it on device?
Given that we are so heavily dependent on native emulators if we are building apps using these JavaScript Native tools, our lives are heavily impacted by sub-par native emulators. For the Mac-owning developer armed with an installation of Xcode, the Xcode simulator is a perfectly acceptable, reasonably fast way to get an accurate view of an app in progress.
The Xcode simulator is engineered as a Mac app that runs binaries specially built for it. You can use it to test almost all of the functionality expected of an app on a device. Notable exceptions include hardware-specific elements that can’t be tested on a Mac, such as the iPhone accelerometer and GPS capabilities.
Xamarin, for example, uses the native Xcode simulator and makes available the native Android Emulator, warning that it’s very slow, offering tips to speed it up, and pleading for patience:
“The emulator takes a while to launch, so you may consider leaving it running after it starts up. You don’t need to shut down the emulator to re-deploy your app… The runtime installation may take a few moments, so please be patient.”
They have also rolled their own Android emulator called the Xamarin Player.
Some Titanium developers wrote an excellent blogpost discussing how to leverage Intel’s closed-source HAXM (Hardware Accelerated Execution Manager) as an alternative to KVM for machine emulation. HAXM makes it all a little better.
Some developers, however, have turned to entirely different Android emulators for app testing; I personally prefer Genymotion (shown below), which is based on the VirtualBox emulator.
A great emulator is critical to the creation of a great mobile app. But what are emulators, even, within a mobile context? How do they work? Why are some better than others? Why are Android and iOS emulators so different? And what’s the difference between a simulator and an emulator? Let’s take a look.
Simulators and Emulators
Let’s first address the confusion between the two. An emulator is software that imitates “a machine executing binary code, while ‘simulation’ often refers to computer simulation” (wikipedia). The word “emulator” was coined in 1963 at IBM, where engineers developed products using a “new combination of software, microcode, and hardware”. If an emulator is more like a virtual machine, a simulator, on the other hand, is simply software that simulates that machine.To get a better idea of the difference, I went straight to Telerik engineering – always a good solution when in doubt. Principal Front-End Developer Kamen Bundev explained not only the difference, but gave a short history:
“An Emulator is a version of the OS compiled for the desktop CPU, running in a Virtual Machine. In the early days of Android, the OS was not even compiled for x86 and the Virtual Machine was emulating the whole ARM CPU architecture, thus it was tens of times slower. Now, both Apple and Google provide x86 VM images, so the VM, if the CPU supports this, directly passes most of the calls to the underlying CPU and GPU, thereby emulating the platform much faster.”
Since an Emulator is a full OS virtual machine, our app needs to be deployed on it as on a real device, meaning an emulator takes more time to deploy than a simulator.
The eternal tradeoff between using a simulator versus an emulator, then, is one of speed versus accuracy. A simulator is only an approximation of a mobile device. An emulator is more full-featured – it may include the ability to leverage the hardware of a mobile device from within the emulator. Meanwhile, a simulator is often simply a shell – your app runs on your computer as a local program that is nested in a frame showing how it will look on various devices.
Sometimes a simulator is almost enough for the purposes of some mobile apps (such as ebooks, 2D games, basic line of business or educational apps). One of my earlier experiences with production mobile development, in fact, was with the very nice Corona SDK simulator which provided an extremely fast way to get a rough snapshot of an app in development, content-scaled for many different devices:
A simulator, however, will only get you so far in your quest to get your app into a production environment and onto clients’ devices.
The Right Tools
Not all simulators are created equal. Each framework’s engineers tend to either custom-build the simulator that suits it best or leverage native emulators to allow off-device testing. Cordova-based hybrid mobile apps which run in web views are particularly well-suited to be tested in custom simulators such as the web-based simulator embedded into the Telerik Platform. Here, the app simply runs in an iframe injected with a Cordova core and some of its core plugins mocked to enable simulating their real functionality. The simulator even includes tools to simulate hardware tooling such as setting location:In addition, by presenting the simulator within a web page, the user can leverage the built-in developer tools such as those offered by Chrome or Safari to inspect the code and detect problems in the console.
Other frameworks that produce hybrid mobile apps have similarly solid simulator options, running as small browser windows. Ionic and Telerik AppBuilder (pictured above) are good examples. Mobile apps built with web technologies are probably the easiest to simulate.
Full-featured IDEs, as well, might offer built-in simulators and emulators that ease the mobile developer’s workflow. An excellent example is Visual Studio’s well-known emulator which is also available as a plugin for other IDEs such as Eclipse. Another good example is AppBuilder’s Desktop Client simulator which is built in and available to and available to LiveSync after you save:
What about non hybrid mobile apps, those that don’t run from within a Web View? How can the developer efficiently emulate an app without running it on device?
The iOS Garden
The new “Javascript Native” toolchains, runtimes and frameworks available to developers – including Titanium, React Native, Fuse, and NativeScript – have pushed the boundaries of the speed that a developer can reasonably expect of an emulator. These tools “utilize a JavaScript virtual machine to interpret JavaScript code, and…translate that code into the native APIs that build the app’s user interface.” The built app is ready to emulate in a native emulator, and developing from a CLI, such as NativeScript’s, leverages these native emulators when the developer builds using commands such astns emulate ios or tns livesync ios --watch.Given that we are so heavily dependent on native emulators if we are building apps using these JavaScript Native tools, our lives are heavily impacted by sub-par native emulators. For the Mac-owning developer armed with an installation of Xcode, the Xcode simulator is a perfectly acceptable, reasonably fast way to get an accurate view of an app in progress.
The Xcode simulator is engineered as a Mac app that runs binaries specially built for it. You can use it to test almost all of the functionality expected of an app on a device. Notable exceptions include hardware-specific elements that can’t be tested on a Mac, such as the iPhone accelerometer and GPS capabilities.
At its core, Xcode takes your code when you build it for use on the Xcode simulator and compiles it to create an .ipa file to be run on a i386 processor since the app is designed to run on MacOSX, iPhone/iPad/iPod emulators are i386. Thus code running on the simulator is built for i386, not ARM which is what is needed to run on a device. Bottom line, the Xcode simulator is designed to act like an iPhone but run on a Mac, and thus can never truly match an iPhone experience, although it can come very close.
The Android Swamp
On Android, however, the waters are considerably muddied. Why is it that there are so many varying Android emulators, such that this wheel continually needs reinventing? Unlike the Xcode simulator, which does not include any attempt to emulate an ARM processor, Android emulators have gone a different route, using an ironically-named (but Open Source) “Quick EMUlator.”“The Android Emulator is based on QEMU (the Quick EMUlator) which (using KVM, a Kernel-based Virtual Machine only available on Linux ) emulates an ARM processor on your computer which has a x86 processor. I surely don’t need to explain why emulating a processor by software isn’t a very good idea if you want something reactive and usable.” (source)The Android emulator is famous for being slow. Every Android developer has had cringeworthy moments in front of audiences or clients when the native Android emulator (Android Virtual Device or AVD, for short) – simply refuses to launch, or is so painfully slow that a session of standup comedy breaks out during the wait. Every framework that handles Android builds has to account for the terrible performance of Android emulators.
Xamarin, for example, uses the native Xcode simulator and makes available the native Android Emulator, warning that it’s very slow, offering tips to speed it up, and pleading for patience:
“The emulator takes a while to launch, so you may consider leaving it running after it starts up. You don’t need to shut down the emulator to re-deploy your app… The runtime installation may take a few moments, so please be patient.”
They have also rolled their own Android emulator called the Xamarin Player.
Some Titanium developers wrote an excellent blogpost discussing how to leverage Intel’s closed-source HAXM (Hardware Accelerated Execution Manager) as an alternative to KVM for machine emulation. HAXM makes it all a little better.
Some developers, however, have turned to entirely different Android emulators for app testing; I personally prefer Genymotion (shown below), which is based on the VirtualBox emulator.
Comments
Post a Comment