Future Tech

Grab shrank its superapp by a quarter in order to survive

Tan KW
Publish date: Tue, 05 Mar 2024, 02:45 PM
Tan KW
0 460,233
Future Tech

In 2019, Southeast Asian superapp developer Grab spotted a problem: its app was growing in size by one percent per month, making it less suited to the modest smartphones found across the region in which it operates, degrading user experience and ultimately threatening its prospects for attracting more users.

"As the app continues to expand with more features, Grab identified the need for a consistent, high-quality experience for new users who may have limited storage space or restricted internet bandwidth," explained the developer on its engineering blog last week.

The Grab app started out providing ride-hailing, and expanded over the next decade into food delivery, parcel delivery, mobile payment, and even its own driver-targeted loans.

Not every user utilizes every offering, yet all features remain present in the app - which grew to four million lines of code.

In Q3 2021 the Singapore-based outfit therefore initiated "Project Bonsai" - an effort to reduce its app's download size and disk footprint. Over six months it improved the former by 26 percent and made an unspecified dent in storage requirements too.

Prior to Project Bonsai, Grab was already using an app bundle approach and tailoring APKs to specific device configurations. Additionally, it monitored changes to the app, established debug build (APK file size) monitoring for every commit merged to the master branch, employed R8/Proguard as a "code shrinker," made use of vector images when possible instead of raster images, enabled resourceConfig to rid itself of languages not used in its regions, and reviewed third-party libraries for unnecessary bloating.

But all this was not enough. So with Project Bonsai, Grab looked to measure, reduce and contain the size of its app by whatever means necessary.

It started by building its own custom tool to analyze binaries from bundle files, which it named App Sizer and integrated with its continuous integration systems.

The tool sends data to a Grafana instance for monitoring and observability of device-specific app download size, identifies which libraries and modules use the most storage space, and creates a list of large files.

Grab says it plans to open-source the tool in the near future.

To reduce the app’s size, Grab decided not to anything new but instead decided to target the biggest offenders it could find.

“Our concentration centered on optimising the dex file size, refining resources, and eliminating duplication and redundancy,” outlined Grab.

Java/Kotlin code was the major contributor of app size, and thus became a top priority for optimisation. And within that code, R classes were the major culprit. “R classes contained ID references not only to their own resources but also to resources from their transitive dependencies,” stated the blog authors.

“This meant that if Module A depended on Module B, and Module B in turn, depended on Module C (Module A -> Module B -> Module C), then Module A’s R class included IDs references to resources from Modules B and C, even if Module A didn’t directly utilise these resources. This explained why R classes in a modularised project could accumulate millions of lines of code,” the authors wrote.

The company also found that its app contained over 1,500 modules and third-party libraries, which led to the generation of significantly large R classes. This did, however, explain why software engineers saw spikes during certain commits despite no significant additions of resources, libraries, or code.

“These fluctuations were linked to changes in the dependency graph, further emphasising the impact of Transitive R classes,” Grab’s devs wrote. Furthermore, R classes were being preserved thanks to default rules. This was fixed by updating the AGP version after performing an automation test to avoid inadvertently removing non-used R class fields. This test was done by script to search for instances where R class reflections were used. Third party libraries were decompiled and applied the same script. Next, Grab revised its R8 configuration rules looking for redundancy.

Bin the bloat

When large files were found, the responsible team was encouraged to remove them if deemed unnecessary, consider offloading to a cloud server, and converting them to more economical file formats.

Even fonts were streamlined as the superapp removed rarely used typefaces and eliminated duplicates. Grab is now working to adopt a single font.

“Our recommendation is to explore the use of one primary font style, with the flexibility to incorporate different typeface variations in your programming to achieve various typefaces using the same font,” Grab’s post states.

One specific library was found to account for eight percent of the app’s storage footprint. Grab removed it, and worked to remove duplicate functions across other libraries.

An addition to the app - a toggle feature to disable a feature remotely - also helped the reduction effort.

“It’s very useful for running an experiment or turning off if a feature causes us any problems,” noted the blog authors.

Grab continues to find explore methods to keep its app trim, including common UI design component and experimenting with dynamic delivery.

Grab disclosed it is considering issuing each team an allocated “app size budget” they must observe.

“By prioritising code optimisation, resource management, modularisation, and asset bundling, we achieved substantial optimisations in app size while enhancing user experience,” boasted Grab.

The problem of app bloat is one that is not likely to go away, particularly in Southeast Asia as smartphone use continues to grow but consumers’ ability to pay for them doesn’t .

Last year a YouGov survey of Asian consumers found three-quarters of respondents between age 18 and 40 prefer mid-range phones due to their keen prices, even though that means missing out on some features. The study was sponsored by Xioami-backed brand Poco - so maybe take it with a grain of salt, while also noting that for Grab the issue of ensuring its app doesn’t overwhelm hardware remains a hot issue. ®

 

https://www.theregister.com//2024/03/05/grab_downsizes_app/

Discussions
Be the first to like this. Showing 0 of 0 comments

Post a Comment