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