这是一个创建于 538 天前的主题，其中的信息可能已经有所发展或是发生改变。
差不多 60 个人头像，base64 已经是压缩图片后编码的 b64 了，可是字符串放在 body 里还是巨大，差不多还有 4MB ，而且这个页面是会频繁刷新的，有成员变动就自动去获取新数据，几秒就干一个 4MB ，吃不消啊
 |
1
hefish 2023-06-23 11:49:46 +08:00  2
我们都是 Img 标签指向 jpg 就完事了。
|
 |
2
wolfan 2023-06-23 11:50:41 +08:00
缩略一下再搞？
|
 |
3
hsfzxjy 2023-06-23 11:58:12 +08:00 via Android
所有人头像放一个请求里吗？为啥要这样
|
 |
5
hhjswf 2023-06-23 12:30:51 +08:00 via Android
头像不都是缩略图存本地吗
|
 |
6
IvanLi127 2023-06-23 12:34:28 +08:00 via Android
一个个拉呗，拉完缓存不就好了？ http2 不是普及了吗？
|
 |
7
k9982874 2023-06-23 12:36:19 +08:00 via Android
无力吐槽。。
|
 |
8
lalalaqwer 2023-06-23 12:39:27 +08:00
你们不会是把头像 base64 后存数据库吧
|
 |
9
opengps 2023-06-23 12:41:28 +08:00
页面本身不是自带缓存吗？本地有的话，刷新也就只是请求一次
|
 |
10
rabbbit 2023-06-23 12:42:28 +08:00
用 img 标签，浏览器会自动缓存
可以从头像大小入手，以 Github 为例 48x48 的头像可以处理到 4kb 以下 |
|
11
opengps 2023-06-23 12:42:44 +08:00
另外如果图片加载对页面影响大，那就单独从文件存储拉图片，不去占用后端接口服务器的带宽就好
|
 |
12
Trim21 2023-06-23 12:42:46 +08:00
频繁刷新这个问题可以考虑在客户端 diff 一下只拉新用户的头像，模拟一下 img 标签的行为...
|
 |
13
felixlong 2023-06-23 12:43:17 +08:00
base64 不是压缩。你把 base64 换成原始的 jpg 。每个图像差不多 5k 。啥都不用改。直接可以把 4M 变成 300K.
|
|
14
Trim21 2023-06-23 12:47:10 +08:00 via Android
@felixlong 他应该是只能返回 JSON 格式，所以就先压缩了图片的二进制再用 base64 编码的。
|
 |
15
tulongtou 2023-06-23 12:49:46 +08:00
nginx 启用 http zip ，文本的 zip 完会小很多
|
 |
16
muzuiget 2023-06-23 13:11:05 +08:00
为什么要这样骚？ img 标签加个 lazyload 属性完事。
|
 |
17
jack4536251 2023-06-23 13:23:28 +08:00 via Android
@lalalaqwer 应该是，正确的做法是存路径
|
 |
18
SnailLin 2023-06-23 14:56:09 +08:00 1
槽点太多，1 、base64 不是压缩 2 、后台返回头像的 url 即可 3 、所有头像懒加载、异步加载
|
 |
19
Ericcccccccc 2023-06-23 15:17:14 +08:00
?
后端肯定是返回链接地址, 哪有直接返回图片本身的. |
 |
20
tairan2006 2023-06-23 16:06:39 +08:00 via Android
你这啥问题？图片不都是返回地址么
|
 |
21
okakuyang 2023-06-23 16:18:50 +08:00
可以用不同的压缩算法压缩响应，如果可以用二进制流传输会比 base64 小一点。base64 会膨胀一点。
|
 |
22
adoal 2023-06-23 16:24:06 +08:00
你是说把所有人的头像图片作为整体来传输，有人的改变了就把 60 个人头像的这个整体重传一边？这不是给自己找麻烦嘛。
|
 |
23
blankmiss 2023-06-23 16:37:42 +08:00
6 啊 这种设计真的无力吐槽
|
 |
24
huangzhiyia 2023-06-23 17:03:32 +08:00 via Android
建议接口改成 api/(unique_id).jpg
|
 |
25
cvbnt 2023-06-23 17:05:06 +08:00 via Android
oss ？
|
 |
26
nkidgm 2023-06-23 17:09:40 +08:00
其实用 base64 传输体积更大了，直接传输还省点流量。。。
|
 |
27
ruoxie 2023-06-23 17:18:38 +08:00
正常操作不是图片存 oss ，后端存图片地址？
|
 |
28
xiangyuecn 2023-06-23 20:02:13 +08:00 1
4MB/4*3=3MB （ Base64 导致增大 1MB ）
3MB/60=50KB （ 50KB 一张图，应该还能再压缩一下到 10-20KB 一张头像） 所以，请使用 url ，依靠浏览器缓存，除了第一次 后面随便你变动，老图都没有流量消耗 |
 |
29
darkengine 2023-06-23 22:06:02 +08:00
这实现方案是谁定的。。。
|
 |
30
zephyru 2023-06-23 22:59:17 +08:00
读了好几遍也没弄明白这个场景为啥要用 base64..用 oss 上 cdn 吧，不行的话，前端手动实现一个缓存？感觉好像也没啥用..后端，把 base64 写成文件，提供 url 让前端用，作用估计也有限..主要不知道这里的，吃不消体现在哪里，页面卡？还是接口返回慢？ 4mb 说大不大，页面我觉得很少会因为这个卡的..
|
 |
31
dayeye2006199 2023-06-24 01:17:42 +08:00
图像存在了数据库里面？
|
 |
32
fyxtc OP @zephyru 页面在取到数据前会转 loading ，数据越大 loading 越久，之前有实现过 url ，体验不好，有的图片如果加载慢就是空白放着，还有可能有的图片永远加载不出来，前端没法缓存，因为有可能随机几秒到几分钟之后 60 个全变的。前端是不知道哪些是变的哪些是不变的。
|
 |
33
Zwying 2023-06-24 12:16:21 +08:00
返回地址吧，base64 不适合
|
 |
35
jazzg62 2023-06-24 13:40:07 +08:00 1
img 标签会有 onload 和 onerror 进度事件，监听就能知道哪些加载好了，哪些还在加载中，哪些加载错误
@fyxtc |
 |
36
superares 2023-06-25 08:39:53 +08:00 via iPhone
应该是为了解决浏览器的问题：同域名并发请求数少，同时加载 60 个图片会加载很久
|
|
37
okakuyang 2023-06-25 09:03:05 +08:00 via iPhone 1
你这个问题可以让前端去解决，因为你这需求以为是保密数据需要解密从数据库读取。如果不是的话返回地址和版本号给前端，从前端去判断哪些需要更新，缓存图片的方法很多种，如果不想缓存就给链接添加一些参数，图片加载不出来就让前端优化加载逻辑。
|
Select Language