• Avoid synchronous IPCs on UI thread: Check for binder transactions keeping the main thread busy: Often there are multiple Inter process communication happening within the app. These could be anything like image / asset loading, third party libs loading, heavy work on application’s main thread like disk or network access etc. StrictMode is a useful developer tool to detect such accident usage.

• How much time does this take and if it is expected & necessary ?
• Is the main thread sleeping / idle / blocked during this time ? If yes, this could be a performance bottleneck.
• Can this be delayed ?

• Wisely use XML and Json parsing: The Gboard app optimized file list parsing by using Java code instead of XML parsing as they were parsing them out into memory as Java objects at runtime. So, GBoard did a work to convert all the XML into Java code at compile time, the latency then become time of class loading, which is much more faster, almost ⅕ of previous. Benchmarking both XML and Json parsing for your app to identify the appropriate library to be used.

• Analyze and fix severe disk read contention: To capture this, use StrictMode in your development environment.
  • Detects accidental disk or network access on the application's main thread, where UI operations are received and animations take place.
• Can automatically terminate the app (or log it to logcat), when a violation has occurred by adding different penalties.

Optimize app size

Users often avoid downloading apps that seem too large, particularly in emerging markets where devices connect to spotty 2G and 3G networks with low bandwidth speed or work on pay-by-the-byte plans.

• Remove unnecessary layouts: Gboard and Camera from Google teams validated the layouts which were unused or could be merged with small UI changes and removed the unnecessary layouts reducing overall app code size.

• Migrate to dynamic layouts/views when appropriate: The apps deep dive and find out the layouts and views which can be dynamically rendered. They used merge and viewstub to further optimize their views and layouts.

• Revaluate features with low DAU. Try to disable features which take more memory and make the app less performant: The team further analyzed their apps to specifically optimize for Android Go and disabled features on go devices which were not of much usage but were taking a lot of memory. They removed complex animations, large GIFs etc. to make space for parts of the app.

• Try combine native binaries with common dependencies into one: If the app has different JNI implementations with a lot of common underlying dependencies - all the different binaries add up to the apk size with redundant components. Camera from Google app benefited from combining several JNI binaries into a single JNI binary while keeping the Java and JNI files separate. This helped the app reduce the apk size by several Mbs.

• Try to reduce dalvik code size: Check for code that is never used at runtime, eg) large classes and auto-generated code.
  • Code optimizers like ProGuard () could help optimize and shrink code size, but they can't deal with codes guarded by runtime-constants. Replacing the check/flags with compile-time constants to make most usage of the optimization tools.

• Reduce translatable strings size :

• Reducing asset size: Be mindful of different target device form factors that your app supports and adjust your assets accordingly.

• Upload your app with Android app bundles: The easiest way to gain immediate app size savings when publishing to Google Play is by uploading your app as an Android App Bundle, which is a new upload format that includes all your app’s compiled code and resources, but defers APK generation and signing to Google Play. Read more here.

• Utilize dynamic delivery feature if applicable: Play Feature Delivery uses advanced capabilities of app bundles, allowing certain features of your app to be delivered conditionally or downloaded on demand. You can use feature modules for custom delivery. A unique benefit of feature modules is the ability to customize how and when different features of your app are downloaded onto devices running Android 5.0 (API level 21) or higher. Learn more here.

Recap

Source: Android Developers Blog

Approach

• 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) 

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. 

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

// 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

Source: Android Developers Blog