在項目中,很多邏輯請求都需要用到UIButton 做點擊事件進行相關跳轉或資料請求等。可以說是在項目中最常用的一種控制項,但是有些細節上的處理還是我們要多注意的,比如我們今天說的連續點擊UIButton導致資料請求多次的問題,或許這個問題網上已經有了很多相關資料,畢竟這個沒什麼難的。流傳的無非就是那幾個方法,第一種方法是通過使用runtime,設定UIButton0.5秒內不會被重複點擊,第二種是在每次點擊時先取消之前的操作,第三種是在點擊後設為不可被點擊的狀態,通過UIButton的enabled屬性來設定。
其實在我看來,我是比較中意第二種方法的,因為這樣不會影響到介面互動的一個流暢性問題,但是在某些情況下還是需要第三種方法去實現。至於第一種方法,聽起來可能是高端大氣上檔次,但是我表示“呵呵”,純粹是誤人子弟。如果我們在通過點擊UIButton的點擊事件做網路請求的時候,難道你就能夠保證在runtime的時間之內能夠收到網路請求的返回結果嗎。如果是在網路不好的情況下,很有可能導致你這個請求是發送的N遍,然後最後擷取到N中結果,如果你是通過addObjectsFromArray等方法添加資料的話,很有可能會導致添加資料重複的問題。
還有一種情況是比如我建立一個webSocket連結,然後需要通過點擊UIButton,切換向伺服器發送不同的資料請求,如果我用第一種方法的話就會導致不停地重複向伺服器發送資料請求,然後收到N多條同樣的資料,如果資料比較多的話直接會在你進行UI重新整理的時候造成卡頓現象。雖然中間可能間隔了你設定的runtime時間,但是仍然避免不了。至於第三種方法雖然能夠避免這個問題,但是會導致切換UI介面的不流暢的問題,因為你必須要等到收到伺服器返回的結果後才能夠點擊不同的UIButton來切換介面。這種情況下我們就要使用第二種方法。
但是在有些情況下,如果我必須等收到伺服器的返回結果才能夠響應某種事件的話就必須要用到第三種方法,如果用第二種方法的話,你會在連續不停地點擊UIButton事件的時候始終陷入一個迴圈,直到你手指離開螢幕才會響應,無疑會增加用戶端cpu的服務壓力。
至於什麼時候使用runtime 的來解決UIButton 的連續點擊造成的問題,我建議大家還是慎用。不要被千篇一律的重複部落格、文章所誤導。畢竟適合自己的才是最好的!