go是aot编译还是jit

发布时间: 2022-10-07 02:19:13

① 了解什么叫做jit compiling，与传统的编译技术有何不同

java 应用程序的性能经常成为开发社区中的讨论热点。因为该语言的设计初衷是使用解释的方式支持应用程序的可移植性目标，早期
Java 运行时所提供的性能级别远低于 C 和
C++
之类的编译语言。尽管这些语言可以提供更高的性能，但是生成的代码只能在有限的几种系统上执行。在过去的十年中，Java
运行时供应商开发了一些复杂的动态编译器，通常称作即时（Just-in-time，JIT）编译器。程序运行时，JIT
编译器选择将最频繁执行的方法编译成本地代码。运行时才进行本地代码编译而不是在程序运行前进行编译（用 C 或
C++ 编写的程序正好属于后一情形），保证了可移植性的需求。有些 JIT 编译器甚至不使用解释程序就能编译所有的代码，但是这些编译器仍然通过在程序执行时进行一些操作来保持 Java 应用程序的可移植性。
由于动态编译技术的多项改进，在很多应用程序中，现代的 JIT 编译器可以产生与 C 或 C++
静态编译相当的应用程序性能。但是，仍然有很多软件开发人员认为 —— 基于经验或者传闻 ——
动态编译可能严重干扰程序操作，因为编译器必须与应用程序共享 CPU。一些开发人员强烈呼吁对 Java
代码进行静态编译，并且坚信那样可以解决性能问题。对于某些应用程序和执行环境而言，这种观点是正确的，静态编译可以极大地提高 Java
性能，或者说它是惟一的实用选择。但是，静态地编译 Java 应用程序在获得高性能的同时也带来了很多复杂性。一般的
Java 开发人员可能并没有充分地感受到 JIT 动态编译器的优点。

本文考察了 Java 语言静态编译和动态编译所涉及的一些问题，重点介绍了实时 (RT) 系统。简要描述了 Java
语言解释程序的操作原理并说明了现代 JIT 编译器执行本地代码编译的优缺点。介绍了 IBM 在 WebSphere Real Time 中发布的
AOT 编译技术和它的一些优缺点。然后比较了这两种编译策略并指出了几种比较适合使用 AOT
编译的应用程序领域和执行环境。要点在于这两种编译技术并不互斥：即使在使用这两种技术最为有效的各种应用程序中，它们也分别存在一些影响应用程序的优缺
点。

执行 Java 程序

Java 程序最初是通过 Java SDK 的 javac程序编译成本地的与平台无关的格式（类文件）。可将此格式看作 Java
平台，因为它定义了执行 Java 程序所需的所有信息。Java 程序执行引擎，也称作 Java 运行时环境（JRE），包含了为特定的本地平台实现
Java 平台的虚拟机。例如，基于 Linux 的 Intel x86 平台、Sun Solaris 平台和 AIX 操作系统上运行的 IBM
System p 平台，每个平台都拥有一个 JRE。这些 JRE 实现实现了所有的本地支持，从而可以正确执行为
Java 平台编写的程序。

事实上，操作数堆栈的大小有实际限制，但是编程人员极少编写超出该限制的方法。JVM 提供了安全性检查，对那些创建出此类方法的编程人员进行通知。

Java 平台程序表示的一个重要部分是字节码序列，它描述了 Java
类中每个方法所执行的操作。字节码使用一个理论上无限大的操作数堆栈来描述计算。这个基于堆栈的程序表示提供了平台无关性，因为它不依赖任何特定本地平台
的 CPU 中可用寄存器的数目。可在操作数堆栈上执行的操作的定义都独立于所有本地处理器的指令集。Java
虚拟机（JVM）规范定义了这些字节码的执行（参见参考资料）。执行 Java 程序时，用于任何特定本地平台的任何 JRE 都必须遵守 JVM
规范中列出的规则。

因为基于堆栈的本地平台很少（Intel X87 浮点数协处理器是一个明显的例外），所以大多数本地平台不能直接执行 Java 字节码。为了解决这个问题，早期的 JRE 通过解释字节码来执行 Java 程序。即 JVM 在一个循环中重复操作：

◆获取待执行的下一个字节码；

◆解码；

◆从操作数堆栈获取所需的操作数；

◆按照 JVM 规范执行操作；

◆将结果写回堆栈。

这种方法的优点是其简单性：JRE 开发人员只需编写代码来处理每种字节码即可。并且因为用于描述操作的字节码少于 255 个，所以实现的成本比较低。当然，缺点是性能：这是一个早期造成很多人对 Java 平台不满的问题，尽管拥有很多其他优点。

解决与 C 或 C++ 之类的语言之间的性能差距意味着，使用不会牺牲可移植性的方式开发用于 Java 平台的本地代码编译。

编译 Java 代码

尽管传闻中 Java 编程的 “一次编写，随处运行”
的口号可能并非在所有情况下都严格成立，但是对于大量的应用程序来说情况确实如此。另一方面，本地编译本质上是特定于平台的。那么 Java
平台如何在不牺牲平台无关性的情况下实现本地编译的性能？答案就是使用 JIT 编译器进行动态编译，这种方法已经使用了十年（参见图 1）：

图 1. JIT 编译器

使用 JIT 编译器时，Java
程序按每次编译一个方法的形式进行编译，因为它们在本地处理器指令中执行以获得更高的性能。此过程将生成方法的一个内部表示，该表示与字节码不同但是其级
别要高于目标处理器的本地指令。（IBM JIT
编译器使用一个表达式树序列表示方法的操作。）编译器执行一系列优化以提高质量和效率，最后执行一个代码生成步骤将优化后的内部表示转换成目标处理器的本
地指令。生成的代码依赖运行时环境来执行一些活动，比如确保类型转换的合法性或者对不能在代码中直接执行的某些类型的对象进行分配。JIT
编译器操作的编译线程与应用程序线程是分开的，因此应用程序不需要等待编译的执行。

图 1 中还描述了用于观察执行程序行为的分析框架，通过周期性地对线程取样找出频繁执行的方法。该框架还为专门进行分析的方法提供了工具，用来存储程序的此次执行中可能不会改变的动态值。

