基礎篇

為(wei)什么(me)對一個變量release后還(huan)要設為(wei)nil

對一(yi)個(ge)變(bian)(bian)量(liang)(liang)release后(hou)，這個(ge)變(bian)(bian)量(liang)(liang)指向的(de)內存釋放了，但(dan)這個(ge)變(bian)(bian)量(liang)(liang)本身沒變(bian)(bian)，仍指向原來的(de)內存地(di)址(zhi)。若這個(ge)變(bian)(bian)量(liang)(liang)在(zai)釋放后(hou)被(bei)訪(fang)問(wen)，或者被(bei)重復release，就會導致應用崩潰。設為nil后(hou)這個(ge)變(bian)(bian)量(liang)(liang)指向0×00，可以(yi)保證程序以(yi)后(hou)訪(fang)問(wen)不到原先的(de)內存地(di)址(zhi)，對nil進行release也(ye)沒任何問(wen)題。

使(shi)用(yong)類成員時，前面加不加self.有什(shen)么區(qu)別

不加self.調(diao)用的(de)是成員本身，加self.后(hou)實際(ji)上調(diao)用了(le)其成員的(de)get set方法。

例:

//.h

@property (nonatomic, retain) NSString *name

//.m

name = @"bang" //沒有retain，隨時(shi)會被(bei)釋放(fang)

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

self.name = @"bang" //等于[self setName:@"bang"]; 這(zhe)時在set方法(fa)里retain了這(zhe)個字(zi)符(fu)串

技巧篇

內存泄漏

可(ke)以通過xcode的(de)(de)編譯工(gong)具(ju)Product-Analyze檢查(cha)函(han)數塊(kuai)范圍內可(ke)能的(de)(de)泄漏點(外(wai)帶(dai)會提示一些可(ke)能有的(de)(de)錯(cuo)誤)。

用leaks工具監測出來(lai)的(de)泄漏查找方法(fa)是跟(gen)蹤其(qi)代碼(ma)提示中出現的(de)變(bian)量(liang)，經常這(zhe)個變(bian)量(liang)是在提示的(de)調(diao)用堆(dui)棧以外的(de)地方泄漏的(de)。若實在查不到，最終辦法(fa)是重寫(xie)這(zhe)個變(bian)量(liang)的(de)retain和release方法(fa)，debug，從調(diao)用堆(dui)棧看是誰(shui)retain了(le)它而沒有release。

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

數據存儲

如無搜索需(xu)要(yao)(yao)，可(ke)以將一個(ge)(ge)數(shu)據(ju)對象(xiang)直(zhi)接序(xu)(xu)列化后存(cun)到sqlite，取出時(shi)直(zhi)接反序(xu)(xu)列化為對象(xiang)使用。序(xu)(xu)列化需(xu)要(yao)(yao)數(shu)據(ju)類實現(xian)NSCoding協議，實現(xian)encodeWithCoder和initWithCoder兩(liang)個(ge)(ge)方法就行，若有(you)多個(ge)(ge)數(shu)據(ju)對象(xiang)，可(ke)以寫個(ge)(ge)基類實現(xian)這兩(liang)個(ge)(ge)方法，并在這里面利(li)用反射枚舉自身所有(you)變量(liang)去encode和decode，一勞永逸，具體實現(xian)網(wang)上找(zhao)找(zhao)就有(you)了(le)。

組件篇

UINavigationController頭尾(wei)顯示隱藏(zang)

在用(yong)NavigationController去管理view的(de)push和(he)pop時，需要(yao)根據不同的(de)view設置是否顯示NavigationBar和(he)ToolBar，一(yi)開始在錯誤的(de)地方設置了，導致有(you)時該顯示NavigationBar和(he)ToolBar時不顯示的(de)情(qing)況，后來發(fa)現在viewWillAppear上設置萬無一(yi)失。別笑我土鱉，沒好好去理解(jie)它整(zheng)個流程(cheng)，一(yi)直沒發(fa)現。

- (void) viewWillAppear:(BOOL)animated{

[super viewWillAppear:animated];

[self.navigationController setToolbarHidden:NO];

[self.navigationController setNavigationBarHidden:NO];

}

UITableView游標式渲染

