Oomph does an awesome job of taking the complexity out of creating killer content for your apps & publications. But because it seems so simple and easy to use, it's very easy to get carried away and overdo your content, putting in too many bells and whistles. Without taking the appropriate level of care when preparing your content, you can cause page loads to be slow, or animation timings to be off and at worst, use all the memory on the iPad causing the app to crash.
Below is a collection of tips & tricks that can help you avoid common memory & performance related issues when developing content.
Consider all device types
Your content may work perfectly on your new iPad, but how is it going to perform for a user with an iPad 1 or 2? Be sure to test on a range of devices wherever possible - the original iPad 1 has only one quarter of the memory capacity of the new iPad and as such, can't handle what the new iPad can.
Transparent Animated Layers
Avoid using layers that contain mostly transparency with a minor content element. These pages are often used to animate in content markers (e.g. next/previous page). Instead of doing this, consider using a small object, and animating this into place. Alternatively, if you must use full screen animated layers, consider only using a small number of layers - less than five is a good number.
Also, if you're creating animated elements on top of long pages, keep the transparent layers only as large as the first page (i.e. one screen full). Using long transparent layers causes the iPad to alpha blend content as you scroll, resulting in both more memory usage and slower scrolling speed.
Flipbooks with Retina Images
Flipbooks with retina quality images are also know to cause problems on iPad 3. Consider downscaling the images or using fewer images.
IPS with Retina Images
IPS's can use considerable resources if the slides are high resolution images. Remember that even on a non-retina device the full-resolution image must be loaded before being down-scaled to fit the dimensions of the IPS region, and that up to three slide are cached for smooth scrolling performance.
Consider Restructuring Content
If you choose to author content that causes heavy memory usage, consider restructuring your content so that these pages are not located adjacent to one another. This will allow the iPad to avoid caching large pages in memory and improve the performance of your magazine.
Always Test on Device
Always test content on device, remember the iPad is not a desktop computer, it only has a limited system resources. If your content is reasonably similar, consider testing an indicative sample page on device before building all your content using that template. This can help flesh out problems early before you've committed to producing all your content.
If you have content causing problems, try previewing content sections individually to see which ones cause the problems.
This rest of this page gives you a technical overview of what makes a page slow to load and how the rendering of page content works on Oomph. Warning: the content can get quite heavy and technical, but it's worth knowing.
Page Loading & Caching
To improve the speed of loading pages, Oomph preemptively renders and caches pages adjacent to the page being viewed. "Cache" is a form of device memory. Caching is designed to speed up the device by "remembering" it's its contents for quick access - i.e. keeping certain parts of your content only at arms length so the user doesn't have to wait long.
For a normal page in the middle of your content, Oomph will cache:
- The current page being viewed.
- The page above the current page in the section (if you're in the middle of a section).
- The page below the current page in the section (if you're in the middle of a section).
- The page to the left of the current page (if you're not in the first section).
- The page to the right of the current page (if you're not in the last section).
You can see that this could cache up to 5 pages (and their constituent layers) in memory at any one time.
A similar system is used for in-page slideshows (i.e. IPS and VIPS). Where the slideshow is small the impact is minimal, but if they are approaching the full size of the screen, or if the slides are retina scaled images the memory requirement can be substantial. The visible slide plus the two adjacent slides are cached.
- The current visible slide.
- The slide to the left for IPS, or above for VIPS.
- The slide to the right for IPS, or above for VIPS.
The same applies to full-screen slideshows, but these are only loaded when the user taps to open the slideshow.
As part of the rendering process, content is rasterised from its original format (PDF/HTML, etc.) into an image, the image is then rendered to screen. Some of these rasterised images are then also cached in memory (as per the above). Keeping too many images of these layers in memory can cause problems such as the iPad feeling laggy, slow scrolling or even crashes. To understand why, let's look at how the iPad renders content to screen.
To render a page to screen, each of its layers is composited on top of one another (taking into account any alpha channel), then rasterised to screen. If pages contain animated layers with alpha channels, the final composite image cannot be cached, it must be composited live each time the animation runs.
A retina iPad has a resolution of 2048×1536 pixels which leads us to a rasterised layer using up 12 MB of memory. If you use transparent animated layers, each layer is also kept, so this is 12 MB per layer. Doing some quick maths, if you had 1 base layer & 9 transparent animated layers in a page (so 10 in total), that's 120 MB of memory needed for just one page.
To take this to the extreme, if you used this technique in adjacent pages, you could end up with up to 600 MB being used at any one time. This may sound like an extreme example, but we have seen live content that uses over 20 transparent animated layers.
It is also important to realise that image based content files (JPGs and PNGs) are decoded to their full native resolution before they can be drawn, regardless of the screen resolution. For example, a retina-sized JPG file at 2048×1536 will require 12MB of memory even when displayed on a non-retina device at 1024×768 resolution. Due to this we advise to avoid using retina images where possible. See tips and tricks for more information.
So even if you don't follow the math completely, the summary is that it's very easy to build content that can cause problems when running on device. And while Oomph can hide a lot of the complexity, at some point you run up against hardware limitations.