@minamike 经锤不😂 用的好几个都被锤没信号了，表面看起来都正常，应该是内伤，ic 焊的不牢靠😂

@paradoxs 一种是存入的文件压根没有后缀，需要自己补上才能出现某些根据后缀关联的 app。某些文件是后缀和 app 需要的后缀不同，需要改成特定后缀才能打开文件（不过相同功能在别的平台没有这种限制，也不能说这种程序功能设计真 TM 蠢吧，不过也是够蠢的😂 也许是因为追求了所谓的极致体验吧）

以前在公司组网主要就是出口路由器和三层交换机稍微好点，多条光纤，是大概 600 块左右的维盟路由器，1500 块左右的三层交换机。其他的每排工位都用的垃圾交换机和 ap，200 台左右设备，4 层楼，每层网速杠杠的（马路上的光纤隔那么几个月总会被挖断一次，剩一条光纤勉强能活😂）。

@sodatea 看样子此问题还是被他们关注了。 我差点都彻底忘了这事了😂 既然新开了 issue 那我就不继续管这个问题了

老兄，你手碰过的有指纹，怎么能够退呢？补 8 块换两罐啤酒😐😐

@5G 不分阶梯吗😐

@IgniteWhite #24 “filezilla 现在已经是恶意软件了”，能详细说一下吗？目前正在用 FileZilla 全家桶😑

拿个小太阳烤烤火，3 4 百瓦，应该蛮省钱了吧，40 块拿去😂
https://wx1.sinaimg.cn/large/a32300cdgy1ga85iyb6pkj20ku0rsavd.jpg

-----
实在不行买包蜡烛，多点几根

还以为我眼神不好，原来顶部的提示框 tm 是自己会变颜色。。。盯看半天明显换了个颜色才发现😐😂

#5 😬😬😬

https://wx3.sinaimg.cn/large/a32300cdgy1ga6i82hqbqj20dw08uaap.jpg

还是 DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE 简单粗暴，哪有那么多花里胡哨的玩意

@wusheng0 @Tink 原来已经有了，按列表翻了一下没看到还以为没人发😂

@jsq2627 #42 这段代码有意思。我试了一个 200kb 的图片（ 1800*1200 ）加载 200 次的内存占用(约 50M 流量)

https://wx3.sinaimg.cn/large/a32300cdgy1ga19ds6fj2j20zb0dkwgy.jpg

任务管理器里面报的内存，不知道是 windows 的是实际的还是 chrome 的是实际的，不过应该 600M+是有的，performance 里面的值雷打不动😂

刚开始加载并渲染 和 只加载不渲染 内存占用差不多（ 50M 左右增量），然后我拖动页面让所有的图片都至少可见一次，内存立马爆炸到 600 多 M ；移除所有已显示的图片后，手动 GC 后内存正常回收。

看样子 Image 的性能优化的确实厉害，缓存了 Image 就没有必要用 Blob 了。

-------

另外还测试了一下 2M 的 Blob *200 个，内存占用出现在浏览器的主进程（ ID：8612 ）上，并不在网页窗口的进程上；测试不断创建 1M 的 ArrayBuffer 就能把 chrome 主进程的内存占光（任务管理器里面看 2.4G 左右就不动了），然后内存放不下的 blob 疯狂写入硬盘（ User Data\Default\blob_storage 目录），目测会把硬盘写满😂。测试代码（ 12G 数据，机械盘估计更明显）：
```
s=[];for(var i=0;i<12000;i++)s.push(new Blob([new Uint8Array(1*1024*1024)]));console.log("end")
```

楼主是来钓鱼的吧😂

@xiaoming1992 #36 URL.createObjectURL(blob)

海南+1、广州+1

看你#10 楼说的，这么大的时间间隙，最佳还是按需实时从网络加载更好些，全部缓存到内存是否有提前优化的嫌疑？

另外猜测意图并非同时需要显示大量图片，如果真需要全部缓存到内存时，尽量不要用 Image 对象来加载图片，自己写 xhr 请求得到二进制 ArrayBuffer，最多内存占用也就比 15M 多点，按需实时从内存实例化 Image 图片对象（ onload 非常快）。直接用 Image 来进行缓存内存占用会翻个 10 几倍也是正常。

干脆用 gitee 的图片外链，github 也能显示了，有比这个更骚的吗😁

https://wx2.sinaimg.cn/large/a32300cdgy1g9yrffkwzxj20ic028mx0.jpg