android熱更新原理

『壹』 用通俗的語言解釋冷更新和熱更新。

熱更新是指軟體不通過運營商店的軟體版本更新審核，直接通過應用自行下載的軟體數據更新的行為。簡單來說，就是在用戶下載安裝APP之後，打開App時遇到的即時更新。熱更新是一種各大手游等眾多App常用的更新方式。

冷更新差不多就是重裝的意思，用戶主動從網路、存儲介質（光碟機、u盤等）來獲取安裝包，進行安裝的過程。而熱更新，是程序自主從安裝渠道（一般是網路）進行更新升級的過程。

工作原理

熱更新就是動態下發代碼，它可以使開發者在不發布新版本的情況下，修復 BUG 和發布功能，讓開發者得以繞開蘋果的審核機制，避免長時間的審核等待以及多次被拒造成的成本。

技術特點

在iOS中有兩種App更新方式：一種是在AppStore內進行更新，更新時重新下載全部安裝包；另一種就是熱更新，用戶只有在打開App時才會發現熱更新包，更新時只需下載安裝更新部分的代碼，再次打開時即可。熱更新最大的優點就是快，它可以繞過蘋果方面的審核，更新通常只需一個晚上即可上線，另一大優點就是更新包較小，一般都在1M左右，用戶不連接WiFi也可隨意下載。

『貳』 安卓動態載入jar實現類似熱更新功能

shift + 滑鼠右鍵打開命令行，輸入dx --dex --output=qula_dex.jar qula.jar

執行成功後

public class FileUtils {

public static void Files(Context context, String fileName, File desFile) {

InputStream in =null;

OutputStream out =null;

try {

in = context.getApplicationContext().getAssets().open(fileName);

out =new FileOutputStream(desFile.getAbsolutePath());

byte[] bytes =new byte[1024];

int i;

while ((i = in.read(bytes)) != -1){

out.write(bytes,0, i);

}

}catch (IOException e) {

e.printStackTrace();

}finally {

try {

if (in !=null)

in.close();

if (out !=null)

out.close();

}catch (IOException e) {

e.printStackTrace();

}

}

}

public static boolean hasExternalStorage() {

return Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED);

}

/**

    * 獲取緩存路徑

    * @param context

    * @return 返回緩存文件路徑

    */

    public static File getCacheDir(Context context) {

File cache;

if (hasExternalStorage()) {

cache = context.getExternalCacheDir();

}else {

cache = context.getCacheDir();

}

if (!cache.exists()){

cache.mkdirs();

}

return cache;

}

}

/**

* 載入dex文件中的class，並調用其中的sayHello方法

*/

private void loadDexClass() {

File cacheFile = FileUtils.getCacheDir(context);

String internalPath = cacheFile.getAbsolutePath() + File.separator +"qula_dex.jar";

File desFile =new File(internalPath);

try {

if (!desFile.exists()) {

desFile.createNewFile();

FileUtils.Files(context,"qula_dex.jar", desFile);

}

}catch (IOException e) {

e.printStackTrace();

}

//下面開始載入dex class

    DexClassLoader dexClassLoader =new DexClassLoader(internalPath,

cacheFile.getAbsolutePath(),null,context.getClassLoader());

try {

//載入的類名為jar文件裡面完整類名，寫錯會找不到此類hh

        Class libClazz = dexClassLoader.loadClass("com.justcodeit.xiaoshuo.netbook.BookFactory_qula");

loadBook = (IBookLoadFactory) libClazz.newInstance();

if (loadBook !=null)

Toast.makeText(context,"版本號" +loadBook.getVersion(), Toast.LENGTH_LONG).show();

}catch (Exception e) {

e.printStackTrace();

}

}

『叄』 安卓12帶來新功能，終於不用等進度條了

想用手機玩 游戲 一共分幾步？第一步下載 游戲 ，第二步等待 游戲 大幾個GB的熱更新，第三步，所有更新完成後才能拿起手機快樂玩耍。雖然玩 游戲 很快樂，但是漫長的更新的過程，特別是大量的熱更新，很磨人，好在這種問題或許在未來有機會緩解。

昨日，谷歌舉行 游戲 開發者峰會，推出了全新的開發工具和解決方案，讓基於安卓和Chrome 操作系統的 游戲 開發變得更為簡單。值得注意的是，本次峰會還講到了android 12在 游戲 方面的改進，比如用戶可以邊下邊玩。

1.玩 游戲 不再等待

「邊下邊玩」功能目前僅適用於Android 12設備，這項功能可以有效縮短下載大型 游戲 時的等待時間。當用戶在Google Play下載 游戲 之後，僅需等待幾秒鍾就能進入 游戲 界面，開始玩 游戲 ，而 游戲 包仍在後台繼續下載。

