Android性能优化总结

最新推荐文章于 2024-09-12 17:14:36 发布

郭霖_

最新推荐文章于 2024-09-12 17:14:36 发布

阅读量3.5k

点赞数 3

文章标签： android java 编程语言 jvm python

原文链接：https://juejin.cn/post/6950608825942868004

版权

/ 今日科技快讯 /

近日，据美国媒体CNBC报道，自今年5月以来，谷歌创始人和其母公司Alphabet的控股股东拉里·佩奇和谢尔盖·布林共出售了价值超10亿美元的股票。根据OpenInsider向美国证券交易委员会提交的文件，从5月开始，两人出售了价值超过10.7亿美元的A类和C类股票。

/ 作者简介 /

本篇文章转载自Xander_Wang的博客，文章主要分享了他对Android性能优化的实践体会，相信会对大家有所帮助！

原文地址：

https://juejin.cn/post/6950608825942868004

/ 前言 /

性能的优化是一个老生常谈的点，也是一个比较重要的点。做过一点性能优化的工作，现在对工作中的优化点做一个总结。如有错误，还请指正。

有哪些方面需要优化

在平时的优化过程中我们需要从哪几个点来优化呢？其实我们平时自己一定也用过软件，在使用软件的过程中有没有什么想吐槽的呢？

“这个 app 怎么还没下载完！”、“太卡了吧！”、"图片怎么还没加载出来！"、"怎么刚进去就卡了！"、“这么点了一下就退出了！”等等，是不是有这样的想法？这些想法其实包含了我们今天要说的内容，就是从哪些方面来优化我们的 APP ，我总结了以下几点。

APK 瘦身优化
启动速度优化
稳定性优化
内存的优化
操作流畅度优化

当然，需要优化的不仅仅是这几个方面，我做的比较多的优化是这几个方面，暂时就这几个方面来谈谈优化吧。

/ APK瘦身 /

如何查看 APK 的组成

如果要优化 APK 的大小，我们首先需要知道我们编译出来的 APK 都包含哪些东西，然后针对占用大的做裁剪，或者删除不需要的东西，从而达到瘦身的目的。查看 APK 的内容占用情况很简单，打开 AS ，把 APK 拖到 AS 里面就可以查看 APK 包含的内容了。

可以看到占大头的是 res 代码等，所以瘦身可以从这几个方面来考虑。

如何减少 res 资源大小

删除冗余的资源

一般随着项目的迭代，部分图片等资源不再使用了，但是可能仍然被编译到了 apk 里面，所以可以删除这部分不再使用的资源，可以使用 lint 工具来搜索项目中不再使用的图片等资源。

重复资源的优化

除了有冗余资源，还有些是文件名不一样，但是内容一样的图片，可以通过比较 md5 值来判断是不是一样的资源，然后编辑 resources.arsc 来重定向。

图片压缩

未压缩的图片文件占用空间较大，可以考虑压缩未压缩过的图片来瘦身。常用的工具是 tinypng 网站。同时也可以借助 TinyPngPlugin 等插件或者其他开源工具来帮助压缩图片。

资源混淆

通过将资源路径 res/drawable/wechat 变为 r/d/a 的方式来减少 apk 的大小，当 apk 有较多资源项的时候，效果比较明显，这是一款微信开源的工具，AndResGuard。

指定语言

如果没有特殊的需求的话，可以只编译中文，因为其他的语言用不上，如果用不上的语言编译了，会在 resource 的表里面占用大量的空间，故：

android {
    defaultConfig {
        ...
        // 仅支持 中文
        resConfigs "zh" 
    }
}

如何减少 so 库资源大小

自己编译的 so

release 包的 so 中移除调试符号。可以使用 Android NDK 中提供的 arm-eabi-strip 工具从原生库中移除不必要的调试符号。

如果是 cmake 来编译的话，可以再编辑脚本添加如下代码：

set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -s")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -s")

别人编译的 so

