iOS 開發日誌：memory leak at navigation pushing control

一直覺得 XCode 提供的 Instrument tool 很方便，習慣都會在 milestone build 做個 memory leak 檢查。

昨天卻發生了 memory leak 在 UIKit 裡面的現象

        IssueViewController *nextController = [[IssueViewController alloc] init];
        [self.navigationController pushViewController:nextController animated:YES];
        [self.navigationController setNavigationBarHidden:YES animated:YES];
        [nextController release];

Code 很標準，但是 Instrument 卻回報在 pushViewController 發生了 memory leak，不管在 simulator 或是實機都一樣。

翻翻 Google，看到很多人有過這種經驗，但是並沒有一致的原因，多半還都是沒有 solution。

在使用 Heap spot 也看不出問題的情形下，只好用最笨的隔離法測試，結果終於找到問題點了！

問題出在 pushViewController 的下一行

        [self.navigationController setNavigationBarHidden:YES animated:YES];

原來在 push 後若是再對自己的 navigationController 動作，對導致 reference count 的增加，變成 memory leak...

移掉這行就 ok 了。

這情形不好抓，只好寫篇記錄～

iOS programming journal: Holy grail of tableview image handling

花了好幾天時間，嘗試各種方式企圖提昇帶有 imageView 的 tableview scrolling performance

Google 搜尋後看到幾個 tip
- prepare image in background。這我本來就這樣做了，但是仍然會頓
- 自己畫 tableviewcell。我也試了，沒用～
- 自己寫 tableviewcell 的 drawRect，不要讓 Cocoa 做一堆 subview render/layout。這我不想試，不信一定要這麼麻煩...

終於在昨天讓我看見了這篇的 Apple sample
http://developer.apple.com/library/ios/#samplecode/LazyTableImages/Introduction/Intro.html

原來真正的重點在

- 當 tableview 在 dragging、decelerating 時，不要去做花時間的動作，譬如 resize image，或是設定很長的 UILabel
- 等 tableview scrolling 停止後，再把畫面上少的東西用準備好，必要時用 background thread（要實作 UIScrollViewDelegate）

總算搞定，現在滑得可順了～～

爸！我跟你說一個密碼

「爸！我跟你說喔～」剛洗好澡的晶晶跑過來找我

「我的耳朵有密碼，你說錯密碼它就會關起來！」

...


「103，快去睡覺。」我指著晶晶

晶：「錯！」

「咦？你不是跟我說密碼是 103 嗎？」我剛其實沒很仔細聽

晶：「不是～密碼是：『嘛嘛咪嘛嘛』」

= =