安卓編譯機器碼

① 鴻蒙系統當時在編譯的時候用的是什麼編程語言

根據華為公布的方舟編譯器資料 可以推測鴻蒙系統是用C、C++語言編寫

如何看待華為鴻蒙系統的開發？

可以預見的鴻蒙系統。

1、除華為外其他國產手機公司不會安裝或重視。由於google禁售的是華為，對於小米等其他國產手機公司不禁售，因此小米等其他國產公司不會安裝鴻蒙系統，即便出於公共形象的壓力而安裝，也不會真正重視，最多就是做個樣子。

反正，內斗內行吧——除非華為讓渡鴻蒙系統的控制權！

2、鴻蒙系統即便能夠兼容安卓應用，在過了新鮮期之後，如何提升用戶體驗度是關鍵。如果像阿里OS一樣可以遠程刪除用戶的app，就直接死翹翹吧。

保持軟體開發商的利益和用戶體驗度的平衡，是鴻蒙系統能否生存的關鍵。開發商沒有得到利益，不會開發鴻蒙系統的app；用戶體驗度差，用戶就不會用鴻蒙系統。

② 方舟編譯器怎麼使用

方舟編譯器怎麼用？方舟編譯器是可以對安卓底層有優化作用的，這種優化是鑲嵌在系統中，能將所有的java代碼都編譯成機器碼，那具體我們要怎麼使用到手機上呢？下面是小編整理的方舟編譯器怎麼用教程，一起去陸旦看看吧！
方舟編譯器怎麼用
1、方舟編譯器是可以對安卓底層有優化作用的，像這樣的優化是鑲嵌在系統中的，能將所有的Java代碼都編譯成機器碼，從而是程序運行的速度更快換句話說就是方舟編譯器並不是一個單獨的app，當軟體運行時，其就在運行。
2、方舟編譯器提供了更高效的內存回收機制，回收時無需暫停應用，隨時用隨時回收，大大提高運行速度。舉一個鏈凳例子：EMUI9.1僅棚悉旅僅對系統組件SystemServer應用了華為方舟編譯器後，就帶來了系統操作流暢度提升24%，系統響應性能提升44%的收益。
3、代碼優化是編譯器最為核心的功能，也是評判一個編譯器優劣最重要的標准。
方舟編譯器|

③ 為什麼android不將java代碼編譯成本地代碼

1、Java所謂的跨平台主要是指cpu架構（x86\ARM\IBM的cpu等等），而不僅僅是OS。
2、Android手機硬體不標准，編譯成機器碼到一些手機上無法運行。
3、ART是在app安裝時，將app的代碼編譯成本地機器碼，這樣就可以因地制宜地將二進制碼編譯成對應的本地機器碼了，解決了問題2。但也不是在app發布時編譯為本地機器碼的。

④ 為什麼Android不可以繞開虛擬機直接運行

安卓是谷歌將它從開源linux上改造而來，依舊保持開源特性。為了應用開發者更多地開發安卓程序，自然也就保留了linux上的虛擬機機制。同時，安卓的目標是手機等移動終端，這些設備的處理器五花百門，而且開源安卓也會被各種深入定製，這同樣導致了安卓依然沿用了虛擬機機制來保持高兼容性。當然，這些華為研發了方舟編譯器，讓系統直接運行機器碼，以此來消除虛擬機帶來的弊端。

安卓系統最早並不是谷歌研發出來的，而是一家名叫Android的初創公司研發的。這家公司成立22個月後，就把原始Android雛形系統以4千萬美元的價格賣給了谷歌。 這個雛形原本就基於linux系統研發而來，自然裡面也還是沿用了linux的虛擬機機制。

谷歌拿到系統後，自己繼續研發Android系統，在2007年還集合了84家當時一流的硬體廠商組成研發聯盟。整個研發依然還是基於linux開源系統，但它解決了商業化的一個大難題。那就是，linux是開源系統，是有GPL開源協議的。很多硬體廠家為了適配該系統，必須將在上面研發的驅動程序公開，一旦公開驅動程序代碼就相當於公開了自己的硬體設計。而谷歌研發的Android系統解決了這個問題，它將驅動程序放置到了userspace裡面，並讓它可以通過l內核訪問硬體。同時，公開介面就可以讓硬體廠商編寫驅動程序。硬體廠商只需要提供驅動程序即可，不需要公開源代碼了。