因为这个 JIT 编译过程在程序执行时发生，所以能够保持平台无关性：发布的仍然是中立的 Java 平台代码。C 和 C++ 之类的语言缺乏这种优点，因为它们在程序执行前进行本地编译；发布给（本地平台）执行环境的是本地代码。

挑战

尽管通过 JIT 编译保持了平台无关性，但是付出了一定代价。因为在程序执行时进行编译，所以编译代码的时间将计入程序的执行时间。任何编写过大型 C 或 C++ 程序的人都知道，编译过程往往较慢。

为了克服这个缺点，现代的 JIT
编译器使用了下面两种方法的任意一种（某些情况下同时使用了这两种方法）。第一种方法是：编译所有的代码，但是不执行任何耗时多的分析和转换，因此可以快
速生成代码。由于生成代码的速度很快，因此尽管可以明显观察到编译带来的开销，但是这很容易就被反复执行本地代码所带来的性能改善所掩盖。第二种方法是：
将编译资源只分配给少量的频繁执行的方法（通常称作热方法）。低编译开销更容易被反复执行热代码带来的性能优势掩盖。很多应用程序只执行少量的热方法，因
此这种方法有效地实现了编译性能成本的最小化。

动态编译器的一个主要的复杂性在于权衡了解编译代码的预期获益使方法的执行对整个程序的性能起多大作用。一个极端的例子是，程序执行后，您非常清楚哪些方
法对于这个特定的执行的性能贡献最大，但是编译这些方法毫无用处，因为程序已经完成。而在另一个极端，程序执行前无法得知哪些方法重要，但是每种方法的潜
在受益都最大化了。大多数动态编译器的操作介于这两个极端之间，方法是权衡了解方法预期获益的重要程度。

Java 语言需要动态加载类这一事实对 Java
编译器的设计有着重要的影响。如果待编译代码引用的其他类还没有加载怎么办？比如一个方法需要读取某个尚未加载的类的静态字段值。Java
语言要求第一次执行类引用时加载这个类并将其解析到当前的 JVM
中。直到第一次执行时才解析引用，这意味着没有地址可供从中加载该静态字段。编译器如何处理这种可能性？编译器生成一些代码，用于在没有加载类时加载并解
析类。类一旦被解析，就会以一种线程安全的方式修改原始代码位置以便直接访问静态字段的地址，因为此时已获知该地址。

IBM JIT
编译器中进行了大量的努力以便使用安全而有效率的代码补丁技术，因此在解析类之后，执行的本地代码只加载字段的值，就像编译时已经解析了字段一样。另外一
种方法是生成一些代码，用于在查明字段的位置以前一直检查是否已经解析字段，然后加载该值。对于那些由未解析变成已解析并被频繁访问的字段来说，这种简单
的过程可能带来严重的性能问题。

动态编译的优点

动态地编译 Java 程序有一些重要的优点，甚至能够比静态编译语言更好地生成代码，现代的 JIT 编译器常常向生成的代码中插入挂钩以收集有关程序行为的信息，以便如果要选择方法进行重编译，就可以更好地优化动态行为。

关于此方法的一个很好的例子是收集一个特定 array操作的长度。如果发现每次执行操作时该长度基本不变，则可以为最频繁使用的

array长度生成专门的代码，或者可以调用调整为该长度的代码序列。由于内存系统和指令集设计的特性，用于复制内存的最佳通用例程的执行速度通
常比用于复制特定长度的代码慢。例如，复制 8
个字节的对齐的数据可能需要一到两条指令直接复制，相比之下，使用可以处理任意字节数和任意对齐方式的一般复制循环可能需要 10 条指令来复制同样的 8

个字节。但是，即使此类专门的代码是为某个特定的长度生成的，生成的代码也必须正确地执行其他长度的复制。生成代码只是为了使常见长度的操作执行得更快，
因此平均下来，性能得到了改进。此类优化对大多数静态编译语言通常不实用，因为所有可能的执行中长度恒定的操作比一个特定程序执行中长度恒定的操作要少得
多。

此类优化的另一个重要的例子是基于类层次结构的优化。例如，一个虚方法调用需要查看接收方对象的类调用，以便找出哪个实际目标实现了接收方对象的虚方法。
研究表明：大多数虚调用只有一个目标对应于所有的接收方对象，而 JIT
编译器可以为直接调用生成比虚调用更有效率的代码。通过分析代码编译后类层次结构的状态，JIT
编译器可以为虚调用找到一个目标方法，并且生成直接调用目标方法的代码而不是执行较慢的虚调用。当然，如果类层次结构发生变化，并且出现另外的目标方法，
则 JIT
编译器可以更正最初生成的代码以便执行虚调用。在实践中，很少需要作出这些更正。另外，由于可能需要作出此类更正，因此静态地执行这种优化非常麻烦。

因为动态编译器通常只是集中编译少量的热方法，所以可以执行更主动的分析来生成更好的代码，使编译的回报更高。事实上，大部分现代的
JIT
编译器也支持重编译被认为是热方法的方法。可以使用静态编译器（不太强调编译时间）中常见的非常主动的优化来分析和转换这些频繁执行的方法，以便生成更好
的代码并获得更高的性能。

这些改进及其他一些类似的改进所产生的综合效果是：对于大量的 Java 应用程序来说，动态编译已经弥补了与 C 和 C++ 之类语言的静态本地编译性能之间的差距，在某些情况下，甚至超过了后者的性能。

缺点

但是，动态编译确实具有一些缺点，这些缺点使它在某些情况下算不上一个理想的解决方案。例如，因为识别频繁执行的方法以及编译这些方法需要时间，所以应用
程序通常要经历一个准备过程，在这个过程中性能无法达到其最高值。在这个准备过程中出现性能问题有几个原因。首先，大量的初始编译可能直接影响应用程序的
启动时间。不仅这些编译延迟了应用程序达到稳定状态的时间（想象 Web
服务器经
历一个初始阶段后才能够执行实际有用的工作），而且在准备阶段中频繁执行的方法可能对应用程序的稳定状态的性能所起的作用也不大。如果 JIT
编译会延迟启动又不能显着改善应用程序的长期性能，则执行这种编译就非常浪费。虽然所有的现代 JVM
都执行调优来减轻启动延迟，但是并非在所有情况下都能够完全解决这个问题。