联系作者修改，一般很难联系到。

动态下发 so

可以通过服务器下发 so , 下载完后再进入应用，但是体验不好，但是是一个思路。

只编译指定平台的 so

一般我们都是给 arm 平台的机器开发，如果没有特殊情况，我们一般只需要考虑 arm 平台的。具体的方法是 app 下的 build.gradle 添加如下代码：

android {
    defaultConfig {
        ndk {
            abiFilter "armeabi"
        }
    }
}

各个平台的差别如下：

平台	说明
armeabi-v7a	arm 第 7 代及以上的处理器，2011 年后的设备基本都是
arm64-v8a	arm 第 8 代 64 位处理器设备
armeabi	arm 第 5、6 代处理器，早期的机器都是这个平台
x86	x86 32 位平台，平板和模拟器用的多
x86_64	x86 64 位平台

如何减少代码资源大小

一个功能尽量用一个库

比如加载图片库，不要 glide 和 fresco 混用，因为功能是类似的，只是使用的方法不一样，用了多个库来做类似的事情，代码肯定就变多了。

混淆

混淆的话，减少了生成的 class 大小，这样积少成多，也可以从一定层度减少 apk 的大小。

R 文件内联

通过把 R 文件里面的资源内联到代码中，从而减少 R 文件的大小。可以使用 shrink-r-plugin 工具来做 R 文件的内联。

/ 启动速度 /

启动的类型

一般分为，冷启动和热启动。

冷启动：启动时，后台没有任何该应用的进程，系统需要重新创建一个进程，并结合启动参数启动该应用
热启动：启动时，系统已经有该应用的进程(比如按 home 键临时退出该应用)下启动该应用。

如何获取启动时间

adb 命令

adb shell am start -S -W 包名/启动类的全名

adb shell am start -S -W xxx/xxxActivity
Stopping: xxx
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=xxx/xxxActivity }
Status: ok
Activity: xxx/xxxActivity
ThisTime: 770
TotalTime: 770
WaitTime: 848
Complete

ThisTime: 表示最后一个 Activity 启动时间
TotalTime: 表示启动过程中，所有的 Activity 的启动时间
WaitTime: 表示应用进程的创建时间 + TotalTime

一般我们关注 TotalTime 就好了。

另外，谷歌在 Android4.4（API 19）上也提供了测量方法，在 logcat 中过滤 Displayed 字段也可以看到启动时间。

2021-04-06 19:25:52.803 2210-2245 I/ActivityManager: Displayed xxx/xxxActivity: +623ms

+623ms 就是Activity 的启动时间。

时间戳

时间戳的方法基于以下的 2 个知识点。

应用进程刚创建，会调用 Application 的 onCreate 方法。
首次进入一个 Activity 后会在 onResume() 方法后面调用 onWindowsFocusChange 方法。

结合这 2 个特性，我们可以在 A Application 的 onCreate() 方法和 Activity 的 onWindowsFocusChange 方法里面，通过时间戳来获取应用的冷启动时间。

如何监控启动过程

systrace

systrace 是一个功能很强大的工具，除了可以查看卡顿问题，也可以用来查看应用的启动问题。使用示例如下：

python $ANDROID_HOME/platform-tools/systrace/systrace.py gfx view wm am pm ss dalvik app sched -b 90960 -a 你的包名 -o test.log.html

用 Google 浏览器打开 test.log.html 就可以看到详细的启动信息。

Debug 接口

package android.os;
...
class Debug {
    ...
    public static void startMethodTracingSampling(String tracePath, int bufferSize, int intervalUs) {

    }
    public static void startMethodTracing(String tracePath, int bufferSize) {

    }
}

利用 Debug 类的这两个方法，可以生成一个 trace 文件，这个 trace 文件，可以直接在 AS 里面打开，可以看到从 startMethodTracingSampling 到 startMethodTracing 过程中的方法调用等信息，也可以较好的分析启动问题。

