互聯網 - 大數據

簡易搜索功能小記

自從上個版本軟件中加入了列表的搜索功能，現在是個列表的地方產品都要給提供搜索。

@_@

類似聯系人、短信或者文件等的集合數據，用戶輸入關鍵字，然后根據標題或者內容文本去匹配。

搜索相關的問題：

• 發起搜索。
• 本地搜索。
• 請求服務器進行搜索。
• 同步搜索（單線程）。
• 異步搜索（多線程）。
• 結果分頁加載。

要點1：發起搜索

搜索功能第一步就是處理用戶輸入，然后發起搜索。
有兩種：

1、輸入內容后點擊搜索按鈕發起搜索
這種交互比較簡單，用戶主動點擊按鈕進行搜索，可以點擊返回進行取消，新的搜索請求自動取消之前的請求等。
2、輸入過程中自動發起搜索
類似網頁中常見的搜索功能，在輸入關鍵字過程中會即時顯示對應的搜索結果，無需等待輸入完畢后主動發起搜索。
這種情況下，本地搜索，或者網絡情況很好時體驗還不錯，但是，每次搜索都很耗時的話，輸入過程中的搜索很可能就沒有多少——建議了。
在監聽輸入框的變化時，可以避免短時間快速輸入時文本變動發起不必要的搜索——因為搜索結果用戶甚至來不及看，如果搜索是同步的話，那么結果的顯示就會阻塞輸入，或者快速輸入過程中用戶看到列表的閃爍。。。

所以，輸入過程中進行自動搜索，需要一個延遲進行搜索的效果。 代碼不復雜，但是算是一個輸入體驗的小細節：

//監聽EditText的變化，使用handler延遲400毫秒后對搜索邏輯進行發起
onTextChanged(...) {
    mTextChangeNum++;
    mSearchHandler.sendEmptyMessageDelayed(1, 400);
}

//
handleMessage(Message msg...) {
    mTextChangeNum--;
    if (mTextChangeNum == 0) {
        //說明截至目前，400毫秒內沒有新的文本的變化，發起搜索
        String keywords = mSearchBox.getText().toString().trim();
        doSearch(keywords);
    }
}

因為整個過程是在主線程中進行的，無需任何同步，通過handler進行延遲決定是否發起搜索，可以實現快速輸入時——兩次輸入字符間隔在400毫秒內——不搜索。

要點2：異步搜索

搜索比較耗時時，如網絡在線搜索，或者文件查找等，都是要考慮異步進行搜索邏輯的執行的。
如果搜索邏輯是同步執行的，那么每次發起搜索到顯示搜索邏輯是一個完整的過程——沒有打斷。搜索時間必須短——否則卡界面。

以網絡請求服務器搜索結果為例，從ui一致性的角度——搜索結果應該是用戶最后輸入的關鍵字對應的結果：
所以只有最好的網絡請求需要更新數據和ui，因為總是需要對最新的搜索進行響應，異步搜索的方案就是——每次新的請求發出，就取消上一個搜索請求。
Volley中的網絡請求抽象為兩種狀態：pending和flying。所以上一個搜索請求可能還未實際被發出，或者是在等待服務器響應中。無論哪種情況——舊的請求是一定被取消掉的。
類似Volley這樣的網絡框架提供了很好的api去取消已發出的網絡請求——這樣其結束處理也就自然消失了。其它情況下，自己通過一個主線程上標志的集合來維護各個異步請求的 “丟棄狀態” ，這樣，即使請求剛好返回了，那么繼續回到ui部分的 “結束代碼” 就可以根據狀態來立即停止。 瞬時操作，需要同步的狀態，保證其在ui線程被執行最好了。

OK，一句話就是異步請求時，只留最后一個請求即可——和ui保持一致。

要點3：分頁和ui切換

當數據量很大時，分頁是必須的。
不同于PC上的 “上一頁” “下一頁” 這樣去查看指定頁面，移動端更多是流行 “加載更多” 這樣的交互方式來 不斷加載新的內容。
下拉刷新去重新請求搜索，加載更多用來分頁顯示數據。

比較麻煩的就是頁面切換了——當然體驗要求是應該的： 加載中，網絡錯誤，服務器返回錯誤，無數據，正常返回一些結果——這些不同的情況下，分別用不同的視圖來展示給用戶。