一、簡述
經過了一個多星期的時間（自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。
