自定义控件被忽略的渲染性能

渲染性能

Android UI的工作分两阶段:

1.在UI线程Record View#draw 
2.在RenderThread线程DrawFrame(RenderThread:使用GPU资源的线程) 
第一阶段随着View的invalidated在draw(Canvas)中进行 
第二阶段native RenderThread基于Record View#draw步骤所产生的数据内容而进行相应的处理。

渲染性能:UI线程

如果Record View#draw占用时间长,比如在UI线程绘制bitmap。当然,这种直接在UI线程绘制bitmap的方式应该避免使用。

示例1:在主线程完成bitmap绘制,并显示圆角头像自定义控件,onDraw代码实现可能如:

Canvas bitmapCanvas = new Canvas(roundedOutputBitmap);
Paint paint = new Paint();
paint.setAntiAlias(true);
bitmapCanvas.drawRoundRect(0, 0,
        roundedOutputBitmap.getWidth(), roundedOutputBitmap.getHeight(), 30, 30, paint);
paint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.SRC_IN));
bitmapCanvas.drawBitmap(sourceBitmap, 0, 0, paint);
bitmapCanvas.setBitmap(null);
canvas.drawBitmap(roundedOutputBitmap, 0, 0, null);

如果你现在是用这种方式实现其它自定义控件bitmap的绘制,假设sourceBitmap是一个很大的位图,哪怕是缓存,加载进来会出现明显的卡顿现象,所以用后台线程完成这个工作。

示例2:.有时自定义控件需要在设置bitmap的时候,才显示bitmap,代码如下:

void setBitmap(Bitmap bitmap) {
    mBitmap = bitmap;
    invalidate();
}

void onDraw(Canvas canvas) {
    canvas.drawBitmap(mBitmap, null);
}

可以考虑用下面的代码替换:

void setBitmap(Bitmap bitmap) {
    mShaderPaint.setShader(
            new BitmapShader(bitmap, TileMode.CLAMP, TileMode.CLAMP));
    invalidate();
}

void onDraw(Canvas canvas) {
    canvas.drawRoundRect(0, 0, mWidth, mHeight, 20, 20, mShaderPaint);
}

这样可以给bitmap数据源起到保护的作用,避免bitmap中间因为其他的修改(如在bitmap数据源头添加渐变效果或者颜色过滤)而导致bitmap的数据源被修改。

渲染性能:RenderThread

有些放在onDraw(canvas)中的代码套路或许很容易想到,但却会在RenderThread触发频繁的运算。

示例

canvas.save();
canvas.clipPath(mCirclePath);
canvas.drawBitmap(mBitmap);
canvas.restore();

clipPath(Path)会触发很多裁剪工作,应该尽量少用。可以的话,考虑用下面这种方式替换:

mPaint.setShader(new BitmapShader(mBitmap, TileMode.CLAMP, TileMode.CLAMP));
canvas.drawPath(mCirclePath, mPaint);

Android把bitmaps作为OpenGL的纹理来显示,第一次在一帧中显示bitmap时,它就会被上传到GPU上。如下图Systrace所示的Upload width x heigth Texture。虽然它只需要若干毫秒,但还是很有必要让GPU去显示图片的。 
 
        如果这个过程占用很长的时间,可以先查看width和height的值。确保显示的bitmap没有比屏幕所需要展示位图的区域还大。如果width和height的值比展示bitmap的区域还大,那么就会导致upload bitmap to GPU的时间以及内存的浪费。不过现在的图片加载库基本都实现了合适的尺寸加载位图的功能。

原文地址:https://www.cnblogs.com/ganchuanpu/p/9107977.html

时间: 2024-08-29 19:30:59

自定义控件被忽略的渲染性能的相关文章

react+redux渲染性能优化原理

大家都知道,react的一个痛点就是非父子关系的组件之间的通信,其官方文档对此也并不避讳: For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in componentDidMount(), unsubscribe in componentWillU

浅析渲染性能(转)

这篇文章主要关注的是资源加载之后的性能,因为大多数用户关注的不是应用如何加载而是具体的使用.所以要快速响应用户,尤其是无线端,我们有必要了解浏览器渲染性能. RAIL 性能模型 首先一个需要思考的问题,怎样的网站是顺畅的?我们可能可以给一个大概的感觉,如:秒级响应等.其实,也可以给出一个很讨巧的答案:用户觉得顺畅的网站它就是顺畅的.因为几乎所有网站都希望将用户留在页面上,当然以用户为中心建立性能模型是必要的.下面是 Google 提出的一个以用户为中心的性能模型,里面的数据不是 Google 首