其次，有些应用程序完全不能忍受动态编译带来的延迟。如 GUI 接口之类交互式应用程序就是这样的例子。在这种情况下，编译活动可能对用户使用造成不利影响，同时又不能显着地改善应用程序的性能。

最后，用于实时环境并具有严格的任务时限的应用程序可能无法忍受编译的不确定性性能影响或动态编译器本身的内存开销。

因此，虽然 JIT 编译技术已经能够提供与静态语言性能相当（甚至更好）的性能水平，但是动态编译并不适合于某些应用程序。在这些情况下，Java 代码的提前（Ahead-of-time，AOT）编译可能是合适的解决方案。

AOT Java 编译

大致说来，Java 语言本地编译应该是为传统语言（如 C++ 或
Fortran）而开发的编译技术的一个简单应用。不幸的是，Java 语言本身的动态特性带来了额外的复杂性，影响了 Java
程序静态编译代码的质量。但是基本思想仍然是相同的：在程序执行前生成 Java 方法的本地代码，以便在程序运行时直接使用本地代码。目的在于避免
JIT 编译器的运行时性能消耗或内存消耗，或者避免解释程序的早期性能开销。

挑战

动态类加载是动态 JIT 编译器面临的一个挑战，也是 AOT
编译的一个更重要的问题。只有在执行代码引用类的时候才加载该类。因为是在程序执行前进行 AOT
编译的，所以编译器无法预测加载了哪些类。就是说编译器无法获知任何静态字段的地址、任何对象的任何实例字段的偏移量或任何调用的实际目标，甚至对直接调
用（非虚调用）也是如此。在执行代码时，如果证明对任何这类信息的预测是错误的，这意味着代码是错误的并且还牺牲了 Java 的一致性。

因为代码可以在任何环境中执行，所以类文件可能与代码编译时不同。例如，一个 JVM
实例可能从磁盘的某个特定位置加载类，而后面一个实例可能从不同的位置甚至网络加载该类。设想一个正在进行 bug
修复的开发环境：类文件的内容可能随不同的应用程序的执行而变化。此外，Java 代码可能在程序执行前根本不存在：比如 Java
反射服务通常在运行时生成新类来支持程序的行为。

缺少关于静态、字段、类和方法的信息意味着严重限制了 Java 编译器中优化框架的大部分功能。内联可能是静态或动态编译器应用的最重要的优化，但是由于编译器无法获知调用的目标方法，因此无法再使用这种优化。

内联

内联是一种用于在运行时生成代码避免程序开始和结束时开销的技术，方法是将函数的调用代码插入到调用方的函数中。但是内联最大的益处可能是优化方可见的代码的范围扩大了，从而能够生成更高质量的代码。下面是一个内联前的代码示例：

int foo() { int x=2, y=3; return bar(x,y); }final int bar(int a, int b) { return a+b; }

如果编译器可以证明这个 bar就是 foo()中调用的那个方法，则 bar中的代码可以取代 foo()中对
bar()的调用。这时，bar()方法是 final类型，因此肯定是 foo()中调用的那个方法。甚至在一些虚调用例子中，动态 JIT
编译器通常能够推测性地内联目标方法的代码，并且在绝大多数情况下能够正确使用。编译器将生成以下代码：

int foo() { int x=2, y=3; return x+y; }

在这个例子中，简化前名为值传播的优化可以生成直接返回
5的代码。如果不使用内联，则不能执行这种优化，产生的性能就会低很多。如果没有解析
bar()方法（例如静态编译），则不能执行这种优化，而代码必须执行虚调用。运行时，实际调用的可能是另外一个执行两个数字相乘而不是相加的
bar方法。所以不能在 Java 程序的静态编译期间直接使用内联。

AOT
代码因此必须在没有解析每个静态、字段、类和方法引用的情况下生成。执行时，每个这些引用必须利用当前运行时环境的正确值进行更新。这个过程可能直接影响
第一次执行的性能，因为在第一次执行时将解析所有引用。当然，后续执行将从修补代码中获益，从而可以更直接地引用实例、静态字段或方法目标。

另外，为 Java 方法生成的本地代码通常需要使用仅在单个 JVM 实例中使用的值。例如，代码必须调用 JVM
运行时中的某些运行时例程来执行特定操作，如查找未解析的方法或分配内存。这些运行时例程的地址可能在每次将 JVM 加载到内存时变化。因此 AOT
编译代码需要绑定到 JVM 的当前执行环境中，然后才能执行。其他的例子有字符串的地址和常量池入口的内部位置。

在 WebSphere Real Time 中，AOT 本地代码编译通过 jxeinajar工具（参见图 2）来执行。该工具对 JAR 文件中所有类的所有方法应用本地代码编译，也可以选择性地对需要的方法应用本地代码编译。结果被存储到名为 Java eXEcutable (JXE) 的内部格式中，但是也可轻松地存储到任意的持久性容器中。

您可能认为对所有的代码进行静态编译是最好的方法，因为可以在运行时执行最大数量的本地代码。但是此处可以作出一些权衡。编译的方法越多，代码占用的内存
就越多。编译后的本地代码大概比字节码大 10 倍：本地代码本身的密度比字节码小，而且必须包含代码的附加元数据，以便将代码绑定到 JVM
中，并且在出现异常或请求堆栈跟踪时正确执行代码。构成普通 Java 应用程序的 JAR
文件通常包含许多很少执行的方法。编译这些方法会消耗内存却没有什么预期收益。相关的内存消耗包括以下过程：将代码存储到磁盘上、从磁盘取出代码并装入
JVM，以及将代码绑定到 JVM。除非多次执行代码，否则这些代价不能由本地代码相对解释的性能优势来弥补。

图 2. jxeinajar

