前言

由于匹夫本人是做游戏开发工作的,所以平时也会加一些玩家的群。而一些困扰玩家的问题,同样也困扰着我们这些手机游戏开发者。这不最近匹夫看自己加的一些群,常常会有人问为啥这个游戏一更新就要重新下载,而不能游戏内更新呢?作为游戏开发者,或者说Unity3D程序猿,我们都清楚Unity3D不支持热更新,甚至于在IOS平台上生成新的代码都会导致游戏报错崩溃(匹夫之所以在此处强调生成新的代码这几个字,就是提醒各位不要混淆Reflection.Emit和反射)。但我们是否和普通的玩家一样,看到的仅仅是“不能”的现象,而不了解“不能”背后的原因呢?那今天小匹夫就抛砖引玉,写写自己对这个问题的想法~~聊聊到底是谁偷了玩家的热更新。

从一个常见的报错说起

不知道各位看官中的U3D程序猿在开发IOS版本的时候是否也曾经碰到过这样的报错:

ExecutionEngineException: Attempting to JIT compile method 'XXXX' while running with --aot-only.

这个报错的意思很明确,说的也很具体,翻译成中文的大意就是在使用--aot-only这个选项的前提下,又试图去使用JIT编译器编译XXX方法。

那么不知道是否会有看官觉得这个问题兴许是程序跑在IOS平台上时,不小心犯了IOS的忌讳,使用了JIT(假设此时我们还不知道为何使用JIT是IOS的忌讳)去动态编译代码导致的IOS的报错呢?

答案是否定的。

又或者更进一步,看到“ExecutionEngineException”,似乎和IOS平台的异常没什么太大的关联,那就把责任定位在Unity3D的引擎上好了。一定是游戏引擎此时不支持JIT编译了。

也不全对,不过离真相很近了。

各位想想,能涉及到编译的被怀疑的对象还能有谁呢?

好了,不卖关子了。这个异常其实是Mono的异常。换言之,Unity3D使用了Mono来编译,所以Unity3D的嫌疑被排除。而IOS并没有因为生成或者运行动态生成的代码而报错,换言之这个异常发生在触发IOS异常之前,所以说Mono在IOS平台上进行JIT编译之前就先一步让程序崩溃了。

说到这里,就绕不过Mono是如何编译代码这个话题了。如果我们去Mono的托管页面看它的源码,就可以简单对它的目录结构做一个简单的分析,匹夫就简单总结一下Mono编译部分的目录结构:

docs 关于mono运行时的文档,在这里你可以看到例如编译的说明文档,还有小匹夫很看重的Mono运行时的API列表
data 一些Mono运行时的配置文件
mono Mono运行时的核心,也是本文关于Mono部分的焦点,简单介绍一下它的几个比较重要的子目录
    metadata 实现了处理metadata的逻辑
    mini JIT编译器(重点)
    dis 可执行CIL代码的反编译器
    cil CIL指令的XML配置,在这里你可以看到CIL的指令都是什么
    arch 不同体系结构的特定部分。
mcs C#源码编译器(C#---->CIL)
  mcs    
    mcs 源码编译器
    jay 分析程序的生成程序

好啦,具体到咱们要聊的JIT编译,我们需要看的就是mono目录下的mini文件夹中的文件了,这个文件夹中的.c文件们实现了JIT编译。

这个目录的结构截个图都截不全,因为文件太多:

不过这里小匹夫想来一个倒叙,也就是先直接定位这个报错“ExecutionEngineException: Attempting to JIT compile method 'XXXX' while running with --aot-only.”的位置,然后再探明它究竟是如何被触发的。

这样,我们就来到了mono的JIT编译器目录mini下的mini.c文件。这里就是JIT的逻辑实现。而那段报错呢?在mini.c文件中是这样处理的:

if (mono_aot_only) {
    char *fullname = mono_method_full_name (method, TRUE);
    char *msg = g_strdup_printf ("Attempting to JIT compile method '%s' while     running with --aot-only. See http://docs.xamarin.com/ios/about/limitations for more information.\n", fullname);
    *jit_ex = mono_get_exception_execution_engine (msg);
    g_free (fullname);
    g_free (msg);
    return NULL;
}