這么多硬體廠商一起研發，自然就會 面臨一個問題就是每個廠商的硬體都不同。這對Android生態發展來說是個必須解決的兼容性問題。最好的辦法依然是沿用linux的虛擬機機制 ，這樣Android的軟體作者就無需針對不同硬體重新開發軟體。只需要一次開發就可以在安卓系統上的虛擬機中運行。

安卓的虛擬機機制在很大程度上解決了兼容性的問題，但是這種邊解釋邊執行的方式，也降低了軟體的運行效率。這些年，華為在這方面的研發上花了大功夫，成功研製出了「方舟」編譯器。該編譯器就是為了解決這個問題而誕生的。如果軟體作者採用方舟編譯器重新編譯自己的程序。它的軟體就可以以機器碼的形式在安卓系統上高效運行，並且方舟編譯器還會對程序進行優化。按照華為方面的數據顯示， 使用華為方舟編譯器編譯後的程序，操作流暢度提升24%，系統響應速度提升44%，第三方應用操作流暢度提升60%！

Android沒有繞開虛擬機直接運行，是因為從它研發之初為了保持高兼容性，不得不沿用了虛擬機的機制。但在這些年，華為研發了「方舟」編譯器，就是為了解決這個問題。通過方舟編譯器編譯後的程序可以直接以機器碼的形式在安卓系統上運行，效率大大提高。

為了多點兒面試題[機智]

當初設計android的時候，設計人員只是軟體工程師，無法針對某個CPU(目前有的CPU框架intel，arm，mips，rsicv等)去開發。最好的是，我針對所有CPU都支持。

跨平台，是指java語言編寫的程序，一次編譯後，可以在多個系統平台上運行。

因為機器針對不同機器語言，有不同執行邏輯。

就好比二進制000100，在arm裡面是調用加法器，而riscv是調用乘法器一樣。所以，需要給這些不同平台請個翻譯。而虛擬機就是起到翻譯作用。

這樣雖然增加了消耗(例如執行同樣代碼，時間消耗上，c明顯由於java)，但是可以某種意義上，把軟體，物理硬體分開了。軟體重點設計自己app，而硬體不斷增加CPU性能。

因為上層應用是 建立在 java 庫的基礎上，運行 java 庫 需要 java 虛擬機，調試模式，可以登錄到系統里，直接運行linux 命令，也可以下載運行 c程序。

啥叫Android不可以繞開虛擬機直接運行？Android本質上是Linux的變種，它本身就是應用APP的虛擬機容器，Android源碼針對硬體平台編譯之後，就是直接在CPU上運行的機器碼了，它的運行並不依賴於其他的虛擬機。

APP是JAVA打包的，倒是需要在Android的JVM里運行，畢竟要考慮跨平台嘛。

ActivityThread.java就是一個應用程序，有main方法，是一個進程，就是靠虛擬機，沒有這個就沒有app。咋繞開，繞開就得不用這個，得從內部更換成別的，都更換了那就不是簡單的事情了

因為java代碼必須編譯成機器語言才行，這時候就要接助虛擬機

在問為什麼前，先問下是什麼？Android是可以不依賴虛擬機運行的，只需要改一下重新編譯就好了。

系統就是這么設計的

⑤ 安卓art虛擬機在什麼位置

一、概述
我們知道Android的程序雖然也是使用Java/Kotlin語言編碼，並生成.class位元組碼，但並不能直接運行在JVM上，而是運行在自己的VM上。而Android程序之所以不能在JVM上運行的根本原因是.class位元組碼文件並不是Android的最終可執行文件(執行效率問題)，而是一個過渡產物，最終會生成dex文件在Android VM上執行。

1.1 Android虛擬機分類：
Android VM大體分為兩種： Dalvik 虛擬機和 ART虛擬機。