跟大小问题相违背的一个事实是：在编译过的方法和解释过的方法之间进行的调用（即编译过的方法调用解释过的方法，或者相反）可能比这两类方法各自内部之间
进行的调用所需的开销大。动态编译器通过最终编译所有由 JIT
编译代码频繁调用的那些解释过的方法来减少这项开销，但是如果不使用动态编译器，则这项开销就不可避免。因此如果是选择性地编译方法，则必须谨慎操作以使
从已编译方法到未编译方法的转换最小化。为了在所有可能的执行中都避免这个问题而选择正确的方法会非常困难。
优点
虽然 AOT 编译代码具有上述的缺点和挑战，但是提前编译 Java 程序可以提高性能，尤其是在不能将动态编译器作为有效解决方案的环境中。

可以通过谨慎地使用 AOT 编译代码加快应用程序启动，因为虽然这种代码通常比 JIT
编译代码慢，但是却比解释代码快很多倍。此外，因为加载和绑定 AOT
编译代码的时间通常比检测和动态编译一个重要方法的时间少，所以能够在程序执行的早期达到那样的性能。类似地，交互式应用程序可以很快地从本地代码中获
益，无需使用引起较差响应能力的动态编译。

RT 应用程序也能从 AOT 编译代码中获得重要的收益：更具确定性的性能超过了解释的性能。WebSphere Real Time
使用的动态 JIT 编译器针对在 RT 系统中的使用进行了专门的调整。使编译线程以低于 RT
任务的优先级操作，并且作出了调整以避免生成带有严重的不确定性性能影响的代码。但是，在一些 RT 环境中，出现 JIT
编译器是不可接受的。此类环境通常需要最严格的时限管理控制。在这些例子中，AOT
编译代码可以提供比解释过的代码更好的原始性能，又不会影响现有的确定性。消除 JIT
编译线程甚至消除了启动更高优先级 RT 任务时发生的线程抢占所带来的性能影响。

优缺点统计

动态（JIT）编译器支持平台中立性，并通过利用应用程序执行的动态行为和关于加载的类及其层次结构的信息来生成高质量的代码。但是
JIT
编译器具有一个有限的编译时预算，而且会影响程序的运行时性能。另一方面，静态（AOT）编译器则牺牲了平台无关性和代码质量，因为它们不能利用程序的动
态行为，也不具有关于加载的类或类层次结构的信息。AOT 编译拥有有效无限制的编译时预算，因为 AOT
编译时间不会影响运行时性能，但是在实践中开发人员不会长期等待静态编译步骤的完成。

表 1 总结了本文讨论的 Java 语言动态和静态编译器的一些特性：

表 1. 比较编译技术

两种技术都需要谨慎选择编译的方法以实现最高的性能。对动态编译器而言，编译器自身作出决策，而对于静态编译器，由开发人员作出选择。让
JIT 编译器选择编译的方法是不是优点很难说，取决于编译器在给定情形中推断能力的好坏。在大多数情况下，我们认为这是一种优点。

因为它们可以最好地优化运行中的程序，所以 JIT 编译器在提供稳定状态性能方面更胜一筹，而这一点在大量的生产 Java
系统中最为重要。静态编译可以产生最佳的交互式性能，因为没有运行时编译行为来影响用户预期的响应时间。通过调整动态编译器可以在某种程度上解决启动和确
定性性能问题，但是静态编译在需要时可提供最快的启动速度和最高级别的确定性。表 2 在四种不同的执行环境中对这两种编译技术进行了比较：

表 2. 使用这些技术的最佳环境

图 3 展示了启动性能和稳定状态性能的总体趋势：

图 3. AOT 和 JIT 的性能对比

使用 JIT 编译器的初始阶段性能很低，因为要首先解释方法。随着编译方法的增多及 JIT
执行编译所需时间的缩短，性能曲线逐渐升高最后达到性能峰值。另一方面，AOT 编译代码启动时的性能比解释的性能高很多，但是无法达到 JIT
编译器所能达到的最高性能。将静态代码绑定到 JVM 实例中会产生一些开销，因此开始时的性能比稳定状态的性能值低，但是能够比使用 JIT
编译器更快地达到稳定状态的性能水平。

没有一种本地代码编译技术能够适合所有的 Java
执行环境。某种技术所擅长的通常正是其他技术的弱项。出于这个原因，需要同时使用这两种编译技术以满足 Java
应用程序开发人员的要求。事实上，可以结合使用静态和动态编译以便提供最大可能的性能提升 —— 但是必须具备平台无关性，它是 Java
语言的主要卖点，因此不成问题。

结束语

本文探讨了 Java 语言本地代码编译的问题，主要介绍了 JIT 编译器形式的动态编译和静态 AOT 编译，比较了二者的优缺点。

虽然动态编译器在过去的十年里实现了极大的成熟，使大量的各种 Java 应用程序可以赶上或超过静态编译语言（如 C++ 或
Fortran）所能够达到的性能。但是动态编译在某些类型的应用程序和执行环境中仍然不太合适。虽然 AOT
编译号称动态编译缺点的万能解决方案，但是由于 Java 语言本身的动态特性，它也面临着提供本地编译全部潜能的挑战。

这两种技术都不能解决 Java 执行环境中本地代码编译的所有需求，但是反过来又可以在最有效的地方作为工具使用。这两种技术可以相互补充。能够恰当地使用这两种编译模型的运行时系统可以使很大范围内的应用程序开发环境中的开发人员和用户受益。

② Google I/O 2016 上发布的 Android N 有哪些新特性

