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的威力。
请相信二进制序列化之后的体积比二进制大了大约两倍。