Android application optimization: use reflection to test whether the Android device uses "live wallpaper"

First of all, this may be a very rare optimization, but we still spent a lot of time and careful to figure out the details of this optimization, so I think it makes sense to share this small optimization. Looking forward to one day, someone in a certain place may encounter the same problem and benefit from this paper.

What is reflection?

Reflection is used to observe and modify the behavior of the program during operation. A reflection-oriented program component can monitor the code execution in a range, and can modify itself according to the obtained target object information and the related range. This can be achieved by dynamically allocating program code during operation.

In a programming language with strict type detection, such as Java, the specific types, interfaces, fields, and methods of the objects that need to be called in the program are generally required to be legal during compilation. Sex is checked. The reflection technology allows to postpone the message check of the object that needs to be called from the compilation period to the operation period and then perform it on the spot.

In this way, the interface name, fields (fields) of the target object, that is, the data members (member variables), and available methods of the target object, can be unclear during compilation, and then the target object can be used during operation. Your own message decides how to deal with it. It also allows the instantiation of new objects and the invocation of related methods based on the judgment results.

Why does this problem occur?

We have received complaints straight away. Users claimed that after enabling live wallpaper, our Buzz widget lags behind on Red Note 5. In order to reproduce this problem, we use Union+U-APM online testing on Red Note 5, and use custom exceptions to throw the problem.

The test shows that this exception is passed

WallpaperManager.getInstance(this).getWallpaperInfo()

This is triggered by the if code, which means that this is caused by the application blurring the table and trying to present content on the table. If a live wallpaper is running on the desktop, blurring it will cause some periodic processor consumption.

Why use reflection instead of API?

I prefer that each of our applications has only one version in the Android Market, and the APIs used for this are only available in some SDKs. Reflection allows us to use the API while still allowing the application to run on devices with older firmware.

How to solve

Alright, we are going to show the solution

if(WallpaperManager.getInstance(this).getWallpaperInfo() != null){//不模糊}

To use reflection to do this, we have to use Class.forName("") , Class.getDeclaredMethod() , Object.invoke() method, which is kind of like this

boolean blurBackground = true;
//get the WallpaperManager Class
Class classWallpaperManager = Class.forName("android.app.WallpaperManager");
if(classWallpaperManager != null)
{
//find its .getInstance(this) method
Method methodGetInstance = classWallpaperManager.getDeclaredMethod("getInsta
//invoke the WallpaperManager's .getInstance(this) method to get one
Object objWallpaperManager = methodGetInstance.invoke(classWallpaperManager,

//discover the WallpaperManager Object's .getWallpaperInfo() Method
Method methodGetWallpaperInfo = objWallpaperManager.getClass().getMethod("ge
//invoke it
Object objWallPaperInfo = methodGetWallpaperInfo.invoke(objWallpaperManager,
if(objWallPaperInfo!=null)
{
Log.d("WidgetDroid","WallpaperInfo not null");
blurBackground=false;
}
}

try/catch , we package it in a quick Android version check and a 06180b7cb5905f block to ensure safety.

You're done, now if the device uses a live wallpaper, the application background will not be blurred, and our Widget World can return to normal.