mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Joshua Gross
2cd89d040b
Summary: I've had my eyes on this optimization for a while: during TTRC especially, but really during any heavy render path, Fabric will create hundreds to thousands of MountItem class instances in order to construct a BatchMountItem. This results in: hundreds/thousands of round-trip JNI calls, hundreds/thousands of Object allocations, etc. This will also result in increased memory and GC pressure. Theoretically, by reducing the number of JNI calls and reducing allocations, we may be able to get some small wins in memory and CPU usage during very hot paths. I am motivated to do this, in part, to indirectly measure the cost of JNI calls as well as allocating many objects vs an int buffer. I am unaware of such a measurement that we can use to make architectural decisions for React Native Android overall. The other reason this could be a positive change: if it's successful and we can delete the old path, we'll be able to delete a bunch of Java classes entirely which is great for APK size wins. Changelog: [Internal] Reviewed By: shergin Differential Revision: D24631230 fbshipit-source-id: 86a46ffcaef4ecbec2e608ed226aed0b5c4b832e
Building React Native for Android
See the docs on the website.
Running tests
When you submit a pull request CircleCI will automatically run all tests. To run tests locally, see Testing.