android性能优化实战理论篇

标签: android 性能优化 理论 | 发表时间:2016-06-13 03:17 | 作者:iamws
出处:http://blog.csdn.net

本文地址:http://blog.csdn.net/iamws/article/details/51636175

第二篇:理论

         通过之前前篇介绍的工具,我们知道了应该怎么样去获取要分析的数据,但是也仅仅局限在于怎么样获取数据,而没有深入数据分析,这一篇主要讲解的是UI刷新这块部分android理论知识,有了这些知识后,对于上面的数据该怎么分析,你就胸有成竹了。

ps:本文只是个人理解后的总结,并不会深入源码层次分析,如有错误,还请麻烦各位帮忙指正~


这篇文章要解决的理论问题如下:

1、什么是内存泄漏,内存溢出,这块对性能有什么影响以及android GC的种类

2、网上说的android UI刷新是60fps/16ms一次是什么样的一回事

3、android的整体绘制原理

4、view动画和属性动画区别

5、过度绘制会导致什么问题

6、硬件加速制的时候你是否对画布使用了lockcanvas()方法

7、哪些操作是耗费CPU的

8、其他性能优化注意点(想到后再加上)


如果对以上知识已经了解的话,那就麻烦跳过这篇,期待下一篇实战举例吧(┬_┬)


好了,开始

第一:什么是内存泄漏,内存溢出,这块对性能有什么影响以及android GC的种类?

(这块需要对GC有一些了解,了解了java GC的这块知识后下面就很好理解了)

由于android是个移动设备上的操作系统,没有了PC上的硬件支持,所以对于系统cpu,内存资源都需要额外关注,这才是为什么要很注意性能问题;

内存泄漏:简单讲就是之前创建了对象,也分配了内存给它,但是后来这个对象没用了,本来应该要交给系统去回收,但是对象却由于一直被GC ROOT上存在引用链导致无法回收,然后这部分内存就一直被占用了,如果每次操作都会生成这个对象的话,将会逐渐吞噬app的内存剩余空间,最终结果就是导致内存被吃完了,然后抛出溢出异常


内存溢出:常称OOM,out of memory,一般玩图片加载不注意的时候很容易碰到这个异常,这个其实是一个app在任何android手机运行的时候,都会是 linux给fork出虚拟机(例如:dalvik)进程跑的,而每个虚拟机创建的时候就会给他当前系统规定的可使用内存大小,如果你的app某个操作导致要使用的内存超过了这个分配值,而且GC后剩余的内存都没办法给你足够的空间去分配,那么这个异常就出来了


android GC种类:我们在android的logcat中输入GC关键字,可以看到GC基本上有以下这几类:

GC_FOR_MALLOC: 表示准备在堆上分配内存时内存不够触发的GC

GC_CONCURRENT: 表示是在当前内存达到一定设置量后导致触发的GC

GC_BEFORE_OOM: 表示是在准备抛OOM异常之前进行GC

GC_EXPLICIT: 表示是程序中主动调用System.gc、VMRuntime.gc接口或者收到信号时触发的主动GC
ps:android GC相关的知识推荐可以看看老罗写的博客,友情链接:http://blog.csdn.net/luoshengyang/article/details/41822747


可以看到上面除了主动代码或者信号调用以外,其它的GC都是在内存分配过程中调用的,而GC过程是需要涉及到CPU计算的,同时GC过程分为挂起或者与其他线程并行两种模式,这时候大家就明白为什么GC的时候会突然出现性能下降或者应用界面容易无响应了吧,这也证明了内存泄漏的危害,因为内存泄漏后就会导致可使用内存的降低,随着对象对内存的新申请,很容易就会触发频繁GC了,所以解决内存泄漏是解决性能优化的一个重要方法。


第二:网上说的android UI刷新是60fps/16ms一次是什么样的一回事?

我们可以看到基本上网上都有说android的UI是60fps的,也就换算成1000/60=16ms刷新一次,这种说法是怎么来的,而且这个是谁定义的呢?

答案当然是google,为什么google这样定义,这是因为做过android 2.x系列开发的人都知道,安卓当时的流畅度是完败给IOS的,流畅性被吐槽的特别多,google当时也发现这个问题很严重,于是在2012年的google i/o大会上,正式推出了4.1版本,同时也推出了黄油计划,这个黄油计划目标就是提升整体的流畅度,这里面就涉及到所谓的单缓存、双重缓存和三重缓存通道的机制区别,而且为了确保每次刷新的帧数相同,制定了vsync信号,这个信号就是通知系统的SurfaceFlinger要去执行渲染整个页面了

