YVR18資料關注點3:Treble
Treble方案在Linaro推了3年,從一開始誰都說不清楚是什麼,現在再看,看起來比較成熟了,雖然我自己不做手機方案了,但現在有人想到要“在伺服器領域也可以學習Treble的優秀實踐”,所以我也來總結一下Treble方案的核心在什麼地方。
Treble現在比較完整的敘述在這裡:
ofollow,noindex"> https:// source.android.com/devi ces/architecture/ https:// source.android.com/devi ces/architecture/images/VNDK.pdf它的目標現在也比較清楚了,是要把Framework部分完全獨立出來,讓升級Framework不需要跟著下面Vendor相關的部分相對獨立。
Treble提供了類似以前CTS相容性測試套件類似的VTS前向相容測試套件對相容性進行測試。
Treble相容性通過升級的HAL層實現,為此引入了一種HIDL語言來描述兩者之間的關係,定義了兩種HAL:
繫結式:主要用於流量不大的介面,基於Binder進行通訊
直通式:主要用於流量大的介面,基於傳統的呼叫進行通訊,有可能是在同一個程序內(SP-HAL),也可以通過共享記憶體來實現(比如傳統的HWComposer/">Composer)
HIDL本質上是對Binder介面的封裝,原始檔用hal做副檔名,很類似過去Binder的Java介面定義檔案,像這樣:
interface IBar extends IFoo { // IFoo is another interface // embedded types struct MyStruct {/*...*/}; // interface methods create(int32_t id) generates (MyStruct s); close(); };
如果是繫結式或者共享記憶體式,Framework和HAL間就是IPC呼叫,如果是SP-HAL方式,就變成dlopen,然後直接進行相關的本地呼叫。
在核心上,Treble推出了一個公共的主線: https:// android.googlesource.com /kernel/common/ ,但從介紹材料上看是推薦性質的,還沒有能力讓各家都使用同一個核心,這應該是一個合作效率的問題。Google在Linaro上的專案是要拉著幾個主要的供應商一起維護這個核心,但以AOSP現在的升級速度,我覺得真正實現這個會比較困難。
Treble要求各家必須使用ko的方式提供驅動,然後把這些ko放到一個稱為Vboot的分割槽上,根據描述檔案進行動態載入。
我個人不太認可這種實踐可以用於伺服器的。所謂介面穩定,前提就是介面沒有改進需求了。是改進期望影響了介面的穩定性,而不是介面穩定性的需求決定了如何改進。在PC領域,很早就實現前向相容了,而在幾乎一樣軟體棧的伺服器領域,到現在都沒有完全實現前向相容。是因為在現在這個階段,伺服器還在拼效能,所以很多東西都還在修改,這種情況下主動去把介面穩定下來,這是自己找死。
Treble花了三年成了現在的樣子,有一個很重要的要素是這兩年AOSP已經玩不出什麼花樣了,你一個介面隨你玩一兩年都是一個樣子,收縮起來是有意義的,但如果你不是,那就是自己束縛自己了。
對了,演講207中提到Treble把SELinux作為基礎的安全保護錯誤,避免system和vendor的程式碼可以訪問其他分割槽。這個有空到是可以看看具體是怎麼設計的。