2017 has passed before we knew it. The blog hasn’t been updated for a while - one reason is that I increasingly realize how shallow my knowledge is and fear that writing about technical topics might mislead readers, and another reason is simply that I’ve been too lazy. Given these two reasons, I’ve decided that blog updates no longer need to be limited to technical articles - things I find meaningful, thoughts, and reflections will also be shared here. On one hand, it serves as my own record, and if it happens to help readers along the way, that would be even better (though there aren’t many readers anyway…).

Since 2017 has just passed, I feel it’s necessary to recommend to everyone the things that I found to be great experiences or very helpful for work and life in 2017 - perhaps you’ll need them in 2018. The recommendations include Apps, hardware, books, equipment, etc. It should be noted that these are things that brought me great help in 2017 - what works for me may not work for you. Without further ado, let’s get into it!

In the blink of an eye, it’s 2017. I’ve been working for nearly four years. I went to school in Weihai in 2009, started my internship in Shanghai in 2012, stayed in Shanghai after graduating in 2013, joined Meizu in Zhuhai in 2014, and have been here ever since.

I’ve been writing on this blog since graduation—writing, deleting, and rewriting—recording my journey from App development to System App development, and finally to System Framework development. Looking back after a few years is a great way to appreciate how far I’ve come.

This post records my thoughts on my blog, my job, my work habits, and my expectations for 2017. It’s a mix of confusion and ambition.

We are already 30% through 2017. I hope it’s not too late to share this.

In March 2016, Google added Bottom Navigation to its design guidelines. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Bottom tab bars were common in iOS apps, while older Android guidance discouraged them. These were design recommendations, not platform limitations or a requirement for every iOS app.

This is the second article in a series on Android Bottom Navigation, covering style, behavior, and dimensions.

In March 2016, Google added Bottom Navigation to its design guidelines. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Bottom tab bars were common in iOS apps, while older Android guidance discouraged them. These were design recommendations, not platform limitations or a requirement for every iOS app.

This is the first article in a series on Android Bottom Navigation, covering its usage and historical evolution.

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

I wrote this because understanding common memory problems before writing the code can save a lot of diagnosis later. We will look at Bitmaps, database queries, list reuse, and drawing: who creates each resource, what keeps it alive, and when it is no longer needed. Retention, repeated allocation, and leaks need different remedies.

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.

Series Catalog:

1. Overview of Android Performance Patterns
2. Android Performance Patterns: Render Performance
3. Android Performance Patterns: Understanding Overdraw
4. Android Performance Patterns: Understanding VSYNC
5. Android Performance Patterns: Profile GPU Rendering

Technical review (2026-10-13): The three-color diagrams are retained from the 2015 video. Their Update / Execute / Process stages can be compared with Android 4.4.4 source. Android 6.0 and Android 16 use finer breakdowns and different reference-line implementations; the old legend does not apply unchanged to every device.

Original video introduction:

“If you can measure it, you can optimize it” is a common term in the computing world, and for Android’s rendering system, the same thing holds true. In order to optimize your pipeline to be more efficient for rendering, you need a tool to give you feedback on where the current perf problems lie.

In this video, Colt McAnlis walks you through an on-device tool built for this exact reason. “Profile GPU Rendering” will help you understand the stages of the rendering pipeline, see which portions might be taking too long, and decide what to do about it in your application.

Profile GPU Rendering Tool

Profile GPU Rendering is a quick on-device tool for finding operations associated with high rendering-stage costs. Despite its name, the bars do not directly measure GPU hardware execution time, and cannot identify every cause of jank on their own. See the official explanation.

Series Catalog:

1. Overview of Android Performance Patterns
2. Android Performance Patterns: Render Performance
3. Android Performance Patterns: Understanding Overdraw
4. Android Performance Patterns: Understanding VSYNC
5. Android Performance Patterns: Profile GPU Rendering

Technical review (2026-10-13): The introduction and nine diagrams are retained from the 2015 video. The text corrects the fixed-60Hz assumption, tearing explanation, and “VSync copies the back buffer” description, and adds modern frame-rate hints and analysis tools.

