Why are PNG images larger in the iOS app bundle than in my project?

后端 未结 3 951
感情败类
感情败类 2021-02-07 19:03

I am in the process of updating Hungry Helga (iPhone and iPad versions) for iOS 6, and all of the PNG files in my new app bundle archives are between 20 and 40 percent larger th

3条回答
  •  长发绾君心
    2021-02-07 19:36

    I do not work for Apple nor do I have any inside information - however, I did poke around and have some theories. If you use terminal you can cd into the Xcode.app and find pngcrush there:

    $ find . -name pngcrush ./Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush

    If you then run:

    ./pngcrush -?
    

    you find some interesting tidbits:

    | It was compiled with LLVM 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-420.0.12) and modified by Apple as indicated in the sources.

    and

    -iphone (optimize for iPhone OS)

    Since I too saw that some large pngs where also much larger in the bundle than the original (which I had previously crushed myself!), I wanted to see how Xcode uses pngcrush. I used an old UNIX trick:

    • move pngcrush to xpngcrush
    • create a new executable shell file that calls pngcrush with the same argument list
    • log the arguments into a text file in /tmp

    What I found was that Apple calls pngcrush as:

    pngcrush -q -iphone oldFile newFile

    One can infer from this that this Apple specific feature of pngrush was designed specifically to tailor the image for iOS. I say tailor, not crush.

    Does Apple really care if your png is the smallest possible file, to save the greatest amount of space? I'd argue, not really - the devices have fairly large file storage space. Do they really care if your app downloads really fast? Again, I'd argue not really, since the user is going to assume the time is related to the size of the app, and that that is under the control of the developers.

    However, what the user is going to hold Apple accountable for is the launch speed. From the first tap to when the app starts doing something - people will believe that is all the speed of the device (which we developers know is not strictly true). With the new iPad3, some of the launch images are now really big, so what can be done to make loading them as fast as possible?

    I don't know the answer to that question, but I can imagine that Apple decompresses the original image, then re-compresses it with settings that make loading it in the device as fast as possible.

    PS:

    1) I just disabled the crush option, and observed Xcode 4.5 copying my png files without modification.

    2) To get your app size down, have you tried using JPEGs with a high quality setting - even 1? Such images will look very good and be much much smaller. Virtually all images in my app are JPEGs. You can experiment with Preview to do the conversions.

    EDIT: it occurred to me there may be an elegant solution to this. That is, for really important images - ones that you want to appear as fast as possible - then use pngcrush with the '-iphone' flag. For others, use more standard pngcrush options.

    One way to do this is to create a new image directory, and write a shell file that pre-processes every png with a real crusher or tje '-iphone' flag, putting the output in the original image folder (where Xcode can get them). Then turn off the automatic 'Crush PNG Files' option.

    EDIT2: I entered a bug at bugreporter.apple.com and posted on the Xcode listserv - if you have an interest in this bookmark the question and come back when its updated.

    EDIT3: someone gave me a link that explains in more detail the how and why of Apple's '-iphone' option ImageOptim

    EDIT4: Apple responded to my bug report, confirming that they modify the images for easier processing by iOS, which may make them larger, by intent.

提交回复
热议问题