其实说实话大大们维护了so long years,要我一个菜菜找出优化点或者bug谈何容易!
科科,有一些bug还没弄明白怎么造成的也不太容易复现,就暂时不写了。

这里使用Chrome 50版本
chrome.png

首先就是调节开发者工具到手机布局,然后随机滚动了下屏幕,Console.log提示:
timeout.png

个人觉得这个是优化点一。看提示就知道是因为计时器的原因,一定是计时器还在运走,但是User滚动了屏幕,所以暂时暂停了计时器的代码(可以从Warning看出其实是Chrome自身的bug,不过不知道其他的WebKit内核上是否会有同样的问题)。这里有在StackOverflow看到类似的问题,Answer

如下:
0.0.png

随即就点开了 [requestIdleCallback][4] 这个链接,是Google Developers的页面。这里有一段Checking这个方法的代码,如果不存在就退化成setTimeout(但是下面也说了是不推荐的,因为行为上,setTimeout并不是在空闲的时间去运行0.0,其实想想就知道了解决的方案就是使用这个调用在空闲时间去运行指定的Callback,而setTimeout并没有这个功能。不过说话间想起了Window.requestAnimationFrame(),但是这个行为上并没有setTimeout的超时功能需要完善下(或许我没看见?),而且鉴于本身设计为响应动画的API,FPS是有限制的所以应该是不能很精确的计时,哎哎哎简直脑洞大开啊0.0)

aaa.png

调用相对就简单多了

bbb.png

同样是可以超时运行的,参数二添加
{timeout : *delay*}
就好了。

另外觉得是优化点二的,就是发现下面各个商品Item图像加载,是异步的,滑动到才加载。不过网速很慢的时候加载出的图片依旧从上到下显示出来然后旋转的加载标志才消失。我想的是:

图片的空间保留(多个parent的div也好,直接设置外面高度也好)但是img的高度为0,加载完成后高高度再恢复真正的高度并且!使用过渡动画!但是这里我并不敢保证有效因为可能会很卡2333...,这里高度也可以用opacity个人觉得,至少,酱紫在弱网速下反馈效果很好而不是突然间或依旧卡着就显示出图片了2333...

有个bug不知道如何复现,或者说不知道是不是bug,资料:
error.png

还有就是google统计会很慢吧,虽然这个在国内并没有被GFW阻拦,但还是很慢吧我们要不要自己搞一个。。。
Resource MIME偶尔会出那么点问题也没复现,这个拉回去斩了后端,为何不做好HTTP Header...

Resource MIME.png

最后就是显的*不那么重要*的**重要问题**了,加载时间好长的这个...

time1.png

呐呐,我在尝试下载ai框架的源码并且去解析下原理,因为我并没查到任何资料2333...

最后的最后说下网站的分析,这部分占的比较少因为这两天实在是Resource
Busy啊啊啊。显然的是用了Sea.js和ai框架(噗,这个不用看js直接看DOM树好伐),然后比较了下Base64图片和转存到png的图片(因为logo部分就是酱紫加载的),还真的减小了传输体积,并且减少了请求数量。。。感觉不合理啊(坑,这里可能是我转存的方式不对,之前写辽宁省教育厅的项目的时候是传输到后端用php转的这里我直接用浏览器的另存为功能了2333...)

Sea.js其实比较简单,但是它解决了模块化的重要问题!说到这里就不得不感谢玉伯

呐呐,以上都是个人见解,看官要自己斟酌哦poi~~~