差不多 60 个人头像，base64 已经是压缩图片后编码的 b64 了，可是字符串放在 body 里还是巨大，差不多还有 4MB ，而且这个页面是会频繁刷新的，有成员变动就自动去获取新数据，几秒就干一个 4MB ，吃不消啊
This topic created in 1232 days ago, the information mentioned may be changed or developed.
 |
1
我们都是 Img 标签指向 jpg 就完事了。
|
2 |
wolfanJun 23, 2023
2
缩略一下再搞？
|
 |
hsfzxjyJun 23, 2023 via Android
3
所有人头像放一个请求里吗？为啥要这样
|
 |
hhjswfJun 23, 2023 via Android
5
头像不都是缩略图存本地吗
|
 |
IvanLi127Jun 23, 2023 via Android
6
一个个拉呗，拉完缓存不就好了？ http2 不是普及了吗？
|
 |
k9982874Jun 23, 2023 via Android
7
无力吐槽。。
|
 |
lalalaqwerJun 23, 2023
8
你们不会是把头像 base64 后存数据库吧
|
 |
opengpsJun 23, 2023
9
页面本身不是自带缓存吗？本地有的话，刷新也就只是请求一次
|
 |
rabbbitJun 23, 2023
10
用 img 标签，浏览器会自动缓存
可以从头像大小入手，以 Github 为例 48x48 的头像可以处理到 4kb 以下 |
|
opengpsJun 23, 2023
11
另外如果图片加载对页面影响大，那就单独从文件存储拉图片，不去占用后端接口服务器的带宽就好
|
 |
Trim21Jun 23, 2023
12
频繁刷新这个问题可以考虑在客户端 diff 一下只拉新用户的头像，模拟一下 img 标签的行为...
|
 |
felixlongJun 23, 2023
13
base64 不是压缩。你把 base64 换成原始的 jpg 。每个图像差不多 5k 。啥都不用改。直接可以把 4M 变成 300K.
|
 |
DonaidTrumpJun 23, 2023
15
nginx 启用 http zip ，文本的 zip 完会小很多
|
 |
muzuigetJun 23, 2023
16
为什么要这样骚？ img 标签加个 lazyload 属性完事。
|
 |
jack4536251Jun 23, 2023 via Android
17
@lalalaqwer 应该是，正确的做法是存路径
|
 |
18
槽点太多，1 、base64 不是压缩 2 、后台返回头像的 url 即可 3 、所有头像懒加载、异步加载
|
 |
EricccccccccJun 23, 2023
19
?
后端肯定是返回链接地址, 哪有直接返回图片本身的. |
 |
keenkillerJun 23, 2023 via Android
20
你这啥问题？图片不都是返回地址么
|
 |
okakuyangJun 23, 2023
21
可以用不同的压缩算法压缩响应，如果可以用二进制流传输会比 base64 小一点。base64 会膨胀一点。
|
 |
adoalJun 23, 2023
22
你是说把所有人的头像图片作为整体来传输，有人的改变了就把 60 个人头像的这个整体重传一边？这不是给自己找麻烦嘛。
|
 |
blankmissJun 23, 2023
23
6 啊 这种设计真的无力吐槽
|
 |
huangzhiyiaJun 23, 2023 via Android
24
建议接口改成 api/(unique_id).jpg
|
 |
cvbntJun 23, 2023 via Android
25
oss ？
|
 |
nkidgmJun 23, 2023
26
其实用 base64 传输体积更大了，直接传输还省点流量。。。
|
 |
ruoxieJun 23, 2023
27
正常操作不是图片存 oss ，后端存图片地址？
|
 |
28
4MB/4*3=3MB （ Base64 导致增大 1MB ）
3MB/60=50KB （ 50KB 一张图，应该还能再压缩一下到 10-20KB 一张头像） 所以，请使用 url ，依靠浏览器缓存，除了第一次 后面随便你变动，老图都没有流量消耗 |
 |
darkengineJun 23, 2023
29
这实现方案是谁定的。。。
|
 |
zephyruJun 23, 2023
30
读了好几遍也没弄明白这个场景为啥要用 base64..用 oss 上 cdn 吧，不行的话，前端手动实现一个缓存？感觉好像也没啥用..后端，把 base64 写成文件，提供 url 让前端用，作用估计也有限..主要不知道这里的，吃不消体现在哪里，页面卡？还是接口返回慢？ 4mb 说大不大，页面我觉得很少会因为这个卡的..
|
 |
dayeye2006199Jun 24, 2023
31
图像存在了数据库里面？
|
 |
32
@zephyru 页面在取到数据前会转 loading ，数据越大 loading 越久，之前有实现过 url ，体验不好，有的图片如果加载慢就是空白放着，还有可能有的图片永远加载不出来，前端没法缓存，因为有可能随机几秒到几分钟之后 60 个全变的。前端是不知道哪些是变的哪些是不变的。
|
 |
ZwyingJun 24, 2023
33
返回地址吧，base64 不适合
|
 |
superaresJun 25, 2023 via iPhone
36
应该是为了解决浏览器的问题：同域名并发请求数少，同时加载 60 个图片会加载很久
|
|
37
你这个问题可以让前端去解决，因为你这需求以为是保密数据需要解密从数据库读取。如果不是的话返回地址和版本号给前端，从前端去判断哪些需要更新，缓存图片的方法很多种，如果不想缓存就给链接添加一些参数，图片加载不出来就让前端优化加载逻辑。
|
Select Language