0

I'd like to calculate FPS to detect performance issue of an application based on existing Android profiling tool .

I noted that on Systrace, it can record the length of performTraversals. As far as I know, performTraversals performs measure, layout and draw, which include most of jobs when updating a frame. So can performTraversals be representative enough to measure whether a frame will take 60 ms to update?

I also noted that Systrace record the time spending on SurfaceFlinger. I know SurfaceFlinger served for rendering purpose, but I don't know the exact beginning point and ending point of a frame. Should I also considering the time spent on SurfaceFlinger to the frame rate? (Though I do observe that SurfaceFlinger perform more frequently than performTraversals, which means SurfaceFlinger may not necessarily follow performTraversals. It will also be triggered in other scenarios.)

P.S. I'm aware of the sysdump gfxinfo, but it can only record 128 frames(~2 seconds), while what I want may last much longer.

Wei Yang
  • 895
  • 3
  • 15
  • 26

1 Answers1

1

Systrace is not useful for measuring FPS overall, but you can do that trivially with a frame counter and System.nanoTime(). If you're not hitting your target framerate, though, it can help you figure out why not.

The official docs provide some useful pointers, but there's a lot of information and the interactions can be complex. The key things to know are:

  • The device display panel generates a vsync signal. You can see that on the VSYNC line. Every time it transitions between 1 and 0 is a refresh.
  • The vsync wakes surfaceflinger, which gathers up the incoming buffers for the various windows and composites them (either itself using OpenGL ES, or through the Hardware Composer).
  • If your app was running faster than the panel refresh rate (usually 60fps), it will have blocked waiting for surfaceflinger (in, say, eglSwapBuffers()). Once surfaceflinger acquires the buffer, the app is free to continue and generate another frame.
  • Unless you're rendering offscreen, you can't go faster than surfaceflinger.

As of Android 4.3 (API 18) you can add your own events to the systrace output using the android.os.Trace class. Wrapping your draw method with trace markers can be extremely informative. You have to enable their tag with systrace to see them.

If you want to be running at 60fps, your rendering must finish in well under 16.7ms. If you see a single invocation of performTraversals taking longer than that, you're not going to hit maximum speed.

fadden
  • 51,356
  • 5
  • 116
  • 166
  • Hi! Fadden, thanks for your informative answer. My current situation is that I have no source code for most of the apps under testing. I guess that will make frame counter solution unfeasible. What I want may not be precisely the frame rate, but using the data on Systrace to detect potential performance problems with timestamp information. I understand I can infer janks through the running itme of performTraversals. It seems that the onMessageReceived method on SurfaceFlinger thread can also take up to more than 10 ms. Will that also affect the frame rate? – Wei Yang Jul 30 '13 at 23:32
  • I'm assuming you have "gfx" and "view" tags enabled. Ideally surfaceflinger takes very little time to run, and starts anew on every vsync (assuming there's activity -- vsync events are turned off if nothing is animating to improve battery life). If surfaceflinger is slow it's usually because it's waiting for GPU rendering to complete. For a typical app you can look at the View durations to see slow-rendering frames, then use hierarchyviewer to check for obvious problems. The information available is much better in the newly-released Android 4.3. – fadden Jul 31 '13 at 05:25