I just recently talked to an app marketing agency and they are strongly recommending that I find a way to take my 153MB app and somehow get it under the 50MB mark that is the current standard for downloading over a wireless network (3G, 4G, etc.).
I have no idea where to go from here. As far as app size goes, my app is very UI intensive and I have a combination of (mostly) JPGs, PNG's, and a few small videos. I've already run all my jpg's through JPEGmini and as many png's as still looked alright through tinypng.org.
I'm curious if I could somehow "compress" or zip my resources and then unzip them in code to significantly reduce my app size (Before it's installed on the device...I don't care how big it expands to after it's downloaded and installed).
Host the video somewhere else and then downloading them after the app starts for the 1st time (or when they are actually played) maybe the biggest win. Other small wins would be drawing procedurally as oppose to using images. What is the combined size of your images, also the combined size of your videos?
Related
I am planning to ship an app with at least 20 pictures that can be at big as 10mb each. They are pictures that the user is likely to zoom in quite a bit therefore it is a requirement to keep the resolution quite high. We are still trying to make them smaller, but even so, its unlikely that they are going to be less than 7mb each.
The images can be shipped with the app as well as additional pictures can also be downloaded. The requirement is for the pictures to be available offline once the user downloads them as the app is to be used in remote areas by researchers.
What is the best mechanism to store them and how should I store them in iOS Swift 3?
Thanks for your help in advance.
You can store your pictures in document directory of the app and store the path in SQLite DB.
There are not rules but a set of best practices.
To store them I suggest you to save them directly into your resources, not Xcode image asset, this is because "image asset" can only be called with the imageNamed: method of UIImage, that has the side effect of cache images.
Then you can create a plist file with an array of image names, and fetch your info from here. If you need something more complicated there is Core Data, but I can't see an application of it with your spec.
What is the size of an uncompressed image in memory? An approx
equation n_pixel_height * n_pixel_width * n_channels in bytes (supposing 8 bit for channel)
If your images are about 10Mb in jpg they are compressed, thus means that they will take a huge amount of memory. memory on this kind of devices is a precious and short resource.
If your app exceeds the memory limit, after a set of callback such as didReceiveMemoryWarning, if you don't free enough memory, you app will be killed.
Alway try on device in this case and not on simulator because the simulator use your mac resources.
Now how to handle big images?
You can use CATiledLayer, you can find a lot of tutorials online. CATiledLayer as the name suggest creates a tiles of layer, each tile should correspond at a piece of your image, and it draws them only when they are visible.
Unfortunately it draws asynchronously this means that your tiles can be shown not exactly at the same time, there some strategy to avoid that issue, one is explained in an apple sample code.
Of course there is a problem that needs to be solved, how can I cut my large images into tiles?
You can do programmatically or provide them already cut as resources of your application
I'm working on an iPad-only iOS app that essentially downloads large, high quality images (JPEG) from Dropbox and shows the selected image in a UIScrollView and UIImageView, allowing the user to zoom and pan the image.
The app is mainly used for showing the images to potential clients who are interested in buying them as framed prints. The way it works is that the image is first shown, zoomed and panned to show the potential client if they like the image. If they do like it, they can decide if they want to crop a specific area (while keeping to specific aspect ratios/sizes) and the final image (cropped or not) is then sent as an email attachment to production.
The problem I've been facing for a while now, is that even though the app will only be running on new iPads (ie. more memory etc.), I'm unable to find a method of handling the images so that the app doesn't get a memory warning and then crash.
Most of the images are sized 4256x2832, which brings the memory usage to at least 40MB per image. While I'm only displaying one image at a time, image cropping (which is the main memory/crash problem at the moment) is creating a new cropped image, which in turn momentarily bumps the apps total RAM usage to about 120MB, causing a crash.
So in short: I'm looking for a way to manage very large images, have the ability to crop them and after cropping still have enough memory to send them as email attachments.
I've been thinking about implementing a singleton image manager, which all the views would use and it would only contain one big image at a time, but I'm not sure if that's the right way to go, or even if it'd help in any way.
One way to deal with this is to tile the image. You can save the large decompressed image to "disk" as a series of tiles, and as the user pans around pull out only the tiles you need to actually display. You only ever need 1 tile in memory at a time because you draw it to the screen, then throw it out and load the next tile. (You'll probably want to cache the visible tiles in memory, but that's an implementation detail. Even having the whole image as tiles may relieve memory pressure as you don't need one large contiguous block.) This is how applications like Photoshop deal with this situation.
I ended up sort of solving the problem. Since I couldn't resize the original files in Dropbox (the client has their reasons), I went ahead and used BOSImageResizeOperation, which is essentially just a fast, thread-safe library for quickly resizing images.
Using this library, I noticed that images that previously took 40-60MB of memory per image, now only seemed to take roughly half that. Additionally, the resizing is so quick that the original image gets released from memory so fast, that iOS doesn't execute a memory warning.
With this, I've gotten further with the app and I appreciate all the idea, suggestions and comments. I'm hoping this will get the app done and I can get as far away from large image handling as possible, heh.
I'm currently working on a picture-sharing app on iOS, and my developer is struggling mightily with managing memory. I would really appreciate some help.
Take this "user feeds" module, my developer can't design a scroller that maintains a smooth scroll unless much of the thumbnails are preloaded before scrolling starts. This expectedly makes the initial loading experience much longer than desired. He used server-side compression which further compresses IPhone images (originals were around 2mb) that were already compressed to 200kb on the iOS side down to around 20kb. The end result is a highly blurry low-quality thumbnail, especially displayed at the size seen in the video.
https://dl.dropboxusercontent.com/u/76154448/Scrolling%20Down%20Only%20Works%20With%20Highly%20Compressed%20Thumbnails%20and%20Needs%20Pre-loading%20to%20Ensure%20Smooth%20Scrolling.mp4
He originally just used a cropped version of the underlying image as the "thumbnail," but with each picture being 200kb, 10 "thumbnails" loaded is already 2MB of memory used. Another 2MB is being used on thumbnails of user avatars, since those were not yet compressed by the server. We designed the feed, like many other picture apps, so that more images can be loaded by scrolling down.
My questions are this:
What is a good technique to do server side compression of thumbnails without quality loss? How does an app like Streamzoo do this?
https://dl.dropboxusercontent.com/u/76154448/Smooth%20Scrolling%20with%20Streamzoo.mp4
What is a good technique for managing the increase in live bytes? How do picture apps like Pic Collage manage to show up to 200 thumbnails while seemingly keeping every image cached without crashing?
Any responses are greatly appreciated!
He's probably creating all UIImageViews once the server responds. He could use UICollectionView to lazy load views, so only a few of them would be on memory on the same time.
I wrote an article about performance tips and tricks, and this one is covered there.
I am creating a kind of 'map' in my app. This is basically only viewing an image with an imageView/scrollView. However, the image is huge. Like 20,000x15,000 px or something. How can I tile this image so that it fits? When the app tiles by itself, it uses way too much memory, and I want this to be done before the app I launched, and just include the tiled, not the original image. Can photoshop do this?
I have not done a complete search for this yet, as I am away, and typing on an iPhone with limited network connection..
Apple has a project called PhotoScroller. It supports panning and zooming of large images. However, it does this by pre-tiling the images - if you look in the project you will see hundreds of tiles for various zoom sizes. The project however does NOT come with any kind of tiling utility.
So what some people have done is create algorithms or code that anyone can use to create these tiles. I support an open source project PhotoScrollerNetwork that allows people to download huge jpegs from the network, tile them, then display them as PhotoScroller does, and while doing research for this I found several people who had posted tiling software.
I googled "PhotoScroller tiling utility" and got lots of hits, including one here on SO
CATiledLayer is one way to do it and of course the best if you can pre-tile the images downloading them from the internet (pay attention on how many connection you are going to open) or embedding them(increasing overall app size), the other is memory map the image on the file system (but an image with that res could take about 1GB), take a look at this question it could be an intersteing topic SO question about low memory scenario
I'm currently trying to understand how Unity creates its builds because my teams is creating a texture heavy game and it's crucial that we have enough memory for the game to function in the various environments (specifically web and iOS).
To test out the memory, I created a scene with a 166MB Resources folder and a cube. If you want to try it you can download it here: http://www.mediafire.com/?a137tz6anatf6qi. The cube's for debugging purposes: When the scene is just loaded, it's green. It changes to blue and a second later starts to load all the textures in Resources. When it turns red it unloads all unused assets (which is basically everything because I didn't assign the textures to anything).
Now I've read about the disadvantages of Resources folder in various places, but my issue is: with an empty scene and one game object, when the scene just starts, the process already takes up more than 600MB in the task manager!! After loading all Resources, it goes up to 1.3GB. Why? What is the 600MB that is being loaded? And how come the Resources folder bloats up by ~6 times?? I read something about the compression actually increasing the file size of the images, is that true?
You do not specify if you are running a build or in editor mode. I'm guessing you are running in editor mode, and I think Unity loads all resources in editor mode in case you want to change something on the fly.
Make an actual build of your cube test project and re-check the memory usage. According to this, it will not even put your unused resources in the build (and as far as my experience goes, that is true).
Unity is already very efficient on doing what you want (outside the editor mode), so I think you shouldn't have to worry too much with it. Take a trial version of Unity IOs and build your cube project for actual device testing.
This page lists texture compression types you can use for each platform. You may want to check out:
"RGB Compressed PVRTC 2 bits Compressed RGB texture. Lower quality format suitable for diffuse textures. 2 bits per pixel (16 KB for a 256x256 texture)"