Android性能最佳实践_android javathreadshell attachcurrentthread-优快云博客

本文分享了Android应用性能优化的实用技巧，包括减少对象创建、优选数据结构、使用静态方法等，还深入探讨了JNI的高效使用方法，如合理管理引用及线程等。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

最近看了谷歌官方关于Android性能最佳实践的部分，感觉应该要记下来才行。这里面有很多不看不知道的东西，我也为一些比较难懂的点增加了一些额外阅读的链接。刚总结完了JNI的小贴士，往后几天会陆续在这篇文章中把性能最佳实践这一部分补充完整。

后面还有安全最佳实践，权限最佳实践等部分，每一部分一篇文章，都会分开记录下来。

性能小贴士

这里介绍了一些小优化，可以提升app的整体性能。但是不一定会带来性能的飙升。选择正确的算法和数据结构是获得良好性能的首要任务。这里的小优化都是一些通用的编码实践，实现高效代码。

实现高效代码有两个基本规则：

不要重复造轮子
不要无谓分配内存

不要创建不必要的对象

创建对象总是要付出代价的。当我们创建越来越多的对象的时候，我们其实在强制地让垃圾回收器更加频繁地工作。这会造成类似于『打嗝』一样的波动，影响用户体验。

因此，要避免任何不必要的对象创建。以下是一些建议：

比如说，如果一个方法要返回String对象。Java内部实现的时候，String最后都是会被加到StringBuffer中的，因此不需要在代码中创建一个临时的StringBuffer或者StringBuilder对象来append字符串，直接用String就好了。
从字符串中截取子字符串的时候，不要创建新的String对象去存放原字符串的拷贝，可以选择直接return substring就好。

更加影响性能的一些点在于数组的使用上：

int类型的array比Integer类型的array性能更好；同时，想方设法避免（int， int）这样多维数组的使用，将多维数组降成一维从而获取性能提升；

总结一下，尽量避免临时对象的创建，这样能减少垃圾回收器的运行次数，提升用户体验。

尽可能使用static而不是virtual

如果一个方法不需要访问这个类的成员，那么用static修饰这个方法。这样一来，大致上会有15%-20%的访问速度提升。

这里stackoverflow有个针对于这个问题的很好的解释

使用static final修饰常量

使用statis final修饰常量，能提高访问速度。

这里涉及到java的编译原理，做不了深入解释了。

要注意的是，这只对原始类型数据以及String常量有效。

避免在类的内部使用Getter/Setter方法

在C++等语言中，(i = getCount())这样的代码是很好的编码习惯，编译器会提升执行效率。

但是在安卓中，使用这样的方式是很糟糕的想法。在安卓中调用Virtual Method差不多就像寻找成员变量一样消耗性能。在类中，直接访问成员变量而不要使用Getter方法。

没有JIT编译的情况下，直接访问成员的速度将3倍快于调用Getter方法。拥有JIT编译的情况下，直接访问成员变量变得和访问局部变量一样快捷，将达到7倍快于调用Getter方法。

这是一片关于Java中Virtual Method的文章

使用增强for循环

除了ArrayList的遍历之外，增强for循环的性能是最好的。无论有没有JIT编译支持，在ArrayList的遍历上使用手写for循环，都将3倍快于增强for。

但是在其他容器上，增强for的性能在没有JIT的情况下快于手写for循环，在有JIT的情况下等同于手写for循环。

鉴于更少的代码，在除了ArrayList的地方，都使用增强for。

看下面的情形：

static class Foo {
    int mSplat;
}

Foo[] mArray = ...

public void zero() {
    int sum = 0;
    for (int i = 0; i < mArray.length; ++i) {
        sum += mArray[i].mSplat;
    }
}

public void one() {
    int sum = 0;
    Foo[] localArray = mArray;
    int len = localArray.length;

    for (int i = 0; i < len; ++i) {
        sum += localArray[i].mSplat;
    }
}

public void two() {
    int sum = 0;
    for (Foo a : mArray) {
        sum += a.mSplat;
    }
}

zoo()方法是最慢的，使用了手写for循环，并且每次循环都要获取array长度；

one()方法快一些，不用每次都获取array长度了；

