Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/xcode/7.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Ios Xcode内置png压缩效果_Ios_Xcode_Sprite Kit_Compression_Png - Fatal编程技术网

Ios Xcode内置png压缩效果

Ios Xcode内置png压缩效果,ios,xcode,sprite-kit,compression,png,Ios,Xcode,Sprite Kit,Compression,Png,我有一个关于png-8与png-24使用情况与Xcode内置的问题 一些转换成png-8的图像可以这样保存,因为png-24版本之间的差异不容易被注意到。但有些图像必须存储为png-24,以便质量保持在高水平。。。当像png-8一样保存时,相同的图像大约要小3倍,所以我想使用png-8和png-24时,在内存消耗方面会有一些好处。但我不确定的是: iOS是否更喜欢png-24 在iOS中使用png-8而不是png-24有什么问题吗?首选什么 当Xcode中的COMPRESS_PNG_FILES

我有一个关于png-8与png-24使用情况与Xcode内置的问题

一些转换成png-8的图像可以这样保存,因为png-24版本之间的差异不容易被注意到。但有些图像必须存储为png-24,以便质量保持在高水平。。。当像png-8一样保存时,相同的图像大约要小3倍,所以我想使用png-8和png-24时,在内存消耗方面会有一些好处。但我不确定的是:

  • iOS是否更喜欢png-24
  • 在iOS中使用png-8而不是png-24有什么问题吗?首选什么
  • 当Xcode中的COMPRESS_PNG_FILES设置为YES时,在PS(或像TexturePacker这样的程序)中优化图像有什么好处,因为我想Xcode以某种方式覆盖了在PS中完成的优化
  • 当优化图像时,Xcode实际上做了什么

我知道让Xcode做它应该做的事情可能已经足够了,特别是对于有足够内存和cpu能力的新设备,但我很好奇“引擎盖下”发生了什么,这是不是浪费时间在Photoshop中进行优化?

除了PNG8和PNG 24之间可用的颜色之外,主要区别在于透明度方面

PNG8 alpha有时在外观上会有些锯齿状,而PNG24则更加平滑。如果alpha不是您所关心的问题,并且图像看起来足够好,那么PNG8可能是一个不错的选择

PNG8 Alpha

PNG24 Alpha

Xcode使用后台优化.png文件。也是一篇很好的博客文章,可以回答你的问题

  • iOS是否更喜欢png-24
iOS当然喜欢它的图像接近自己的硬件格式(见下文)。但是,它可能不会假定某种格式,也不会随意转换图像。这意味着默认的后处理可以将图像从调色板(8位)转换为真彩色图像,如果应用程序希望其图像包含调色板,这将是破坏性的。调色板图像有很多好的和正确的用法

  • 在iOS中使用png-8而不是png-24有什么问题吗?首选什么
颜色深度-对于某些类型的图像(但不是所有图像),颜色深度越高越好。尺寸-越小越好(决定什么时候,你可以自己决定)。除了Sangony州之外,PNG规范非常慷慨,即使在索引模式下,也允许使用多于一位的alpha。也就是说,通常的RGB调色板也可以是RGBA,包括alpha。我不知道更常见的PNG格式有什么“问题”,甚至不常见的

  • 当Xcode中的COMPRESS_PNG_FILES设置为YES时,在PS(或像TexturePacker这样的程序)中优化图像有什么好处,因为我想Xcode以某种方式覆盖了在PS中完成的优化
Photoshop在优化PNG方面不是非常好,但它肯定不是最差的
pngcrush
(原文)是专门为尝试从PNG中挤出最后一个字节而编写的——但在最高设置下,这确实需要一段时间。我可能在不知情的情况下使用了苹果改良的
pngcrush
,因为它默认是“开”的;我在编译代码时没有发现如此大的延迟,所以苹果的默认设置可能不是最高的。这表明手动运行
pngcrush
可能是值得的,在这种情况下,您肯定不希望XCode撤销它

  • 当优化图像时,Xcode实际上做了什么
最明显的“优化”是:将存储顺序从RGB切换到BGR,并通过将alpha通道与颜色通道预乘来丢弃alpha通道。另见

据推测,存储顺序thingy对于默认目标设备(iPad、iPhone)来说是最佳的。预乘alpha是一种常用的优化方法,因为这样可以减少实时显示图像所需的计算量。(它也有一些缺点。)


如果没有任何精确的测量,人们只能推测这些优化对现代硬件是否真的重要。所有到“显示”格式的内部转换都可以尽快缓存。

在这些链接中,我发现使用png-8当然是可能的,但不推荐使用。这是链接:但没有解释为什么会这样?你知道这是为什么吗?是的,我不想在这件事上为阿尔法费心。只是试着将背景图像保存为png-24和png-8,对于这个特殊的例子,仔细观察两者并没有明显的区别。但是在大小上有明显的区别,800kb和300kb。所以,我很好奇iOS/Spritekit更喜欢什么…谢谢你的回答…我将再次仔细阅读,以了解所有细节。