一、簡述
經過了一個多星期的時間（自2017/10/16開始），到目前（2017/10/24）為止，專案框架的搭建已基本完成、還完成了首頁中「直播」與「推薦」Fragment的資料填充，可以說相仿度很高，說這麼多不如先看看效果。
很6吧，但這不是重點，本篇要記錄的，是使用fiddler來抓取app客戶端的資料（包括http和https的資料抓取），並記錄下對介面與資料的分析結果，下面就直入主題吧。
二、使用Fiddler抓http包
1、Fiddler設定
要使用Fiddler來給手機app抓包，需要進行一次設定。
通過Tools->Fiddler Options進入設定介面：
切換到Connections標籤，填寫要監聽的埠（如：8888），將下方3個鉤勾上，最後點選OK關閉設定介面。
2、手機設定
開啟設定，找到WLAN，長按當前連線的wifi，設定代理主機與埠。
- 要注意，你的手機必須和執行Fiddler的電腦在同個區域網內。
- 不同的手機設定介面有所不同，這裡以模擬器為例，其他手機請參考後自己在對應位置進行設定。
3、開始抓包
經過上面的2步設定後，下面就可以來抓包了。
此時如果在Fiddler中有太多請求記錄，不方便我們檢視接下來要抓的資料，可以進行如下操作將這些記錄清除。
仔細看，當我從「推薦」切換到「直播」時，app發起來資料請求，同時Fiddler中捕獲到了12條資料。這其中，只有帶有Json圖示的記錄是我們要的（即序號為3，4，5的資料）。
分別點選這3條json資料請求記錄，發現序號5的請求是我們想要的
Fiddler自帶的json檢視視窗可以很方便的幫我們理清返回的資料結構，但可惜的是，它提供的可操作性實在是太弱了，連複製都不行，所以這個視窗的作用也就是讓我們方便的檢視下抓取到的資料請求是不是我們想要的而已了。
4、使用HiJson代替Fiddler自帶的json檢視視窗
很多時候，我都會使用HiJson來幫助我完成對介面返回資料的分析，我相信大多數安卓開發者對該工具應該不會陌生。不過，HiJson不支援直接資料請求，所以需要從別處將json資料複製到HiJson中，Fiddler的WebView視窗可以幫到我們。
將WebView視窗中的資料全選，右鍵，複製。開啟HiJson，貼上到左視窗後點選“格式化JSON字串”。
好了，http的資料包抓取就到這了，不難，下面來看看https的抓包流程。
三、使用fiddler抓https包
參考上面http的抓包配置，確定配置無誤後，開始抓一次「推薦」版塊的包看看。
有沒有發現什麼問題？在Fiddler中沒找不到帶有Json圖示的請求記錄，但有2個帶鎖的請求，而且Host顯示”Tunnel To”，這就說明「推薦」版塊採用的是https請求，這種加密請求，沒辦法這樣直接檢視，還需要進行以下配置。
1、Fiddler設定
開啟Fiddler設定介面，切換到HTTPS標籤，將”Capture HTTPS CONNECTs”、”Decrypt HTTPS traffic”、”Ignore server certificate errors(unsafe)”都勾上，將中間的下拉選單選擇為”from all processes”，最後點選OK關閉設定介面。
2、手機設定
開啟手機瀏覽器，輸入執行Fiddler的主機ip與監聽的埠，可以開啟一個Fiddler的證照下載頁面。
點選最後一行的”FiddlerRoot certificate”下載並安裝證照。
最後，重啟Fiddler。
可能在安裝證照的時候會要求你為手機設定鎖屏密碼，隨便設定一個你能記住的密碼就好了，如Pin碼：1234。
3、開始抓包
經過上面的配置後，下面就可以來抓https的包了。
重複之前的操作，在「推薦」版塊中重新整理一下看看（留意下Protocol列）。
這次抓取到了2條https記錄，一眼就看出來了，序號1那條就是我們想要的（帶著json圖示）。
下面我們來驗證下，這是不是就是重新整理時伺服器返回的json資料呢？
沒錯，就是伺服器返回的json資料。
要注意，現在的多數app都會有資料快取功能，如果你在使用Fiddler抓包的過程中遇到app在啟動載入資料時，捕獲不到你想要看到的資料請求記錄，那很有可能就是app使用了之前的資料快取，你要做的就是到系統的設定中，找到應用管理列表中對應的app，然後手動清空app的快取資料即可。
到這裡，使用Fiddler抓取app的http、https資料包的過程及注意事項就都說完了。接下來就記錄下我對bilibili首頁的「推薦」版塊資料的分析吧。
四、介面與資料分析
1、介面
對比了幾個不同時機的介面資料（開啟app時，下拉重新整理時，上拉載入更多時），我發現！！！
url中的幾個關鍵引數作用分別如下：
- idx：第一次載入資料時為0（此時，open_event=cold），若是載入更多，則是之前資料中的最後一個idx，或是重新整理，則是之前資料中一開始的idx。
- pull：重新整理為true，載入更多為false。
- login_event：為1時會載入banner，為0時則不載入banner(細節有待考究)
- 其他引數，親測不用也無所謂~
2、資料
這部分圖片過多，可能看官大爺沒什麼耐心看，文章的最後有附上該介面的實現程式碼連結，可直接拉到最後檢視。
通過仔細觀查的bilibili手機APP的介面設計，並分析對應返回的資料的結構，我又發現！！！
安卓開發者一眼就能看出來，這個「推薦」版塊絕對是採用多佈局列表設計，那這個列表到底有多少佈局呢，答案是至少有12種（根據資料的goto欄位區分）。就我找出的這12種佈局大致可分為2大類：「大布局」和「小布局」。
1）「大布局」
大布局包括的goto值有：banner、coverge、special、topic、rank、tag。
2）「小布局」
小布局包括的goto值有：av、av(帶有rcmd_reason)、bangumi、login、ad_web_s、article_s。
