Android项目优化记录

项目优化点

1.OOM和崩溃优化

1.1 OOM优化

1.2 ANR优化

1.3 Crash优化

2.内存泄漏优化

2.0 动画资源未释放

2.1 错误使用单利

2.2 错误使用静态变量

2.3 handler内存泄漏

2.4 线程造成内存泄漏

2.5 非静态内部类

2.6 未移除监听

2.7 持有activity引用

2.8 资源未关闭

2.9 其他原因

3.布局优化

3.1 include优化

3.2 ViewStub优化

3.3 merge优化

3.4 其他建议

4.代码优化

4.1 lint代码检测

4.2 代码规范优化

4.3 View异常优化

4.4 去除淡黄色警告优化

4.5 合理使用集合

4.6 Activity不可见优化

4.7 节制的使用Service

5.网络优化

5.1 图片分类

5.2 获取网络数据优化

5.3 网络请求异常拦截优化

6.线程优化

6.1 使用线程池

7.图片优化

7.1 bitmap优化

7.2 glide加载优化

8.加载优化

8.1 懒加载优化

8.2 启动页优化

9.其他优化

9.1 静态变量优化

9.2 注解替代枚举

9.3 多渠道打包优化

9.4 TrimMemory和LowMemory优化

9.5 轮询操作优化

9.6 去除重复依赖库优化

9.7 四种引用优化

9.8 加载loading优化

9.9 对象池Pools优化

10.RecyclerView优化

10.1 页面为何卡顿

10.2 具体优化方案

1.OOM和崩溃优化

1.2 ANR优化

ANR的产生需要满足三个条件

主线程：只有应用程序进程的主线程响应超时才会产生ANR；

超时时间：产生ANR的上下文不同，超时时间也会不同，但只要在这个时间上限内没有响应就会ANR；

输入事件/特定操作：输入事件是指按键、触屏等设备输入事件，特定操作是指BroadcastReceiver和Service的生命周期中的各个函数，产生ANR的上下文不同，导致ANR的原因也会不同；

ANR优化具体措施

将所有耗时操作，比如访问网络，Socket通信，查询大量SQL 语句，复杂逻辑计算等都放在子线程中去，然 后通过handler.sendMessage、runonUIThread、AsyncTask 等方式更新UI。无论如何都要确保用户界面作的流畅 度。如果耗时操作需要让用户等待，那么可以在界面上显示度条。

使用AsyncTask处理耗时IO操作。在一些同步的操作主线程有可能被锁，需要等待其他线程释放相应锁才能继续执行，这样会有一定的ANR风险，对于这种情况有时也可以用异步线程来执行相应的逻辑。另外，要避免死锁的发生。

使用Handler处理工作线程结果，而不是使用Thread.wait()或者Thread.sleep()来阻塞主线程。

Activity的onCreate和onResume回调中尽量避免耗时的代码

BroadcastReceiver中onReceive代码也要尽量减少耗时，建议使用IntentService处理。

各个组件的生命周期函数都不应该有太耗时的操作，即使对于后台Service或者ContentProvider来讲，应用在后台运行时候其onCreate()时候不会有用户输入引起事件无响应ANR，但其执行时间过长也会引起Service的ANR和ContentProvider的ANR

2.内存泄漏优化

内存检测第一种：代码方式获取内存

/**

 * 内存使用检测：可以调用系统的getMemoryInfo()来获取当前内存的使用情况

 */

private void initMemoryInfo() {

    ActivityManager activityManager = (ActivityManager) Utils.getApp()

            .getSystemService(Context.ACTIVITY_SERVICE);

    ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();

    if (activityManager != null) {

        activityManager.getMemoryInfo(memoryInfo);

        LogUtils.d("totalMem=" + memoryInfo.totalMem + ",availMem=" + memoryInfo.availMem);

        if (!memoryInfo.lowMemory) {

            // 运行在低内存环境

        }

    }

}

复制代码

内存检测第二种：leakcanary工具

LeakCanary的原理是监控每个activity，在activity style="margin: 0px; padding: 0px;  font-size: 16px; color: rgb(51, 51, 51); font-family: mp-quote, -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;      text-align: justify;        ">2.0 动画资源未释放

2.1 错误使用单利

2.2 错误使用静态变量

2.3 handler内存泄漏

2.4 线程造成内存泄漏

2.5 非静态内部类

2.6 未移除监听

2.7 持有activity引用