一般有那些优化方法

耗时操作放到异步进程

比如文件解压、读写等耗时 IO 操作可以新开一个线程来执行。

延时初始化

即暂时不适用的工具类等延后到使用的时候再去初始化。比如从 xml 里面读取颜色，可以考虑在使用的时候再去读取和解析。

线程优化

线程的创建需要消耗较多的系统系统资源，减少线程的创建。可以考虑共用一个线程池。

/ 稳定性优化 /

APP 稳定性的维度

app 稳定一般指的是 app 能正常运行，app 不能正常运行的情况分为两大类，分别是 Crash 和 ANR。

Crash：运行过程中发生的错误，是无法避免的。
ANR：应用再运行时，由于无法再规定的时间段内响应完，系统做出的一个操作。

如何治理 Crash

应用发生 Crash 是由于应用在运行时，应用产生了一个未处理的异常(就是没有被 try catch 捕获的异常)。这会导致 app 无法正常运行。

如果需要解决的话，就需要知道这个未处理的异常是在哪里产生的，一般是通过分析未处理的异常的方法调用堆栈来解决问题。

Android APP 可以分为 2 层，Java 层和 Native 层。所以如何捕获需要分开说。

Java 层获取未处理的异常的调用堆栈

这个需要了解 Java 虚拟机是如何把一个未捕获的异常报上来的。未捕获的异常，会沿着方法的调用链依次上抛，直到 ThreadGroup 的 uncaughtException 方法。

    public void uncaughtException(Thread t, Throwable e) {
        if (parent != null) {
            // 递归调用，可以忽略
            parent.uncaughtException(t, e); 
        } else {
            // 交给了 Thread.getDefaultUncaughtExceptionHandler() 来处理未捕获的异常
            Thread.UncaughtExceptionHandler ueh =
                Thread.getDefaultUncaughtExceptionHandler();
            if (ueh != null) {
                ueh.uncaughtException(t, e);
            } else if (!(e instanceof ThreadDeath)) {
                System.err.print("Exception in thread \""
                                 + t.getName() + "\" ");
                e.printStackTrace(System.err);
            }
        }
    }

查阅代码发现，发现 ThreadGroup 最终会给 Thread 的 defaultUncaughtExceptionHandler 处理。

  private static volatile UncaughtExceptionHandler defaultUncaughtExceptionHandler;

上面的代码显示：Thread 的 defaultUncaughtExceptionHandler 是 Thread 类的一个静态变量。

看到这里，如何捕获 Java 层未处理的异常就很清晰了，给 Thread 设置一个新的 defaultUncaughtExceptionHandler，在这个新的 defaultUncaughtExceptionHandler 里面收集需要的信息就可以了。

需要注意的一点是旧的 defaultUncaughtExceptionHandler 需要保存下来，然后新的 defaultUncaughtExceptionHandler 收集信息后，需要再转给旧的 defaultUncaughtExceptionHandler 继续处理。

Native 层获取未处理的异常的相关信息

Java 层如何收集未处理的异常的信息说过了，我们来看看 Native 层发生未处理的异常的话，是如何处理的。Native 层的处理，需要掌握 linux 的一些知识，由于本人不是特别了解 linux ，这里就直接参考别人的文章了。如果有错误，还请指正。

本人通过查阅资料发现，Native 层如果发生未处理的异常(注:如果 Native 层捕获了异常，是可以通过 JNI 抛到 Java 层去处理的) ，系统会发出信号给 Native 层，在 Native 层如果要收集未处理的异常信息，就需要注册对应信号的处理函数。当发生异常的时候，Native 层会收到信息，然后通过处理器来收集信息。

注册信号处理函数如下：

#include <signal.h> 
int sigaction(int signum,const struct sigaction *act,struct sigaction *oldact));

