google图片墙到底是怎么产生的？

google图片墙的特别之处

1. 无限滚动加载，加载的过程中滑动进度条，页面没有卡顿感
2. 视觉可见的最后一行一定是满行的；

   

经过观察发现的几点：

• 加载前使用蓝色的背景框占位
• 背景框的宽高等同与之后img的宽高．img的宽很好计算（intrinsicＷidth * 某个范围的值（＜242px） /intrinsicHeight）

  

   

google采用 外层div(margin-right:20,margin-bottom:20)->a(仅包含图片)->div(里层div,包括img,做超出部分的隐藏)－>img

• 每一行行高并不相同
• 每一行数目接近
• 每行高度相近

因为是滚动加载，要让最后一行视觉上是满行的相对好办（可以将最后一行隐藏）；通过观察发现，google实现排列的方式一定有js参与的．查找了相关资料．找到一份开源的计算输出的算法．

没有详细去查看该方法是不是像Google Photos Web UI中描述的方法．但是应该大体上差不多是同一类方法；

这是我使用该方法的输出：

输入：图片的长宽比

输出：图片在container上的相对位置．每张图当前的高度等；

那么要实现上面的两点，是可以满足需求的（在滚动加载的前提下）：

1. 像后台获取一定数量的图片，通过长宽比计算出所在的位置．只要判断未加载完成，隐藏最后一行；
2. 为了快速响应用户的行为，不让滚动卡顿，在用户快速滑动的时候，并不加载图片，只是展示占位符．用户停留时加载压缩后的图片；点击大图时显示高清图．在Google Photos Web UI文章中说过一个有意思的优化，如果从模糊的低清图转为高清图（点击图片时图片放大并呈现动画，高清图加载完毕替换）

##＃ 未完

1. flexLayout的算法很有意义，但是并未找到相关论文，不知道折行断点是怎么找的，依据是什么
2. 仔细观察现有google photo，它并不是按照justified-layout给出的值那样布局的．google图片并未使用object-fit(性能问题？兼容问题？)，但是使用外框遮挡了一部分（类似裁剪的效果）,这种遮挡的比例应该不能超过一定的值，这个标准是如何得到的？感觉google photo的布局比我想的要复杂很多．