Android 性能优化总结

时间  2021-04-22
标签 html java python linux android git github shell 浏览器 性能优化 栏目 Android 繁體版
原文   原文链接

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

有哪些方面须要优化

在平时的优化过程当中咱们须要从哪几个点来优化呢？其实咱们平时本身必定也用过软件，在使用软件的过程当中有没有什么想吐槽的呢？java

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

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

固然，须要优化的不只仅是这几个方面，我作的比较多的优化是这几个方面，暂时就这几个方面来谈谈优化吧。linux

APK 瘦身

如何查看 APK 的组成

若是要优化 APK 的大小，咱们首先须要知道咱们编译出来的 APK 都包含哪些东西，而后针对占用大的作裁剪，或者删除不须要的东西，从而达到瘦身的目的。android

查看 APK 的内容占用状况很简单，打开 AS ，把 APK 拖到 AS 里面就能够查看 APK 包含的内容了。git

资源预览

能够看到占大头的是 res 代码等，因此瘦身能够从这几个方面来考虑。github

如何减小 res 资源大小

  1. 删除冗余的资源

通常随着项目的迭代，部分图片等资源再也不使用了，可是可能仍然被编译到了 apk 里面，因此能够删除这部分再也不使用的资源，可使用 lint 工具来搜索项目中再也不使用的图片等资源。shell

  1. 重复资源的优化

除了有冗余资源，还有些是文件名不同，可是内容同样的图片，能够经过比较 md5 值来判断是否是同样的资源，而后编辑 resources.arsc 来重定向。浏览器

  1. 图片压缩

未压缩的图片文件占用空间较大，能够考虑压缩未压缩过的图片来瘦身。经常使用的工具是 tinypng 网站。性能优化

同时也能够借助 TinyPngPlugin 等插件或者其余开源工具来帮助压缩图片。

  1. 资源混淆

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

  1. 指定语言

若是没有特殊的需求的话，能够只编译中文，由于其余的语言用不上，若是用不上的语言编译了，会在 resource 的表里面占用大量的空间，故

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

如何减小 so 库资源大小

  1. 本身编译的 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")
  1. 别人编译的 so

联系做者修改，通常很难联系到。

  1. 动态下发 so

能够经过服务器下发 so , 下载完后再进入应用，可是体验很差，可是是一个思路。

  1. 只编译指定平台的 so

通常咱们都是给 arm 平台的机器开发，若是没有特殊状况，咱们通常只须要考虑 arm 平台的。具体的方法是 app 下的 build.gradle 添加以下代码

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

各个平台的差异以下：

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

如何减小代码资源大小

  1. 一个功能尽可能用一个库

好比加载图片库，不要 glide 和 fresco 混用，由于功能是相似的，只是使用的方法不同，用了多个库来作相似的事情，代码确定就变多了。

  1. 混淆

混淆的话，减小了生成的 class 大小，这样聚沙成塔，也能够从必定层度减小 apk 的大小。

  1. R 文件内联

经过把 R 文件里面的资源内联到代码中，从而减小 R 文件的大小。

可使用 shrink-r-plugin 工具来作 R 文件的内联

参考文档

Android App包瘦身优化实践

启动速度

启动的类型

通常分为，冷启动和热启动

> 冷启动：启动时，后台没有任何该应用的进程，系统须要从新建立一个进程，并结合启动参数启动该应用。

> 热启动：启动时，系统已经有该应用的进程(好比按 home 键临时退出该应用)下启动该应用。

如何获取启动时间

  1. 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 的启动时间。

  1. 时间戳

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

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

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

如何监控启动过程

  1. 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 就能够看到详细的启动信息。

  1. 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 过程当中的方法调用等信息，也能够较好的分析启动问题。

通常有那些优化方法

  1. 耗时操做放到异步进程

好比文件解压、读写等耗时 IO 操做能够新开一个线程来执行。

  1. 延时初始化

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

  1. 线程优化

线程的建立须要消耗较多的系统系统资源，减小线程的建立。能够考虑共用一个线程池。

如何检测线程的建立，能够参考我个开源库 performance

稳定性优化

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 代码的崩溃捕获机制及实现。

如何治理 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 内存堆栈后，还能够看到各个类占用的内存状况。

有关每一个已分配对象的详细信息显示在右侧的 Instance View 中