1.多窗口支持
在 Android N 中，我们为该平台引入了一个新的而且非常需要的多任务处理功能 — 多窗口支持。
现在，用户可以一次在屏幕上打开两个APP。
在运行 Android N 的手机和平板电脑上，用户可以并排运行两个APP，或者处于分屏模式时一个APP位于另一个APP之上。用户可以通过拖动两个APP之间的分隔线来调整APP。
在 Android TV 设备上，APP可以将自身置于画中画面模式，从而让它们可以在用户浏览或与其他APP交互时继续显示内容。如需了解详细信息，请参阅下文。
多窗口支持为您提供新的吸引用户方式，特别是在平板电脑和其他更大屏幕的设备上。您甚至可以在您的APP中启用拖放，从而使用户可以方便地将内容拖放到您的应用或从其中拖出内容—这是一个非常好的增强用户体验的方式。
向您的APP添加多窗口支持并配置多窗口显示的处理方式非常简单。例如，您可以指定您的 Activity 允许的最小尺寸，从而防止用户将 Activity 调整到该尺寸以下。您还可以为APP禁用多窗口显示，这可确保系统将仅以全屏模式显示APP。
如需了解详细信息，请参阅多窗口支持开发者文档。
2.Notification 增强功能
在 Android N 中，我们重新设计了Notification，使其更易于使用并且速度更快。部分变更包括：
- 模板更新：我们正在更新Notification模板，新强调了图片跟头像。开发者将能够充分利用新模板，只需进行少量的代码调整。
- 绑定的Notification：系统可以将消息组合在一起（例如，按消息主题）并显示组。用户可以适当地进行 Dismiss 或 Archive 等操作。如果您已实现 Android Wear 的通知，那么您已经很熟悉此模型。
- 直接回复：对于实时通信应用，Android 系统支持内联回复，以便用户可以直接在通知界面中快速回复短信。
- 自定义视图：两个新的 API 让您在通知中使用自定义视图时可以充分利用系统的风格，如Notification标题和操作。
如需了解如何实现新功能的信息，请参阅通知指南。
2.配置文件指导的 JIT/AOT 编译
在 Android N 中，我们添加了 Just in Time (JIT) 编译器，对 ART 进行代码分析，让它可以在应用运行时持续提升 Android 应用的性能。JIT 编译器对 Android 运行组件当前的 Ahead of Time (AOT) 编译器进行了补充，有助于提升运行时性能，节省存储空间，加快应用更新和系统更新速度。
配置文件指导的编译让 Android 运行组件能够根据应用的实际使用以及设备上的情况管理每个应用的 AOT/JIT 编译。例如，Android 运行组件维护每个应用的热方法的配置文件，并且可以预编译和缓存这些方法以实现最佳性能。对于应用的其他部分，在实际使用之前不会进行编译。
除提升应用的关键部分的性能外，配置文件指导的编译还有助于减少整个 RAM 占用，包括关联的二进制文件。此功能对于低内存设备非常尤其重要。
Android 运行组件在管理配置文件指导的编译时，可最大程度降低对设备电池的影响。仅当设备处于空闲状态和充电时才进行编译，从而可以通过提前执行该工作节约时间和省电。
3.快速的应用安装路径
Android 运行组件的 JIT 编译器最实际的好处之一是应用安装和系统更新的速度。即使在 Android 6.0 中需要几分钟进行优化和安装的大型应用，现在只需几秒钟就可以完成安装。系统更新也变得更快，因为省去了优化步骤。
4.瞌睡模式
Android 6.0 推出了瞌睡模式，即设备处于空闲状态时，通过推迟应用的 CPU 和网络活动以实现省电目的的系统模式，例如，设备放在桌上或抽屉里时。
现在，在 Android N 中，瞌睡模式又前进了一步，在外出时也可以省电。只要屏幕关闭了一段时间，且设备未插入电源，瞌睡模式就会对应用使用熟悉的 CPU 和网络限制。这意味着用户即使将设备放入口袋里也可以省电。

屏幕关闭片刻后，设备在使用电池时，瞌睡模式将限制网络访问，同时延迟作业和同步。在短暂的维护时间范围后，其允许应用访问网络，并执行延迟的作业/同步。打开屏幕或将设备插入电源会使设备退出瞌睡模式。
当设备再次处于静止状态时，屏幕关闭且使用电池一段时间，瞌睡模式针对 PowerManager.WakeLock,AlarmManager 警报和 GPS/Wi-Fi 扫描应用完整 CPU 和网络限制。
无论设备是否处于运动状态，将应用调整到瞌睡模式的最佳做法均相同，因此，如果您已更新应用以妥善处理瞌睡模式，则一切就绪。如果不是，请立即开始将应用调整到瞌睡模式。
5.Project Svelte：后台优化
Project Svelte 在持续改善，以最大程度减少生态系统中一系列 Android 设备中系统和应用使用的 RAM。在 Android N 中，Project Svelte 注重优化在后台中运行应用的方式。
后台处理是大多数应用的一个重要部分。处理得当，可让您实现非常棒的用户体验 — 即时、快速和情境感知。如果处理不得当，后台处理会毫无必要地消耗 RAM（和电池），同时影响其他应用的系统性能。
自 Android 5.0 发布以来，JobScheler 已成为执行后台工作的首选方式，其工作方式有利于用户。应用可以在安排作业的同时允许系统基于内存、电源和连接情况进行优化。JobScheler 可实现控制和简洁性，我们想要所有应用都使用它。
另一个非常好的选择是 GCMNetworkManager（Google Play 服务的一部分），其在旧版 Android 中提供类似的作业安排和兼容性。
我们在继续扩展 JobScheler 和 GCMNetworkManager，以符合多个用例 — 例如，在 Android N 中，现在，您可以基于内容提供程序中的更改安排后台工作。同时，我们开始弃用一些较旧的模式，这些模式会降低系统性能，特别是低内存设备的系统性能。
在 Android N 中，我们删除了三个常用隐式广播 — CONNECTIVITY_ACTION、ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO — 因为这些广播可能会一次唤醒多个应用的后台进程，同时会耗尽内存和电池。如果您的应用收到这些广播，请充分利用 N Developer Preview 以迁移到 JobScheler 和相关的 API。
如需了解详情，请查看后台优化文档。
6.Data Saver
在移动设备的整个生命周期，蜂窝数据计划的成本通常会超出设备本身的成本。对于许多用户而言，蜂窝数据是他们想要节省的昂贵资源。
Android N 推出了 Data Saver 模式，这是一项新的系统服务，有助于减少应用使用的蜂窝数据，无论是在漫游，账单周期即将结束，还是使用少量的预付费数据包。Data Saver 让用户可以控制应用使用蜂窝数据的方式，同时让开发者打开 Data Saver 时可以提供更多有效的服务。
用户在 Settings 中启用 Data Saver 且设备位于按流量计费的网络上时，系统屏蔽后台数据使用，同时指示应用在前台尽可能使用较少的数据 — 例如，通过限制用于流媒体服务的比特率、降低图片质量、延迟最佳的预缓冲等方法来实现。用户可以将特定应用加入白名单以允许后台按流量的数据使用，即使在打开 Data Saver 时也是如此。