two()方法最快，使用了增强for（这里不是ArrayList）。

记住在非ArrayList的情况下用增强for。

使用默认包访问权限而不是私有private权限

考虑如下情形：

public class Foo {
    private class Inner {
        void stuff() {
            Foo.this.doStuff(Foo.this.mValue);
        }
    }

    private int mValue;

    public void run() {
        Inner in = new Inner();
        mValue = 27;
        in.stuff();
    }

    private void doStuff(int value) {
        System.out.println("Value is " + value);
    }
}

内部类Inner访问了外部类的成员变量mValue和成员方法run，语法上是没有问题的，运行结果也正确。

但是，因为mValue和run方法被private修饰，VM是禁止直接访问一个类的私有成员的，因为Foo和Inner是两个不同的类。

为了能使内部类访问外部类的私有成员，编译器生成了如下两个方法：

/*package*/ static int Foo.access$100(Foo foo) {
    return foo.mValue;
}

/*package*/ static void Foo.access$200(Foo foo, int value) {
    foo.doStuff(value);
}

因此，无论是访问mValue还是run，都调用了其中一个方法。

在前面讲到了，在同一个类中要访问成员或者方法最好的方式是直接访问，而不是通过方法调用。因此，这里就是性能损耗的地方。

最好将private去掉，也就是使用默认权限。但是这样一来其他同一包中的类就能访问这些成员了。

最好的办法就是不要写这样的代码了。

避免使用浮点

最佳实践的一条是，浮点操作在安卓设备上，2倍慢于整型操作。

速度层面上说，float和double的速度差不多，其实就是一样的慢！表述范围上来说，double是2倍于float的，那么在没有内存烦恼的台式电脑上，double是首选。

另外要注意的是，有些处理器支持硬件乘操作，但是不支持硬件除操作。因此，在设计有大量除或者模运算的时候，要特别注意性能问题。

尽量使用标准库

Java有的方法，就不要自己去实现了。Java库的代码是针对于虚拟机进行过优化的。System.arrayCopy()f案发9倍快于手写的循环拷贝。

关于性能要知道的地方

没有JIT编译支持的设备上，直接确定一个引用的类型会使调用更加高效。比如，定义HashMap的时候，直接定义为：

HashMap hashMap = new HashMap();

而相较于：

Map hashMap = new HashMap();

对hashMap调用方法，会有大概6%的性能提升。

性能优化之前

在进行优化之前，先测试并确定我们确实有性能问题，并且尽量量化这个性能问题，这样，我们才能在性能优化之后测试优化的效果。

Traceview工具很好用，但是要记住，使用Traceview将会关闭JIT功能。这意味着使用Traceview的时候性能的下降可能在JIT功能恢复的时候就能弥补。

这里是Traceview的说明页面

这里是Systrace的说明页面

JNI小贴士

JavaVM和JNIEnv

JNI定义了两种最关键的数据结构：

JavaVM
JNIEnv

在源码中，C部分定义为两个结构体：

struct _JavaVM
struct _JNIENV

在C++部分中，可以看做定义了两个类

typedef _JNIENV JNIENV
typedef _JavaVM JavaVM

数据结构的定义是这样的：

struct _JNIEnv {

    const struct JNINativeInterface* functions;

    #if define(__cplusplus)
    jclass FindClass(const char* name) {
        return functions->FindClass(this, name);
    }

    ...

}

数据结构如果是C实现的代码：

JNIEnv即struct JAVANativeInterface*，在传递JNIEnv* env的时候，其实就传递了struct JAVANativeInterface** functions，从上面数据结构的定义看出，如果要在C代码中调用FindClass方法，必须先对env做一次解引用，才能得到指向functions具体函数的指针，即，(*env)->FindClass(this, name)。

而如果是C++实现的代码：

传递JNIENV* env，其实相当于传递了struct _JNIEnv* env。从上面的定义可以看出，C++部分对JNINativeFunctions做了封装。因此要调用函数，只需要用env直接调用即可，即，env->FindClass(this, name)

JNIEnv是threadlocal的，因此不能在线程间进行传递。

如果一段代码无从获取JNIEnv，那么应该共享JavaVM，然后使用GetEnv来获取JNIEnv。

