在2023年6月這個時間點，我們有必要談談熱更新這個技術到底何去何從。
\\\\
ios平台的熱更新可以分為三類：
\\ 第二類是使用native動態化技術，替換原生**。這種是蘋果所主要打擊的物件，雖然不是不能繞過蘋果的檢測，但一旦發現肯定會被處理。
\\ ios在較新的版本裡允許本地庫的動態載入(要求簽名一致)，也就是說，技術層面其實ios要比早些年要開放一些；但在商務層面，蘋果的審核在今年是偏嚴厲的，通過觀察ios的熱更禁止行為，得到的結論是但凡沒有動態載入和反射呼叫系統的函式，蘋果仍然是允許的(也就是說仍然可以動態載入自己的功能)，但從第二次通知來看這方面也在收緊，未來如何變化還尤未可知。
\\\\
雖然ios上熱更新遭遇阻礙，但在國內android平台，事情是另乙個樣子。
\\\\
這些熱更新技術大部分已經開源，但要想應用這些技術實際並不容易，其中有很多坑。
\\\\
第一大坑當屬android系統版本相容性。有些熱更新技術在開發的技術路線選擇時，未完善考慮系統公升級帶來的問題。當android系統進行大的版本公升級時，可能會對底層的**進行一些修改，如果熱更新技術依賴了舊版本的**，一旦系統公升級，熱更新技術就會變得完全不可用。早期的熱更新技術基本都有這樣的特點。
\\ 第二大坑是由android系統碎片化帶來的相容問題。由於國內不同android版本和硬體裝置的組合高達數千種，不同廠商還會對自家的rom進行魔改，熱更新由於涉及系統底層**，撞上錯誤的概率並不小，android的開放生態使得沒有任何人能絕對的說，它的應用或**可以和所有android機型相容。由此帶來的問題就是，如果你使用的是部分第三方的開源熱更新技術，沒有人及時跟進issue時，遇到問題難以及時修復。
\\ 第三大坑是部署和實施，熱更新並不是在在客戶端嵌個sdk，然後寫幾行**整合就完了，你還需要在伺服器部署更新包的分發，管理不同的客戶端版本和差分包，更新出現問題時要能回滾，另外灰度發布也是運營大概率會要求支援的，甚至可能還有針對機型和系統版本進行更新的需求。這方面的人力成本並不小。
\\\\
黃杲介紹，樂變的android熱更新服務通過以下手段避免以上的幾個坑。
\\ 對於android新版本的適配，樂變作為google partners lab的成員，可以做到在每年的年初，甚至是google i/o之前，就完成了下半年才會正式發布的android新版本的相容和測試。
\\ 樂變熱更作為已經研發和成熟商業化運營已有五年的方案，支援從android 2.2到最新的android o pre-release的所有版本，支援x86等小眾架構，支援dalvik和art引擎，並適配過數千款機型，所以成熟度非常高。
\\ 此外，樂變熱更新提供的是一整套的解決方案，包括客戶端、服務端、管理後台和統計系統、crash分析系統等等，所有這些部分都無需開發者自己來構建和實現。
\\ 最後，在服務的靈活性方面，樂變不僅支援公有雲的標準化服務，也支援私有雲的部署方案，結合客戶的訴求，實施方式靈活多變。
\\\\
比如遊戲包體通常比較大，所以在差分包計算上難度會更大；同時，遊戲的強制更新比較多，針對強制更新將使用者體驗設計好就很重要；再有，遊戲渠道的二次打包的現象比較普遍，這又會進一步對於差分包的計算提出新的挑戰；最後，應用和遊戲要更新物件的側重點也會有些差異，比如應用在渠道包之間一般只有渠道標識的差異，但遊戲則需整合不同渠道sdk.
\\\\
熱更新在遊戲中的乙個特殊地方就是遊戲分包技術，當前手機遊戲的安裝包越做越大，但實際上可以通過一些技術實現邊下邊玩，相對的安裝包可以做到很小。
\\ 黃杲介紹道，樂變的遊戲分包服務包括**壓縮：
\\ 第二級是邊玩邊下，原理是通過將使用者早期訪問到的資源提取出來形成乙個小包，在使用者玩遊戲的同時自動下午後續內容(非wifi狀態需要使用者確實和選擇)，通過這種方式，通常能夠將包體壓縮至原包體的三分之一以下的大小；
\\ 當前樂變的遊戲分包技術支援支援ios和android，支援的遊戲引擎包括unity和cocos2d-x，其它的遊戲引擎或平台的對接還在開發和測試當中，比如針對虛幻引擎的支援，還有針對windows系統的支援等。
\\\\