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的程式碼可以訪問其他分割槽。這個有空到是可以看看具體是怎麼設計的。