技術不止钦幔，文章有料碎乃，加
JiuXinDev入群急黎，Android 搬磚路上不孤單
前言
在經(jīng)過前兩篇關于 Paging 文章的鋪墊以后，現(xiàn)在要和大家分享一下起點讀書是如何去應用 Paging 思想的蝶怔。
為什么是思想？
因為現(xiàn)階段的 Paging 2是穩(wěn)定版兄墅，但是它難用踢星，而Paging 3雖然比較好用，但我還是不敢將 Alpha 狀態(tài)的它用于我們的生產(chǎn)環(huán)境察迟，并且它和具體的業(yè)務結(jié)合起來仍有一些障礙斩狱。
一、背景
從我進入閱文以后扎瓶，一直進行起點讀書社區(qū)業(yè)務的迭代所踊，在瀏覽社區(qū)業(yè)務標桿 -- 微博的時候，我發(fā)現(xiàn)在瀏覽微博列表的時候概荷，很少會出現(xiàn)滑到數(shù)據(jù)底部秕岛，然后出現(xiàn) Loading 狀態(tài)的情況，這應該是對數(shù)據(jù)進行了預加載。
我們的App滑動到數(shù)據(jù)底部會出現(xiàn) Loading 狀態(tài)：
如果使用預加載方案继薛，用戶對滑動數(shù)據(jù)底部去發(fā)起網(wǎng)絡請求所帶來的等待無感知修壕，整個瀏覽過程也更加流暢，所以遏考，我打算將這項技術應用到我們的社區(qū)業(yè)務慈鸠。
二、方案選擇
Android Jetpack 中的 Paging 是具有對數(shù)據(jù)進行預加載功能的灌具，不過前面也提到了青团，無論是 Paging 2 還是 Paging 3 都有一定的痛點，我們具體分析一下咖楣。
Paging 2 的問題還是十分明顯的：
- API 是真的難用：需要根據(jù)不同的場景督笆，采用不同的數(shù)據(jù)源。
- 沒有狀態(tài)管理：意味著數(shù)據(jù)加載的時候诱贿，難以監(jiān)聽請求的狀態(tài)娃肿，更新對應的UI。
Paging 3 解決了上述的問題珠十，但是它仍然處于 Alpha 狀態(tài)料扰，這使得我不得不放棄它，并且宵睦，即使接入了记罚，也會有下面的問題：
-
RecyclerView的Adapter沖突：相信大家的業(yè)務都封裝了自己的Adapter，無論是采用繼承還是直接使用 Paing 3 中的PagingDataAdapter都比較困難壳嚎。 - 數(shù)據(jù)接口問題：定義接口的時候桐智，基本上很少出現(xiàn)只返回數(shù)據(jù)列表的情況，它還回返回一些其他信息烟馅，以我們業(yè)務為例说庭，返回帖子列表的時候，還會返回圈子的信息郑趁，圈子的信息如何帶回來刊驴？
基于以上的問題聘裁，我們造一了個輪子 QDPaging悼瘾。
三、框架結(jié)構
1. 基本功能
在造輪子之前迟隅，需要先理清業(yè)務的基本訴求梭纹，我們的出發(fā)點比較簡單躲惰，就是數(shù)據(jù)的預加載和狀態(tài)管理。
1.1 狀態(tài)管理
狀態(tài)管理是用來和UI打交道的变抽，QDPaing 直接借鑒了 Paging 3 的狀態(tài)結(jié)構础拨。
分別對應著：
-
Refresh：刷新場景 -
Append：加載更多 -
Prepend：向前加載數(shù)據(jù)
需要指出的氮块，我使用了兩種基礎的 Adapter，一種是可對數(shù)量容量限制的Adapter诡宗，另外一種無需限制滔蝉，無需限制的場景下是沒有 Prepend（向前加載） 的。
1.2 數(shù)據(jù)預加載
跟 Paging 3 不同的是塔沃，因為項目以及一些其他原因蝠引，QDPaging 數(shù)據(jù)加載沒有使用協(xié)程和 Flow，而是改用 Paging 2 中的線程池 + LiveData芳悲。
什么時候會觸發(fā)預加載呢立肘？
-
綁定數(shù)據(jù)的時候：因為在
Adapter中，每次我們需要綁定數(shù)據(jù)名扛，會調(diào)用它的getItem方法，滿足一定的條件后茧痒，就會啟動肮韧。 -
loadMore：我們的
RecyclerVIew都是封裝過的， 所以每次滑動到底部時旺订，都會觸發(fā)一個loadMore的方法弄企，這個時候也會觸發(fā)預加載。 - refresh：刷新數(shù)據(jù)的場景区拳。
整個加載流程是這樣的：
2. 其他功能
在基本的需求得到滿足之后拘领，我又加了一些其他的功能。
2.1 傳輸列表之外的數(shù)據(jù)
在列表頁定義接口的時候樱调，通常會夾帶一些額外的數(shù)據(jù)约素，這時，大家可能都會面臨這樣的抉擇笆凌，定一個接口還是兩個接口：
- 一個接口：將數(shù)據(jù)整合在一個接口圣猎。
- 兩個接口：列表數(shù)據(jù)走一個接口，其他信息走一個接口乞而，不過送悔，這加大了工作量，有可能會帶來兩次刷新爪模，這是視覺同學所不能忍受的欠啤。
最后往往都會選擇一個接口，不過這種方式對于之前談到的 Paging 庫來說屋灌，可能不太友好洁段，不過也有解決方式。
QDPaging 是如何解決這個問題的呢声滥？簡單來說眉撵，就是做一層數(shù)據(jù)封裝侦香，將數(shù)據(jù)包括起來，再存放一個類型為 Any 的成員變量纽疟，相當于 Java 中的 Object罐韩，當你實現(xiàn)自己的數(shù)據(jù)源的時候，就可以把其他的數(shù)據(jù)存在這個 Any 的成員變量中污朽，借助 LiveData 傳回來散吵。
2.2 數(shù)據(jù)容量限制
數(shù)據(jù)容量限制的目的是為了方便控制內(nèi)存。
為了控制數(shù)據(jù)容量蟆肆，QDPaging 使用了雙向鏈表矾睦，一頁數(shù)據(jù)就是一個節(jié)點，一個節(jié)點中記錄了當前的數(shù)據(jù)炎功、頁碼枚冗、前一個節(jié)點和后一個節(jié)點。
當數(shù)據(jù)容量超出閾值時蛇损，向后加載就拋出前面的節(jié)點赁温，向前加載則拋出后面的節(jié)點，最終實現(xiàn)數(shù)量上的控制淤齐。
2.3 減少代碼
在結(jié)合起點讀書固有Ui組件的基礎上 股囊，又增加了一些事件的自動處理：
- 刷新、加載更多等請求的自動發(fā)起更啄。
- 列表控件對于加載狀態(tài)（弱網(wǎng)稚疹、無網(wǎng)才會顯示）、刷新狀態(tài)和正常數(shù)據(jù)狀態(tài)的自動切換祭务。
- 錯誤處理内狗。
所以，在一些分頁的場景下待牵，我們現(xiàn)在只要實現(xiàn)一個數(shù)據(jù)源的類其屏，并告訴系統(tǒng)，下一頁和上一頁的頁碼分別是什么缨该，最后再綁定一下UI組件偎行，可能的話，還需要處理一下出列表數(shù)據(jù)外的場景贰拿。
總的來說蛤袒，還是可以減少一些平時必須要寫的代碼的。
四膨更、結(jié)果收益
我們稱滑動到數(shù)據(jù)尾造成的請求加載為有效的加載等待場景妙真，看一下優(yōu)化前后的效果（因為是gif，所以看著會比較卡）：
| 優(yōu)化前 | 優(yōu)化后 |
|---|---|
 改版前
