历史的进程

Android的View和渲染架构是个很有意思的话题，Romain Guy, Chet Haase这两位Google工程师每隔一两年都会在Google IO上介绍Android渲染架构的最新进展，最早也最有意思的的演讲是2011年的：
https://www.youtube.com/watch?v=v9S5EO7CLjo&t=718s
2011年，Google改进了Android的渲染架构，向iOS看齐，利用GPU做界面渲染并对Android Canvas进行了抽象以同时支持GPU渲染和软件渲染，2.3 IceCream Sandwitch之后的4.x版本起，Android终于不再有非常严重的渲染延迟。随后，Android逐渐改进Canvas实现，让几乎所有API都能够利用GPU来绘制，并且默认的渲染模式也从软件渲染改为了硬件渲染。

https://www.youtube.com/watch?v=NYtB6mlu7vA
2013年，Romain Guy介绍了Android的View架构，介绍了Android的measure、layout、draw是如何工作的，并现场教我们用最简单的方式实现一个FlowLayout。

https://www.youtube.com/watch?v=zdQRIYOST64&t=1728s
2018年的演讲从整体上深入浅出的介绍了如今Android的渲染架构。

Skia是硬渲染，还是软渲染？

在2011年左右，国内的Android还是2.3主导，如果我们查找2011年左右的文章，会看到当时Android的图形渲染是采用CPU渲染的，用的是Skia库，当时虽然GPU已经普及了，并且Android也实现并提供了OpenGL API，但是当时的Android View架构并没有使用硬件渲染。
当时看到相关资料时，让我产生一个比较固定的印象：Android卡顿是因为使用了软渲染，使用了Skia库，Skia库是一个软渲染的库。
后来，Android为了优化显示性能来和iOS对抗，引入了一条完全不一样的渲染机制，Android团队自行利用OpenGL API实现了Android View架构使用的Canvas API，当开启硬件加速时，Canvas API会利用新的OpenGL实现，不再使用Skia了。
但是，Skia毕竟也在不断发展，软渲染效率低，Skia也会提供硬渲染能力。当年或许是因为Android优化刻不容缓，Android团队得到的资源更多，没空和Skia协调，先自行实现了Android用到的Canvas API（大如Google这样的公司，团队间的协作想必会有很大成本吧）。但是，到了现在，Skia已经把可能用GPU加速渲染的API都进行过优化了，而且如今的CPU性能相比以前也有了成倍提升，少数难以使用GPU支持的API依然使用CPU渲染也不成问题。
从Google的角度来看，最好公司内的团队不要有太多重复工作，长远来看Android维护一套渲染方案，Skia维护一套渲染方案，肯定是不合适的。未来，Google旗下的所有产品底层渲染都会使用Skia API，不如将Android维护HW Rendering API的开发人员调去Skia，两边取长补短，未来Android也采用Skia渲染。如今Android和iOS差距已经拉平，是时候偿还技术债务了。于是，我们看到Android的渲染方案里，除了传统的HW方案，又出现了HW Skia方案。猜想这应该就是Android正在利用Skia API替换掉Android内之前自行维护的HW Rendering API。