tableView的(de)機(ji)制大概(gai)是(shi)：先(xian)定好(hao)總(zong)行(xing)數(shu)(shu)，某一(yi)行(xing)滾入視圖范圍時(shi)，回調(diao)一(yi)個函(han)數(shu)(shu)去取view出(chu)來(lai)顯示(shi)。這(zhe)一(yi)行(xing)滾出(chu)視圖再滾入時(shi)仍會繼續回調(diao)這(zhe)一(yi)函(han)數(shu)(shu)取view。有(you)這(zhe)樣的(de)機(ji)制就是(shi)說無論你table里的(de)數(shu)(shu)據(ju)有(you)多少，都可以全部放入table中不用分頁(ye)，因為不用一(yi)次性把(ba)所有(you)數(shu)(shu)據(ju)都取出(chu)來(lai)，只在需(xu)要顯示(shi)的(de)時(shi)候根據(ju)游(you)標(biao)去取對應的(de)數(shu)(shu)據(ju)就行(xing)了。

可能(neng)這(zhe)是(shi)APP組件很(hen)自(zi)然的(de)(de)(de)方式不用說(shuo)明(ming)，但在web上頁面(mian)上的(de)(de)(de)數據和元素(su)都(dou)是(shi)要一次性載入內存的(de)(de)(de)，做久了web，一開始沒(mei)想到它這(zhe)樣的(de)(de)(de)實現機制(zhi)，導致我們走了不少彎路。

UIWebView渲染(ran)范圍(wei)

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

曾嘗試webview嵌在(zai)tableview里，為(wei)(wei)了讓(rang)(rang)webview跟(gen)tableview一(yi)起滾(gun)(gun)動(dong)，把webview的(de)(de)(de)大(da)小(xiao)設為(wei)(wei)webview里的(de)(de)(de)內容大(da)小(xiao)，讓(rang)(rang)webview不(bu)(bu)出(chu)滾(gun)(gun)動(dong)條(tiao)，從而(er)能跟(gen)著tableview的(de)(de)(de)滾(gun)(gun)動(dong)條(tiao)一(yi)起滾(gun)(gun)。這(zhe)(zhe)樣做的(de)(de)(de)后果是(shi)(shi)每(mei)次webview都一(yi)次性(xing)渲(xuan)染整(zheng)(zheng)個(ge)頁面，內存占用(yong)多性(xing)能很差，而(er)且在(zai)放大(da)縮小(xiao)這(zhe)(zhe)個(ge)webview時，渲(xuan)染放大(da)的(de)(de)(de)整(zheng)(zheng)個(ge)頁面更吃(chi)力(li)，出(chu)現不(bu)(bu)能忍(ren)受的(de)(de)(de)性(xing)能。解決辦法(fa)是(shi)(shi)讓(rang)(rang)webview定住高(gao)度為(wei)(wei)一(yi)整(zheng)(zheng)屏(ping)iphone的(de)(de)(de)高(gao)度，限制了webview每(mei)次的(de)(de)(de)渲(xuan)染范(fan)圍(wei)為(wei)(wei)可視范(fan)圍(wei)，性(xing)能大(da)好。帶來的(de)(de)(de)問題(ti)是(shi)(shi)無法(fa)隨(sui)tableview滾(gun)(gun)動(dong)，但可以以其他方(fang)式(shi)優化(hua)體驗(yan)。最近看(kan)到新版的(de)(de)(de)ZAKER也是(shi)(shi)這(zhe)(zhe)樣做的(de)(de)(de)。

個人感覺篇

界面布局調(diao)整非常麻煩(fan)，讓人懷念web了。界面描述方法XIB感覺晦澀難(nan)學，至(zhi)今不(bu)會，沒(mei)有(you)CSS+HTML來得方便(bian)。

有編(bian)譯器把關(guan)，少了像寫(xie)js時多寫(xie)or寫(xie)錯一個字符(fu)查(cha)半天的(de)問題。

Object-C寫起來(lai)(lai)各種(zhong)變量函數和變量調用很長，沒有(you)js的(de)短小(xiao)精(jing)悍(han)來(lai)(lai)得爽(shuang)。

第一(yi)次編(bian)寫涉及手動內(nei)存管理(li)的(de)程序，挺(ting)有意思，沒想象中難，但有些(xie)內(nei)存管理(li)導致的(de)bug很(hen)難查(cha)。

雖(sui)然APP不像web那(nei)樣隨(sui)時更(geng)新，但也不像傳統PC客戶端升級(ji)那(nei)么麻煩，用戶更(geng)新意愿(yuan)更(geng)強，還是適合快速迭(die)代的。

細(xi)節是(shi)可(ke)以決定成敗(bai)，但(dan)得看你把什么(me)定成細(xi)節。

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