Android UI and the GPU - 1501130356
Last updated
Was this helpful?
Last updated
Was this helpful?
视频发布时间
2015年1月6日
视频介绍
One of the most challenging questions for Android Developers is “how does your activity actually get drawn to the screen?” Or rather, how does all that crazy XML and markup language turn into pixels that the user can see and understand?
视频推介语
暂无,待补充。
翻译
润稿
终审
原始链接
中文字幕
翻译流水号
加入字幕组
周亿
姜昭宇
——
1501130356
想要知道怎么做出一个高性能的应用
就需要理解底层的工作
如果你完全不知道硬件在做什么
你将不能充分的利用硬件的性能来提升你的应用
我是Colt McAnlis
说到你的应用程序的渲染
理解Android如何利用GPU能够大幅度的
提升你的应用性能
最主要的问题是你的应用程序是
如何在屏幕上被绘制出来的
或者说 那些XML和标记语言
是如何转换成用户能看到并理解的图像的
它的核心就是在进行着光栅化的处理过程
这个过程就是将一些高级的对象
比如说字符串 按钮
路径或者是形状 转换成屏幕上纹理中的像素点
光栅化是一个非常非常耗时的过程
正因如此 你的手机设备的硬件上有一个特殊的部分
被设计来提升光栅化的处理速度
图形处理器 或者是叫做GPU
早在20世纪90年代就被引入主流电脑
以帮助加快光栅化过程
GPU本身被设计成使用一组特定的图元
主要的多边形
纹理 或是你会称作的图片
在GPU绘制任何东西到屏幕上之前
你的CPU是负责将这些图元传输到GPU
完成这项任务是使用了Android上的常见的API
就是被我们熟知的OpenGL ES
也就是说你的任何UI对象 比如按钮
路径或者复选框需要被绘制到屏幕上
它们首先要在CPU上转换成多边形和纹理
然后再传递给GPU进行光栅化处理
正如你想象的那样
处理UI对象并转换成多边形和纹理并不是最快的操作
同样 从CPU上传到GPU上也不是那么快 这样
你就想去减少转换对象的数量
和提交到GPU的数量
不过值得庆幸的是
OpenGL ES API允许你将内容传送到GPU
并且保存在GPU中
当在以后你需要再次绘制一个按钮的时候
你只需要参考GPU内存中的已经存在的网格
告诉OpenGL如何绘制它
一般的规则是这样 优化渲染性能就意味着
尽可能多且快的将更多的数据上传到GPU
然后留在GPU中 尽可能长的时间内不去修改
每次你更新GPU中的资源
你都在失去宝贵的处理时间
这也是Android系统遵守的一项原则
让渲染高性能的执行
举个例子 你的主题提供了一些资源
包括位图和一些可绘制的东西
被组合在一起形成一个纹理 并且上传到GPU
旁边就是常用的多边形 比如九宫格
这也就意味着任何时候你要使用这些资源绘制一个视图
我们不需要进行任何的转换
所有的内容都驻留在GPU中
这些类型的视图会快速的显示出来
但是 UI对象越来越高级
这个过程就变得越来越复杂
比如 显示图片 CPU先要加载这些图片到内存
转换之后传递给GPU进行绘制
使用路径创建一个单独的集群
因为我们可能需要在CPU中实际创建一个多边形的链
甚至在GPU上创建一个类似形状遮罩纹理
绘制文本完全就是灾难
我是说 想象一下
在CPU上我们不得不栅格化文字到一个纹理
然后上传到GPU
然后再对照着GPU中的数据
将字符串中的字符一个个绘制
动画使得这些事情变得更加复杂
取决于你修改视图的方式
你可能每一帧都需要承担更新GPU中资源的开销
这还不包含其他GPU的性能问题
例如 不是要重新绘制整个应用的每一帧
Android通过只绘制更新过的部分区域以节约性能
更何况CPU的转换并上传到
Android上不得不以高性能的方式
将一切需要渲染的准备好
但是最棘手的部分在于 为了提供一个流畅的
完美的用户体验 你不得不更新你的代码
GPU资源 并且将动画每帧都控制在16毫秒以内
至少这是我们的目标
这也是为何你应该查看其他的
Android Performance Patterns视频以来
提高渲染性能
噢 别忘了加入Google+社区和
更多的开发者一起讨论
代码分析 你值得拥有 性能问题 永不能忘