Frequent “LL stopped working” since I moved from Nexus 4 to OnePlus One due to OutOfMemory exceptions.
Generally LL is running stable, memory usage about 160MB. But once (you know my current WIP template) some animations through script are triggered, memory usage jumps fast up to 200MB, which seems to be a critical level (despite 3GB RAM) at which LL starts to struggle. Suddenly LL stops responding. Sometimes after leaving it alone for a few minutes LL settles down and is working again (though it seems LL was somehow restarted). But mostly after a 1 or 2 minutes I get the “stopped working” message.
I know, Pierre Hébert , you explained the higher memory usage resulting from that higher resolution. But still I don’t understand why it crashes It’s driving me crazy. All I do is moving some (4 to 5) panels containing a widget from point A to point B. Why is this causing memory usage to go up that fast?
How I animate:
I determine a list/array of items (by getById) to be moved. Animation is done through a function which calls itself about 16 times (animation steps) through setTimeout. For each Item setPosition is called. That’s it. I compared that way to how others do animations, seems similar.
I’ll send you a logcat, here are on of the (to me) mysterious allocation faults. Free bytes seem enough for allocation. Is it due to fragmented memory?
E/art ( 5132): Throwing OutOfMemoryError “Failed to allocate a 42252 byte allocation with 1651160 free bytes”
E/art ( 5132): Throwing OutOfMemoryError “Failed to allocate a 524 byte allocation with 1612752 free bytes; failed due to fragmentation (largest possible contiguous allocation 65104 bytes)”
E/art ( 5132): Throwing OutOfMemoryError “Failed to allocate a 64 byte allocation with 1612752 free bytes; failed due to fragmentation (largest possible contiguous allocation 65104 bytes)” (recursive case)
W/System.err( 5132): java.lang.OutOfMemoryError: Failed to allocate a 1200828 byte allocation with 2277304 free bytes
W/System.err( 5132): at android.graphics.Bitmap.nativeCreateFromParcel(Native Method)
W/System.err( 5132): at android.graphics.Bitmap.access$000(Bitmap.java:29)
W/System.err( 5132): at android.graphics.Bitmap$1.createFromParcel(Bitmap.java:1459)
W/System.err( 5132): at android.graphics.Bitmap$1.createFromParcel(Bitmap.java:1451)
W/System.err( 5132): at android.widget.RemoteViews$BitmapCache.
W/System.err( 5132): at android.widget.RemoteViews.
W/System.err( 5132): at android.widget.RemoteViews.
W/System.err( 5132): at android.widget.RemoteViews$2.createFromParcel(RemoteViews.java:2536)
W/System.err( 5132): at android.widget.RemoteViews$2.createFromParcel(RemoteViews.java:2534)
W/System.err( 5132): at com.android.internal.appwidget.IAppWidgetService$Stub$Proxy.getAppWidgetViews(IAppWidgetService.java:561)
W/System.err( 5132): at android.appwidget.AppWidgetHost.createView(AppWidgetHost.java:347)
W/System.err( 5132): at net.pierrox.lightning_launcher.b.bc.a(Unknown Source)
W/System.err( 5132): at net.pierrox.lightning_launcher.views.ItemLayout.u(Unknown Source)
W/System.err( 5132): at net.pierrox.lightning_launcher.views.ItemLayout.a(Unknown Source)
W/System.err( 5132): at net.pierrox.lightning_launcher.b.n.a(Unknown Source)
W/System.err( 5132): at net.pierrox.lightning_launcher.views.ItemLayout.c(Unknown Source)
W/System.err( 5132): at net.pierrox.lightning_launcher.b.ab.j(Unknown Source)
W/System.err( 5132): at net.pierrox.lightning_launcher.c.a.o.commit(Unknown Source)
]]>
D5 Creation
< ![CDATA[
[Off topic] that phone has 3gb of ram?!?
]]>
< ![CDATA[
Chris Chastain Last time I checked it had 😉 From specs: 3 GB LP-DDR3, 1866MHz. That thing is a powerful beast with Quad 2.5GHz and big display. And still battery lasts for two days of normal use where my Nexus 4 died after less than one.
]]>
< ![CDATA[
Wow. I should look into those I guess. Thanks, Lutz
]]>
< ![CDATA[
Chris Chastain Just let me know if you want an invite once I’ll get them.
]]>
< ![CDATA[
hell my tablet doesn’t even have 1gb ram (even though it’s actually advertised as 1gb) but then my device is over than your mother. that’s saying something and that something is this tablet is a piece of (?.+) and check the regex box.
]]>
< ![CDATA[
The fragmentation issue is something specific to ART, I never saw this with Dalvik. But anyway this is probably a sign of bad behavior somewhere.
In the log, it appears that the error comes from trying to allocate a 1M image for a widget, and this widget view is recreated because something in the container has changed and triggered a reload. My guess is that this reload event is triggered too many times. Changing the position only shouldn’t trigger such an heavy operation, that is suspicious, maybe a bug with panels.
Regarding memory figures, do you know what 160M and 200M are ? Is it virtual memory, or RSS, or maybe PSS ? It doesn’t seem to be the heap size, which is usually limited to a far lower bound. I think the important figure is the delta: the increase in memory is 40M, which is too much. If my assumption about the widget being recreated on each animation step is correct, then this could explain this jump. Two cycles of 16 times 1M+ will rapidly consume these 40M. I expect to see some garbage collection in the meantime, which would allow the animation to be run a few times more, but doe to this fragmentation phenomenon the runtime could finally fail to allocate the bitmap. I am not experienced with art however, so I may be wrong.
Could you share the script and the widget in a test template so that I can check whether the container is reloaded too many times ?
]]>
< ![CDATA[
Pierre Hébert 160MB/200MB is shown in “System Panel” app as memory usage. But I also saw “199MB needs clipping to 192MB” or similar in logcat.
I will check my functions wether there are other changes to the panel (item as well as container) which might cause widgets redraw.
I switched to ART since with Dalvik I had even more stability and performance issues. Apps running with ART generally use far less memory. Had ART active on Nexus 4 for months, so I activated on OnePlus, too.
Test template… I will try, but it won’t be this evening earliest. But it’s basically the same I sent you the link to a while ago as Preview 😉 Not much has changed since then, especially within the scripts.
]]>
< ![CDATA[
Pierre Hébert Thanks for the hint, it was my fault as it seems.
I not only set position, but also size:
iPnl.setPosition(pnlX,pnlY);
iPnl.setSize(pnlW,pnlH);
However, though the width and height did not change, just calling setSize caused redrawing. Checking the size before calling setSize fixed the issue. Memory usage does not rise anymore, and without caused redraw it also feels faster/smoother now.
iPnl.setPosition(pnlX,pnlY);
if (Math.round(iPnl.getWidth())!=pnlW ||
Math.round(iPnl.getHeight())!=pnlH) {
iPnl.setSize(pnlW,pnlH);
}
Another lesson learned…
]]>
< ![CDATA[
Pierre Hébert One more observation: detaching a panel (“i.onGrid” to false) from grid also causes redrawing. When attaching it’s understandable, the location and size probably changes. But when detaching it doesn’t. Or it shouldn’t.
]]>
< ![CDATA[
You mean reloading ? Even changing the size shouldn’t trigger a reload, at least in most cases.
I will have a look at this.
]]>
< ![CDATA[
Pierre Hébert yes, reload seems the correct word. Reload of the widget inside a panel. But every detaching a panel item with just a bunch of shortcuts in it seems to trigger a bunch of actions, sometimes LL does not react anymore for minutes.
]]>