Here’s the fourth round-up of Android tips I’ve been posting.
This is a 2015 introduction to the Systrace tool. The workflows that mention Eclipse, Device Monitor, sdk/tools/systrace, and User builds being unable to capture traces are no longer the default path today. What remains useful is the basic idea: Systrace showed SurfaceFlinger, WindowManager, View, CPU scheduling, and other system behavior on one timeline. For current trace capture and analysis, start from the Android Perfetto Series Catalog.
The workflow has changed like this:
| Old flow | Current flow |
|---|---|
| Click Systrace in Eclipse / Android Studio Device Monitor | Use System Tracing from Developer Options, or run adb shell perfetto |
python systrace.py --time=10 -o trace.html ... |
adb shell perfetto -t 10s -b 64mb ... --out /data/misc/perfetto-traces/trace.perfetto-trace |
| Generate HTML and open it in Chrome | Generate .perfetto-trace and open it in Perfetto UI or trace_processor |
| Mainly zoom and click inside the HTML view | Read tracks and slices first, then narrow evidence with search, SQL, and metrics |
| User builds were treated as mostly unusable | User builds can capture limited information; system-level detail still benefits from Userdebug/eng |
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 half the effort for twice the result.
In this article, we’ll start with a brief introduction to the Systrace tool.
Introduction to Systrace
Systrace is a performance data sampling and analysis tool introduced in Android 4.1. It helps developers collect execution information from key Android subsystems (such as SurfaceFlinger, WindowManagerService, and other critical Framework modules, services, and the View system), allowing for a more intuitive analysis of system bottlenecks and performance improvements.
Systrace’s capabilities include tracking system I/O operations, kernel workqueues, CPU load, and the health of various Android subsystems. On the Android platform, it’s composed of three main parts:
- Kernel Space: Systrace leverages the
ftracefeature in the Linux Kernel. Therefore, to use Systrace, the relevantftracemodules in the kernel must be enabled. - Data Collection: Android defines a
Traceclass that applications can use to output statistical information toftrace. Additionally, theatraceprogram in Android reads statistical info fromftraceand passes it to data analysis tools. - Data Analysis Tools: Android provides
systrace.py(a Python script located inAndroid SDK directory/platform-tools/systracethat callsatraceinternally) to configure data collection (such as tags, output filename, etc.), collectftracestatistics, and generate a resulting HTML file for user viewing. Essentially, Systrace is a wrapper around the Linux Kernel’sftrace. Applications need to utilize theTraceclass provided by Android to use Systrace.
Official documentation and usage for Systrace can be found here: Systrace
Android Studio
As Google’s “own son,” the Nexus phone series receives special treatment that is obvious to everyone. After Android 5.0 was released, the Nexus 5 was updated to the latest system immediately. Similarly, Android Studio, as Google’s official IDE, is highly valued. I switched from Eclipse to Android Studio right from the start, upgrading from the initial beta versions all the way to the current 1.0 stable version (1.1 was released today, and I’ve already upgraded).
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 refers to the system drawing more than one layer on a single pixel during a frame. For example, if a TextView has a background color, the pixels displaying the text are drawn twice: once for the background and once for the characters. Overdraw inevitably impacts performance because memory bandwidth is finite. When overdraw exceeds the available bandwidth, the frame rate drops. Bandwidth limits vary significantly across different devices.
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.
Here’s the second round-up of Android tips I’ve been posting.
With my recent project I’ve been posting one Android class/method a day. People have been asking for an archive of these links, so every couple weeks I’m going to round them up here. I’ll also be adding a bit of color commentary, but still the goal is for this not to be a ton of work for me. :)
Log2File is a utility class for Android applications to record logs to a file (such as the SD card).
Usage Scenarios:
- Unable to connect to a computer for debugging (e.g., USB port is occupied by USB OTG).
- Logs are difficult to capture in real-time.
- Bugs appear randomly and are not easily reproducible.
- Other scenarios where persistent logging is needed.
0. Introduction
This article was originally published on my CSDN blog: http://blog.csdn.net/grackergao/article/details/18322749. I have now migrated it here. The source code is available on Github: https://github.com/Gracker/Android-Utils/blob/master/Log2File.java.
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
If the adb command indicates that no devices are found, please ensure you have already completed these basic steps:
- Enable USB Debugging (Settings - Developer Options - USB Debugging). If you don’t see Developer Options, go to “About” and tap the Build Number several times.
- Restart Adb with Sudo: Try
sudo adb kill-serverandsudo adb start-server.
If it still doesn’t work, follow the steps below:
1. Introduction to Accessibility Service
Accessibility services are a feature of the Android framework designed to provide alternative navigation feedback to users on behalf of applications installed on Android devices. An accessibility service can communicate information about the application to the user, such as text-to-speech, or haptic feedback when the user’s finger hovers over an important area of the screen.
This section covers how to create an accessibility service, how to handle information received from applications, and how to provide feedback to the user.