結果發生了神奇的事
原本我說即使把 cell 內容填值這部份運算加快
即 cell.text = @"tt"; // 填固定值，所以運算極快了
也還是有嚴重的 lag
在我把程式分離出來後，竟然解決了
然後回頭再去調整原程式，本來無法加快的也加快了 Orz
我實在不知道當初怎麼調整的，會無論如何都調不出來
當初沒保留版本，現在死無對證
所以現在問題就變成要把運算及顯示拆開
在這邊還是想請問大家一個架構，在微軟的 Visual C++/MFC 下我寫得出來
但在 Object C 我寫不出來
－－－－－－－－－
假設我的運算時間長達兩秒，無法忍受
我可以用另一個 thread 來做，等做出來後再請 UI thread 顯示
而為了使 UI 的操作流暢，架構大概會是這樣
－ (void)UIClick
{
PostToThread(^{
//在另一個 thread 中運算，並儲存結果,時間長達兩秒
PostToUI(^{
//要求 UI 顯示，時間也要半秒
});
});
}
如上，UI 若顯示快就沒問題了，但偏偏 UI 也還是要花上半秒
上面的架構執行結果大概會是 UI 接受動作後，畫面在兩秒後更新
每一次 click 都會更新一次 UI
而我想要更流暢的，就是如果在兩秒運算中又有 UI Click 進來
那麼運算完（也可以中斷；這先不列入目標）後又會馬上重啟運算
直到 user 完全沒再有 UI 輸入，才真的去更新 UI
這有點像多次 SetNeedsDisplay 後，被合併起來只執行一次更新的感覺
因此我想要的是
user click -> calc value
user click -> calc value
user click -> calc value
//太久沒 click
update UI
但我實作的結果是
user click -> calc value -> update UI
user click -> calc value
user click -> calc value -> update UI
有加快，不流暢
我 click 的速度大約 0.3秒一次，而 update ui 一但開始就佔用 0.5秒
這使得整個動作忽快忽慢，完全稱不上流暢
若 calc 佔用兩秒，照理每 0.3 秒一次的 click 是夠早告知系統應該連續運算
不要進入 update UI 才對
用另一個 calc thread 不就是為了流暢嘛
我的問題在，我捨不得開一個 thread 一直檢查 status
假設我自己做 dirty 管理 （就像 setNeedsDisplay)
－ (void)UIClick
{
mDirty = true;
}
另一個 thread 只要監視 dirty 變數，一但 dirty 發生就去運算
－ （void)calcThread
{
while(!QuitThread) {
while ( mDirty == false ) //P1
;
mDirty = false;
//calc 兩秒
if ( mDirty = false ) {
//updateUI
}
}
}
如上，這個 thread 一直在 while loop 中等待
一但 mDirty 變成 true,就會計算,在計算的一開始我就先 reset dirty
所以如果計算過程中又發生 UI click, 那麼就又會被 set dirty
於是 update ui 就不會被執行
總之一定要整個運算都完成並且沒有新的 ui click, 才會去更新 ui
這邏輯可用，但問題是另一個 thread 在 P1 這點
實在不該用 while loop 一直檢查 mDirty 這個變數
這代表這個 thread 一直瓜分 cpu 時間
在微軟的 Visual C, 我會用 event, 配合同步指令
但在 Object C 中，我想用 ＠syncronize
卻寫不出來...