注：这一部分内容需要对浏览器实现有所了解
自顶而下的树排版模型
团队一步一步走过来，习惯使用纯粹的 SQL 来设计表和执行查询，为了满足非常丰富复杂的查询需求，我们的 SQL 可以写成几百行甚至上千行。
刚开始的时候，需求变化非常快，想法圈在整个产品发布前迭代了接近 30 个版本，几乎两周一次推倒重来，我们开始考虑如何在已有的基础上做一些抽象工作以减少劳动力。
外面很多的数据框架不能照搬过来用（很难满足如此快速复杂的变化，学习过程可能是指数增长），反思我们的初衷，是一个能够辅助目前工作的小工具，简单做这么几件事情就好：
Android 不仅系统版本众多，机型众多，而且各个市场都各有各的政策和审核速度，每次发布一个版本对于开发同学来讲都是一种漫长的煎熬。相比于 iOS 两三天就能达到 80% 的覆盖速度而言，Android 应用版本升级至少需要两周才能达到 80% 的升级率，严重阻碍了版本迭代速度。也导致市场上 App 版本分散，处理 bug 和投诉等也越来越麻烦。
Android 排版引擎实现 - 索引设计
实现和优化一个排版引擎不是一件轻松的事情。甚至描述清楚设计也不轻松。看看这篇讲浏览器实现原理的文章有多长就明白了。
在日常的应用开发中，把代码放到哪总是可以纠结很久，而且这种纠结消耗的时间丝毫不弱于给变量起名字。
MVC／MVP／MVVM.. 等等一系列架构里，关注点在 C 层，M 和 V 其实比较少提到。可能是由于这两层的定位过于纯粹，而 C 层跟业务有更加密切的关系，对其抽象的需求更强一些。
而日常开发中，M 层提供数据的角色很清晰，却不能够含糊对待，从后台获得数据，本地加工后落地DB，根据 VC…