signum：代表信号编码，可以是除SIGKILL及SIGSTOP外的任何一个特定有效的信号，如果为这两个信号定义自己的处理函数，将导致信号安装错误。
act：指向结构体sigaction的一个实例的指针，该实例指定了对特定信号的处理，如果设置为空，进程会执行默认处理。
oldact：和参数act类似，只不过保存的是原来对相应信号的处理，也可设置为NULL。

有了信号处理函数，后面还要做的事情就是收集信息了，由于本人不是很熟悉 Native 的开发，这里就不展开说了了，大家可以参考 Android 平台 Native 代码的崩溃捕获机制及实现。

Android 平台 Native 代码的崩溃捕获机制及实现：

cnblogs.com/mingfeng002/p/9118253.html

/ 如何治理ANR /

ANR 是 Applicatipon No Response 的简称。如果应用卡死或者响应过慢，系统就会杀死应用。为什么要杀死应用？其实也很好理解，如果不杀死应用，大家会以为系统坏了。

那我们如何监控 ANR 呢？以及我们如何分析 ANR 的问题呢？常见的导致 ANR 的原因有哪些呢？

首先，ANR 的原理是 AMS 在 UI 操作开始的时候，会根据 UI 操作的类型开启一个延时任务，如果这个任务被触发了，就表示应用卡死或者响应过慢。这个任务会在 UI 操作结束的时候被移除。

然后，如何分析 ANR 问题呢？

一般 ANR 发生的时候， logcat 里面会打印 ANR 相关的信息，过滤关键字 ANR 就可以看到，这里不做详细分析，可以参考后面的文章。

然后一般会在 /data/anr 目录下面生成 traces.txt 文件，里面一般包含了 ANR 发生的时候，系统和所有应用的线程等信息(需要注意的是，不同的 rom 可能都不一样)，通过 logcat 打印的信息和 traces.txt 里面的信息，大部分的 ANR 可以分析出原因，但是呢，也有相当一部分的 ANR 问题无法分析，因为 logcat 和 traces.txt 提供的信息有限，有时候甚至没有特别有用的信息，特别是 Android 的权限收紧， traces.txt 文件在高 Android 版本无法读取，给 ANR 问题的分析增加了不少的困难。不过好在最近发现头条给 ANR 写了一个系列的文章，里面对 ANR 问题的治理方法，个人觉得很好，这里引用一下。

本人之前写过一个小的性能监测的工具，其中有监控 UI 线程 Block 的功能，考虑后续加入头条的 ANR 监测机制，等后续完成了，在做一个详细的总结吧。这次的总结就写到这里。

/ 内存的优化 /

硬件的内存总是有限的，所有每个应用分到的内存也是有限的，所有内存的优化很有必要，否则应用就没有足够的内存使用了，这个时候就会 Crash 。

内存都消耗在哪里了

优化内存的话，需要了解内存在哪里消耗了了，针对内存消耗大的场景做优化，对症下药，才可以有一个好的优化效果。

Android Studio 里面的 Profiler 工具是一个很好用的工具，通过里面的 memory 工具可以实时监控 APP 运行过程中的内存分配。

dump APP 内存堆栈后，还可以看到各个类占用的内存情况。

可以查看每个对象的详细信息。

Android Studio 里面的 Profiler 工具的具体使用教程请参考官方教程，这里就不做详细介绍了。

如何合理使用内存

利用上面的方法，找到内存消耗大的场景，就需要做优化了，主要做法就是想办法减少特定场景下的内存的使用。个人总结了一下平时可能会做的优化。

图片相关的优化

图片是我目前做的应用里面占用内存比较大的一块了，也碰到了一些问题，我主要是通过以下的方法来做优化。

暂时用不上的图片不加载，比如说，有个网络加载异常的图，不要一开始就初始化，等到真的有异常了需要展示的时候再初始化
加载图片的时候，尽量加载指定大小的图片，因为有时候会碰到控件的大小小于实际图片尺寸的情况，这个时候，会浪费一些内存。有需要的话，可以让后台返回不同尺寸的图片。
根据不同的图片格式
不显示的图片，可以考虑先释放。