2.8 资源未关闭

静态集合使用不当导致的内存泄漏

不需要用的监听未移除会发生内存泄露

有时候我们需要把一些对象加入到集合容器（例如ArrayList）中，当不再需要当中某些对象时，如果不把该对象的引用从集合中清理掉，也会使得GC无法回收该对象。如果集合是static类型的话，那内存泄漏情况就会更为严重。因此，当不再需要某对象时，需要主动将之从集合中移除。

问题代码

//add监听，放到集合里面

tv.getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {

    @Override

    public void>        //监听view的加载，view加载出来的时候，计算他的宽高等。

    }

});

复制代码

解决办法

//计算完后，一定要移除这个监听

tv.getViewTreeObserver().removeOnWindowFocusChangeListener(this);

复制代码

注意事项：

tv.setOnClickListener();//监听执行完回收对象，不用考虑内存泄漏

tv.getViewTreeObserver().addOnWindowFocusChangeListene,add监听，放到集合里面，需要考虑内存泄漏

复制代码

重用布局文件

标签可以允许在一个布局当中引入另一个布局，那么比如说我们程序的所有界面都有一个公共的部分，这个时候最好的做法就是将这个公共的部分提取到一个独立的布局中，然后每个界面的布局文件当中来引用这个公共的布局。

如果我们要在标签中覆写layout属性，必须要将layout_width和layout_height这两个属性也进行覆写，否则覆写效果将不会生效。

标签是作为标签的一种辅助扩展来使用的，它的主要作用是为了防止在引用布局文件时引用文件时产生多余的布局嵌套。布局嵌套越多，解析起来就越耗时，性能就越差。因此编写布局文件时应该让嵌套的层数越少越好。

举例：比如在LinearLayout里边使用一个布局。里边又有一个LinearLayout，那么其实就存在了多余的布局嵌套，使用merge可以解决这个问题。

仅在需要时才加载布局[ViewStub]

自定义全局的状态管理器【充分使用ViewStub】

某个布局当中的元素不是一起显示出来的，普通情况下只显示部分常用的元素，而那些不常用的元素只有在用户进行特定操作时才会显示出来。

举例：填信息时不是需要全部填的，有一个添加更多字段的选项，当用户需要添加其他信息的时候，才将另外的元素显示到界面上。用VISIBLE性能表现一般，可以用ViewStub。

ViewStub也是View的一种，但是没有大小，没有绘制功能，也不参与布局，资源消耗非常低，可以认为完全不影响性能。

ViewStub所加载的布局是不可以使用标签的，因此这有可能导致加载出来出来的布局存在着多余的嵌套结构。

针对多状态，有数据，空数据，加载失败，加载异常，网络异常等。针对空数据，加载失败，异常使用viewStub布局，一键设置自定义布局，也是优化的一种。

项目地址：

视图层级

这个标签在UI的结构优化中起着非常重要的作用，它可以删减多余的层级，优化UI。但是就有一点不好，无法预览布局效果！

减少太多重叠的背景(overdraw)

避免复杂的Layout层级

这个问题其实最容易解决，建议就是检查你在布局和代码中设置的背景，有些背景是隐藏在底下的，它永远不可能显示出来，这种没必要的背景一定要移除，因为它很可能会严重影响到app的性能。如果采用的是selector的背景，将normal状态的color设置为”@android:color/transparent”,也同样可以解决问题。

这里的建议比较多一些，首先推荐使用Android提供的布局工具Hierarchy Viewer来检查和优化布局。第一个建议是：如果嵌套的线性布局加深了布局层次，可以使用相对布局来取代。第二个建议是：用标签来合并布局。第三个建议是：用标签来重用布局，抽取通用的布局可以让布局的逻辑更清晰明了。记住，这些建议的最终目的都是使得你的Layout在Hierarchy Viewer里变得宽而浅，而不是窄而深。

总结：可以考虑多使用merge和include，ViewStub。尽量使布局浅平，根布局尽量少使用RelactivityLayout,因为RelactivityLayout每次需要测量2次。

都是一些微优化，在性能方面看不出有什么显著的提升的。使用合适的算法和数据结构是优化程序性能的最主要手段。

lint去除无效资源和代码

使用Android Studio的Lint，步骤：点击菜单栏 Analyze -> Run Inspection by Name -> unused declaration -> Moudule ‘app’ -> OK