這項功能在原理上與迅雷的「邊下邊播」有些類似，經過數秒的等待後，用戶便可以直接進入 游戲 ，不需要等整個 游戲 下完，400MB 大小的 游戲 只需 10 秒即可開始遊玩。這項功能對於Xbox、PS平台的主機玩家而言並不陌生，因為這兩種 游戲 主機已經提供了類似的功能，但是這項功能在安卓手機上實現還是第一次。

不過對於手機端的「邊下邊玩」，實際遊玩體驗如何，畫質表現如何等問題，谷歌並沒有提及，預計在之後的測試中，會有更為明確的測試結論。另外，國內手機廠商會針對安卓系統進行個性化、品牌化、本地化處理，會針對功能做出一些修改和完善，或許屆時這項功能會以一種更為完備，或者以另一種形式出現也並非不可能。

2. 游戲 儀表盤，自定義 游戲 參數

Android 12新增 游戲 儀表盤功能，這項功能可以讓用戶自定義 游戲 運行的各項參數，還提供了 游戲 直播快捷鍵、 游戲 數據小部件、屏幕錄制、截屏、幀數監測和免打擾按鈕等功能。

另外， 游戲 儀表盤這次還增加了性能模式調節功能，這項功能與手機-電源選項中的性能模式有所不同，它是可以針對 游戲 而獨立設置的。目前，性能模式有性能、標准和省電三種模式，選擇之後，系統會自動為該 游戲 記憶性能配置，下次打開 游戲 不需要重新設置。

這項功能的意義在於玩家可以針對 游戲 單獨調整性能輸出，例如《原神》、《和平精英》、《崩壞3》這樣的 游戲 ，大可用性能模式火力全開，而對於消消樂等休閑 游戲 ，便可以選擇「標准」或「省電」模式，適當降低性能輸出，動態降低功耗。

3.Android 12代碼曝光新機和自研晶元

開發者在Andorid 12新 游戲 模式的API文檔中，發現了谷歌下一代Pixel系列的命名——Pixel 6和Pixel 6 XL，將搭載谷歌自研的處理器平台。目前，該系列手機的真機圖也在網上曝光。

Pixel 6系列的外觀相比上一代不能說不一樣，只能說是完全不同，整部手機的設計語言都有了非常大的改變，特別是手機背面的辨識度直接拉滿。

該系列手機正面搭載一塊6.71英寸居中打孔屏，開孔非常小，而Pixel 6 XL搭載的是一塊曲面屏，四周邊框控製得非常好，大大提升了正面屏幕的屏佔比以及整體的觀感。

不過相比正面，背面設計更為大膽。手機背面被分為三段，相機模組部分凸起，攝像頭橫向排布。但不同的是，Pixel 6搭載了5000萬像素主攝+1200萬像素超廣角攝像頭，XL版本在前者的基礎上增加了一顆4800萬像素長焦攝像頭，而且這顆長焦攝像頭很有可能還是一顆潛望式攝像頭，所以XL版本的凸起部分也更寬。在配色選擇上，Pixel 6 XL將會有4種顏色選擇，而Pixel 6隻有一種。

除了大膽的外觀設計，自研晶元也是Pixel 6系列的重點之一。該系列將全系搭載谷歌自研的處理器平台，採用5nm晶元製程，由谷歌和三星半導體部門聯合開發。在性能表現上，這款處理器與高通驍龍870大致相當。另外，Pixel 6將配備8GB+128/256GB兩種內存組合，內置4614mAh電池，XL則配備12GB RAM，有128/256/512GB三種存儲規格，電池容量增加到5000mAh。

結合之前已經公布的內容，Android 12是一個干貨滿滿的新系統，這款系統將在今年秋季開啟推送，預計屆時Pixel 6系列手機也會與消費者見面。

『肆』 安卓熱更新違規嗎

違規
其實無論是安卓還是iOS，規則上都是不允許「熱更新」的。只不過以前iOS並沒有特別嚴格的限制，安卓是由於開源且其服務在國內不能使用，所以形同虛設。禁止熱更新有利有弊。有利的是，禁止熱更新，更能夠保證用戶的安全性。不利的是，每次都需要下載一個完整的應用，耗費流量。
如果平台支持熱更新的話，客戶端在更新的時候不需要重打包，玩家不需要重新進入網站下載最新安裝包，而直接在大廳內部檢測更新文件唯一標識碼，自動下載更新替換文件。

『伍』 android熱更新框架哪個好

一.基礎知識

1.阿里的熱更新框架已經開源 了。但已經很久沒有更新過新版本了。當前的版本只支持到了 Android 4.4。由於 5.0 起新的 ART 虛擬機、更嚴格的 SELinux 策略以及對 64 位的支持之類的事，使得 Xposed 都在開發上做了很多調整。我不知道 Dexposed 現在是否支持，但至少阿里沒有開源。