能够查看每一个对象的详细信息。

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

如何合理使用内存

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

  • 图片相关的优化

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

  1. 暂时用不上的图片不加载，好比说，有个网络加载异常的图，不要一开始就初始化，等到真的有异常了须要展现的时候再初始化
  2. 加载图片的时候，尽可能加载指定大小的图片，由于有时候会碰到控件的大小小于实际图片尺寸的状况，这个时候，会浪费一些内存。有须要的话，可让后台返回不一样尺寸的图片。
  3. 根据不一样的图片格式
  4. 不显示的图片，能够考虑先释放。
  • 尽量少地建立对象

毫无疑问，若是对象少，内存确定也消耗的少，那平时须要注意哪些呢？

  1. 自定义 view 的时候，不要在 onDraw 方法里面频繁建立对象。由于 onDraw 方法可能会频繁调用，这个时候就会建立大量的对象。从而形成浪费，同时也会致使 gc 触发的频率升高，形成卡顿。
  2. 尽可能少建立线程，建立线程实际上是比较消耗资源的，建立一个空的线程，大概会占用 1-2 M 内存。同时通常异步任务很快就会执行完，若是频繁建立线程来作异步任务，除了内存使用的多，还可能 GC 形成卡顿。执行异步任务的话，通常建议用线程池来执行，可是须要注意线程池的使用。
  3. 尽可能用 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 的最短引用链并提示。

常见的内存泄漏的场景

我的总结了下工做中碰到内存泄漏的一些场景，现记录下来，你们能够参考下。

  1. 静态变量持有 Context 等。
  2. 单例实例持有 Context 等。
  3. 一些回调没有反注册，好比广播的注册和反注册等，有时候一些第三方库也须要注意。
  4. 一些 Listener 没有手动断开链接。
  5. 匿名内部类持有外部类的实例。好比 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 的解码方式解码图片。对于用不一样的解码方式解码图片，效率是否会高，本人没作过测试，可是毫无疑问，内存的使用是不一样的。

频繁请求网络

网络请求的话，能够参考下面的优化方法。

  1. 若是使用 okhttp 请求网络的话，尽可能全局使用一个 httpclient ，这样作的好处是能够复用，提升网络请求效率。

  2. 后台支持的话，开启 gzip 压缩，这样网络传输的数据量小些，传输效率会高些。

  3. 自定义 dns ，减小解析 dns 的时间。

  4. 经过和后台商量，部分数据后台接口一步到位，尽可能避免屡次请求后才拿到完整的目标数据。

复杂的布局

若是布局复杂的话， CPU 要进行大量的计算才能够肯定最终的图形。因此布局复杂的话，CPU 须要大量的运算资源，因此优化复杂的布局是颇有必要的。

  1. 减小布局层次，能够利用 ViewStub 、merge 和 include 等标签来尝试减小布局层次。

  2. 使用高效的布局容器，好比 ConstraintLayout，能够不用嵌套布局容器来实现复杂效果。

  3. 部分效果能够考虑用自定义 View 实现。

这个优化感受不是特别好作，可能优化了，可是效果很差，可是又不能不作。

频繁建立对象

为何这个要列出来呢？由于频繁建立对象，可能会短期内消耗大量内存，而后内存不足的时候系统就会尝试 GC 来回收对象，而 GC 是很耗资源的操做，虽然如今 Android 系统对 GC 作了不少优化，可是尽可能减小 GC 的触发老是好的。

通常频繁建立对象的场景有:

  • 自定义 View 的时候，在 onDraw 方法建立临时对象
  • 循环里面使用 "+" 拼接字符串
  • ArrayList 等有容积限制的容器类初始化的容量不合理，致使后续新增数据频繁扩容。

可能还有一些场景没有列出来，若是你们有好的建议，能够提出来。

除了频繁建立对象可能会触发 GC ，若是某次使用过大的内存也可能会致使 GC ，好比展现一个超大的 Bitmap ，虽然能够用缩略图来展现，可是可能会碰到须要放大查看具体细节的场景，这个时候能够考虑采用裁剪显示区域(BitmapRegionDecoder)的方式来解析图片。

小结

以上是我工做中涉及到的优化点，可能不是很全，也不免有遗漏。若是有错误和遗漏，还请你们指正。

联系我

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程