AndroidAPP性能优化总结

关于APP性能优化,需要做到如下几点:

  • App使用起来不卡顿、流畅
  • 省电、省流量
  • 稳定,不闪退(减少闪退,ANR率)
  • APP包尽量要小

卡顿优化

造成卡顿的原因

  • UI的绘制。主要原因是绘制的层级深、页面复杂、刷新不合理,由于这些原因导致卡顿的场景更多出现在在 UI、启动后的初始界面、跳转到页面的绘制上。

  • 数据处理上。导致这种卡顿场景的原因是数据处理量太大,一般分为三种情况

    • 一是数据在主线程处理,这个是初级工程师会犯的错误
    • 二是数据处理占用 CPU 高,导致主线程拿不到时间片
    • 三是内存增加导致 GC频繁,从而引起卡顿。引起卡顿的原因很多,但不管怎么样的原因和场景,最终都是通过设备屏幕上显示来达到用户,归根到底就是显示有问题,所以,要解决卡顿,就要先了解 Android 系统的渲染机制。
  • UI的过度绘制,绘制的页面有几层View,底层View都是隐藏的,这种的还绘制的话就会造成过度绘制

Andriod卡顿优化方案

  • 不要在主线程进行网络访问/大文件的IO操作
  • 绘制UI时,尽量减少绘制UI层次;减少不必要的view嵌套,可以用Hierarchy Viewer工具来检测,后面会详细讲;
  • 当我们的布局是用的FrameLayout的时候,我们可以把它改成merge,可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)
  • 提高显示速度,使用ViewStub:当加载的时候才会占用。不加载的时候就是隐藏的,仅仅占用位置。
  • 在view层级相同的情况下,尽量使用 LinerLayout而不是RelativeLayout;因为RelativeLayout在测量的时候会测量二次,而LinerLayout测量一次,可以看下它们的源码;
  • 删除控件中无用的属性;
  • 布局复用.比如listView 布局复用
  • 尽量避免过度绘制(overdraw),比如:背景经常容易造成过度绘制。由于我们布局设置了背景,同时用到的MaterialDesign的主题会默认给一个背景。这时应该把主题添加的背景去掉;还有移除 XML 中非必须的背景
  • 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域,只有在这个区域内才会被绘制。也是避免过度绘制.
  • 启动优化,启动速度的监控,发现影响启动速度的问题所在,优化启动逻辑,提高应用的启动速度。比如闪屏页面,合理优化布局,加载逻辑优化,数据准备,这里后面我会单独写一篇文章讲如何优化程序的启动速度及Splash页面设计,这里还会讲到热启动和冷启动.
  • 合理的刷新机制,尽量减少刷新次数,尽量避免后台有高的 CPU 线程运行,缩小刷新区域。

Android卡顿优化所用到的工具

性能问题并不容易复现,也不好定位,但是真的碰到问题就需要借助相应的的调试工具,下面介绍比较常用的调试工具。

  • Profile GPU Rendering
    在手机开发者模式下,有一个卡顿检测工具叫做:Profile GPU Rendering
    • 上图中的绿线代表16ms,要确保一秒内达到到60fps,需确保每帧的每条线在绿色16ms标记线之下
    • 下面的柱状图蓝色代表测量绘制时间,如果蓝色线很高【可能是因为你的一堆视图突然变得无效,或者你的几个自定义视图的onDraw函数过于复杂】
    • 柱状图红色代表执行的时间,这部分是Android进行2D渲染 Display List的时间,为了绘制到屏幕上,Android需要使用OpenGl ES的API接口来绘制Display List.这些API有效地将数据发送到GPU,最终在屏幕上显示出来.当你看到红色的线非常高的时候,这些复杂的自定义View就是罪魁祸首
    • 橙色部分表示的是处理时间,或者说是CPU告诉GPU渲染一帧的地方,这是一个阻塞调用,因为CPU会一直等待GPU发出接到命令的回复,如果柱状图很高,那就意味着你给GPU太多的工作,太多的负责视图需要OpenGL命令去绘制和处理.

总之,保持动画流畅的关键就在于让这些垂直的柱状条尽可能地保持在绿线下面,任何时候超过绿线,你就有可能丢失一帧的内容.

  • Debug GPU overDraw过度绘制检测
    在手机开发者模式下,有一个过度绘制检测工具叫做:Debug GPU overDraw

    • 原色:没有过度绘制
    • 蓝色:1 次过度绘制
    • 绿色:2 次过度绘制
    • 粉色:3 次过度绘制
    • 红色:4 次及以上过度绘制

耗电优化

