I have an app developed with Sencha Touch and phonegap. At one point, it downloads data from a server and, once it has received a successful response, it displays the next screen. I found, when bundling it up as an iOS app, that it would transition to that next screen, but not display anything, reporting low memory. So I simplified the layout of that next screen (the DOM structure was pretty complex) and it now works on the iOS simulators and on my iPhone.
However, in Android, I can see from the output of my console.log statements that it successfully retrieves the data and fires an event to display the next screen. It then sits around for ages before it displays that screen, even though my console.log statements show that the 'painted' event of that screen has been fired.
Eventually, the screen does show up, but all the controls on the screen are unresponsive to touch. Is it likely that I need to simplify the structure of that screen still further? As the iOS version received a low memory warning before I simplified the page structure, I suspect the Android version may have a similar problem, but I don't know how to monitor memory usage. In the Android version, shortly before the screen does eventually display I see the following in logcat:
UpdateFrameCache: pending style recalc, ignoring
And on the screen which is unresponsive, when I tap some (but not all) of the unresponsive controls, I see:
Got ACTION_DOWN but still waiting on stale event. Catching up.
Eventually, the app will just close itself, with:
Fatal signal 11 (SIGSEGV) at 0xbbbadbeef (code = 1)
Any help gratefully received.
If you perform intensive computations in the UI thread, it might explain why it takes so long.
Try using AsyncTask or a Service if you have some backgorund computations to do. Once they are done, update the interface in the UI thread.
Gordak
Related
My app is hanging when returning from one activity back to a ListView activity. I know the ListView is slow and RecyclerView is a better replacement, however I don't think this would be causing complete UI freezing for multiple seconds (I see ListView lag however this hang is 100% unresponsiveness). The hanging is almost always persistent until you close and re-open the app, and ANR is almost always triggered.
I have messed around with TraceView and see a lot of Object.wait() calls taking up CPU time, but I don't know how to interpret that. Where can I go from here?
Edit (more info):
There is a lot going on from SQLite, image loading, rest calls and so on going on in the app and I've been running Strict Mode and fixing issues but nothing shows up in Strict Mode logs when this type of hang happens (which is very reproduceable)
Screenshot of systrace during hang
In our javaScript game we are having a problem where "touchmove" events are slow and "janky" until an orientation change at which point they become smooth again.
The slowness returns when the game does a lot of work like loading a level.
Here is a video that show the slow touch move in action, and the orientation change which fixes the issue.
https://youtu.be/7rSqkJuOQjc
The following warning does appear in the log
Handling of 'touchmove' input event was delayed for 141 ms due to main thread being busy. Consider marking event handler as 'passive' to make the page more responive.
However, the slow events persist well after the game has stopped doing heavy lifting like loading a level and building sprites.
I cannot use passive handlers in any case becuase panning the map must preventDefault to stop the interface scrolling as well.
I assume the slowness is related to touch events as I have measured how often the touch handlers are called and they seem strange.
Will receive 5-10 events in a row in under ~20ms, then there will be one that is about 150-200ms, then another batch of fast events, and another slow one.
After the orientation change, all events are received in under 20ms
I have also measured my responses from requestAnimationFrame and they seem to be a fairly solid 16.8ms
For those intrested you can see the problem yourself at https://blight.ironhelmet.com
The problems occur in Chrome and Cordova, both native and using Crosswalk.
The problems do not occur on Safari on iOS or any tested Desktop browser.
I would like to know if anybody else had this problem and how I might go about fixing it.
Is possible to force an "orientation change" or whatever happens during an orientation change, using javaScript?
The hardware renderer was not kicking in, and the slow software rendering was slowing event processing. (drawing pixels from one canvas to another)
After an orientation change, it seems that the garbage collector cleaned up unused canvases which enabled the hardware renderer to kick in.
I am working with Google's Leanback library for Android TV and I am trying to figure out how to best listen for the buttons on the remote control (especially the ones that are not captured by the MediaSession).
For that reason I have a break point in BaseGridView.dispatchTouchEvent() and when I press one of the remote buttons the debugger does indeed jump to that point and shows me the usual debug information.
However, after a few (2-5) seconds the debug info disappears and is replaced by the message "Frame is not available".
In other places the debugger is working fine, so I was wondering whether the delay caused by the debugger is counted as ANR and the app is therefore force closed?
In any case, is there any way to get around this?
This message appears because u set too many breakpoints, and threads are waiting data from other threads, to settle this, you could cancel some breakpoints and waiting for the data to be ready...
the message "frames not available" means that no more frames are available for debugging.
The android studio help states clearly the purpose of the frame window and the frames within:
The Frames pane enables you to gain access to the list of threads of your application , export to a text file and customize thread presentation. For each thread, you can view the stack frame, examine frames, navigate between frames, and automatically jump to a frame's source code in the editor. You can select a thread via a the thread selector drop-down list on top of the pane. The status and type of a thread is indicated by a special icon and a textual note next to the thread's name.
So now that you have no frames available means all frames are closed for debugging. Might be due to app being force closed or misbehaving at that line in any way. Try debugging the statement after which this happens to get rid of this behaviour.
Hope it helps
When you get the message "frames not available" it means that no more frames are available for debugging. The frames are part of Android Studio's debugging which gives you access to the list of threads running in your application. It is the long list of processes you see in the debugging window. So what is happening is that Android Studio loses knowledge of the threads it had before you set the breakpoint when you are stepping out. This might be happening in your case because by default when you set a breakpoint, it stops execution of all threads. When you step out, the threads that follow rely on the threads before to work which is what closes the app. Since you are setting your breakpoint at getCurrentDetails, my best assumption is that it did not get the response from OKHttp in time since it is happening in a background thread. You can try two things to get it to work. First, try and right click on the breakpoint and change the breakpoint from pausing all threads to just that thread. This should allow OKHttp to get the response in time before being cut off. Or, shift your breakpoint further down and see if it works.
Having the same issue, restarting AS works for me.
File --> Invalidate Caches/Restart fixed the problem that I had.
I'm trying to use the output of systrace to detect janky scrolling during automated tests: I want to notice it early, without having to sit there watching.
I spent some time trying to fathom the trace, and found this ebook very helpful: https://www.safaribooksonline.com/library/view/high-performance-android/9781491913994/ch04.html
The most promising hypothesis was checking whether VSYNC-sf ever stopped ticking on phones displaying VSYNC-sf.
On other machines, SurfaceFlinger seems to be started by either HW_SYNC_0 or VSYNC (sometimes one or both of those VSYNCs stop) but SurfaceFlinger also seems to be involved with VsyncOn, which sometimes appears to keep track of whether there are activity buffers outstanding, and sometimes whether there are input events that need delivering. Confusingly, sometimes input events are delivered during half-second pauses when there's no surface flinger activity, no application drawing, and when even the VSYNC and HW_VSYNC signals decide to pause.
Does anyone know what's going on there?
Should I simply expect to see Surface Flinger always busy - not alternately busy and idle with each tick - and always aligned with one or other of the VSYNCs?
I also sometimes see SurfaceFlinger taking longer than a tick to complete its processing - is that the application's fault for having a very complicated display, or is it just something that happens because some queue isn't empty enough?
I'd prefer to miss a possible jank than claim to have found one which isn't there.
Thanks!
Testing Display Performance Lists how to use the new framestats command from dumpsys to get this type of information. It will provide information on what frames you've missed, and how many of them you've missed.
It's also worth noting that SurfaceFlinger isn't always busy. It's only active when part of the screen needs to be updated. If nothing on the screen needs updating, then no new rendering occurs, and such, SurfaceFlinger should be idle.
You can get a bigger-picture view of the Android rendering pipeline with the Rendering Performance 101 video from Android Performance Patterns.
I'm loading a bunch of images using AsyncTasks, creating bitmaps. Lots of recycling views going on etc. Without going into the gory details, I would like to know if there is any way I can get some realtime stats on threads that might be helpful. In particular what I am noticing is that the doInBackground runs really fast once it gets kicked off, but it seems they it takes a while for these tasks to run. So I was wondering how I can know how many threads are running at a given time. I have seen the dreaded 128 limit on thread exception with 10 in queue, but thats once there is an overload, I would like to be able to watch this as the program is running. Hopefully this visibility will tell me something. BTW, I did try bumping of the thread priority within the doInBackground() but again its really not that it is not fast once it runs, its that it does not get scheduled to run fast. I'm on Android Studio, what kind of tools are available?
When debugging and stopped on a breakpoint you can scroll through all the launched threads and their current execution points (the spinner on the left of the debug tab).
Knowing where your threads are started you can launch method profiling on this method and see how your threads are performing (a "timer" button on the left of the android tab).