Android N 继承了 ConnectivityManager，以便为应用检索用户的 Data Saver 首选项并监控首选项变更提供一种方式。所有应用均应检查用户是否已启用 Data Saver 并努力限制前台和后台数据的使用。
7.快速设置Tile API
“快速设置”通常用于直接从通知栏显示关键设置和操作，非常简单。在 Android N 中，我们已扩展“快速设置”的范围，使其更加有用更方便。
我们为额外的“快速设置”Tile添加了更多空间，用户可以通过向左或向右滑动跨分页的显示区域访问它们。我们还让用户可以控制显示哪些“快速设置”Tile以及显示的位置 — 用户可以通过拖放Tile来添加或移动Tile。
对于开发者，Android N 还添加了一个新的 API，从而让您可以定义自己的“快速设置”Tile，使用户可以轻松访问您应用中的关键控件和操作。
对于急需或频繁使用的控件和操作，保留“快速设置”Tile，且不应将其用作启动应用的快捷方式。
定义Tile后，您可以将它们显示给用户，用户可通过拖放将Tile添加到“快速设置”。

如需创建应用Tile的更多信息，请参阅可下载的 API 参考中的 android.service.quicksettings.Tile。
8.号码屏蔽
Android N 现在支持在平台中进行号码屏蔽，提供框架 API，让服务提供商可以维护屏蔽的号码列表。默认短信应用、默认手机应用和提供商应用可以对屏蔽的号码列表进行读取和写入操作。其他应用则无法访问此列表。
通过使号码屏蔽成为平台的标准功能，Android 为应用提供一致的方式来支持广泛的设备上的号码屏蔽。应用可以利用的其他优势包括：
- 还会屏蔽已屏蔽的来电号码发出的短信
- 通过 Backup & Restore（备份和还原）功能可以跨重置和设备保留屏蔽的号码
- 多个应用可以使用相同的屏蔽号码列表
此外，通过 Android 的运营商应用集成表示运营商可以读取设备上屏蔽的号码列表，并为用户执行服务端屏蔽，以阻止不需要的来电和短信通过任何介质（如 VOIP 端点或转接电话）到达用户。
如需了解详细信息，请参阅可下载的 API 参考中的 android.provider.BlockedNumberContract。
9.来电过滤
Android N 允许默认的手机应用过滤来电。手机应用执行此操作的方式是实现新的 CallScreeningService，该方法允许手机应用基于来电的 Call.Details 执行大量操作，例如：
- 拒绝来电
- 不允许来电到达呼叫日志
- 不向用户显示来电通知
如需了解详细信息，请参阅可下载的 API 参考中的 android.telecom.CallScreeningService。
10.多区域设置支持、多语言
Android N 现在允许用户在设置中选择多个区域设置，以更好地支持双语用例。应用可以使用新的 API 获取用户选择的区域设置，然后为多区域设置用户提供更成熟的用户体验 — 如以多个语言显示搜索结果，并且不会以用户了解的语言翻译网页。
除多区域设置支持外，Android N 还扩展了用户可用的语言范围。它针对常用语言提供超过 25 种的变体，如英语、西班牙语、法语和阿拉伯语。它还针对 100 多种新语言添加了部分支持。
应用可以通过调用 LocaleList.GetDefault() 获取用户设置的区域设置列表。为支持扩展的区域设置数量，Android N 正在改变其解析资源的方式。请务必使用新的资源解析逻辑测试和验证您的应用是否能如期运行。
如需有关新资源解析行为和应遵循的最佳做法的更多信息，请参阅多语言支持。
11.Android 中的 ICU4J API
Android N 目前在 Android 框架（位于 android.icu 软件包下）中提供 ICU4J API 的子集。迁移很简单，主要是需要从 com.java.icu 命名空间更改为 android.icu。如果您已在您的应用中使用 ICU4J 捆绑包，切换到 Android 框架中提供的 android.icu API 可以大量节省 APK 大小。
如果要了解有关 Android ICU4J API 的更多信息，请参阅 ICU4J 支持。
12.OpenGL™ ES 3.2 API
Android N 添加了框架接口和对 OpenGL ES 3.2 的平台支持，包括：
- 来自 Android 扩展包 (AEP) 的所有扩展（EXT_texture_sRGB_decode 除外）。
- 针对 HDR 的浮点帧缓冲和延迟着色。
- BaseVertex 绘图调用可实现更好的批处理和流媒体服务。
- 强大的缓冲区访问控制可减少 WebGL 开销。
Android N 上适用于 OpenGL ES 3.2 的框架 API 与 GLES32 类一起提供。使用 OpenGL ES 3.2 时，请务必通过标记和 android:glEsVersion 属性在您的清单文件中声明要求。
如需了解有关使用 OpenGL ES 的信息，包括如何在运行时检查设备支持的 OpenGL ES 版本，请参阅 OpenGL ES API 指南。
13.Android TV 录制
Android N 通过新的录制 API 添加了从 Android TV 输入服务录制和播放内容的功能。构建在现有时移 API 之上，TV 输入服务可以控制能够录制的渠道数据、保存录制的会话的方式，同时可通过录制的内容管理用户交互。
如需了解详细信息，请参阅 Android TV 录制 API。
14.Android for Work
Android for Work 针对运行 Android N 的设备添加了许多新功能和 API。部分重要内容如下— 有关与 Android N 相关的 Android for Work 更新的完整列表，请参阅 Android for Work 变更。
15.关闭工作
在具有托管配置文件的设备上，用户可以切换工作模式。工作模式关闭时，管理的用户临时关闭，其禁用托管配置文件应用、后台同步和通知。这包括配置文件所有者应用。关闭工作模式时，系统显示永久状态图标，以提醒用户他们无法启动工作应用。启动器指示该工作应用和小组件无法访问。
16.Always on VPN
设备所有者和配置文件所有者可以确保工作应用始终通过指定的 VPN 连接。系统在设备启动后自动启动该 VPN。
新的 DevicePolicyManager 方法为 setAlwaysOnVpnPackage() 和 getAlwaysOnVpnPackage()。
由于 VPN 服务无需应用交互即可由系统直接绑定，因此，VPN 客户端必须针对 Always on VPN 处理新的入口点。和以前一样，由与操作匹配的 Intent 过滤器将服务指示给系统。android.net.VpnService。
用户还可以使用 Settings>More>Vpn 在主要用户中手动设置实现 VPNService 方法的 Always on VPN 客户端。
17.辅助工具增强功能
Android N 现在针对新的设备设置直接在欢迎屏幕上提供“Vision Settings”。这使用户可以更容易发现和配置他们设备上的辅助工具功能，包括放大手势、字体大小、显示屏尺寸和 TalkBack。
随着这些辅助工具功能更为突出，在启用这些功能后，您的用户更可能试用您的应用。请务必提前启用这些设置测试您的应用。您可以通过 Settings > Accessibility 启用它们。
还是在 Android N 中，辅助工具服务现在可以帮助具有动作障碍的用户触摸屏幕。全新的 API 允许使用人脸追踪、眼球追踪、点扫描等功能构建服务，以满足这些用户的需求。
如需了解详细信息，请参阅可下载的 API 参考中的 android.accessibilityservice.GestureDescription