那么现在简单介绍一下这块缓存流程和部分技术:

什么是SurfaceFlinger:官方解释是:Every window that is created on the Android platform is backed by a surface. All of the visible surfaces rendered are composited onto the display by SurfaceFlinger.

就是说每个window背后都是surface,而所有的可见surface最后组成并要显示出来的时候,靠的就是SurfaceFlinger去渲染的,而SurfaceFlinger是一个system级的服务,依赖的是binder通信机制,由client去请求建立surface并最终完成渲染通信过程

所以android的渲染逻辑是:vsync信号是由系统每隔16ms发出一次,发出后就是通知SurfaceFlinger需要渲染了,渲染的数据哪里来呢?就是上面说的(单缓存、双重缓存和三重缓存技术通道里面存储的)存储的缓存队列,而缓存队列里面的数据怎么来的,就是CPU和GPU计算得出的页面绘制数据;



简单说下这几个缓存机制吧,单缓存:CPU/GPU绘制后的数据与屏幕显示读取的数据在同一个缓存队列中;但是由于计算频率和显示频率一般是不同的,这种缓存模式最容易导致的就是画面撕裂,也就是说看到的界面容易出现上一个帧和当前帧在同一个画面组成一张图,而这并不是我们想要的流畅度;


双重缓存:给了2个buffer队列,一个给CPU/GPU绘制后存放数据,一个给屏幕渲染的时候去读取数据,同时制定2个buffer之间的数据交换的规则,最终解决上面画面撕裂的问题;不过CPU和GPU共用同一个buffer,而我们知道,CPU和GPU如果在休眠,只有收到vsync信号才会开始处理下一个的数据,如果某次当vsync信号发出时,而且刚好又是一个耗时操作,CPU或者GPU还在处理上一个帧的计算,就会出现CPU或者GPU正占有着buffer,那么那个没有占有buffer的CPU/GPU也没办法处理了,所以就只好继续再休眠一个帧了,所以三重缓存就出来了


三重缓存:比上面的双重缓存还要多一个缓存,目地就是说硬件你们就各在个的缓存里面做事情,这样最大化利用各个硬件的计算频率优势,同时也规范制定好了之间数据的交换规则,这样,android的UI流畅度一下就上来了


顺便借用一下google io 2012的宣传资料里面的图,直观展示上面三者的区别和影响吧:

图2-1:单缓存下界面展示撕裂的原因,因为CPU/GPU频率高,Display频率低,当界面开始读取下一个数据时候,就会把途中0.015的图读出来,就撕裂啦




图2-1 单缓存实现图




图2-3双缓存实现图



图2-4 三缓存实现图



所以由上面的分析我们得知,如果想要你的应用顺畅展示界面,一需要确保你的每次渲染提交的计算过程能够在16ms内完成,二要减少没必要的高帧率计算,让你的渲染帧率保持跟系统刷新的频率,这样就能很大程度上释放cpu,同时保证流畅度,也就是性能优化的一个方法了。

此处可以参考文章:

官方渲染:http://source.android.com/devices/graphics/index.html

黄油计划:http://blog.csdn.net/innost/article/details/8272867

视频搜索:google发表的Android 21个性能优化典范教学



第三个:android的整体绘制原理

这块就纯粹是看android的view绘制源码了,网上应该也挺多的解释的,具体就是系统层的windowmanager怎么跟ViewRoot关联起来,然后再怎么从顶级DecorView到内部的view做measure,layout,draw等等,这里主要提的一点就是子布局的测量过程是需要依赖父布局的测量结果和子布局的属性一起才能决定最终子view测量结果的

为什么要单独列出来说这个呢,主要是考虑如果你的子布局一直有变化,将会带来整体所有上层父布局全都重走measure过程,而measure是CPU消耗的,下面是我demo的例子,testlinearlayout为父布局容器,嵌套两层,里面再动态插入子布局容器testtextview,布局树和日志如下:


看了图后你就明白,为什么一直说UI嵌套不能过深了,这块主要解决的就是UI布局嵌套过深,如果子布局变化过快带来的CPU计算损耗,是一个重要的性能优化点。


可以参考书籍:《深入理解android 卷II》《android开发艺术探索》里面有从framework层和java层两块详细分开介绍整个流程,这里就不多说了(主要太懒了(*^__^*) ,相关资料太多了)



