Android 高版本 HTTPS 抓包解決方案！（建議收藏）
微信改了推動(dòng)機(jī)制，真愛(ài)請(qǐng)星標(biāo)本公號(hào) 公眾號(hào)回復(fù)加入BATcoder技術(shù)群 BAT
MegatronKing | 作者
承香墨影 | 校對(duì)
https://juejin.cn/post/6844903831579394055 | 原文
HTTP 協(xié)議發(fā)展至今，已經(jīng)有二十多年的歷史，整個(gè)發(fā)展的趨勢(shì)主要是兩個(gè)方向：效率 & 安全。
效率方面，從 HTTP1.0 的一次請(qǐng)求一個(gè)連接，到 HTTP1.1 的連接復(fù)用，到 SPDY/HTTP2 的多路復(fù)用，到 QUIC/HTTP3 的基于 UDP 傳輸，在效率方面越來(lái)越高效。
安全方面，從 HTTP 的明文，到 HTTP2 強(qiáng)制使用 TLSv1.2，到 QUIC/HTTP3 強(qiáng)制使用 TLSv1.3，越來(lái)越注重?cái)?shù)據(jù)傳輸?shù)陌踩浴?/p>
總而言之，HTTP 協(xié)議的發(fā)展對(duì)，用戶(hù)是友好的，但是對(duì)開(kāi)發(fā)者而言卻不那么友善。
抓包是每個(gè)程序員的必修技能之一，尤其是在接口調(diào)試和程序逆向方面具有廣闊的用途。但是，隨著越來(lái)越多的通信協(xié)議使用加密的 HTTPS，而且系統(tǒng)層面也開(kāi)始強(qiáng)制規(guī)定使用 HTTPS，抓包似乎是顯得越來(lái)越難了。
本篇博客，主要詳解 Android 平臺(tái)下，HTTPS 抓包的常見(jiàn)問(wèn)題以及解決辦法。工欲善其事必先利其器，博客中以 HttpCanary 作為抓包工具進(jìn)行講解>
更多 HttpCanary 的資料，請(qǐng)見(jiàn)：github: https://github.com/MegatronKing/HttpCanary。
一、抓包原理
幾乎所有網(wǎng)絡(luò)數(shù)據(jù)的抓包，都是采用中間人的方式（MITM），包括大家常用的 Fiddler、Charles 等知名抓包工具，HttpCanary 同樣是使用中間人的方式進(jìn)行抓包。
從上面這個(gè)原理圖，可以看出抓包的核心問(wèn)題主要是兩個(gè)：
MITM Server 如何偽裝成真正的 Server； MITM Client 如何偽裝成真正的 Client；
第一個(gè)問(wèn)題，MITM Server 要成為真正的 Server，必須能夠給指定域名簽發(fā)公鑰證書(shū)，且公鑰證書(shū)能夠通過(guò)系統(tǒng)的安全校驗(yàn)。比如 Client 發(fā)送了一條 https://www.baidu.com 的網(wǎng)絡(luò)請(qǐng)求，MITM Server 要偽裝成百度的 Server，必須持有 www.baidu.com 域名的公鑰證書(shū)并發(fā)給 Client，同時(shí)還要有與公鑰相匹配的私鑰。
MITM Server 的處理方式是從第一個(gè) SSL/TLS 握手包 Client Hello 中提取出域名 www.baidu.com，利用應(yīng)用內(nèi)置的 CA 證書(shū)創(chuàng)建 www.baidu.com 域名的公鑰證書(shū)和私鑰。
創(chuàng)建的公鑰證書(shū)在 SSL/TLS 握手的過(guò)程中發(fā)給 Client，Client 收到公鑰證書(shū)后會(huì)由系統(tǒng)會(huì)對(duì)此證書(shū)進(jìn)行校驗(yàn)，判斷是否是百度公司持有的證書(shū)，但很明顯這個(gè)證書(shū)是抓包工具偽造的。為了能夠讓系統(tǒng)校驗(yàn)公鑰證書(shū)時(shí)認(rèn)為證書(shū)是真實(shí)有效的，我們需要將抓包應(yīng)用內(nèi)置的 CA 證書(shū)手動(dòng)安裝到系統(tǒng)中，作為真正的證書(shū)發(fā)行商（CA），即洗白。這就是為什么，HTTPS 抓包一定要先安裝 CA 證書(shū)。
第二個(gè)問(wèn)題，MITM Client 偽裝成 Client。由于服務(wù)器并不會(huì)校驗(yàn) Client（絕大部分情況），所以這個(gè)問(wèn)題一般不會(huì)存在。比如 Server 一般不會(huì)關(guān)心 Client 到底是 Chrome 瀏覽器還是 IE 瀏覽器，是 Android App 還是 iOS App。
當(dāng)然，Server 也是可以校驗(yàn) Client 的，這個(gè)后面分析。
二、安裝 CA 證書(shū)
抓包應(yīng)用內(nèi)置的 CA 證書(shū)要洗白，必須安裝到系統(tǒng)中。而 Android 系統(tǒng)將 CA 證書(shū)又分為兩種：用戶(hù) CA 證書(shū)和系統(tǒng) CA 證書(shū)。
顧明思議，用戶(hù) CA 證書(shū)是由用戶(hù)自行安裝的，系統(tǒng) CA 證書(shū)是由系統(tǒng)內(nèi)置的，很明顯后者更加真實(shí)有效。
系統(tǒng) CA 證書(shū)存放在 /etc/security/cacerts/ 目錄下，名稱(chēng)是 CA 證書(shū) subjectDN 的 Md5 值前四位移位取或，后綴名是 .0，比如 00673b5b.0。考慮到安全原因，系統(tǒng) CA 證書(shū)需要有 Root 權(quán)限才能進(jìn)行添加和刪除。
對(duì)于非 Root 的 Android 設(shè)備，用戶(hù)只能安裝用戶(hù) CA 證書(shū)。
無(wú)論是系統(tǒng) CA 證書(shū)還是用戶(hù) CA 證書(shū)，都可以在設(shè)置 → 系統(tǒng)安全 → 加密與憑據(jù) → 信任的憑據(jù)中查看：
三、Android 7.0 的用戶(hù) CA 證書(shū)限制
Android 從 7.0 開(kāi)始，系統(tǒng)不再信任用戶(hù) CA 證書(shū)（應(yīng)用 targetSdkVersion >= 24 時(shí)生效，如果 targetSdkVersion <24 即使系統(tǒng)是 7.0 + 依然會(huì)信任）。也就是說(shuō)即使安裝了用戶(hù) CA 證書(shū)，在 Android 7.0 + 的機(jī)器上，targetSdkVersion>= 24 的應(yīng)用的 HTTPS 包就抓不到了。
比如上面的例子，抓包工具用內(nèi)置的 CA 證書(shū)，創(chuàng)建了 www.baidu.com 域名的公鑰證書(shū)發(fā)給 Client，系統(tǒng)校驗(yàn)此證書(shū)時(shí)發(fā)現(xiàn)是用戶(hù) CA 證書(shū)簽發(fā)的，Sorry。。。
那么，我們?nèi)绻@過(guò)這種限制呢？已知有以下四種方式（低于 7.0 的系統(tǒng)請(qǐng)忽略）。
3.1 AndroidManifest 中配置 networkSecurityConfig
如果我們想抓自己的 App，只需要在 AndroidManifest 中配置 networkSecurityConfig 即可：
<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
<application android:networkSecurityConfig="@xml/network_security_config"
... >
...
</application>
</manifest>
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>
這樣即表示，App 信任用戶(hù) CA 證書(shū)，讓系統(tǒng)對(duì)用戶(hù) CA 證書(shū)的校驗(yàn)給予通過(guò)。更多相關(guān)信息，詳見(jiàn) Network security configuration。
Network security configuration：https://developer.android.com/training/articles/security-config
3.2 調(diào)低 targetSdkVersion < 24
如果想抓一個(gè) App 的包，可以找個(gè)歷史版本，只需要其 targetSdkVersion < 24 即可。
然而，隨著 GooglePlay 開(kāi)始限制 targetSdkVersion，現(xiàn)在要求其必須 >= 26，2019 年 8 月 1 日后必須 >= 28，國(guó)內(nèi)應(yīng)用市場(chǎng)也開(kāi)始逐步響應(yīng)這種限制。絕大多數(shù) App 的 targetSdkVersion 都將大于 24 了，也就意味著抓 HTTPS 的包越來(lái)越難操作了。
3.3 平行空間抓包
如果我們希望抓 targetSdkVersion >= 24 的應(yīng)用的包，那又該怎么辦呢？
我們可以使用平行空間或者 VirtualApp 來(lái)曲線(xiàn)救國(guó)。平行空間和 VirtualApp 這種多開(kāi)應(yīng)用可以作為宿主系統(tǒng)來(lái)運(yùn)行其它應(yīng)用，如果平行空間和 VirtualApp 的 targetSdkVersion < 24，那么問(wèn)題也就解決了。
在此，我推薦使用平行空間，相比部分開(kāi)源的 VirtualApp，平行空間運(yùn)行得更加穩(wěn)定。但必須注意平行空間的版本 4.0.8625 以下才是 targetSdkVersion < 24，別安裝錯(cuò)了。
當(dāng)然，HttpCanary 的設(shè)置中是可以直接安裝平行空間的。
3.4 安裝到系統(tǒng) CA 證書(shū)目錄
對(duì)于 Root 的機(jī)器，這是最完美最佳的解決方案。如果把 CA 證書(shū)安裝到系統(tǒng) CA 證書(shū)目錄中，那這個(gè)假 CA 證書(shū)就是真正洗白了，不是真的也是真的了。
由于系統(tǒng) CA 證書(shū)格式都是特殊的 .0 格式，我們必須將抓包工具內(nèi)置的 CA 證書(shū)以這種格式導(dǎo)出，HttpCanary 直接提供了這種導(dǎo)出選項(xiàng)。
操作路徑：設(shè)置 → SSL 證書(shū)設(shè)置 → 導(dǎo)出 HttpCanary 根證書(shū) → System Trusted(.0)
PS. 很不幸的 HttpCanary v2.8.0 前導(dǎo)出的證書(shū)名稱(chēng)可能不正確，建議升級(jí)到 v2.8.0 以上版本操作。
導(dǎo)出 .0 格式的證書(shū)后，可以使用 MT 管理器將 .0 文件復(fù)制到 /etc/security/cacerts/ 目錄下，或者通過(guò) adb remount 然后 push 也可（這里稍微提一下，別在 sdcard 里找這個(gè)目錄）。
四、Firefox 證書(shū)安裝
火狐瀏覽器 Firefox 自行搞了一套 CA 證書(shū)管理，無(wú)論是系統(tǒng) CA 證書(shū)還是用戶(hù) CA 證書(shū)，F(xiàn)irefox 通通都不認(rèn)可。這種情況，我們需要將 CA 證書(shū)通過(guò)特殊方式導(dǎo)入到 Firefox 中，否則 Firefox 瀏覽網(wǎng)頁(yè)就無(wú)法工作了。
HttpCanary v2.8.0 版本提供了 Firefox 證書(shū)導(dǎo)入選項(xiàng)。在設(shè)置 → SSL 證書(shū)設(shè)置 → 添加 HttpCanary 根證書(shū)至 Firefox 中：
點(diǎn)擊右上角復(fù)制按鈕將 url 復(fù)制到粘貼板，然后保持此頁(yè)面不動(dòng)，打開(kāi) Firefox 粘貼輸入復(fù)制的 url。
出現(xiàn)下載證書(shū)彈框后，一定要手動(dòng)勾上：信任用來(lái)標(biāo)志網(wǎng)站和信任用來(lái)標(biāo)志電子郵件用戶(hù)。然后確定即可。
五、公鑰證書(shū)固定
證書(shū)固定（Certificate Pinning）是指 Client 端內(nèi)置 Server 端真正的公鑰證書(shū)。在 HTTPS 請(qǐng)求時(shí)，Server 端發(fā)給客戶(hù)端的公鑰證書(shū)必須與 Client 端內(nèi)置的公鑰證書(shū)一致，請(qǐng)求才會(huì)成功。
在這種情況下，由于 MITM Server 創(chuàng)建的公鑰證書(shū)和 Client 端內(nèi)置的公鑰證書(shū)不一致，MITM Server 就無(wú)法偽裝成真正的 Server 了。這時(shí)，抓包就表現(xiàn)為 App 網(wǎng)絡(luò)錯(cuò)誤。已知的知名應(yīng)用，比如餓了么，就采用了證書(shū)固定。
另外，有些服務(wù)器采用的自簽證書(shū)（證書(shū)不是由真正 CA 發(fā)行商簽發(fā)的），這種情況 App 請(qǐng)求時(shí)必須使用證書(shū)固定。
證書(shū)固定的一般做法是，將公鑰證書(shū)（.crt 或者 .cer 等格式）內(nèi)置到 App 中，然后創(chuàng)建 TrustManager 時(shí)將公鑰證書(shū)加進(jìn)去。很多應(yīng)用還會(huì)將內(nèi)置的公鑰證書(shū)偽裝起來(lái)或者加密，防止逆向提取，比如餓了么就偽裝成了 png，當(dāng)然對(duì)公鑰證書(shū)偽裝或者加密沒(méi)什么太大必要，純粹自欺欺人罷了。
證書(shū)固定對(duì)抓包是個(gè)非常麻煩的阻礙，不過(guò)我們總是有辦法繞過(guò)的，就是麻煩了點(diǎn)。
5.1 JustTrustMe 破解證書(shū)固定
Xposed 和 Magisk 都有相應(yīng)的模塊，用來(lái)破解證書(shū)固定，實(shí)現(xiàn)正常抓包。
eg. JustTrustMe: https://github.com/Fuzion24/JustTrustMe
破解的原理大致是，Hook 創(chuàng)建 SSLContext 等涉及 TrustManager 相關(guān)的方法，將固定的證書(shū)移除。
5.2 基于 VirtualApp 的 Hook 機(jī)制破解證書(shū)固定
Xposed 和 Magisk 需要刷機(jī)等特殊處理，但是如果不想刷機(jī)折騰，我們還可以在 VirtualApp 中加入 Hook 代碼，然后利用 VirtualApp 打開(kāi)目標(biāo)應(yīng)用進(jìn)行抓包。當(dāng)然，有開(kāi)發(fā)者已經(jīng)實(shí)現(xiàn)了相關(guān)的功能。詳見(jiàn)：
VirtualHook：https://github.com/rk700/VirtualHook CertUnpinning：https://github.com/rk700/CertUnpinning
不過(guò)，這里 CertUnpinning 插件的代碼有點(diǎn)問(wèn)題，要改改。
5.3 導(dǎo)入真正的公鑰證書(shū)和私鑰
如果 Client 固定了公鑰證書(shū)，那么 MITM Server 必須持有真正的公鑰證書(shū)和匹配的私鑰。如果開(kāi)發(fā)者具有真正服務(wù)端的公鑰證書(shū)和私鑰，（比如百度的公鑰證書(shū)和私鑰百度的后端開(kāi)發(fā)肯定有），如果真有的話(huà)，可以將其導(dǎo)入 HttpCanary 中，也可以完成正常抓包。
在設(shè)置 → SSL 證書(shū)設(shè)置 → 管理 SSL 導(dǎo)入證書(shū) 中，切換到服務(wù)端，然后導(dǎo)入公鑰證書(shū) + 私鑰，支持 .p12 和 .bks 格式文件。
六、雙向認(rèn)證
SSL/TLS 協(xié)議提供了雙向認(rèn)證的功能，即除了 Client 需要校驗(yàn) Server 的真實(shí)性，Server 也需要校驗(yàn) Client 的真實(shí)性。
這種情況，一般比較少，但是還是有部分應(yīng)用是開(kāi)啟了雙向認(rèn)證的。比如匿名社交應(yīng)用 Soul 部分接口就使用了雙向認(rèn)證。使用了雙向認(rèn)證的 HTTPS 請(qǐng)求，同樣無(wú)法直接抓包。
關(guān)于雙向認(rèn)證的原理。
首先，雙向認(rèn)證需要 Server 支持，Client 必須內(nèi)置一套公鑰證書(shū) + 私鑰。在 SSL/TLS 握手過(guò)程中，Server 端會(huì)向 Client 端請(qǐng)求證書(shū)，Client 端必須將內(nèi)置的公鑰證書(shū)發(fā)給 Server，Server 驗(yàn)證公鑰證書(shū)的真實(shí)性。
注意，這里的內(nèi)置的公鑰證書(shū)有區(qū)別于前面第 5 點(diǎn)的公鑰證書(shū)固定，雙向認(rèn)證內(nèi)置的公鑰證書(shū) + 私鑰是額外的一套，不同于證書(shū)固定內(nèi)置的公鑰證書(shū)。
如果一個(gè) Client 既使用證書(shū)固定，又使用雙向認(rèn)證，那么 Client 端應(yīng)該內(nèi)置一套公鑰證書(shū) + 一套公鑰證書(shū)和私鑰。
第一套與 Server 端的公鑰證書(shū)相同，用于 Client 端系統(tǒng)校驗(yàn)與 Server 發(fā)來(lái)的證書(shū)是否相同，即證書(shū)固定；第二套 SSL/TLS 握手時(shí)公鑰證書(shū)發(fā)給 Server 端，Server 端進(jìn)行簽名校驗(yàn)，即雙向認(rèn)證。
用于雙向認(rèn)證的公鑰證書(shū)和私鑰代表了 Client 端身份，所以其是隱秘的，一般都是用 .p12 或者 .bks 文件 + 密鑰進(jìn)行存放。由于是內(nèi)置在 Client 中，存儲(chǔ)的密鑰一般也是寫(xiě)死在 Client 代碼中，有些 App 為了防反編譯會(huì)將密鑰寫(xiě)到 so 庫(kù)中，比如 S 匿名社交 App，但是只要存在于 Client 端中都是有辦法提取出來(lái)的。
6.1 雙向認(rèn)證抓包
這里以 S 匿名社交 App 為例，講解下如何抓取使用了雙向認(rèn)證的 App 的 HTTPS 包。
如果服務(wù)器使用了 Nginx 且開(kāi)啟了雙向認(rèn)證，抓包時(shí)會(huì)出現(xiàn) 400 Bad Request 的錯(cuò)誤，如下：
有些服務(wù)器可能不會(huì)返回 404，直接請(qǐng)求失敗。
接下來(lái)看，如何使用 HttpCanary 配置雙向認(rèn)證抓包。
首先，解壓 APK，提取出 .p12 或者 .bks 文件，二進(jìn)制的文件一般存放都在 raw 或者 assets 目錄。
將 client.p12 文件導(dǎo)入手機(jī)，然后在 HttpCanary 的設(shè)置 → SSL 證書(shū)設(shè)置 → 管理 SSL 導(dǎo)入證書(shū)中，切換到客戶(hù)端（因?yàn)樾枰浣o MITM Client），然后導(dǎo)入. p12 文件。
由于雙向認(rèn)證的公鑰證書(shū)和私鑰是受密鑰保護(hù)的，所以需要輸入密碼：
一般通過(guò)逆向可以從 APK 中提取出密鑰，具體操作這里略過(guò)。輸入密鑰后，需要輸入映射域名，這里使用通配符 \* 映射所有相關(guān)域名：
導(dǎo)入完成后如下：
可以點(diǎn)進(jìn)證書(shū)詳情查看細(xì)節(jié)，這個(gè) client.p12 文件包含公鑰證書(shū)和私鑰，是用于雙向認(rèn)證的。
配置完成后，重新進(jìn)行抓包，看看效果。
可以看到，之前 400 Bad Request 的兩個(gè)要求雙向認(rèn)證的請(qǐng)求成功了！
七、SSL 重協(xié)商
有些服務(wù)器可能會(huì)開(kāi)啟 SSL 重協(xié)商，即 SSL/TLS 握手成功后發(fā)送請(qǐng)求時(shí)服務(wù)器會(huì)要求重新握手。這種情況一般比較少，但是也不排除，已知的應(yīng)用比如 10000 社區(qū) 就使用了 SSL 重協(xié)商。
由于 Android 系統(tǒng)對(duì) SSL 重協(xié)商是有限支持，所以部分系統(tǒng)版本抓包會(huì)失敗，表現(xiàn)為網(wǎng)絡(luò)異常。在 Android 8.1 以下，SslSocket 是完全支持 SSL 重協(xié)商的，但是 SSLEngine 卻是不支持 SSL 重協(xié)商的，而 HttpCanary 解析 SSL/TLS 使用的是 SSLEngine。在 Android 8.1 及以上，SSLEngine 和 SslSocket 統(tǒng)一了實(shí)現(xiàn)，故是支持 SSL 重協(xié)商的。
所以，如果確認(rèn)服務(wù)器使用了 SSL 重協(xié)商，請(qǐng)使用 8.1 及以上版本系統(tǒng)進(jìn)行抓包。
八、非 HTTP 協(xié)議抓包
如果確認(rèn)了以上幾點(diǎn)，HttpCanary 仍然抓包失敗，那么極有可能使用的并非是 HTTP 協(xié)議。比如像微信聊天，視頻直播等，使用的就不是 HTTP 協(xié)議，這種情況需要使用其它的抓包工具，比如 Packet Capture 這種直接解析 TCP/UDP 協(xié)議的，但是往往非 HTTP 協(xié)議的數(shù)據(jù)包即使抓到了也無(wú)法解析出來(lái)，因?yàn)榇蟾怕识际嵌M(jìn)制而非文本格式的。
九、結(jié)語(yǔ)
抓包是個(gè)技術(shù)活兒，需要對(duì)網(wǎng)絡(luò)協(xié)議有大致的了解，對(duì)抓包感興趣的同學(xué)可以多查閱 TCP、UDP、SSL/TLS、HTTP 等相關(guān)資料。
HttpCanary 是專(zhuān)業(yè)的 HTTP 協(xié)議抓包工具，專(zhuān)注 HTTP 協(xié)議三十年（吹過(guò)頭了），不過(guò)目前還不支持 QUIC/HTTP3 這種新協(xié)議，等 QUIC/HTTP3 正式應(yīng)用起來(lái)再說(shuō)吧。
九、墨影小結(jié)
本文很長(zhǎng)，知識(shí)密度也很高，我這里再試著結(jié)構(gòu)化的小結(jié)一下本文的內(nèi)容，希望對(duì)大家有所幫助。
Android 對(duì) HTTPS 的限制，通常來(lái)自 2 個(gè)方面：Android 系統(tǒng)自身的限制，和開(kāi)發(fā)者加強(qiáng)了 CA 驗(yàn)證。
Android 系統(tǒng)的約束，高版本（Android 7.0+）將不信任用戶(hù)自行安裝的 CA 證書(shū)，導(dǎo)致驗(yàn)證不通過(guò)。針對(duì)這種情況，有如下幾種解決方案：
可打包 Apk：配置 networkSecurityConfig，針對(duì)此 App 信任用戶(hù)證書(shū)；
可打包 Apk：調(diào)低 targetSdkVersion 至 24 以下；
不可打包 Apk：采用「平行空間（v. 4.0.8625 以下）」版本的 App 運(yùn)行后抓包；
不可打包 Apk：系統(tǒng) Root 后，將 CA 證書(shū)裝入系統(tǒng)目錄；
換個(gè) Android 7.0 以下的設(shè)備抓包（文章未提到）；
針對(duì)可自行打包的 Apk，通常會(huì)設(shè)置內(nèi)部測(cè)試版本和對(duì)外發(fā)布版本，以不同的打包策略來(lái)做隔離。
除了 Android 系統(tǒng)自身的約束外，開(kāi)發(fā)者還會(huì)加強(qiáng) App 的 CA 驗(yàn)證，通常的技術(shù)手段有「公鑰證書(shū)固定」和「雙向認(rèn)證」。
針對(duì)公鑰證書(shū)固定，解決方案有：
利用 Xposed 的 JustTrustMe 插件破解，Hook 相關(guān)流程將固定證書(shū)移除；
利用 VirtualApp 加入 Hook 代碼，原理與 JustTrustMe 類(lèi)似；
導(dǎo)入真正的公鑰證書(shū)和密鑰（僅適用于內(nèi)部使用）；
再就是雙向認(rèn)證，廣義上的 HTTPS，通常只做了客戶(hù)端驗(yàn)證服務(wù)端，實(shí)際上 HTTPS 是可以做到雙向驗(yàn)證的，針對(duì)雙向驗(yàn)證的 App，可使用 HttpCanary 導(dǎo)入證書(shū)，并通過(guò)逆向的手段拿到私鑰進(jìn)行破解抓包。
總結(jié)就到這里，只保留了一些我個(gè)人覺(jué)得需要記住的部分，當(dāng)然更多細(xì)節(jié)還是建議直接閱讀原文。
推薦閱讀
? 耗時(shí)2年，Android進(jìn)階三部曲第三部《Android進(jìn)階指北》出版！
? 『BATcoder』做了多年安卓還沒(méi)編譯過(guò)源碼？一個(gè)視頻帶你玩轉(zhuǎn)！
BATcoder技術(shù)群，讓一部分人先進(jìn)大廠
大家好，我是劉望舒，騰訊TVP，著有三本技術(shù)暢銷(xiāo)書(shū)，連續(xù)四年蟬聯(lián)電子工業(yè)出版社年度優(yōu)秀作者，谷歌開(kāi)發(fā)者社區(qū)特邀講師。
前華為技術(shù)專(zhuān)家，現(xiàn)大廠技術(shù)負(fù)責(zé)人。
想要加入 BATcoder技術(shù)群，公號(hào)回復(fù)BAT 即可。
為了防止失聯(lián)，歡迎關(guān)注我的小號(hào)
微信改了推送機(jī)制，真愛(ài)請(qǐng)星標(biāo)本公號(hào)??