Optimize for Android (Go edition): Lessons from Google apps - Part 1

Hallo Friends cellphone prices and specifications, In the article that you are reading this time with the title Optimize for Android (Go edition): Lessons from Google apps - Part 1, we have prepared this article well for you to read and take the information in it. hopefully the contents of the post Article Android Developers Blog, Article IFTTT, what we write you can understand. all right, have a nice reading..

Posted by Niharika Arora, Developer Relations Engineer

The Android operating system brings the power of computing to everyone. This vision applies to all users, including those on entry-level phones that face real constraints across data, storage, memory, and more.
This was especially important for us to get right because, when we first announced Android (Go edition) back in 2017, people using low-end phones accounted for 57% of all device shipments globally (IDC Mobile Phone Tracker).

What is Android (Go edition)?

Android (Go edition) is a mobile operating system built for entry-level smartphones with less RAM. Android (Go edition) runs lighter and saves data, enabling Original Equipment Manufacturers (OEMs) to build affordable, entry-level devices that empower people with possibility. RAM requirements are listed below, and for full Android (Go edition) device capability specifications, see this page on our site.

Year	2018	2019	2020	2021	2022	2023
Release	Android 8	Android 9	Android 10	Android 11	Android 12	Android 13
Min RAM	512MB	512MB	512MB	1GB	1GB	2GB

Android (Go edition) provides an optimized experience for low-RAM devices. By tailoring the configuration and making key trade-offs, we’re able to improve speed and performance for low-end devices and offer a quality phone experience for more than 250M people around the world.

Recent Updates

We are constantly making phones powered by Android (Go edition) more accessible with additional performance optimizations and features designed specifically for new & novice internet users, like translation, app switching, and data saving.

Below are the recent improvements we made for Android 12:

Faster App Launches

Longer Battery Life

Easier App Sharing

More Privacy Control

Why build for Android (Go edition)?

With the fast growing & easily accessible internet, and all the features available at low cost, OEMs and developers are aiming & building their apps specifically for Android (Go edition) devices.

Fast forward to today — over 250 million+ people worldwide actively use an Android (Go edition) phone. And also considering the big OEMs like Jio, Samsung, Oppo, Realme etc. building Android (Go edition) devices, there is a need for developers to build apps that perform well especially on Go devices.

But the markets with the fast growing internet and smartphone penetration can have some challenging issues, such as:

• Your app is not starting within the required time limit.
• A lot of features/required capabilities increases your app size 
• How to handle memory pressure while working on Go apps?

Optimize your apps for Android (Go edition)

To help your app succeed and deliver the best possible experience in developing markets, we have put together some best practices based on experience building our own Google apps Gboard & Camera from Google.

Approach

Define Metrics & breakdowns → Benchmark Metrics → Identify bottlenecks → Optimize bottlenecks → Add regression tests.        ↑_________________________________↓

Phases	Description
Define	Before starting any optimization effort, it’s important to define the goals. Key Performance Indicators (KPIs) have to be defined for the app. KPIs can be common across different apps and some can be very specific. Some examples of KPIs can be   KPI Category App Startup Latency Common to all apps App Crash Rate Common to all apps End to end latency for CUJ - Camera Shot Specific to Camera app App Not Responding Rate Common to all apps Once KPIs are defined the team should agree on the target thresholds. This can be derived from the minimum user experience/benchmarks in mind. KPIs should ideally be defined from the perspective of balancing User Experience and technical complexity.
Breakdown	Once KPIs are defined, the next steps could be to break down a given KPI into individual signal metrics. For example → End to end latency for CUJ (shots in Camera) can be divided into → Frame capture latency, image processing latency, time spent on saving a processed image to disk etc. Similarly, App Crash Rate can be bucketed into → Crash due to unhandled errors, Crash due to high memory usage, Crash due to ANR etc.
Benchmark	Benchmark or measure the KPI values and individual metrics to identify current performance. If KPI targets are met, things are good. If not → identify the bottlenecks by looking at the individual breakdowns.
Repeat the process	After optimizing a certain bottleneck go back and benchmark the metrics again to see if the KPI targets are met. If not, repeat the process. If yes, great job!
Add Regular regression test	That either runs for every change or in some frequency to identify regressions in KPIs. It is more difficult to debug and find sources of regressions or bugs than to not allow them to get into the codebase. Don’t allow the changes that fail the KPI goals unless the decision is to update the KPI targets. Try to invest in building a regression infrastructure to deal with such issues in early stages. Decide on how often tests should run? What should be the optimal frequency for your app?

Optimize App Memory

• Release cache-like memory in onTrimMemory(): onTrimMemory() has always proven useful for an app to trim unneeded memory from its process. To best know an app's current trim level, you can use ActivityManager.getMyMemoryState(RunningAppProcessInfo) and then try to optimize/trim the resources which are not needed.

GBoard used the onTrimMemory() signal to trim unneeded memory while it goes in the background and there is not enough memory to keep as many background processes running as desired, for example, trimming unneeded memory usage from expressions, search, view cache or openable extensions in background. It helped them reduce the number of times being low memory killed and the average background RSS. Resident Set Size(RSS) is basically the portion of memory occupied by your app process that is held in main memory (RAM). To know more about RSS, please refer here. 

• Check if malloc can be replaced with mmap when accessing read-only & large files: mmap is only recommended for reading a large file onto memory ('read-only memory mapped file'). The kernel has some special optimizations for read-only memory mapped files, such as unloading unused pages.

