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