LAB501

Android L – Rerouting Google…

The new user interface is certainly a welcomed change, but let’s not forget its main purpose. I haven’t heard of many people complaining about Android’s looks, but I’ve heard people wondering how Google will develop its portfolio in tech domains adjacent to those already dominated by Android. That’s what Material Design is supposed to achieve, user experience uniformity from the phone to your TV, to your car. We don’t have any examples in this regard, so color me intrigued by how it will all play out for Google and how the software will end up looking on a computer or TV screen.

Now, you didn’t think Google would go through all this hassle if they didn’t bring Android to new types of computing devices. I’ve heard rumors we’re going to see Android-based servers, and in these highly specialised fields a smartphone operating system would have nothing to offer. That’s why Google’s making some changes to how its operating system is working. Probably the most important is the switch from the Dalvik VM to ART (Android Runtime). While users had the option to switch between these two, but Android L uses strictly ART as the runtime library. What the hell does this mean? Speaking in simplified terms, Android applications contain Dalvik byte code. This is not code that your device’s CPU can execute, so it has to be translated before being sent to the CPU. Traditionally, the Dalvik byte code was interpreted and translated at the moment when it was need, but Android 2.2 added a JIT (just-in-time) compiler which transformed the most used Dalvik byte code to machine code even before execution. That’s all great, but translating from Dalvik to machine code uses resources (time and processing power), and ART looks to optimize the previously described process. Translation now occurs on the first boot or after an application is installed, so the machine code is ready to be used at any time. ART should bring performance and efficiency improvements, but the new runtime presents other benefits as well…

… one of these is flexibility. And how is Google taking advantage of this? By adding 64-bit capabilities to Android, 9 months after the introduction of the iPhone 5S, the first smartphone to use a 64-bit CPU. Don’t be fooled by marketing departments that 64-bit devices are automatically faster than current 32-bit ones. There some situations where a 64-bit CPU would see massive performance advantages, but another one is its strongest: the capability to address way more memory: 4 trillions the size. Try to put that into perspective for a moment: there wasn’t a huge pressure to add more memory to smartphones or tablets. But servers? That’s another story, one that has to do with huge memory sizes.

Sure, Android L remains a mobile operating system, so mobile devices receive their fair share of love. Improvements to battery life are claimed, and optimizations have been made to the animation and graphics libraries. The device can now dispatch jobs to the GPU in parallel to executing them (for each View), and more types of effects and animations are computed on the GPU. These optimizations were a must in designing such an interactive interface.

Other changes to the graphics stack include new functionality, that should bring Android’s 3D capabilities to “PC-level graphics”. Of course this is an exaggeration, but nonetheless it means developers get new tools to build games for Android. This is something iOS has done quite a bit better, history shows, so it’s interesting to see how Android’s rounding its set of skills.

No comments la: Android L – Rerouting Google…

    Leave a Reply