前段時間對我們原有的一個im應(yīng)用進(jìn)行了優(yōu)化重構(gòu)。
對于聊天會話界面琼开，涉及到文本易结、圖片、語音柜候、通知等等不同消息(cell)的顯示搞动，且不同的消息內(nèi)容，cell的高度都是不固定的渣刷，手動動態(tài)計算每個cell的高度感覺實在是太麻煩了鹦肿，而且感覺效率也不高，一堆計算辅柴、分支擺在那里箩溃，代碼看著也不好維護，于是決定借助ios8 新引入的auto sizing cell特性對該界面進(jìn)行重寫碌嘀。
整個重寫過程進(jìn)行的很順利涣旨，cell使用相對布局，然后設(shè)置estimatedRowHeight筏餐，剩下的高度計算就交給系統(tǒng)了开泽，確實省下了相當(dāng)多的計算與邏輯，代碼看起來也簡單清晰了很多魁瞪，達(dá)到了我的優(yōu)化目的穆律。但是惠呼，這里出現(xiàn)了一個問題，在數(shù)據(jù)添加峦耘，reloadtable后剔蹋，調(diào)用[Table scrollToRowAtIndexPath:[NSIndexPath indexPathForRow:row inSection:0] atScrollPosition:UITableViewScrollPositionBottom animated:NO];時，在某些情況下辅髓，table總是無法滾動到正確的指定位置泣崩，對顯示效果產(chǎn)生了很大影響。
這個問題困擾了我很久洛口，反復(fù)的檢查自己的代碼邏輯(代碼中涉及到了table的ContentInset的調(diào)整矫付，我開始一直以為是我這個值設(shè)置的有問題造成的錯誤)，log各種table相關(guān)的坐標(biāo)信息都找不到問題所在第焰，但也摸到了一些規(guī)律买优，最后我開始懷疑是蘋果這套機制的問題了，于是我在調(diào)用scrollToRowAtIndexPath時挺举，把它放到dispatch_after中杀赢，讓其在reloaddata后延遲0.1-0.2秒的時間再去滾動(給系統(tǒng)“足夠”的時間去繪制table)，驚奇的發(fā)現(xiàn)湘纵，問題竟然解決了脂崔。。梧喷。障簿。雏门。虐呻。
但是這樣解決方式終歸不好 1.這個0.1-0.2秒的延時是我實驗得出的去团，沒有任何參考依據(jù)? 2.在某些特定使用場景下文搂，這個很短的延時還是會讓用戶覺察出輕微的卡頓? 3.以后別人維護代碼時肯定會對加這個邏輯迷惑不已适刀。
于是我繼續(xù)嘗試搜索，最后發(fā)現(xiàn)了也有幾個人遇到了和我相同的問題煤蹭，帖子里面還有人說這是ios的bug(但最后我覺得算不上bug,只能說是這套機制有坑)
stackoverflow.com/questions/25686490/ios-8-auto-cell-height-cant-scroll-to-last-row
http://technology.ezeenow.com/posts/5731/iOS_8_Auto_cell_height_Can_t_scroll_to_last_row
1.用dispatch_after一個很短的時間再去scrollToRowAtIndexPath笔喉，竟然和我之前的解決方式一樣。硝皂。常挚。。稽物。奄毡。
2.正確設(shè)定estimatedRowHeight(有個老外這么解決的)，也是我最終的解決方法
當(dāng)時學(xué)習(xí) auto sizing cells 時贝或，看了網(wǎng)上很多文章教程吼过，對estimatedRowHeight的設(shè)置基本都十分草率锐秦，過分強調(diào)了其便捷性，基本上都只說了這個值必須要有盗忱，而且基本都是告訴你針對不同cell酱床，統(tǒng)一預(yù)估個大概的平均值就行(還強調(diào)一下，十分方便......)趟佃，但實踐證明扇谣，這個值的設(shè)置簡直太重要了，千萬不可草率設(shè)置闲昭。
最終
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
JHMessageObject *msg = [_msgAry objectAtIndex:[indexPath row]];
switch (msg.msgType) {
case IMTypePlain:
return 80;
case IMTypeImage:
return 160;
case IMTypeVoice:
return 65;
case IMTypeRoomNof:
return 65;
case IMTypeRevoke:
return 65;
default:
return 80;
}
return 80;
}
我重寫了estimatedHeightForRowAtIndexPath方法罐寨，針對不同的消息類型（cell樣式）， 分別去相對精確的去預(yù)設(shè)他們的高度序矩，最終bug解決了衩茸，顯示效果也十分理想
可以說estimatedRowHeight的正確設(shè)置，不僅影響了table的繪制效率贮泞，同時還能避免出現(xiàn)很多莫名其妙的詭異問題楞慈，希望后面的同學(xué)在使用中多加注意
