分析列表頁首先要看入口，因為乙個好的列表頁肯定是可復用的，入口的不同將導致列表的資料展示不同以及處理的不同。
做過不止一次從不同入口到同乙個列表頁，但展示卻是不同的，這裡可能是因為業務不同，可能是因為許可權不同，可能是因為歷史操作不同。那麼你的入口邏輯就要區分下了，區分不同的入口導致的差別，以及首次和非首次進入的區別。
列表進來了，我不想看，返回了我的入口頁面。這裡也有很重要的邏輯判斷。大部分人覺得返回不就是返回上乙個頁面麼。有時候的確可以如此考慮，但要看你的頁面流是什麼。
相信很多人知道頁面歷史記錄，在pc端你可以通過多入口很方便的進入到任何乙個可操作性的業務入口，但是手機端只能通過返回、關閉以及指定的主頁或者其他按鈕脫離本頁面。
也有些邏輯是借助於返回進行的，比如離開頁面的風險提示，讓你確認操作然後再離開。而有的返回只是當前頁某些展示的去掉。
雖然都是列表，但實際上有很多時候我們的列表資料卻可能是總量確定的，可能涉及到某個人某個業務的資料量的時候，就只有不到一屏，或者最多兩頁，那這種時候，其實全量列表對於使用者來說是最合適最友好的，而對於全量列表也就不存在載入更多或者沒有更多的情況了。
底部上拉是比較常規的互動方式，現在比較常用的是無限滾動載入直到沒有資料可載入。
這兩點是完全不同的頁面展示，而對於沒有資料在特定場景下都有特定的含義。
比如有些情況下，產品需要做一些指引，需要在沒有資料的時候引導使用者，你可以通過新建資料從而有資料，或者是因為你缺少某些操作、資質之類的原因導致你沒有資料可以看。
也有意外情況是因為你的弱網，斷網環境導致了你的沒有資料。還有一些異常情況也會導致，而針對異常情況是否做單獨說明也是需要和產品確認的點。比如伺服器閘道器報錯引起的或者程式設計師開小差了。
而沒有更多資料，其展示也越來越趨於簡單，正經的文案可能是寫，沒有更多資料了，調皮一點的會寫我是有底線的。
當沒有更多資料的時候，作為效能互動優化的角度，也需要在邏輯判斷上取消其請求資料的部分，甚至取消上拉本身的邏輯操作。
作為分頁的常規邏輯，需要清除的知道每次請求的準確頁數。我可以簡單分享下自己的邏輯，假設使用者是初始狀態進入的，那麼預設pageno是1，當觸發的時候去請求第二頁麼？不，不是這樣的。
實際上，當我們的當前的pageno == pagetotal的時候，已經不用請求了；
小於的時候，就需要請求，對應的載入動畫，請求介面，取消動畫。然後將頁數加1 之後，進行重新的判斷，如果發現此時，等於了就要下面顯示沒有更多資料；如果還是小於就可以仍然觸發其載入操作。
特別的是，需要大家注意當本來就只有一頁資料的時候，你就要顯示出沒有更多資料了。這種情況基本都會被忽略，因為一般情況下好像生產環境的列表資料不會這麼少，而導致測試或者開發測不到這種異常情況的。
就是我們常說的loading圖，很多互動會認為你不加這個就互動不好呢。我自己的觀點是看你介面的請求時間以及對應的操作內是否有資料可看。
具體例子說明下：比如上面提到的無限滾動載入，其實大多數時候，我們是看不到其無限滾動載入的觸發動畫的，因為其會定義在當你舉例底部還有50-100px的時候，就已經去請求資料了，其載入互動在你沒看到的底部位置，快的話1s-2s就把下面的資料請求並渲染好了，這樣反而是體驗好的。但如果你的設定是讓其閃現1s出現載入框然後消失那才尷尬呢。那麼，為什麼開始進來的時候需要載入動畫是**的loading呢，因為此時你沒有資料可看。
專案的滑動可以展示更多操作或者資訊。也有一些列表在切換型別的tab部分是通過滑動的，而也有列表是通過頁面滑動切換列表的。慢慢的這種切換列表的方式會變為主流。
很多時候會遇到列表的拖拽來調整順序，從而達到來調整你的優先順序或者喜歡程度等。
雙擊進行的操作會比較少，但慢慢的也會充當為手機手勢常用的一種。
目前的搜尋有很多種型別，有本地搜尋，有遠端搜尋。本地搜尋指的是以顯示的列表中進行關鍵字過濾，不用請求介面；而遠端搜尋則是根據關鍵字進行遠端搜尋。
隨著前端互動的增加，觸發條件也增加了很多，簡單分為以下幾種：
做的好的產品會針對之前搜尋過的結果進行搜素記錄提示，這個提示是個性化的，動態根據歷史記錄更新的。可以輸入部分後再提供的聯想搜尋結果中進行選擇從而搜尋。
這裡簡單講下搜尋與常規展示的邏輯處理，以搜尋頁和常規列表頁為乙個頁面考慮。
如果你的搜尋請求介面和常規列表介面是同乙個，一般情況下都是同乙個，當進行搜尋的時候，得到有效關鍵字之後，請求資料，需要將頁數重置為1，需要提供關鍵字， 得到搜尋結果之後，需要判斷其是否有資料，其展示的沒有資料和常規列表的沒有資料提示是不一樣的，不一樣在你需要告訴使用者：1 搜尋的關鍵字是什麼 2 是搜尋無結果，區別於常規的無結果。
而當你將關鍵字去掉，切換為常規列表的時候，需要把關鍵字去空，頁數也重置為1 。這裡也延伸的拓展下，如果你還涉及到多個tab列表的切換，那麼你的tab可能就是對應到不同的type值的傳參，這部分也需要根據對應的部分進行重置。甚至於你可能需要同時進行幾種狀態的記憶管理，這是很常見的需求。
列表中的現在都要支援一定的懶載入，在雲**的處理中都是開始是預設圖，然後是實際縮圖代替。
1 縮圖的列表佔比，主要作用 2 縮圖一般不是原圖，但有一定的轉換關係。在阿里的圖床中會根據你穿的提供至少3中規格的正方形縮圖讓你進行選擇規格。 3 顯示的內容，一般情況下都是原圖內容的100%展現，但如果原圖寬比不符合縮圖的長寬比，很常見的把，那麼就會把原圖中間的百分之多少截圖作為縮圖展示的部分。 4 控制原圖的比例，當然更多時候為了保證產品的統一，可能會控制原圖的比例。但如果業務本身是控制不了的，或者本來就不希望控制，也不用控制的。
其核心體驗是：先出輪廓，再詳細渲染。
其實這裡僅僅列舉了乙個手機列表頁的部分邏輯，還沒有列舉完整，到這裡你還覺得做乙個列表是很簡單的事情麼，其實如果從沒有很成熟的經驗開始做的話，也沒有那麼容易，需要考慮比較多的事情吧，畢竟列表頁是承載很多業務展現形式的載體。
如果你覺得本文還不錯，加個喜歡，沒有主講**技術，但滿滿的前端邏輯。
說一說 r與 n
今天在用python讀取txt檔案的時候，遇到了乙個比較坑的問題，那就是 n 和 r 究竟有什麼區別？在計算機還沒有出現之前，人們設計了一種機器叫做電傳打字機，這種機器每秒鐘可以打10個字元。不過它有個問題，就是打完一行換行的時候，需要0.2s，正好可以列印兩個字元，如果這個時候有新的字元傳過來，那...
簡單的說一說mmap
mmap memory map，就是記憶體對映 簡單的說就是將檔案對映到使用者的位址空間中。這麼做有什麼好處呢？1.傳統檔案訪問方式是,首先用open系統呼叫開啟檔案,然後使用read,write等呼叫進行順序或者隨即的i o.這種方式是非常低效的,每一次i o操作都需要一次系統呼叫.而通過mmap...
說一說JS的IIFE
iife immediately invoked function expression，意為立即呼叫的函式表示式，也就是說，宣告函式的同時立即呼叫這個函式。對比一下，這是不採用iife時的函式宣告和函式呼叫 function foo foo 下面是iife形式的函式呼叫 functionfoo 函...