037e71bc03
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. |
||
|---|---|---|
| .clj-kondo | ||
| .dependabot | ||
| .github | ||
| .lsp | ||
| .vscode | ||
| android | ||
| ci | ||
| doc | ||
| fastlane | ||
| ios | ||
| logs | ||
| maestro | ||
| modules/react-native-status | ||
| nix | ||
| patches | ||
| resources | ||
| scripts | ||
| src | ||
| test | ||
| test-resources | ||
| translations | ||
| .buckconfig | ||
| .carve_ignore | ||
| .dockerignore | ||
| .env | ||
| .env.e2e | ||
| .env.jenkins | ||
| .env.nightly | ||
| .env.release | ||
| .envrc | ||
| .eslintrc.js | ||
| .flowconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .nycrc | ||
| .prettierignore | ||
| .prettierrc.js | ||
| .watchmanconfig | ||
| .zprintrc | ||
| LICENSE.md | ||
| Makefile | ||
| README.md | ||
| RELEASES.md | ||
| VERSION | ||
| app.json | ||
| babel.config.js | ||
| binding.gyp | ||
| default.nix | ||
| index.js | ||
| metro.config.js | ||
| package.json | ||
| react-native.config.js | ||
| shadow-cljs.edn | ||
| shell.nix | ||
| status-go-version.json | ||
| supervisord.conf | ||
| yarn.lock | ||
README.md
Status - a Mobile Ethereum Operating System
Join us in creating a browser, messenger, and gateway to a decentralized world. Status is a free (libre) open source mobile client targeting Android & iOS built entirely on Ethereum technologies. That's right, no middlemen and go-ethereum running directly on your device.
Why?
We believe in a medium of pure free trade, economies with fair, permission-less access and a world without intermediaries. We want to create policies that can exist between friends or scale globally, we want to communicate securely and be uninhibited by legacy systems.
We want to take responsibility for our data, and the way we conduct ourselves privately and promote this way of life to a mass audience.
We want deep insights into our own economies so we can make informed, data-driven decisions on how to make our lives better. The Ethereum blockchain, Smart Contracts, Swarm and Whisper provide us with a path forward.
If this interests you, help us make Status a reality - anyone can contribute and we need everyone at any skill level to participate.
How to Contribute?
Go straight to the docs and choose what interests you:
-
Developer Developers are the heart of software and to keep Status beating we need all the help we can get! If you're looking to code in ClojureScript or Golang then Status is the project for you! We use React Native and there is even some Java/Objective-C too! Want to learn more about it? Start by reading our Developer Introduction which guides you through the technology stack and start browsing beginner issues. Then you can read how to Build Status, which talks about managing project dependencies, coding guidelines and testing procedures. Check out our coding guidelines.
-
Community Management Metcalfe's law states that the value of a network is proportional to the square of the number of connected users of the system - without community Status is meaningless. We're looking to create a positive, fun environment to explore new ideas, experiment and grow the Status community. Building a community takes a lot of work but the people you'll meet and the long-lasting relationships you form will be well worth it, check out our Mission and Community Principles
-
Specification / Documentation John Dewey once said, "Education is not preparation for life; education is life itself ". Developers and Designers need guidance and it all starts from documentation and specifications. Our software is only as good as its documentation, check out our docs and see how you can improve what we have.
-
Blog Writing Content is King, keeping our blog up to date and informing the community of news helps keep everyone on the same page.
-
Testers It's bug-hunting season! Status is currently under active development and there is sure to be a bunch of learning, build status from scratch or if an android user checks out our nightly builds. You can shake your phone to submit bug reports, or start browsing our Github Issues. Every bug you find brings Status closer to stable, usable software for everyone to enjoy!
-
Security Status is a visual interface to make permanent changes on the Blockchain, it handles crypto-tokens that have real value and allows 3rd party code execution. Security is paramount to its success. You are given permission to break Status as hard as you can, as long as you share your findings with the community!
-
Evangelism Help us spread the word! Tell a friend right now, in fact, tell everyone - yell from a mountain if you have to, every person counts! If you've got a great story to tell or have some interesting way you've spread the word about Status let us know about it in our chat
Give me Binaries!
You can get our Beta builds for both Android and iOS on our website, through our nightly builds, or by building it yourself.
Core Contributors
Special thanks to @adrian-tiberius. Without the dedication of these outstanding individuals, Status would not exist.
Contact us
Feel free to email us at support@status.im.
License
Licensed under the Mozilla Public License v2.0