0

My Sencha Touch app (demo is here: http://www.bodbot.com/MobileApp/senchademo/index.html) has been crashing on a relatively regular basis on Android and Windows Phone. I have yet to figure out the root cause of the crash despite a fair amount of investigation, so any help would be awesome. Here's what I have so far:

  1. On Android, when the app crashes, I get a signal 11 sigsegv error. Due to the fact that I am working pretty much exclusively in javascript, my assumption is that the likely cause of this segmentation fault would be some sort of a memory leak, since I'm not writing any code that's pointing at anything in memory.

  2. When I use Chrome's timeline memory analysis and use the app very heavily, the memory usage pattern does seem to clearly indicate a memory leak, especially when compared to similar usage on one of Sencha Touch's demo apps. (screenshots below)

My problem is that I can't track down the (assumed) memory leak. I'm doing everything that I've found about optimizing sencha for memory:

  • I'm using listener delegates pretty much exclusively
  • I make sure that most components that aren't currently being viewed are destroyed
  • I don't go too nuts on the global variables within javascript

It does look like Chrome's "Record Heap Allocations" might be able to reveal something, but given the sheer volume of pieces that it's tracking, I'm having real trouble making any sense of it.

Am I missing a method for optimizing memory in Sencha Touch? Is there a more effective way than Chrome's Record Heap Allocations for tracking down Sencha Touch app memory leaks?

Screenshots:

Memory Usage for my Sencha Touch

Memory Usage for Sencha Touch demo app

Sergio Prado
  • 1,197
  • 2
  • 16
  • 33
  • Usually it means that you don't destroy objects that not in the current view. – Baidaly Feb 08 '15 at 23:14
  • Unfortunately I've been exceptionally diligent about destroying all objects that aren't in the current view, I'm not sure it's that issue. – Sergio Prado Feb 09 '15 at 03:27

0 Answers0