The UI performance of the app on Android is still very slow compared to that of iOS. And performance on android is very bad, nearing unusable.
When developing Android applications, you have to keep in mind all the different Android OS versions and various screen sizes and resolutions. The main objective before releasing an application is to find bugs and design imperfections. Default Android emulator The great thing about using an emulator for development is that it gives you an opportunity to develop applications without having a real Android device. The default Android emulator comes together with the Android SDK and can be found in the 'tools' folder. So far so good, we have our cake, but can we eat it? The answer comes about 5 minutes after we hit the 'Launch' button.
Go grab a coffee. Have breakfast. Wait another 5 minutes. Maybe even more. Finally - the emulator launches, only to show how slow it actually is. All these performance problems stem from the fact that it emulates an ARM processor so it can run the actual code of your application.
It accomplishes that by providing dynamic binary translation of the device machine code to the OS and processor architecture of your development machine. Basically, it does a lot of mumbo-jumbo to pretend it's an ARM processor - when actually it isn't. OK, it's slow. So what can we do about it?.
Well, first, we can help our CPU out by delegating the rendering process to the GPU by checking 'Use Host GPU' checkbox in AVD's edit window. The screen should now look better and be more responsive. That's because the CPU is not dealing with the tedious work of doing rendering anymore. But, that's still not fast enough.
We can download Intel Atom (x86) images and, while we're at it, download Intel x86 Emulator Accelerator (HAXM, for Mac and Windows only). This will enable virtual machine acceleration capabilities of the Intel CPU (for more information check ).
Now we're getting somewhere, once this baby starts up, it should run fast and smooth. You could say that this level of speed should be sufficient. That may be true, but an issue with the Intel x86 images is that you don't get Google Apps, they only come with ARM images. This is important if you're testing an app that uses GMaps,.
So, as we've seen, ARM images aren't fast enough even with hardware acceleration. And emulators don't have the Play Store. Genymotion by Genymobile is a new, fast Android emulator developed by the French company Genymobile. It's based on the open-source project AndroVM, and the first beta version was released back in June. It runs on all major platforms (Mac, Windows, Linux).
For now it's freely available, but there is also going to be a paid version. According to, the free version will be feature-rich, and the paid version will be intended for large companies needing a higher level of collaboration on Genymotion. How to use it? Genymotion relies on Oracle VirtualBox to work (version 4.1 or above). Download and install. For Windows users it's not necessary to install VirtualBox separately, because it is available from the Genymotion site, bundled with the Genymotion emulator.
Go to and sign up. You'll receive a validation mail, so just click on the validation link to proceed. Download and install the Genymotion emulator (the current version is 1.1.0). Start Genymotion.
You might need to configure path to your Android SDK location in Genymotion settings (probably if you've installed SDK in a non default location). Since this is a first start, there are no devices. Click on 'Add' and download new device. To see available devices, write your credentials in the pop-up dialog and click 'Connect'. Select the device and click 'Start'.
It starts quickly and is insanely fast! It's a little awkward to start the emulator separately, but Genymotion provides Eclipse and Android Studio integration through plugins, also available on Genymotion website. To use the plugin, you have to provide a path to Genymotion installation and Android SDK, as well. OK, it's fast.
Well, for me, the sheer speed of Genymotion is what got me using it in the first place. Which is kind of funny, because in the first version you couldn't even rotate the device. But, alongside the speed bump, it also provides GPS, compass and battery control via some good-looking widgets. Battery control widget The GPS widget even provides GMaps for selecting mock locations, which is really nice for testing location based apps. Device angle control and Play Store Through the Genymotion shell it's also possible to control the device's angle (accelerometer), but it would be cool to control it using a widget, something like the Windows phone emulator does. Genymotion devices with Google Apps also come with the Play Store preinstalled. This comes in handy if you want to test an app from the Play Store quickly.
Multiple screen sizes Multiple screen sizes are one of Android developer's worst nightmares. There is a huge number of different screen configurations of Android devices. Genymotion, as well as the default emulator, offers custom configuration of device's screen. In the list of available devices, select the device for which you want to change screen configuration and click on the monitor icon on the right side. Then simply select one of the predefined screen resolutions or create your own. Be careful when choosing resolution, because you may end up with something rather strange Where it comes short The main setback of Genymotion is that it only provides devices with API version 16, 17 and a preview version of Android 4.3 (API 18). If we take a look at, we'll see that Gingerbread still holds about 33% of all devices (API 10).
So, for testing on that platform you still need either a default emulator or real device, which kind of defeats the purpose of Genymotion as a testing platform. And there is no camera, which I don't miss, but could be really useful. In the future, we can expect even more features, like taking screenshots or video screen capturing (which would be great for making demonstration videos).
An accelerometer widget would be cool, and even a camera would be nice, but we can only wait and see. Final thoughts Well, you can never really get rid of real devices, because you'll always want to test an app on a real device before releasing it. But during development I recommend using a Genymotion emulator. Even though it doesn't cover all major Android OS versions. It's fast, stable, the GPS sensor manipulation is awesome and with the device rotation feature added to the 1.1.0 version - it's truly the way to go.
Also, deploying apps is almost instant and that can save you a lot of time when you're doing small changes to the app. But you have to watch out since the Genymotion emulator runs faster than real devices themselves, giving you a false impression of the performance of the app. Always test on a real device! Like this article? Sign up for our monthly and never miss any of them.
As of May 2015, debugging Xamarin Android applications on an emulator is no longer slow - in fact it is very comparable to a real device if using the right tool and configuring it properly. The provides a virtual machine image to run in VirtualBox that is super-fast. to run the emulator with special images and when turning on 'Use host GPU' it runs pretty fast. The only difference that I realized is that the Xamarin Android Player is slightly faster, especially when deploying the app and attaching debugger (which makes is superior to the standard Emulator, which otherwise works fine too). And by the way: you should definitely enable Fast Deployment in Visual Studio. Speed is dependent on your development device performance.
Debugging through real android device can provide you much faster steps through. Although if problem which I am solving isnt in UI layer (my projects often consists from two projects - UI and Work layer), I am using simple console application with reference on dll with work layer and simply unload project with UI. Iam using Visual Studio 12 which screams that referenced.dll isnt fully supported but it works perfectly and super fast like in normal console application. I'm currently using Xamarin Studio.
In project settings you can find a way to build and deploy faster then you deploy to device, but ONLY FOR DEBUG MODE. In Xamarin Studio, right-click you Android project and go to Options. There, inside Build group, go to Android Build. In Packaging tab, make sure you have both ' Use shared mono runtime' and ' Fast assembly deployment' checked.
It builds for me in less than 8 seconds!! It also works in Visual Studio: right-click your Android project and go to Properties. In Android Options section, make sure you have ' Use shared mono runtime' and ' Fast assembly deployment (debug mode only)' checked.
I've just tested my Solution and it seems to run as fast as in Xamarin studio. As I mentioned, I actually use only Xamarin Studio and it's very fast. Obviously it will take much more time if it's you first deploy to a AVD (Android Virtual Device = emulator) since the shared mono runtime will also be deployed, but the consecutive ones will be lightning speed!:) Remember also to use this fast deployment only for debugging, never for Release mode. I've tested with an AVD running Android 2.3 and one running Android 4.0.3 and then both works as expected. This deployment configuration to AVD is faster than any device I've tested, but it only seems to work in emulator, not in my test devices.
![Very Very](/uploads/1/2/5/5/125519043/306295069.png)
In my devices the app stops responding as soon as it opens. Do not forget to comment here if it works fine for you. Yes, I use all of my old devices and my current device for debugging. Its better for a number of reasons. One, the emulator is great, but you never know just how the app is going really look and feel until you test it on a device. Sometimes the emulator doesn't draw things exactly as they may appear on the real screen. Also, if you're using external applications provided by android like making calls, emailing you'll need a real device.
However, all that being said, the emulator is a great place to start and get going. One tip is to never close the emulator once you get it running if you are doing a lot subsequent tests/bug fixes. That way you're emulator is already loaded in your computer's memory and doesn't have rebuild it each time.