③ Rust 和 Go,哪个性能更好

要说性能，那是Rust更好。更多的编译期优化、无 GC 等特点加持，开发高性能应用自然是 Rust 性能高。据统计利用 Rust 开发的 RipGrep 性能甚至赛过使用 C 开发的 Grep。

但是性能不是唯一考量，当你纠结 Borrow Check，纠结 unsafe，纠结 clone，纠结各种奇怪的类型限制的时候；当你 cargo build 怒草电脑风扇三分钟的时候；人家 GoLang 可能早就发两个版了。

同时 Rust 的语法花活众多，遍历数组可以写循环也可以 for_each() 一行流。不像 GoLang 那么白开水谁写都差不多一个味道，经常第一天想到神来之笔快乐 Coding 到半夜第二天爬起来发现昨晚写的都甚么东西看不懂不如蜘蛛爬，这是坠痛苦的！

Go 的编译器为了个编译速度快连循环不变式提升、循环展开、对齐等等优化一个都不做，函数内敛一堆限制大多数情况都不做（比如函数里有个 for 或者 defer 或者 select 等，或者函数多于 40 个表达式），拥有的优化一只手都能数的过来：

基础优化欠缺，高级优化更是一个没有，和在 Debug 配置编译下的 -O0 优化的 C++ 差不多一个概念（而且跑得更慢），哪来的资本和 rust 比性能。

其他方面：

而且 Go 的 GC 吞吐量也很低，大多数情况下各方面 Go 跑的甚至都比 Java 更慢。只不过得益于 AOT 编译的设计，相比 Java 而言除了内存占用小和启动速度快之外就没有任何优势了，比较适合拿来做性能不关键的命令行工具。

个人还是更喜欢 Rust。

④ Java中有类似于NGen的工具吗

AOT编译（Ahead-of-Time Compilation）不但涉及一个编译器，还要涉及配套的运行时支持系统（runtime system）。两者通常是紧密耦合的。
换句话说，一个AOT编译器只能跟自己的runtime搭配使用，这个runtime可以是一个完整的VM（如NGen与CLR的搭配），也可以是一个比较小的runtime（如.NET Native里的MRT（Minimal Runtime），只提供基础的GC、多线程支持等功能）。

⑤ 安卓各版本差异

1、系统恢复开源
2、统一手机与平板，通知栏支持单个清楚，人脸解锁，数据流量监视器，内置拼音检查，Roboto字体，Wi-Fi直连即WLAN直连（4.0）
3、三重缓冲，Google Now（基于时间和位置的语音搜索），离线语音输入支持，通知中心增强，应用增量更新技术（4.1.2）
4、ART模式支持，RAM优化，Emoji键盘，增强蓝牙，NFC付费（4.4.2）
5、32位系统支持

1、引入对64位系统的支持，兼容支持32位应用
2、卡片化、扁平化设计风格
3、新增浮动通知
4、预先编译（AOT）Android运行时由Android核心库集和Dalvike虚拟机改成Android核心库集和ART。两者的区别就是Dalvike虚拟机采用了一种被称为JIT（just-in-time）的解释器进行动态编译,而ART模式则在用户安装App是进行预编译AOT（Ahead-of-time）。将android5.X的运行速度提高了3倍左右。
5、Android 5.1添加了对同时使用多个蜂窝运营商SIM卡的支持。

1、动态权限，用户可直接在运行时管理应用权限。
2、取消了Apache HTTP客户端。
3、Doze电量管理功能，在“Doze”模式下，手机会在一段时间未检测到移动时，让应用休眠清杀后台进程减少功耗，谷歌表示，当屏幕处于关闭状态，平均续航时间提高30%，这个区别于IOS的墓碑机制。在安卓开发，需要后台运行时，最好在前台留有进程，防止被误杀。
4、从Android6.X起，Ecilpse ADT不再更新支持Android开发。
5、谷歌正式将指纹识别加入系统底层，开发相关的API，加大指纹开发的安全性。
6、加入了Android Pay进一步强化移动支付

