一.內部版本接入
內部最新版本爲0.7.48，接入方式與外部版本相同，不再贅述。
詳情看：ROBUST接入
着重講解外部版本與內部版本的區別：
外部版本需要設定補丁加載路徑以及加載時機，內部則配合Env自行保存及加載。
內部使用需要在Application中手動初始化Robust，如圖：
根據觀察的補丁加載時機以及抓包的結果來看。
推測：內部補丁加載時機爲Application初始化，會去根據上述參數構建一個get請求，請求補丁列表。如果有補丁，則下載補丁然後自動加載。所以補丁加載只會在
App進程被殺之後才生效。
這裏說句題外話。內部使用與外部使用最大的區別在於，我團內部使用，是有Env發版策略配套，補丁放置的服務器由專門的人員去維護。而外部人員使用，需要自己選擇補丁放置的服務器路徑，自己
去訂製補丁請求的策略。在代碼上的區別就在於 PatchManipulate 這個類中的更改：
外部版本需要繼承上述類，而內部版本已經替我們寫好了子類。
是不是很眼熟？在初始化Robust時會傳入上述參數，最終依據這些數據，組成一個get請求，請求相應的補丁。
下面是一個完整請求的例子：
URL
當發現請求能拿到補丁時，會請求到下載地址：
根據下載地址，下載補丁，然後放置在指定的文件地址中。
Tips：內部使用時，注意Robust.xml中的 patchPackname 路徑設置爲 com.meituan.robust.patch
二.補丁製作及發佈
發版原則：
第零、首先確保自己的修改能解決問題，而不是自己對修改沒有信心，抱着試試的心態。簡單的驗證方式就是把自己的修改提交到git，然後使用jekins打一個release包，驗證問題是否修復
第一、不推薦濫用熱補丁，對於比較大的問題才予以修復（線上修復的範圍：線上bug P1 P2予以修復、p3待定（業務老大和QA商量，通知平臺QA wangkai17參與），其餘不予以上線），熱補丁上線是存在風險的，可能存在着QA沒有測試到的場景，產生一些意想不到的bug。
補丁上線之前需要郵件周知自己業務老大和QA老大，[email protected],[email protected],[email protected],[email protected]，[email protected]，郵件主題：xx業務+版本號+修復文件簡要說明，例如：團購業務6.7.1版本修復旅遊頻道支付bug，郵件內容中指明具體修復的bug以及技術評估範圍和測試範圍.
業務老大和QA老大同意之後才允許上線，上線之後出現的問題，需要由上線補丁的操作者、QA以及相關人員共同負責（eva後臺有記錄），所以慎重上線。
第二、如果責任人都不確定是否能修復bug，或者說bug不是必現的，責任人自己也沒有把握修復問題，那就不要上了。以測試的心態去線上操作熱補丁，我們是拒絕的。
第三、晚上七點之後拒絕上線熱補丁，熱補丁製作出來需要進過QA的測試，不可以匆匆忙忙的測試，甚至在沒有QA的參與下測試，然後直接上線，需要給予QA足夠的時間來測試。
第四、補丁上線之後，需要留意crash數據（一般留意一個星期的數據，crash工作臺，搜索crash關鍵數據：robust或者patch），發現數據異常，需要立即定位問題，及時下線補丁。
補丁製作：
1.手動製作補丁
補丁製作基於線上版本的最後一次commit，保證代碼一致後，執行線上打包命令，保存生成的兩個文件。
這裏以服務員App舉例：
手動打線上包命令：./gradlew assembleRelease signRelease
打包完成之後，保留mapping，methodsMap.robust文件。
在主工程src同級目錄下建立robust文件，將上述保留文件copy進去。
然後，更改我們需要修復的方法。
更改規則如下：
在改動的方法上面添加@Modify註解或者在修改的方法裏面調用RobustModify.modify()（針對Lambda表達式）
@Modifyprotectedvoid onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
//或者是被修改的方法裏面調用RobustModify.modify()方法protectedvoid onCreate(Bundle savedInstanceState) {
RobustModify.modify()
super.onCreate(savedInstanceState);
}
新增的方法和字段使用@Add註解
//增加方法@AddpublicString getString() {
return”Robust”;
}
//增加類@AddpublicclassNewAddCLass {
publicstaticStringget() {
return”robust”;
}
}
代碼修改完畢，主工程build.gradle中打開插件製作。
//製作補丁時將這個打開，auto-patch-plugin緊跟着com.android.application
//apply plugin: ‘auto-patch-plugin’
接着再運行一次剛纔的打包命令，補丁製作好後會拋出一個RuntimeException,代表補丁就已經做好啦。
2.補丁自動製作
此處已有詳細文檔，不再贅述
https://wiki.sankuai.com/pages/viewpage.action?pageId=727552545
補丁製作詳細版
三.補丁發佈
經過前面幾步，終於辛辛苦苦製作出補丁，現在終於可以把補丁放到服務器上測試了。熱補丁的服務器在eva上（因此發佈補丁的權限和eva服務器的權限是一樣的,eva權限申請流程），eva有測試服務器和正式服務器:
其中測試服務器上傳補丁頁面的地址爲：http://10.4.239.113:8001/Android/waimai/addpatch(以外賣爲例，域名中是包含appname 的) 補丁的管理頁面爲：http://10.4.239.113:8001/Android/waimai/patches
正式服務器上傳補丁頁面的地址爲：http://appupdate.sankuai.com/Android/waimai/addpatch 補丁的管理頁面爲：http://appupdate.sankuai.com/Android/waimai/patches
以測試服務器爲例：
服務員測試服補丁發佈地址
點擊補丁管理，會出現一個添加補丁的地址
然後如何確定補丁是否下發成功了？
三.補丁的測試
建議測試的時候在測試服務上面測試，免得污染線上的環境。爲了把線上apk中的獲取補丁的請求轉發到測試服務器上，需要使用Charles進行轉發，需要導入配置文件，
測試的時候抓取手機log，如果補丁沒有導致apk崩潰並且修復了bug，那麼就去log中搜索exception，看看有沒有補丁引起的其他異常，如果異常的堆棧中含有patch或者robust就表示和補丁有關係。
又或者不加載補丁的時候沒有exception，加載補丁之後卻出現了exception，那麼也是和補丁相關的異常
判斷補丁是否下載：
儘可能的覆蓋所有使用到被補丁方法的場景
四.補丁的正式上線
補丁經過QA的測試之後，QA和bug影響業務的老大同意之後上線，各個獨立app各自負責補丁上線