我使用 Matt 提出的程序进行了几个额外的测试：
- 当最小部署目标是 iOS 6 时，不会生成 Assets.car。
[UIImage imageNamed:]返回nilJPG 图像，除非“.jpg”扩展名作为图像名称的一部分提供
- 当最小部署目标是 iOS 7 时，会生成 Assets.car，但它只包含那些在 Asset Catalog 中作为 PNG 导入的图像。所有 JPG 都被复制到 Assets.car 之外。除非“.jpg”扩展名作为图像名称的一部分提供，否则
[UIImage imageNamed:]返回JPG 图像。nil
- 当最小部署目标是 iOS 8 时，Assets.car 包含所有图像。它的大小为 13MB。
[UIImage imageNamed:]即使未指定“.jpg”扩展名，也能正确返回 JPG 图像。包含“.jpg”扩展名时，图像也能正确加载
- 当最小部署目标是 iOS 9 时，Assets.car 包含所有图像。它的大小为 11.5MB。
[UIImage imageNamed:]即使未指定“.jpg”扩展名，也能正确返回 JPG 图像。包含“.jpg”扩展名时，图像也能正确加载
我使用了Matt 建议的图像提取工具从这些资产中提取图像。我只能从配备 Retina 的设备的档案中导出，并且我可以确认所有图像都具有正确的分辨率（即只有视网膜尺寸，iPad 特定图像被忽略）。然而，该工具以 PNG 格式保存所有这些文件，因此文件夹的最终大小总是比 Assets.car 大。
最令人惊讶的是，案例 3 和案例 4 的文件夹大小相同（39.4MB）。此外，图像似乎完全相同。所以，我真的很想知道那里会发生什么，因为这些情况下 Assets.car 的大小有 2MB 的差异。
总而言之，我们仍然不确定这种测试方法是否可以用来准确地模拟 App Thinning 行为。所以，如果有人有这方面的个人经历，如果他们能分享出来，那就太棒了。
但是，假设为 AdHoc 导出特定设备会产生与 App Store 执行的实际 App Thinning 相同的结果，我们可以得出以下结论：
- 仅当部署目标是 iOS 7 或更高版本时，才会启动应用程序精简
- JPG 图像的应用程序细化仅适用于从 iOS 8 的最低部署目标开始
[UIImage imageNamed:]仅当通过资产目录正确处理 JPG 图像时，才正确返回 JPG 图像而不提供“.jpg”扩展名。如前所述，仅当最小部署目标是 iOS 8 或更高版本时才会发生[UIImage imageNamed:]如果指定了“.jpg”扩展名，则始终加载正确的图像。
最后两个结论似乎与这个问题无关，但我在 Stack Overflow 上发现了几个关于如何使用 Asset Catalogs 正确加载 JPG 图像的相互矛盾的意见。有些人声称您可以在不提供“.jpg”扩展名的情况下加载它们，而其他人则抱怨这种方法不起作用。我认为上面的 3 和 4 详细解释了在这种情况下发生了什么以及为什么人们会得到不同的结果。
