筆記摘抄于：阿裡《深入探索android熱修複技術原理》 一.熱修複介紹： 1.修複技術對比
2.代碼修複的兩種方案： 1.阿裡的底層替換方案（時效性好，加載快，立即見效，傳統的替換方案不能添加，删除 方法和屬性） 2.騰訊的類加載方案（時效性差，需要冷啟動，但是修複範圍廣，限制少）
3.sophix特點 1.非入侵式 2.結合類加載方案和底層替換方案 3.資源修複 4.so修複
二.代碼熱修複技術 1.andfix: 1.替換所有artmethod 2.artmethod是緊密排列的，兩個artmethod起始位址的內插補點就是前一個artmethod的大小 3.通路權限（dex2oat時已經進行了權限檢測，是以機器碼碼中沒有權限檢測代碼） 4.同包名下通路權限問題（利用反射設定新類的classloader為原來的類） 5.非靜态方法（采用冷啟動方式處理） 6.andfix限制：替換方案不能添加，删除 方法和屬性 2.你所不知道的java 1.内部類 1.内部類在編譯器會被編譯為和外部類一樣的頂級類 2.靜态内部類不持有外部類的引用，非靜态内部類相反 3.内（外）部類會在編譯期間生産access&**相關方法貢外（内）部類通路 對應熱部署的解決方案：阻止成access&**相關方法
2.匿名内部類 1.匿名内部類編譯時生産的類名為：外部類.&number 對應熱部署的解決方案：不能新增和删除匿名内部類 3.域編譯 1.clinit和init差別 <clinit>：在jvm第一次加載class檔案時調用，包括靜态變量初始化語句和靜态塊的執行（此方法java源碼沒有有編譯器合成） <init>:在執行個體建立出來的時候調用，包括 調用new操作符；調用Class或 Java .lang.reflect.Constructor對象的newInstance()方法；調用任何現有對象的clone()方法；通過java.io.ObjectInputStream類的getObject()方法反序列化。 2.熱修複不支援clinit（即：不能修複靜态變量和靜态代碼塊） 4.final static 域翻譯
1.final static 修飾非引用類型可以優化，但是修飾引用類型不能起到優化的作用 處理方案：final static 修飾原始類型和String類型 可以實行熱修複 final static 修飾要引用類型 不以實行熱修複 5.方法編譯 1.如果使用代碼混淆，方法可能被内聯或裁剪
方法裁剪：方法入參沒有使用，在混淆任務之前會先裁剪成無參的方法 防止被裁剪的辦法：
熱修複處理方案：熱修複配置檔案加上 -dontoptimaize 不讓混淆對方案裁剪和内聯 6.switch case 語句編譯 1.switch 語句的id資源id不會被替換 熱修複處理方案：修改smail反編譯流程，碰到packed-switch 指令強轉為sparse-switch指令，：pswitch_N等指令也強轉為：ppswitch_N指令，然後做資源id暴力替換，然後回編譯smail為dex 7.Lambda表達式編譯 1.新增Lambda表達式删除Lambda表達式導緻類方法錯亂，導緻熱修複失敗 2,修改lambda表達式可能新增field也會導緻熱修複失敗 8.通路權限對熱修複的 影響 1.類加載有三個階段：resolve>link>init 3.冷啟動類加載原理 1.冷啟動比較
2.插樁 1.加載一個dex檔案到本地記憶體時，如果不存在odex檔案，就會先執行dexopt。 2.
3.DexFile.loadDex嘗試把dex檔案解析到natice記憶體，在加載到native之前，會先檢查有沒有odex，不過不存在對應odex檔案，那麼Dalvik下會執行dexopt，Art下會執行dexoat，最後得到odex，實際上虛拟機執行的是odex而不是dex 4.Dalvik：使用自行研發的全量dex加載方案 Art：Art已經支援多dex加載，處理方式為：更新檔dex作為知足dex（classes.dex）加載 3.多态對冷啟動的影響 1.fidle和static方法不具有多态特性 2.private 方法也不具有多态特性 4.Dalvik下完整dex方案 1.一般，把新的dex插入到ClassLoader最前面，問題:
2.一種全新的方案： 1.将基線包dex中需要替換的class去除掉，加載時沒有這個class就會去更新檔dex中找 注意：這裡的去除class并不是把素有資訊去除掉，這會導緻dex各個部分發生變化，隻是要完成解析dex時找不到這個class的目的 2.Application的處理（程式入口）
三，資源熱修複技術 四，so庫熱修複技術