在jni.h中，C和C++部分的定于是不同的，通过typedef来区分。因此，如果一个header file会被两种语言包含，就不要把涉及JNIEnv的部分放进去。

线程

所有线程都是Linux线程，由内核管理。

线程可以通过pthread_create另外创建，并通过AttachCurrentThread或者AttachCurrentThreadAdDaemon，来创建一个java.lang.Thread对象，添加到主线程组（ThreadGroup）中。

一个线程在attach之前无法进行任何JNI操作。

对一个已经attach的线程做attach操作产生一个no操作，可以看做操作被忽略。

调用AttachCurrentThread的线程在退出前必须调用DetachCurrentThread。也可以使用pthread_key_create创建析构函数，然后在那里调用DetachCurrentThread。

jclass，jmethodID，jfieldID

如果想在native代码中操作java对象的成员，通过如下方式进行：

通过FindClass方法获取对象引用
通过GetFieldID获取成员ID
通过相应的方式获取成员的值，例如GetIntField

找到成员ID和方法ID的过程就是通过字符串比对查找，如果考虑性能问题，可以通过下面的方式在类加载的时候缓存一份ID，已经查找过的就不再查找了。

    private static native void nativeInit();

    static {
        nativeInit();
    }

在native代码中实现这个方法，然后就会在每次类加载的时候自动执行ID的差找工作。

局部和全局引用

JNI中所有参数以及所有方法的返回都是局部引用。就算对象继续存在，只要方法已结束，局部引用就不可用了。

这适用于多有jobject的子类。

唯一保存局部引用的方式是通过NewGlobalRef或NewWeakGlobalRef方法来创建全局引用。

这通常用于缓存一个FindClass返回的jclass对象：

jclass localClass = env->FindClass("MyClass");

jclass globalClass = reinterpret_cast<jclass>(env->NewGlobalRef(localClass));

值得注意的是，对于同一个对象的引用的值可以是不同的。例如，连续对同一个对象调用NewGlobalRef方法而返回值可以是不同的。因此，千万不要用==来判断两个引用是否相等，而应该使用IsSameObject方法。另外，不要用jobject当索引。

JNI的实现中只允许16个局部引用，如果要创建超过这个数量的引用，使用EnsureLocalCapacity/PushLocalFrame来获取更多数量的预留空间。创建的引用应该使用DeleteLocalRef来手动回收。

jfieldIDs和jmethodIDs，以及GetStringUTFChars和 GetByteArrayElements的返回值，都不能作为NewGlobalRef的参数，因为他们是非object类型。

最后，任何通过AttachCurrentThread添加的线程中的局部引用，都应该手动释放。

UTF-8和UTF-16字符串

Java语言使用的是UTF-16字符串。JNI提供了方法来兼容Modified UTF-8。这中编码的好处是我们可以继续使用C风格的\0结尾的字符串，但是坏处是我们不能给JNI的方法传递任意UTF-8字符串，因为有可能出错。

不要忘记release从get方法获得的字符串。这些get方法获取的字符串只当在release调用之后才保证有效。

传递给NewStringUTF方法的数据必须是Modified UTF-8编码。常见的一个错误是，从一个文件或者网络读取字符串然后直接传递给NewStringUTF方法而不进行过滤。

这里有一篇关于如果和在JNI中使用正确编码的文章，有兴趣的同学可以看一看~

原始数组

JNI中，Object数组只能一次访问一个条目，但是原始数据类型的数组能像在C中定义的那样读和写。

使用Get<PrimitiveType>ArrayElements能获取到指向实际数据的指针或者开辟新的内存空间来拷贝数据。注意，只有当release方法调用了，get方法返回的数据才能被使用，也就是说，如果调用了get方法但是没有调用release方法，那一块堆内存就无法被其他指令使用了。因此必须release每个get到的数组，并且确保如果get失败了，我们没有去release一个NULL指针。

异常

大多数的JNI函数都不能在有异常发生而没有解决的时候调用。

在异常发生的时候可以调用的JNI函数如下：

