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，我确无动于衷！人生最大的悲哀莫过于此！