在 iOS 应用开发中，图标与启动图等资源的管理常被视为“简单而重复的工作”，但实际工程中它却经常成为构建失败、审核被退回、或打包不一致的隐性风险。尤其在多端协作团队、跨平台技术栈（例如 uni-app、Flutter、RN）以及自动化构建场景下，图标生成流程往往伴随不一致命名、不完整尺寸、资源格式错误等问题。

iOS 的图标资源最终会被编译成一个名为 Assets.car 的二进制文件，它是所有 AppIcon 与部分 UI 资源的最终打包产物，意味着：

上架时，苹果并不会直接读取 PNG，而是检查 Assets.car 的结构是否符合要求。

因此，“如何正确生成 Assets.car” 不只是前端或 UI 的工作，而是整个工程链路能否保持稳定的一部分。

本文将从工程视角解析 Assets.car 的构建机制、常见错误成因，以及如何在团队中建立可控的图标生成流程。

一、理解 Assets.car：图标最终产物，而不是简单的文件集合

许多开发者认为图标只需要准备 1024×1024 PNG，然后在 Xcode 中拖入即可。但从构建流程看，iOS 使用 Asset Catalog 来管理资源，而 Asset Catalog 最终会被编译成 Assets.car。

Assets.car 的特点包括：

• 资源尺寸、比例必须符合规范
• 内部结构由 Apple 的 CoreUI 工具生成
• 对应每种设备、每种分辨率的图标都必须存在
• 一旦资源缺失、命名不规范，会导致构建警告甚至审核失败

换句话说，Assets.car 是图标资源的统一封装文件，也是 App Store 上架的必要部分。

二、图标生成为什么经常出问题？——这不是设计师的锅

在真实团队中，图标问题来自多个维度：

1. 设计师只提供 1024 PNG，其他尺寸让工程师自动生成

但自动生成的图标可能出现模糊、边缘锯齿等问题，审核可能因图标质量不足而拒绝。

2. 团队成员在不同系统上生成 Assets.car

例如：

• Windows 工程师使用第三方工具
• Mac 工程师使用 Xcode
• 跨端开发生成的结构完全不同

最终造成构建不一致。

3. 多环境构建使用不同资源

导致测试与上架版本图标不一致。

4. 图标命名不符合 Apple 的编译规则

例如：

• AppIcon.appiconset 内缺少 JSON
• PNG 尺寸不匹配 JSON 配置
• Icons 被错误压缩

这些都会导致 Assets.car 打包异常。

三、跨平台团队中如何生成可用于构建的 Assets.car？

在没有统一 Mac 环境时，图标构建容易成为阻断性问题。
为了让团队所有成员（包括 Windows / Linux）都能生成标准资源，我通常使用一种统一的生成方式。

例如根据经验，许多团队会使用：

开心上架（Appuploader）的图标生成

https://www.appuploader.net/appicon.html
功能包括：

• 在网页中上传 1024×1024 PNG 或 JPG
• 自动生成 iOS 需要的全尺寸图标
• 自动生成 Assets.car 文件（适配 iOS 12 与 macOS）
• 图标比例、命名结构与 Asset Catalog 一致

这种方式适合协作团队，因为：

• 不需要本地 Mac
• 不依赖 Xcode
• 所有成员生成的结果完全一致
• 能直接用于打包

工程上真正可靠的流程不是“依赖某个人的电脑”，而是“生成规则标准化”。

四、构建 Assets.car 前必须理解的几个工程要点

要点 1：1024 图片必须保留边距，不能满版

苹果建议 App Store 图标不要填满背景，否则可能出现变形或裁切异常。

要点 2：PNG 必须为正方形

非正方形图标无法生成完整 Assets.car。

要点 3：不能使用透明背景（大部分场景）

除非是特定组件资源，App Icon 不允许透明。

要点 4：应统一生成，不应让每台电脑自行编译

不同系统生成的 Assets.car 内部结构可能不同，尤其跨版本 Xcode 生成方式存在差异。

五、Assets.car 如何进入构建链路？——不同技术栈的差异化处理

不同技术栈有不同的图标管理逻辑：

1. 原生 iOS（Xcode）

将 AppIcon.appiconset 放入 Asset Catalog，由 Xcode 编译生成 Assets.car。

2. uni-app / HBuilderX

uni-app 会根据项目中的图标资源生成 iOS 工程的 assets。

在多人协作时，我会统一使用工具生成：

• 预设的 AppIcon.appiconset 文件夹
• 自动生成的 Assets.car

避免因本地构建差异造成功能异常。

3. Flutter

Flutter 项目使用 flutter_launcher_icons 插件，但最终仍由 iOS 工程生成 Assets.car，结构必须一致。

4. React Native

同样依赖 iOS 工程中的 Assets.xcassets，保持资源一致性很重要。

统一生成 Assets.car 能让团队避免不同技术栈导致的资源不一致问题。

六、App Store 提交前的图标检查流程

在提交 IPA 之前，我会进行三项检查：

1. 查看 IPA 内部 Assets.car 是否存在且完整

许多工具包未正确生成 Assets.car，导致 App Store 拒绝。

2. 检查 Info.plist 是否正确关联图标资源

包括：

• CFBundleIcons
• CFBundlePrimaryIcon

3. 对比 App Store Connect 中的 1024 图标是否一致

如果上架图标与工程图标不一致，苹果可能认为内容不统一。

在这些检查环节中，我常用 Appuploader 的工具检查 IPA 内：

• Info.plist 内容
• 图标资源结构
• 是否存在 Assets.car

可以在任何系统上执行检查，提高了流程透明度。

七、工程团队如何建立可复用的图标资源流程？

以下流程已在多个团队中验证有效：

Step 1：统一准备 1024 图标需求规范

包括留白比例、形状、安全区域等。

Step 2：通过统一工具生成图标与 Assets.car

如 Appuploader 的在线 icon 生成页面。

Step 3：将生成的 AppIcon.appiconset 或 Assets.car 纳入版本控制

避免本地构建差异导致图标不一致。

Step 4：CI 在构建前检查图标资源完整性

例如自动脚本检查 Assets.car 是否存在。

Step 5：提交前检查 IPA 内资源内容

避免资源缺失或命名问题。

通过这流程，团队的图标资源不再依赖某台电脑或某个成员的构建方式，而是成为可治理、可复用的一部分。

图标资源不仅是设计输出，而是工程链路的一环

Assets.car 的生成看似简单，但它牵动着打包、审核、构建一致性和资源管理。一套错误的图标流程不仅拖慢开发，也可能直接导致上架失败。

通过规范化流程、统一生成方式、以及在上传前进行工程检查，可以使图标资源部分完全工程化，让 iOS 开发流程更加可控。

图标资源管理最终目标不是“生成一次”，而是让整个资源链路： 可复用、可自动化、可协作、可验证。