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:

1. Unable to connect to a computer for debugging (e.g., USB port is occupied by USB OTG).
2. Logs are difficult to capture in real-time.
3. Bugs appear randomly and are not easily reproducible.
4. 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:

1. 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.
2. Restart Adb with Sudo: Try sudo adb kill-server and sudo 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.