第四个:view动画和属性动画的区别

这块想必大家一般都知道这些动画在应用层上最大的区别,view动画是假移动,view实际上还在原来位置,点击什么的事件也是在原位置监听,而属性动画是真移动,通过改变view的translation属性值,这样在新位置也能触发事件

不过这里要说的是他们的性能区别,先说总结的吧,优先使用属性动画去做,属性动画对性能优化提升最大

why?

//TODO 插入动画对比图1、2、3

过几天补上,做好的图不见了- - !!!



第五个:过度绘制会导致什么问题

什么叫做过度绘制?我们知道屏幕渲染最终依赖的都是手机硬件上的每一个小像素点的颜色的改变去实现的,而且由上面所知,目前android采用的是16ms的刷新机制,也就是说你看到的每一帧图像之间有16ms的间隔期,但是在这个间隔期内,你的计算可能对某些像素点指定了要做多次绘制,当系统最终渲染的时候等于也会对这个像素点按你的要求单帧内也绘制多次,导致有些时候实际上是做了很多无用功,例如指定了某个viewgroup背景颜色是白色,然后里面放入一个子view,但是你让这个子view背景色还是白色后,当系统开始渲染这一帧就会按你的意思,某个像素绘制一个白色,然后又绘制一次白色,这样是不是感觉后面的绘制实际上是多余而且没有必要的,所以说过度绘制的削减对于UI流畅度的提升非常重要。

所以过度绘制导致的问题是CPU/GPU做了很多无用功,界面渲染过程也浪费了比较多的绘制资源

解决也很简单,1、减少背景设置重叠,2、减少不必要的view重叠,3、减少复杂布局实现(要和产品撕逼的一点,嘿嘿)等

下面随机找了2款线上APP的渲染展示图,都是登陆功能的,大家可以稍微看看:(只做技术知识研究分享展示用,对应APP的开发GG别打我)






第六个:想用硬件加速的时候你是否对画布使用了lockcanvas()方法

目前主流手机基本都有硬件加速功能了,而且硬件加速在渲染上对我们的CPU计算帮助很大,所以大家都想去用好它,我们很多时候在用surfaceview, surfacetextture去做一些复杂自定义view绘制的时候也特别希望用上它去帮忙加速,但是事与愿违,原来官方文档中写了一句话,导致我们以为是用了硬件加速帮忙,结果反而不是的,这句话就是官方文档中着重注意的:


翻译过来大概就是说如果获取画布采用lockcanvas()方法的时候,那么这个画布的绘制就不会是硬件加速了

这个优化点首先是要感谢工作中的同事,是他在优化过程中发现并提出的,同时证明我看文档的时候还是不太仔细,好像这句话我当时都忽略了,惭愧~

所以这块大家希望能让硬件加速帮上忙的话特别注意一下下,也算作一个优化注意点



第七个:哪些操作是耗费CPU的

这块只能说以往经常碰到的点提一下吧

1、布局计算

2、动画播放

3、图片加载

4、本地IO

5、反射机制

6、多重内部循环

7、线程

8、锁

9、某些api里面有的绘制计算

10、view的各种变形操作

11、等等等(想到再补)

是不是觉得跟java的很像啊,没错,基本就是一样的,java耗费的地方,android也一样,这块就不着重说了,大家注意实现某些逻辑的时候多考虑下是否有更好的实现方案或者更佳的api调用就ok了


第八个:其它分析点

想到再补充,不过都是集中在前篇说的这几个问题里面:内存泄漏,布局层次过深,measure计算过多,动画绘制问题,io,自定义控件的draw里面对象创建,线程滥用,handler里面丢了个外部对象不清除,内部类与匿名类问题等;



下一篇将会开始结合实例数据代码分析,不过这里面要写很多对比demo,毕竟公司项目的代码不能拿出来分析的,但是demo都是根据项目中性能问题真实改编而来,这块预计需要花比较多的业余时间了,可能会分多个不同侧重点推出,敬请期待哈~

ps:这篇文章花了一个晚上去整理思绪后写的,本来留了很多补充的地方,不过要开始下一阶段工作了,而且这一系列的文章就是需要结合数据去实际分析优化性能的,重点在于实例上,所以就先推出这个版本吧,以后再考虑加上补充拉~



author:iamwsbear@gmail.com

转载必须注明出处:本文地址:http://blog.csdn.net/iamws/article/details/51636175


