When detecting that my application was closed by the OS on low-mid range Android devices (ex: Samsung S4) after browsing the different screens of the App ([V3] Memory leak), I started a refactoring of it (Router components for each Page, jquery removal and derived libraries, event handler optimization, using Template7, correct configuration of stackPages and keepEnable in the router, update of Cordova and FWK7 to the latest version). This produced a remarkable improvement in the performance of my App (in modern devices the performance is excellent and crashes do not occur) but … in devices with lower capability the operating system continued to close my application after browsing 10 or 12 screens approximately.
What other thing can i do? I thought. Will I have to implement Vue and Webpack? The proofs of concept didn’t give better results than with Fwk7 Core. I was wondering where I’m failing.
It turns out that in the beforeAnimation of each page consumed a web services to load/update the content by viewing a spinner using the Dialog Loading control ( app.dialog.progress(); ) until the AJAX call was made.
It occurred to me to avoid showing the Dialog Loading and see what happened … Eureka !! the number of screens that I can navigate after this simple change is at least double.
When only showing/hiding the Dialog every 10 seconds without any other action, there are big jumps in the memory utilization in Android Profiler while the memory snapshots in Chrome Inspect remain constant. Coming to the conclusion that the component does not present memory leaks but that the shadows and animations used in this component consume resources of the device causing crashes of the App.
Based on my experience, if your App presents crashes, especially for low-mid-range devices with outdated webviews, I recommend you pay attention in the Dialogs and be very careful with the shadows/animations.
I hope these tips help you!