雖然方舟編譯器還沒開放源碼，但是大家對此還挺有興趣的。最近和小夥伴討論了下方舟編譯器，並且討論了下我提出的一個猜測，關於編譯器執行代碼的一個可行方案。
ART - Android Runtime
4.4提出，與Dalvik共存，5.0替換Dalvik
7.0更改方案為AOT與JIT混合
雖然方舟編譯器還沒開放源碼，但是大家對此還挺有興趣的。最近和小夥伴討論了下方舟編譯器，並且討論了下我提出的一個猜測，關於編譯器執行代碼的一個可行方案。
ART - Android Runtime
4.4提出，與Dalvik共存，5.0替換Dalvik
7.0更改方案為AOT與JIT混合
7.0的混合模式的意思就是第一次運行時編譯成機器碼，然後利用保存下來的機器碼，去掉無用的，再存起來，供下次使用。
顯而易見，以下便是缺點：
第一，在將字節碼編譯成機器碼也是需要時間的，就算是直接進入堆棧(內存)，那也是有延遲的。儘管那幾毫秒對於人類來說可以忽略。更何況，CPU還是傻傻地，編譯好後會返回ART，等待ART的執行指示，等到執行指示，然後執行好後，依舊得經過ART堆棧，最後才能呈現於前臺。
第二，就算不在使用時利用保存下來的數據進行編譯，那麼在你不用的時候編譯，那就造成了耗電。
那，咱們說說華為的方舟編譯器。
在開發的時候直接編譯成機器碼。
儘管我們不知道他是單個編譯器直接編譯成機器碼還是先讓JDK/AAPT編譯成字節碼後，才轉換成機器碼，但是這個我們都可以忽略，因為這跟用戶並沒有什麼關係。
雖然方舟編譯器還沒開放源碼，但是大家對此還挺有興趣的。最近和小夥伴討論了下方舟編譯器，並且討論了下我提出的一個猜測，關於編譯器執行代碼的一個可行方案。
ART - Android Runtime
4.4提出，與Dalvik共存，5.0替換Dalvik
7.0更改方案為AOT與JIT混合
7.0的混合模式的意思就是第一次運行時編譯成機器碼，然後利用保存下來的機器碼，去掉無用的，再存起來，供下次使用。
顯而易見，以下便是缺點：
第一，在將字節碼編譯成機器碼也是需要時間的，就算是直接進入堆棧(內存)，那也是有延遲的。儘管那幾毫秒對於人類來說可以忽略。更何況，CPU還是傻傻地，編譯好後會返回ART，等待ART的執行指示，等到執行指示，然後執行好後，依舊得經過ART堆棧，最後才能呈現於前臺。
第二，就算不在使用時利用保存下來的數據進行編譯，那麼在你不用的時候編譯，那就造成了耗電。
那，咱們說說華為的方舟編譯器。
在開發的時候直接編譯成機器碼。
儘管我們不知道他是單個編譯器直接編譯成機器碼還是先讓JDK/AAPT編譯成字節碼後，才轉換成機器碼，但是這個我們都可以忽略，因為這跟用戶並沒有什麼關係。
當然，咱們講講手機端他到底是怎麼個回事。
我們預測方舟的方案是應該是在打包的時間插入了一個架構在ART的運行時，暫時叫他方舟運行時。執行代碼由方舟運行時直接調用機器碼，交於CPU執行，在返回ART或者方舟呈現。
為什麼預測是在ART架構了一個運行時？
ART並不知道你編譯的二進制是可執行的，換句話來說，ART只看得懂字節碼，而看不懂二進制，那麼方舟就能直接調用二進制，繞過ART的編譯。除此之外，華為的想法是其他設備都能使用。由於安卓限權，包括根目錄讀寫限制等等，直接在ART架構一個運行時是最靠譜，並且最合理的。
Java本身就有native方法，那為什麼不直接使用native方法？
Java本身的native方法，最終還是會經過JVM，並且Android的圖像處理/音視頻都是魔改過了，更何況，他們全部方法都會經過native，然後才反饋於ART展示。而經過Java native前後都是需要進行編譯，這樣就造成了時間上的問題。
60%的流暢度提升是否真實？
我們猜測有可能。
正常來說，現在所有軟件，包括PC，移動設備等等，為了降低軟件的大小，編譯所使用的都是動態編譯，目的是將系統本身動態庫與軟件分開，從而降低軟件大小，並且縮短編譯時間，軟件運行的時候再調用動態庫鏈接編譯。這就造成了時間延遲。
不過，除了動態編譯，咱們還有靜態編譯。
雖然方舟編譯器還沒開放源碼，但是大家對此還挺有興趣的。最近和小夥伴討論了下方舟編譯器，並且討論了下我提出的一個猜測，關於編譯器執行代碼的一個可行方案。
ART - Android Runtime
4.4提出，與Dalvik共存，5.0替換Dalvik
7.0更改方案為AOT與JIT混合
7.0的混合模式的意思就是第一次運行時編譯成機器碼，然後利用保存下來的機器碼，去掉無用的，再存起來，供下次使用。
顯而易見，以下便是缺點：
第一，在將字節碼編譯成機器碼也是需要時間的，就算是直接進入堆棧(內存)，那也是有延遲的。儘管那幾毫秒對於人類來說可以忽略。更何況，CPU還是傻傻地，編譯好後會返回ART，等待ART的執行指示，等到執行指示，然後執行好後，依舊得經過ART堆棧，最後才能呈現於前臺。
第二，就算不在使用時利用保存下來的數據進行編譯，那麼在你不用的時候編譯，那就造成了耗電。
那，咱們說說華為的方舟編譯器。
在開發的時候直接編譯成機器碼。
儘管我們不知道他是單個編譯器直接編譯成機器碼還是先讓JDK/AAPT編譯成字節碼後，才轉換成機器碼，但是這個我們都可以忽略，因為這跟用戶並沒有什麼關係。
當然，咱們講講手機端他到底是怎麼個回事。
我們預測方舟的方案是應該是在打包的時間插入了一個架構在ART的運行時，暫時叫他方舟運行時。執行代碼由方舟運行時直接調用機器碼，交於CPU執行，在返回ART或者方舟呈現。
為什麼預測是在ART架構了一個運行時？
ART並不知道你編譯的二進制是可執行的，換句話來說，ART只看得懂字節碼，而看不懂二進制，那麼方舟就能直接調用二進制，繞過ART的編譯。除此之外，華為的想法是其他設備都能使用。由於安卓限權，包括根目錄讀寫限制等等，直接在ART架構一個運行時是最靠譜，並且最合理的。
Java本身就有native方法，那為什麼不直接使用native方法？
Java本身的native方法，最終還是會經過JVM，並且Android的圖像處理/音視頻都是魔改過了，更何況，他們全部方法都會經過native，然後才反饋於ART展示。而經過Java native前後都是需要進行編譯，這樣就造成了時間上的問題。
60%的流暢度提升是否真實？
我們猜測有可能。
正常來說，現在所有軟件，包括PC，移動設備等等，為了降低軟件的大小，編譯所使用的都是動態編譯，目的是將系統本身動態庫與軟件分開，從而降低軟件大小，並且縮短編譯時間，軟件運行的時候再調用動態庫鏈接編譯。這就造成了時間延遲。
不過，除了動態編譯，咱們還有靜態編譯。
靜態編譯的方法跟動態編譯相反，在編譯的時候，將所有所需要的動態庫內容，直接載入軟件內，那麼就降低了運行時鏈接動態庫的時間。
但是！60%應該只是實驗室的測試，要求的是極端測試環境，例如CPU完全沒事幹，內存空閒，沒用毒瘤在後臺跳等等極端環境下，才有機會實現。在日常使用上，我預測應該只有30~50%的提升。
並且，華為自己的設備完全可以在系統直接插入一個方舟運行環境，抑或是一定的配置，遇到有方舟編譯出來的應用，直接跑機器碼，直接無視ART/JVM，利用自己本身的運行時呈現。
這是在沒有源碼的情況下根據多設備都能運行的原則，並且使用官方的說法，而預測的可能性。
在源碼公佈的時候才能知道是否如此。
那麼，在8月9日源碼公佈的時候，我會盡快讓大家知道，方舟底層到底是怎麼運作的。