84669 人学习
152542 人学习
20005 人学习
5487 人学习
7821 人学习
359900 人学习
3350 人学习
180660 人学习
48569 人学习
18603 人学习
40936 人学习
1549 人学习
1183 人学习
32909 人学习
RT 设计客户端与服务端交互 API 中,那些琐碎细小的几 KB 图片应该如何处理?
人生最曼妙的风景,竟是内心的淡定与从容!
JSON 流?
你的意思是不是把那些图片直接 Base64 Encodeing 处理之后通过 JSON API 传递给客户端吗?
如果是这个意思的话,那么既有好处也有坏处,针对你的几个问题简单说一下:
一般琐碎的几KB的图片可以通过编码之后传输会比较快,当然如果量不上去的话这个差别也很小啦
很遗憾,如果你不是直接请求二进制文件的话,Data URI 是没有办法在客户端缓存的,每当文档变化的时候它们都必须重新下载
无论大小都是一样的存吧,或许会涉及到磁盘读写的性能?这方面我不太了解。
不大不小……这个要怎么定义呢?难道设计一个系统还需要先针对图片尺寸和大小分个上中下三档吗?我觉得静态资源单独做个 CDN 处理,API 返回请求 CDN 的地址给客户端就好了,目前最成熟的做法也就是这样了吧。至于那些特别小的东西,一般来说都是图标之类的吧,要么 sprites 处理一下,要么直接转成字体。
大于200字节都不要用base64了。请相信gzip的威力。 请相信二进制序列化之后的体积比二进制大了大约两倍。
JSON 流?
你的意思是不是把那些图片直接 Base64 Encodeing 处理之后通过 JSON API 传递给客户端吗?
如果是这个意思的话,那么既有好处也有坏处,针对你的几个问题简单说一下:
一般琐碎的几KB的图片可以通过编码之后传输会比较快,当然如果量不上去的话这个差别也很小啦
很遗憾,如果你不是直接请求二进制文件的话,Data URI 是没有办法在客户端缓存的,每当文档变化的时候它们都必须重新下载
无论大小都是一样的存吧,或许会涉及到磁盘读写的性能?这方面我不太了解。
不大不小……这个要怎么定义呢?难道设计一个系统还需要先针对图片尺寸和大小分个上中下三档吗?我觉得静态资源单独做个 CDN 处理,API 返回请求 CDN 的地址给客户端就好了,目前最成熟的做法也就是这样了吧。至于那些特别小的东西,一般来说都是图标之类的吧,要么 sprites 处理一下,要么直接转成字体。
大于200字节都不要用base64了。请相信gzip的威力。
请相信二进制序列化之后的体积比二进制大了大约两倍。