今天回顧了下這個(gè)直播 優(yōu)化TableView滑動(dòng)體驗(yàn)阱佛，其中前面講的影響性能的點(diǎn)的印象比較深刻，特此記錄耍缴。
- 一砾肺、較多出現(xiàn)影響性能的點(diǎn)
- 二、額外想到之前看到的點(diǎn)
- 三私恬、對(duì)某些的擴(kuò)展
一债沮、影響性能的點(diǎn)
主線程干了與繪制無關(guān)的事情炼吴，凡是耗時(shí)的都有影響本鸣。當(dāng)然把復(fù)雜的事情放到異步線程中去，假如計(jì)算時(shí)間比較久時(shí)硅蹦，滑動(dòng)時(shí)也可能出現(xiàn)空白的情況荣德，也是很不爽的。
- 1童芹、大量的對(duì)象的創(chuàng)建和銷毀涮瞻，過多的時(shí)候肯定是有影響，這個(gè)無須多說假褪。
- 2署咽、文本的計(jì)算多的話，放在主線程肯定就有影響生音。很多時(shí)候我們可以都把那個(gè)計(jì)算提前算出來宁否。
- 3、服務(wù)器下發(fā)的圖片和實(shí)際的尺寸不一致缀遍，不得不去手動(dòng)改尺寸慕匠，而重新計(jì)算尺寸就是有影響性能的。
- 4域醇、重復(fù)去讀圖片台谊，可以采取緩存的方法去避免重復(fù)蓉媳。
- 5、設(shè)置圓角锅铅。其實(shí)單純的設(shè)置圓角很簡單酪呻，它不會(huì)帶來任何性能損耗。
view.layer.cornerRadius = 10.0f;
因?yàn)樵谀J(rèn)情況下盐须，這個(gè)屬性只會(huì)影響視圖的背景顏色和 border号杠。而是我們加上
label.layer.cornerRadius = 10.0f;
label.layer.masksToBounds = true；
也就是說設(shè)置 masksToBounds才會(huì)導(dǎo)致離屏渲染丰歌，從而影響性能的姨蟋。具體可以看看iOS 高效添加圓角效果實(shí)戰(zhàn)講解。
- 6立帖、cell 不復(fù)用眼溶，這個(gè)基本不會(huì)用到，我們現(xiàn)在一般都會(huì)用的吧晓勇。
- 7堂飞、圖片的透明，盡量不要用绑咱，渲染過程相對(duì)比會(huì)多好幾倍
- 8绰筛、用AutoLayout 某種程度是會(huì)重新計(jì)算的，自然是耗時(shí)的描融。
話說铝噩，其中有些點(diǎn)上現(xiàn)在是無不可避免的，例如自動(dòng)布局這塊窿克，現(xiàn)在的項(xiàng)目基本都是用的骏庸，而且隨著硬件的性能越來越好，小性能的缺失是可以忽略的年叮，整體來說掌握一個(gè)度吧具被。
二、額外想到之前看到的點(diǎn)
- iOS 保持界面流暢的技巧 : YY 作者所寫只损，絕對(duì)要看一姿。
- UIKit性能調(diào)優(yōu)實(shí)戰(zhàn)講解.
- iOS 程序性能優(yōu)化.
以下是 UIKit性能調(diào)優(yōu)實(shí)戰(zhàn)講解-- bestswifter 文章中提到的，在此直接摘抄下跃惫。
- 避免圖層混合
- 確倍Ｌ荆控件的opaque屬性設(shè)置為true，確保backgroundColor和父視圖顏色一致且不透明（就是不要設(shè)置View 的顏色 為Clear）
- 如無特殊需要辈挂，不要設(shè)置低于1的alpha值 （alpha = 1.0）
- 確保UIImage沒有alpha通道
- 避免臨時(shí)轉(zhuǎn)換
- 確保圖片大小和frame一致衬横，不要在滑動(dòng)時(shí)縮放圖片( 和重新計(jì)算尺寸有關(guān))
- 確保圖片顏色格式被GPU支持，避免勞煩CPU轉(zhuǎn)換 （CPU 要做的事太多了）
- 慎用離屏渲染
絕大多數(shù)時(shí)候離屏渲染會(huì)影響性能 （shouldRasterize（光柵化终蒂、masks（遮罩）蜂林、shadows（陰影）遥诉、edge antialiasing（抗鋸齒）、group opacity（不透明）噪叙、復(fù)雜形狀設(shè)置圓角等矮锈、漸變...）- 重寫drawRect方法，設(shè)置圓角睁蕾、陰影苞笨、模糊效果，光柵化都會(huì)導(dǎo)致離屏渲染
- 設(shè)置陰影效果是加上陰影路徑
- 滑動(dòng)時(shí)若需要圓角效果子眶，開啟光柵化
特別是那個(gè) View 設(shè)置成 [UIColor clearColor] 是我常犯的錯(cuò)瀑凝。
三、單獨(dú)想想高度相關(guān)的優(yōu)化
對(duì)上述其中的一些點(diǎn)還沒有切身的感受體驗(yàn)臭杰，另外有些是沒法避免的粤咪，但最近老用都愛文字計(jì)算高度這塊，就想著如何讓涉及到文字計(jì)算高度這塊的影響降低呢渴杆？
- 異步處理寥枝？
- 提前處理？
- 緩存 磁奖？
例如像 Cell 和 UILabel 中的計(jì)算：
- UITableView 中 Cell 的高度處理
固定高度時(shí)囊拜，盡量直接用下面這個(gè)，而不用那個(gè)代理中的高度返回
self.tableView.rowHeight = 44;
另外比搭，高度不固定時(shí)可以用到緩存冠跷，就是那個(gè)UITableView-FDTemplateLayoutCel
#import "UITableView+FDTemplateLayoutCell.h"
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return [tableView fd_heightForCellWithIdentifier:@"reuse identifer" configuration:^(id cell) {
// Configure this cell with data, same as what you've done in "-tableView:cellForRowAtIndexPath:"
// Like:
// cell.entity = self.feedEntities[indexPath.row];
}];
}
源自：優(yōu)化UITableViewCell高度計(jì)算的那些事
- UILabel 中文字高度的計(jì)算
- (CGSize)sizeThatFits:(CGSize)size;
- (CGRect)boundingRectWithSize:(CGSize)size options:(NSStringDrawingOptions)options attributes:(nullable NSDictionary<NSString *, id> *)attributes context:(nullable NSStringDrawingContext *)context
上面相對(duì)來說，是我們平常計(jì)算高度最常用的方法敢辩，前者是 View 本身的蔽莱，后者是 String 的弟疆，但是他們放在什么位置呢戚长，此時(shí)我的想法是提前計(jì)算好，不要等到真正滑動(dòng)時(shí)再來算怠苔，這樣相對(duì)來說同廉，對(duì)性能的影響就減少啦。例如數(shù)據(jù)返回的時(shí)候柑司，順便立馬就將其需要計(jì)算的高度迫肖，然后等到需要數(shù)據(jù)更新時(shí)，高度也一并返回把高度給計(jì)算好攒驰。
其實(shí)這個(gè)地方有個(gè)問題蟆湖，當(dāng)我們用自動(dòng)布局的時(shí)候，數(shù)據(jù)更新的時(shí)候一般還是會(huì)重新計(jì)算一下約束的玻粪，還是有影響的隅津。不過這也不是計(jì)算高度所涉及到的話題咯诬垂。
四、另外注意下：性能測(cè)試方法
- TimeProfile (最直觀的)
- CADisplayLink (fps 值的記錄)
目前個(gè)人還是只看看 TimeProfile 的伦仍，實(shí)際的不多结窘，另外之前試用了下JPFPSStatus感覺還是很清晰，但是木有自己公司的項(xiàng)目中試過充蓝。
總的說來還是要多實(shí)際操作對(duì)比的隧枫，不斷總結(jié)，注意一些常用的性能影響原因谓苟，反正iOS 保持界面流暢的技巧 絕對(duì)要多看看官脓。
