Android開發中網絡代理設置實用總結

1、背景

進行Android項目開發時，跟網絡代理基本上每天都在打交道。一般狀況下，至少有三個場景中常常用到網絡代理：
1，常常經過Chrome訪問Google等國外的技術網站，如經過SS工具等；
2，AS（Android Studio）中須要下載國外的aar或jar包等資源；
3，手機抓包時，電腦上開啓Charles等抓包軟件，手機網絡鏈接電腦抓包軟件對應的代理。

不管是使用SS，仍是經過AS拉取資源，以及Charles抓包等，有時候咱們都會遇到一些「莫名其妙」的網絡問題。解決問題時，有時候可能莫名的又好了，有時候可能須要很久也無法解決。尤爲當這三個工具同時使用時。緣由在於對於網絡代理這塊總體流程沒有摸清，且他們之間有多是會相互影響的，這時候出現問題可能一籌莫展。

2、網絡代理流程

項目開發過程當中用到的瀏覽器也好，AS也罷，廣義範疇上都是屬於應用層軟件。軟件在實現的過程當中，依據實際的狀況，可能會對系統網絡代理進行判斷，若是有代理，走代理。甚至提供對外的設置項，例如AS、Chrome能夠針對網絡代理去進行單獨的配置。一旦配置，將依據具體狀況，結合軟件自身配置和系統網絡代理去走網絡。固然，也有些軟件，並無對系統網絡代理進行判斷，這種狀況下，無論系統網絡代理是如何設置的，也直接走默認的網絡過程。

同時，不一樣的網絡代理配置，對軟件的的影響也是不一樣的。例如，若是系統設置了FTP代理，則只可能對使用到FTP協議的相關軟件形成可能的影響，對只是使用HTTP協議的軟件是沒有影響的。可是，若是系統設置了TCP代理，此時，位於TCP協議上層的應用層使用到HTTP協議的軟件，也均可能形成影響。由於，HTTP層，最終仍是要經過TCP層去進行網絡傳輸的。

大致上，總的流程是這樣的。

操做系統對網絡代理設置了接口，代理軟件經過對應設置，能夠配置具體的網絡代理信息。其餘應用層的網絡請求，達到操做系統後，會依據具體的網絡代理設置，決定是否走網絡代理、以及具體如何走網絡的流程。

以SS（Shadow**Socks）爲例，本機安裝的SS，從對生效的其餘應用層軟件角度來講，屬於Server層，由於全部原生Client的請求，最終都將經過SS進行轉發。但另外一方面，從SS代理整體架構上來講，本機安裝的SS，只是屬於SS Clinet，由於對應的還有一個遠程的SS Server。原生Client的請求，經由本機SS Client轉發後，將達到指定的SS Server，SS Server拿到請求後，解封，獲得實際的請求信息，轉發給 Remote Server， 並將獲得的請求結果對應封裝後響應到SS Client，對應的，處理後回傳給原生Client應用。

所以，若是網絡代理設置後出現問題，整體的判斷流程是這樣的：
1，有無網絡代理軟件設置了網絡代理；
2，若有設置，具體的設置方式是怎樣的，針對的又是何種網絡協議設置；
3，網絡代理軟件設置後是否生效（能夠從系統偏好 >> 網絡 >> 高級 >> 代理去查看）；
4，其餘應用層軟件對網絡代理的支持（取決於其餘應用層軟件自身是否有單獨的網絡代理配置，以及網絡代理的協議層級）；
5，對其餘應用層軟件是否有預期中的影響效果。

這其中最關鍵的兩點是：具體的網絡代理設置及其餘應用層軟件對網絡代理的支持。

3、網絡代理實踐

不一樣的網絡代理軟件，有不一樣的設置方法。例如SS能夠設置PAC自動模式、白名單模式、全局模式等。PAC自動模式和白名單模式，針對更新下來的或配置的域名列表，去決定究竟是否經過SS去轉發原生的網絡請求。全局模式則直接Socket層代理，對上層Http訪問來講，都將生效。所以，若是設置的是全局模式，表現上將是不管是訪問多內網站仍是國外網站，都將經過SS去轉發網絡請求。但這裏有個地方是須要注意的，全局模式設置，實際上默認對應的是系統Http代理、Https代理和Sockes代理，若是瀏覽器自身有獨立的代理配置，例如配置成PAC的模式，那麼實際訪問網站過程當中，走的流程將是PAC模式，甚至瀏覽器若是忽視系統網絡代理，直接走直連模式，此時，網絡代理設置是無效的。

能夠實際測試下，系統開啓SS全局代理，咱們看下系統檢測到的代理設置結果：

其中，來自澳大利亞的IP代表SS Server訪問Remote Server的出口IP地址。

新開一個Chrom，經過SwitchyOmega選擇走系統代理，訪問ip檢測網站獲得的結果：

SwitchyOmega切換到PAC（須要對應配置好），結果顯示：

此時，若是咱們新打開AS，在Preference >> Http Proxy設置中，看到的結果是：

咱們發現，此時SS的全局模式對系統網絡代理的設置，對AS已經形成了影響（雖然AS自身此時並未設置代理）。例以下載內網下的aar資源等就會失敗。

若是SS模式有所更改，此時須要重啓AS，甚至殺掉java進程，才能看到上述警告消失（由於有緩存的存在）。

固然，Gradle也能夠針對單獨的項目或Gradle全局，經過在gradle.properties中配置的方式，設置網絡代理。 如常見的：

systemProp.http.proxyHost=127.0.0.1
systemProp.http.proxyPort=1087
systemProp.https.proxyHost=127.0.0.1
systemProp.https.proxyPort=1087
複製代碼

還有一個很是容易遇到的，可是被人忽略的點是，在開啓Charles抓包軟件時，默認狀況下是啓動系統代理，即Proxy >> macOS Proxy默認是勾選的。

此時，Charles至關於代理設置軟件，在啓動的時候自動設置了系統的Http及Https代理。此時，至關於本機上同時存在了多個網絡代理軟件，且同時進行了網絡代理配置，最終的結果，將是覆蓋的效果（後啓動的若是與先啓用的有針對同一個協議進行設置，之後啓用的爲準）。但無論怎樣，此時對AS每每也會形成影響，例如找不到證書，或者aar資源下載失敗等。

之前在AS開發項目時，正好遇到Charles抓包，致使的代理問題，費解了很長時間。

固然，Charles啓動時默認開啓系統代理是能夠取消掉的。具體路徑在Proxy >> Proxy Settings >> masOS下設置。

實際開發中，SS的設置對AS的影響通常都知道，但Charles抓包時默認開啓的系統代理比較隱蔽，每每會形成困擾。

不管何種代理軟件，設置何種模式的代理，設置同時啓用，最終的代理效果均可以在系統偏好 >> 網絡 >> 高級 >> 代理中去查看。但這過程當中使用的其餘應用層軟件，可能會形成一些莫名的困擾。此時，設置正確的網絡代理方式後，每每經過重啓軟件甚至刪掉對應的進程等方式能夠解決。

4、結語

不一樣的網絡代理軟件，能夠設置出不一樣的網絡代理效果，但整體上，網絡代理流程都是相似的（固然，Charles做爲網絡代理時，實際上並不存在Proxy Server，只是做爲中間人轉發了網絡請求）。

在本機存在多個代理軟件同時使用的狀況下，每每會對其餘應用層的軟件形成影響。此時，須要仔細梳理下最終網絡代理設置的結果，以及其餘軟件自身的代理配置，去綜合判斷並處理。

end~