iOS開發初學者記錄

來源：Bang

做完了專案，想總結下，不知怎麼寫合適，只列出一些iOS開發的基礎點，開發前因為不知道這些點，導致走了一些彎路，希望對初學者有幫助。

基礎篇

為什麼對一個變數release後還要設為nil

對一個變數release後，這個變數指向的記憶體釋放了，但這個變數本身沒變，仍指向原來的記憶體地址。若這個變數在釋放後被訪問，或者被重複release，就會導致應用崩潰。設為nil後這個變數指向0×00，可以保證程式以後訪問不到原先的記憶體地址，對nil進行release也沒任何問題。

使用類成員時，前面加不加self.有什麼區別

不加self.呼叫的是成員本身，加self.後實際上呼叫了其成員的get set方法。
例:

技巧篇

記憶體洩漏

可以通過xcode的編譯工具Product-Analyze檢查函式塊範圍內可能的洩漏點（外帶會提示一些可能有的錯誤）。

用leaks工具監測出來的洩漏查詢方法是跟蹤其程式碼提示中出現的變數，經常這個變數是在提示的呼叫堆疊以外的地方洩漏的。若實在查不到，最終辦法是重寫這個變數的retain和release方法，debug，從呼叫堆疊看是誰retain了它而沒有release。

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

資料儲存

如無搜尋需要，可以將一個資料物件直接序列化後存到sqlite，取出時直接反序列化為物件使用。序列化需要資料類實現NSCoding協議，實現encodeWithCoder和initWithCoder兩個方法就行，若有多個資料物件，可以寫個基類實現這兩個方法，並在這裡面利用反射列舉自身所有變數去encode和decode，一勞永逸，具體實現網上找找就有了。

元件篇

UINavigationController頭尾顯示隱藏

在用NavigationController去管理view的push和pop時，需要根據不同的view設定是否顯示NavigationBar和ToolBar，一開始在錯誤的地方設定了，導致有時該顯示NavigationBar和ToolBar時不顯示的情況，後來發現在viewWillAppear上設定萬無一失。別笑我土鱉，沒好好去理解它整個流程，一直沒發現。

UITableView遊標式渲染

tableView的機制大概是：先定好總行數，某一行滾入檢視範圍時，回撥一個函式去取view出來顯示。這一行滾出檢視再滾入時仍會繼續回撥這一函式取view。有這樣的機制就是說無論你table裡的資料有多少，都可以全部放入table中不用分頁，因為不用一次性把所有資料都取出來，只在需要顯示的時候根據遊標去取對應的資料就行了。

可能這是APP元件很自然的方式不用說明，但在web上頁面上的資料和元素都是要一次性載入記憶體的，做久了web，一開始沒想到它這樣的實現機制，導致我們走了不少彎路。

UIWebView渲染範圍

UIWebView不是根據可視範圍決定每次的渲染範圍，而是根據自身控制元件的frame大小決定。

曾嘗試webview嵌在tableview裡，為了讓webview跟tableview一起滾動，把webview的大小設為webview裡的內容大小，讓webview不出滾動條，從而能跟著tableview的滾動條一起滾。這樣做的後果是每次webview都一次性渲染整個頁面，記憶體佔用多效能很差，而且在放大縮小這個webview時，渲染放大的整個頁面更吃力，出現不能忍受的效能。解決辦法是讓webview定住高度為一整屏iphone的高度，限制了webview每次的渲染範圍為可視範圍，效能大好。帶來的問題是無法隨tableview滾動，但可以以其他方式優化體驗。最近看到新版的ZAKER也是這樣做的。

個人感覺篇

介面佈局調整非常麻煩，讓人懷念web了。介面描述方法XIB感覺晦澀難學，至今不會，沒有CSS+HTML來得方便。

有編譯器把關，少了像寫js時多寫or寫錯一個字元查半天的問題。

Object-C寫起來各種變數函式和變數呼叫很長，沒有js的短小精悍來得爽。

第一次編寫涉及手動記憶體管理的程式，挺有意思，沒想象中難，但有些記憶體管理導致的bug很難查。

雖然APP不像web那樣隨時更新，但也不像傳統PC客戶端升級那麼麻煩，使用者更新意願更強，還是適合快速迭代的。

細節是可以決定成敗，但得看你把什麼定成細節。

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