Original video introduction:

Unbeknownst to most developers, there’s a simple hardware design that defines everything about how fast your application can draw things to the screen.

You may have heard the term VSYNC - VSYNC stands for vertical synchronization and it’s an event that happens every time your screen starts to refresh the content it wants to show you.

Effectively, VSYNC is the product of two components: Refresh Rate (how fast the hardware can refresh the screen), and Frames Per Second (how fast the GPU can draw images). In this video, Colt McAnlis walks through each of these topics and discusses where VSYNC (and the 16ms rendering barrier) comes from, and why it’s critical to understand if you want a silky smooth application.

Basic Concepts

To understand smoothness and jank, distinguish app frame production, system composition, and display presentation. VSync (vertical synchronization) coordinates their timing. It is not the mathematical product of refresh rate and FPS, nor an operation that renders the app’s content for it. See the AOSP VSync explanation.

Series Catalog:

1. Overview of Android Performance Patterns
2. Android Performance Patterns: Render Performance
3. Android Performance Patterns: Understanding Overdraw
4. Android Performance Patterns: Understanding VSYNC
5. Android Performance Patterns: Profile GPU Rendering

Technical review (2026-10-13): The excerpts and diagrams are from the 2015 video. Overdraw remains a useful concept; the text now adds versioned color mappings, transparency exceptions, and conditions for removing backgrounds. Lighter overlay colors alone are not evidence of a performance gain.

Original video introduction:

One of the most problematic performance problems on Android is the easiest to create; thankfully, it’s also easy to fix.

OVERDRAW is a term used to describe how many times a pixel has been re-drawn in a single frame of rendering. It’s a troublesome issue, because in most cases, pixels that are overdrawn do not end up contributing to the final rendered image. As such, it amounts to wasted work for your GPU and CPU.

Fixing overdraw has everything to do with using the available on-device tools, like Show GPU Overdraw, and then adjusting your view hierarchy in order to reduce areas where it may be occurring.

What is Overdraw?

At the beginning of the video, the author uses a house painter as an analogy: painting a wall is hard work, and if you have to repaint it because you don’t like the color, the first layer was a waste of effort. Similarly, some drawing beneath a fully opaque region may make no contribution to the final image. When you try to balance high performance with perfect design, you often run into a common performance issue: Overdraw!

Overdraw means drawing the same pixel more than once within a frame. In the stacked-card example below, work beneath a fully opaque card may be unnecessary. Overlap is not always waste: translucent content, shadows, and antialiased edges still need the underlying color for blending. Removing that content would change the image. Clipping and renderer optimizations also affect the work performed. See the official explanation.

Series Catalog:

1. Overview of Android Performance Patterns
2. Android Performance Patterns: Render Performance
3. Android Performance Patterns: Understanding Overdraw
4. Android Performance Patterns: Understanding VSYNC
5. Android Performance Patterns: Profile GPU Rendering

Technical review (2026-10-13): This is a study note from the 2015 video series. The Nexus 5 example and tool screenshots remain historical material. The original introduction uses 16ms as an approximation for 60Hz; the discussion below now clarifies refresh behavior, jank, and tool limitations.

Original video introduction:

Rendering performance is all about how fast you can draw your activity, and get it updated on the screen. Success here means your users feeling like your application is smooth and responsive, which means that you’ve got to get all your logic completed, and all your rendering done in 16ms or less, each and every frame. But that might be a bit more difficult than you think.

In this video, Colt McAnlis takes a look at what “rendering performance” means to developers, alongside some of the most common pitfalls that are ran into; and let’s not forget the important stuff: the tools that help you track down, and fix these issues before they become large problems.

Android Rendering Knowledge

When you think you’ve developed a world-changing app, your users might not agree. They might think your app is slow and laggy, failing to achieve the smoothness they expect, let alone changing the world. Straight into the bin! Hang on, it runs smoothly on my Nexus 5. How can it be slow? If you know anything about Android fragmentation, you’d know that many low-end phones don’t have the powerful processor and GPU of a Nexus 5, or the same clean stock Android installation.

