Android 工程師如何終結碎片化問題？

距 Android P 正式版還差一步，化零為整的碎片化問題即將解決。

距離 Google 發布 Android P Beta 2 以及終極版 API 不到一個月，近日Google 再次推出第四次更新，Android P Beta 3 版本現已面向開發者開放。

Google 表示最後一個測試版最終確定了開發者為其 App 所需的所有 API、最新的 Bug 修復、穩定性優化以及安全更新，且這個測試版將更接近預計今年夏天即將發布的 Android P 正式版。

Android P Beta 3 還為 Android Studio 構建工具帶來了更新，將 D8 作為獨立工具。想要使用新 API 構建，將官方 API 28 SDK 和工具下載到 Android Studio 3.1 中，然後將項目的 compileSdkVersion 和 targetSdkVersion 更新為 API 28。此外，Android P 的新功能還包括多攝像頭支持、凹口屏幕適配、更好用的推送通知、ImageDecoder、TextClassifier 等等。

▌適用機型

與過去幾年相比，在 Project Treble 下，Android 公測項目可在更多設備上使用：

除谷歌的 Pixel 設備外，Android P beta 還可在索尼 Xperia XZ2、小米 Mix 2S、諾基亞 7 Plus、Oppo R15 Pro、Vivo X21、OnePlus 6 和 Essential PH-1 上使用。

那麼為何有史以來，Android 開發者預覽版第一次可發布在除 Google 自家的 Pixel 機型外的其他設備上，當然，這其中就涉及到了上述提到的 GoogleTreble 項目概念問題。

▌何為 Treble 項目？

隨著去年 Android 8.0 的發布，Google 向全世界宣布了 Treble 項目。Treble 是 Android 有史以來最大的工程之一，將 Android 操作系統與硬體分離開來，極大地減輕了更新設備所需的工作量。它的目標就是解決 Android 一直存在的碎片化問題，而在 6 個月之後的今天，這個項目似乎起到了很好的作用。

今年的整個 Google I/O 大會到處可見 Treble 革命效果。Android P beta 版發布，不僅限於 Google 自己的 Pixel 設備，Android 的開發者預覽版也可發布在上文所述的設備之上，這都要歸功於 Treble 項目帶來的兼容性。就連汽車製造商這種地球上對新技術最不敏感的物種，都搭上了 Treble 項目的快車。道奇和沃爾沃都有用 Android 作為信息娛樂系統的原型車，而兩者都採用了 Android P。

而接下來，我們從外媒 ARS 採訪Treble 項目的負責人 Iliyan Malchev 和 Android 工程副總裁 Dave Burke 的訪談過程中，剖析 Treble 項目解決碎片化問題的手段以及一窺 Android 的未來。

▌伴隨 Android P 而來的 Treble 項目

首先來回顧下 Treble 項目的近況。

Iliyan Malchev：Treble 將操作系統分離到一個適配層中，這個適配層根據硬體進行了裁剪。這一點依然保持不變，但細節才是最重要的。我們仍然需要改進許多東西，這正是我們這次 Android P 發布中的重點。關於 Treble 目前的情況，我想許多媒體沒有注意到的是，現在任何預裝 Google 應用的設備，任何發布時安裝了 Oreo 或更新版本的設備，都必須能流暢地運行一個用於認證的 Android 二進位映像。

這個映像並不是產品。我們的意圖並不是發布這個映像，而是通過強制任何設備都能運行這個「標準映像」，我們要建立一種向心力，以較為柔和的方式防止合作者們做出對他們的標準沒有太大意義的改動。在今年的 Android P 中我們完成了技術部分，現在我們開始與晶元廠商共同完成下一步。

Dave Burke：對，我想這才是最大的變動。在完成技術工作之後，我們需要實際地向晶元廠商推行這一工作，這項工作帶來的變動十分巨大。

Google 的「 Android 發布的生命周期」

Malchev：我們在台北、韓國和聖地亞哥分別與聯發科、三星和高通合作。我們將我們的成品嵌入他們的 BSP（Board Support Package，板級支持包）。高通等公司拿到我們發布 AOSP（Android Open Source Project， Android 開源項目）之後，就將其嵌入到 BSP，再交給設備製造商。 BSP 才是設備的起點。設備不是從 AOSP 開始做的，因為 AOSP 自身並不是個完整的產品。

