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:
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.
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:
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:
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:
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:
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
Singletonare alternatives, not declarations to combine in one source file.
Series Catalog:
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 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:
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.
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:
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.
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:
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.
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:
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.
| Investigation | Current entry point and conditions |
|---|---|
| View / Compose hierarchy and attributes | Use Layout Inspector on debuggable apps. It can also show Compose recomposition/skipping; hierarchy inspection is not a frame-duration measurement |
| Quick rendering-stage and overdraw signals | Developer options provide Profile GPU/HWUI Rendering and Debug GPU Overdraw. The bars represent CPU-side rendering stages, not pure GPU execution time, and do not cover every custom rendering path. See the official guide |
| Frames missing their deadlines | Perfetto FrameTimeline requires Android 12 / API 31+. Relate frames to the thread, scheduling, and SurfaceFlinger tracks actually captured |
| Regressions during scrolling or transitions | Macrobenchmark FrameTimingMetric is available from AndroidX Benchmark 1.1.0. frameOverrunMs requires API 31+ and measures something different from frameDurationCpuMs |
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.
