Android在创建硬件层慢的原因分析

      最近在项目上,发现很多应用在开始滑动的时候,都会卡顿一下,看了一下systrace文件,可以看到在buildLayer的时候耗时比较长:

      到是在glTexImage2D耗时比较多。进一步使用GL Trace分析,可以看到:

glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = 6408, width = 1024, height = 1536, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = []) 

Wall time: 15, 911, 458 ns 

Thread time: 13, 418, 698 ns 

glEndTilingQCOM(preserveMask = 1) 

Wall time: 183, 106 ns 

Thread time: 183, 105 ns 

可以看到Open GL ES在draw的时候,耗时异常。

         对比以前的平台:

glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = 6408, width = 1024, height = 1536, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = []) 

Wall time: 1, 708, 984 ns 

Thread time: 1, 708, 984 ns 


glEndTilingQCOM(preserveMask = 1) 

Wall time: 7, 468, 021 ns 

Thread time: 4, 963, 803 ns 


在draw TexImage的时候,是多么的简洁干练呀!

同事通过跟踪glTexImage2D可以看到,这个时候是因为有大的内存copy操作,因为屏幕分辨率很大,而且有一张大的图片,导致有一个10.5M的内存拷贝操作,而这个操作时很耗时的。

        我们跟踪了很多天,芯片厂商也跟踪了很多天,至少有一个月左右的时间吧!问题依然毫无进展,痛苦呀!

        突然有一天,问题由所好转了!这是怎么一回事呀?上帝真好!于是呼我折腾了一天,回退了一下版本,发现一个修改kernel的config文件的版本把这个问题改好了!

         来回折腾以后,发现config文件都用错了!这让我情何以堪呀!当时我读到Sun的Dtrace的开发人员找到,是因为把服务器配置成了路由器,引发出性能问题,从而萌发出开发Dtrace的时候,我觉得Sun的人很“傻”!我现在觉得我们也聪明不到哪去,而且还在走别人10多年前的老路!至少别人开发了Dtrace,我确无动于衷!人生最大的悲哀莫过于此!

评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值