2.在本地動態執行遠端下發的代碼是極度危險的行為。利用此方法執行非法代碼等或用於繞過 Google Play 等市場的審查是違反相關協議的，也是對用戶極度不負責任的行為。

3.在一些訪問非常密集的地方使用熱更新可能會對效率產生相對比較大的影響，應該避免使用.

4.我們可以對 Java 的 ScriptEngine 進行一些封裝成為一個 HotPatch 類使得它更適合做熱更新的工作。

5.首先,檢查熱更新補丁的管道一定要建立在 https 上，因為下發代碼是極其危險的，如果被劫持，後果是無法想像的。其次,請求時最好自動帶上 Android 版本、手機型號、地區、版本號等信息，以方便更精確地下發，千萬不能下發錯。

6.Java在運行時載入對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類載入器

7.我們的如果想做hotpatch，一定要保證我們的hotpacth dex文件出現在dexElements列表的前面。

二.常用的熱更新技術框架:

基於QQ空間的HotFix →→ 要使用到android dex分包方案→拆分dex的項目的話，可以參考一下谷歌的multidex方案實現.

大眾點評的NuWa←項目補丁自動化做的很完整
alibaba/AndFix

阿里巴巴的DexPosed
dalvik_patch實現multidex
使用React-Native實現app熱部署的一次實踐
alibaba/AndFix

三、常用的熱更新技術框架比較

Advantage
disadavantage
NuWa
1，可以新增類和欄位，
2，兼容到6.0系統
1，基本原理是classloader,類載入器
2，不能修改資源文件，如圖片布局等（可通過動態布局實現）
AndFix
1， 支持Android2.3到6.0版本
2， 支持arm與x86系統架構
3， 支持dalvik和ART的runtime
4， 不需要重啟App即可應用補丁
1，不能新增類和欄位，
2，不能修改資源文件,
3，不能修改manifest文件
4，不能新增成員變數
5，不能使用加固後的apk製作pacth文件
四、github地址
網路的同學的實現 HotFix
點評的同學的實現 Nuwa
阿里的同學的實現 AndFix
另：AndFix對static的支持不太好，下面是試驗的Demo:
添加了一個靜態的欄位addString：

通過AndFix來製作patch會直接報錯：

『陸』 Android開發Tinker熱更新的問題

通過閱讀官方的技術文檔，始終沒有發現有對這個情況的相關配置項，所以只能從別處下手，最後發現，通過在 app mole 的 「build.gradle」 文件中，注釋掉依賴插件腳本，最終解決掉這個問題：

說兩句：
目前運行調試一切正常，不過要始終留意後續是否會出現問題；重要的一點是，當要打包新版本時，一定要解開這個注釋。

2、can』t the get signConfig for this build

問題：
執行 buildTinkerPatchRelease 打 Release 版本補丁包時報以下錯誤：

Error:Execution failed for task ':app:tinkerPatchRelease'.
> can't the get signConfig for this build
1
2

解決：