正如 Malchev 所說， Android 的開源部分（AOSP）只包括操作系統代碼，並不能在任何硬體上運行。板級支持包（BSP）和 AOSP 結合在一起，再加上其他必要的代碼，才能讓 Android 在某種硬體上運行起來。這就像是 Linux 內核與驅動程序的關係一樣。如上圖所示，Google 發布 AOSP，高通等 SoC（System on a Chip，系統晶元）生產商將 AOSP 與特定版本的 Android Linux 內核及驅動程序結合在一起建立 BSP，然後 OEM 廠商將 BSP 載入到手機上，再加上硬體和軟體方面的定製。

Malchev：我們這次解決的問題就出在 BSP 上。因為如果我們八月份發布 AOSP，然後高通用三個月時間發布 BSP，這就接近年底了，設備製造商就完全沒有機會了。所以我們將所有這些工作都吸收進來，使之在 Android 內部開發階段同時進行。

Burke：其中一個例子就是 Telecom 和 Telephony。我們在上游做了多少改動？很多很多。

Malchev：對，所以除了這些之外，我們還將原本由合作夥伴完成的大約 150 個功能吸收到了上游，讓 AOSP 更像一個完整的產品。這一點非常重要，因為長期維持這些代碼的成本非常高。

這裡的「上游」的意思是「OEM 製造商的上游」，即 AOSP。Malchev 的意思是，他們在 AOSP 里包含了許多第三方收集的代碼，這樣 OEm 廠商就無需再維護太多代碼了。

Treble 項目基本上就是按照公司分割 Android 系統（圖中以不同顏色表示）。Google 是 Android 平台供應商，高通則是典型的 SoC 供應商，而三星等公司則是 OEM 或 ODM。

Burke：另一個巨大的變動就是工作流程。晶元製造商（目前就是我們支持的這三家）實際上會為 AOSP 提交代碼。所有公司都在同一個代碼倉庫上工作。這是我們合作方式上的巨大變更。以前，我們先把 OS 做到某個階段，然後晶元製造商拿到代碼再開發至某個階段，最後設備製造商再開發至某個階段，這一切都是串列的。現在，我們可以與晶元製造商在同一個代碼上並行工作。我們發布的 Android P 的 RC 版，他們稱為「CS 版」，即「商業樣品版」（Commercial Sampling），他們也同時可以發布了。這就是巨大的變更。

Burke 和 Malchev 所說的就是我們在 I/O 大會上看到的 Android P Beta 版的發布。Google、高通和其他 SoC 廠商以及 OEM 廠商都在全力合作，把新的 Android 版本帶到設備上。以前，「串列」的開發過程意味著每個公司必須等待前一家公司完成之後才能開始工作。現在，只要 Android 中的軟硬體之間有了穩定的借口，任何人都可以同時工作，讓新版本的 Android 運行在某個硬體上。

關於現在的情況，Google 甚至還給了我們這句來自 Essential 的話，讓我們得以了解適配 Android P 大概需要多長時間。

「確保Essential 的用戶使用最新的 OS 更新，對於我們極其重要。現在我們通過 Treble，在 Oreo 上實現了製造商和系統的分離，我們的小團隊只用了三天就成功地在 PH-1 上跑起了 Android P。」——Essential 軟體開發副總裁 Rebecca Zavin

Essential 的手機可能是升級的最好例子：它的設備與 Treble 項目兼容，運行原廠的 Android 系統，所以無需做任何軟體改動。但是，三天完成系統移植，這個進度仍然快得不可思議，因為許多 OEM 都要花費幾個月才能完成升級。

Malchev：不過這僅僅是冰山一角。Dave 剛剛提到了與晶元製造商合作，這意味我們都需要大幅度改變工作流程。高通為 Android 工作的部門有 6000 名工程師。對於 Treble 項目，他們緊密地在我們的基礎設施上與我們合作。所以我們能共同保證他們的 BSP 是最新的，我們還確保在 Android 完成時，他們的 BSP 也立即可用。這涉及了數不清的變動。我們與聯發科和三星半導體也做了同樣的事情。

對於 Android P，許多人已經成功地在某些設備，比如華為手機上運行了 Android P，它原本是個深度改造的 Android ，只需用 AOSP 替換掉，就能用了。

Malchev：我在看到第一個報告時感到很高興，因為這是來自設備廠商之外的證據，證明了通用框架是最佳選擇。現在自定義固件極其容易的原因就是，我們為了 Treble 兼容性而強制要求的通用映像，正是自定義固件的基礎。所以就算我們不發布任何關於如何創建該映像的說明，它基本上也是個開源的 Android 。

Burke：之前的情況是，設備製造商要想生產兼容的設備，就必須通過 CTS，即我們的兼容性測試套件（Compatibility Test Suite）。現在他們必須在晶元實現之上的「標準映像」的基礎上去通過 CTS。

