Android development is resource hungry. In fact, even a top of the line MacBook Pro can barely handle a mid to large project. Compiling and running the app takes a whopping 10 to 15 Gb of RAM that just sits there, and that’s without running an emulator! Needless to say if your laptop has only 16 Gb of RAM, good luck doing anything else while developing.
My personal laptop, a 4 year old Razer blade with 16 Gb of RAM, starts FLYING as soon as I open Android Studio on one of my personal projects with only a handful of modules. The fans blow louder than when playing a 3D video game, it’s been driving me nuts.
So I started looking into alternatives. How can I work on my Android projects without my laptop turning into a burning furnace? The answer is of course running the expensive stuff in the cloud.
After trying different approaches like Mirakle, with decent success, my good friend Ty Smith told me about an incubator project by JetBrains called Projector. In essence, it allows you to access any JetBrains IDE through your browser with a clever trick. I tried it out, and was blown away. With this approach, you can seamlessly code from any device that can run a browser. In fact, here’s Android Studio “running” on my phone, because why not.
Of course you would never code on a phone, but it proves that the device hardware is irrelevant. If it has a browser, you can use it to code. This changes everything!
Without the constraints of a beefy hardware, I can choose a development machine that is portable, lightweight, and much cheaper! A good choice in my opinion is a decent Chromebook, a MacBook Air, or a Surface Go. I even considered an iPad as an alternative, it works, but definitely not as comfortable as a real laptop. My personal favorite so far is the Pixelbook Go, great keyboard and super lightweight, been really enjoying coding from it.
Where is Android Studio actually running?
You still need a beefy machine either in the cloud on on your local network to do the actual heavy lifting of running the IDE and Gradle builds. Luckily cloud VMs are now a commodity, and you can get one up and running in a matter of minutes via services like Amazon AWS, Google Cloud or Microsoft Azure. I went with AWS, chose an EC2 instance with 8 cores, 32Gb of RAM and 100 Gb of storage. Running the instance costs me around $0.40 / hour, not cheap if you’re running it 24/7, but since I use it only for a few hours a week for my personal projects, it ends up being quite affordable. Even if I used it for 8 hours a day, 5 days a week, it would cost me around $64 / month. Not bad considering I don’t need an expensive laptop anymore.
When I want to work on my projects, I just start my EC2 instance, run Projector on it, then open a Chrome tab and I’m ready to code. No more crazy fans, no more overheating!
How does it work?
The idea behind Projector is simple but rather brilliant. It intercepts drawing commands from the IDE (or any Swing application) with a custom drawing engine (AWT implementation) that instead of rendering things on screen, records each command, serializes them and sends them to a web client. The web client interprets those drawing commands and renders them in a web page. The web client records keyboard and mouse input, and sends it back to the IDE via AWT.
The beauty of this approach is that even with a slow connection, it renders crisp, pixel-perfect fonts and UI, because it understands the underlying software, so it can render fonts in vector format. Input is also very responsive, because the protocol is specialized, and therefore optimized. This is the killer advantage over more generic remote desktop solutions like VNC, which stream pixels directly. Remote desktops solutions usually render blurry fonts and feel unresponsive over slow connections.
The only drawback from this approach is that some IDE keyboard shortcuts conflict with the browser’s own shortcuts. For instance, cmd+w closes the browser tab instead of one of the tabs in the IDE. There is a work around for that though, by adding the page as a desktop shortcut, which opens any website in app mode. With that, everything has been working really well for me, including all my shortcuts. When putting Chrome in full screen, it pretty much feels like the real thing.
Projector is still very early days, but I can’t wait to see how it evolves.
What about deploying apps to a device and debugging?
Since Android Studio runs on a remote server, I thought it wouldn’t be able to just press run on Android Studio and install the app straight on my phone. I was wrong.
Turns out with a simple ssh tunnel (one simple command line instruction) you can “link” adb on your local machine and on the remote server, so it looks like your device is directly connected to the remote server, and appears in the remote Android Studio like usual.
I went a bit further, and setup WiFi debugging between my phone and my laptop, which means I don’t have to deal with any USB cables.
Pressing “run” in my browser triggers a build on my remote server, which then streams the APK via ssh to my laptop and then via WiFi to my device. What a time to be alive.
How do I try this?
Interested in setting this up yourself? I wrote a step by step setup guide on Github.
What device would you code from, now that we’re liberated from these hardware chains? Let me know on Twitter!