內(nèi)存檢測和離屏渲染的優(yōu)化

? 內(nèi)存檢查

? ? ? ? 在檢測內(nèi)存之前,我們需要知道ios內(nèi)存檢測工具,常見的有:Instruments的Leaks、Build And Analyze、Memory Graph、MLeaksFinder等。

? ? ? Build And Analyze:這種檢測方法操作比較簡單:只需要打開項目工程,選擇Product→Analyze 或者快捷鍵command +? shift + B 即可。檢測一會兒就會出現(xiàn)如下圖一:



圖一

這種分析內(nèi)存的方法,速度快,不運行代碼,分析代碼的結(jié)構(gòu),我們在項目上線前可以簡單的處理代碼問題

? ? ? ? 1 Dead Stroe:代碼書寫問題,一般會報錯如下警告

? ? ? ? Value stored to 'xxx' during its initialization is never read(字面理解是初始化對象xxx無法在程序讀取) 這個警告出現(xiàn)的原因有好多情況:如初始化了對象,但是沒有使用,對象沒有初始化,就開始使用 初始化了兩次等等

圖示二



圖示三
圖示四

? ? ? ? 解決辦法: 對于圖示二 圖示三 這類問題,一直存在工程中,寶寶也是大吃一驚,后來才知,工程維護(hù)的人多,哈哈哈 這就沒辦法了? 圖示四:是我常犯的錯誤,結(jié)構(gòu)體或者對象沒有初始化(startPt) ,就開始使用了;修改如下 CGPoint startPt = CGPointZero

2 Core Foundction/Obeject-C

? ? ? 這個問題,很容易被開發(fā)者忽略,沒有遵循oc語音的特性,就隨性上代碼,也是筆者所犯的錯誤,廢話少說,有圖有證據(jù)!

圖2-1

? ? ? ? OC所寫的代碼都是基本是繼承與NSObject 的,所以有時候需要用super 去調(diào)用父類的方法,只有父類知道怎么去執(zhí)行,子類要想實現(xiàn) 必須先調(diào)用父類的方法!? 血淚啊 !


3 Apple Misuse(Apple)

? ? ? 這類問題,是非常危險的!筆者的理解是,就是潛在的死循環(huán)的始作俑者,一旦上線崩潰,臉上會掛不住的!比如:


圖3-1b

不可變字典對象(dict)value值不能為空,如果在某種情況下value = nil,程序直接崩潰,修復(fù)方式有兩種方式:

第一種: 將快速定義不可變字典的({})方式改為:可變字典處理即可.

第二種:利用異常處理(Java中用比較多)方式,如下:

@try {

<#Code that can potentially throw an exception#>

} @catch (NSException *exception) {

<#Handle an exception thrown in the @try block#>

} @finally {

<#Code that gets executed whether or not an exception is thrown#>;

@try {

//插碼需求,我的設(shè)置

NSDictionary *dict = @{@"WT.mobile":[UserLoginHelper sha

redInstance].userId,

@"WT.es":@"我的移動",

@"WT.event":item.title};

[WebtrendHelper sendEventWithActionAtPath:@"/wdyd" Description:@"wdyd" eventType:@"click" setCustomParameters:dict];

} @catch (NSException *exception) {

// 異常處理

} @finally {

}

4 Memory(Core Foundction/Obeject-C)

? ? ? ? 通常會有這樣的警告:potential leak of an object stored into XXX 意思是潛在的內(nèi)存泄露,我們有時候用某個客戶端,忽然之間消失了,打開又好了,筆者所遇到項目中,就有這類問題,測試發(fā)現(xiàn),這類問題大多數(shù)是內(nèi)存泄露引起的,不過因筆者的水平有限,單單用Build And Analyze分析是無法找到這些問題病根的;所寫的代碼在32位的操作系統(tǒng)上有卡死不動情況,真是蛋疼的節(jié)奏!不知道如何解決這些問題,望大神多多指教。


4-1

? ? ? 圖示4-1 是獲取通訊錄信息代碼,addressBook出現(xiàn)了潛在的內(nèi)存泄露,測試發(fā)現(xiàn)少量手機(jī)會崩潰,仔細(xì)檢查代碼發(fā)現(xiàn)如圖(4-2);

4-2

修改如下即可:

4-3

5 Memory Error

? 在內(nèi)存檢測中遇到了這樣的警告"Use of zero-allocationed memory",不是很理解,圖示如下:(是個地圖導(dǎo)航類.mm文件中出現(xiàn)的)


5-1

離屏渲染

那么到底什么是離屏渲染詳細(xì)可以拜讀https://zhuanlan.zhihu.com/p/72653360

對當(dāng)前App的界面進(jìn)行了離屏渲染結(jié)果是黃色到處都是,這些界面是由UITabView實現(xiàn),之所以會很多離屏渲染,主要有以下原因造成

(1) layer的cornerRadius屬性和masksToBounds屬性使用不當(dāng),以為只要使用了這兩個屬性,就會離屏渲染,這是大錯特錯的.

(2) 濫用layer的mask屬性:控件切圓角.部分代碼如下:


針對這兩種情況,可以考慮如下優(yōu)化:

(1) 考慮使用AsyncDisplayKit庫,全面提升控件異步渲染性能.

(2) 視圖陰影,圓角可以考慮用圖片代替

(3)? 如果無法用圖片代替,cornerRadius屬性和masksToBounds屬性合理使用,讓控件的合理的情況下觸發(fā)設(shè)置圓角.

如對UILable的圓角設(shè)置:

let lable =UILabel.init(frame:CGRect(x:0, y:0, width:100, height:20))

? ? //設(shè)置背景色 給layer設(shè)置,圓角才有效

? lable.layer.backgroundColor = UIColor.white.cgColor

? lable.layer.cornerRadius=10;

(4) 減少對某個視圖 某個方向切圓角 ...... 實在不行就core grapics繪制吧!!! 但性能稍微比mask好點.

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容