http://www.androidin.net/bbs/android-109142-1-1.html
2.2快来了，CM 5.0.7系列也越来越火，我们又更加频繁的接触了一个名词——JIT，但是到底什么叫JIT，很多人搞不清楚，以下解释转自百度和维基：
------------------------------我是百度百科分割线----------------------------------------------------
JAVA领域的JIT
JIT Compiler(Just-in-time Compiler) 即时编译
最早的Java建置方案是由一套转译程式（interpreter），将每个Java指令都转译成对等的微处理器指令，并根据转译后的指令先后次序依序执行，由于一个Java指令可能被转译成十几或数十几个对等的微处理器指令，这种模式执行的速度相当缓慢。
针对这个问题，业界首先开发出JIT（just in time）编译器。当Java执行runtime环境时，每遇到一个新的类别（class：类别是Java程式中的功能群组），类别是Java程式中的功能群组－JIT编译器在此时就会针对这个类别进行编译（compile）作业。经过编译后的程式，被优化成相当精简的原生型指令码（nativecode），这种程式的执行速度相当快。花费少许的编译时间来节省稍后相当长的执行时间，JIT这种设计的确增加不少效率，但是它并未达到最顶尖的效能，因为某些极少执行到的Java指令在编译时所额外花费的时间可能比转译器在执行时的时间还长，针对这些指令而言，整体花费的时间并没有减少。
基于对JIT的经验，业界发展出动态编译器（dynamic compiler），动态编译器仅针对较常被执行的程式码进行编译，其余部分仍使用转译程式来执行。也就是说，动态编译器会研判是否要编译每个类别。动态编译器拥有两项利器：一是转译器，另一则是JIT，它透过智慧机制针对每个类别进行分析，然后决定使用这两种利器的哪一种来达到最佳化的效果。动态编译器针对程式的特性或者是让程式执行几个循环，再根据结果决定是否编译这段程式码。这个决定不见得绝对正确，但从统计数字来看，这个判断的机制正确的机会相当高。事实上，动态编译器会根据「历史资料」做决策，所以程式执行的时间愈长，判断正确的机率就愈高。以整个结果来看，动态编译器产生的程式码执行的速度超越以前的JIT技术，平均速度可提高至50%。
-----------------------我是维基分割线-------------------------------
即时编译（Just-in-time Compilation，JIT），又称动态转译（Dynamic Translation），是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。
在编译为字节码的系统如 Limb 编程语言，Smalltalk，UCSD P-System, Perl，GNU CLISP，和 Java 的早期版本中， 源代码被翻译为一种中间表示即字节码。 字节码不是任何特定计算机的机器码， 它可以在多种计算机体系中移植。 字节码被解释着运行在虚拟机里。
动态编译环境是一种在执行时使用编译器的编译环境。 例如， 多数 Common Lisp 系统有一个编译函数，他可以编译在运行时创建的函数。
在即时编译环境下， 字节码的编译是第一步， 它将源代码递归到可移植和可优化的中间表示。字节码被部署到目标系统。 当执行代码时，运行时环境的编译器将字节码翻译为本地机器码。 基于每个文件或每个函数：函数仅仅在他们要被执行时才会被编译。
目标是要组合利用本地和字节码编译的多种优势：多数重量级的任务如源代码解析和基本性能的优化在编译时处理，将字节码编译为机器码比起从源代码编译为机器码要快得多。部署字节码是可移植的，而机器码只限于特定的系统结构。从字节码到机器码编译器的实现更容易，因为大部分工作已经在实现字节码编译器时完成。
----------------------我是胡扯分割线-------------------------------
好，说白了，JIT 在Android方面其实现实际上是在 Dalvik vm这一层，与内核是分离的，直观的表现就是几个库文件。
然后，JIT到底能提升机器多大的性能？我也不知道——不要跟我说Linpack跑多少分，学计算机的都知道，Linpack只是一个基准测试程序，测试的是机器的浮点计算能力、向量性能和高速缓存性能。Linpack只是众多基准测试的一种，它的分数代表不了任何东西。它只有一个局部的计算性能参考
然后，为什么使用了JIT之后，Linpack的分数就能提高很多？OK，看Linpack是干什么的——有一项是测试高速缓存的，那么，使用JIT之后，一部分Dalvik的字节码（apk程序包的逻辑部分，如*.dex和*.odex）会被转译成手机CPU的指令代码，那好，这部分代码就可以进行重用，减少了编译的时间，这就相当于一个“缓存”，使得访问Dalvik字节码的次数大大降低，也就是减少了解释执行字节码的次数。要知道，解释执行字节码的速度是比较慢的，所以直接体现就是Linpack分数的提高。
那么，JIT对我们使用的影响大么？
准确的说，有，但不是很大，根本达不到Froyo 2.2宣传的那样（我恨IT媒体）几倍的提升。为什么？因为我们用的系统不光有逻辑（程序执行），还有UI（图形渲染），以及其他很多因素（线程调度、I/O等等），单独的JIT技术只是提高了程序代码的执行效率（还不是全部），并未对系统有全局优化的功效。如果可以的话，可以针对Linpack专门设计一个优化的虚拟机，让G2这样的机器跑到30分也是没问题的。但是实际使用的体验不会好很多。
所以，不要迷信~
