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的版本碎片化。