「標準映像」是指 AOSP？它必須能啟動，並且能正常使用一切功能？

Burke：是的，它必須通過所有這些 CTS 測試，大概有八百多萬條測試用例。都必須通過這個標準映像來執行。

2014 年世界移動大會上的一台高通測試機（右）。旁邊的是 Nexus 6（左），世界上最大的商用手機之一

Malchev：這就是所有手機的祖先。或者說，每個使用這片 SoC 的手機，就是說使用驍龍 845 的手機，基本上就是這台機器的複製品。就像個人電腦一樣，只不過每個晶元都有自己的一套體系。這一台運行的是帶有高通的功能的 Android P。基本上這就是個運行 Android P 的 BSP。OEM 廠商可以在它上面做自己的設備了。

而要問我們做了什麼來支持自定義固件。他們是從 Oreo 開始做的，對吧？那正是我們這次發布所做的。在 O MR1（ Android 8.1）和 P 中，我們改進了 Treble。從自定義固件的角度來看，在廠商範圍內支持 Android 的未來版本基本上是零工作量。所有工作量都緊緊密封在 P 中。而在 Oreo 中，你得在我們所稱的 VNDK（Vendor NDK，廠商 NDK）上做一些工作，你上一篇關於 Treble 的稿子也提到了。Oreo 中的 VNDK 的完成度並不高。但在 MR1 和 P 中我們完成了 VNDK。感覺就是，我們擰緊了幾個螺絲。

事實上很難。頂層和底層之間的界限非常非常長，而且二十分曲折。因此，定義這個便捷並強制推行需要極大的努力。我們能自動化的工作越多，它就會越好。我覺得我們已經完成了自動化的部分。

關於廠商 NDK：Treble 項目的工作原理是給 Android 的每個子系統一個 HAL（硬體抽象層）。這些是 Google 和硬體廠商共同定製的標準介面，比如可以讓 Android 的照相機代碼運行在廠商的照相機硬體上。Android Oreo 中大約有 60 個 HAL，分別是照相機、音頻、地理位置等等。Oreo 中這些 HAL 並沒有覆蓋所有設備類型，因此為了讓硬體廠商能為自己的設備類型編寫 HAL，Google 給 Android 加入了廠商 NDK。想像一下比如三星 Galaxy S9 中的視網膜掃描——如果視網膜掃描器不是 Android O 官方支持的設別類型，三星就要利用 VNDK 定義自己的設備類型。Android P 中的設備類型更多，因此軟體開發商和開發者的工作量更少。

Treble 最終發布後有沒有讓你們感到驚訝的事情？

Malchev：當你創造並堅信的理論被證實正確時，那種感覺非常好。我第一次聽到設備廠商之外的正面反饋時，感到十分激動，因為，不論你自己多麼堅信，總會有那麼一絲懷疑。

但通過來自於開發者的反饋，我們開始十分自信！太不可思議了。這與製造商的反饋完全不同。我們在 Android 中做了些很特別的事情，然後該他們做他們的特別的事情，以發布 beta 版，證明了我們到目前為止的工作足夠他們完成他們的工作，並在年內實現發布。

開發者在如此眾多的手機上給出反饋的事情每年都會發生？

Malchev：對，我希望以後只會越來越多。

Burke：對，我覺得是。而且時機很有意思。我感覺，整個行業已經越來越成熟，性價比已經成為 CFO、設備製造商和晶元製造商們越來越關心的事情。他們會看著我們的工作然後說，「哦，我要是直接使用標準映像，不做任何改動，似乎能省很多錢？好，那就這麼干。」以前最開始時他們會說，「哦這是開源的，我們來做點東西吧！」但現在他們意識到，他們最好是只做小改進，復用已有的東西。如果你看看 streamline 是怎樣在硬體領域改變了整個 ODM 行業的，那麼我們就是想在軟體領域做同樣的事情。

Malchev：那句「Be together, not the same」的意思就是，我們不想強迫所有人都一致，但這種靈活性不需要付出修改大量源代碼的代價，是吧？因為每次重新編譯 Android ，都會花掉無法估計的錢去驗證並測試。

▌Android P 有什麼新特性？

Google I/O Keynote 上的 Android P 的新特性

Google Play 商店中的應用必須以最新版本的 Android 作為目標版本。如果所有應用都能在最新版本上運行的話，意味著不需要再支持大量過時的 API，那麼這會不會改變你們對 Android 未來版本的看法？你們會逐步關閉舊的 API 嗎？

