此地是为了记录我分析 Android 6.0 图形系统的成果而写的一系列文章：Android图形系统设计的分析。
最初源于一个简单的想法：既然Android都已经开放了源码，为什么没有人能把它的工作原理讲清楚？折腾一阵之后，问题变成了：哪怕是讲清楚一部分，例如图形系统，这个有多难？最后归于一个简单的目标：假如给我资源，我能不能设计(抄写)出一个类似的图形系统？
结论是：这是有可能的，但是有巨大的挑战！
收获是：
- 图形系统涉及到很多方面。
- 有算法方面：解析几何/矩阵运算，Porter-Duff的合成算法，颜色空间算法。
- 有OS方面：Zero-copy / File handle transform. Heterogeneous architecture. Cross-process calls to the object.
- 有C/C++：如何设计接口(interface)，设计类。如何使之在C/C++环境里通用。
- 有工程方面：架构模式和设计模式。
- 做工程，涉及到很多细节。不是知道一个大概就过得去的。一个细节不到位，系统就跑不起来。而这样的细节成百上千个。
- 做大型软件工程，一定要讲规范，讲架构，讲设计模式。复杂度一定要用方法和工具控制起来。
- 一定要让自己的每一行代码平淡无奇。系统已经够复杂的了，如果在代码细节里耍花枪，只能让自己死得难看。
未知的是：不知道这个系统是怎么开发出来的！
也就是，我不知道这个系统是怎么做出来的！举个例子就是，我可以知道汽车发动机各个零件的用途，用测量工具测绘各个尺寸，我可以用逆向工程画出零件的图纸。但是给我一个工厂，我未必能再造出一台发动机来。也就是我不知道生产工艺是什么。
在这种大型软件工程里，设计师/架构师和开发工程师是怎么配置，规模多大？划分成什么样的小组和职责？设计师/架构师曾经考虑过什么方案，最终为什么选择了这个方案？工程又是如何推进的？
一切都要靠摸索。我和国外的设计师/架构师还是有很大的差距。