浅析渲染性能

这篇文章主要关注的是资源加载之后的性能,因为大多数用户关注的不是应用如何加载而是具体的使用.所以要快速响应用户,尤其是无线端,我们有必要了解浏览器渲染性能. RAIL 性能模型 首先一个需要思考的问题,怎样的网站是顺畅的?我们可能可以给一个大概的感觉,如:秒级响应等.其实,也可以给出一个很讨巧的答案:用户觉得顺畅的网站它就是顺畅的.因为几乎所有网站都希望将用户留在页面上,当然以用户为中心建立性能模型是必要的.下面是 Google 提出的一个以用户为中心的性能模型,里面的数据不是 Google 首

测试Qt Quick在各个平台上的3D渲染性能

测试Qt Quick在各个平台上的3D渲染性能 Qt是一个跨平台的GUI框架,它的QtQuick更是支持结合OpenGL原生的代码进行渲染.我想将我以前写的程序整合到QtQuick上来,看看渲染效果是否满意,于是写了一个小小的程序,来做一下渲染基准测试.运行结果出来,不容乐观呐. 蒋彩阳原创文章,首发地址:http://blog.csdn.net/gamesdev/article/details/43842131.欢迎同行前来探讨. 首先为了描述最基本的情况,我制作了一个带有纹理的立方体.它使用

React爬坑秘籍(一)——提升渲染性能

React爬坑秘籍(一)——提升渲染性能 ##前言 来到腾讯实习后,有幸八月份开始了腾讯办公助手PC端的开发.因为办公助手主推的是移动端,所以导师也是大胆的让我们实习生来技术选型并开发,他来做code review.之前也学习过React,当然也是非常合适这一次的开发. 我会梳理这一个月来,自己对架构的思考过程和踩过的坑.当然这一切都不一定是最佳的,所以希望能有更多的建议和讨论. 例子所需库:Webpack.React.Immutable.其中Webpack用于前端构建,如果不清楚的同学可以看这

图形性能(widgets的渲染性能太低,所以推出了QML,走硬件加速)和网络性能(对UPD性能有实测数据支持)

作者:JasonWong链接:http://www.zhihu.com/question/37444226/answer/72007923来源:知乎著作权归作者所有,转载请联系作者获得授权. -----图形性能部分-----Qt的widgets部分,运行时的图像渲染性能是一般的,因为大部分的界面内容都是Qt自绘,没有走硬件加速,也就是说很多图形内容都是CPU算出来的.但是widgets底层毕竟是C++,而且Qt的模块写的也不错,做过很多优化,这个渲染的性能在桌面上与有硬件加速的框架比差别不大,除

android app性能优化大汇总(UI渲染性能优化)

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

浏览器渲染基本原理(五):优化渲染性能

渲染卡顿是怎么回事? 网页不仅应该被快速加载,同时还应该流畅运行,比如快速响应的交互,如丝般顺滑的动画等. 大多数设备的刷新频率是60次/秒,也就说是浏览器对每一帧画面的渲染工作要在16ms内完成,超出这个时间,页面的渲染就会出现卡顿现象,影响用户体验. 为了保证页面的渲染效果,需要充分了解浏览器是如何处理HTML/JavaScript/CSS的. 渲染流程分为几步? JavaScript:JavaScript实现动画效果,DOM元素操作等. Style(计算样式):确定每个DOM元素应该应用什

通过分析 WPF 的渲染脏区优化渲染性能

原文:通过分析 WPF 的渲染脏区优化渲染性能 本文介绍通过发现渲染脏区来提高渲染性能. 本文内容 脏区 Dirty Region WPF 性能套件 脏区监视 优化脏区重绘 脏区 Dirty Region 在计算机图形渲染中,可以每一帧绘制全部的画面,但这样对计算机的性能要求非常高. 脏区(Dirty Region)的引入便是为了降低渲染对计算机性能的要求.每一帧绘制的时候,仅仅绘制改变的部分,在软件中可以节省大量的渲染资源.而每一帧渲染时,改变了需要重绘的部分就是脏区. 以下是我的一款 WPF