Reputation: 363
I have a universal game written in Swift with about 200 images, which take up around 200 MB of ram. However, on storage they take up only 15MB. On Xcode the size of the default view is 600x600, and the view that my UIImageView is residing in is 200x200. My goals is to have an image that uses the least amount of ram, and uses the least amount of storage space, but retains its quality.
For the ram: Should I run some code to resize the image prior to displaying it in order to use less memory, which I worry may be slightly CPU intensive.
For the storage space: Is there a way I can calculate the image dimensions I would need in order to satisfy all iOS devices?
Or am I looking at this completely the wrong way.
Upvotes: 0
Views: 251
Reputation: 437632
The assets catalog is going to be the most efficient way to have different assets for different devices, while enjoying "app thinning" which can allow a device to only download the assets needed for that particular device (keeping app downloads as small as possible).
For example, if you have a 200x200 image view, if you want to be most memory efficient for different types of devices, you'd have a 1x (i.e. 200x200), 2x (i.e. 400x400), and 3x (i.e. 600x600) rendition of that asset, and through the efficiency of assets catalogs, the device would download and use the asset of the appropriate scale for that device.
If, on the other hand, you only supply only a 1x image (e.g. a 200x200 image in our above example), it will look pixelated on a retina device, which will put off many users. Or you can supply only a 3x image (e.g. a 600x600 image), it will look sharp on all devices, but you'll be taking up more memory than needed on non-retina devices (or, if you do just-in-time resizing, you can offset the memory impact, but at the cost of performance).
So, if you want the best looking and most responsive UI that works on well on devices of multiple scale
resolution, you'd supply all three resolutions. And if you use an asset catalog, it makes the selection of the asset at runtime easier, and you open up the possibility of app thinning.
Upvotes: 2