新人专享好礼凡未购买过小册的用户，均可领取三张 5 折新人专享券，购买小册时自动使用专享券，最高可节省 45 元。小册新人 5 折券最高可省 15 元小册新人 5 折券最高可省 15 元小册新人 5 折券最高可省 15 元注：专享券的使用期限在领券的七天内。一键领取购买小册时自动使用专享券前往小册首页本活动仅适用于小册新用户知道了与Android热更新方案Amigo的初次接触
主要记下引入的过程。
其实热更新最重要的是不需要重新安装apk，有的甚至不需要重启app，就可以更新代码或者资源文件。
我对比目前的几大主流的热更新方案，感觉Amigo是目前最适合我的。
nuwa/QZone
全平台支持
补丁包大小
gradle支持
tinker的功能非常强大，基本除了AndroidManifest.xml文件和tinker本身少数几个类之外，其他内容都能替换，包括布局、资源。不足之处在于其首次配置稍有点复杂，上手难度较AndFix稍高一些。
AndFix不可以修复Application的onCreate()，而且现在已经升级为SopHix，SopHix需要使用阿里的平台，每月免费5万台。目测SopHix的功能很强大，但是要接入阿里……
Robust是美团的方案，但是由于进行了代码侵入，对运行效率、方法数、包体积都有影响，文件方法数变多，企业级应用可能会涉及到65535的问题。
Amigo是下载一个完整的APK（所以包有点大，当然也可以做差分包），支持增加Activity，支持修改资源文件。
重点是接入方便。
在 project 的 build.gradle中：
buildscript {
repositories {
dependencies {
classpath 'com.android.tools.build:gradle:2.3.0'
classpath 'me.ele:amigo:0.6.8'
对了，目前Amigo不支持gradle3.0，我用的是2.3.0。
在module的 build.gradle
apply plugin: 'me.ele.amigo'
dependencies {
compile 'me.ele:amigo-lib:0.6.7'
disable false
autoDisableInInstantRunMode true
调用更新（新的apk已经在本地）
var file = File(Environment.getExternalStorageDirectory().path + File.separator + "test.apk")
if(file.exists()){
Amigo.workLater(this, file) {
toast("更新成功！")
val intent = packageManager.getLaunchIntentForPackage(packageName)
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
startActivity(intent)
android.os.Process.killProcess(android.os.Process.myPid())
最后是重启App。
我调用Amigo.work(context, patchApkFile);方法app不会自动重启，需要手动点击图标启动。
在Amigo的插件中，替换原有 Application的，所以Amigo支持修改Application。
Amigo替换了整个dex文件，所以保证了成功率。
加入掘金和开发者一起成长。发送简历到 hr@xitu.io，期待你的加入！分享03:11:06 UTC
安卓手机上已有一个旧版本的app，不进行卸载操作，这时候直接安装新版可以覆盖掉旧版，运行起来就是最新版本的，此时，也可以再覆盖掉新版安装回旧版本遇到的问题：如果旧版进行过热更新之后，就无法进行应用覆盖安装操作了，无论是用高版本还是低版本都无法覆盖热更之后的版本，（包名签名都是一致的），请问有人遇到过吗，如何解决
03:28:53 UTC
应该是把可写目录的已下载的旧的更新文件删掉
03:40:04 UTC
我是这样删除的jsb.fileUtils.removeDirectory(jsb.fileUtils.getWritablePath());
03:42:32 UTC
程序中是这样删除的
05:09:11 UTC
每次做整包更新的时候删除一下缓存目录
07:26:19 UTC
jsb.fileUtils.getWritablePath()是可写目录，别的游戏也会用到，你这是在给别的游戏挖坑啊，666
14:48:25 UTC
我也遇到了这个问题。你删除掉之后，可以了正确使用最新的更新文件嘛？
00:01:43 UTC
新版本需要强制清除热更新缓存目录。 这是很多人容易忽略的点。
00:03:35 UTC
getWritablePath 是基于自己游戏APP目录下的。 比如 android上就是 mnt/data/com.ooxx.ooxx/目录， IOS上就是 app/ewer-5432f-2rfedcv3..../ducuments/.大概是这个意思。
就是说，是基于自己目录下的， 不会影响到其它应用
14:59:10 UTC
就是要自己删一次？坑爹
05:30:14 UTC
05:31:14 UTC
判断有整包更新的时候删除一下就可以了
05:36:09 UTC
07:01:35 UTC
main.js 会去根据 local storage 获取之前热更新下来的目录，这样的话可能会造成安装好的新版本资源被覆盖的情况。
也不是一定要删除原来的，你也可以每个发布 app 包的主版本用不同的 local storage key 来保存本地路径，这样就不会冲突了
07:42:21 UTC
panda大大这个方法好，比较不容易出错，而且方便操作。
10:17:24 UTC
每一个IPA,APK，都有一个对应的版本号。。 写入到缓存目录中。 启动时，先检查这个版本号与缓存中的是否一致。 如果不一致。则删除缓存目录，再cc.game.restart
15:58:22 UTC
AssetManagerEx里其实是做了的，把包里的project.manifest传进去，跟缓存的比较，比缓存大会删掉全部缓存，HotUpdate里有一句this._am.loadLocalManifest(this.manifestUrl);
自行提前调用
bool localNewer = _localManifest-&versionGreater(cachedManifest, _versionCompareHandle);
if (localNewer)
// Recreate storage, to empty the content
fileUtils-&removeDirectory(storagePath);
fileUtils-&createDirectory(storagePath);
CC_SAFE_RELEASE(cachedManifest);如何评价苹果将在 6 月 12 日禁止「热更新」？
百姓大小事，一呼百应！
如何评价苹果将在 6 月 12 日禁止「热更新」？
如何评价苹果将在 6 月 12 日禁止「热更新」？
更新：如何看待截止
App Store 下架 2 万中国及其他国家 App？问题相关：苹果全面禁止热更新：6月12日前不调整App将被下架！苹果严禁应用热更新 王者荣耀、12306等受影响
很多人都在猜测，苹果要对热更新动刀子了，甚至还传出了“王者荣耀、12306 等大批使用热更新机制的游戏和应用不执行就会被下架”的传闻。但事实真的是这样吗？先做一个科普：什么是热更新，为何要热更新？热更新简而言之，服务器在不关闭的情况下，用户打开应用即可下载安装更新的代码运行，这是目前移动游戏更新的主流方式之一。举个例子，主流的游戏都会根据不同的节假日做大型的活动运营，这种运营基本都是即时性的，热更新是满足这种需求最有效的方式之一。而如果通过提交 App Store 审核的方式下发更新，考虑到 Android 和 iOS 同步，大型游戏可能需要 1 个月甚至更长的审核周期，这一点苹果也应该心知肚明。再说全文重点：热更新并未被禁止！热更新并未被禁止！热更新并未被禁止！接着来看看苹果最新通知是怎么说的：以下是通知原文：Dear Developer,
In March of this year we notified you that your app contains code designed explicitly with the capability to change your app’s behavior or functionality after App Store Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. We requested that you remove any code, frameworks, or SDKs that fall in line with the functionality described above before submitting the next update for your app for review.
As of this message, we have not received a compliant update for your app.
To ensure there is no interruption of the availability of your app, please submit an update by June 12th, 2017. If we do not receive an update by that date, your app may be removed from the App Store.以下是对应的翻译：亲爱的开发者
在今年 3 月我们已经发过消息提醒，你的 App 内有一些热更新（即绕过 App Store 审核的更新）的代码，这些代码违反了苹果开发者协议的 3.3.2 条款与 App Store 审核指南的 2.5.2 条款。我们曾要求你移除所有相关代码、框架或 SDK，并且重新提交版本。
在这条消息推送时，我们还没有收到过你进行过相应的调整。
为了确保你的 App 在 App Store 内的正常运行，请在
之前提交一次更新。如果不做调整的话，你的 App 可能会从 App Store 下架。围观苹果热更新政策的正确姿势苹果官方给开发者发出的通知，关键就在这句话：我们曾要求你移除所有相关代码、框架或 SDK，并且重新提交版本。我们从一位匿名开发者那里找到了这样的答案：不符合 2.5.2 条款， App 包含热更新代码，特别提到了 dlopen（），dlsym（），respondingToSelector:, performSelector:, method_exchangeImplementations（）这些函数，但是苹果没有禁用热更新，只是禁用了几种热更新框架和技术，而 JSPatch 等苹果不让使用的原因是，能够直接修改代码，可以修改到功能，这样其实绕过了苹果的审核，其他的苹果禁止使用的框架也是如此。关于应对措施，这位开发者的方案是这样的：后期提交的版本，要么没有热更新，要么只能用 React Native 框架热更新，其他如 JSPatch、RolloutIO、TriggerIO、WAX(Lua) 等都不能用。也就是说，要求移除相关代码、框架和 SDK 只是为了规范开发者的代码，这会冲击到部分热更新解决方案，但不等于封杀热更新，合理采用热更新机制的产品，不存在也没理由被下架。这一点，我们从“如何看待苹果禁止 JSPatch 等 iOS APP 热更新方案？”这个话题中，一位来自白鹭时代的开发者 @王泽 的回答中也找到了相应的答案。截止目前为止，我们也没有收到使用白鹭引擎打包游戏的开发者收到了苹果警告邮件的消息。对于那些受到警告邮件的开发者，王泽的解释如下：目前为止收到警告邮件的开发者绝大部分使用了 JS-Patch 或 Rollout 类库，剩下未直接使用这些类库的开发者，目前初步估计很可能是在集成的第三方SDK 中使用了上述框架。而未采用上述框架的热更新技术，目前为止并未收到影响。而绝大部分游戏引擎由于并没有调用这些类库，也自然没有受到影响。所以苹果确实对于采用热更新机制提出了严格的要求，但如果解读为禁用封杀热更新，并不准确。苹果为何要这么做？苹果禁止滥用热更新机制，和 iOS 封闭的做法本质上是一致的，为了应用生态的安全可控和体验的一致性，毕竟 App Store 堪称是苹果最大的现金牛之一。数据显示，到目前为止 App Store 给开发者的收入分成高达 700 亿美元，去年就达到了 200 亿美元。市场研究公司 Macquarie 的分析师 Ben Schachter 在报告中这样写道，“ App Store 是有史以来最好的商业模式之一，苹果的投资者不需要依赖于苹果的创新来驱动该模式的前进。”任何一个小细节都有可能搞砸 App Store 这块大蛋糕，尤其是采用 JSPatch 热更新这种苹果无法把控的应用更新机制。据了解，今年二月份网络安全公司 Fire Eye 发现 JSPatch 存在安全漏洞，一旦黑客发现和利用这个后门，她们就是能访问到设备中的照片、麦克风和剪贴板数据和其他涉及个人隐私的功效，App Store 中有 1220 款应用程序可能会受此影响。所以，苹果有必要对采用这类机制的开发者提出了“移除所有相关代码、框架或 SDK，并且重新提交版本”的要求。总结下来，苹果的禁止了部分热更新的函数、框架和代码，但未禁用热更新机制，所以那些关于王者荣耀、12306 等产品被下架的内容，可能是对苹果开发者条款的误读，只能说你被骗了。by 苏扬
不问是不是，媒体误导什么就信什么，而且挺多回答也都喜欢使用阴谋论的解释，这不是健康的思考问题的方法。什么叫『全面』？挺多媒体在相关新闻都加了这个词，明显的有失偏颇，而且媒体基本都没有给出相关的技术解释，反而去误导说王者荣耀可能受到影响，吃瓜群众也就都信以为真。什么是热更新？苹果所指的热更新这里有讨论： 如何看待苹果禁止 JSPatch 等 iOS APP 热更新方案？当然，条款里有说明不可以下载可执行代码，解释性代码也必须把代码打包在本地，这个限制其实挺严格的，但具体实施起来感觉还没有那么严格，毕竟应用去请求 LUA 脚本并执行之类的我觉得苹果审查是比较难看出来的，此前警告的也都以原生代码的热更新为主。有没有例外？苹果官方是有明确说明 JavascriptCore 可以正常使用，但前提是代码没有改变应用的主要特性与功能。这就意味着游戏的话微调数据或者逻辑是没有问题的，但如果添加或者改变玩法的话就必须到 AppStore 更新了。这里的边界其实有点模糊，比如王者荣耀添加或者重做一个英雄，算不算改变主要特性？这些都得再看。原因是什么？是苹果要收紧审核么？封杀了 jspatch 就会封杀游戏热更新 / RN 么？这些阴谋论明显是想多了。官方给出来的解释是避免中间人攻击，就这么简单，其他的都只是附带的目的或者后果。应该感到着急么？不见得。首先即使苹果再强势地禁止热更新，也不可能在审核阶段将这类行为都监控到，而且如果没有修改到核心应用逻辑或者功能的话，其实都是比较难发现其中有热更新行为的；其次，对热更新有刚性需求的情况毕竟不多，深思熟虑之后上架 AppStore 并在上面写好 Change Log 知会给用户，其实大多数情况不失为不错的选择；再次，带着镣铐跳舞这在任何行业都再正常不过，有点限制算什么呀，还得看是否能带来更好的环境以及收益；最后，对热更新有刚性需求的大公司多得去了，他们自然会去跟苹果谈判妥协得到两全的方案，不用担心这类功能被『全面』禁止。
百姓网 Logo
百姓网 熊掌号
简单，快速，搞得定！
七彩虹是该电脑主板的品牌，以下是解决方法：应该是系统不行了，先按F8，调出启动菜单，用最后一次正确配置和安全模式试试，...
谢谢邀请。已经回答过很多次类似问题，看到题主说这么多，还是愿意简略回答下。在五术中，相术入门容易，想深入穷究人生祸福...
这款洗面奶，用起来也很方便的，用温水湿润脸部，挤上适当洗面奶，在手上打出沫在往脸上涂，不要直接抹在脸上。洗完以后用凉...
大几千块钱吧，现在家电市场的价格都还是比较透明，哪里买的都差不多价
平台上的资金回款时间还是 蛮快的，安全什么的都挺好，建议去试试看。
&2018 百姓网股份有限公司 客服电话：400-036-3650 或 021-（周一至周日 9:00～18:00）
沪ICP备号 沪ICP证B2- 沪公网安备16号炸窝了，苹果禁止使用热更新
招聘信息：
今天一早，不少iOS开发群都炸窝了，原因是部分iOS开发者收到了苹果的警告邮件：有开发者质疑可能是项目中使用了JSPatch、weex以及ReactNative等热更新技术。对于修复bug提交审核的开发者来说，热更新技术可以帮开发者避免长时间的审核等待以及多次被拒造成的成本开销。但也给黑客留了后门，也就违反了苹果的安全和隐私政策。不过这次苹果只是对使用热更新的应用进行了警告，并没有开发者反应产品因此问题被下架。对此，开发者表示：舞小月：苹果注重的就是流畅性和用户体验，混编做的东西肯定没有native的流畅，这就违背了苹果本来的意愿，被禁也是正常的，而且苹果自己的蛋糕为何要分给竞争对手？以前没混编的时候你该怎么做不还是做了，现在没有，不代表以后没有，就像之前没有混编，后来有了混编。新的框架苹果自然也会去完善，苹果既然做了这个决定，他肯定会优化自己的东西。Gilbertat：苹果爸爸会不会在自己的生态中搞死js啊luohui8891：我们也是昨天收到的，目前没有什么对策。我们的APP只是用JSPatch做热修复，并不修改应用的功能行为等（但我觉得Apple并不care这个）。lsllsllsl：没用RN没用JSPatch，同样收到警告。luohui8891：@tcathy 根据邮件里说是你下次提交前请去掉这样远程下载代码运行的机制。所以应该就是下个版本如果不删除就rejectLoooren：早上收到邮件，itunesconnect站内信，电话通知....用到了weexxiaofuyesnew：昨天晚上微软发布了Visual Studio 2017，自带基于React Native的iOS开发功能。鉴于微软这两年来开源的力度，发布这一功能似乎是在抢占开发者的市场，基于vs2017，在非苹果上开发ios应用更容易了。所以，苹果在这个节骨眼发出这个警告邮件，就有点威胁现有开发者的意思。暗地里想跟微软互怼。对于那些已经在学习RN、weex、JSPatch的同学来说，这是个悲惨的故事从苹果的角度看，禁止应用使用热更新技术更多是为了保护用户隐私、数据安全以及其全力打造的生态圈。对于用户来说，出于安全起见，应谨慎授予应用权限；对于开发者来说，为了审核以及长远的用户体验考虑，不要轻易触碰苹果拉的那条红线。以上内容来源于，
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量4556点击量2428点击量2074点击量2043点击量1885点击量1809点击量1738点击量1727点击量1654
&2018 Chukong Technologies,Inc.
京公网安备89你的位置： >
> Android 热更新热升级访问权限和即时生效问题
取消了相关框架的热更，在
社区专家群引起了大量的讨论。大家纷纷发表自己的看法和技术解决方案。本文不是 IOS 相关的问题的解决方案，主要围绕
的热更新进行学习！
综合前面的几篇文章《》、《》、《》。
看了前面的几篇文章，你可能会有疑惑：我们只是替换了ArtMethod的内容，但新替换的方法的所属类，和原先方法的所属类，是不同的类，被替换的方法有权限访问这个类的其他private方法吗？
以这段简单的代码为例
public class Demo{
private void func(){}
Demo构造函数调用私有函数func所对应的Dex Code和Native Code为
这个调用逻辑和之前Activity的例子大同小异，需要注意的地方是，在构造函数调用同一个类下的私有方法func时，没有做任何权限检查。也就是说，这时即使我把func方法的偷梁换柱，也能直接跳过去正常执行而不会报错。
可以推测，在dex2oat生成AOT机器码时是有做一些检查和优化的，由于在dex2oat编译机器码时确认了两个方法同属一个类，所以机器码中就不存在权限检查的相关代码。
同包名下的权限问题
但是，并非所有方法都可以这么顺利地进行访问的。我们发现补丁中的类在访问同包名下的类时，会报出访问权限异常：
虽然com.patch.demo.BaseBug和com.patch.demo.MyClass是同一个包com.patch.demo下面的，但是由于我们替换了com.patch.demo.BaseBug.test，而这个替换了的BaseBug.test是从补丁包的Classloader加载的，与原先的base包就不是同一个Classloader了，这样就导致两个类无法被判别为同包名。具体的校验逻辑是在虚拟机代码的Class::IsInSamePackage中：
关键点在于，Class loaders must match这行注释。
知道了原因就好解决了，我们只要设置新类的Classloader为原来类就可以了。而这一步同样不需要在JNI层构造底层的结构，只需要通过反射进行设置。这样仍旧能够保证良好的兼容性。
实现代码如下：
这样就解决了同包名下的访问权限问题。
反射调用非静态方法产生的问题
当一个非静态方法被热替换后，在反射调用这个方法时，会抛出异常。
比如下面这个例子：
//BaseBug.test方法已经被热替换了。
BaseBug bb = new BaseBug();
Method testMeth = BaseBug.class.getDeclaredMethod(&test&);
testMeth.invoke(bb);
invoke的时候就会报：
这里面，expected receiver的BaseBug，和got到的BaseBug，虽然都叫com.patch.demo.BaseBug，但却是不同的类。
前者是被热替换的方法所属的类，由于我们把它的ArtMethod的declaring_class_替换了，因此就是新的补丁类。而后者作为被调用的实例对象bb的所属类，是原有的BaseBug。两者是不同的。
在反射invoke这个方法时，在底层会调用到InvokeMethod：
这里面会调用VerifyObjectIsClass函数做验证。
o表示Method.invoke传入的第一个参数，也就是作用的对象。
c表示ArtMethod所属的Class。
因此，只有o是c的一个实例才能够通过验证，才能继续执行后面的反射调用流程。
由此可知，这种热替换方式所替换的非静态方法，在进行反射调用时，由于VerifyObjectIsClass时旧类和新类不匹配，就会导致校验不通过，从而抛出上面那个异常。
那为什么方法是非静态才有这个问题呢？因为如果是静态方法，是在类的级别直接进行调用的，就不需要接收对象实例作为参数。所以就没有这方面的检查了。
对于这种反射调用非静态方法的问题，我们会采用另一种冷启动机制对付，本文在最后会说明如何解决。
即时生效所带来的限制
除了反射的问题，像本方案以及Andfix这样直接在运行期修改底层结构的热修复，都存在着一个限制，那就是只能支持方法的替换。而对于补丁类里面存在方法增加和减少，以及成员字段的增加和减少的情况，都是不适用的。
原因是这样的，一旦补丁类中出现了方法的增加和减少，就会导致这个类以及整个Dex的方法数的变化。方法数的变化伴随着方法索引的变化，这样在访问方法时就无法正常地索引到正确的方法了。
而如果字段发生了增加和减少，和方法变化的情况一样，所有字段的索引都会发生变化。并且更严重的问题是，如果在程序运行中间某个类突然增加了一个字段，那么对于原先已经产生的这个类的实例，它们还是原来的结构，这是无法改变的。而新方法使用到这些老的实例对象时，访问新增字段就会产生不可预期的结果。
不过新增一个完整的、原先包里面不存在的新类是可以的，这个不受限制。
总之，只有两种情况是不适用的：
引起原有了类中发生结构变化的修改
修复了的非静态方法会被反射调用，而对于其他情况，这种方式的热修复都可以任意使用。
虽然有着一些使用限制，但一旦满足使用条件，这种热修复方式是十分出众的，它补丁小，加载迅速，能够实时生效无需重新启动app，并且具有着完美的设备兼容性。对于较小程度的修复再适合不过了。
本修复方案将最先在阿里Hotfix最新版本(Sophix)上应用，由手机淘宝技术团队与阿里云联合发布。
Sophix提供了一套更加完美的客户端服务端一体的热更新方案。针对小修改可以采用本文这种即时生效的热修复，并且可以结合资源修复，做到资源和代码的即时生效。
而如果触及了本文提到的热替换使用限制，对于比较大的代码改动以及被修复方法反射调用情况，Sophix也提供了另一种完整代码修复机制，不过是需要app重新冷启动，来发挥其更加完善的修复及更新功能。从而可以做到无感知的应用更新。
并且Sophix做到了图形界面一键打包、加密传输、签名校验和服务端控制发布与灰度功能，让你用最少的时间实现最强大可靠的全方位热更新。
一张表格来说明一下各个版本热修复的差别：
Andfix开源版本
阿里Hotfix 1.X
阿里Hotfix最新版(Sophix)
支持，除部分情况[0]
支持，除部分情况
方法增加减少
以冷启动方式支持[1]
方法反射调用
只支持静态方法
只支持静态方法
以冷启动方式支持
视情况支持[2]
Android版本
支持2.3~7.0
支持2.3~6.0
全部支持包含7.0以上
大部分支持[3]
大部分支持
加密传输及签名校验
加密传输及签名校验
低，几乎无损耗
低，几乎无损耗
低，仅冷启动情况下有些损耗
繁琐，命令行操作
繁琐，命令行操作
便捷，图形化界面
不大，仅变动的类
小，仅变动的方法
不大，仅变动的资源和代码[4]
服务端支持
支持服务端控制[5]
支持服务端控制
部分情况指的是构造方法、参数数目大于8或者参数包括long,double,float基本类型的方法。
冷启动方式，指的是需要重启app在下次启动时才能生效。
对于Andfix及Hotfix 1.X能够支持的代码变动情况，都能做到即时生效。而对于Andfix及Hotfix 1.X不支持的代码变动情况，会走冷启动方式，此时就无法做到即时生效。
Hotfix 1.X已经支持绝大部分主流手机，只是在X86设备以及修改了虚拟机底层结构的ROM上不支持。
由于支持了资源和库，如果有这些方面的更新，就会导致的补丁变大一些，这个是很正常的。并且由于只包含差异的部分，所以补丁已经是最大程度的小了。
提供服务端的补丁发布和停发、版本控制和灰度功能，存储开发者上传的补丁包。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！本文原文出处：： &
相关文章推荐