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.

Introduction

This is an annotated edition of Android Performance Case Study Follow-up by Romain Guy. The first-person case narrative below belongs to the original author.

Technical review — 2026-10-13: The 2015 Falcon Pro 3 / Moto X 2014 case is retained. Android Device Monitor, which hosted Tracer for OpenGL ES and Hierarchy Viewer, was deprecated in Android Studio 3.1 and removed in 3.2. The old workflow is historical; an Android 12+ Perfetto workflow is added below. The original website could not be reopened during this review; the technical corrections use the linked official documentation and versioned source.

Case study

Two years ago, I published Android Performance Case Study to help Android developers understand the tools and techniques needed to identify, track, and optimize performance bottlenecks.

That article used the Twitter client Falcon Pro as a case study. Its developer, Joaquim Vergès, was kind enough to let me use his app as an example and quickly addressed the issues I found. Fast forward to recently: Joaquim was building Falcon Pro 3 from scratch. Before its release, he contacted me about a scrolling performance issue. Once again, I had to analyze it without access to the source code.

In the original Chinese post, I translated Dan Lew’s fifth and final Android tips round-up, which he published in May 2014. As in the earlier parts, I added explanations and notes of my own rather than translating word for word. I hope a few of these tools save you some trouble. Technical corrections and version updates are noted below.

Technical review — 2026-10-13: Old Support Library links now point to AndroidX. Storage, thumbnail generation, and app languages have version-specific updates. The side effects of clearing app data and yielding a database transaction are explained in their entries.

In the original Chinese post, I translated Dan Lew’s fourth Android tips round-up, which he published in May 2014. These are small tools worth sharing, and I added my own notes where I had something to contribute. The version updates are noted below.

Technical review — 2026-10-13: Most of these View/XML APIs remain usable, but the explanations of configuration changes, clipping, and atomic files needed correction. The Gradle Daemon has been enabled by default since 3.0. AtomicFile behavior is illustrated using Android 4.4.4 and Android 16 source versions below.

In the original Chinese post, I translated Dan Lew’s third Android tips round-up, which he published in April 2014. As with the earlier parts, I added my own notes and explanations where I thought they would help. Some of these are tools I use myself; if a few are new to you, I hope they come in handy. The API corrections and version limits are noted below.

Technical review — 2026-10-13: Platform android.app.Fragment was deprecated in API 28; the Fragment entries below use AndroidX. LocalBroadcastManager and Otto are no longer maintained. Other tips remain useful within the API and behavior limits stated below.

Technical review — 2026-10-13: This is a historical Nexus 5 / Android Lollipop tutorial with an obsolete device and toolchain. Its LRX22C binaries correspond to Android 5.0.1 / AOSP android-5.0.1_r1. The source, binary, and flashing requirements below are tied to that combination. An Android 16 Cuttlefish example is added separately; do not mix it with the old phone firmware.

Following my previous article, Using Android Studio to View Android Lollipop Source Code, we know that simply reading code has its limits—understanding can remain superficial and easily forgotten. In contrast, code you’ve personally written or modified tends to leave a much deeper impression, and the process becomes easier to grasp during the implementation phase. While studying the source code, being able to modify it, run it on a phone, and see the results firsthand significantly boosts both learning efficiency and enthusiasm. This article explains how to compile the Android Lollipop source code yourself and run it on a Nexus 5.

Why compile your own firmware instead of using Google’s factory images?
The goal here is a userdebug build suitable for platform debugging. User builds restrict facilities such as ADB root. Userdebug enables more debugging operations, but does not make every partition freely writable under all conditions.

This guide assumes a consistent Lollipop source tree and a Nexus 5. See the historical AOSP environment guide and source download instructions. Android 5.x uses OpenJDK 7 on Linux. Keep its old OS and dependencies in a dedicated historical build environment rather than using it as the setup for a current workstation.

AOSP means Android Open Source Project. It includes the platform and open-source apps, but not the proprietary Google Mobile Services (GMS) suite. Hardware binaries, GMS licensing, and Android compatibility are separate matters. Meeting the CDD and passing CTS establishes compatibility; it does not automatically grant GMS. For the requirements, see the Android compatibility overview.