1、多窗口支持，用户可以并排运行两个应用
2、更便捷的通知栏，自动将多条通知合并，可以直接回复通知
3、快速的应用安装路径，只需几秒钟就可以完成安装。系统更新也变得更快，因为省去了优化步骤。
4、随时随地低电耗模式，屏幕关闭一段时间，且设备未插电源，低电耗模式就会对应用使用熟悉的CPU和网络限制。
5、“快速设置”通常用于直接从通知栏显示关键设置和操作，非常简单。
6、号码屏蔽和来电过滤
7、WebView：Chrome和WebView配合使用、多进程、Javascript在页面加载之前运行、不安全起点上的地理定位
8、支持app应用签名v2的打包方式，引入一项新的应用签名方案APK Sigature Scheme v2，它能提供更快的应用安装时间和更多针对未授权APK文件更改的保护。
9、权限更改，面向Android 7.0或更高版本的应用私有目录被限制访问。
10、JIT/AOT编译共存（Just In Time, Adead of Time）

1、安装未知来源的第三方开关被移出，变成了每次安装未知的第三方都要手动授权。
2、通知功能的改变，应用收到通知时，会在应用的右上角显示一个红点，长按会跳出一个弹出菜单。
3、画中画功能的加入。
4、支持自动填写的功能。

1、DNS over TLS: 是一个通过传输层安全协议（TLS）来加密并打包域名系统（DNS）的安全协议。此协议设计目的是为了防止中间人攻击与控制DNS数据以增强用户隐私。
2、（刘海屏）全新的手势操作界面，不带返回键和多任务键。
3、GPS定位之外的WiFi定位，增加了平台级支持IEEE 802.11 mc Wi-Fi协议，让开发者可在App中使用室内定位。
4、网络和神经网络，设备会对网络有更精细的调整：根据任务需求的数据大小和当前的网络环境。在收费网络里延迟一些网络请求，而在不急飞的网络里可以通过消息预获取来得到更好的用户体验。神经网络API的更多操作则是让设备变得更智能，更聪明。

⑥ 为什么有的要编art

有的要编art是因为可以提高启动和运行速度。
ART是一个AOT编译器。所谓AOT (Ahead of Time)是指在运行以前就把中间代码静态编译成本地代码，而JIT (Just inTime)则是在运行时动态编译。
AOT的主要编译过程发生于开发用机，因此编译得慢一点没关系，可以充分的做各种耗时的优化，JIT在运行时动态编译，通常不能做太耗时的优化，否则影响启动和运行速度更具体一点。

⑦ Android 的 ART 是什么东西，有何作用

ART是一个AOT编译器。所谓AOT (Ahead of Time)是指在运行以前就把中间代码静态编译成本地代码，而JIT (Just inTime)则是在运行时动态编译。 AOT和JIT比各有长处，这里不详细，只简单列举几个最主要的： AOT的主要编译过程发生于开发用机，因此编译得慢一点没关系，可以充分的做各种耗时的优化；JIT在运行时动态编译，通常不能做太耗时的优化，否则影响启动和运行速度更具体一点，以Sun的JVM为例，JIT大体上划分为client和server两种模式。Client模式下VM是一边解释执行，一边识别热点区域进行JIT编译，以免明显影响启动速度；考虑到内存占用，也不会把所有Java字节码都编译成本地代码。Server模式下则会进行全面的JIT编译，因为server启动慢一点没关系，一旦跑起来就会运行很长时间，所以花一点点时间全面优化是值得的。因为受优化程度限制，JIT编译出来的本地代码体积通常比较大，5到10倍于bytecode都是正常的。AOT编译出来的本地代码体积更小。Android的JIT code cache也是内存占用的重要角色。因为是预编译好的机器代码，AOT产生的代码和加载执行过程和普通的本地代码没有太大分别。不过仍然需要运行时的GC支持。虽然AOT可以有更多的时间和空间做编译优化，但并不等于性能上就一定胜过JIT。JVM有不少东西只能在运行时动态决定是否可以采用编译优化（如识别可以inline的虚方法），以及运行时动态反优化（例如inline了一个虚方法，后来发现遇到新的派生类的实例，就需要取消原来的inline）。这些事情AOT就不容易做到。 AOT的编译器一般会分两个版本，一个在开发机上编译整个系统和预装应用，另一个是一个精简版，在设备上运行，负责编译连接新安装的应用。 AOT编译出来的代码仍然需要运行时的支持，特别是GC。如果ART确实是用AOT compiler替换JIT，性能先不谈，Android的内存占用应该会因此获益。现在dex代码经过 dex => optimized dex => JIT cache这个过程，内存中需要同时容纳odex和JIT cache两份代码；换成ART以后，就变成dex => oat，内存里只放oat就可以。不过考虑到ART的解释器代码里有提到deoptimization，也有可能在特定情况下还需要load dex代码解释执行。重要的是oat应该是可以直接mmap执行的代码（其实就是一个真·ELF格式的文件），加载/换页重加载的速度都会比从odex动态编译来得快。

⑧ 编程时选用的程序设计语言，对软件的开发与维护的影响

编程时选用的程序设计语言，对软件的开发与维护的影响?
这个是有一定的影响的，有些编程语言维护起来比较简单，而有些编程语言维护起来难度还是比较大的。另外也要考虑到运维人员的接受程度。

⑨ Google I/O 2016 上发布的 Android N 有哪些新特性

⑩ Google I/O 2016 上发布的 Android N 有哪些新特性

阅读全文

热点内容

内置存储卡可以拆吗发布：2025-05-18 04:16:35 浏览：336

编译原理课时设置发布：2025-05-18 04:13:28 浏览：378

linux中进入ip地址服务器发布：2025-05-18 04:11:21 浏览：612

java用什么软件写发布：2025-05-18 03:56:19 浏览：32

linux配置vim编译c 发布：2025-05-18 03:55:07 浏览：107

砸百鬼脚本发布：2025-05-18 03:53:34 浏览：944

安卓手机如何拍视频和苹果一样发布：2025-05-18 03:40:47 浏览：741

为什么安卓手机连不上苹果7热点发布：2025-05-18 03:40:13 浏览：803

网卡访问发布：2025-05-18 03:35:04 浏览：511

接收和发送服务器地址发布：2025-05-18 03:33:48 浏览：372

go是aot编译还是jit

与go是aot编译还是jit相关的资讯