Dilvik 虛擬機：Android 5.0 版本之前。
ART虛擬機：Android 5.0 版本全面使用。
1.2 虛擬機的演變及優化：
Android 1.0，使用Dalvik作為Android虛擬機運行環境，此時的虛擬機是一個解釋執行器。
Android 2.2，Android 虛擬機中加入了JIT編譯器（Just-In-Time Compiler）。
Android 4.4，全新的ART虛擬機運行環境誕生，此時ART和Dalvik是共存的，用戶可以在兩者之間進行選擇。
Android 5.0，ART全面取代了Dalvik成為了Android虛擬機運行環境，並使用AOT預編譯技術在安裝Apk時全量預編譯 。
Android 7.0，ART虛擬機採用 JIT/AOT混合編譯模式。
二、Dalvik
Dalvik是Google公司自己設計用於Android平台的虛擬機，它是Android平台的重要組成部分，支持dex格式（Dalvik Executable）的Java應用程序的運行。dex格式是專門為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。Google對其進行了特定的優化，經過優化的Dalvik，具有高效、簡潔、節省資源的特點，同時還允許在有限的內存中同時運行多個虛擬機的實例，並且每一個Dalvik 應用作為一個獨立的Linux進程執行。獨立的進程可以防止在虛擬機崩潰的時候所有程序都被關閉。
2.1 Dalvik和JVM的區別
Dalvik 基於寄存器，而 JVM 基於棧。
指令數量：基於寄存器的操作指令，會增加操作數的大小(劣勢)，但是會大大減少操作指令的數量(優勢)
操作效率：基於寄存器(CPU上)的指令操作速度比基於操作數棧(主存)的速度快。
移植性：基於寄存器執行效率好，但是可移植性差，難跨平台。
Dalvik虛擬機有共享機制，不同應用之間在運行時可以共享相同的類，擁有更高的效率。
2.2 JIT（Just-In-Time Compile）
Android 2.2之前，Dalvik虛擬機是通過解釋器 (解釋器逐條讀入位元組碼 -> 逐條翻譯成機器碼 -> 執行機器碼)來執行程序的，效率低。針對這個問題，引進了JIT（即時編譯器）技術。它是一種優化手段。

JIT技術：將解釋過的機器碼緩存起來，下次再執行時到這個方法的時候，則直接從緩存裡面取出機器碼來執行。減少了讀取位元組碼和翻譯位元組碼的操作。以此來提高效率。JIT技術的引入使得Dalvik的性能提升了3~6倍。

注意： 並不是所有執行過的代碼對應的機器碼都會被緩存起來。而是只有被認定為熱點代碼（Hot Spot Code） 的代碼才會。這里所指的熱點代碼主要有兩類，包括：
被多次調用的方法
被多次執行的循環體（雖然只是循環體被多次執行，但仍是將整個方法的機器碼緩存起來）。

缺點： JIT技術的缺點：
每次重新啟動引用都需要重新編譯。
運行時比較耗電。
三、ART 虛擬機
ART虛擬機在Android 5.0開始替換Dalvik虛擬機，其處理應用程序執行的方式不同於Dalvik虛擬機，它不使用JIT而是使用了AOT（Ahead-Of-Time），也就是提前編譯技術。並對垃圾收集器也進行了改進和優化。

預先編譯機制(AOT)可提高應用的性能。同時ART 還具有比 Dalvik 更嚴格的安裝時驗證。

3.1 AOT（Ahead-Of-Time）預先編譯技術
AOT(提前編譯技術)： 簡單來說就是提前將位元組碼轉換成本地機器碼，然後存儲在本地磁碟上，運行時可以直接執行，避免了Dalvik時期的應用運行時再來解釋位元組碼。運行時效率大大提高。

在Android 7.0 之前，Android系統安裝Apk時，會進行一次全量預編譯，將位元組碼預先編譯成本地機器碼，生成 oat文件，並存儲在本地磁碟上。這樣在App每次運行時就不需要重新編譯，可以直接使用編譯好本地機器碼，運行效率大大提升。但是這也使得安裝應用的時間大大增加，於是在Android7.0及之後，又重新引進了JIT技術，形成JIT/AOT混合編譯模式。

混合編譯的特點：

應用在安裝的時候，不進行AOT預編譯。
應用運行時直接通過解釋器翻譯位元組碼為機器碼然後執行。（在應用運行期間使用了JIT技術）並同時記錄熱點代碼信息到profile文件中。
手機進入空閑或充電狀態的時候，系統會掃描APP目錄下的profile文件，並通過AOT對熱點代碼進行編譯。
下一次啟動時，會根據profile文件來運行已編譯好的機器碼，避免在運行時對已經轉換為機器碼的方法又進行了JIT編譯。
應用運行期間會持續對熱點代碼進行記錄，以方便在空閑或充電時進行AOT，以此循環。
使用JIT編譯器來對AOT編譯器進行補充，降低了Apk安裝的時間，提升了運行時性能，節省了存儲空間，加快應用運行速度。

小結：
Android 7.0以前，採用AOT全量預編譯，Apk安裝時預編譯dex生成對應的機器碼文件。但預編譯量大導致Apk安裝時間長。
Android 7.0及之後，採用JIT/AOT混合編譯模式，根據對應的profile在空閑時進行AOT預編譯。