在移动设备中,电池的重要性不言而喻,没有电什么都干不成。对于操作系统和设备开发商来说,耗电优化一直没有停止,去追求更长的待机时间,而对于一款应用来说,并不是可以忽略电量使用问题,特别是那些被归为“电池杀手”的应用,最终的结果是被卸载。因此,应用开发者在实现需求的同时,需要尽量减少电量的消耗。
耗电的原因其实很多,几种优化方案如下:

  • 合理的使用wack_lock锁,wack_lock锁主要是相对系统的休眠(这里就是为了省电,才做休)而言的,意思就是我的程序给CPU加了这个锁那系统就不会休眠了,这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题,比如微信等即时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了wake_lock锁。关于wake_lock的使用
  • 使用jobScheduler2,集中处理一些网络请求,有些不用很及时的处理可以放在充电的时候处理,比如,图片的处理,APP下载更新等等,这里有一篇关于jobScheduler的使用,请查阅;
  • 计算优化,避开浮点运算等。
  • 数据在网络上传输时,尽量压缩数据后再传输,建议用FlatBuffer序列化技术,这个比json效率高很多倍,不了解FlatBuffer,建议找资料学习一下,后面有时间的话,也会专门写关于FlatBuffer的文章。

andriod耗电分析所用到的工具

在 Android5.0 以前,在应用中测试电量消耗比较麻烦,也不准确,5.0 之后专门引入了一个获取设备上电量消耗信息的 API:Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系统电量分析工具,是一款图形化数据分析工具,直观地展示出手机的电量消耗过程,通过输入电量分析文件,显示消耗情况,最后提供一些可供参考电量优化的方法。

安装包大小优化

  • res资源优化

  • 代码优化

    • 实现功能模块的逻辑简化
    • Lint工具检查无用文件将无用的资源列在“UnusedResources: Unused resources”,删除。
    • 移除无用的依赖库。
  • lib资源优化

    • 动态下载的资源。
    • 一些模块的插件化动态添加。
    • so文件的剪裁和压缩。
  • assets资源优化

    • 音频文件最好使用有损压缩的格式,比如采用opus、mp3等格式,但是最好不要使用无损压缩的音乐格式
    • 对ttf字体文件压缩,可以采用FontCreator工具只提取出你需要的文字。比如在做日期显示时,其实只需要数字字体,但是使用原有的字体库可能需要10MB大小,如果只是把你需要的字体提取出来生成的字体文件只有10KB
  • 代码混淆

    • 使用proGuard 代码混淆器工具,它包括压缩、优化、混淆等功能。
  • 7z极限压缩
    具体请参考微信的安接包压缩,实现实现原理,有时间再分析;

内存优化

在 Android 系统中有个垃圾内存回收机制,在虚拟机层自动分配和释放内存,因此不需要在代码中分配和释放某一块内存,从应用层面上不容易出现内存泄漏和内存溢出等问题,但是需要内存管理。Android 系统在内存管理上有一个 Generational Heap Memory 模型,内存回收的大部分压力不需要应用层关心, Generational Heap Memory 有自己一套管理机制,当内存达到一个阈值时,系统会根据不同的规则自动释放系统认为可以释放的内存,也正是因为 Android 程序把内存控制的权力交给了 Generational Heap Memory,一旦出现内存泄漏和溢出方面的问题,排查错误将会成为一项异常艰难的工作。除此之外,部分 Android 应用开发人员在开发过程中并没有特别关注内存的合理使用,也没有在内存方面做太多的优化,当应用程序同时运行越来越多的任务,加上越来越复杂的业务需求时,完全依赖 Android 的内存管理机制就会导致一系列性能问题逐渐呈现,对应用的稳定性和性能带来不可忽视的影响,因此,解决内存问题和合理优化内存是非常有必要的。

内存泄漏出现的情景

  • 单例中引用的上下文Context,引用了Activity中的Context,这样会造成内存泄漏,要引用Application中的Context;
  • 资源性对象未关闭。比如Cursor、File文件等,往往都用了一些缓冲,在不使用时,应该及时关闭它们。
  • 注册对象未注销。比如事件注册后未注销,会导致观察者列表中维持着对象的引用。
    类的静态变量持有大数据对象。
  • 非静态内部类的静态实例。
  • Handler临时性内存泄漏。如果Handler是非静态的,容易导致 Activity 或 Service 不会被回收。
  • 容器中的对象没清理造成的内存泄漏。
  • WebView。WebView 存在着内存泄漏的问题,在应用中只要使用一次 WebView,内存就不会被释放掉。

内存优化的方案

  • 对象引用。强引用、软引用、弱引用、虚引用四种引用类型,根据业务需求合理使用不同,选择不同的引用类型。
  • 减少不必要的内存开销。注意自动装箱,增加内存复用,比如有效利用系统自带的资源、视图复用、对象池、Bitmap对象的复用。
  • 使用最优的数据类型。比如针对数据类容器结构,可以使用ArrayMap数据结构,避免使用枚举类型,使用缓存Lrucache等等。
  • 图片内存优化。可以设置位图规格,根据采样因子做压缩,用一些图片缓存方式对图片进行管理等等。图片的压缩几种方案。

内存分析工具

Memory Monitor

Memory Monitor 是一款使用非常简单的图形化工具,可以很好地监控系统或应用的内存使用情况.
主要有以下功能:

  • 显示可用和已用内存,并且以时间为维度实时反应内存分配和回收情况。
  • 快速判断应用程序的运行缓慢是否由于过度的内存回收导致。
  • 快速判断应用是否由于内存不足导致程序崩溃。

Heap Viewer

