Flash的首屏应用

简介：

良品首页3.0版本在设计的时候，想在首屏添加一些特殊的效果，例如彩蛋之类，所以整个首屏使用了Flash，在高品质的显示效果和动画效果背后带来了大量问题，下面来一一分析。

问题：

1. 版面大，使用了1000 * 500的分辨率，分2屏展示。

2. 高品质的图片，带宽需求高。

3. 灵活的展示方式，图片个数不确定，请求数目多，平均每次版本 10张图片左右。

4. 图片分布在CDN的不同服务器上，加上Flash的SWF文件，图片的配置文件，Flash的资源一共分布在6个服务器上，cross-domain 验证开销巨大。

5. 丢失Ref问题

6. 某些用户设备无对Flash的支持

1. 上线前的版本：

图片全部都是PNG24,所有图片（2屏）同时加载，首次打开页面，所有的请求数在34个左右，图片大小在1.1M左右。一般网速下打开首屏需要 10-15秒。

2. 正式上线的版本：

与上线前得版本相比，打开页面时，仅加载第一屏的图片，第二屏图片延迟加载，首屏的请求数下降3-4个，图片大小降低到800K 左右。打开首屏8-10秒。

此时问题依然严重，所有人都反映首屏加载慢，我们说服了设计师，将首屏的PNG替换成JPG，画质在85以上，由设计师自由调整，保证画质的前提下，大大降低图片大小。

3. 优化图片后的版本：

加载图片的大小降低一半，请求数未变，首屏图片降低到400K左右，打开时间在3-5秒。

到了这个时候，图片的大小已经没法优化，Flash在未加载完时，首屏一片空白，至少3秒才能看到图片加载，网速慢的情况下5-10秒钟都是空白，仔细分析发现时间有很大部分消耗在Flash的cross-domain验证上，在验证时，会阻塞对此服务器的请求。

此时需要解决的问题是，将空白去掉，加载完成Flash前显示首屏的图片，等Flash加载完成后，替换掉Dom元素。

4. 加载Flash前显示首屏图片

部分图片重复加载，整个首屏的请求数上升8个左右，图片的请求大小上升到900K，但是由于图片在Flash加载前已经加载，Flash加载的图片仅是在缓存中加载，所以，图片整体大小并未增加，但是缓存机制无法保证在所有用户都起作用。

设计师对此次改进依然不满意，因为有2-3秒内首屏没有动画效果，所以一个Flash首屏的JS提单版本开发出来，在整个Flash加载以及内部的图片加载完成后隐藏JS版生成的Dom元素，隐藏而不是移除的原因是为了后台的统计。

5. JS部分替代版本：

所有首屏图片重复加载，对首屏的影响跟前面的版本相比差别不大，增强了用户体验，在不支持Flash的浏览器中依然可以使用。

Flash 版本从上线到这个时候已经半个月，无论前端还是BI部门对这个首屏都不满，特别是BI部门，后台系统对点击数据的统计是基于 a 标签的，Flash版本使BI部门只能手工统计，而且不准确。我们找了设计师后，确认一些额外的超炫功能暂时不再上线，我们就使用完全的JS版本替代Flash版本。

6. JS完全替代版本：

首页，首屏的请求数降低到25个，首屏资源的大小下降到370K左右，加载时间2-3秒，中间没有白屏等待Flash加载的现象。

*首屏的加载时分屏加载的，第一屏切到第二屏前加载第二屏的图片。

*加载时间是按首次加载算的，浏览器未缓存的情形

Flash在高访问量的首页应用有一定的限制，特别是作为展示多个图片的容器，因为这种网站一般使用CDN服务器，所以图片会分布在多个服务器上，由此带来的cross-domain问题很难解决，其他的诸如丢失Ref等问题网络上都有现成的解决方案（模拟Form提交）。