YVR18資料關注點3：Treble
Treble方案在Linaro推了3年，從一開始誰都說不清楚是什麼，現在再看，看起來比較成熟了，雖然我自己不做手機方案了，但現在有人想到要「在伺服器領域也可以學習Treble的優秀實踐」，所以我也來總結一下Treble方案的核心在什麼地方。
Treble現在比較完整的敘述在這裡：
https://source.android.com/devices/architecture/它的目標現在也比較清楚了，是要把Framework部分完全獨立出來，讓升級Framework不需要跟著下面Vendor相關的部分相對獨立。
Treble提供了類似以前CTS兼容性測試套件類似的VTS前向兼容測試套件對兼容性進行測試。
Treble兼容性通過升級的HAL層實現，為此引入了一種HIDL語言來描述兩者之間的關係，定義了兩種HAL：
綁定式：主要用於流量不大的介面，基於Binder進行通訊
直通式：主要用於流量大的介面，基於傳統的調用進行通訊，有可能是在同一個進程內(SP-HAL），也可以通過共享內存來實現（比如傳統的HWComposer）
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的方式提供驅動，然後嘗試把通用內核和驅動放在vboot分區上，Soc相關驅動放SoC分區上，ODM的相關驅動放在ODM分區上。希望可以獨立升級通用內核部分，我個人不是很看好這種模式。我認為他們升不了幾個版本的。
從星期五的KeyNotes上看到，Google對於統一內核的主要考量是質量，他們認為沒有持續維護，代碼的安全令人擔心。但他們也承認這個問題在於，SoC的生命周期太短，這是影響廠商投入到代碼主線化的動力。Android Common版本的質量保證用例主要來自兩方面：LTP和VTS（Vendor Test Suit，通過sysfs激活Android相關功能）。
我個人不太認可這種實踐可以用於伺服器的。所謂介面穩定，前提就是介面沒有改進需求了。是改進期望影響了介面的穩定性，而不是介面穩定性的需求決定了如何改進。在PC領域，很早就實現前向兼容了，而在幾乎一樣軟體棧的伺服器領域，到現在都沒有完全實現前向兼容。是因為在現在這個階段，伺服器還在拼性能，所以很多東西都還在修改，這種情況下主動去把介面穩定下來，這是自己找死。
Treble花了三年成了現在的樣子，有一個很重要的要素是這兩年AOSP已經玩不出什麼花樣了，你一個介面隨你玩一兩年都是一個樣子，收縮起來是有意義的，但如果你不是，那就是自己束縛自己了。
對了，演講207中提到Treble把SELinux作為基礎的安全保護錯誤，避免system和vendor的代碼可以訪問其他分區。這個有空到是可以看看具體是怎麼設計的。
推薦閱讀：