mono_aot_only?没错,只要我们设定mono的编译模式为full-aot(比如打IOS安装包的时候),则在运行时试图使用JIT编译时,mono自身的JIT编译器就会禁止这种行为进而报告这个异常。JIT编译的过程根本还没开始,就被自己扼杀了。

那么JIT究竟是什么洪水猛兽?为何IOS这么忌讳它呢?那就不得不聊聊JIT本尊了。

美丽的JIT

因何美丽

名如其特点,JIT——just in time,即时编译。

什么?这就是匹夫你要告诉大家伙的?这不是人人都知道的嘛?而且网上一搜也全都是JIT=just in time了事。好吧好吧,匹夫知错啦。那就认真的定义一下JIT:

一个程序在它运行的时候创建并且运行了全新的代码,而并非那些最初作为这个程序的一部分保存在硬盘上的固有的代码。就叫JIT。

几个点:

  1. 程序需要运行
  2. 生成的代码是新的代码,并非作为原始程序的一部分被存在磁盘上的那些代码
  3. 不光生成代码,还要运行。

需要提醒的是第三点,也就是JIT不光是生成新的代码,它还会运行新生成的代码。之后我们会就这个话题展开。不过在之前匹夫还是要解释一下,为何称JIT是美丽的。

举个例子:

比如你某一天突然穿越成为了一个优秀的学者(好吧好吧,这个貌似不是必须要穿越),现在要去一个语言不通的国家做一系列讲座。面对语言不通的窘境,如何才不出丑呢?

匹夫有三条方案:

  1. 在家的时候雇人把所有的讲稿全部翻译一遍。这是最省事的做法,但却缺乏灵活性。比如临时有更好的话题或者点子,也只能恨自己没有好好学外语了。
  2. 雇一个翻译和你一起出发,你说啥他就翻译成啥。这样就不存在灵活性的问题,因为完全是同步的。不过缺点同样明显,翻译要翻译很多话,包括你重复说的话。所以需要的时间要远远高于方案1。
  3. 雇一个翻译和你一起出发,但不是你说啥他就翻译啥,而是记录翻译过的话,遇到曾经翻译过的就不会再翻译了。你自己就可以根据之前的翻译记录和别人交流了。

看完这三条方案,各位看官心中更喜欢哪个呢?

匹夫个人的答案是方案3,因为这便是JIT的道。所以说JIT的美丽,就在于即保留了对代码优化的灵活性,也兼具对热点代码进行重复利用的功能。

模拟一下JIT的过程

JIT这么好,那它是如何实现既生成新代码,又能运行新代码的呢?

编译器如何生成代码很多文章都有涉及,匹夫就不多在此着墨了。下面我就着重和各位聊聊,如何运行新生成的代码。

首先我们要知道生成的所谓机器码到底是神马东西。一行看上去只是处理几个数字的代码,蕴含着的就是机器码。

unsigned , 0x};

macCode对应的汇编指令就是:

mov    (%rdi),%rax

其实可以看出机器码就是比特流,所以将它加载进内存并不困难。而问题是应该如何执行。

好啦。下面我们就模拟一下执行新生成的机器码的过程。假设JIT已经为我们编译出了新的机器码,是一个求和函数的机器码:

long add(long num) {
  ;
}

, 0xc0, 0x,
0xc3 

首先,动态的在内存上创建函数之前,我们需要在内存上分配空间。具体到模拟动态创建函数,其实就是将对应的机器码映射到内存空间中。这里我们使用c语言做实验,利用mmap函数来实现这一点。

头文件 #include <unistd.h>    #include <sys/mman.h>
定义函数 void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offsize)
函数说明 mmap()用来将某个文件内容映射到内存中,对该内存区域的存取即是直接对该文件内容的读写。

因为我们想要把已经是比特流的“求和函数”在内存中创建出来,同时还要运行它。所以mmap有几个参数需要注意一下。

代表映射区域的保护方式,有下列组合:

PROT_EXEC  映射区域可被执行;
    PROT_READ  映射区域可被读取;
    PROT_WRITE  映射区域可被写入;

