Android實際開發問題12 渲染初認識

2021-07-14 11:51:33 字數 2341 閱讀 2125

本篇部落格只是將自己對於ui渲染的認識簡單說明一下.

首先從android系統卡頓說起,android介面為什麼會發生卡頓呢?主要是因為android手機(大部分)渲染頻率為60hz,即1s可以渲染1000/60=16.6666ms,意思就是說,介面的處理必須在這16.666ms中處理完,如果由於繪製時間過長,超出了16.666那麼下一幀就會缺少時間繪製,因為在繪製過程中已經到了臨界時間,這樣就出現了丟幀,就導致了卡頓情況的發生..

為了避免這種情況的發生,就要想辦法將所有操作在16.666ms之中完成,也就是減少渲染時間.下面通過乙個例子介紹一下:

假如讓乙個工人去刷一面5m*5m的牆,平均分成五份,每份塗一種顏色,總共五種顏色,下面給出兩種解決方案:

a.現將牆整體刷為一種顏色,然後再將牆的4/5刷成第二種顏色,以此類推,將牆刷為五種顏色....

b.找到五種顏色的臨界點,然後在各自的區域裡刷上不同的顏色...

我想只要沒有什麼奇葩想法的,應該都會覺得b算是兩種解決方案中最為合理的一種....a方案耗費時間是b方案的3倍,而且還大大的消耗了資源....

通過上面這個例子,能夠聯想到android顯示區域就是這面牆,怎麼樣能夠合理的顯示布局控制項,就可以快速的提公升渲染速度和所需資源

下面通過系統自帶的渲染工具,我們可以了解一下渲染情況:設定->開發人員選項->除錯gpu過度繪製->顯示過度繪製區域

這裡共有四種顏色,分別代表渲染的力度:

1x 藍色區域

2x 綠色區域

3x淺紅色區域

>=4x深紅色區域

這裡的x表明的就是每乙個畫素的點被渲染的次數,渲染次數越多,渲染時間越長

下面看看如果如下**

這個是mainactivity,裡面什麼內容都沒有,所以他的顯示區域是這樣的

完全的白色區域,沒有渲染痕跡,這也就說明在布局根目錄以及其父類容器並未進行渲染

然後新增一層帶有背景色的容器

當前的渲染狀況

然後繼續向裡面新增有背景色的容器

當前的渲染情況

再次新增一層帶有背景色容器

當前渲染狀況

再次新增一層帶有背景色的容器

當前的渲染情況

當前就是最高的除錯顯示級別,再加入帶有背景色的容器顯示也和上面一樣

顯示狀況:

可以看出並無太大區別...

然後去掉每一層的背景色

當前的顯示狀況

所以通過以上介紹我們就能夠看出要想不過度渲染,最好要詳細設計好控制項的擺放...

下面展示一下我自己的自定義view,雖然明白上述道理,可是豐富的ui還是屢屢觸及底線

當前的顯示

上面可以看出這裡的過度渲染十分嚴重,設法去除掉activity跟布局背景色之後

雖然也有部分是過度渲染,但是顯然看起來更加舒服了.....

這個頁面的時間整體就是乙個view,下面展示一下:

android開發問題彙總

原因在於電腦vt技術沒有開啟,網路上關於這方面的解決已經很多了,博主也是按著一樣的解決思路,發現bios已經開了,但是haxm一直無法安裝成功,會提示vt還是沒有開啟,而自己明明已經把vt開啟了 博主的電腦是hp的,其他品牌電腦,大同小異 最後,發現是萬能的360把vt被遮蔽了。開啟360安全衛士 ...

Virsual Studio 開發問題

win32 控制台應用 自動生成 stdafx.h stdatx.cpp resouce.h targetver.h 工程名.cpp win32 dll 自動生成 stdafx.h stdatx.cpp resouce.h targetver.h 工程名.cpp dllmain.cpp stdafx...

開發問題集合

q1 變數儲存 超出範圍問題 設計id為256位的變數,策劃填表的時候超出範圍,最終儲存的變數將被截斷,導致與表中的資料不一致 a1 這時改變資料結構的話會導致之前擁有該物品的玩家丟失資料,建議的解決方案為,可臨時改變表中資料id為截斷後的數值,在每一次儲存資料的時候將數值手動進行判斷,若超出範圍的...