參考： 實現 ART 即時 (JIT) 編譯器

3.2 Dalvik與ART虛擬機的區別
Dalvik每次都要編譯再運行，Art只會安裝時啟動編譯(7.0之前全量預編譯)。
Art佔用空間比Dalvik大（原生代碼佔用的存儲空間更大），就是用「空間換時間」。
Art減少編譯，減少了CPU使用頻率，使用明顯改善電池續航。
Art應用啟動更快、運行更快、體驗更流暢、觸感反饋更及時。
3.3 Interpreter解釋器、JIT、AOT的在ART上的使用
解釋器： 逐條讀入位元組碼 -> 逐條翻譯成機器碼 -> 執行機器碼，重復執行同一代碼時需要重新翻譯執行。
JIT編譯器： 對運行時的熱點代碼(熱點代碼)進行編譯，且緩存在內存中，當下次繼續執行時，直接從內存中獲取，減少重復編譯。
AOT編譯器： 在運行前將位元組碼轉換為機器碼，在運行時直接運行轉換後的機器碼。

在這里插入圖片描述

3.4 垃圾回收方面的優化
Android虛擬機（Dalvik && ART）學習

四、Android中的幾種文件
4.1 Apk文件
APK 文件其實是 zip 格式，在Window平台上可以直接將後綴格式改為zip進行解壓。解壓後的目錄如下圖所示：
在這里插入圖片描述

文件名 說明
META-INF/ 信息描述，簽名等用途。編譯生成一個apk包時，會對所有要打包的文件做一個校驗計算，並把計算結果放在META-INF目錄下。而在Android手機上安裝apk包時，應用管理器會按照同樣的演算法對包里的文件做校驗，如果校驗結果與META-INF下的內容不一致，系統就不會安裝這個apk。這就保證了apk包里的文件不能被隨意替換
res/ 存放資源文件
libs/ 存放的是 ndk 編出來的 so 庫
AndroidManifest.xml 程序全局清單文件
classes.dex dalvik 位元組碼
resources.ars 編譯後的二進制資源文件，主要是對應的索引
assets/ 保留工程中assets目錄，其他工程下的、jar包中的assets也會合並到該assets目錄下。
4.2 dex文件
dex 文件是可被Dalvik虛擬機識別並執行的文件， Dalvik 會執行 .dex 文件中的 dalvik 位元組碼，但一般Dalvik在執行dex優化後的文件(即odex文件)。

dex文件特點：

dex文件是Android系統中的一種文件，是一種特殊的數據格式，和Apk、jar等格式文件類似。
文件更加緊湊：dex文件是能夠被DVM識別，載入並執行的文件格式。相比於Jar文件，dex會把所有包含的信息整合在一起，減少冗餘信息，從而降低了載入文件時的I/O耗時，提高類的查找速度。
dex文件包含應用程序的全部操作指令和運行時數據。
相對於PC上的JVM能運行 .class文件，Android上的Dalvik虛擬機能運行 .dex 文件。
.dex文件和 .class文件的格式對照：
在這里插入圖片描述
dex 文件結構：
在這里插入圖片描述

4.3 引起dex文件65535問題的原因
當Android系統啟動一個Apk時，會通過 dexopt 工具對dex進行優化。dexopt 的執行過程是在第一次載入dex文件的時候執行的。這個過程會生成一個odex文件，即Optimised Dex (執行odex的效率會比直接執行Dex文件的效率要高很多)。但早期Android系統中， dexopt 有一個問題(即65535問題)。dexopt會把每一個類的方法id檢索起來，存在一個鏈表結構裡面。但是這個鏈表的長度是用一個 short類型(2^16=65536)來保存的，導致了方法id的數目不能夠超過65536個。
4.4 odex文件 (Optimized DEX)
背景： 對Android dex文件進行優化來說，需要注意的一點是dex文件的結構是緊湊的，但是我們還是要想方設法進行運行速度的提高，因此我們仍然需要對dex文件進一步優化。
odex文件的使用場景：

安裝階段： Apk在安裝時，系統會進行驗證和優化，目的是為了校驗代碼合法性及優化代碼執行速度。當驗證和優化後，系統會從Apk中提取dex文件進行優化，並將優化後的產物(odex文件)保存到 data/dalvik-cache 目錄下。
運行階段： 當運行Apk的時候，會直接載入odex文件，避免重復驗證和優化，加快了Apk的響應時間。
odex 文件的生成過程：

