※ 引述《leondemon (狗狗)》之銘言： : 以上是簡化的一個流程 以上程式碼在搜尋時是可以work : 但是當鍵盤輸入過於快速時(大約超過每秒2個字母) 會發生以下問題： : Problem 1: : 當輸入過於快速時 發現到async的operation會一直卡在isExecuting的狀態 : 發現是卡在NSArray的-indexOfObjectPassingTest:裡面出不來 不知道為什麼 : 朋友說試著改用suffix tree來做搜尋 (不過我還沒研究...) : 目前字串搜尋速度效率我可以接受 只不過不知道為什麼會發生這種情況... Orz 我們不能夠確定 NSArray 的 indexOfObjectPassingTest: 裡頭 有沒有 lock，搞不好同時有兩個 thread 一起 enumerate 資料 會造成什麼東西被卡住。 我覺得可以先嘗試在建立一筆新的 async 搜尋的時候，先把前面 所有的 operation 先統統清掉在加入到 operation queue。 對 self.operationQueue 呼叫一下 cancelAllOperations 看看。 或是把 operation queue 允許的 operation 設成 1，一個 operation 做完才能做下一個。 : Problem 2: : 當輸入過於快速時 會發生UI整個卡住不能動的情況 : 把-scrollToRowAtIndexPath:atScrollPosition:animate:給comment out就不會卡住 : 原本推測是前一個scroll的animation還沒結束就實行下一個scroll造成 iOS 裡頭有動畫的元件，動畫都需要 0.25 秒的時間，如果這一個 動畫還沒做完就去呼叫另外一個動畫，往往會出問題，像是 navigation controller 還在 push 的時候就要求 pull，就會導致 整個 navigation 路徑亂掉。 一種作法是，我們可以把所有的 scroll 動作，再包成一個 operation 丟到另外一個 operation queue 裡頭，而不是直接丟到 main thread 做事。這個 operation queue 一次只允許一個 operation，裡頭每個 operation 在要求 main thread 更新 UI 之後，再 sleep 個 0.25 秒，或是跑個 0.25 秒的 runloop，確保所有的動畫都有足夠的時間。 不過這麼做，應該就會感覺 UI 的反應速度趕不上打字的速度。 -- zonble.net cocoa.zonble.net --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 36.229.55.22