How do I reduce memory usage for published HTML5 courses?

Report · Nov 17, 2015

My team has created a bunch of courses loaded onto Android devices via APKs and played locally on the devices (not through a browser). We used Captivate 8 to create the courses, which range from 65-110 slides (almost all of them are under 100 slides). We didn't use any audio or video other than the clicking sound effect that is built into the program. The projects are not very complex, although some of them use a motion path on a few slides.

The published APKs range from 1.5 - 8 MB. When running on the devices, they are consuming a ridiculous amount of memory. The one 8 MB course was logged using 185 MB! This appears to be causing other apps to crash, which is unacceptable. What on earth could be causing this kind of memory usage, and what can be done to reduce it?

I should note that we have also been deleting unused items from the library before publishing.

Report · Nov 17, 2015

Deleting items in the Library has no effect whatsoever on the size of the published file.

Keep number of slides, number of frames as low as possible. With shared actions you can often reduce number of slides. I managed once to reduce the file size of a project to 50% of the original size by using objects timed for several slides, and shared actions. For graphics: create them in the wanted resolution, do not resize them in Captivate. I don't think Effects add that much to file size. You cannot use SVG yet in CP8 nor states.

As for memory use, an engineer should be able to explain, I'm just a user.

Report · Nov 17, 2015

Thank you for the quick response, Lilybiri. I agree that deleting unused items in the library shouldn't impact the size of the published file, but it definitely does. For many of our APKs that had been edited a lot, it made a huge difference. It's easy to test:

Anyway, our issue isn't with file size so much as it is with the RAM consumed by the courses as they are running on the device. When you open a course and track its memory consumption repeatedly using the "dumpsys meminfo" command in adb shell, you can watch the memory consumption get greater and greater even if the course is just sitting there doing nothing. Eventually the Android device runs out of memory, so it begins "cleaning up" other apps that are running in the background. When our training apps are interfering with apps required for people to do their jobs, that is a big, big problem.

When I googled this issue, it looks like Captivate courses have been experiencing this memory leak since at least Captivate 2. Our experience tells me that it's obviously not limited to Flash, since our courses are HTML5.

Report · Nov 17, 2015

I have heard that any developer working on apps for mobile devices spends most of their project life trying to work out how to conserve memory. They lose a lot of sleep over it apparently.

One of the issues I read about on one of the developer forums was that all JPGs were rendered out to BMPs at runtime and that this was consuming huge amounts of memory. It's one of the reasons why photo sharing or viewing apps tend to bog down.

One of the reasons why the "flat" look is so popular with graphic and web designers right now is that using drop shadows or blurs or reflections can take inordinate amounts of memory to render on mobile devices. So, since nobody wants their design to be the reason an app crashed, they avoid these like the plague.

Captivate's content is multi-media and usually contains lots of images. If it is true that images are uncompressed at run-time, then this could be hurting your project.

However, I'm also leaning towards the concluding that modules for mobile learning are going to need to be MUCH SMALLER than desktops in order to avoid these kinds of issues.

Report · Nov 17, 2015

Dang. I really like drop shadows. I don't care what's modern--I like what I like. Guess I'll have to dump 'em.

Report · Aug 15, 2016

This turned out to be a bug in the software. I communicated with Adobe developers to get it fixed.

Report · Aug 16, 2016

Andrew,

I believe you will have seen these fixes and more applied in the recent 9.0.2 update. I'm curious about how you are finding the performance? I've heard from several people seeing great gains on iOS - wondering if you're getting similar results on Android.

Allen

Report · Aug 16, 2016

Thanks for your help with this, Allen. I've been looking forward to testing it, but I haven't had time to update the modules for that project yet. It's on my docket - I'll let you know how it goes!