android {
...
// 簽名配置【buildTypes中調用了signingConfigs，則signingConfigs{}要置於buildTypes{}前面】
signingConfigs {
release {
try {
storeFile file("MyProject.jks")
storePassword "111111"
keyAlias "zhangzeqiao"
keyPassword "111111"
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}
}

buildTypes {
release {
...
signingConfig signingConfigs.release
}
debug {
...
signingConfig signingConfigs.release
}
}
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
其中要特別注意，signingConfigs{} 方法體要置於 buildTypes{} 方法體前面，不然會報以下錯誤：

『柒』 Android 插件化

原理：實現原理上都選擇盡量少的hook，通過在manifest上預埋一些組件實現四大組件的插件化。其中Small更形成了一個跨平台、組件化的框架。

VirtulApp：
能夠完全模擬app的運行環境，能夠實現免安裝應用和雙開技術。
Atlas：
阿里出品，號稱是一個容器化框架，結合了組件化和熱更新技術。

Android中有兩種類載入器，DexClassLoader和PathClassLoader，它們都繼承於BaseDexClassLoader。

兩者的區別：DexClassLoader多了一個optimizedDirectory的路徑參數，這個目錄必須是內部存儲路徑，用於緩存系統創建的Dex文件。

所以我們可以使用DexClassLoader去載入外部Apk中的類。

ClassLoader調用loadClass方法載入類採用了雙親委託機制來避免重復載入類。
首先，ClassLoader會查看自身已經載入的類中是否已經存在此類，如不存在，然後，則會使用父類來載入此類，如不能成功載入，則會使用自身重載於BaseDexClassLoader的findClass()方法來載入此類。

DexClass的DexPathList在DexClass的構造器中生成，findClass()方法則是從DexPathList下面找出對應的DexFile，循環DexElements，通過dexElement.dexFile取出對應的DexFile，再通過DexFile.loadClassBinaryName()載入對應的類。

作用：使用插件DexClassLoader載入出需要的類。

通過每一個插件的DexClassLoader載入出自身所需要的類，當每一個插件需要載入相同的類庫時，可採用該類庫的不同版本來使用。

通過把每一個插件的pathList（DexFile）合並到主app的DexClassLoader上，來使各個插件和主app直接能夠相互調用類和方法，並且各個插件中相同的功能可以抽取出來作為一個Common插件供其它插件使用。

插件調用主工程
在ClassLoader構造時指定主工程的DexClassLoader為父載入器即可直接調用主工程中的類和方法。
主工程調用插件
如果是多DexClassLoader的情況，則需要通過插件的DexClassLoader載入對應的類並反射調用其方法。此種情況，主工程一般會在一個統一的地方對訪問插件中的類和方法做一些訪問許可權的管理及配置。

如果是單DexClassLoader的情況，則可以直接調用插件中的類和方法。但是當多個插件引用的庫的版本不同時，會出現錯誤，因此，建議採用Gradle版本依賴管理統一處理主工程及各個插件的庫依賴。

Android通過Resource來載入資源，只要有插件apk，就可以使用assertManager.addAssertPath（apkPath）的方式來生成assertManager，再使用其new出對應的Resource對象即可。

注意：由於AssertManager並不是Public，所以需要通過反射的方式去調用它。並且由於一些Rom對Resource的處理，所以，需要兼容處理。

有2種處理方式：

產生的原因：由於主工程和各個插件引用的Resource id重復產生的沖突。

解決思路：Android中的資源在系統中是以8位16進制0XPPTTRRRR的方式存在，其中PP即是資源區分的區域（Android系統只用它來區分系統資源和應用資源），只要讓每一個插件的PP段取不同的值即可解決資源id沖突的問題。
具體解決方式：

1.修改aapt源碼，編譯期修改PP段。
2.修改Resource的arsc文件，其中的每一條都包含了資源id和映射路徑。

Activity的處理最為復雜，有兩種處理方式：
1.ProxyActivity的方式。
2.預埋StubActivity，hook系統啟動Activity的過程。

原理：VirtualAPK通過替換了系統的Instrumentation，hook了Activity的啟動和創建，省去了手動管理插件Activity生命周期的繁瑣，讓插件Activity像正常的Activity一樣被系統管理，並且插件Activity在開發時和常規一樣，即能獨立運行又能作為插件被主工程調用。

Android插件化方向主要有2個方向：

Android 插件化

『捌』 android熱更新是什麼意思

我們知道Java在運行時載入對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類載入器，
PathClassLoader其實實現的就是簡單的從文件系統中載入類文件。PathClassLoade本身繼承自BaseDexClassLoader，BaseDexClassLoader重寫了findClass方法，
該方法是ClassLoader的核心

『玖』 react native能解決熱更新問題嗎

上一篇和大家分享了如何在Android 現有App中集成React Native。本篇博客同樣是react Native中比較經典的內容：熱更新部署。
android原生App中我們實現熱修復有很多種選擇：Tinker、hotFix、Qzone的熱更新等等。基本的思路都是大同小異的。React Native中的熱更新有點像App的版本更新，也就是根據查詢server端的版本和手機端目前App的版本進行對比，然後來執行是否更新的操作。根本原因在於react native的載入啟動機制：React Native會將一系列資源打包成js bundle文件，系統載入js bundle文件，解析並渲染。所以，React Native熱更新的根本原理就是更換js bundle文件，並重新載入，新的內容就完美的展示出來了。微軟為我們提供了CodePush來簡化熱更新的操作，但是由於速度等原因在國內並沒有備受青睞。本篇內容就以自己伺服器來更新的方式實現。

『拾』 Android版微信的增量升級包是什麼原理

升級機制：
我們打算採用delta編碼的patch升級Android應用。新的升級機制可以描述如下：

1、 在伺服器上生成一個patch。
2、 下載patch到手機中。
3、 通過補丁獲取一個已安裝應用的新的安裝apk。
4、 安裝應用的新版本並刪掉舊的版本和patch。

統計數據：
我們當前正在研究應用怎樣在android中升級。這個研究結果將允許我們在新的升級機制下節約大量的流量。我們創建了一個android應用用來收集統計數據（可能會用於將來的研究）。
應用會收集以下數據：
1、 應用的名字，版本，大小和每個應用最後升級的時間。
2、 統計Wifi和3G的鏈接狀態。

谷歌增量升級技術：

在谷歌2012 I/O大會上宣布Google Play Stroe的增量升級技術。它始於八月中旬。他們使用跟我們相同的升級機制。比較兩個應用的不同，並將patch部署在終端上。