專案經驗，如需轉載，請註明作者：Yuloran (t.cn/EGU6c76)
前言
這個 bug 本不應該定位這麼久，只是最近狀態實在是太差了，無論是心理上還是身體上，都感覺非常的疲憊。
Bug 現象
使用 RxDownload2 下載檔案時，要等很久(平均6s以上)，才開始重新整理進度。
定位分析
從理論上看，使用 @Streaming 的方式下載檔案，在與伺服器建立連線後應當立即返回，只有從輸入流開始讀資料時才會阻塞。但是，現在下載進度重新整理需要等待這麼久，看起來像是已經下完了才開始重新整理。從 okhttp 的日誌看，這段時間確實是發起 GET請求 到 End Http 的時間，那麼這期間肯定出了什麼問題。okhttp 框架應該不會有問題，那隻能是我們的攔截器有問題，如果攔截器中呼叫了讀取資料的方法，就會導致阻塞。
Bug 原因
嗯，加解密攔截器、日誌攔截器中都呼叫了 response.body() 方法，所以導致了阻塞。
Bug 修復
分析業務，下載檔案時無需對報文進行加解密，所以刪掉即可。同時重寫一個針對下載的日誌攔截器，不呼叫 response.body() 方法，就解決了。
其它
哈哈，定位這個問題哪有上面說的這麼簡單，專案原因就不多說了。
附
RxDownload2 系列文章：