Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix broken images on the Profiling page #1698

Merged
merged 1 commit into from
Mar 5, 2020
Merged

fix broken images on the Profiling page #1698

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions docs/profiling.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,13 +39,13 @@ Once the trace starts collecting, perform the animation or interaction you care

After opening the trace in your browser (preferably Chrome), you should see something like this:

![Example](/react-native/docs/assets/SystraceExample.png)
![Example](/docs/assets/SystraceExample.png)

> **HINT**: Use the WASD keys to strafe and zoom

If your trace .html file isn't opening correctly, check your browser console for the following:

![ObjectObserveError](/react-native/docs/assets/ObjectObserveError.png)
![ObjectObserveError](/docs/assets/ObjectObserveError.png)

Since `Object.observe` was deprecated in recent browsers, you may have to open the file from the Google Chrome Tracing tool. You can do so by:

Expand All @@ -57,7 +57,7 @@ Since `Object.observe` was deprecated in recent browsers, you may have to open t
>
> Check this checkbox at the top right of the screen to highlight the 16ms frame boundaries:
>
> ![Enable VSync Highlighting](/react-native/docs/assets/SystraceHighlightVSync.png)
> ![Enable VSync Highlighting](/docs/assets/SystraceHighlightVSync.png)
>
> You should see zebra stripes as in the screenshot above. If you don't, try profiling on a different device: Samsung has been known to have issues displaying vsyncs while the Nexus series is generally pretty reliable.

Expand All @@ -69,37 +69,37 @@ On the left side, you'll see a set of threads which correspond to the timeline r

- **UI Thread.** This is where standard android measure/layout/draw happens. The thread name on the right will be your package name (in my case book.adsmanager) or UI Thread. The events that you see on this thread should look something like this and have to do with `Choreographer`, `traversals`, and `DispatchUI`:

![UI Thread Example](/react-native/docs/assets/SystraceUIThreadExample.png)
![UI Thread Example](/docs/assets/SystraceUIThreadExample.png)

- **JS Thread.** This is where JavaScript is executed. The thread name will be either `mqt_js` or `<...>` depending on how cooperative the kernel on your device is being. To identify it if it doesn't have a name, look for things like `JSCall`, `Bridge.executeJSCall`, etc:

![JS Thread Example](/react-native/docs/assets/SystraceJSThreadExample.png)
![JS Thread Example](/docs/assets/SystraceJSThreadExample.png)

- **Native Modules Thread.** This is where native module calls (e.g. the `UIManager`) are executed. The thread name will be either `mqt_native_modules` or `<...>`. To identify it in the latter case, look for things like `NativeCall`, `callJavaModuleMethod`, and `onBatchComplete`:

![Native Modules Thread Example](/react-native/docs/assets/SystraceNativeModulesThreadExample.png)
![Native Modules Thread Example](/docs/assets/SystraceNativeModulesThreadExample.png)

- **Bonus: Render Thread.** If you're using Android L (5.0) and up, you will also have a render thread in your application. This thread generates the actual OpenGL commands used to draw your UI. The thread name will be either `RenderThread` or `<...>`. To identify it in the latter case, look for things like `DrawFrame` and `queueBuffer`:

![Render Thread Example](/react-native/docs/assets/SystraceRenderThreadExample.png)
![Render Thread Example](/docs/assets/SystraceRenderThreadExample.png)

## Identifying a culprit

A smooth animation should look something like the following:

![Smooth Animation](/react-native/docs/assets/SystraceWellBehaved.png)
![Smooth Animation](/docs/assets/SystraceWellBehaved.png)

Each change in color is a frame -- remember that in order to display a frame, all our UI work needs to be done by the end of that 16ms period. Notice that no thread is working close to the frame boundary. An application rendering like this is rendering at 60 FPS.

If you noticed chop, however, you might see something like this:

![Choppy Animation from JS](/react-native/docs/assets/SystraceBadJS.png)
![Choppy Animation from JS](/docs/assets/SystraceBadJS.png)

Notice that the JS thread is executing almost all the time, and across frame boundaries! This app is not rendering at 60 FPS. In this case, **the problem lies in JS**.

You might also see something like this:

![Choppy Animation from UI](/react-native/docs/assets/SystraceBadUI.png)
![Choppy Animation from UI](/docs/assets/SystraceBadUI.png)

In this case, the UI and render threads are the ones that have work crossing frame boundaries. The UI that we're trying to render on each frame is requiring too much work to be done. In this case, **the problem lies in the native views being rendered**.

Expand All @@ -109,7 +109,7 @@ At this point, you'll have some very helpful information to inform your next ste

If you identified a JS problem, look for clues in the specific JS that you're executing. In the scenario above, we see `RCTEventEmitter` being called multiple times per frame. Here's a zoom-in of the JS thread from the trace above:

![Too much JS](/react-native/docs/assets/SystraceBadJS2.png)
![Too much JS](/docs/assets/SystraceBadJS2.png)

This doesn't seem right. Why is it being called so often? Are they actually different events? The answers to these questions will probably depend on your product code. And many times, you'll want to look into [shouldComponentUpdate](https://reactjs.org/docs/react-component.html#shouldcomponentupdate).

Expand All @@ -124,7 +124,7 @@ If you identified a native UI problem, there are usually two scenarios:

In the first scenario, you'll see a trace that has the UI thread and/or Render Thread looking like this:

![Overloaded GPU](/react-native/docs/assets/SystraceBadUI.png)
![Overloaded GPU](/docs/assets/SystraceBadUI.png)

Notice the long amount of time spent in `DrawFrame` that crosses frame boundaries. This is time spent waiting for the GPU to drain its command buffer from the previous frame.

Expand All @@ -139,7 +139,7 @@ If these don't help and you want to dig deeper into what the GPU is actually doi

In the second scenario, you'll see something more like this:

![Creating Views](/react-native/docs/assets/SystraceBadCreateUI.png)
![Creating Views](/docs/assets/SystraceBadCreateUI.png)

Notice that first the JS thread thinks for a bit, then you see some work done on the native modules thread, followed by an expensive traversal on the UI thread.

Expand Down