Burke：這個問題很有意思。我的回答是，這不是我們的主要目的。主要目的只是讓應用開發者使用最新的功能。例如，在 Marshmallow（Android 6.0）中引入運行時許可權時，許多應用的目標都是 pre-N（Android 7.0），而當時這種情況不應該發生。 所以其實這是個我們沒控制好的環節。我們在引入這個規則時考慮了許多情況。現在的結果是，8 月份之後新提交的應用必須遵守該原則，而已有的應用必須在 11 月之後完成更新。

我覺得有個很有意思的問題，比如說想想未來幾年的事情，再想想 32 位和 64 位的問題。你當然可以改變應用的生態系統以便隨時緊跟晶元的發展。這種情況給了我們一些改變的動力，但並不是我們的主要目標。

你這個問題提得很對，這的確是個刪除舊 API 的好機會。只不過，我們最不願意做的事情就是放棄開發者。建立一個成功的應用十分困難，這正是建立業務的最大的挑戰。我們最不願意做的事情就是為難別人。從另一個角度來看，每個人都可以按照自己的意願前進，因此我們會全面考慮這個問題，嗯，對，這會給我們一些選擇，但還是那句話，並不是我們的主要目的。

Android P 會支持 Wi-Fi RTT 嗎？這個不是在 Android 5.0 就支持了嗎？我記得有個 RTT 管理器是吧？

Burke：對，以前就有。這個是 802.11mc。以前只給系統使用，但現在我們加上了公開的 API，所以應用也可以使用 RTT 的信息了。

所以說以前不是公開的，而現在公開了？

Burke：對。以前不對第三方應用開放，而現在開放了。稍後會有個演講是關於米級定位的。我記得那個演講里有一段室內導航的視頻，酷極了。那個視頻就像是，一個人在樓里隨時進行定位，而一切都只需要通過 RTT 實現。這個點子確實很棒。

難點之一就是，這個點子看上去似乎很容易。其實是，嗯，是兩個方向上的 RTT。你的手機發給無線訪問點（AP）一條消息，AP 給消息加上時間戳然後返回給你。光速是已知的，這樣就能計算出距離。但實際的問題是，要想知道具體位置，你得給多個訪問點發消息，而難點是，這些消息並不會同時返回。所以你得解個約束方程才能知道你在哪兒，我記得這個叫「多點定位」（multilateration）吧。這個確實太酷了。

確實有個關於 Wi-Fi RTT（Round Trip Time，來回通信延遲）的 Google I/O 演講。GPS 需要能看得到天空，並且精度只能到大約 5 米左右，但如果附近有多個 Wi-Fi 熱點的話，Wi-Fi RTT 能提供更好的定位，最終的精度能到達１～２米左右。室內導航的視頻大約在演講的 5:30 開始。Android P 不僅會開放 802.11mc API 供開發者直接使用，還會將其包含在 Google 簡單易用的「混合位置服務」API 中，從而自動通過多個信號源（GPS、Wi-Fi、蜂窩網路、陀螺儀）確定位置。

儘管 Android 會支持 Wi-Fi RTT，你還需要幾台支持 Wi-Fi RTT 的路由器，或者叫信標（Google Wi-Fi 在今年年底會支持 802.11mc），而且還得知道這些 Wi-Fi 熱點在地圖上的位置。在 Google I/O 的 RTT 演講中，Google 提到他們打算以後以眾包的方式提供 Wi-Fi 路由器的位置，以讓 RTT 變得更實用。Google 地圖目前已經用眾包方式提供不太精確的 Wi-Fi 地點了。

以前在 Android O 中有個開發者選項，可以切換 GPU 渲染方式為「default」或「Skia」。現在這個選項沒有了，我記得 Android P 默認運行的就是 Skia 吧？

Burke：以前 Android 的標準窗體不支持硬體渲染的。基本上是建立在 Skia 之上，而 Skia 是軟體渲染。同時我們還做了個「GL 渲染器」，是基於 OpenGL 的。所以以前有兩種方法。系統里有一種使用硬體加速器的方法，這得放棄 Skia 去使用 GL 渲染器。而其他部分可以使用 Skia。不過說來話長，其實一部分 GL 渲染器也在使用 Skia。聽起來是有點怪。

Malchev：一些 Skia 在慢慢地遷移到 GL 上，但並不是所有的都遷移了。

Burke：我們在給 Skia 做一個 GL 後台。我們在清理架構。簡單來說，整個架構的目標是讓 Android 的 UI 框架直接與 Skia 對話，然後 Skia 負責與硬體加速的後台對話。而不是像現在這個奇怪的世界一樣，一些窗體得自己去找 GL 渲染器。這就是我們要清理的東西。我只是想不起來這是 P 里的功能還是以後版本的功能了。我記得還沒完全完成呢，但這是我們的目標。源代碼里看得見，也不是什麼大秘密。