DeleteGlobalRef
DeleteLocalRef
DeleteWeakGlobalRef
ExceptionCheck
ExceptionClear
ExceptionDescribe
ExceptionOccurred
MonitorExit
PopLocalFrame
PushLocalFrame
ReleaseArrayElements
ReleasePrimitiveArrayCritical
ReleaseStringChars
ReleaseStringCritical
ReleaseStringUTFChars

在调用诸如CallObjectMethod的方法时，必须检查是否有异常发生。

使用ExceptionCheck或ExceptionOccurred检查是否有异常，使用ExceptionClear清除异常。

JNI并没有提供操作Throwable类的方法。因此，如果要获取异常信息的字符串，只能找到Throwable类，找到getMessage "()Ljava/lang/String;"方法的methodID，然后调用这个方法；如果返回了NON-NULL的值，则再使用GetStringUTFChars获取一些信息来打印。

扩展检查

JNI的错误检查机制很薄弱，因此Android提供了一种叫做CheckJNI的机制来让JavaVM和JNIEnv完成更多的错误检查工作。

检查的范围不限于：

数组：试图创建负数大小的数组
非可用指针：传递不可用的jarray/jobject/jstring给JNI函数，或者传递NULL给non-nullableJNI函数
字符串编码错误

等等…

如果我们使用的是虚拟机，这个模式默认是打开的。

如果是在ROOT设备上，可以使用如下方式重启运行环境并打开CheckJNI：

adb shell stop
adb shell setprop dalvik.vm.checkjni true
adb shell start

除了上述两种情况，使用如下方式：

adb shell setprop debug.checkjni 1

打开CheckJNI模式之后，在logcat中可以看到如下输出：

D AndroidRuntime: CheckJNI is ON

已经在运行的app不会受到任何影响，但是从这时起运行的app都会在CheckJNI模式下。

修改CheckJNI模式到任何其他值或者重启运行时环境都会关闭CheckJNI模式。关系CheckJNI之后的输出如下：

D Late-enabling CheckJNI

64位系统需要考虑的

Android当前被设计运行在32位平台，当然，也可以在64位平台编译运行，但不是当前的设计目的。大部分时间我们不需要担心这个情况，但当遇到在对象中往整数类型成员中储存指针的时候，要做一些处理。为了支持那些使用64位指针的的平台，我们需要把指针存放在long类型中，而不是int类型。

不支持的特性/向上兼容

除了下面这个特性，JNI1.6所有的特性Android都能支持：

DefineClass 这个特性没有实现。由于Android不使用Java字节码或class文件，因此传递二进制class数据不会起作用。

向上兼容需要考虑的情况如下：

动态获取方法ID

直到Android 2.0（Eclair），在搜索methodID的过程中，$符号不能被正确的转换为_00024。解决方案可以是显式地注册这个方法，或者从内部类中移出来。
分离线程（Detach）

直到Android 2.0（Eclair），不能使用pthread_key_create的析构函数来防止thread must be detached before exit。（因为运行时环境也使用了pthread key destructor function，会造成看谁先调用的情况）
、弱全局引用（Weak global references）

直到Android 2.2 (Froyo)，没有weak global references可以使用。

直到Android 4.0 (Ice Cream Sandwich)，weak global references只能被传递给NewLocalRef，NewGlobalRef，以及 DeleteWeakGlobalRef方法。

Android 4.0 (Ice Cream Sandwich)之后， weak global references就能像其他引用一样被使用。
局部引用（Local references）

直到Android 4.0 (Ice Cream Sandwich)，local references事实上是直接指针（direct pointers），看Quora上的问答什么是direct pointer和indirect pointer。4.0增加了indirect pointer特性是为了更好地支持垃圾回收。这里有JNI Reference变动的详细说明
通过GetObjectRefType确定引用类型

直到Android 4.0 (Ice Cream Sandwich)，由于使用direct pointer，造成了无法使用GetObjectRefType获取引用类型。取而代之的，使用了一种先验式的机制，按照弱全局引用表（weak globals table），参数（arguments），局部引用表（locals table）以及全局引用表（globals table ）这样的顺序查找这个引用的类型。因此，有可能我们使用GetObjectRefType去确定一个全局的jclass（global jclass）的类型，而这个全局的jclass就是那个参数jclass（把local jclass做成全局的），会返回JNILocalRefType，而不是JNIGlobalRefType。