Technical review — 2026-10-13: This article was written in 2015. Its event-timeline concepts remain useful, while the Eclipse / Device Monitor entry points are obsolete. Historical script options below are checked against AOSP android-5.0.0_r1. The added Perfetto commands target Android 11 / API 30 and later, with older-system differences noted separately. Continue with the Android Perfetto series catalog.

This is the first article in the Android Performance Optimization Tools series. This series mainly introduces the tools used during the Android performance optimization process, how to use these tools to discover problems, and how to solve them. In terms of performance optimization, Android provides many performance tools for everyone to use. Following our consistent “discover problem - solve problem” thinking, discovering the problem is the most important part. Trying to solve a problem without first identifying it properly often leads to twice the effort for half the result.

In this article, we’ll start with a brief introduction to the Systrace tool.

Introduction to Systrace

Systrace arrived with Android 4.1 / SDK Tools R20 as a system-event tracing and visualization tool. It places enabled CPU scheduling, SurfaceFlinger, WindowManager, View, and other events on a shared timeline. It does not automatically sample every Java method or provide complete call stacks. See the original SDK Tools R20 announcement.

The historical workflow has three parts:

• Kernel events: These depend on enabled ftrace support and accessible kernel events. Scheduling, I/O, frequency, and other categories must be checked on the device.
• Userspace annotations and collection: System components emit ATrace markers, while atrace configures categories and reads tracing data. Apps can add their own sections with android.os.Trace.beginSection() / endSection(); these public APIs were added in Android 4.3 / API 18, not Android 4.1.
• Host-side reporting: The old systrace.py invokes atrace over ADB, processes the data, and builds an HTML report with a viewer. Existing system events can be captured without changing app code; custom business-operation sections require instrumentation.

Perfetto supports additional data sources, so describing all of it as an ftrace wrapper would be incomplete. It still reads android.os.Trace markers. See the Trace API and Perfetto ATrace documentation.

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.

Introduction

The previous article covered the theory of overdraw and tools to detect it. While iOS users rely on Apple’s curation, Android users rely on developers’ discipline. Unfortunately, many market-leading Android apps still suffer from significant overdraw issues. As a developer, I want to see Android bridge and eventually surpass the experience gap with iOS.

This post follows one overdraw optimization case. It uses only a few of the available techniques; apps differ, and so will the changes they need. Treat it as an example. Getting this right still takes work.

If you missed the theory part, check it here: Android Performance Optimization: Overdraw (Part 1)

Updated 2026-10-13: This article was written in 2014. Its source excerpts have been checked against AOSP android-4.4.4_r2. Overdraw remains relevant, but ADT, monitor, Hierarchy Viewer, and the old OpenGL tracing workflow are outdated. Android Studio 3.1 and later use Layout Inspector for hierarchy inspection; use Perfetto for frame timing. The historical source is retained below, with Android 12 and Android 16 boundaries added.

It’s been a while since my last update. After joining a new company, things have been busy, but I’ve been spending a lot of time researching Android performance. I’ve realized there’s so much I still don’t know, so I’m starting from the application level and working my way down. This series will document my learnings on Android performance optimization.

First, we’ll discuss GPU Overdraw, which is often the most direct point of contact for developers. This topic is split into two parts: Part 1 covers the theory and optimization suggestions, and Part 2 will walk through a practical optimization example.

What is Overdraw?

GPU overdraw means drawing the same pixel more than once within a frame. For example, drawing a TextView background and then its text can draw the pixels under the characters twice. Extra shading, blending, and memory accesses cost resources, but whether they cause missed frames depends on area, transparency, GPU capabilities, and the rest of the frame’s work. A color overlay alone cannot establish the performance impact. See Android’s overdraw guide.

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.

For the second Chinese post in this series, I translated Dan Lew’s Android Tips Round-Up. As in the first part, I’ve added notes from using some of these tools and filled in explanations where I thought they would help. If a few of the APIs are new to you, I hope the list comes in handy. The API updates are noted below.

Reviewed 2026-10-13: This 2014 list covers View and system utility APIs. Activity.onBackPressed() was deprecated in API 33, and text layout has a Builder API from API 23. The notes below add replacements and correct the explanations of alarms, application memory, and screen density.

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.