題外話，Skia 是個主要由 Google 開發的開源圖形引擎。在演講中提了幾個問題之後，我得到了更多的細節，如 Skia 能加速 Material Design 里廣泛應用的陰影渲染等。希望我能找到個更完整的答案，不過研究過程的第一步走得不錯。

更新：在這次訪談結束後，Burke 澄清 Skia GL 後台實際上在 Android P 中已經完成了。

為什麼 Android P 的 API 里有個新的指紋讀取 API？舊的有什麼問題？看上去似乎沒問題。

Burke：有好幾個原因，但最主要的是我們看到一些設備製造商（如 Vivo）希望支持屏下指紋識別。所以你得有個標準的 UI，否則其他應用就亂了。如果能回到當初我們肯定會這麼做，如提供標準的系統對話框，這樣廠商們就能採用了。

就像是「請按這裡」一樣的 UI？

Burke：是的。這就是主要的原因。而且新 API 對生物識別提供了更通用的支持，因為以後會有越來越多的生物識別技術，所以這也是主要原因。所以，現在「FingerprintManager」API 已經不建議使用了，改成了「BiometricPrompt」。

應用會「亂」這個點不錯。屏下指紋識別會要求在當前應用上彈出一個窗口，而手指放上去不能觸發應用本身的東西。由於 Android 安全原因而鎖定了浮動窗口，因此沒有 Google 的參與和標準的 API，這個彈出窗口就很難實現。

Dave Burke 喜歡更長的續航時間，我們也喜歡

關於後台 Activity 的改動。你們現在會利用 AI 來更激進地關閉應用嗎？

Burke：對，我們想盡量節省電池。有四個桶，第一個桶里是未來三小時內會用到的應用，最後一個桶是至少 24 小時之內不會用到的桶，中間的以此類推。然後我們利用 AI 根據用戶的使用習慣來預測哪個應用放到哪個桶里。每個桶里的應用對於網路和 CPU 的訪問級別都不一樣。因此簡單來說，我們希望系統中只有那些馬上會用到的應用才能更多地使用電池、網路和 CPU。

上述提及對手機的「訪問」，是指 JobScheduler 窗口嗎？

Burke：對，基本上就是 JobScheduler 窗口。為什麼要更新 API，因為我們想把所有應用都放到 JobScheduler 下，這樣就能統一管理，而不是像以前那樣。

這個其實很有意思。我們其實可根據每個人的使用習慣訓練個模型，它能告訴你使用 Twitter 的習慣。但我們不想這麼做，所以我們在設備內部精心打造了一個系統。它有個通用的使用模型，當你使用手機時，我們會檢查你的使用情況。比如說，你正在用 Twitter，我們就會檢查你怎樣用 Twitter，然後找到最接近的模型。其實更像是個性化，而不是在設備上進行訓練。而保證在設備上完成這切，可以解決很多隱私方面的問題。

JobScheduler 是從 Android 5.0 Lolipop 開始，作為 Volta 項目的一部分提供的 API。它守護著後台 CPU 活動和網路訪問的使用情況。應用不是自己去訪問網路，而是交給 JobScheduler，後者將不重要的請求放到後台做批量處理，從而讓設備能休眠更長時間，以節省電池，然後在特定的窗口內定期喚醒設備供所有應用的後台活動使用。以前，JobScheduler 還負責關閉那些不使用的應用，但現在 Android P 有了「自適應電池」（Adaptive Battery）功能，似乎將會有個更合理的功能負責根據應用的使用情況來關閉應用。

▌Treble 項目感悟

Burke：我個人花費了很多時間與設備製造商和晶元製造商打交道，他們都很喜歡 Treble 項目，貌似對他們來說這是最大的改進。這個項目很難，它涉及了太多部分，而且要求團隊里每個人都必須做出改動，包括媒體框架、位置服務、UI 工具包等等。我們投入了相當大的經理，這就是為什麼在 O 中我們推出的面向消費者的功能較少，因為我們的工程預算都花在了 Treble 上。

而在 P 中，我們又開始提供更多面向消費者、面向普通用戶的功能。但是，最棒的不僅是這次發布有許多新特性，而且我們終於可以收穫 Android O 時的投入，讓設備製造變得更快了。

Malchev：更重要的是，我們需要引導 Treble 的企業化過程。我想指出的是，只有與全世界的大公司通力合作，我們才能證明這個過程。一旦我們證明了 Treble 能在任何設備上運行，他們就會越來越多地接納 Treble，直到所有人都使用 Treble。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！