|
 改版后
|
QDPaging 確實可以減少有效的等待加載場景荚守，結(jié)果也符合我的預期：
| 版本 | 人均有效的等待次數(shù)（次） |
|---|---|
| 7.9.76 | 4.485 |
| 7.9.78 | 0.015 |
下降了 99% 的有效等待加載場景珍德，當然练般，在弱網(wǎng)或者無網(wǎng)的情況下，預加載也無濟于事锈候。
除此以外薄料，我們這個預加載庫還能夠：
- 有效的減少邏輯代碼。
- 結(jié)合
Android Jetpack中的LiveData和Lifecycle泵琳，降低因組件生命周期帶來的crash摄职。 - 限制數(shù)據(jù)容量達到限制內(nèi)存的目的。
總結(jié)
雖然取得了我們想要的結(jié)果获列，但是接下來仍有很多工作要做：
- 分頁庫雖與起點 UI 組件的耦合性有點高谷市，需要抽離出來。
- 目前預加載功能只在起點讀書的發(fā)現(xiàn)頁的關注列表頁落地击孩，后續(xù)有更多頁面推廣迫悠。
Android Jetpack 作為谷歌推出的最新的 Android 快速開發(fā)工具集，有許多值得我們學習的地方巩梢。比如我們的預加載庫及皂，一大半的功能都是借鑒于 Android Jetpack 中的 Paging 庫，并且使用了 Android Jetpack 中的 LiveData 和 Liftcycle且改。
如果只使用 Android Jetpack 中的某一個庫可能會和其他相同作用的庫體驗沒什么不同，但是其中的幾個庫組合使用的話卻是大型真香現(xiàn)場板驳，起點在去年上半年進入敏捷開發(fā)的工作模式又跛，如果想要跑得更快，我們未來會引入更多的 Android Jetpack 組件若治。
廣告
如果覺得本文不錯慨蓝，三連 是對我創(chuàng)作最大的鼓勵～
我是九心，歡迎添加我
JiuXinDev端幼，進入我的學習群礼烈，與我一同進階。
