谢谢反馈，问题原因已经找到，可以试一下 1.4 最新的分支
是的，是的，就是它
看上面的回复
好的，非常感谢~
已经拉取了，也download-deps.py了，但是编译错误，log是
https://pan.baidu.com/s/1eS7i4z4
请问是什么原因呢？
这种自定义的方式都没有教程啊
是放到cocos creator下，还是工程下呢？我放工程下的cocos2dx了
检查一下搜索路径是否有生效，可以在 ScriptingCore 的 runScript / compileScript 那边下断点
@panda
我们现在热更新遇到的问题是，资源文件能成功更新，jsc文件没有生效，是什么原因呀
01-14 17:30:48.105: D/Cocos2dxDownloader(24993): onSuccess(i:200 headers:[Lcz.msebera.android.httpclient.Header;@431af778 file:/data/data/com.xxx.xxx/files/remote-asset/src/project.jsc.tmp
这里显示已经从远处服务器下载下来了
查看FileUtils搜索路径,也是远程路径优先,但是FileUtils好像找不到远程下载的jsc文件,然后去assets/src/project.jsc这里加载了jsc文件.
01-14 17:30:50.125: D/cocos2d-x debug info(24993): ScriptingCore::executeScript path: src/project.js
01-14 17:30:50.125: D/cocos2d-x debug info(24993): find FileUtils::fullPathForFilename:assets/src/project.jsc
01-14 17:30:50.135: D/cocos2d-x debug info(24993): ScriptingCore::compileScript byteCodePath : src/project.jsc
更新完有重启么 ？
需要去 FileUtils 里面去跟踪一下，看看为什么没有生效了
setAssetDonloadState这个操作其实会卡很久 比如现在project.manifest有 2m大，这次更新 只更新3个文件，那么要操作几千次setAssetDownloadState(Succ) ,这个会在一开始的时候卡很久，其实这个操作没有也没关系
最新的代码 合并的过程中我发现 tempManifest其实第二次打开就会被remote下载下来的manifest覆盖，还有每下载一个文件就保存tempManifest 会在更新过程中有明显的卡顿
嗯，这个刚刚已经调整了，设置了按照下载进度，每过 10% 就保存一次
有个情况帮忙分析下原因，比如说 版本号 1.1.0的客户端 自动更新到了 1.3.0，然后覆盖安装了一个1.2.0的安装包，最后打开 执行的代码逻辑还是 1.2.0的。如果删除原先的安装包，再安装1.2.0再自动 更新到1.3.0则正常 执行的是1.3.0的代码
有什么原因吗，跟搜索路径之类的相关吗
这个bug确实存在，因为每次ios替换安装的时候 writabelPath会改变 跟之前不一样 main.js 里使用保存的 searchpath就会出错
覆盖安装，不仅 writablePath 不同，旧安装包所引用的 writablePath 也会被清空，所以不论如何之前的本地下载版本都没有用了
这个在应用层是无法控制的，必须重新检查更新
我现在的改法 在 main.js里直接把 writablepath加到searchpath里去了
仔细看了这个，还是云里雾里