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

标签: 编程技术 android | 发表时间:2015-06-21 03:40 | 作者:techug
分享到:
出处:http://www.vaikan.com

渲染篇

1) Why Rendering Performance Matters

现在有不少App为了达到很华丽的视觉效果,会需要在界面上层叠很多的视图组件,但是这会很容易引起性能问题。如何平衡Design与Performance就很需要智慧了。

2) Defining ‘Jank’

大多数手机的屏幕刷新频率是60hz,如果在1000/60=16.67ms内没有办法把这一帧的任务执行完毕,就会发生丢帧的现象。丢帧越多,用户感受到的卡顿情况就越严重。

552dd22e52006_middle

3) Rendering Pipeline: Common Problems

渲染操作通常依赖于两个核心组件:CPU与GPU。CPU负责包括Measure,Layout,Record,Execute的计算操作,GPU负责Rasterization(栅格化)操作。CPU通常存在的问题的原因是存在非必需的视图组件,它不仅仅会带来重复的计算操作,而且还会占用额外的GPU资源。

4) Android UI and the GPU

了解Android是如何利用GPU进行画面渲染有助于我们更好的理解性能问题。一个很直接的问题是:activity的画面是如何绘制到屏幕上的?那些复杂的XML布局文件又是如何能够被识别并绘制出来的?

Resterization栅格化是绘制那些Button,Shape,Path,String,Bitmap等组件最基础的操作。它把那些组件拆分到不同的像素上进行显示。这是一个很费时的操作,GPU的引入就是为了加快栅格化的操作。

CPU负责把UI组件计算成Polygons,Texture纹理,然后交给GPU进行栅格化渲染。

然而每次从CPU转移到GPU是一件很麻烦的事情,所幸的是OpenGL ES可以把那些需要渲染的纹理Hold在GPU Memory里面,在下次需要渲染的时候直接进行操作。所以如果你更新了GPU所hold住的纹理内容,那么之前保存的状态就丢失了。

在Android里面那些由主题所提供的资源,例如Bitmaps,Drawables都是一起打包到统一的Texture纹理当中,然后再传递到GPU里面,这意味着每次你需要使用这些资源的时候,都是直接从纹理里面进行获取渲染的。当然随着UI组件的越来越丰富,有了更多演变的形态。例如显示图片的时候,需要先经过CPU的计算加载到内存中,然后传递给GPU进行渲染。文字的显示比较复杂,需要先经过CPU换算成纹理,然后交给GPU进行渲染,返回到CPU绘制单个字符的时候,再重新引用经过GPU渲染的内容。动画则存在一个更加复杂的操作流程。

为了能够使得App流畅,我们需要在每帧16ms以内处理完所有的CPU与GPU的计算,绘制,渲染等等操作。

5) GPU Problem: Overdraw

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

当设计上追求更华丽的视觉效果的时候,我们就容易陷入采用复杂的多层次重叠视图来实现这种视觉效果的怪圈。这很容易导致大量的性能问题,为了获得最佳的性能,我们必须尽量减少Overdraw的情况发生。

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

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

6) Visualize and Fix Overdraw – Quiz & Solution

这里举了一个例子,通过XML文件可以看到有好几处非必需的background。通过把XML中非必需的background移除之后,可以显著减少布局的过度绘制。其中一个比较有意思的地方是:针对ListView中的Avatar ImageView的设置,在getView的代码里面,判断是否获取到对应的Bitmap,在获取到Avatar的图像之后,把ImageView的Background设置为Transparent,只有当图像没有获取到的时候才设置对应的Background占位图片,这样可以避免因为给Avatar设置背景图而导致的过度渲染。

总结一下,优化步骤如下:

  • 移除Window默认的Background
  • 移除XML布局文件中非必需的Background
  • 按需显示占位背景图片

7) ClipRect & QuickReject

前面有提到过,对不可见的UI组件进行绘制更新会导致Overdraw。例如Nav Drawer从前置可见的Activity滑出之后,如果还继续绘制那些在Nav Drawer里面不可见的UI组件,这就导致了Overdraw。为了解决这个问题,Android系统会通过避免绘制那些完全不可见的组件来尽量减少Overdraw。那些Nav Drawer里面不可见的View就不会被执行浪费资源。

但是不幸的是,对于那些过于复杂的自定义的View(通常重写了onDraw方法),Android系统无法检测在onDraw里面具体会执行什么操作,系统无法监控并自动优化,也就无法避免Overdraw了。但是我们可以通过canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域,只有在这个区域内才会被绘制,其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。同时clipRect方法还可以帮助节约CPU与GPU资源,在clipRect区域之外的绘制指令都不会被执行,那些部分内容在矩形区域内的组件,仍然会得到绘制。

除了clipRect方法之外,我们还可以使用 canvas.quickreject()来判断是否没和某个矩形相交,从而跳过那些非矩形区域内的绘制操作。

8) Apply clipRect and quickReject – Quiz & Solution

上面的示例图中显示了一个自定义的View,主要效果是呈现多张重叠的卡片。这个View的onDraw方法如下图所示:

打开开发者选项中的显示过度渲染,可以看到我们这个自定义的View部分区域存在着过度绘制。那么是什么原因导致过度绘制的呢?

9) Fixing Overdraw with Canvas API

下面的代码显示了如何通过clipRect来解决自定义View的过度绘制,提高自定义View的绘制性能:

下面是优化过后的效果:

10) Layouts, Invalidations and Perf

Android需要把XML布局文件转换成GPU能够识别并绘制的对象。这个操作是在DisplayList的帮助下完成的。DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。

在某个View第一次需要被渲染时,Display List会因此被创建,当这个View要显示到屏幕上时,我们会执行GPU的绘制指令来进行渲染。

如果View的Property属性发生了改变(例如移动位置),我们就仅仅需要Execute Display List就够了。

然而如果你修改了View中的某些可见组件的内容,那么之前的DisplayList就无法继续使用了,我们需要重新创建一个DisplayList并重新执行渲染指令更新到屏幕上。

请注意:任何时候View中的绘制内容发生变化时,都会需要重新创建DisplayList,渲染DisplayList,更新到屏幕上等一系列操作。这个流程的表现性能取决于你的View的复杂程度,View的状态变化以及渲染管道的执行性能。举个例子,假设某个Button的大小需要增大到目前的两倍,在增大Button大小之前,需要通过父View重新计算并摆放其他子View的位置。修改View的大小会触发整个HierarcyView的重新计算大小的操作。如果是修改View的位置则会触发HierarchView重新计算其他View的位置。如果布局很复杂,这就会很容易导致严重的性能问题。

11) Hierarchy Viewer: Walkthrough

Hierarchy Viewer可以很直接的呈现布局的层次关系,视图组件的各种属性。 我们可以通过红,黄,绿三种不同的颜色来区分布局的Measure,Layout,Executive的相对性能表现如何。

12) Nested Hierarchies and Performance

提升布局性能的关键点是尽量保持布局层级的扁平化,避免出现重复的嵌套布局。例如下面的例子,有2行显示相同内容的视图,分别用两种不同的写法来实现,他们有着不同的层级。

下图显示了使用2种不同的写法,在Hierarchy Viewer上呈现出来的性能测试差异:

13) Optimizing Your Layout

下图举例演示了如何优化ListItem的布局,通过RelativeLayout替代旧方案中的嵌套LinearLayout来优化布局。

相关 [google android 性能] 推荐:

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

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

Android 性能优化

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

Google将关闭Android App Inventor

- tinda - Solidot
新上任的Google CEO Larry Page已发誓要调整公司的重心,将精力集中中优先项目上,一些对用户有用但却对公司没有帮助的项目纷纷关闭,如Google字典服务,如Google Labs中的众多项目. 其中一个被关闭的项目是Android App Inventor. Android App Inventor由MIT计算机科学Hal Abelson领导开发,借鉴了入门级编程项目Scratch,让没有编程经验和知识的人开发Android应用程序,因此颇受教育界人士的欢迎.

Google Android Market疑遭屏蔽

- 小天 - Solidot
中国的Android移动用户报告无法访问Google官方的应用程序商店Android Market. Android Market此前也被临时屏蔽过,目前不清楚这次屏蔽是否是长期性的. Google的移动产品如Gmail等也同时被屏蔽. 中国的Android用户暂时可以使用第三方应用商店替代,但安全性无法保证,许多Android恶意程序都是在第三方应用商店传播.

Android 性能核心揭密

- - CSDN博客推荐文章
其实我发现不少人不注重性能的开发,这样产品体验会很差的. 移动互联网是用户体验为王的时代,而排在影响用户体验的问题如快速、流畅、省电等,都与研发优化直接相关. 推荐使用traceview和monkey等工具来测试应用,利用layoutopt和ninepatch等工具优化视图,建议开发者注重代码复用,做好应用分析最大化利用第三方工具.

Android应用性能 分析

- - CSDN博客推荐文章
  其实主要是内存方面,内存管理是个永恒的话题. 1.从工具DDMS中,在Sysinfo的tab栏里面有一个Memory usage的选项,通过USB连接Android设备以后很容易抓到图. 在图中可以看到系统随时可以用的内存是Free和Buffers两项,因为我抓图的系统只有128M的内存,所以看上去这部分可用内存已经很少了.

Android应用性能测试

- - CSDN博客推荐文章
java虚拟机有内存使用上限的限制. adb shell进入手机,这此参数被纪录在/system/build.prop中,如果想直接查看可以使用adb shell getprop. 单个应用程序最大内存限制,超过这个值会产生OOM. 单个java虚拟机最大的内存限制,超过这个值会产生OOM. android程序内存一般限制在16M,当然也有24M的,而android程序内存被分为2部分:.

Android性能优化典范

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

Google+ Android 应用已支持 NFC [视频]

- 太平犬 - 谷安——谷奥Android专题站
Google 喜欢将自己不同的技术和服务搞到一起,取长补短彼此促进,看起来 Google+ 也不例外. 通过带有 NFC 的手机,Google+ 应用可以读取 NFC 标签从而快速分享内容. 当然直到 NFC 普及之前估计难火热起来. Google 已经宣传 NFC(near-field communications/近场通信)有一段时间,他们还推出了基于 NFC 的 Google Wallet(Google 钱包)服务.

Google和Android的专利纷争

- Xu Ning - 月光博客
  笔者是从G1开始用Android的,到目前用的是Nexus One,并且下一代的Nexus我也要定了. 笔者痴迷于Google的各项服务,有两个付款账户,并且Gmail, Calendar, Docs,以及 Google+ Circles用起来都比我想象的要舒服得多. 截至投稿的这一瞬间,笔者认为Google还没有从混沌中醒来.