Typically this is useful for loading large assets or ML models.

• Scheduling tasks which require similar resources(CPU, IO, Memory) appropriately: Concurrent scheduling could lead to multiple memory intensive operations to run in parallel and leading to them competing for resources and exceeding the peak memory usage of the app. The Camera from Google app found multiple problems, ensured a cap to peak memory and further optimized their app by appropriately allocating resources, separating tasks into CPU intensive, low latency tasks(tasks that need to be finished fast for Good UX) & IO tasks. Schedule tasks in right thread pools / executors so they can run on resource constrained devices in a balanced fashion.

• Find & fix memory leaks: Fighting leaks is difficult but there are tools like Android Studio Memory Profiler/Perfetto specifically available to reduce the effort to find and fix memory leaks.

Google apps used the tools to identify and fix memory issues which helped reduce the memory usage/footprint of the app. This reduction allowed other components of the app to run without adding additional memory pressure on the system.

An example from Gboard app is about View leaks

A specific case is caching subviews, like this: 

 

void onKeyboardViewCreated(View keyboardView) {   this.keyButtonA = keyboardView.findViewById(...);   ... }

The |keyboardView| might be released at some time, and the |keyButtonA| should be assigned as null appropriately at some time to avoid the view leak.

Lessons learned:

• Always add framework/library updates after analyzing the changes and verifying its impact early on.
• Make sure to release memory before assigning new value to a pointer pointing to other object allocation in heap in Java. (native backend java objects) 

For example :

In Java it should be ok to do

 

ClassA obj = new ClassA("x"); // ... something obj = new ClassB("y");

 

GC should clean this up eventually.

 

if ClassA allocates native resources underneath and doesn't cleanup automatically on finalize(..) and requires caller to call some release(..)  method, it needs to be like this 

 

ClassA obj = new ClassA("x"); // ... something // Explicit cleanup. obj.release(); obj = new ClassB("y");

 

else it will leak native heap memory. 

• Optimize your bitmaps: Large images/drawables usually consume more memory in the app. Google apps identified and optimized large bitmaps that are used in their apps. 

Lessons learned :

• Prefer Lazy/on-demand initializations of big drawables.
• Release view when necessary.
• Avoid using full colored bitmaps when possible. 

For example: Gboard’s glide typing feature needs to show an overlay view with a bitmap of trails, which can only has the alpha channel and apply a color filter for rendering.

 

// Creating the bitmap for trails. trailBitmap = Bitmap.createBitmap(w, h, Bitmap.Config.ALPHA_8); ... // Setup paint for trails. trailPaint.setColorFilter(new ColorMatrixColorFilter(new ColorMatrix(new float[] {   0, 0, 0, 0, (color >> 16) & 0xFF,   0, 0, 0, 0, (color >> 8) & 0xFF,   0, 0, 0, 0, color & 0xFF,   0, 0, 0, 1, 0 }))); ... // onDraw @Override protected void onDraw(Canvas canvas) {   super.onDraw(canvas);   if (trailBitmap != null) {     canvas.drawBitmap(trailBitmap, 0, 0, trailPaint);   } }

 

A screenshot of glide typing on Gboard

• Check and only set the alpha channel for the bitmap for complex custom views used in the app. This saved them a couple of MBs (per screen size/density).
• While using Glide, 
• The ARGB_8888 format has 4 bytes/pixel consumption while RGB_565 has 2 bytes/pixel. Memory footprint gets reduced to half when RGB_565 format is used but using lower bitmap quality comes with a price too. Whether you need alpha values or not, try to fit your case accordingly.
• Configure and use cache wisely when using a 3P lib like Glide for image rendering.
• Try to choose other options for GIFs in your app when building for Android (Go edition) as GIFs take a lot of memory.
• The aapt tool can optimize the image resources placed in res/drawable/ with lossless compression during the build process. For example, the aapt tool can convert a true-color PNG that does not require more than 256 colors to an 8-bit PNG with a color palette. Doing so results in an image of equal quality but a smaller memory footprint. Read more here.
• You can reduce PNG file sizes without losing image quality using tools like pngcrush, pngquant, or zopflipng. All of these tools can reduce PNG file size while preserving the perceptive image quality.
• You could use resizable bitmaps. The Draw 9-patch tool is a WYSIWYG editor included in Android Studio that allows you to create bitmap images that automatically resize to accommodate the contents of the view and the size of the screen. Learn more about the tool here. 

Recap

This part of the blog outlines why developers should consider building for Android (Go edition), a standard approach to follow while optimizing their apps and some recommendations & learnings from Google apps to improve their app memory and appropriately allocate resources.

In the next part of this blog, we will talk about the best practices on Startup latency, app size and the tools used by Google apps to identify and fix performance issues.

from Android Developers Blog https://ift.tt/9iD8oJg
via IFTTT

Thus the article Optimize for Android (Go edition): Lessons from Google apps - Part 1

Enough of the articles Optimize for Android (Go edition): Lessons from Google apps - Part 1 this time, hopefully it can be of benefit to all of you. well, see you in another article post.

You are now reading the article Optimize for Android (Go edition): Lessons from Google apps - Part 1 By address link https://cellphone-prices-and-specifications.blogspot.com/2022/09/optimize-for-android-go-edition-lessons.html