每辆车都有相同的构图，这才让列表看起来设计精良。
把车辆图像接入您的产品，不必大费周章。清晰的文档、开放的 SDK 和现成的插件几分钟内就能接上您的技术栈，我们的状态页面还会实时显示 API 的运行情况。
我们通过仅请求渲染的宽度，大幅减少了列表视图的负载，黑暗模式在我们切换到透明裁剪的那天就不再是特殊情况了。
所有这些，因为交付的内容是图像 URL。任何从 URL 渲染图像的内容都能完全集成，解析步骤在您的后端中，与客户端堆栈无关。
通过 width 参数请求宽度变体，并按设备选择，就像网页上的 srcset 一样。三种尺寸在实践中覆盖了手机到平板。
通过您的正常管道缓存它们，稳定 ID 作为键。对于固定车队，构建时的捆绑也适用，许可证涵盖了存储的副本
一次性设计：加载时的固定比例占位符，缺失时的品牌回退，并记录标识符。响应还标记了回退，如替换的车型年份，因此您决定显示什么。
如果你缓存的话，就不是。在目录更新时解析，从你自己的存储或CDN提供服务，这样应用就不会在关键路径上等待我们的源。
有一个用于 JavaScript 栈的 npm 包，REST API 够小，原生团队通常在一个下午内将其包装起来。文档包括完整的参数参考。
车辆图像以其他人的决定形式到达应用团队：列表已存在，照片就是那样，应用必须在停车库里的三年前的手机上让它们平滑滚动。大部分的工程努力都用于弥补那些从未为应用制作的图像。
最大的收获令人尴尬地简单：请求卡片渲染的大小。将1200像素的图像发送到300像素的单元格中的列表视图，是在浪费用户的电池和耐心去处理没有人看到的像素。通过将宽度和格式作为请求参数，正确的尺寸变成了配置，性能预算不再与设计对抗。
在目录更新时服务器端解析，缓存到您自己的存储中，将我们的 CDN 作为补充而不是主要来源。应用的关键路径仅依赖于您控制的基础设施，这就是外部图像目录的感觉：无处不在，却又无处可见。
每辆车都有相同的构图，存在时不易察觉，缺失时却显而易见。固定的宽高比防止单元格跳动，均匀的照明保持暗色模式一致，透明的剪切图让设计系统拥有每一个背景。列表不再看起来像聚合内容，而是像应用程序。
从您的数据中发送一些VIN或规格，并告诉我们您渲染的卡片大小。您将获得可以直接放入构建中的URL。