作者:iamws 发表于2016/6/13 3:17:31 原文链接
阅读:78 评论:0 查看评论

相关 [android 性能优化 理论] 推荐:

android性能优化实战理论篇

- - CSDN博客推荐文章
本文地址:http://blog.csdn.net/iamws/article/details/51636175.          通过之前前篇介绍的工具,我们知道了应该怎么样去获取要分析的数据,但是也仅仅局限在于怎么样获取数据,而没有深入数据分析,这一篇主要讲解的是UI刷新这块部分android理论知识,有了这些知识后,对于上面的数据该怎么分析,你就胸有成竹了.

Android 性能优化

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

Android性能优化典范

- - 移动开发 - ITeye博客
2015新年伊始,Google发布了关于Android性能优化典范的专题,一共16个短视频,每个3-5分钟,帮助开发者创建更快更优秀的Android App. 课程专题不仅仅介绍了Android系统中有关性能问题的底层工作原理,同时也介绍了如何通过工具来找出性能问题以及提升性能的建议. 主要从三个方面展开,Android的渲染机制,内存与GC,电量优化.

Android性能优化-线程性能优化

- - CSDN博客推荐文章
熟练使用Android上的线程可以帮助你提高应用程序的性能. 本篇文章讨论了使用线程的几个方面:使用UI或主线程; 应用程序生命周期和线程优先级之间的关系; 以及平台提供的帮助管理线程复杂性的方法. 在每一部分,本篇都描述了潜在的陷阱以及如何避免它们的策略. 当用户启动你的应用程序时,Android会创建一个新的  Linux process 以及一个执行线程.

Android开发性能优化简介

- - CSDN博客推荐文章
       随着技术的发展,智能手机硬件配置越来越高,可是它和现在的PC相比,其运算能力,续航能力,存储空间等都还是受到很大的限制,同时用户对手机的体验要求远远高于PC的桌面应用程序. 以上理由,足以需要开发人员更加专心去实现和优化你的代码了. 选择合适的算法和数据结构永远是开发人员最先应该考虑的事情.

Android性能优化之渲染篇

- - 移动开发 - ITeye博客
关注微信号:javalearns   随时随地学Java. Google近期在Udacity上发布了Android性能优化的在线课程,分别从渲染,运算与内存,电量几个方面介绍了如何去优化性能,这些课程是Google之前在Youtube上发布的Android性能优化典范专题课程的细化与补充. 下面是渲染篇章的学习笔记,部分内容和前面的性能优化典范有重合,欢迎大家一起学习交流.

Google《Android性能优化》学习笔记

- - 外刊IT评论
现在有不少App为了达到很华丽的视觉效果,会需要在界面上层叠很多的视图组件,但是这会很容易引起性能问题. 如何平衡Design与Performance就很需要智慧了. 大多数手机的屏幕刷新频率是60hz,如果在1000/60=16.67ms内没有办法把这一帧的任务执行完毕,就会发生丢帧的现象. 丢帧越多,用户感受到的卡顿情况就越严重.

Android性能优化之内存泄漏

- - CSDN博客推荐文章
  内存泄漏(memory leak)是指由于疏忽或错误造成程序未能释放已经不再使用的内存. 那么在Android中,当一个对象持有Activity的引用,如果该对象不能被系统回收,那么当这个Activity不再使用时,这个Activity也不会被系统回收,那这么以来便出现了内存泄漏的情况. 在应用中内出现一次两次的内存泄漏获取不会出现什么影响,但是在应用长时间使用以后,若是存在大量的Activity无法被GC回收的话,最终会导致OOM的出现.

Android-性能优化-内存优化

- - CSDN博客移动开发推荐文章
Android-性能优化-内存优化. 详见: JVM 内存分配机制. 详见: JVM 垃圾回收机制. Dalvik 虚拟机(DVM)是 Android 系统在 java虚拟机(JVM)基础上优化得到的,DVM 是基于寄存器的,而 JVM 是基于栈的,由于寄存器高效快速的特性,DVM 的性能相比 JVM 更好.

Android应用开发性能优化完全分析

- - CSDN博客推荐文章
其实有点不想写这篇文章的,但是又想写,有些矛盾. 当然了,本文不会就此编辑这么一次,因为技术在发展,工具在强大(写着写着Android Studio 1.4版本都推送了),自己的经验也在增加,所以本文自然不会覆盖所有性能优化及分析;解决的办法就是该文章会长期维护更新,同时在评论区欢迎你关于性能优化点子的探讨.