以前做前端開發的時候，使用最多的工具就是 Fiddler ，用來定位問題、模擬特定場景非常方便，極大提升了開發效率。而轉做 iOS 開發以後，一大頭疼的問題是 Fiddler 沒有 Mac 版，幸虧找到了 Charles Proxy 這個還不錯的替代工具，不過使用上與 Fiddler 還是有不少區別 ...
以前做前端開發的時候，使用最多的工具就是 Fiddler ，用來定位問題、模擬特定場景非常方便，極大提升了開發效率。
而轉做 iOS 開發以後，一大頭疼的問題是 Fiddler 沒有 Mac 版，幸虧找到了 Charles Proxy 這個還不錯的替代工具，不過使用上與 Fiddler 還是有不少區別
另外據我不完全的觀察，不少 iOS 開發工程師並不習慣於使用 HTTP 抓包工具……因此我覺得還是有必要寫一篇文章介紹下 Charles
試用 & 正版 & 破解
Charles 是收費軟體，可以免費試用 30 天。試用版本每次使用時間不能超過 30 分鐘，使用過程中不定時會中斷 5 秒鐘，並且啟動時將會有 10 秒種的延時。因此，該試用方案對廣大用戶還是相當友好的，只是當你需要長時間進行封包調試時，會因為 Charles 強制關閉而遇到影響。
如果手頭經濟寬裕，建議上官網購買正版。
除此之外，網上也有破解版，在 http://charles.iiilab.com/ 這個網站可以下載到Charels各個版本的破解版。
使用與配置
鑒於 Charles 的使用教程非常多，本文不打算寫成入門教程，而是針對常見的開發場景，介紹如何使用 Charles 提高開發效率
基礎的使用，可以參考 iOS開發工具——網路封包分析工具Charles
Charles 本質上是一個 HTTP 代理伺服器，因此需要在 iOS 設備上配置代理，不過這也意味著 Charles 只能抓取手機連接 WIFI 時的 HTTP 包，而 3G/4G 則不行
另外強烈建議使用之前先簡單瞭解一下 HTTP 協議，Charles 畢竟只是個工具而已
使用場景
快速定位 BUG 原因
App 開發中最常見的問題是，某個界面需要通過後端 HTTP 介面獲取數據並展示，而測試妹子給你提了個 BUG，告訴你這個界面沒數據或者數據有誤
初級工程師常犯的錯誤是：一開始就打斷點 Debug 或者一口咬定是後端問題，這常常會造成時間的浪費
正確的做法是先縮小 BUG 原因範圍，再準確定位，通常我會按照這樣的順序來診斷：
1. Charles 抓到相應的 HTTP 包了嗎？沒抓到請 debug App 代碼
2. 抓到的包 HTTP 響應正確嗎？
* 如果無響應，或者 HTTP status 是4xx/5xx/，責任果斷推給後端
* 響應是否符合介面文檔定義？完全不符合或者多了/少了JSON 欄位，責任果斷推給後端
* 響應符合定義，但是是報錯信息，那麼可能是 HTTP 請求不正確，對照請求與文檔定義，如果無誤，說明文檔有錯漏……責任依然推給後端
3. 以上都正確，那麼問題應該在 App 端，請開始 debug 代碼
記得拿著 Charles 的抓包結果截圖去找後端，這比 Xcode 控制台打出來的信息更容易說服他們
禁用響應緩存
關於查看響應的部分，有一點需要註意的是，現在不少後端服務都會開啟 Etag （不瞭解的請看維基百科）
而如果你使用了 AFNetworking ，那麼可能在 Charles 中看不到響應內容（304響應沒有 body）
解決方法是點擊菜單Tools → No caching，在界面中開啟全局或針對特定功能變數名稱的緩存禁用模式
快速構造請求中、請求失敗
通常 App 在發起請求時會有過渡效果（比如轉菊花⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄），在請求失敗時會有錯誤提示
不過在開發過程中由於同在一個區域網請求過程通常非常短，一般也不會失敗，那怎麼去調試這兩種界面呢？
一種方式是使用 OHHTTPStubs 這個庫通過 Mock 來構造響應，缺點是要寫代碼，另一種就是使用 Charles 了
先啟動 App 發起一次請求，然後在 Charles 中找到相應的請求，點擊右鍵勾選『Breakpoints』
這樣，下次 App 再發起同樣 URL 的請求時，Charles 會給你一個斷點界面，你可以選擇 Excute 或者 Abort
如果要調試請求失敗的界面，那就點 Abort，App 會進入 HTTP 請求失敗的處理流程
如果要調試請求中的界面，那就停在這個斷點界面即可，調試完了再點 Abort 或者 Excute
實際操作過程中會發現 Excute 需要點擊兩次才能完成一次 HTTP 請求，這是為什麼呢？請看下節
構造期望的響應數據
App 中常有一些界面會根據後端數據的不同而展現不同的樣式，那麼在開發過程中就期望後端介面能返回一些特定的數據。如果巴望著後端同學替你『造數據』那就不太現實了，可行的方式依然是上面提到的兩種，通過 OHHTTPStubs mock，或者使用 Charles
而 Charles 里要構造數據又有兩種方式
實時修改響應
前面提到需要點擊兩次 Excute 才能完成一次 HTTP 請求，原因是，Charles 的斷點功能分別提供了修改 HTTP Request 和 Response 的機會
在點擊第二次 Excute 之前，我們可以實時修改響應的內容，點擊『Edit Response』，然後選一種合適的展示面板修改即可，比如如果是 JSON 響應的話，推薦使用 JSON 面板
映射本地文件
另外一種方式就類似於 OHTTPStubs 了，可以將本地文件指定為特定 URL 的響應
首先依然需要先讓 Charles 抓取到相應的 HTTP 請求，然後在請求上點右鍵，選擇最下麵的『Map Local』
然後在彈出界面中選擇本地文件 
這種方式最大的用處是，當後端介面開發尚未完畢時，App 端可以『自給自足』地完成完整的界面流程。
另外 Charles 還提供了對已有 Map 規則的導入導出功能，這樣就可以將編好的整套規則共用給其他同事了，方法是點擊菜單 Tools → Map Local，在彈出界面中點擊 Export 
最後劇透下，我正在考慮如何通過工具將 Map Local 與後端開發流程連接，更高效地實現 App 開發，至於時間點嘛……哈哈
