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 瀏覽：335

編譯原理課時設置發布：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 瀏覽：739

為什麼安卓手機連不上蘋果7熱點發布：2025-05-18 03:40:13 瀏覽：803

網卡訪問發布：2025-05-18 03:35:04 瀏覽：511

接收和發送伺服器地址發布：2025-05-18 03:33:48 瀏覽：371

go是aot編譯還是jit

與go是aot編譯還是jit相關的資訊