Optimize opening of Settings screens (#19940)
This commit rewrites utils.re-frame/delay-render to use hooks. The new implementation renders significantly better than what we have today, at least on Android. Why not hiccup instead of a function call to delay-render? The Settings screen is rendered slightly faster if I use delay-render as a function call instead of hiccup. My only guess is that this is just less work to be done by Reagent, since the wrapper function is not creating a wrapper component with its own lifecycle. The full analysis can be found here, but it's copied for future reference: -------------------------------------------------------------------------------- Based on my analysis of individual frames being rendered and having investigated 3 different scenarios: 1. Scenario 1: No delay whatsoever, i.e. not using `delay-render`. 2. Scenario 2: Using `delay-render` like in `develop`, that is, a form-2 component with a local Reagent atom. 3. Scenario 3: Using `delay-render` as in this PR, using hooks. All 3 scenarios open the Settings screen with all rendered views in the same amount of time. In terms of raw performance, they are completely identical. The absolute value doesn't matter, but in my recordings, on average, 10 frames of video after the first press on the user's profile image. So how can it be that on Android the new solution is visibly smoother? It's all about latency and our brains are very picky about it. Scenario 1 - Not using delay-render: the user notices a longer delay after pressing on the profile image because all components in the Settings screen are mounted in one go. This gives the impression to the user of being slower. In slower Android devices, we've seen a user even press twice because the Settings screen was taking longer to open. On newer Android devices this is not much of a problem. There's another problem in `Scenario 1`, on Android, with too many elements and/or too many heavy elements being mounted, the opening animation is sometimes completely cut off or very clunky (a similar problem can happen while opening the Activity Center). Scenario 2 - Use delay-render with a form-2 component: The Settings items are always rendered after the opening animation completes. Our brains perceive this as a slight delay because we can see the empty gray background for 1-3 frames. This is quite noticeable on my physical Android device, even with a prod build. Scenario 3 - Use delay-render as a hook: the optimal solution from the user's perspective, Settings items sometimes can be rendered before the animation completes. I say sometimes because other times the items are rendered only 1 frame before or right when the animation completes, which would be almost the same as Scenario 2. What the hooks solution gave us is a little bit of the Scenario 1 and Scenario 2 in one package, and because the Settings items can be sometimes rendered before the opening animation completes, our brains see that as being faster. In future performance investigations, we might want to focus on manipulating latency more aggressively to see where that leads us.
This commit is contained in:
parent
cb9a620f40
commit
037e71bc03
|
@ -199,6 +199,15 @@
|
|||
[handler deps]
|
||||
(react/useMemo handler (get-js-deps deps)))
|
||||
|
||||
(defn delay-render
|
||||
[content]
|
||||
(let [[render? set-render] (use-state false)]
|
||||
(use-mount
|
||||
(fn []
|
||||
(js/setTimeout #(set-render true) 0)))
|
||||
(when render?
|
||||
content)))
|
||||
|
||||
(def layout-animation (.-LayoutAnimation ^js react-native))
|
||||
(def configure-next (.-configureNext ^js layout-animation))
|
||||
|
||||
|
|
|
@ -21,12 +21,12 @@
|
|||
|
||||
(defn- settings-category-view
|
||||
[data]
|
||||
[rf/delay-render
|
||||
(rn/delay-render
|
||||
[quo/category
|
||||
{:list-type :settings
|
||||
:container-style {:padding-bottom 12}
|
||||
:blur? true
|
||||
:data (filter show-settings-item? data)}]])
|
||||
:data (filter show-settings-item? data)}]))
|
||||
|
||||
(defn scroll-handler
|
||||
[event scroll-y]
|
||||
|
@ -35,9 +35,9 @@
|
|||
|
||||
(defn- footer
|
||||
[{:keys [bottom]} logout-press]
|
||||
[rf/delay-render
|
||||
(rn/delay-render
|
||||
[rn/view {:style (style/footer-container bottom)}
|
||||
[quo/logout-button {:on-press logout-press}]]])
|
||||
[quo/logout-button {:on-press logout-press}]]))
|
||||
|
||||
(defn- get-item-layout
|
||||
[_ index]
|
||||
|
|
|
@ -4,7 +4,6 @@
|
|||
[re-frame.core :as re-frame]
|
||||
[re-frame.interceptor :as interceptor]
|
||||
[re-frame.interop :as rf.interop]
|
||||
[reagent.core :as reagent]
|
||||
[taoensso.timbre :as log]
|
||||
[utils.datetime :as datetime])
|
||||
(:refer-clojure :exclude [merge reduce]))
|
||||
|
@ -80,14 +79,6 @@
|
|||
(swap! handler-nesting-level dec)
|
||||
res))
|
||||
|
||||
(defn delay-render
|
||||
[_]
|
||||
(let [render? (reagent/atom false)]
|
||||
(js/setTimeout #(reset! render? true) 0)
|
||||
(fn [content]
|
||||
(when @render?
|
||||
content))))
|
||||
|
||||
(def sub (comp deref re-frame/subscribe))
|
||||
|
||||
(def dispatch re-frame/dispatch)
|
||||
|
|
Loading…
Reference in New Issue