Heap Viewer 的主要功能是查看不同数据类型在内存中的使用情况,可以看到当前进程中的 Heap Size 的情况,分别有哪些类型的数据,以及各种类型数据占比情况。通过分析这些数据来找到大的内存对象,再进一步分析这些大对象,进而通过优化减少内存开销,也可以通过数据的变化发现内存泄漏。
主要有以下功能:

  • 实时查看App分配的内存大小和空闲内存大小
  • 发现Memory Leaks
    Heap Viewer不光可以用来检测是否有内存泄漏,对于内存抖动,我们也可以用该工具检测,因为内存抖动的时候,会频繁发生GC,这个时候我们只需要开启Heap Viewer,观察数据的变化,如果发生内存抖动,会观察到数据在段时间内频繁更新。

Allocation Tracker

Memory Monitor 和 Heap Viewer 都可以很直观且实时地监控内存使用情况,还能发现内存问题,但发现内存问题后不能再进一步找到原因,或者发现一块异常内存,但不能区别是否正常,同时在发现问题后,也不能定位到具体的类和方法。这时就需要使用另一个内存分析工具 Allocation Tracker,进行更详细的分析, Allocation Tracker 可以分配跟踪记录应用程序的内存分配,并列出了它们的调用堆栈,可以查看所有对象内存分配的周期。

Memory Analyzer Tool(MAT)

MAT 是一个快速,功能丰富的 Java Heap 分析工具,通过分析 Java 进程的内存快照 HPROF 分析,从众多的对象中分析,快速计算出在内存中对象占用的大小,查看哪些对象不能被垃圾收集器回收,并可以通过视图直观地查看可能造成这种结果的对象。

稳定性优化

Android 应用的稳定性定义很宽泛,影响稳定性的原因很多,比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等,都会对应用的稳定性造成影响。其中最常见的两个场景是:Crash 和 ANR,这两个错误将会使得程序无法使用,比较常用的解决方式如下:

  • 提高代码质量。比如开发期间的代码审核,看些代码设计逻辑,业务合理性等。
  • 代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。
  • Crash监控。把一些崩溃的信息,异常信息及时地记录下来,以便后续分析解决。
  • Crash上传机制。在Crash后,尽量先保存日志到本地,然后等下一次网络正常时再上传日志信息。

性能优化

Android 性能主要之响应速度 和 UI刷新速度。

  • 函数耗时测量工具: TraceView
  • UI布局分析工具:Hierarchy Viewer
    • 可以看到View的布局层次,以及每个View刷新加载的时间

避免OOM

减少内存对象的重复利用

  • ArrayMap/SparseArray代替hashmap
  • 避免在android里面使用Enum
  • 减少bitmap的内存占用
    • inSampleSize:缩放比例,在把图片载入内存之前,我们需要先计算出一个合适的缩放比例,避免不必要的大图载入。
    • decode format:解码格式,选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8,存在很大差异。
  • 减少资源图片的大小,过大的图片可以考虑分段加载

内存对象的重复利用

大多数对象的复用,都是利用对象池的技术。

  • listview/gridview/recycleview contentview的复用
  • inBitmap 属性对于内存对象的复用ARGB_8888/RBG_565/ARGB_4444/ALPHA_8 这个方法在某些条件下非常有用,比如要加载上千张图片的时候。
  • 避免在ondraw方法里面 new对象
  • StringBuilder 代替+

ANR 相关知识

ANR 是什么?怎样避免和解决 ANR

ANR->Application Not Responding
也就是在规定的时间内,没有响应。

三种类型:
1). KeyDispatchTimeout(5 seconds) –主要类型按键或触摸事件在特定时间内无响应
2). BroadcastTimeout(10 seconds) –BroadcastReceiver在特定时间内无法处理完成
3). ServiceTimeout(20 seconds) –小概率类型 Service在特定的时间内无法处理完成
为什么会超时:事件没有机会处理 & 事件处理超时

怎么避免ANR

ANR的关键

是处理超时,所以应该避免在UI线程,BroadcastReceiver 还有service主线程中,处理复杂的逻辑和计算

而交给work thread操作。

  • 避免在activity里面做耗时操作,oncreate & onresume
  • 避免在onReceiver里面做过多操作
  • 避免在Intent Receiver里启动一个Activity,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。
  • 尽量使用handler来处理UI thread & workthread的交互。

如何解决ANR

首先定位ANR发生的log:

1
04-01 13:12:11.572 I/InputDispatcher( 220): Application is not responding:Window{2b263310com.android.email/com.android.email.activity.SplitScreenActivitypaused=false}.  5009.8ms since event, 5009.5ms since waitstarted
1
2
3
4
CPUusage from 4361ms to 699ms ago ----CPU在ANR发生前的使用情况
04-0113:12:15.872 E/ActivityManager( 220): 100%TOTAL: 4.8% user + 7.6% kernel + 87% iowait

04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 3697ms to 4223ms later:-- ANR后CPU的使用量

从log可以看出,cpu在做大量的io操作。
所以可以查看io操作的地方。
当然,也有可能cpu占用不高,那就是 主线程被block住了。