尽可能少地创建对象

毫无疑问，如果对象少，内存肯定也消耗的少，那平时需要注意哪些呢？

自定义 view 的时候，不要在 onDraw 方法里面频繁创建对象。因为 onDraw 方法可能会频繁调用，这个时候就会创建大量的对象。从而造成浪费，同时也会导致 gc 触发的频率升高，造成卡顿。
尽量少创建线程，创建线程其实是比较消耗资源的，创建一个空的线程，大概会占用 1-2 M 内存。同时一般异步任务很快就会执行完，如果频繁创建线程来做异步任务，除了内存使用的多，还可能 GC 造成卡顿。执行异步任务的话，一般建议用线程池来执行，但是需要注意线程池的使用。
尽量用 StringBuilder 或者 StringBuffer 来拼接字符串。平时发现的问题主要是在打印 logcat 的时候和拼接后台返回的数据的时候会创建大量的 String，所以如果有类似的情况也可以考虑做一些优化。

内存泄漏是什么

内存泄漏指的是本应该释放的内存，由于一些原因，被 GC ROOT 对象持有，从而而无法在 GC 的时候释放，这样可能会导致的一个问题就是，重复操作以后，APP 没有足有的内存使用了，这个时候系统会杀死 APP 。所以内存泄漏是需要排查的。

如何监控和分析内存泄漏问题

上一个小结总结了上面是内存泄漏，是因为某些 GC ROOT 对象持有了期望释放的对象，导致期望释放的内存无法及时释放。所以如何监控和分析内存泄漏问题就成了如何找到 GC ROOT 的问题。

一般手动分析的步骤是：重复操作怀疑有内存泄漏的场景，然后触发几次 GC 。等几秒钟后，把 APP 的内存堆栈 dump 下来(可以使用 as 的工具 dump)，然后用 sdk 里面的 cover 工具转换一下，然后用 MAT 工具来分析内存泄漏的对象到 GC ROOT 的引用链。

手动分析总是很麻烦的，一个好消息是，有一个特别好用的自动监控和分析内存泄漏的工具，这个工具就是 leakcanary ，它可以自动监控并给出内存泄漏的对象到 GC ROOT 的引用链。

使用很简单，只需要在 APP 的 build.gradle 下面新增。

dependencies {
  // debugImplementation because LeakCanary should only run in debug builds.
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.7'
}

leakcanary 比较核心的一个原理就是利用了弱引用的一个特性，这个特性就是：

在创建弱引用的时候，可以指定一个 RefrenceQueue ，当弱引用引用的对象的可达性发生变化的时候，系统会把这个弱引用引用的对象放到之前指定的 RefrenceQueue 中等待处理。

所以 GC 后，引用对象仍然没有出现在 RefrenceQueue 的时候，说明可能发生了内存泄漏，这个时候 leakcanary 就会 dump 应用的 heap ，然后用 shark 库分析 heap ，找出一个到 GC ROOT 的最短引用链并提示。

常见的内存泄漏的场景

个人总结了下工作中碰到内存泄漏的一些场景，现记录下来，大家可以参考下。

静态变量持有 Context 等。
单例实例持有 Context 等。
一些回调没有反注册，比如广播的注册和反注册等，有时候一些第三方库也需要注意。
一些 Listener 没有手动断开连接。
匿名内部类持有外部类的实例。比如 Handler , Runnable 等常见的用匿名内部类的实现，常常会不小心持有 Context 等外部类实例。

/ 操作流畅度优化 /

为什么会卡顿

为什么卡顿之前，我们先需要简单了解一点硬件相关的知识。就是在界面绘制的过程中， CPU 主要的任务是计算出屏幕上所有 View 对应的图形和向量等信息。GPU 的主要任务就是把 CPU 计算出的图形栅格化并转化为位图，可以简单理解为屏幕像素点对应的值。

