一、简述
经过了一个多星期的时间（自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。
最后附上该界面的主要实现代码
- RecommendFragment.java
- RecommendMultiItem.java
- RecommendMultiItemAdapter.java
- RecommendPresenter.java
