I optimized and put compressed images into Images.xcassets
When I build the package and look into the contents of it, I see that all of the images are modified by XCode (build tools etc..) and for example Default-568h#2x.png (218KB) becomes LaunchImage-568h#2x.png(455KB)
This makes it impossible for me to put optimized images.
What am I doing wrong here?
Your issues is most likely premultiplied alpha channel. I ran into this same issue when designing my game engine and it was relatively painless to fix.
Last I knew there is no option to disable premultiplied alpha channels for the Xcode bundle.However, Xcode comes bundled with a textureool which can be used at build time to format your images into another format that does not suffer this same optimization. Since my code focuses on sending texture data to OpenGL i used the powerVR format PVRTC. However, you're free to utilizes whatever format you like.
If you decide to go this route you can add a build target to your project which converts all png files into which ever format you prefer.
Related
What would be the best way to include a lot of images in the bundle? I have an index of (game) items thus about 4000-5000 image files (total 27mb so not that big). Just include the whole map in the bundle or maybe first write a script that converts them to NSData? I could imagine there would be a smart way to do this so the app wouldn't have to look through all images individually to find a single one. Would love to hear your thoughts.
27mb isn't a huge amount to download so the easiest option would be to put them in an asset catalog, as Ryan Heitner mentioned in his comment this will allow App Thinning to take place in iOS 9.
I'm not sure what you mean by this:
I could imagine there would be a smart way to do this so the app wouldn't have to look through all images individually to find a single one
Each image will need to have a unique name (this is true regardless of the number of assets you have) and your code references the images by that name so it won't have to "look through all images individually to find a single one".
Alternatively if you really want to reduce the initial download size you could use On Demand Resources (another upcoming iOS 9 feature) to store them on Apple servers and loaded on demand in your code. Presumably you won't be targeting only iOS 9 though so in this case you would need to host the resources yourself and load them using standard techniques (see here, here, here, or use a library.
You should pack them in a texture atlas.
Then, the texture atlas files should be imported in your bundled via a folder reference (blue folder icon) and not a group (yellow folder icon).
Images imported in bundle in folder reference won't be optimized be Xcode on packaging. So you can make your own file optimization using imageOptim. It can compress a lot more than what Xcode can do on JPEG and PNG images.
I am trying to submit an application in App Store, and I need to decrease its memory a little bit, if this is possible. I tried a method which I am gonna describe below to make my app lighter, but with not luck.
Details
I followed these steps to see what was causing this large size
Make an archive of the project
Distribute it
Save for Enterprise or Ad-Hoc Deployment
Select the .ipa file and changed the extension to .zip
Extract it, and open Payload
Show the Package Contents
Contents
I had .png files with 680 Kb (when I added those where 32 kb approximately), I deleted them and I reduced the size of application by 2 MB. There are other files that take space but not considerably, except one executable file that is taking about 90 % of the .ipa's size.
Question
Is it possible to decrease executable file's size? If not then can you give me a hint where I should look to make my app lighter in terms of size.
P.S I use third party libraries like Vuforia SDK and libraries on GitHUB
How can I reduce the size of this executable file
You cannot reduce the size of the executable inside your built app bundle. This is your code! The only ways to reduce its size are:
Cut code. Obviously you can't do that because you would exclude functionality that makes your app work.
Remove an architecture slice. You should not do that because you want to build for all possible architectures.
Having said that... I have never generated an executable inside the app bundle anywhere near this large. Maybe you are measuring / building wrong:
Make sure you are archiving. Nothing else except an archive is worth measuring.
Make sure that you are generating a Release build when you Archive.
Make sure that your Release build settings include the full compiler optimization (smallest, fastest).
Suggestion how to reduce binary size from Reducing the size of my App:
Compiler Options
Setting the Optimization Level build setting to Fastest, Smallest [-Os]; and the Strip Debug Symbols During Copy build setting to Yes (COPY_PHASE_STRIP = YES) can dramatically lower the size of your compiled binary. These settings are the default for the "Release" configuration in Xcode projects.
Assets are almost always the main culprit of large apps sizes.
If you archive your app and export the IPA you will be able to convert it so a .zip by changing the extension and then unzip and look at the contents of the package.
If you sort by file size you will see which files are the largest. Keep in mind images with transparency are larger.
Some more insight as well: http://bjango.com/articles/pngcompression/
If you're truly concerned about the internals of the executable, build with a link map. That shows sizes by segment and by symbol.
e.g.
# Sections:
# Address Size Segment Section
0x0000AB90 0x00711D30 __TEXT __text
0x0071C8C0 0x00028D34 __TEXT __symbol_stub4
0x007455F4 0x00001A58 __TEXT __stub_helper
0x0074704C 0x00057452 __TEXT __cstring
[…]
# Symbols:
# Address Size File Name
0x000122A0 0x00000020 [ 6] ___Block_byref_object_copy_
0x000122C0 0x0000001C [ 6] ___Block_byref_object_dispose_
0x00012320 0x00000028 [ 6] ___copy_helper_block_78
0x00012348 0x0000001C [ 6] ___destroy_helper_block_79
[…]
I came across an article in the web which explains the process in the following 9 points:
Ensure that you have reached the maximum level of iOS stripping, for
more info on iOS stripping, see this post.
Enabling bitcode DOES increase the size of your over-the-air download.
In our case, it was the difference between 130 and 70MB. If you wish
to turn bitcode off, you can do so in your xcode project, or using a
post build attribute such as this one.
The Launch image in your xcode project is NOT optimized. While running
something through a compression algorithm doesn’t work because Unity
decompresses and stores images without much compression in order to
decrease startup time, it does work for the launch images that are
generated by Untiy after project generation.Run all your images
through a lossless compression algorithm in order to save a few MBs
(10 in our case).
If this isn’t enough, it’s time to start looking at your asset logs.
Run your build in Unity and open the Editor log, it’s this
ridiculously small icon next to your console preferences. In our case,
they are already optimized. With a 111MB in uncompressed assets, we
were able to achieve an over-the-air size of 70MB. Go over each asset
and change the resolution to the lowest possible quality that your
users won’t notice. The best compression setting is PVRTC for iOS.
While you are at it, check out Resource Checker in order to see large
textures in-memory. Reducing the resolution on these will also
decrease build size, as well as memory consumption. Also, please use
sprite atlases – you will see the wonders this does!
Check for unused libraries in your project, or libraries that are
using far too much space for their functionality. Commands such as df
and ls -lh might come in useful here, run these in your project files
and see which files really stand out and need to be reduced in size.
Keep in mind that these individual libraries do not necessarily have
the same build effect as your textures – generally, these are compiled
for multiple architectures, and if a library is 20MB, it generally
only affects your build size by about 6MB, due to the fact that
libraries often include architecture support for i386, arm64, and arm7
in the same library
Check that the /Plugins/Android is not included in your iOS project.
See this post for more information.
Make sure you don’t have any unused scenes in your build settings.
Build your project, and check out the archive before you submit it to
iTunes Connect. You can do so by clicking “Product -> Archive”,
letting it archive, and when it’s done, “Window -> Organizer” to pop
up this interface and find the build location.
Under “Products/Applications/game.app” Run the mv command to turn your
.app into a browsable directory.In this directory you’ll be able to
see a lot of the stuff we did, and also find inspiration for more
things you can do.
Now, there are a lot more things that could result in a bigger than
expected build size, and I’m sure there are a lot more things you can
to do get below it also.
If you’d like to add to this list, or have further questions (I’m usually happy to answer questions), leave a comment below with your specific use case, and I’ll try to help!
All the best,
Pim
If you have already checked all your assets (images, audio, etc... ) just check if you need all the external libraries (3rd party libraries out of the iOS sdk) that you import in your app.
Does anyone know why Xcode (4.6.3) would start TiffUtil in the Copy Resources Phase instead of just copying PNG files to the bundle using CpResource . I'm now ending up with some normal PNG icons and splash screens and a few tiffs. I've checked the images, there doesn't seem to be anything wrong with them.
Thanks,
Daniel Dekkers
I ran into this last week!
The problem was in the build settings.
Combine High Resolution Artwork COMBINE_HIDPI_IMAGES
Combines image files at different resolutions into one multi-page TIFF
file that is HiDPI compliant for Mac OS X 10.7 and later. Only image
files in the same directory and with the same base name and extension
are combined. The file names must conform to the naming convention
used in HiDPI. [COMBINE_HIDPI_IMAGES]
It wants to take your x.png and x#2x.png and turn it into a multi-page TIFF. But since this option isn't valid for iOS, none of your images will work correctly.
So, in the build settings, try and find "Combine High Resolution Artwork" and turn it off. If its not in there, you can also search for the COMBINE_HIDPI_IMAGES flag and turn it off.
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 than they were in my past releases. Of course, this is putting me over the 3G download limit of 50 MB so I'd really like to figure out what's going on.
I am currently using version 4.5 of Xcode on OSX 10.7.5. If I recall correctly the previous version was built with Xcode 4.2. I tried turning on and off PNG compression in the build settings but that had no effect on the image sizes in the bundle.
To give a concrete example, my largest PNG image is 1.9 MB as a source asset. It is 2.1 MB in the old app bundle, and 2.5 MB in the new app bundle.
Did Apple change the way the PNG compressor works or is there maybe a setting that I'm missing or something?
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.
Xcode 5 now got changes in image compressions. the best and compressed way is to use asset catalogs.
If even using Xcode 5 and asset catalogs doesn't result well for your app, check the other relative post PNG optimization issue using pngcrush tool for more answers could be helpful
Using David H's script, I found that Xcode is also passing the command line parameter "-f 0" to pngcrush. The man page indicates that the "-f 0" will disable any IDAT filtering before compression which can result in a larger PNG file. Testing on my 1.9 MB example file from above confirms:
pngcrush -iphone in.png out.png gives the 2.1 MB result that I am looking for
pngcrush -iphone -f 0 in.png out.png yields the undesired 2.5 MB result
Now the questions are: Why did Apple change this? Will it break image loading in some way if I work around it? If not, is there a setting for this in Xcode or will I always have to use a script to filter out the "-f 0" argument?
The RIM compiler performs extra optimization and compression on the resulting ".jar" while building the final .cod file, but there are things that can be done by the developer to significantly reduce the final .cod file size.
One such thing would be to run PNGCrush, OptiPNG, or a similar tool to reduce the size of the included .png files. In an application with a large number of image files (such as an app featuring a custom UI), this can yield a significant reduction in the final .cod file size.
How can I optimize the final .cod file for size? Something to be done in the .java code itself? Something to be done in the project structure? Something to be done to the files or resources?
Good question!
Compression (GZip, ZLib) may be useful when installing large bin/txt/xml files
And that's what they say in RIM:
Setting appropriate access
Avoid creating interfaces
Use static inner classes
Avoid unnecessary field initialization
Import individual classes
Also, interesting facts:
All images was PNG format. I want to
know why : compile with JDE 4.5 -->
900k, compile JDE 4.2, 2.6.1, 4.7 -->
1800k. What is difference ? Thanks !
Seems that JDE 4.5 uses more optimization techniques than older JDE
versions.
Check the image below, it produced by PngOut from 55 K png image. It's size is 3427 bytes
I think you most certainly want to consider a shrinker (and optimizer/obfusticator) like ProGuard (http://sourceforge.net/projects/proguard/). This can shrink your Java code by collapsing full class names into shortened versions, removing unused code, etc. Along the way it can improve the efficiency of the code. It's great. The only hard part is modifying your build to optimize the generated class files before the RIM build stuff gets its hands on it to make a .cod.
A good approach is to GZIP all resources and then use net.rim.device.api.compress.GZIPInputStream class to load compressed files. That way you don't have to implement decompress code by yourself.
Also you can use pngout for optimizing image resources.
Make sure that you use PNG-8 instead of PNG-24 when possible. Try to minimize number of colors in palette. After this, use PngOut.
As for ProGuard, I have problems on old BB devices when using optimize feachure of Progruard ("-dontoptimize" switch) - so use it carefully, although it is a great tool.