Android为毛出现Treble架构_支持treble和不支持treble-优快云博客

前言

Android 8.0 版本的一项新元素是 Project Treble。这是 Android 操作系统框架在架构方面的一项重大改变，旨在让制造商以更低的成本更轻松、更快速地将设备更新到新版 Android 系统。
有人告诉我android系统多出了Treble架构后，我查询到以上谷歌官方的宣言。Treble这个名词，让我开始以为是很新的东西。但是仔细研究后，发觉Treble还是建立在已有技术上的。当然，谷歌弄出Treble的真实原因到底是什么呢？先从Treble带来什么开始吧。

Treble带来了什么

1. 多了一层IPC（binder）

以前版本的老版本中通过dllopen打开so库，或者干脆直接依赖编译连接so库，达到调用so库中的函数的方式，将被binder实现的IPC( 进程间通讯)的方式替换掉。
尽管，为了兼容老版硬件升级，任然保留了以前的老的调用方式，但是不可避免的，在今后的android系统升级中，新的硬件只要上了新版本的android系统，必然使用treble建议的IPC方式。

2. 性能必然有损失

很多开发者觉得，性能上没有影响，实际上是错误的，多一层IPC，必然带来额外的内存拷贝和CPU占用，当然这个是相对以前dllopen或者直接连接so库来说的。
为什么大部分的系统开发者感觉不出性能上的下降呢？想一想，Android1.X版本的时候，为什么没有上treble架构呢？没有binder吗？不是，最大的原因是现在的硬件性能相对以前有很大的提升，无论是SOC的多核，亦或IO的性能，覆盖住这多出的IPC资源占用是绰绰有余的。

3. HIDL接口定义语言

出现了HIDL，以及后面一整套相对应的代码生成工具，和必要的接口实现方法。勤劳的android工程师们又要开始学习了。其实，说到底还是binder，设计思想和实现方式变化不大。至于为什么用binder？这个涉及到binder的前世今生。我会有另外的文章去解释。

引入Treble的目的是什么

1. 将framework层与hal层之间的界线划分更清晰

1.1 法律上的考虑

依然在想办法隔离IP的传导，无论是自上而下的，亦或是自下而上的，直接编译连接so库或dllopen，上层的framework层和so库跑在同一进程里，很容易引发IP（知识产权）纠纷。
谷歌的哲学：自己不作恶，但也不妨碍别人作恶。之前版本的dllopen的搞法，就有脱离对底层so库依赖的趋势，只不过IPC做的更彻底。当然，是否用IPC调用so库，就能防止IP的传导？我们不清楚，不过谷歌一直都擅长：引导法律关于软件IP的解释。

1.2 安全上的考虑

做出IPC层，并且还划分了不同的域，对进一步细分访问权限是很有好处的。

1.3 测试上的考虑

有了这个IPC层隔离，测试起来更方便，针对HAL层上的Treble层测试就好，以前想要测hal层，还是很麻烦的。主要还是缺乏统一的接口。以前的情况是：硬件稍微不一样，必然导致HAL层的测试用例需要修改重写。现在编写一次后，基本能cover住大部分的HAL层。

1.4 HAL层的由来

HAL的历史说来话长，它最早是出现在linux系统世界里的，比Android系统的出现要早很多。
但是从HAL出现以来，HAL层和framework层的界线确实很模糊。比如：直接依赖编译HAL的so库，或者dllopen打开的，甚至有socket通讯贯穿的，当然还有其他IPC方式从framework调用到HAL层的搞法。确实比较混乱。
谷歌确实是在想办法梳理framework和HAL之间的关系，Treble就是努力地尝试之一。只不过统一成binder的IPC调用，是否是最佳实现，现在还不好说。

2. 有什么感觉不好呢

2.1 防止碎片化

让制造商以更低的成本更轻松、更快速地将设备更新到新版 Android 系统。
真的更轻松吗？大家都知道，Android系统的真正优势在于开源，因为可以修改定制，所以会有千千万万的变化的版本出现。这个是特例独行的现代人喜欢的。即使外壳类似，但是里面的OS变化很大，带来各自众多的粉丝群体。
由于Treble的带入，将HAL以上这部分的开发固化下来了，不是不可以修改扩展，而是修改扩展的成本变高，变麻烦起来。对于追求变化的手机系统厂商，Treble是一个不小的麻烦。（注意，以后的新版本，binder方式的Treble才是大趋势。）
当然，从谷歌的角度看，防止碎片化，是一个必然的措施。