#include<stdio.h>                                                                                            #include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>

//分配内存
void* create_space(size_t size) {
    , size,
            PROT_READ | PROT_WRITE | PROT_EXEC,
            MAP_PRIVATE | MAP_ANON,
            -, );
    return ptr;
}

这样我们就获得了一块分配给我们存放代码的空间。下一步就是实现一个方法将机器码,也就是比特流拷贝到分配给我们的那块空间上去。使用memcpy即可。

//在内存中创建函数
void copy_code_2_space(unsigned char* m) {
    unsigned char macCode[] = {
        0x, 0x, 0xc0, 0x,
        c3
    };
    memcpy(m, macCode, sizeof(macCode));
}

然后我们在写一个main函数来处理整个逻辑:

#include<stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>

//分配内存
void* create_space(size_t size) {
    , size,
            PROT_READ | PROT_WRITE | PROT_EXEC,
            MAP_PRIVATE | MAP_ANON,
            -, );
    return ptr;
}

//在内存中创建函数
void copy_code_2_space(unsigned char* addr) {
    unsigned char macCode[] = {
        0x, 0x, 0xc0, 0x,
        0xc3
    };
    memcpy(addr, macCode, sizeof(macCode));
}

//main 声明一个函数指针TestFun用来指向我们的求和函数在内存中的地址
int main(int argc, char** argv) {
    ;
    typedef long (*TestFun)(long);
    void* addr = create_space(SIZE);
    copy_code_2_space(addr);
    TestFun test = addr;
    );
    printf("result = %d\n", result);
    ;
}

编译并且运行看一下结果:

//编译
gcc testFun.c
//运行
./a. 

留给我们的难题

OK,到此为止,一切都很顺利。这个例子模拟了动态代码在内存上的生成,和之后的运行。似乎没有什么问题呀?可不知道各位是否忽略了一个前提?那就是我们为这块区域设置的保护模式可是:可读,可写,可执行的啊!如果没有内存可读写可执行的权限,我们的实验还能成功吗?

让我们把create_space函数中的“可执行”PROT_EXEC权限去掉,看看结果会是怎样的一番景象。

修改代码,同时将刚才生成的可执行文件a.out删除重新生成运行。

rm a.out
vim testFun.c
gcc testFun.c
./a.

结果。。。报错了!

小结论

所以,IOS并非把JIT禁止了。或者换个句式讲,IOS封了内存(或者堆)的可执行权限,相当于变相的封锁了JIT这种编译方式。原因呢?且听下回分解~~~~~谁偷了我的热更新?IOS和安全漏洞的赌注

如果各位看官觉得文章写得还好,那么就容小匹夫跪求各位给点个“推荐”,谢啦~

装模作样的声明一下:本博文章若非特殊注明皆为原创,若需转载请保留原文链接http://www.cnblogs.com/murongxiaopifu/p/4278947.html )及作者信息慕容小匹夫

