最近在專案上，發現很多應用在開始滑動的時候，都會卡頓一下，看了一下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 = )可以看到open gl es在draw的時候，耗時異常。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
對比以前的平台：
glteximage2d(target = gl_texture_2d, level = 0, internalformat = 6408, width = 1024, height = 1536, border = 0, format = gl_rgba, type = gl_unsigned_byte, pixels = )在draw teximage的時候，是多麼的簡潔幹練呀！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
同事通過跟蹤glteximage2d可以看到，這個時候是因為有大的記憶體copy操作，因為螢幕解析度很大，而且有一張大的，導致有乙個10.5m的記憶體拷貝操作，而這個操作時很耗時的。
我們跟蹤了很多天，晶元廠商也跟蹤了很多天，至少有乙個月左右的時間吧！問題依然毫無進展，痛苦呀！
突然有一天，問題由所好轉了！這是怎麼一回事呀？上帝真好！於是呼我折騰了一天，回退了一下版本，發現乙個修改kernel的config檔案的版本把這個問題改好了!
來回折騰以後，發現config檔案都用錯了！這讓我情何以堪呀！當時我讀到sun的dtrace的開發人員找到，是因為把伺服器配置成了路由器，引發出效能問題，從而萌發出開發dtrace的時候，我覺得sun的人很「傻」！我現在覺得我們也聰明不到哪去，而且還在走別人10多年前的老路！至少別人開發了dtrace，我確無動於衷！人生最大的悲哀莫過於此！
關於Android硬體抽象層
1.為什麼需要硬體抽象層？硬體抽象層是把部分的驅動的工作放到使用者態，這樣做是因為linux遵循gun license 發布的時候需要公開源 而android是遵循apache license，無需公布源 顯然如果把驅動 晶元相關的所有 都對外公開會傷害商家的利益。2.硬體驅動層的基本架構是怎樣的？...
Android 硬體抽象層（HAL）
出發點 保護廠商利益 android的硬體抽象層，簡單來說，就是 對linux核心驅動程式的封裝，向上提供介面，遮蔽低層的實現細節。也就是說，把對硬體的支援分成了兩層，一層放在使用者空間 user space 一層放在核心空間 kernel space 其中，硬體抽象層執行在使用者空間，而linux...
android學習之旅 硬體抽象層
1 為什麼會新增硬體抽象層？如果不新增硬體抽象層，我們在android所用的linux核心中新增和修改 就要遵循gpl協議，將 公開。把對硬體的驅動程式的 公開，會損害移動裝置廠商的利益，因為這相當於暴露了硬體的實現細節和引數。所以android源 是遵循apache license協議，它允許移動...