android UI性能优化详解

  2016-01-15 23:25:06 发布
您的评价:
     
0.0
收藏     0收藏
文件夹
标签
(多个标签用逗号分隔)

android UI性能优化详解

设计师,开发人员,需求研究和测试都会影响到一个app最后的UI展示,所有人都很乐于去建议app应该怎么去展示UI。UI也是app和用户打交道的部分,直接对用户形成品牌意识,需要仔细的设计。无论你的app UI是简单还是复杂,重要的是性能一定要好。

UI性能测试

性能优化都需要有一个目标,UI的性能优化也是一样。你可能会觉得“我的app加载很快”很重要,但我们还需要了解终端用户的期望,是否可以去量化这些期望呢?我们可以从人机交互心理学的角度来考虑这个问题。研究表明,0-100毫秒以内的延迟对人来说是瞬时的,100-300毫秒则会感觉明显卡顿,300-1000毫秒会让用户觉得“手机卡死了”,超过1000ms就会让用户想去干别等事情了。

这是人类心理学最基础的理论,我们可以从这个角度去优化页面/view/app的加载时间。 Ilya Grigorik 有一个很棒的演讲,是关于搭建1000毫秒内加载完成移动网站的。如果你的网页能在1秒内加载好,就超过了人类感知的预期,你的用户一定会感觉很满意。还有研究表明,如果网页在3-4秒内还没加载出任何内容,用户就会放弃了。把这些数据应用到app的加载,不难明白加载时间是越短越好。这篇文章主要关注UI的加载时间。当然UI性能优化还会涉及到其他方面,比如必需在后台运行到任务,要从服务器下载一个文件等等,这些我们在后面的文章再聊。

卡顿(Jank)

内容的快速加载很重要,渲染的流畅性也很重要。android团队把滞缓,不流畅的动画定义为jank,一般是由于丢帧引起的。安卓设备的屏幕刷新率一般是60帧每秒(1/60fps=16.6ms每帧),所以你想要渲染的内容能在16ms内完成十分关键。每丢一帧,用户就会感觉的动画在跳动,会出现违和感。为了保证动画的流畅性,我们接下来看下从哪些方面优化可以让内容在16ms内渲染完成,同时分析一些常见的导致UI卡顿的问题。

android设备的UI渲染性能

早期android用户抱怨最多的就是UI,尤其是触碰反馈和动画流畅度,感觉都很卡。后来随着android系统逐渐成熟,开发人员也投入了大量的时间和精力让交互变的流畅起来。下面列举一些不同系统版本所带来的提升:

  • 在Gingerbread或者更早的设备上,屏幕完全是由软件绘制(CPU绘制)的(不需要GPU的参与)。后来随着屏幕尺寸变大和像素的提升,纯粹靠软件绘制遇到了瓶颈。

  • Honeycomb加入了平板设备,进一步增加了屏幕尺寸。同时出于性能考虑,加入了GPU芯片,app在渲染内容的时候多了一个GPU硬件加速的选项。

  • 对于针对Ice Cream Sandwich或者更高系统的设备,GPU硬件加速是默认打开的。将软件绘制(CPU)的压力大部分转移到了GPU上。

  • Jelly Bean 4.1 (and 4.2) “Project Butter” 做了近一步的提升来避免卡顿,通过引入VSYNC机制和增加额外的frame buffer(vsync和frame buffer的解释可以参考这篇文章),运行 Jelly Bean的设备丢帧的概率变的更小。引入这些机制的同时,android开发团队还加入了一些优秀的工具来测量屏幕的绘制,开发者可以使用这些工具来检测VSYNC buffering和卡顿。

我们从普通开发者的角度,来逐一看下这些提升和相关的测量工具。我们的目标很明显:

  • 屏幕绘制低延迟
  • 保证流程稳定的帧率来避免卡顿

当android开发团队引入这些UI流畅性的提升时,他们需要能量化这些提升的工具。经由他们的努力,这些工具都打包进了SDK以方便开发者们来检测UI相关的性能问题。接下来我们就使用这些工具来优化几个demo程序。

搭建Views

大家应该都对android studio里xml布局编辑器很熟悉了,知道怎么在android studio(Eclipse)中搭建和检测View结构。下图是一个简单的app view,包含一些套嵌的子view。搭建这些view的时候,一定要留意屏幕右上角的组件树(Component Tree)。套嵌的子view越深,组件树就越复杂,渲染起来也就越费时间。

图4-1

对于app里的每一个view,android系统都会经过三部曲来渲染:measure,layout,draw。可以在脑中回想下你搭建的view的xml布局文件结构,measure从最顶部的节点开始,顺着layout树形结构依次往下:测量每个view需要在屏幕当中展示的