iOS開(kāi)發(fā)初學(xué)者詳細(xì)總結(jié)

基礎(chǔ)篇

為什么對(duì)一個(gè)變量release后還要設(shè)為nil

對(duì)一個(gè)變量release后，這個(gè)變量指向的內(nèi)存釋放了，但這個(gè)變量本身沒(méi)變，仍指向原來(lái)的內(nèi)存地址。若這個(gè)變量在釋放后被訪問(wèn)，或者被重復(fù)release，就會(huì)導(dǎo)致應(yīng)用崩潰。設(shè)為nil后這個(gè)變量指向0×00，可以保證程序以后訪問(wèn)不到原先的內(nèi)存地址，對(duì)nil進(jìn)行release也沒(méi)任何問(wèn)題。

使用類(lèi)成員時(shí)，前面加不加self.有什么區(qū)別

不加self.調(diào)用的是成員本身，加self.后實(shí)際上調(diào)用了其成員的get set方法。

例:

//.h

@property (nonatomic, retain) NSString *name

//.m

name = @"bang" //沒(méi)有retain，隨時(shí)會(huì)被釋放

NSString *str = self.name //等于NSString *str = [self name];

self.name = @"bang" //等于[self setName:@"bang"]; 這時(shí)在set方法里retain了這個(gè)字符串

技巧篇

內(nèi)存泄漏

可以通過(guò)xcode的編譯工具Product-Analyze檢查函數(shù)塊范圍內(nèi)可能的泄漏點(diǎn)(外帶會(huì)提示一些可能有的錯(cuò)誤)。

用leaks工具監(jiān)測(cè)出來(lái)的泄漏查找方法是跟蹤其代碼提示中出現(xiàn)的變量，經(jīng)常這個(gè)變量是在提示的調(diào)用堆棧以外的地方泄漏的。若實(shí)在查不到，最終辦法是重寫(xiě)這個(gè)變量的retain和release方法，debug，從調(diào)用堆棧看是誰(shuí)retain了它而沒(méi)有release。

要注意的是，用CFXXCreate(例如CFArrayCreate)生成的變量要用CFRelease釋放。

數(shù)據(jù)存儲(chǔ)

如無(wú)搜索需要，可以將一個(gè)數(shù)據(jù)對(duì)象直接序列化后存到sqlite，取出時(shí)直接反序列化為對(duì)象使用。序列化需要數(shù)據(jù)類(lèi)實(shí)現(xiàn)NSCoding協(xié)議，實(shí)現(xiàn)encodeWithCoder和initWithCoder兩個(gè)方法就行，若有多個(gè)數(shù)據(jù)對(duì)象，可以寫(xiě)個(gè)基類(lèi)實(shí)現(xiàn)這兩個(gè)方法，并在這里面利用反射枚舉自身所有變量去encode和decode，一勞永逸，具體實(shí)現(xiàn)網(wǎng)上找找就有了。

組件篇

UINavigationController頭尾顯示隱藏

在用NavigationController去管理view的push和pop時(shí)，需要根據(jù)不同的view設(shè)置是否顯示NavigationBar和ToolBar，一開(kāi)始在錯(cuò)誤的地方設(shè)置了，導(dǎo)致有時(shí)該顯示NavigationBar和ToolBar時(shí)不顯示的情況，后來(lái)發(fā)現(xiàn)在viewWillAppear上設(shè)置萬(wàn)無(wú)一失。別笑我土鱉，沒(méi)好好去理解它整個(gè)流程，一直沒(méi)發(fā)現(xiàn)。

- (void) viewWillAppear:(BOOL)animated{

[super viewWillAppear:animated];

[self.navigationController setToolbarHidden:NO];

[self.navigationController setNavigationBarHidden:NO];

}

UITableView游標(biāo)式渲染

tableView的機(jī)制大概是：先定好總行數(shù)，某一行滾入視圖范圍時(shí)，回調(diào)一個(gè)函數(shù)去取view出來(lái)顯示。這一行滾出視圖再滾入時(shí)仍會(huì)繼續(xù)回調(diào)這一函數(shù)取view。有這樣的機(jī)制就是說(shuō)無(wú)論你table里的數(shù)據(jù)有多少，都可以全部放入table中不用分頁(yè)，因?yàn)椴挥靡淮涡园阉袛?shù)據(jù)都取出來(lái)，只在需要顯示的時(shí)候根據(jù)游標(biāo)去取對(duì)應(yīng)的數(shù)據(jù)就行了。

可能這是APP組件很自然的方式不用說(shuō)明，但在web上頁(yè)面上的數(shù)據(jù)和元素都是要一次性載入內(nèi)存的，做久了web，一開(kāi)始沒(méi)想到它這樣的實(shí)現(xiàn)機(jī)制，導(dǎo)致我們走了不少?gòu)澛贰?

UIWebView渲染范圍

UIWebView不是根據(jù)可視范圍決定每次的渲染范圍，而是根據(jù)自身控件的frame大小決定。

曾嘗試webview嵌在tableview里，為了讓webview跟tableview一起滾動(dòng)，把webview的大小設(shè)為webview里的內(nèi)容大小，讓webview不出滾動(dòng)條，從而能跟著tableview的滾動(dòng)條一起滾。這樣做的后果是每次webview都一次性渲染整個(gè)頁(yè)面，內(nèi)存占用多性能很差，而且在放大縮小這個(gè)webview時(shí)，渲染放大的整個(gè)頁(yè)面更吃力，出現(xiàn)不能忍受的性能。解決辦法是讓webview定住高度為一整屏iphone的高度，限制了webview每次的渲染范圍為可視范圍，性能大好。帶來(lái)的問(wèn)題是無(wú)法隨tableview滾動(dòng)，但可以以其他方式優(yōu)化體驗(yàn)。最近看到新版的ZAKER也是這樣做的。

個(gè)人感覺(jué)篇

界面布局調(diào)整非常麻煩，讓人懷念web了。界面描述方法XIB感覺(jué)晦澀難學(xué)，至今不會(huì)，沒(méi)有CSS+HTML來(lái)得方便。

有編譯器把關(guān)，少了像寫(xiě)js時(shí)多寫(xiě)or寫(xiě)錯(cuò)一個(gè)字符查半天的問(wèn)題。

Object-C寫(xiě)起來(lái)各種變量函數(shù)和變量調(diào)用很長(zhǎng)，沒(méi)有js的短小精悍來(lái)得爽。

第一次編寫(xiě)涉及手動(dòng)內(nèi)存管理的程序，挺有意思，沒(méi)想象中難，但有些內(nèi)存管理導(dǎo)致的bug很難查。

雖然APP不像web那樣隨時(shí)更新，但也不像傳統(tǒng)PC客戶(hù)端升級(jí)那么麻煩，用戶(hù)更新意愿更強(qiáng)，還是適合快速迭代的。

細(xì)節(jié)是可以決定成敗，但得看你把什么定成細(xì)節(jié)。

最后，0 bug的程序不存在，極致是把最主要的事做好。done is better than perfect。