点击菜单栏 Analyze -> Run Inspection by Name -> unused resources -> Moudule ‘app’ -> OK，这样会搜出来哪些未被使用到未使用到xml和图片，如下：

如何检测哪些图片未被使用

如何检测哪些无效代码

避免创建不必要的对象 不必要的对象应该避免创建：

静态优于抽象

对常量使用static final修饰符

在没有特殊原因的情况下，尽量使用基本数据类型来代替封装数据类型，int比Integer要更加有效，其它数据类型也是一样。

如果有需要拼接的字符串，那么可以优先考虑使用StringBuffer或者StringBuilder来进行拼接，而不是加号连接符，因为使用加号连接符会创建多余的对象，拼接的字符串越长，加号连接符的性能越低。

当一个方法的返回值是String的时候，通常需要去判断一下这个String的作用是什么，如果明确知道调用方会将返回的String再进行拼接操作的话，可以考虑返回一个StringBuffer对象来代替，因为这样可以将一个对象的引用进行返回，而返回String的话就是创建了一个短生命周期的临时对象。

尽可能地少创建临时对象，越少的对象意味着越少的GC操作。

nDraw方法里面不要执行对象的创建

如果你并不需要访问一个对系那个中的某些字段，只是想调用它的某些方法来去完成一项通用的功能，那么可以将这个方法设置成静态方法，调用速度提升15%-20%，同时也不用为了调用这个方法去专门创建对象了，也不用担心调用这个方法后是否会改变对象的状态(静态方法无法访问非静态字段)。

static int intVal = 42;  static String strVal = "Hello, world!";

编译器会为上面的代码生成一个初始方法，称为方法，该方法会在定义类第一次被使用的时候调用。这个方法会将42的值赋值到intVal当中，从字符串常量表中提取一个引用赋值到strVal上。当赋值完成后，我们就可以通过字段搜寻的方式去访问具体的值了。

final进行优化:

static final int intVal = 42;  static final String strVal = "Hello, world!";

这样，定义类就不需要方法了，因为所有的常量都会在dex文件的初始化器当中进行初始化。当我们调用intVal时可以直接指向42的值，而调用strVal会用一种相对轻量级的字符串常量方式，而不是字段搜寻的方式。

这种优化方式只对基本数据类型以及String类型的常量有效，对于其他数据类型的常量是无效的。

基本数据类型的数组也要优于对象数据类型的数组。另外两个平行的数组要比一个封装好的对象数组更加高效，举个例子，Foo[]和Bar[]这样的数组，使用起来要比Custom(Foo,Bar)[]这样的一个数组高效的多。

view自定义控件异常销毁保存状态

经常容易被人忽略，但是为了追求高质量代码，这个也有必要加上。举个例子！

@Override

protected Parcelable>    //异常情况保存重要信息。

    //return super.onSaveInstanceState();

    final Bundle bundle = new Bundle();

    bundle.putInt("selectedPosition",selectedPosition);

    bundle.putInt("flingSpeed",mFlingSpeed);

    bundle.putInt("orientation",orientation);

    return bundle;

}

@Override

protected void>    if (state instanceof Bundle) {

        final Bundle bundle = (Bundle) state;

        selectedPosition = bundle.getInt("selectedPosition",selectedPosition);

        mFlingSpeed = bundle.getInt("flingSpeed",mFlingSpeed);

        orientation = bundle.getInt("orientation",orientation);

        return;

    }

    super.onRestoreInstanceState(state);

}

复制代码

淡黄色警告虽然不会造成崩溃，但是作为程序员还是要尽量去除淡黄色警告，规范代码

使用优化过的数据集合

Android提供了一系列优化过后的数据集合工具类，如SparseArray、SparseBooleanArray、LongSparseArray，使用这些API可以让我们的程序更加高效。HashMap工具类会相对比较低效，因为它需要为每一个键值对都提供一个对象入口，而SparseArray就避免掉了基本数据类型转换成对象数据类型的时间。

当Activity界面不可见时释放内存

当时看到这个觉得很新奇的，但是具体还是没有用到，要是那个大神有具体操作方案，可以分享一下。

当用户打开了另外一个程序，我们的程序界面已经不可见的时候，我们应当将所有和界面相关的资源进行释放。重写Activity的onTrimMemory()方法，然后在这个方法中监听TRIM_MEMORY_UI_HIDDEN这个级别，一旦触发说明用户离开了程序，此时就可以进行资源释放操作了。

节制的使用Service