If a large number of users complain that your app is laggy, don’t just blame their hardware. Sometimes the problem lies within the app itself, including rendering work or a blocked main thread. Measure first to identify the cause and choose a fix. Thus, knowing how Android rendering works is essential for any Android developer.

Series Catalog:

1. Overview of Android Performance Patterns
2. Android Performance Patterns: Render Performance
3. Android Performance Patterns: Understanding Overdraw
4. Android Performance Patterns: Understanding VSYNC
5. Android Performance Patterns: Profile GPU Rendering

In 2015, Google introduced the Android Performance Patterns short-video series. The original playlist is on YouTube; Google’s companion-course announcement also documents the series.

Technical review — 2026-10-13: The original 2015 motivation and viewing experience are retained. The videos remain useful background, while the old tools, Google+ resources, and fixed “16ms” guidance need the version context below.

Overdraw, VSYNC, and main-thread/RenderThread cooperation still matter, but the refresh interval is not always 16ms. It is about 16.67ms at 60Hz, 11.11ms at 90Hz, and 8.33ms at 120Hz. Use the system’s scheduling deadlines and trace data when judging actual frames instead of applying one fixed threshold to every device and scenario.

The old Android Device Monitor, which hosted Hierarchy Viewer and Traceview, was deprecated in Android Studio 3.1 and removed in 3.2. Use the current Profiler for method analysis and Layout Inspector for hierarchy inspection. For Macrobenchmark, follow the setup requirements: a release-like, non-debuggable, profileable target, with consistent device and scenario conditions.

Introduction quoted in the original 2015 article:

Android Performance Patterns is a collection of videos focused entirely on helping developers write faster, more performant Android Applications. On one side, it’s about peeling back the layers of the Android System, and exposing how things are working under the hood. On the other side, it’s about teaching you how the tools work, and what to look for in order to extract the right perf out of your app.

But at the end of the day, Android Performance Patterns is all about giving you the right resources at the right time to help make the fastest, smoothest, most awesome experience for your users. And that’s the whole point, right?

The videos explain Android performance in three to five minutes each. The speakers talk fast; before subtitles were available, they really tested my listening. Subtitles were available when this article was written; check each video’s current subtitle tracks rather than assuming complete coverage today.

While the videos are short, they are packed with information. A point the speaker passes over in one sentence can take a lot of reading to understand, or a while spent learning a debugging tool. This means the series doesn’t directly teach you “how to optimize your app” step-by-step; rather, it tells you what you need to know about Android performance so that you know which tools to use, what steps to take, and what goals to aim for.

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.

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.

This post dates from 2014, when I was using a Nokia X and an old Android SDK. The udev and user-group instructions were updated for Ubuntu 24.04 LTS on 2026-10-13. The old SYSFS rule and Upstart restart procedure no longer apply; the adb_usb.ini workaround remains at the end as a historical note.

1. Problem Overview

Recently, while developing for a Nokia project, I encountered the following issue:

When I plugged in a Nokia X, the computer did not respond at all—it wasn’t recognized. My colleague’s Windows machine also failed to detect it. After searching Google for a long time, I finally found a solution. Since I didn’t record it originally and later forgot how to configure it when helping someone else, I decided to document it here for everyone.

2. Solution

Enable USB debugging on the device and use a cable that supports data transfer. Check the selected Platform-Tools version with adb version, then inspect the connection using adb devices -l.

• Empty list: check the cable, port, USB debugging setting, and whether the host enumerates the device.
• no permissions: check Linux udev rules and the current user’s groups.
• unauthorized: ADB has found the device; unlock it and accept the RSA debugging prompt.
• offline: the device is not responding normally to ADB; reconnect it or restart the ADB server and inspect the state again.

USB enumeration, host permissions, and device authorization are separate checks. See the ADB reference and hardware-device setup guide.

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.