如果操作过程中卡顿了，一般就是 CPU 和 GPU 其中的一个或者多个无法短时间完成对应的任务。

一般而言，CPU 除了需要计算 View 对应的图形和向量等信息，还要做逻辑运算和文件读写等任务，所以 CPU 造成卡顿更常见。一般也是通过减少 CPU 的计算任务来优化卡顿。

影响 CPU 的使用率一般有以下几个方面：

读写文件
解析大量图片
频繁请求网络
复杂的布局
频繁创建对象

如何检测卡顿

虽然我们知道了大概哪些原因会导致卡顿，但是我们无法准确定位出问题的代码点在哪里，针对上面的部分问题，本人写了一个开源库来自动检测。

开源库地址：

https://github.com/XanderWang/performance

详细的原理，可以参考上面的连接，这里简单总结下监控 UI 卡段的原理。

我们知道，Android 里面，界面的刷新需要再主线程或者说 UI 线程执行。而界面的绘制起始点又利用了 Looper 消息循环机制。Looper 消息循环机制有一个有意思的特点，就是 Looper 在 dispatch Message 的时候，会在 dispatch 前和 dispatch 后利用 Printer 打印特定 tag 的字符串，通过接管 Printer ，我们就可以获取 dispatch message 前后的时机。

然后我们可以在 dispatch message 之前，在异步线程启动一个抓取系统信息的延时任务。在 dispatch message 之后，我们可以移除异步线程的这个延时任务。如果某个消息的执行没有超过阈值，那就表示在异步线程的延时任务被取消，表明没有卡顿。如果某个消息的执行时间超过了阈值，那异步线程里的延时任务就会执行，表明有卡顿，异步线程的延时任务会获取此时的系统状态，从而辅助我们分析卡顿问题。

如何优化卡顿

如何检测说完了，我们来说说如何优化。在为什么会卡顿小结我总结了几种常见，现在对几种场景的优化总结下。

读写文件

最常见的一个读写文件而不自知的就是 SharePerfrences 的使用，使用 sp 的时候需要注意不要频繁调用 apply 或者 commit 方法，因为每调用一次就有可能会有一次写文件操作(高版本系统做了优化 apply 做了优化，不一定会写文件)。所以，如果调用次数多的话，就会多次写文件，写文件又是一个耗时且耗资源的操作，所以要少做。

一般优化方法是合理拆分 sp 文件，一个 sp 文件不要包含太多的项，同时每一项的内容尽量短。尽量批量提交数据后再 commit 或者 apply 。同时需要注意的是 commit 会直接触发写文件(内容有变化的时候)，所以如果在 UI 线程调用 commit 方法需要注意可能会阻塞 UI 线程。

如果有更高的性能需求，可以考虑用 mmkv 来替换或者 DataStore 来替换 sp 。具体的替换方法就不细说了。网上有很多资料参考。

另外一个常见的读写文件的场景是从 xml 文件里面读取布局、色值等操作，这些都是一些 io 操作。从 xml 读取布局的话，可以考虑用代码直接创建 view 来优化，从 xml 里面读取颜色可以考虑加个 HashMap 来优化。

解析大量图片

解码图片毫无疑问是一个计算量大的操作，所以一般加载图片的时候最好根据实际显示的尺寸做压缩，并且保存压缩后的缩略图，方便下次直接加载。

另外还需要注意列表滚动过程中，控制对图片的加载，一般列表在滑动过程中，不加载图片，等列表滚动停止后，才开始加载图片。

另外的一个优化的方法就是减少图片的使用，不过这个难度有点大。

另外还可以考虑针对不同的图片格式，用不同的解码格式。比如 png 格式的图片根据机器实际情况选择 8888 或者 4444 解码方式解码图片。如果是 jpg/jpeg 格式的图片，就用 565 的解码方式解码图片。对于用不同的解码方式解码图片，效率是否会高，本人没做过测试，但是毫无疑问，内存的使用是不同的。