I'm Bob Bringhurst, the lead writer for the Digital Publishing Suite.

Memory Handling in DPS

If DPS articles include memory-intensive overlays, you might run into trouble when viewing them on mobile device with obvious memory limitations. Sometimes the app becomes sluggish, sometimes it crashes, and sometimes it takes a PDF article too long to load.

How do you avoid these memory problems? If you go against guidance and do something like create a pan and zoom image with a 5000×5000-pixel PNG image or scale down a huge video, you’ll likely crash your app. However, in some cases, individual overlays that by themselves wouldn’t cause memory problems can be a problem when combined with other memory-intensive overlays on the same page or even on adjacent pages.

Whenever you turn to a page in an article, the DPS viewer loads each page above and below that article into memory, and it loads the current page of the next or previous article. This pre-loading improves the performance of articles and helps prevent crashing when users swipe quickly.

In this example, viewing page 2 of the third article loads the pages above and below it as well as the first page of the articles before and after.

In the next example, suppose we swipe to the first page of the next article. New pages and articles are preloaded, and other pages drop out of memory.

Smooth Scrolling articles are divided into tiles to improve performance. When you swipe through a smooth scrolling article, different tiles of the article are loaded into and removed from memory, as shown in the next example.

Now that both devices and DPS folios handle memory better than they used to, knowing how articles are preloaded usually doesn’t matter. But when you run into memory issues, this knowledge can help you. If you create two or more memory-intensive articles right next to each other, jumping to an article causes one page to load and other pages to preload. In extreme cases, that might be enough to slow down performance or even crash the app.

Guidance

If you run into a memory problem, consider breaking up your memory-intensive pages with low-memory or static articles, such as basic ads. What are examples of memory intensive pages?

Large pan & zoom images

Scrollable frames—especially scrollable frames with nested overlays

Pages with multiple overlays loaded simultaneously

Transparency effects or large images in either overlays or PDF articles

In some cases, any individual article or page might work just fine, but when combined with adjacent memory hogs, watch out.

Usually, overlays with Edge animation have a small Auto Play delay, so those pages are memory-intensive only when loaded, not preloaded. How much memory they require depends of course on the HTML code.