How to speed up the Android Emulator by up to 400%(blogs.nuxeo.com) |
How to speed up the Android Emulator by up to 400%(blogs.nuxeo.com) |
The only time I fire up the emulators is to make sure my assets are scaling properly for the various screen sizes of devices I don't own yet.
If you start with video (or even audio) displaying/capturing then the emulator is pretty fast useless indeed.
One pain point I have, though, is the need to always hit the VirtualBox host key when switching between Eclipse and VirtualBox, since there's no true integration. Sometimes I also get some weird effects with the mouse pointer not being able to move around the entire framebuffer. (Hmm, maybe a VirtualBox integration module for android-x86 would be a good weekend project...)
The Android 2.2 and 2.3 Emulators are atleast on my machine fast enough for development, but i still prefer to develop against hardware just because it feels faster and more real. Multi-Touch is easier...
Even on iOS it's better to develop against actual hardware than the simulator, therefor it's not really that much of an issue.
I dont think its fair to call the emulator an obstacle, it just comes with limitations. After all, emulators are only designed to emulate, they can't replace areal device. A hammer is still a tool, its just not the appropriate tool when you're trying to assemble a clock.
Maybe its just time to upgrade your tools.
XCode isn't perfect, but I don't need google for blog posts or spend hours writing scripts or messing with configuration files in order to get it into a usable state.
Being open source has nothing to do with how easy a platform is to develop on. All that means is that the platform's source code is available.
Debugging on a phone is not so bad, but it's not quite as nice as the iOS simulator experience.
I figured it was important to test on a low end phone, right? ( see how I nicely justified my cheapness there?) The downside to that plan was the jQuery Mobile bug that only showed up on top end devices (now the Huawei has a Galaxy S2 siting next to it...)
They are the Google Reference devices. Admittedly, it's perhaps not as lean as what you're referring to, but as a testing sandbox, I've tried a lot of different phones, but nothing has worked as well, in a general sense, as the reference models.
But just working from (non reference) phones is dangerous too, it's so annoying to implement the volume controls with a BroadcastReceiver for the ACTION_MEDIA_BUTTON Intent (works great on Motorola's), but fails on HTC, and you should just override onKeyUp()... all (Android) phones behave differently, and not only in (screen) specs. Samsung Galaxy S (<2.2) is notorious in not following the Android specs, for example it shows the versionCode instead of versionName to the user [http://developer.android.com/guide/publishing/versioning.htm...] and if you do some (proxy) audio stream playback there is the [http://google.com/search?q=PVMFMemoryBufferReadDataStreamImp...] error with no real solutions...
The problem is, in the end, it should work on the popular devices, not the 'perfect' Android reference phones..
* No Google APIs. So no MapView.
* The various builds are quirky. I couldn't get networking to function in the "Stable" Froyo build. Meanwhile, the Gingerbread build used in the linked post reports the wrong SDK version (it claims Honeycomb but is actually Gingerbread). The deprecated Froyo build I tried didn't support Google Accounts. And so on.
Meanwhile, new builds are currently impossible due to the ongoing kernel.org outage (android-x86 has some hard submodule deps on git.android.kernel.org), so my attempts to go in and tweak the build were thwarted.
Still, very cool stuff. I think the iOS simulator is fantastic and I've been pining for something similar for Android. This doesn't quite meet my needs at the moment, but it would save me multiple hours per week if I could get it set up properly.
The question is whether you can make the emulator run as fast as modern dual core android phones.
Why not? A lot of programmers develop native apps on high-performance workstations because it makes development faster.
Once in a while, you might hit a bug in which the execution time on a phone or in a slow emulator will cause problems. These are the exception to the rule. Use good programming practices especially with respect to multithreading and time-sensitive code and use sensible algorithms (don't under- or over-optimize), and these will be few and far between.
In general, you want fast builds, fast tests, and fast iteration. Anything that allows you to iterate faster is a good thing.
* Presuming you want your NDK app to run any Intel-based tablets/phones.
I get to the home screen with everything loaded in about 18 seconds. I'm on a fairly new system with decent processor and memory to spare, but even on my old single processor 4GB laptop I get the emulator launched in about 35 seconds.
Actually, it is closer to 70 seconds.
Then the lag while attempting to use it is unbearable, it stutters, input is completely ignored, or it crashes randomly when we try to replicate that bug on an actual device we can't.
Core2 Duo, T7500 @ 2.20GHz 4GB RAM Patriot Inferno SSD
2.3 load time from start to lock screen: 65 seconds.
(for me, that was a lesson learned in 1995 doing Macromedia "cross platform" Mac and Windows development)
Of course this diversity is both Android's largest blessing and its biggest curse.
Just watch that your horse desn't fall off that precariously-high ledge and crush us lowly startup operators.
Regardless, there's always going to be the issue of supporting multiple devices, but I have found that if I develop in the 'perfect' environment first, it speeds development time considerably. It's akin to web development against standards. I feel very sorry for the developers (if there are any left, this used to be accepted practice) who developed for Internet Explorer, and then had to cobble in "support" for other browsers. In much the same vain, it's easier to work against the best possible outcome, and then revisit your code for the edge cases.
I don't know, or have any numbers to know whether or not the Galaxy S2 is 'edge' or not, as I'm guessing it's quite popular. :-\ Sorry.
But for general everyday development, I much prefer the simulator - I can look at the result of a code change in under 5 seconds with a simple keystroke, and not even have to pick up a device off my desk. It's empowering to be able to tweak your UIs and see the results in almost-real-time. I cannot do that if I'm forced to push the app to devices every single time.
Not to mention the debugger runs a hell of a lot faster on the host machine than any device - for the vast majority of bugs that isn't based on device quirks, it makes them much quicker to isolate and resolve.
Only if you don't test on real devices.