ISV(Independent Software Vendors),独立软件开发商。一般是独立的第三方公司,公司有专业的设计师和程序员,为付费的商家提供一对一的定制化开发。
imageX(图床):公司提供的图片存储、CDN 分发和图片动态处理的云服务,返回一个图片 url,可以在 url 上增加参数实现图片的实时转码、裁切、缩放等功能。社区也有一些图片托管商提供类似的服务。
TOS(Tinder Object Storage):公司提供的一个对象存储服务。社区也有一些类似的解决方案,如 OSS。
DevBox:公司给员工提供的一台 linux 服务器,可以通过内网 ssh 访问。
B 端:指商家操作的后台,PC 端网页,基本 Chromium-only。
C 端:指消费者浏览的页面,在手机 App 内运行。
店铺开放 ISV 链路后,随着头部商家的全页定制化的增加,性能问题受到越来越多的关注,我们针对 ISV 开发的页面,做了系统性的诊断,并沉淀出一系列优化 TODO,本文主要介绍图片优化子项目(一定要看到最后,相信一定有收获)。
可以看到,在图片的首次加载时,优化效果比较明显。
我们随机抽取了几张线上图片做对比:
以下图片都是无损 PNG 截图效果,以便准确对比。
图片类型 | 图片/大小 | 图片/大小 |
---|---|---|
原图 | 2.3M | 1.2M |
离线压缩后(离线压缩为本次专项工作) | 197KB (-91.6%) | 95.8KB (-92.0%) |
imageX 转 PNG(线上实时拼后缀) | 2.3M (-0%) | 1.2M (-0%) |
imageX 转 JPG | 236KB (-89.9%) | 114KB (-90.4%) |
imageX 转 WebP | 158KB (-93.3%) | 68.2KB (-94.4%) |
离线压缩后再用 imageX 转 WebP | 147KB (-93.8%) | 63.2KB (-94.8%) |
可以看到,对原图转 JPG 有明显的收益,转 WebP 收益更大。离线压缩收益比在线转 JPG 略高,对离线压缩后的图片再进行在线转 WebP 仍能得到压缩收益。
我们可以看到,对于原图,直接拼 .png 后缀压缩率没有明显优化,由于要考虑到原图可能有透明通道,不能直接转 JPG。但拼 .webp 后缀后,优化已经很明显。但为什么我们不直接使用 WebP 图片呢,主要以下几个原因:
兼容性问题,需要做成运行时。 WebP 有一定的兼容性问题,我们必须做成运行时 SDK 在端上判断,才能决定是否启用 WebP。这个 SDK 我们有提供给 ISV SDK,但并没有很高的覆盖率。
端上需要对每一个图片请求进行拦截,这个会劣化所有的图片网络请求。
另外随端发版的问题,会让这个功能变得碎片化,对于存量的老版本客户端感受不到收益,对于前端来说,会成为历史包袱,需要长期考虑向后兼容问题。
综上,我们最终决定对于存量和增量图片分别进行处理。首页我们要解决存量的问题,提升整个大盘的水位,再解决增量问题,保持优化效果。
对于存量图片, 我们的结论是进行数据库替换,遍历所有数据库里的图片,进行下载、离线压缩、上传、得到新 url 再回写回数据库。
对于增量图片, 先做临时性卡口,和产品达成一致,先做粗暴的体积限制,不准商家上传大于 500Kb 的图片。如果不做这样的卡口,就会一边出水一边放水,永远动态清不了零了。在后续上线了 B 端创建页面时对图片进行压缩能力后,再把临时卡口放开。
离线清洗数据说起来简单,但其实是个高风险的操作。本着追求极致和务实敢为的态度,我们最终还是决定尝试一下。这个我们和后端同学进行了详细的技术评审,并设计了周全的预案以保万无一失。本文主要说下这里面遇到的问题和解法:
原理并不复杂,主链路只有以下四步,不过坑倒是有不少。
为什么要设计数据结构?因为要防止图片被二次压缩导致失真,需要把图片压缩的相关信息存储。在这里我们定义了一个简单的数据结构。这里有三个 md5 的 hash 值,便于将图片作为 url 或本地文件查询时快速找到对应的压缩数据。
interface IImageMinyfyMappingJSON {
width: number // 图片宽度
height: number // 图片高度
hash: string // 图片 url 的 hash,md5(rawUrl)
rawExtname: '.jpg' | '.png' | '.gif' // 压缩前图片扩展名
rawImageHash: string // 压缩前图片 md5 值
rawSize: number // 压缩前图片大小(字节)
rawUrl: string // 原图片 url
newExtname: '.jpg' | '.png' | '.gif' // 压缩后图片扩展名
newImageHash: string // 压缩后图片体积
newSize: number // 压缩后图片大小(字节)
newUrl: string // 压缩后图片地址
}
数据存储在 tos 上,没有使用数据库是因为这是一个低频操作,tos 具有更好的稳定性,也不用自己考虑负载问题。
这是一张 imageX 返回的图片地址:
https://p1-ecom-qualification.byteimg.com/tos-cn-i-tsivw11p2g/2ceb46b2d4a342b9a8d282cf8b51bbb4~tplv-tsivw11p2g-image.image
我们可以看到 imageX 的图片都是不带扩展名的,都叫 .image,这使得下载时无法提前知道图片类型(其实也能通过 HTTP Header 的 MIME 信息,但这要多一次 header 请求,得不尝失)。所以这里使用的下载方式是先以随机数命名,再使用 md5(rawUrl) + rawExtname
重命名。
export const downloadImage = async (httpUrl: string, outputDir: string):Promise<string> => {
const tmpPath = path.join(outputDir, `.tmp_${Date.now()}${Math.random()}${Math.random()}${Math.random()}`)
try {
fs.ensureDirSync(outputDir)
spawnSync(`wget -O ${tmpPath} ${httpUrl}`, { stdio: 'inherit', shell: true })
const imageHash = md5(fs.readFileSync(tmpPath))
const { ext } = await fileTypeFromFile(tmpPath) as FileTypeResult
const dest = path.join(outputDir, imageHash + '.' + ext)
// 允许同名覆盖,有可能同一张图片多次在不同场景下上传,这时 md5 算出来是一样的。另外,确保函数多次执行是幂等的
fs.moveSync(tmpPath, dest, { overwrite: true })
return dest
} catch (e) {
fs.removeSync(tmpPath)
throw e // 抛错很重要,不要随便把错误吃掉,后面会说
}
}
这里踩到一个坑:一开始直接以 Math.random() 作为临时文件名,但这个在多次独立执行后是有可能碰撞到相同的随机数的,详见 JS 随机数生成算法[1](关键这篇文章也是我写的,允悲,还是太自信 V8 的伪随机生成了)。后来加了时间戳和 3 个随机数降低碰撞。更科学的方式应该使用标准的 uuid 生成库,它还会考虑机器 mac 地址等信息,进一步减少多机器独立事件的碰撞概率。
图片扩展名推断使用了 file-type 库。
使用 wget 下载图片是因为 wget 支持同步下载(node 里没有同步网络 io 的方法),最主要的是 wget 支持断点续传和进度展示。
对于不同图片,使用的压缩算法是需要不同的,这里对比了几种不同的压缩算法,最终如下:
以下图片都是无损 PNG 截图效果,以便准确对比。
图片类型 | PNG |
---|---|
原图(PNG) | 737KB |
TinyPNG(好用,但不开源,只有 HTTP 调用,且限流,把图片传到境外服务器不可接受) | 180KB |
OxiPNG | 475KB |
imageX(toJPG) | 38.8KB |
MozJPEG(这结果绝绝子了,但问题是转成 jpg 后透明通道没啦) | 30.8KB |
离线压缩后再 imageX to WebP(离线压缩后再转 WebP 可期望达到最极致结果) | 18.6KB |
注:
JPG 没必要转成 PNG GIF 本次没有做,因为本次量不大 SVG 本次没有做,因为本次量不大,推荐 svgo 以及一个国内大佬的 svg-slim
综上调研,我们决定压缩逻辑如下:
JPG 直接用 MozJPEG 压缩
PNG 如果 含有透明通道,使用 OxiPNG,否则使用 MozJPEG
如果压缩后的图片比原图大,放弃,使用原图
其他图片,跳过
综上,核心的优化点是把无透明通道的 PNG 转成 JPG。这里不得不研究下 PNG 图片的详细定义:(摘自维基百科)
便携式网络图形(英语:Portable Network Graphics,PNG)是一种支持无损压缩的位图图形格式,支持索引、灰度、RGB 三种颜色方案以及 Alpha 通道等特性。PNG 的开发目标是改善并取代 GIF 作为适合网络传输的格式而不需专利许可,所以被广泛应用于互联网及其他方面上。
PNG 另一个非正式的名称来源为递归缩写:“PNG is Not GIF”。PNG 的官方念法是“平”(/pɪŋ/),但是多数人是当成三个英文字母分开读。
PNG 图片大多数都使用
PNG
作为扩展名,其互联网媒体类型为image/png
。PNG 于 1997 年 3 月作为知识性 RFC 2083 发布,于 2004 年作为 ISO/IEC 标准发布。PNG 图片主要由三种类型存储:
PNG 8:图片使用 8 bits 来存储,可以用 2 的 8 次方大小个种类颜色来存储一张黑白的图片。也就是说 PNG 8 能存储 256 中颜色,因为颜色少,文件体积也非常小,一张图片如果颜色简单,将它设置成 PNG 8 得图片是非常省空间合适的。 PNG 24:图片使用 24bits 来存储,用三个 8bits 分别去表示 R(红)、G(绿)、B(蓝)三个通道(Channel)的数值。可以表达 256 乘以 256 乘以 256=16777216 种颜色的图片,色彩丰富度更高,但相对的所占用的空间也就更大了。 PNG 32:图片使用 32bits 来存储,相当于 PNG 24 加上 8bits 的透明颜色通道,总共有 R(红)、G(绿)、B(蓝)、A(透明)四个通道。图片能表示的色彩跟 PNG 24 一样多,并且还支持 256 种透明度,能让图片色彩更加丰富。
注意这里一簇叫 APNG,扩展名通常也以 .png 结尾,这类图片不能用 OxiPNG 压缩,会丢失动画。使用 imageX 也不能转换成 WebP,同样会丢失动画。
注意这张图原图是 APNG , 但微信文章里不支持展示,这里实际放的是 GIF 录屏(「萌」混过关 🙈),查看原图可以复制以下链接到浏览器:https://p1-ecom-qualification.byteimg.com/tos-cn-i-tsivw11p2g/545cb9abb2ee4256a13235a5e6dfd3e1~tplv-tsivw11p2g-image.png
好在 file-type 库会把它识别成扩展名 apng
所以对 PNG 的处理逻辑是:
如果是 APNG,跳过,返回原图
再检测是否含有透明通道,决定能不能转 JPG
const isTransparentPng = (pngPath: string, limit = 255) => {
if (path.extname(pngPath) !== '.png') return false
if (cache[pngPath]) return cache[pngPath]
const buffer = fs.readFileSync(pngPath)
// 图片的宽度存在buffer的第17到20个字节
const width = buffer.readUInt32BE(16)
// 图片的宽度存在buffer的第21到24个字节
const height = buffer.readUInt32BE(20)
const pngCanvas = canvas.createCanvas(width, height)
const context = pngCanvas.getContext('2d')
const img = new canvas.Image()
img.src = buffer
// node 端实际同步的,使不使用 onload 回调没有区别
context.drawImage(img, 0, 0, width, height)
// 获取 PNG 图片的数据的像素数据
const res = context.getImageData(0, 0, width, height)
const imgData = res.data
const piexCount = imgData.length / 4
let isOpacity = false
for (let i = 0; i < piexCount; i++) {
const opacity = imgData[i * 4 + 3]
if (opacity < limit) {
// 如果小于limit,则存在透明像素,退出
isOpacity = true
break
}
}
cache[pngPath] = isOpacity
return isOpacity
}
判断透明度这里用的 node-canvas 库,比较慢(比起网络 io,这真算不上啥了),传原我厂大佬的 rust-canvas 有更好的性能,这里没来得及尝试,考虑到成熟度风险还是用了比较主流的库。
这里没有太多可说的,主要调用 imageX 的 HTTP 接口进行的上传。同时,还会上传一份流程 1 中产出的 mapping 到 TOS。
https://lf3-static.bytednsdoc.com/obj/eden-cn/uhpqnuvfps/minify-image/7d9562cf155631f9b3833eef95d9393e
回写数据库是一个高风险且复杂的事。先看我们的数据库里的结构:
商家搭建页面的每一个楼层,在我们这里是一条物料数据,一个物料由多个原子组件构成。对于后端来说是一个 string,入库前有结构体检测,但落库后存储在数据库里是一个 JSON string,对这个数据,后端无法直接进行回写。
目前我们有 20 多种原子组件类型。如果针对每一种原子组件类型进行入库逻辑编写,会使这个洗数据的工作量变得过于浩大。
高阶 JSON: 我们允许 ISV 自定义复杂的数据结构,对平台来说是一个 string 类型,这造成了我们物料里有二阶、三阶 JSON(即 JSON string 里还有 JSON string)。前面说到 C 端的后端不能直接正则替换也是这个原因,有可能造成转译符不匹配,JSON 对于字面量的完整度要求非常高。
所以这里使用了一种深度优先的遍历方式,不去理解 JSON 结构体的业务逻辑,而是逐级向下展开(JSON.parse)再逐级向上还原(JSON.stringify)。
// 核心函数,onEach 函数会返回三个形参,当前值 val,key 和父亲 parent
// 因为 js 里是址引用,直接给 val 赋值不能改变原数据,要用 parent[key] 进行修改
export const walkIsvJSONSync = (data: any, onEach?: (value: any, key: string, parent: any) => void) => {
const _walk = (data: any) => {
jsonuri.walk(data, (val, key, parent) => {
onEach?.(val, key, parent)
if (isJSONString(val)) {
const data = JSON.parse(val)
_walk(data)
parent[key] = JSON.stringify(data)
}
})
}
_walk(data)
}
// 封装后的方法调用,更换图片
export const changeImages = (data: any, imagesMap: Record<string, string>) => {
walkIsvJSONSync(data, (val, key, parent) => {
if (isImage(val)) {
const newImage = imagesMap[val]
if (isImage(newImage)) {
parent[key] = newImage
}
}
})
}
// isImage 函数
const IMAGE_REG = /^(?:https?:)?//.*.(?:image|png|jpg|jpeg|gif)$/
const isImage = (url: string) => {
if (typeof url !== 'string') return false
return IMAGE_REG.test(url)
}
// isJSONString 函数,只把[] 和{} 类型的视为 JSON
const isJSONString = (str: any) => {
if (typeof str !== 'string') return false
if (!(str.startsWith('[') || str.startsWith('{'))) return false
if (str === '{}' || str === '[]') return false // 空数据也跳过
try {
// 这里的判断比较保守
return equal(JSON.parse(str), JSON.parse(JSON.stringify(JSON.parse(str))))
} catch (e) {
return false
}
}
JSONURI 是本人早年在搭建场景中抽象的一个工具库,核心逻辑是用类 linux 路径来描述数据结构,以便在遍历过程中轻松访问和操作祖先和叔侄节点。这里主要使用了里面的 jsonuri.walk 方法。
线上的数据清洗一旦出错,我估计也就领盒饭了,所以这里做了一系列保障。主要包括:
图片替换的安全性对比,比如把 A 商家的数据换成了 B 商家,必须不能出错。
图片替换质量需要能接受,不能出现不能接受的模糊和失真。
线上监控和快速回滚能力。
对压缩前后图片做了 ui 界面,左边是原图,右边是离线压缩后的。左右图片高度是自适应,这样如果发现两列高度不一致,就确定一定有图片压错了(充分条件)。
没法通过肉眼对比所有图片,我还有很多 bug 要写呢。作为必要补充,加上了图片相似度检测。
这里使用的是 SSIM(Structural Similarity Index Measure)算法:
SSIM 算法源自王舟教授的一篇引用近 4w+ 的论文 《图像质量评估:从错误可见性到结构相似性》[2],在图像识别和广电媒体中得到了广泛应用,是很多做 CV 领域同学的必读论文。
SSIM 返回一个 0 到 1 的值,越接近 1 表示越相似。
下图中 5 张爱因斯坦图像与原图有接近的均方误差(MSE),但 SSIM 有明显的不同,SSIM 指标更接近人眼直觉。
SSIM 论文[2]不长,硬着头皮可以啃一啃。SSIM 算法的核心原理是认为自然界的图像像素与像素之间有很强的统计相关性。
这里没有自己手撸实现,而是用了现成的 SSIM 的 JS 实现库 ssim.js,对于相似度大于 0.95 的放过。
import path from 'path'
import ssim from 'ssim.js'
import imageSize from 'image-size'
import canvas from 'canvas'
import url from 'url'
import fs from 'fs-extra'
const __dirname = url.fileURLToPath(new URL('.', import.meta.url))
const getData = async (url: string) => {
const {width = 0, height = 0} = imageSize(url)
const buffer = fs.readFileSync(url)
const cvs = canvas.createCanvas(width, height)
const context = cvs.getContext('2d')
const img = new canvas.Image()
img.src = buffer
context.drawImage(img, 0, 0, width, height)
const { data } = context.getImageData(0, 0, width, height)
return {
data,
width,
height,
}
}
;(async () => {
const [img1, img2] = await Promise.all([
getData(path.join(__dirname, '1.jpg')),
getData(path.join(__dirname, '2.jpg'))
])
const { mssim, performance } = ssim(img1, img2)
console.log(`SSIM: ${mssim} (${performance}ms)`)
})()
本示例里两张图的相似度超过 99.9%
ssim 值 | ||
---|---|---|
0.999 | ||
0.454 |
由于是直接操作数据库,线上会直接生效,所以所谓的回滚其实是用先前记录的数据再次回写数据库。
这里会在操作前把所有的数据存起来,并记录时间戳。
更新时向后端会校验时间戳,如果更新过程中恰好有商家在前台更新了数据,对比时间戳会校验失败,放弃回滚。
整个的放量时间较长,从国庆节前一直放到节后,较长的放量时间,使我们有更多的时间观察数据和线上 oncall。截止 9 月底至今,我们没有收到用户的负向反馈,抽样回访的 16% 店铺运行正常,样本具有置信度,整个替换过程平稳。
/api/minify-image
是一个 HTTP 接口,接收一个 url 参数,在服务端完成图片的下载-压缩-重传动作。
在写脚本的时候,这里使用了 client-server 模式,图片的下载-压缩-重上传包装成了一个 HTTP 接口,图片的清洗触发包成了 client。使用 C-S 模式有以下几个好处:
便于横向扩展。 HTTP 服务可以横向部署在多台机器上。实操中用了三台机器:我的 16 寸 MBP、IT 借的一台 14 寸 MBP、以及一台 DevBox linux 开发机。图片压缩是个很耗 CPU 的工作,分开跑可以解放出我的主力 MBP。
便于控制并发。 只需要控制 client 的连接数,就可以很好地控制并发,尽可能榨干电脑的算力,又不至于搞死 server 端。这里推荐一个好用的控制并发的库 async ,它可以很好地确保同时跑 N 个异步任务。
便于控制超时。 作为前端,都有丰富的处理接口超时的经验,也有成熟的工具来处理超时。处理超时和抛错,是大批量跑脚本必须要做的事,后文会提到。
幂等 + 缓存。 Server 端实现成幂等的 HTTP GET 接口,访问一次和 N 次返回一致。这里有一个缓存优化:如果图片已经处理过,会跳过处理步骤。但没有分别对下载、上传的每一步都做缓存,因为每增加一级缓存,都会增加复杂度。只要保证每一步的操作出入参都是幂等的,就可以无限重放。
可以提前预热数据。 提前写好 curl 脚本模拟 HTTP 请求,可以提前花几天时间把数据库里的所有图片预热,节约之后的实时处理时间。
健壮性。 Server 端可以使用 pm2 等成熟的进程守护工具保障鲁棒性,避免由于处理某一张图片出问题而导致任务卡壳。
通用性。 前面说到我们做了一个 UI 网页,在网页里也可以调用这个接口。之后也可以将这个 HTTP 服务部署到线上,很多工作都可以复用了。
前面提到 HTTP 接口使用了 pm2 做进程守护,避免了服务器的宕机。同样的,对于 client 端的任务脚本,也使用 pm2 做了守护。pm2 的 start 方法可以传 shell 脚本:
pm2 start 'pnpm vite-node scripts/trigger-minify-images.ts'
这么做的目的是避免跑了半天由于某个边界条件没有处理或内存泄露导致脚本退出,一晚上的时间就浪费了。
// trigger-minify-images.ts
;(async () => {
let i = fs.readJSONSync(INDEX_PATH, { throws: false }) ?? 0
for (; i < shopIds.length; i++) {
try {
fs.outputJSONSync(INDEX_PATH, i)
await curl(`${i}....`)
...
} catch (e) {
// 跑批一定是会遇到很多你预料之外问题的,防止任务卡壳要处理好异常和超时
// 错误先记录下来,不要阻塞队列
log(e)
}
}
})()
trigger 脚本里,每一轮任务都会把索引值记到文件,这样在任务崩溃并重试后不用重头再来。
这里也可以将队列每次执行前洗牌乱序,也能避免重试后跑很多重复任务。
由于一开始就做了 Web UI 界面,并且手动测试了一批店铺没有问题。等到需要跑批量任务了,总不能都一个个人肉点啊。
这时候想跑批,自然稳妥的做法是复用这套流程,模拟人的点击操作,于是用了 puppeteer 来帮我打工。
;(async () => {
let i = fs.readJSONSync(INDEX_PATH, { throws: false }) ?? 0
const browser = await puppeteer.launch({
args: [
'--no-sandbox', // 沙盒模式
'--disable-setuid-sandbox', // uid沙盒
'--disable-dev-shm-usage', // 创建临时文件共享内存
'--disable-accelerated-2d-canvas', // canvas渲染
'--disable-gpu', // GPU硬件加速
'--disable-background-timer-throttling',
'--disable-backgrounding-occluded-windows',
'--disable-renderer-backgrounding',
'--proxy-server=http://127.0.0.1:8899', // 这里用了代理
'--window-size=1440,900'
],
// headless: true,
devtools: true
})
for (; i < shopIds.length; i++) {
fs.outputJSONSync(INDEX_PATH, i)
try {
const shopId = shopIds[i]
const item = listData.find(item => item.shop_id.toString() === shopId.toString())
...
const page = await browser.newPage()
await page.setViewport({ width: 1440, height: 0 })
// 完成登录
await page.setCookie({
url: 'https://fxg.jinritemai.com',
name: 'TOKEN',
value: cookie.match(/TOKEN=(.*?)(?:;|$)/)?.[1] ?? '',
expires: Date.now() + 86400000 * 365
})
await page.goto(pageUrl)
const button1 = '#minify-images'
const button2 = '.auxo-btn.auxo-btn-primary:nth-of-type(2)'
// 等待确定按钮出现
await page.waitForSelector(button1, { visible: true, timeout: 5 * 60 * 1000 })
// 获取 dom 节点,需要将方法发送到 page 上下文执行,这个 evaluate 的函数其实是做为字符串发送到 page 上下文的
const value = await page.evaluate(el => el?.textContent?.trim(), await page.$(button1)) ?? ''
if (value !== '压缩') { // 防御代码
continue
}
await page.click(button1)
await page.waitForSelector(button2, { visible: true })
await sleep(1)
await page.click(button2)
// 30s 后再关闭页面,确保所有请求都发送,这里没有用 await,不阻塞循环
sleep(30).then(() => {
page.close()
})
} catch (e) {
console.error(e)
log(e)
}
}
})()
puppeteer 在 headless 为 false 时的坑:每次执行 page.goto 时,Chromium 都会弹到电脑最前面,打断你别的工作。网上搜了些方法都没成功,官方 issue 直接把这个问题给 close 了,close 了……
解决方法:找 IT 借了一台电脑(软件解不了就硬件解吧,哼)。
我们已经将线上所有 ISV 商家图片进行了替换,全量商家图片总体积降低 70%。从单个商家维度来看,其中压缩率最低为 31%;压缩率最高为 97%;压缩率中位数为 73%。
这部分压缩率还没有算上运行时再转成 WebP 的增益。
图片命名的混乱,有些使用 .jpg,有些使用 .jpeg,有些直接把 .png 改成 .jpg 萌混过关。优秀的操作系统和浏览器则都尽可能让我们忘记扩展名和格式。文章前面提到商家运营和设计师可能不是一拨人。乱改扩展名和用扣扣截图都是基操。
好在 imageX 抹平了这个差异,统一使用 .image 后缀。但这又带来一个问题:运行时不能提前知道图片是什么格式,不能压缩透明通道。
这里有一个可行的方案,后续计划去做:在图片入库时,在图片的 url 上带上 query。形如:https://...xxx.image#?width=200&height=100&ext=png&alpha=1
使用 query 的好处:
a. 本身 kv 结构,方便扩展。
b. 将宽高等信息带出可以在图片加载前提前占位避免抖动。
c. 不用改动现有数据结构增加新的结构体。
d. 放在 hash 上请求不会到达服务器,不会穿透 CDN,兼容性好。
有了这些信息,C 端在图片请求前就可以做一些提前优化了。
存量数据中,商家传的最大的一张图片为 3200x3200 尺寸,这在移动端上完全没有必要。目前我们已经卡了新增入口,图片宽度不可大于 1125px(3 倍 375)。
对于存量图片,修改尺寸可能带来一定风险,故本次优化专项选择了保留原尺寸。
这个问题前面也提到了,主要是现在很多图片软件默认导出就是 PNG。对没有透明度和极端清晰度要求的图片应当尽可能转成 JPG。这块之后会在产品层面上增加引导。
本次项目中很多工作是可以沉淀下来的。比如压缩图片的 HTTP 接口、单图对比工具、高阶 JSON 的替换还原方法,将来都可以继续服务新增图片的生产上。
另外,压缩的底层库 MozJPEG 也支持制作成 wasm,可以利用 B 端端侧的算力进行边缘计算,降低服务端负载。
参考抖音在上传视频前,会提前在本地进行压缩,这是一个低频高收益的操作,搭建新页面时多花一些等待时间,对于商家是可以接受的。由于是使用的 client-server 架构,这个预热还可以进一步提前,比如在商家正在编辑的空闲时间做压缩预热,这样在保存发布的时候可以做到秒速压缩了。
我们也在调研 HEIC / HEIF / AVIF 等新型图片格式,预计可以在 WebP 基础上再压缩 30%(目前兼容问题还比较大,可能要和客户端配合)。
具体的产品交互形态等我们进一步细化,等上线后再和大家分享。
后续也会把图片离线压缩做成 SDK 提供给大家使用。
大家可以通过以下链接跳转到原文,查看文中信息的真实效果:https://bytedance.feishu.cn/docx/CxHidEWE2orP6wxqjaLcfUyVnnS
欢迎大家点击左下方“阅读原文”,投递简历加入我们 😊
也可以扫描下方二维码加入我们的微信群催更 😊
Haozi. JS 随机数生成算法,什么是哲学上的「真」随机: https://math.haozi.me/random.html
[2]Zhou Wang(2004).《图像质量评估:从错误可见性到结构相似性》: https://ece.uwaterloo.ca/~z70wang/publications/ssim.pdf
[3]JP Richardson. 一个兼容 fs 的库,提供了非常多好用的方法: https://www.npmjs.com/package/fs-extra
[4]Sindre Sorhus. 文件类型推断库,同时返回 ext 和 mime: https://www.npmjs.com/package/file-type
[5]Haozi. 一个用类 linux 路径描述数据结构的工具库库: https://jsonuri.js.org/
[6]Caolan McMahon. 一个好用地控制并发的库: https://www.npmjs.com/package/async
[7]Christoph Tavan. 专业的 UUID 发生器,遵循 RFC4122 标准: https://www.npmjs.com/package/uuid
[8]Anthony Fu. ts-node 的高性能替代方案: https://www.npmjs.com/package/vite-node
[9]Zhou Wang.《客观的图像质量评估》: https://youtu.be/ibiCs_NJgCQ
[10]Oscar. SSIM 的 JS 实现: https://npmjs.com/ssim.js
关注公众号 👆 干货不迷路