Android 5.0之前：Dalvik虛擬機

Dalvik虛擬機會在執行dex文件前對dex文件做優化，生成可執行文件odex，保存到 data/dalvik-cache 目錄，最後把Apk文件中的dex文件刪除。

注意： 此時生成的odex文件後綴依然是dex ，它是一個dex文件，裡面仍然是位元組碼，而不是本地機器碼。
Android5.0 <= Version < Android 8.0 (Android O)：ART虛擬機

Android5.0之後使用ART虛擬機，ART虛擬機使用AOT預編譯生成oat文件。oat文件是ART虛擬機運行的文件，是ELF格式二進制文件。oat文件包含dex和編譯的本地機器指令，因此比Android5.0之前的odex文件更大。

oat文件生成過程：
App在首次安裝的時候，dex2oat 工具默認會把 dex文件翻譯成本地機器指令，生成ELF格式的OAT文件，並將其放在了 /data/dalvik-cache 或 /data/app/packagename/ 目錄下，此時oat文件後綴格式為odex。
ART載入oat文件後不需要經過處理就可以直接運行，它在編譯時就從位元組碼裝換成機器碼了，因此運行速度更快。
Dalvik虛擬機執行程序dex文件前，系統會對dex文件做優化，生成可執行文件odex，保存到 data/dalvik-cache 目錄，最後把apk文件中的dex文件刪除。 (注意：此時生成的odex文件後綴依然是dex ，它是一個dex文件，裡面仍然還是位元組碼，而不是本地機器碼。)

注意： Android5.0及之後版本生成的 oat文件後綴還是odex，但是已經不是android5.0 及之前版本的文件格式，而是ELF格式封裝的本地機器碼。可以認為oat在dex上加了一層殼，可以從oat里提取出dex。
Android O及之後(>=Android 8.0)：ART虛擬機

Android 8.0及之後版本，dex2oat會直接生成兩個oat文件 (即vdex文件 和 odex文件)。其中 odex 文件是從vdex 文件中提取了部分模塊生成的一個新的可執行二進制碼文件，odex 從vdex 中提取後，vdex 的大小就減少了。

文件生成過程：
App在首次安裝的時候，odex 文件就會生成在 /system/app/<packagename>/oat/ 下。
在系統運行過程中，虛擬機將其 從/system/app 下 到 /data/davilk-cache/ 下。
odex + vdex = Apk 的全部源碼 （vdex 並不是獨立於odex 的，文件 odex + vdex 才代表一個Apk ）。
odex 的優點和缺點：

優點：
啟動快： 省去了系統第一次啟動應用時從Apk文件中讀取dex文件，並對dex文件做優化的過程。和
對RAM的佔用（Apk文件中的dex如果不刪除，同一個應用就會存在兩個dex文件：apk中和 data/dalvik-cache 目錄下）。
安全性：防止第三方用戶反編譯系統的軟體（odex文件是跟隨系統環境變化的，改變環境會無法運行；而apk文件中又不包含dex文件，無法獨立運行）
劣勢：
優化後的odex文件大小通常是原dex文件的1~4倍 (空間換時間)。
4.5 vdex文件
vdex文件是 Android O (Android 8.0) 新增的格式包，其目的是為了降低dex2oat時間。

dex2oat的觸發場景：

當系統OTA (系統升級) 後，用戶自己安裝的應用是不會發生任何變化的，但 framework 代碼已經發生了變化，因此就需要重新對這些應用也做dex2oat。如果沒有vdex文件，則需要重新校驗Apk里dex文件合法性；如果存在vdex文件，就可以省略校驗的過程，節省一部分時間。
當App的 JIT Profile 信息變化時，background dexopt會在後台重新做dex2oat，因為有了vdex，這個時候也可以直接跳過dex文件的校驗流程。
dex 文件直接轉化的可執行二進制碼文件：

App在首次安裝的時候，vdex文件就會生成在 /system/app/<packagename>/oat/下。
在系統運行過程中，虛擬機將其從 /system/app 下 到 /data/davilk-cache/ 下。
4.6 art文件
art文件是由虛擬機執行odex文件後，記錄虛擬機執行Apk啟動的常用函數地址信息後生成出來的文件(記錄函數地址信息方便定址)，目的 是用於加快應用啟動速度。通常會在data/dalvik-cache/ 目錄中保存常用的jar包的相關地址記錄。

