Auto Ads by Adsense

Monday, April 28, 2014

Review: Android Studio

Since helping my wife with her Nutrition Tracker App, I'd had a chance to try both Eclipse and Android Studio for android app development. Both of them run on Windows, my preferred platform, but it didn't take 3 days with Eclipse before I got frustrated with frequent crashing, features not working, and a lousy layout tool. I found Android Studio and downloaded it and soon persuaded my wife to switch to it.

Android Studio is based on IntelliJ IDEA. Back at Google when I was doing Java work, I avoided it like the plague, preferring to stick with Emacs and gtags. That's because Google's Java source base was so big you couldn't possibly load it into IntelliJ on the puny workstations of that time (yes, Google only supplied machines with 2GB of RAM in 2003), and even if it had been possible, those machines would have slowed to a crawl under the load of processing that much code. IntelliJ/Eclipse die-hards were resorting to wacko tricks like subsetting Google's code base so it could load into IntelliJ and then writing plugins into gtags for accessing the rest of the source code. I have no idea what Googlers do today, but my suspicion is that things haven't gotten much better.

For small Android projects like Nutrition Tracker, however, an IntelliJ is just about right. If you're unfamiliar with the Android API, it would supply you with method name completion, tell you which arguments to supply in which order, automagically add imports, allow for automatic refactoring tricks such as moving methods, renaming variables safely, and moving inner classes out of their outer classes, shifting classes between packages, etc. The layout tool helps you avoid having to learn the lame layout XML language, so you can actually try to make things work (as opposed to making things look pretty and usable --- I think Emacs is a great UI, so I have no expertise on those topics).

Android Studio is slow. It's slow to startup, it's slow to compile, and it's slow to run the debugger. A typical edit-compile-debug cycle would take around 10-20 seconds in order to build a tiny app. Note that I'm not complaining about Android Studio's massive use of resources while I'm editing. I think that's entirely appropriate. I want all my 4 cores/8 threads to be utilized in order to make my coding experience faster and more pleasant. I don't even mind the startup, since it doesn't need to happen that frequently, and it's a one time cost. But the Gradle build system is not only a resource hog, but it introduces additional latency into my think-time, so I begrudge every second it's spending traversing dependency graphs instead of actually compiling code. I have no idea why the Android Studio engineers chose a clunky system like Gradle, as opposed to rolling their own and integrating it fully into the IDE. I never want to edit the gradle build files manually, but the system forces me to. What's more, the syntax is really obscure and the documentation is inadequate.

For instance, when doing an android release, the documentation only covers Eclipse. Worse, the documentation lies to you. It tells you to modify your Manifest file, and I did. Until I kept scratching my head as to why that never worked. It turned out that you had to modify the Gradle config, since the Android Manifest XML file was ignored in the presence of Android Studio. Well, that took so much googling around that I can't remember what search term I used to uncover the Stack Overflow answer any more.

The source control integration is also funky. It supports Git, Mercury, and Subversion, but not Perforce. Given that Google uses Perforce internally, I surmise that Google's internal projects do not use Android Studio. This does not bode well, since that will mean that Android Studio's most serious problems (build performance) will most likely never get addressed because its non-existent internal customers will not feel the pain.

For quick and dirty Android projects, Android Studio is probably the best there is. If you're serious about building an Android app, however, my suggestion is that you use Emacs and roll your own build system that's decently fast. Otherwise, the benefits from using an IDE will be swamped by inordinately long compile/edit/debug cycle times. Note that though my machine is old, it's still decently powerful compared to even the fastest rig today, let alone the kind of laptops most "hip" developers favor, so it's unlikely you can solve Android Studio's problems by throwing more hardware at it.

Recommended only for non serious Android projects. It's a great tool for getting started quickly though, so use it to bootstrap yourself into doing Android development if that's one of your goals.

No comments: