Android System Performance Optimization: Reordering, How Many Do You Know?

Here are a few common reordering schemes:

1. Java-level multidex, dex file class layout reordering, improving file read efficiency. Try to put startup-related classes in the same dex file and as close together as possible for kernel file pre-reading and block reading to load into memory ahead of time.

2. Class bytecode conversion to machine code (assembly) AOT, JIT has reordering.

3. Native C++ compilation, compilers may have assembly code-level reordering based on optimization levels.

4. Android graphics pipeline reordering of drawing instruction lists. For example, to avoid performance overhead caused by context switching, instructions may be reordered.

For example, based on the loading degree of drawing tasks:

Original instruction order:

- Load and render a complex application icon (involving image decoding, scaling, etc.).

- Draw interface background color.

- Draw text (set font, size, color, etc.).

In the original order, loading and rendering a complex icon may take longer. Because icon processing is more complex, the GPU may be in a waiting state, not fully utilizing it to draw the background and text.

Reordered instruction sequence:

- Draw interface background color.

- Draw text.

- Load and render

These are static and can be easily analyzed and reordered.

There is also CPU-GPU level reordering of machine code and related memory access ordering. Chip-level instruction reordering mainly optimizes addition, floating-point arithmetic, external data read-write, branch prediction, etc.

Reordering brings performance improvement but increases complexity and introduces bugs.

In the past, I encountered a probability bug in the ART virtual machine caused by instruction reordering, which took me a long time to fix. Later, a senior manager from Qualcomm helped fix it in 3 days.

What other reordering optimization schemes are there? Please leave a comment to share.

I’ll start with this:

Android APP’s looper message loop is not categorized and prioritized, which may cause low-priority messages to block UI components and high-priority messages. For example, an unimportant broadcast can affect the creation and binding of services:

service-create, low-receiver, service-bind

This is a one-size-fits-all approach.

iOS’s runloop has done a lot of categorization and prioritization, but it seems too complex.

Is there a better Android app looper scheme?