谁偷了我的热更新?Mono,JIT,iOS的更多相关文章

  1. iOS第三方类库JSPatch(热更新)

    ---------------------------------------------------------------------------------------------------- ...

  2. Unity3D 热更新方案(集合各位专家的汇总)

    http://blog.csdn.net/guofeng526/article/details/52662994 热更新”这个词,在Unity3D的应用下,是有些语义错误的,但是作为大家都熟知的一项技 ...

  3. iOS热更新-8种实现方式

    一.JSPatch 热更新时,从服务器拉去js脚本.理论上可以修改和新建所有的模块,但是不建议这样做. 建议 用来做紧急的小需求和 修复严重的线上bug. 二.lua脚本 比如: wax.热更新时,从 ...

  4. IOS热更新-JSPatch实现原理+Patch现场恢复

    关于HotfixPatch 在IOS开发领域,由于Apple严格的审核标准和低效率,IOS应用的发版速度极慢,稍微大型的app发版基本上都在一个月以上,所以代码热更新(HotfixPatch)对于IO ...

  5. ios WaxPatch热更新原理

    以下是引用他人文章内容: 为什么需要 WaxPatch 很多情况下,已经在 AppStore 上线的应用需要紧急缺陷修复,此时便需要使用某些技术手段,使应用程序能够动态下载补丁,进行缺陷修复. 什么是 ...

  6. ios app 实现热更新(无需发新版本实现app添加新功能)

    目前能够实现热更新的方法,总结起来有以下三种 1. 使用FaceBook 的开源框架 reactive native,使用js写原生的iOS应用 ios app可以在运行时从服务器拉取最新的js文件到 ...

  7. iOS热更新技术被苹果官方警告?涉及到RN、Weex、JSPatch!!!

    今天一早,不少iOS开发群都炸窝了,原因是部分iOS开发者收到了苹果的警告邮件: 有开发者质疑可能是项目中使用了JSPatch.weex以及ReactNative等热更新技术.对于修复bug提交审核的 ...

  8. React Native热更新(iOS)-Pushy

    React Native的出现,使的开发iOS代码出现了更便捷的方式.由于RN是使用脚本语言编写的,实现了"解释执行"的方式,而这种执行方式的修改只需替换脚步即可,不需要重新发布程 ...

  9. Unity3D逻辑热更新,第二代舒爽解决方案,L#使用简介

    热更新 天下武功,无坚不破,唯快不破 热更新就是为了更快的把内容推到用户手中. 之前,我设计了C#Light,经过半年多的持续修补,勉强可用,磕磕绊绊.感谢那些,试过,骂过,用过的朋友,在你们的陪伴下 ...

随机推荐

  1. Android Gradle Build Error:Some file crunching failed, see logs for details解决办法

    转载请标明出处: http://www.cnblogs.com/why168888/p/5925756.html 本文出自:[Edwin博客园] 错误日志:Error:java.lang.Runtim ...

  2. PMO、P3O

    中国的大中型企业最近几年纷纷设立了项目管理办公室PMO,普遍关注如何发挥PMO最大的价值.而P3O指南描述了一个高阶的组织模型和机制,构建组织内部所有关于变革的决策支持与交付的结构及机制,允许永久的和 ...

  3. JavaScript RegExp 对象(来自w3school)

    RegExp 对象用于规定在文本中检索的内容. 什么是 RegExp? RegExp 是正则表达式的缩写. 当您检索某个文本时,可以使用一种模式来描述要检索的内容.RegExp 就是这种模式. 简单的 ...

  4. jQuery - 动态创建iframe并加载页面

    <html> <head> <script language="JavaScript" src="jquery-1.11.1.min.js& ...

  5. npoi与memcached中的ICSharpCode.SharpZipLib版本冲突的解决方案

    项目中一直使用NPOI与memcached,一直相安无事,但是最近升级了npoi到最新版本,发生了ICSharpCode.SharpZipLib的版本冲突问题. 因为此前一直使用的是NPOI的1.x的 ...

  6. storyboard中xib文件不加载问题

    今天在用Xcode6自定义视图控制器时附带了一个XIB文件,然后把自定义的类绑定到storyboard的ViewController,如图所示  , 发现RootViewController对应的xi ...

  7. android 自定义进度条颜色

    android 自定义进度条颜色 先看图 基于产品经理各种自定义需求,经过查阅了解,下面是自己对Android自定义进度条的学习过程!   这个没法了只能看源码了,还好下载了源码, sources\b ...

  8. Delphi的基本函数

    Delphi的基本函数 函数由一句或多句代码组成,可以实现某个特定的功能.使用函数可以使代码更加易读.易懂,加快编程速度及减少重复代码.过程与函数类似,过程与函数最重要的区别在于,过程没有返回值,而函 ...

  9. Spring中RedirectAttributes对象重定向传参

    Spring3中的FlashAttribute 为 了防止用户刷新重复提交,save操作之后一般会redirect到另一个页面,同时带点操作成功的提示信息.因为是Redirect,Request里 的 ...

  10. Android 第三方应用接入微信平台(2)

    微信平台开放后倒是挺火的,许多第三方应用都想试下,毕竟可以利用微信 建立起来的关系链来拓展自己的应用还是挺不错的,可以节约很多在社交方 面的开销,我最近由于实习需要也在研究这个东西,不过发现网上的相关 ...