A. ios開發中有哪些第三方庫包含熱更新
1.AVOSAVOS是目前比較成熟的BAAS服務商，支持多種客戶端(android、iOS、其他)的SDK，提供賬號管理、推送、第三方登錄、自定義API、用戶反饋組件、數據統計等多項功能。以前開發應用常用自己的伺服器搭建PHP或者NodeJS的RESTfulAPI，現在基本都是通過AVOS實現API的調用。類似的BAAS服務商還有：BMOB2.Testin專注於移動端測試的服務平台，可以掌握准確的崩潰信息。3.FIR/蒲公英應用發布平台4.AnySDK第三方SDK快速接入平台5.Flurry用戶數據分析6.TestFlight遠程測試7.FlightPath用戶統計8.待客統一管理跟蹤用戶。9.七牛雲存儲提供大型文件的雲存儲服務10.SendCloud郵件發送管理系統
B. 原生app嵌套h5頁面怎麼實現熱更新
這種方式必須要native另做一個同步功能了。若native開啟緩存，web靜態資源非覆蓋式發布，既能享受類似本地的快感，還能做到及時更新。
補充：
簡單做: 在靜態伺服器新建一個文本或json文件，裡面寫好版本號，版本號任意，你要更新的時候就去改這個版本號。native每次或定時去拉這個文件，並將版本號存在本地，以後拉取時比對本地版本號，有變化則重新拉取靜態資源到本地。
更好的是: 靜態文件打包時生成改動文件映射表，這個表只有已經改動的文件名稱或地址，native每次拉取這個映射表，發現有改動文件則只拉取改動文件。
這種方式必須要native另做一個同步功能了。若native開啟緩存，web靜態資源非覆蓋式發布，既能享受類似本地的快感，還能做到及時更新。
C. 如何實現 熱更新 android 資源
我們知道Java在運行時載入對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類載入器，PathClassLoader其實實現的就是簡單的從文件系統中載入類文件。PathClassLoade本身繼承自BaseDexClassLoader，BaseDexClassLoader重寫了findClass方法，該方法是ClassLoader的核心。
?
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
@Override
protected Class> findClass(String name) throws ClassNotFoundException {
List suppressedExceptions = new ArrayList();
Class c = pathList.findClass(name, suppressedExceptions);
if (c == null) {
ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class /"" + name + "/" on path: " + pathList);
for (Throwable t : suppressedExceptions) {
cnfe.addSuppressed(t);
}
D. 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來簡化熱更新的操作，但是由於速度等原因在國內並沒有備受青睞。本篇內容就以自己伺服器來更新的方式實現。
E. android tinker熱更新 怎麼支持360加固
the tinker bell /ðə ˈtɪŋkə bel/
F. 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{} 方法體前面，不然會報以下錯誤：
G. android熱修復與加固沖突嗎
針對Android平台，Dexposed支持函數級別的在線熱更新，例如對已經發布在應用市場上的宿主APK，當我們從crash統計平台上發現某個函數調用有bug，導致經常性crash，這時，可以在本地開發一個補丁APK，並發布到伺服器中，宿主APK下載這個補丁APK並集成後，就可以很容易修復這個crash。
Dexposed是基於久負盛名的開源Xposed框架實現的一個Android平台上功能強大的無侵入式運行時AOP框架。
Dexposed的AOP實現是完全非侵入式的，沒有使用任何註解處理器，編織器或者位元組碼重寫器。集成Dexposed框架很簡單，只需要在應用初始化階段載入一個很小的JNI庫就可以，這個載入操作已經封裝在DexposedBridge函數庫裡面的canDexposed函數中，源碼如下所示：
/**
* Check device if can run dexposed, and load libs auto.
*/
public synchronized static boolean canDexposed(Context context) {
if (!DeviceCheck.isDeviceSupport(context)) {
return false;
}
//load xposed lib for hook.
return loadDexposedLib(context);
}
private static boolean loadDexposedLib(Context context) {
// load xposed lib for hook.
try {
if (android.os.Build.VERSION.SDK_INT > 19){
System.loadLibrary("dexposed_l");
} else if (android.os.Build.VERSION.SDK_INT == 10
|| android.os.Build.VERSION.SDK_INT == 9 ||
android.os.Build.VERSION.SDK_INT > 14){
System.loadLibrary("dexposed");
}
return true;
} catch (Throwable e) {
return false;
}
}
Dexposed實現的hooking，不僅可以hook應用中的自定義函數，也可以hook應用中調用的Android框架的函數。Android開發者將從這一點得到很多好處，因為我們嚴重依賴於Android SDK的版本碎片化。