如果应用程序需要使用Service来执行后台任务的话，只有当任务正在执行的时候才应该让Service运行起来。当启动一个Service时，系统会倾向于将这个Service所依赖的进程进行保留，系统可以在LRUcache当中缓存的进程数量也会减少，导致切换程序的时候耗费更多性能。我们可以使用IntentService，当后台任务执行结束后会自动停止，避免了Service的内存泄漏。

图片网络优化

比如我之前看到豆瓣接口，提供一种加载图片方式特别好。接口返回图片的数据有三种，一种是高清大图，一种是正常图片，一种是缩略小图。当用户处于wifi下给控件设置高清大图，当4g或者3g模式下加载正常图片，当弱网条件下加载缩略图【也称与加载图】。

简单来说根据用户的当前的网络质量来判断下载什么质量的图片（电商用的比较多）。豆瓣开源接口可以参考一下！

移动端获取网络数据优化的几个点

连接复用：节省连接建立时间，如开启 keep-alive。

请求合并：即将多个请求合并为一个进行请求，比较常见的就是网页中的CSS Image Sprites。如果某个页面内请求过多，也可以考虑做一定的请求合并。

减少请求数据的大小：对于post请求，body可以做gzip压缩的，header也可以做数据压缩(不过只支持http

对于Android来说默认情况下HttpURLConnection和HttpClient都开启了keep-alive。只是2.2之前HttpURLConnection存在影响连接池的Bug，具体可见：Android HttpURLConnection及HttpClient选择

返回数据的body也可以做gzip压缩，body数据体积可以缩小到原来的30%左右。（也可以考虑压缩返回的json数据的key数据的体积，尤其是针对返回数据格式变化不大的情况，支付宝聊天返回的数据用到了）

在获取数据的流程中，访问接口和解析数据时都有可能会出错，我们可以通过拦截器在这两层拦截错误。

@Override

public void>    //直接调用即可

    ExceptionUtils.handleException(e);

}

复制代码

1.在访问接口时，我们不用设置拦截器，因为一旦出现错误，Retrofit会自动抛出异常。比如，常见请求异常404，500，503等等。

2.在解析数据时，我们设置一个拦截器，判断Result里面的code是否为成功，如果不成功，则要根据与服务器约定好的错误码来抛出对应的异常。比如，token失效，禁用同账号登陆多台设备，缺少参数，参数传递异常等等。

3.除此以外，为了我们要尽量避免在View层对错误进行判断，处理，我们必须还要设置一个拦截器，拦截onError事件，然后使用ExceptionUtils，让其根据错误类型来分别处理。

具体可以直接看lib中的ExceptionUtils类，那么如何调用呢？入侵性极低，不用改变之前的代码！

将全局线程用线程池管理

参考：轻量级线程池封装库，支持异步回调，可以检测线程执行的状态

该项目中哪里用到频繁new Thread

保存图片[注意，尤其是大图和多图场景下注意耗时太久]；某些页面从数据库查询数据；设置中心清除图片，视频，下载文件，日志，系统缓存等缓存内容

使用线程池管理库好处，比如保存图片，耗时操作放到子线程中，处理过程中，可以检测到执行开始，异常，成功，失败等多种状态。

RxJava，RxAndroid，底层对线程池的封装管理特别值得参考

重用线程池中的线程，避免频繁地创建和销毁线程带来的性能消耗；有效控制线程的最大并发数量，防止线程过大导致抢占资源造成系统阻塞；可以对线程进行一定地管理。

大量的线程的创建和销毁很容易导致GC频繁的执行，从而发生内存抖动现象，而发生了内存抖动，对于移动端来说，最大的影响就是造成界面卡顿

线程的创建和销毁都需要时间，当有大量的线程创建和销毁时，那么这些时间的消耗则比较明显，将导致性能上的缺失

直接创建Thread实现runnable方法的弊端

为什么要用线程池

使用线程池管理的经典例子

关于线程池，线程，多线程的具体内容

加载图片所占的内存大小计算方式

第一种加载图片优化处理：压缩图片

第二种加载图片优化：不压缩加载高清图片如何做？

加载网络图片：bitmap内存大小 = 图片长度 x 图片宽度 x 单位像素占用的字节数【看到网上很多都是这样写的，但是不全面】

加载本地图片：bitmap内存大小 = width * height * nTargetDensity/inDensity 一个像素所占的内存。注意不要忽略了一个影响项：Density

