亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

Android開發(fā)筆記之:深入理解Cursor相關(guān)的性能問題

 更新時(shí)間:2013年05月21日 10:50:31   作者:  
本篇文章是對(duì)Android中Cursor相關(guān)的性能問題進(jìn)行了詳細(xì)的分析介紹,需要的朋友參考下

當(dāng)數(shù)據(jù)庫中存有大量數(shù)據(jù)的時(shí)候,用Cursor查詢時(shí)要注意,有可能引發(fā)性能問題。數(shù)據(jù)庫查詢出來的Cursor都會(huì)由一個(gè)CursorWindow來進(jìn)行數(shù)據(jù)管理,包括內(nèi)存空間的申請(qǐng)和數(shù)據(jù)的填充。CursorWindow對(duì)Cursor中的內(nèi)容大小有限制,限制為1024*1024也就是1M,換句話說Cursor中數(shù)據(jù)的大小不能超過1M,如果超過1M會(huì)引發(fā)如下的錯(cuò)誤:

復(fù)制代碼 代碼如下:

08-23 05:48:31.838: DEBUG/Cursor(1805): skip_rows row 149
08-23 05:48:31.844: ERROR/CursorWindow(1805): need to grow: mSize = 1048576, size = 11499, freeSpace() = 7397, numRows = 80
08-23 05:48:31.844: ERROR/CursorWindow(1805): not growing since there are already 80 row(s), max size 1048576
08-23 05:48:31.844: ERROR/Cursor(1805): Failed allocating 11499 bytes for blob at 228,7
08-23 05:48:31.849: DEBUG/Cursor(1805): finish_program_and_get_row_count row 12
08-23 05:48:31.851: DEBUG/browser/BrowserBookmarkFoldersAdapter(1805): getView()-Position:149
08-23 05:48:32.019: DEBUG/Cursor(1805): skip_rows row 148

這表明CursorWindow中的空閑空間已經(jīng)不足,已經(jīng)在申請(qǐng)新的空間,但似乎申請(qǐng)失敗。這個(gè)錯(cuò)誤有時(shí)候會(huì)導(dǎo)致查詢得到的Cursor為null,有時(shí)候不會(huì)引發(fā)太嚴(yán)重的問題。但是它會(huì)引起性能上的問題,不停的申請(qǐng)空間會(huì)占用大量的CPU時(shí)間,從而導(dǎo)致整個(gè)手機(jī)變卡。特別是在ListView或GridView中綁定的Cursor,會(huì)導(dǎo)致無法滑動(dòng),或者滑動(dòng)變的十分的卡。用Android2.3的原生Browser,打開其中的歷史記錄,當(dāng)有超過200條歷史記錄時(shí),不停的滑動(dòng),特別是由下向上滑時(shí)會(huì)變的十分的卡,而對(duì)于其書簽,如果條目超過100,且每個(gè)都有縮略圖時(shí),滑動(dòng)會(huì)變得特別的卡,甚至都打不開,就是這個(gè)原因。
這個(gè)問題沒有根本的解法,這是Android系統(tǒng)的限制,唯一可行的就是想辦法避免,也就是盡可能讓Cursor的大小 小于1M,以下是可行的方法:
1. 只查詢需要的字段
這個(gè)特別重要,根據(jù)UI顯示的需要,或者實(shí)際的需要查詢需要的字段。就是一定要給ContentResolver.query(uri, projection)第二個(gè)參數(shù)PROJECTION,如果這個(gè)參數(shù)為null,那么就會(huì)查詢表中所有的字段,那么當(dāng)條數(shù)一增加Cursor的大小 會(huì)增長很快。Browser中歷史記錄的原因就是它在query的時(shí)候查詢了所有的字段,其數(shù)所庫中保存了favicon和thumbnail二進(jìn)制文件,因此當(dāng)包含了這二個(gè)字段時(shí),Cursor的容量很容易就達(dá)到了限制。
2. 二進(jìn)制文件不要存在數(shù)據(jù)庫中
數(shù)據(jù)庫僅適用于保存一些較短文字,整數(shù),布爾,浮點(diǎn)數(shù)等一些,易于查詢和操作的輕量級(jí)的數(shù)據(jù),目的也是在于快速搜索和查詢。對(duì)于像圖片,較長的文字(如文章)等大數(shù)據(jù),最好直接以文件形式存儲(chǔ)在硬盤中,然后在數(shù)據(jù)庫保存它們的訪問路徑。對(duì)于像favicon這樣的小圖片也可以考慮存在數(shù)據(jù)庫中,但是像對(duì)于thumbnail的圖片就不明智,除非整個(gè)應(yīng)用在數(shù)量上有限制(比如只有幾十或百級(jí))否則很容易在查詢的時(shí)候達(dá)到1M的限制。
3. 對(duì)于特別大量的數(shù)據(jù)超過5000級(jí)或萬級(jí)或十萬級(jí)或百萬級(jí)的要分段查詢
無論表中的一條記錄數(shù)據(jù)量如何的小,當(dāng)條數(shù)達(dá)到5000級(jí)或者萬級(jí)或者更多的時(shí)候,還是會(huì)達(dá)到1M的限制,這時(shí)就需要分段查詢,比如每次查詢500個(gè),或者1000個(gè)。另外,如果是要做展示用,這么多數(shù)據(jù)一下子出來,用戶也不方便查看。
【實(shí)例】Android2.3書簽,歷史記錄和最多訪問三個(gè)頁面當(dāng)數(shù)據(jù)量達(dá)到300左右時(shí),就會(huì)出現(xiàn)滑動(dòng)很卡的現(xiàn)象,特別是由下向上滑動(dòng)時(shí),特別的卡,會(huì)狂打出:
復(fù)制代碼 代碼如下:

08-23 05:48:31.844: ERROR/CursorWindow(1805): need to grow: mSize = 1048576, size = 11499, freeSpace() = 7397, numRows = 80
08-23 05:48:31.844: ERROR/CursorWindow(1805): not growing since there are already 80 row(s), max size 1048576
08-23 05:48:31.844: ERROR/Cursor(1805): Failed allocating 11499 bytes for blob at 228,7

這樣的LOG。而書簽似乎都沒有辦法打開和滑動(dòng),其特別的卡。
究其原因就是它們在查詢的時(shí)候都用了同一個(gè)字段集Browser.HISTORY_PROJECTION這個(gè)是把bookmarks表中的所有字段都 查詢出來。書簽,歷史記錄和最多訪問雖是三個(gè)不同的展示頁,但它們的數(shù)據(jù)是相同的都是來自bookmarks表。Bookmarks表中存有_id,title,url,bookmark,favicon,touch_icon,thumbnail等字段,其中favicon和thumbnail是二進(jìn)制圖片數(shù)據(jù)(byte[])。Browser.HISTORY_PROJECTION里面包含了所有的字段,當(dāng)然也包含了favicon和thumbnail,所以當(dāng)條目一旦達(dá)到200多時(shí),Cursor就會(huì)達(dá)到其1M的限制,因此會(huì)導(dǎo)致性能下降,滑動(dòng)變卡。

事實(shí)上對(duì)于歷史記錄和最多訪問二個(gè)頁面來講thumbnail和touch_icon根本就沒有用到,它只需要_id,title,url,bookmark和favicon;對(duì)于書簽頁,也僅是在GRID時(shí)才用到thumbnail。所以,只需要把查詢時(shí)的字段集Browser.HISTORY_PROJECTION中的THUMBNAIL去掉,即可以解決滑動(dòng)變卡。

相關(guān)文章

最新評(píng)論