第一次開機不會生成在 /system/app/<packagename>/oat/ 下，以後也不會。
odex 文件在運行時，虛擬機會計算函數調用頻率，進行函數地址的修改。
最後在 /data/davilk-cache/ 由虛擬機生成 art文件(art文件生成)。
生成 art文件後，/system/app 下的odex 和 vdex 會無效，即使你刪除，apk也會正常運行。
push 一個新的apk file 覆蓋之前 /system/app 下Apk file ，會觸發 PMS 掃描時下發 force_dex 的flag ，強行生成新的vdex 文件 ，覆蓋之前的vdex 文件，由於某種機制，這個新vdex 文件會到 /data/dalvik-cache/ 下，於是 art 文件也變化了。
4.7 oat文件
ART虛擬機運行的是oat文件，oat文件是一種Android私有ELF文件格式，oat文件包含有從dex文件翻譯而來的本地機器指令，還包含有原來的dex文件內容(如下圖所示)，因此oat文件比odex文件更大。APK在安裝的過程中，會通過dex2oat工具生成一個OAT文件(文件後綴還是odex)。對於apk來說，oat文件實際上就是對odex文件的包裝，即oat=odex。

注意： Android5.0 及之後的版本，oat文件的後綴還是odex，但是已經不是android5.0 之前的文件格式，而是ELF格式封裝的本地機器碼。可以認為oat在dex上加了一層殼，可以從oat里提取出dex。

⑥ 安卓手機運行環境art什麼意思

Android運行環境ART

安卓之前的版本運行機制是Dalvik，這個導致安卓卡慢，安卓4.4之後推出了ART，在5.0上完全使用了ART模式。

ART 的機制與 Dalvik 不同。在Dalvik下，應用每次運行的時候，位元組碼都需要通過即時編譯器轉換為機器碼，這會拖慢應用的運行效率，而在ART 環境中，應用在第一次安裝的時候，位元組碼就會預先編譯成機器碼，使其成為真正的本地應用。這個過程叫做預編譯（AOT,Ahead-Of-Time）。這樣的話，應用的啟動(首次)和執行都會變得更加快速。

通俗一點就是，ART增加APK安裝容量，實現了流暢度。

⑦ 安卓平台屬於動態庫操作嗎

屬於
靜態庫全稱靜態鏈接庫，動態庫全稱動態鏈接庫，看到全稱就知道什麼意思了吧？也就是說在鏈接的時候才會用到的庫，只有C/C++、OC語言才會有鏈接過程，Java沒有。

在Android中說到靜態庫和動態庫，一般說的都是C/C++代碼，我們知道在android中是通過jni技術訪問到C代碼的，我們會把C/C++打包成so文件，這個就是動態庫（共享庫）。如果我們想要使用的C庫是.a形式的靜態庫時，我們要把.a包裝成so庫，具體網上有方法。

個人感覺在java語言中討論靜態庫和動態庫就是個偽概念，java是的編譯結果是位元組碼文件，不是二進制文件，而且沒有鏈接的過程，jvm在解釋執行java代碼的時候調用C++代碼只能是動態的。

在C++和object C開發中，用編譯鏈接的過程，靜態庫在鏈接過程中，會和自己寫的源代碼打到一塊，多個程序多個靜態庫。動態庫不會打到一塊，如果有共享情況的話，系統只會載入一次。

OC的代碼處理過程是很復雜的，有預處理、編譯、鏈接過程，預處理就是處理宏什麼的，編譯這個過程就很復雜了，有編譯前端和編譯後端，編譯稱機器碼（中間還會有匯編的過程），鏈接就是鏈接動態庫或者靜態庫。

Android（java）代碼處理過程就很簡單啦，畢竟是運行在虛擬機上的。沒有所謂的預處理，直接編譯，這里的編譯也就是把java代碼轉化成位元組碼，這個編譯和OC中的編譯可不是一個概念，只不過也這么叫而已。後續Aandroid還會用dex工具把.class打包成.dex，不同的VM模式（5.0以後都是ART）會對.dex進行不同的優化，具體看Android 編譯到運行APK過程總結。需要提一下的是，ART採用AOT和JIT技術，在安裝或者運行的時候，會把位元組碼轉化成機器碼，這個機器碼也會受VM控制的，具體看Android之Dalvik 、ART

C/C++、Object C屬於編譯型語言，這是毋庸置疑的，因為它們都會在生成安裝包之前編譯成機器碼。