质量压缩方法：在保持像素的前提下改变图片的位深及透明度等，来达到压缩图片的目的，这样适合去传递二进制的图片数据，比如分享图片，要传入二进制数据过去，限制500kb之内。

采样率压缩方法：设置inSampleSize的值(int类型)后，假如设为n，则宽和高都为原来的1/n，宽高都减少，内存降低。

缩放法压缩：Android中使用Matrix对图像进行缩放、旋转、平移、斜切等变换的。功能十分强大！

使用BitmapRegionDecoder，主要用于显示图片的某一块矩形区域，如果你需要显示某个图片的指定区域，那么这个类非常合适。

在画廊中加载大图

假如你滑动特别快，glide加载优化就显得非常重要呢，具体优化方法如下所示

recyclerView.addOnScrollListener(new RecyclerView.OnScrollListener() {

    @Override

    public void>        super.onScrollStateChanged(recyclerView, newState);

        if (newState == RecyclerView.SCROLL_STATE_IDLE) {

            LoggerUtils.e("initRecyclerView"+ "恢复Glide加载图片");

            Glide.with(ImageBrowseActivity.this).resumeRequests();

        }else {

            LoggerUtils.e("initRecyclerView"+"禁止Glide加载图片");

            Glide.with(ImageBrowseActivity.this).pauseRequests();

        }

    }

});

复制代码

该优化在新闻类app中十分常见

具体看这篇文章

ViewPager+Fragment的搭配在日常开发中也比较常见，可用于切换展示不同类别的页面。

懒加载,其实也就是延迟加载,就是等到该页面的UI展示给用户时,再加载该页面的数据(从网络、数据库等),而不是依靠ViewPager预加载机制提前加载两三个，甚至更多页面的数据。这样可以提高所属Activity的初始化速度,也可以为用户节省流量.而这种懒加载的方式也已经/正在被诸多APP所采用。

启动时间分析

启动时间优化

启动页白屏优化

启动时间优化

系统创建进程的时间和应用进程启动的时间，前者是由系统自行完成的，一般都会很快，我们也干预不了，我觉得能做的就是去优化应用进程启动，具体说来就是从发Application的onCreate()执行开始到MainActivity的onCreate()执行结束这一段时间。

延迟初始化

后台任务

启动界面预加载

Application的onCreate()方法

MainActivity的onCreate()方法

优化的手段也无非三种，如下所示：

常见有三种，这里解决办法是给当前启动页添加一个有背景的style样式，然后SplashActivity引用当前theme主题，注意在该页面将window的背景图设置为空！

更多关于启动页为什么白屏闪屏，以及不同解决办法，可以看我这篇博客：App启动页面优化

当系统启动一个APP时，zygote进程会首先创建一个新的进程去运行这个APP，但是进程的创建是需要时间的，在创建完成之前，界面是呈现假死状态，于是系统根据你的manifest文件设置的主题颜色的不同来展示一个白屏或者黑屏。而这个黑（白）屏正式的称呼应该是Preview Window，即预览窗口。

实际上就是是activity默认的主题中的android:windowBackground为白色或者黑色导致的。

总结来说启动顺序就是：app启动——Preview Window(也称为预览窗口)——启动页

为什么存在这个问题？

解决办法

现在application初始化内容有：阿里云推送初始化，腾讯bugly初始化，im初始化，神策初始化，内存泄漏工具初始化，头条适配方案初始化，阿里云热修复……等等。将部分逻辑放到IntentService中处理，可以缩短很多时间。

开启IntentSerVice线程，将部分逻辑和耗时的初始化操作放到这里处理，可以减少application初始化时间

关于IntentService使用和源码分析，性能分析等可以参考博客：IntentService源码分析

IntentService子线程分担部分初始化工作

尽量不使用静态变量保存核心数据。这是为什么呢？- 这是因为android的进程并不是安全的，包括application对象以及静态变量在内的进程级别变量并不会一直呆着内存里面，因为它很有会被kill掉。- 当被kill掉之后，实际上app不会重新开始启动。Android系统会创建一个新的Application对象，然后启动上次用户离开时的activity以造成这个app从来没有被kill掉的假象。而这时候静态变量等数据由于进程已经被杀死而被初始化，所以就有了不推荐在静态变量（包括Application中保存全局数据静态数据）的观点。

二、重要提示

上京东选好货，京东省钱内购，详情查看下图二维码....

获取更多内容关注公众号：