Android App性能优化

最新推荐文章于 2023-09-25 09:24:30 发布

Purity0303

最新推荐文章于 2023-09-25 09:24:30 发布

阅读量320

点赞数

分类专栏： Android App性能优化文章标签： android 优化性能布局

本文链接：https://blog.csdn.net/qq_23668969/article/details/65630490

版权

Android App性能优化专栏收录该内容

1 篇文章 0 订阅

订阅专栏

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

用户容易在UI执行动画或者滑动ListView的时候感知到卡顿不流畅，是因为这里的操作相对复杂，容易发生丢帧的现象，从而感觉卡顿。有很多原因可以导致丢帧，也许是因为你的layout太过复杂，无法在16ms内完成渲染，有可能是因为你的UI上有层叠太多的绘制单元，还有可能是因为动画执行的次数过多。这些都会导致CPU或者GPU负载过重。

Understanding Overdraw

Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源。

我们可以通过手机设置里面的开发者选项，打开Show GPU Overdraw的选项，可以观察UI上的Overdraw情况。

蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。

Overdraw有时候是因为你的UI布局存在大量重叠的部分，还有的时候是因为非必须的重叠背景。例如某个Activity有一个背景，然后里面的Layout又有自己的背景，同时子View又分别有自己的背景。仅仅是通过移除非必须的背景图片，这就能够减少大量的红色Overdraw区域，增加蓝色区域的占比。这一措施能够显著提升程序性能。

Refresh Rate：代表了屏幕在一秒内刷新屏幕的次数，这取决于硬件的固定参数，例如60Hz。
Frame Rate：代表了GPU在一秒内绘制操作的帧数，例如30fps，60fps。

布局优化
- 避免OverDraw过渡绘制
- 优化布局层级
- 避免嵌套过多无用布局
- 当我们在画布局的时候，如果能实现相同的功能，优先考虑相对布局，然后在考虑别的布局，不要用绝对布局。
- 使用<include />标签把复杂的界面需要抽取出，把重复使用的布局抽出来
代码优化
- 使用AndroidLint分析结果进行相应优化
- 不使用枚举及IOC框架，反射性能低
- 常量加static
- 静态方法
- 减少不必要的对象、成员变量
- 尽量使用线程池
- 适当使用软引用和弱引用
- 尽量使用静态内部类，避免潜在的内存泄露
- 图片缓存，采用内存缓存LRUCache和硬盘缓存DiskLRUCache
- Bitmap优化，采用适当分辨率大小并及时回收

减小对象的内存占用

避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象。

1）使用更加轻量的数据结构

例如，我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据结构。图8演示了HashMap的简要工作原理，相比起Android专门为移动操作系统编写的ArrayMap容器，在大多数情况下，都显示效率低下，更占内存。通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效，在于他们避免了对key与value的自动装箱（autoboxing），并且避免了装箱后的解箱。

2）避免在Android里面使用Enum

1）枚举会增加dex文件大小

前面说到枚举也是一个类，那么对于枚举的定义，看似简单，我们可以看下在Android工程的bin/classes/包名目录下，查看相关的编译时候的class类的文件，我们可以发现和内部类一样，枚举也会生成一个类文件

2）枚举会增加dex文件方法数量

通过前面的介绍后，我们已经很容易想到这个问题。枚举作为一个类，除了本身的一些方法外，编译器还会额外增加几个方法。如前面介绍的values()、valueOf()，另外还有构造函数等等以及在使用switch的时候，额外增加的函数。这样枚举的数量越多，必然导致方法数量的增加。对于大型的App，dex文件为了规避早期版本的65535方法数限制，一直在努力的减少方法数量，手淘也会经常因为方法数的超限而导致无法打包。而代码中枚举这样的隐晦的类及其包括的方法，如果能够减少也是减少方法数量的一个新途径，可谓踏遍铁鞋无觅处，得来全不费工夫

3）枚举会增加内存的使用

我们知道，int等类型的常量，在编译的时候，编译器会做优化，在生成class字节码的过程中就已经直接替换掉了，这样可以提升性能。而枚举不同，虽然本质上和int值类似，但是它会为每个枚举项导出static和final域的实例。前面关于单例的文章中已经提到，枚举其实也是一个单例。这样一旦引用该枚举的时候，就会触发虚拟机加载该枚举类，并且实例化所有的枚举项，并且这些枚举实例的内存无法回收，而且枚举是单例，如果自定义的枚举类中包含了大块内存的引用，也可能会带来内存泄露。

4）枚举会增加字符串常量

枚举的每一项，编译器都会自动生成对应的字符串常量，以便后续的函数中方便获得枚举的名字。

5）枚举会增加函数调用时间

枚举的使用会产生函数调用时间的开销，在高频率情况下就会产生一定的性能问题。我们可以通过代码测试和TraceView来跟踪这个函数的调用。

3）减小Bitmap对象的内存占用

Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，通常来说有以下2个措施：

inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。
decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。

4）使用更小的图片

在涉及给到资源图片时，我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片。尽量使用更小的图片不仅可以减少内存的使用，还能避免出现大量的InflationException。假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而发生InflationException，这个问题的根本原因其实是发生了OOM。

5）避免在onDraw方法里面执行对象的创建

类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作，因为他会迅速增加内存的使用，而且很容易引起频繁的gc，甚至是内存抖动

6）StringBuilder

在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”。