等高瀑布流布局的算法

(听学长说最近前端面试喜欢问这个，转来学习下，其实自己也看得不是很懂，慢慢研究。原文)

之前有写过一篇非等宽图片列表的布局的博文，那只是这种布局之前的叫法，为了和常规的等宽瀑布流布局做区分，根据这种布局的特性（整行是等高的），那么就叫等高瀑布流布局吧。

怎么又拿这种布局出来说事？最近几天在对以前开发的360图片搜索结果列表页的图片尺寸和交互效果做一些细节上的调整。同时也对布局的算法做了优化，之前采用的是以宽度裁切为主和夹杂着一些等比缩放的算法，当时是为了让每一行看起来高度都一致。由于宽度裁切的效果会让图片左右边缘部分有损失，而且当时也有图片 hover 时的放大效果在一定程度上弥补了这种损失。这次放弃了宽度裁切，也去掉了 hover 时放大图片的效果，全部采用了等比缩放的算法。

在上一篇博文中谈到的等比缩放的算法其实并不是最优的，还是会有一定的上下或者左右的裁切。研究了一下 Google+ 的相册使用的等高瀑布流布局的缩放，发觉还有一种更优的缩放计算的算法，于是花了两个小时将这种算法推演了出来。这里先检讨下，由于智商上的缺陷，数学绝对是我的弱项，这种算法比之前的要简单得多，之前是走了弯路了。

好吧，上面的废话扯了一堆，下面就直奔主题吧，基本的布局方式并没有变，有疑问的可以看之前的博文。

计算基准高度

这是最关键的一点，如果图片本身不是定高的，像 Google+ 相册那样，那么需要先将整行图片都先缩放到同一个固定的高度，可以先使用整行图片中最小高度的图片为初次的基准高度。如果图片本身就是等高的，那么就直接省却了这一步。

基准高度 = 缩放后的总宽度 / 缩放前的总宽度 * 原图高度

计算高度的缩放比

有了基准高度，一切都好办了。

高度的缩放比 = 基准高度 / 原图高度

计算缩放后的宽度

缩放后的宽度 = 高度的缩放比 * 原图宽度

处理误差

大功告成了？只差最后一步了，那就是误差的处理。在计算的过程，由于图片的宽高都是取整的，难免会出现误差，可以将误差叠加到整行中最小或最大宽度的图片上再次对图片进行一些缩放，这个时候就需要一点点的裁切了。

至此，等高瀑布流布局的等比缩放的算法都介绍完毕了，是的，就是这么简单。