This article was originally written by Yingyun for my Knowledge Planet. Since the Planet has closed, I am publishing this series on OS performance design here.

Yingyun is a veteran performance optimization expert with deep insights into system-level tuning, having worked at several major smartphone manufacturers. He is currently active in our community. If you have any questions or feedback, feel free to join our WeChat group.

1. The Genesis

This starts a new series exploring the various considerations in OS architectural design. In reality, these principles apply to the design of any large-scale software.

My knowledge and experience have limits, and these views are subjective. There will be gaps. I would like to hear other views and see what I have missed.

A fellow developer shared a Weibo post (https://weibo.com/1808884742/IApbpEVQr) where blogger @王波粒 noticed a peculiar phenomenon on the Mate 30 Pro. I highly recommend watching the video first.

The question concerns a difference observed in 2020: some Huawei samples displayed feed images during scrolling, while some other samples waited until the list stopped. This is not a claim about every current device; configuration, caches, and system behavior can differ even with the same client version.

The same version of Weibo behaving differently on different phones was something I wanted to understand as a system performance engineer. Had Weibo made a specific adaptation? What had changed? Let’s look at the code and see what we can learn.

Around 1:30 AM on May 23, 2020, a large number of Samsung phone users in China experienced severe issues including freezes, infinite reboots, and forced entries into Recovery Mode. Improper handling by users led to data loss, and the incident quickly became a trending topic on social media platforms like Zhihu, with service centers overwhelmed.

Social media responses ranged from frustration to anger, with some comparing the incident to the Note 7 battery disaster, “charging-gate,” or “green-screen-gate.” Some predicted Samsung would be forced out of the Chinese market. People lost job offers due to missed calls, others lost valuable data, and some even resorted to smashing their devices in frustration.

As an Android developer, I am not here to pile on Samsung. My goal is to uncover the root cause of this incident and see what we can learn from it. Since it’s a technical failure in the Android system, it’s essential to analyze it from a technical perspective.

On Medium, @MindOrks published a 2020 Android Developer Learning Path. Given that some readers may have difficulty accessing the original content, I am sharing it here combined with my own 2020 learning plan for your reference.

The original article is quite simple, mostly listing knowledge points without much explanation. I have added brief introductions for each point and included some additional topics based on my own understanding. This is for your reference only.

This article is primarily for Android developers. If you are a beginner, it will help you find a learning path. If you are an experienced developer, it can help you identify gaps in your knowledge. If you have any other suggestions, feel free to leave a message.

This article records a 2019 issue: animation work continued after the app’s UI was no longer visible. However, some apps continue to run “zombie animations”—animations that are completely invisible to the user yet consume precious CPU cycles and battery. When users discover this, the result is often a manual kill, an OS-level background restriction, or an outright uninstallation.

This issue can be easy to miss. In the original investigation, I used Systrace after opening apps and returning home, capturing traces while swiping between launcher pages. Some departed apps still fired callbacks. A reproduction should record versions, operations, and visibility; opening many apps is not itself a diagnostic requirement or proof.

Here, “zombie animations” means updates that continue when their UI is invisible and the feature no longer needs them. Many paths can schedule animation work through Choreographer. Investigate the actual stack, playback state, and library version. A live process is not necessarily free to consume CPU indefinitely; modern systems can freeze eligible cached processes.

Whether you are an Android App developer or a System developer, having a foundational understanding of the Android system is extremely beneficial. I recently set up a development environment at home and decided to share the process for anyone interested. The general steps involved are as follows:...

Someone recently asked on Zhihu: “How to calculate APK startup time?”

“How can I use Python or direct ADB commands to calculate APK startup time? I want to measure the time from clicking the icon to the APK being fully started. For example, in a game, this would be from the icon tap to entering the login screen. Existing methods like adb shell am start -W provide ThisTime and TotalTime, but I’m unsure of the difference and they don’t seem to match visual reality.”

My colleague Guo Qifa and I answered different parts of the question. With his permission, I put our answers together here: partly so I could find them again, and partly to make them easier for other developers to find outside Zhihu.

In the previous article, we tried the third DelayLoad approach. That article showed the code; here I want to follow what happens when it runs.

That takes us through several Android framework classes and Activity lifecycle methods.

I found tracing it quite fun: use the tools, add some debug code, and follow it one step at a time. Doing that helped me understand Activity startup better. I hope walking through it helps you too.

To make an Android app start faster, the main idea is to do less during startup. In practice, we usually reach for:

1. Asynchronous Loading
2. Delayed Loading (DelayLoad)
3. Lazy Loading

If you have worked on startup optimization, you have probably used these already. Here I want to look at one DelayLoad implementation and why it behaves as it does. The code is simple, but following it takes us through Looper, Handler, MessageQueue, and VSYNC. I’ll also discuss the problems I ran into and some thoughts along the way.

Preface

These are my notes from learning how hwui’s RenderThread works in Android 5.0. I haven’t covered every detail; I wanted to trace the main flow so that, next time I hit a problem, I would know where to look.

I captured the first RenderThread Draw during app startup with Systrace, as shown below. It helps show the execution order on that thread, but the end of a DrawFrame slice is not the moment pixels appear on screen: GPU work, buffer consumption, composition, and presentation still matter. A StartingWindow may appear during startup; this CPU slice alone does not establish when it disappears.

Finding a value in an unsorted array or linked list without an additional index can require scanning every element. A hash table uses a hash to locate a bucket and supports constant-time basic lookup when hashes are well distributed; it does not guarantee O(1) lookup for every input.

HashMap is an implementation of the Map interface based on a hash table. This implementation provides all optional mapping operations and permits null values and null keys. (The HashMap class is roughly equivalent to Hashtable, except that it is unsynchronized and permits nulls.) This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.

This article follows the source through the array-and-list structure, constructors, put and resizing, get, and the iterator checks using modCount. A final section covers changes in later JDKs.

Android Memory Optimization Series:

1. Android Code Memory Optimization Suggestions - Android (Official)
2. Android Code Memory Optimization Suggestions - Java (Official)
3. Android Code Memory Optimization Suggestions - Android Resources
4. Android Code Memory Optimization Suggestions - OnTrimMemory

---

onTrimMemory(int level), introduced in Android 4.0 (API 14), hints when an app should reduce unnecessary memory usage. Trimming caches can help the system retain more background processes, but does not guarantee process survival or a faster next return.

This article keeps the Q&A format to explain callback delivery, integration, and cleanup. Decide what to retain by resource purpose, and make sure the UI can recover what was released.

Android Memory Optimization Series:

1. Android Code Memory Optimization Suggestions - Android (Official)
2. Android Code Memory Optimization Suggestions - Java (Official)
3. Android Code Memory Optimization Suggestions - Android Resources
4. Android Code Memory Optimization Suggestions - OnTrimMemory

---

For GC to reclaim unused objects, longer-lived owners must stop retaining references that are no longer needed. Reachability from GC roots matters, not whether another object holds a reference: a group of mutually referencing objects can still be collected when the whole group is unreachable. Becoming unreachable does not mean GC runs immediately or that the memory is immediately returned to the OS.

Memory management also includes bounded caches, resource ownership, and component lifecycles. Close files, connections, and native resources through their own APIs rather than waiting only for their Java wrappers to be collected.

Android Memory Optimization Series:

1. Android Code Memory Optimization Suggestions - Android (Official)
2. Android Code Memory Optimization Suggestions - Java (Official)
3. Android Code Memory Optimization Suggestions - Android Resources
4. Android Code Memory Optimization Suggestions - OnTrimMemory

---

This article covers micro-optimizations in Android Java code. Choosing suitable algorithms and data structures still comes first; these techniques are most useful for reducing repeated work and temporary allocations in hot paths.

The original source was Google’s Android Training article, Performance Tips. “Java (Official)” in the title refers to its Java coding advice for Android, not to an Oracle Java performance specification.

On May 28, 2015, Google announced the Android M Developer Preview for devices including Nexus 6. This records that experience; the images below show the home screen and Easter egg.

Obsolete experimental procedure · Technical review (2026-10-13): Changing system properties to expose this switch is retained only as history for Nexus 6 (shamu) and the 2015 Android M preview. Google’s later announcement identifies the initial preview as MPZ44Q, but this article retained no device build-number output to verify its exact image. Modern multi-window development uses the versioned APIs discussed at the end, without these system modifications.

The Singleton pattern restricts how instances are created and accessed. This article follows eager initialization, double-checked locking, the holder idiom, and enums, explaining their initialization behavior and limits.

Technical review (2026-10-13): These patterns remain applicable. The discussion is checked against the Java 5+ memory model and Java SE 25 specifications. It corrects the loading/initialization distinction, runtime access checks, and the explanation of enum reflection. The code blocks named Singleton are alternatives, not declarations to combine in one source file.

This is the final article in our MAT series, detailing how to reconstruct original images from memory snapshots to debug leaks.

1. Android Memory Optimization (1) - Introduction to MAT
2. Android Memory Optimization (2) - Advanced MAT Usage
3. Android Memory Optimization (3) - Viewing Original Bitmaps in MAT

Technical review — 2026-10-13: This historical technique depends on the Bitmap implementation. The original screenshots are retained. The field is checked against AOSP android-4.4.4_r2; Android 8.0 / API 26 explains the native-pixel change. Updated GIMP 3.2.6 import settings and a current debugging alternative follow.

When investigating image-related memory problems in MAT, knowing which image a Bitmap contains makes the object much easier to connect to an app feature. “Original image” here means the pixels held by the runtime Bitmap, not the downloaded JPEG/PNG, its compression settings, or EXIF. MAT can show what retains the object; a large Bitmap alone does not establish a leak.

This workflow requires the dump to contain the pixel array. A Java wrapper and a native address alone cannot reconstruct pixels missing from the dump.

This is the second article in our MAT series, focusing on advanced techniques for analyzing memory issues in Java and Android applications.

1. Android Memory Optimization (1) - Introduction to MAT
2. Android Memory Optimization (2) - Advanced MAT Usage
3. Android Memory Optimization (3) - Viewing Original Bitmaps in MAT

Technical review — 2026-10-13: The 2015 screenshots are retained; concepts and query descriptions were checked against MAT 1.17.0 documentation. The old Studio conversion/GC menus are historical. Reference directions, unreachable-object interpretation, and leak criteria are corrected below, with missing steps restored.

For capture, see the introductory article: obtain a heap dump in Android Studio Profiler with debuggable / complete data, then export to MAT as needed. LeakCanary can support automated tests, but the ordinary leakcanary-android dependency belongs in debug builds. The official 2.14 release-analysis workflow is still marked experimental; adding LeakCanary is not a generic production-capture strategy. See UI-test integration and LeakCanary for releases.

Characteristics of Java Memory Leaks

• A typical Java memory leak is an object that is still reachable but no longer useful.
• Compare its intended lifetime with the actual ownership path, rather than judging only its size or instance count.
• Recreating reusable objects adds allocation and GC work. If old objects are collected normally, that is allocation waste, not necessarily a leak. An oversized legitimate allocation can also cause OOM.

Advanced MAT Techniques

Dumping Memory with Android Studio

The screenshot shows an early Android Studio capture UI:

This is the first article in the series on using the MAT tool. This series consists of three articles, detailing how to use MAT to analyze memory issues, whether they are Java application memory issues or Android application memory issues:

1. Android Memory Optimization (1) - Getting Started with MAT
2. Android Memory Optimization (2) - Advanced MAT Usage
3. Android Memory Optimization (3) - Opening Original Bitmap Images in MAT

Technical review — 2026-10-13: The tutorial and historical screenshots are retained. MAT’s heap-analysis concepts remain useful, while the Eclipse/DDMS capture workflow is obsolete. Installation requirements now reference MAT 1.17.0 (2026-06-10; Java 21+ for the standalone tool). The ART, Bitmap, retained-size, and reference explanations have been corrected.

Start with a Java/Kotlin heap dump in Android Studio Profiler, then export to MAT when its analysis is useful. LeakCanary can help find Android memory leaks. MAT mainly explains why managed-heap objects remain reachable; process-wide memory and native allocations also require tools such as dumpsys meminfo, native allocation recording, or Perfetto heapprofd on Android 10+. On user builds, heapprofd requires a debuggable or profileable app; it cannot arbitrarily profile other apps.

Introduction to MAT

What is MAT?

MAT (Memory Analyzer Tool) is an Eclipse-based Java heap analyzer. It helps us find memory leaks and reduce memory use by showing how much space objects occupy and which references keep them alive. Its reports give us places to start investigating.

MAT is available as an Eclipse plugin or a standalone Eclipse RCP application. The standalone tool does not require a full Eclipse IDE, but it still needs a compatible Java runtime. Whether an Android HPROF needs conversion depends on its format and the analyzer’s support, not on which MAT installation method you chose.

Technical review — 2026-10-13: The original article targets Android 5.0 Lollipop and Android Studio 1.x. The historical IDEGen workflow below has been checked against AOSP android-5.0.0_r1; the added AIDEGen example uses the documentation at android-16.0.0_r1.

Android Studio

Google has always looked after its own. The Nexus 5 got Android 5.0 right away, and Android Studio was getting plenty of attention too. I switched from Eclipse early on and followed Android Studio from the betas through to 1.0.

Reviewed 2026-10-13: This technique applies to traditional Android View layouts. The focus attributes have been available since API 1 and remain supported. Input focus and keyboard visibility are separate states, so adding the attributes does not guarantee that the keyboard stays hidden in every situation.

In Android development, using EditText is very common. However, sometimes EditText automatically grabs focus when entering a page, causing the soft keyboard to pop up immediately. While this is convenient in some cases, most of the time we prefer the keyboard to appear only when the user explicitly clicks on the EditText.

Reviewed 2026-10-13: This 2014 list focuses on Android’s View system. Most APIs remain valid. The old Html.fromHtml(String) overload was deprecated in API 24; the notes below add its replacement and correct the descriptions of cache directories, layout inflation, and reverse playback.

For the first Chinese post in this series, I translated Dan Lew’s Android Tips Round-Up. You may already know some of these small SDK tools; I’m writing them down in case a few are new to you. It isn’t a word-for-word translation. I use some of these classes myself, so I’ve added my own notes and explanations where I thought they would help. This English edition includes the API updates below.

Updated 2026-10-13: The 2014 implementation wrote directly under the external-storage root, which is outdated. Android 10 (API 29) introduced scoped storage; Android 11 (API 30) ignores requestLegacyExternalStorage for apps targeting API 30 or higher. The replacement below uses app-internal storage, requires Android 4.4 (API 19) or later, and needs no storage permission. See Android 11 storage changes.

Log2File records logs explicitly supplied by an Android application to a file. It is useful when:

1. A computer cannot be connected for debugging, for example because USB OTG occupies the port.
2. Logs are difficult to capture in real time.
3. An intermittent bug requires a record of the operations preceding it.
4. I’ll leave the other uses to your imagination.

It saves only the content passed to w(); it does not automatically capture system logcat. Use the Logcat tools for system logging.

0. Introduction

This article originally appeared on my CSDN blog before moving here. The original GitHub source URL returned 404 during this update, so the replacement implementation is included below.

Updated 2026-10-13: This article records the historical approach of observing notifications through accessibility events before Android 4.3. That approach is outdated for a general notification center. Android 4.3 (API 18) introduced NotificationListenerService; section 4 adds a minimal listener for Android 7.0 (API 24) and later. The legacy examples explain the earlier implementation and do not provide a complete notification list.

1. Accessibility Service in Practice

The previous article introduced accessibility services and their basic configuration. This article follows the original implementation of a simple notification center. Android’s system notification UI displays notifications from apps and system components, such as missed calls, screenshots, weather, and news updates. Before Android 4.3, ordinary third-party apps did not have a public API to query the active notification list. Accessibility events offered a limited way to observe notifications; Android 4.3 added the dedicated NotificationListenerService.getActiveNotifications() API.

1. Introduction to Accessibility Service

Updated 2026-10-13: This article was originally written in 2014 and covers accessibility service configuration available from Android 4.0 (API 14). Accessibility services remain supported, but using them as a general notification-center API is outdated. Android 4.3 (API 18) introduced NotificationListenerService for that purpose. The examples below correct service declarations and explain the node-recycling change in Android 13 (API 33).

Accessibility services help people with disabilities, or people temporarily unable to interact with a device, use applications. They can read interface text aloud or provide haptic feedback. This section covers service creation, event handling, and inspecting accessibility nodes.

The system binds an AccessibilityService after the user enables it; it is not started like an ordinary background task service. The examples give you a service skeleton and a few methods. To use them in your app, you’ll still need to add text-to-speech, a settings interface, and application resources. See the service lifecycle and configuration reference.