前言
相信隨著前端職業的興起，有不少後端或者專案經理覺得前端不就那麼回事麼？甚至於有些時候，後端一看這麼個簡單的東西也要做一天？那麼本文就帶大家瞭解一下一個還算正常的手機列表頁需要那些工作量。
入口
分析列表頁首先要看入口，因為一個好的列表頁肯定是可複用的，入口的不同將導致列表的資料展示不同以及處理的不同。
做過不止一次從不同入口到同一個列表頁，但展示卻是不同的，這裡可能是因為業務不同，可能是因為許可權不同，可能是因為歷史操作不同。那麼你的入口邏輯就要區分下了，區分不同的入口導致的差別，以及首次和非首次進入的區別。
也有一種特殊處理，就是當是列表頁進入詳情再返回列表的時候，需要記憶上一步列表的狀態。對於app是很簡單的事情也許，但對於前端就需要記錄比較多的關鍵點了。可能包括：使用者的過濾選擇，關鍵字，請求到的分頁資訊，請求到的快取資料，滾動到的位置。對，很明確行業是有明確的方案的，但注意我這裡是說的工作量，有這部分需求就需要去實現，去細化，以及測試的。
返回
列表進來了，我不想看，返回了我的入口頁面。這裡也有很重要的邏輯判斷。大部分人覺得返回不就是返回上一個頁面麼。有時候的確可以如此考慮，但要看你的頁面流是什麼。
相信很多人知道頁面歷史記錄，在pc端你可以通過多入口很方便的進入到任何一個可操作性的業務入口，但是手機端只能通過返回、關閉以及指定的主頁或者其他按鈕脫離本頁面。
曾經深度研究過網易雲音樂app的播放頁。它可以是很多頁面點選進來的，每種不同渠道的進入，在音樂播放頁返回都要返回指定的頁而不是簡單的歷史記錄頁。所以不要簡單的認為手機端的返回就和瀏覽器的返回前進是一樣的。當你的應用需要的時候，這個返回邏輯可以包含不同的業務判斷。
也有些邏輯是藉助於返回進行的，比如離開頁面的風險提示，讓你確認操作然後再離開。而有的返回只是當前頁某些展示的去掉。
常規列表支援的互動
全量列表 && 分頁列表
雖然都是列表，但實際上有很多時候我們的列表資料卻可能是總量確定的，可能涉及到某個人某個業務的資料量的時候，就只有不到一屏，或者最多兩頁，那這種時候，其實全量列表對於使用者來說是最合適最友好的，而對於全量列表也就不存在載入更多或者沒有更多的情況了。
底部上拉載入 && 無限滾動載入
底部上拉是比較常規的互動方式，現在比較常用的是無限滾動載入直到沒有資料可載入。
下拉重新整理 && 頂部雙擊重新整理
下拉重新整理是比較常規的互動方式，不過已經越來越少用了。現在更多的是頂部雙擊可以同時達到快速回到頂部並且重新整理的作用，對微信朋友圈的互動就是這樣的。
沒有資料 && 沒有更多資料
這兩點是完全不同的頁面展示，而對於沒有資料在特定場景下都有特定的含義。
比如有些情況下，產品需要做一些指引，需要在沒有資料的時候引導使用者，你可以通過新建資料從而有資料，或者是因為你缺少某些操作、資質之類的原因導致你沒有資料可以看。
也有意外情況是因為你的弱網，斷網環境導致了你的沒有資料。還有一些異常情況也會導致，而針對異常情況是否做單獨說明也是需要和產品確認的點。比如伺服器閘道器報錯引起的或者程式設計師開小差了。
而沒有更多資料，其展示也越來越趨於簡單，正經的文案可能是寫，沒有更多資料了，調皮一點的會寫我是有底線的。
當沒有更多資料的時候，作為效能互動優化的角度，也需要在邏輯判斷上取消其請求資料的部分，甚至取消上拉本身的邏輯操作。
分頁的頁數
作為分頁的常規邏輯，需要清除的知道每次請求的準確頁數。我可以簡單分享下自己的邏輯，假設使用者是初始狀態進入的，那麼預設pageNo是1，當觸發的時候去請求第二頁麼？不，不是這樣的。
在你請求有資料拿到第一頁的時候，其實你就知道總條數以及總頁數了。所以在每一次資料請求之前，就可以通過比較pageNo與pageTotal的關係來決定載入觸發操作的時候是否有必要請求下一頁的資料，其是否還有下一頁。
實際上，當我們的當前的pageNo == pageTotal的時候，已經不用請求了；
小於的時候，就需要請求，對應的載入動畫，請求介面，取消動畫。然後將頁數加1 之後，進行重新的判斷，如果發現此時，等於了就要下面顯示沒有更多資料；如果還是小於就可以仍然觸發其載入操作。
特別的是，需要大家注意當本來就只有一頁資料的時候，你就要顯示出沒有更多資料了。這種情況基本都會被忽略，因為一般情況下好像生產環境的列表資料不會這麼少，而導致測試或者開發測不到這種異常情況的。
載入動畫
就是我們常說的loading圖，很多互動會認為你不加這個就互動不好呢。我自己的觀點是看你介面的請求時間以及對應的操作內是否有資料可看。
具體例子說明下：比如上面提到的無限滾動載入，其實大多數時候，我們是看不到其無限滾動載入的觸發動畫的，因為其會定義在當你舉例底部還有50-100px的時候，就已經去請求資料了，其載入互動在你沒看到的底部位置，快的話1s-2s就把下面的資料請求並渲染好了，這樣反而是體驗好的。但如果你的設定是讓其閃現1s出現載入框然後消失那才尷尬呢。那麼，為什麼開始進來的時候需要載入動畫是中央的loading呢，因為此時你沒有資料可看。
類似的例子還出現在列表項上支援的某些操作，當你點選請求伺服器進行功能的時候，其實你關注點是功能的執行結果，而不是繼續看資料，也不想丟失這部分的操作，而在產品設計的角度，也會盡量減少此時其他的不必要操作，所以才會有這樣一個互動，告知使用者我在處理你的請求裡，請稍等。一則是友好，二則避免使用者重複點選，造成伺服器不必要的負擔，以及一些後端邏輯處理上多高併發的問題瓶頸，還有就是多請求多返回的衝突提示。
列表項騷操作
左滑 && 右滑
專案的滑動可以展示更多操作或者資訊。也有一些列表在切換型別的tab部分是通過滑動的，而也有列表是通過頁面滑動切換列表的。慢慢的這種切換列表的方式會變為主流。
拖拽
很多時候會遇到列表的拖拽來調整順序，從而達到來調整你的優先順序或者喜歡程度等。
雙擊
雙擊進行的操作會比較少，但慢慢的也會充當為手機手勢常用的一種。
搜尋功能
搜尋範圍
目前的搜尋有很多種型別，有本地搜尋，有遠端搜尋。本地搜尋指的是以顯示的列表中進行關鍵字過濾，不用請求介面；而遠端搜尋則是根據關鍵字進行遠端搜尋。
搜尋觸發條件
隨著前端互動的增加，觸發條件也增加了很多，簡單分為以下幾種：
- 動態搜尋，每當輸入發生變化的時候
- 離開焦點的時候
- 輸入法回車的時候
- 點選其後面的搜尋按鈕
- 搜尋圖示
搜尋幫助
做的好的產品會針對之前搜尋過的結果進行搜素記錄提示，這個提示是個性化的，動態根據歷史記錄更新的。可以輸入部分後再提供的聯想搜尋結果中進行選擇從而搜尋。
搜尋與常規展示矛盾點
這裡簡單講下搜尋與常規展示的邏輯處理，以搜尋頁和常規列表頁為一個頁面考慮。
搜尋列表與常規列表關係
如果你的搜尋請求介面和常規列表介面是同一個，一般情況下都是同一個，當進行搜尋的時候，得到有效關鍵字之後，請求資料，需要將頁數重置為1，需要提供關鍵字， 得到搜尋結果之後，需要判斷其是否有資料，其展示的沒有資料和常規列表的沒有資料提示是不一樣的，不一樣在你需要告訴使用者：1 搜尋的關鍵字是什麼 2 是搜尋無結果，區別於常規的無結果。
而當你將關鍵字去掉，切換為常規列表的時候，需要把關鍵字去空，頁數也重置為1 。這裡也延伸的擴充下，如果你還涉及到多個tab列表的切換，那麼你的tab可能就是對應到不同的type值的傳參，這部分也需要根據對應的部分進行重置。甚至於你可能需要同時進行幾種狀態的記憶管理，這是很常見的需求。
搜尋列表是否和常規列表作為同一個頁面
對於這種互動是打問號的，自從有第一個產品在搜尋框點選開啟新頁面之後，搜尋頁單獨開啟頁面就變成了app互動的一種不成文的習慣。
列表中的懶載入
小談圖片
列表中的圖片現在都要支援一定的懶載入，在雲音樂的處理中都是開始是預設圖，然後是實際縮圖代替。
縮圖規則，一般都是按照比例排版的縮圖。不知道大家有沒有研究過微信的縮圖，它可不是簡單的把原圖尺寸用那麼小的尺寸顯示那樣簡單。縮圖涉及到的點這裡稍微列舉下：
1 縮圖的列表佔比，主要作用 2 縮圖一般不是原圖，但有一定的轉換關係。在阿里的圖床中會根據你穿的圖片提供至少3中規格的正方形縮圖讓你進行選擇規格。 3 顯示的內容，一般情況下都是原圖內容的100%展現，但如果原圖寬比不符合縮圖的長寬比，很常見的把，那麼就會把原圖中間的百分之多少截圖作為縮圖展示的部分。 4 控制原圖的比例，當然更多時候為了保證產品的統一，可能會控制原圖的比例。但如果業務本身是控制不了的，或者本來就不希望控制，也不用控制的。
小談骨架屏
第一次感受到骨架屏是簡書的使用者體驗，初次感覺沒特別的，再反過來對比的時候，發現這樣的體驗好很多。相信骨架屏會是頁面懶載入技術之後，前端體驗優化又一個必備必現的技術點。
其核心體驗是：先出輪廓，再詳細渲染。
總結
其實這裡僅僅列舉了一個手機列表頁的部分邏輯，還沒有列舉完整，到這裡你還覺得做一個列表是很簡單的事情麼，其實如果從沒有很成熟的經驗開始做的話，也沒有那麼容易，需要考慮比較多的事情吧，畢竟列表頁是承載很多業務展現形式的載體。
如果你覺得本文還不錯，加個喜歡，沒有主講程式碼技術，但滿滿的前端邏輯。