[META] Upgrading JSC
See original GitHub issueThe purpose of this issue is to create a “single point of truth” regarding the efforts related to upgrading the JSC used by the react-native
repo/project, in order to coordinate and recap all the efforts connected to this subject.
Foreword
The JavaScriptCore (JSC), basically, allows Android developers to use JavaScript natively in their apps - you can read here for more details about how react native uses engines.
Currently, react-native
bundles in the Android app android-jsc, which is outdated and relies on old native tooling (ex. NDK v10).
Why
Upgrading the JSC would improve greatly performances for react-native
apps running on Android, and allow support for x64 builds on Android apps.
Which links back this to the main “Roadmap of future Android(s)” issue #19297 - quote:
In anticipation of future Android devices that support 64-bit code only, the Play Console will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions. This can be within a single APK or as one of the multiple APKs published.
Related
PRs
Currently there are two approaches possible, keep relying on the android-jsc bundled but changing some other configs:
Which seems to not be the way to go, given that internally FB doesn’t use it.
The alternative is to move to the JSC fork maintained by some important players in the core & community:
- Build 64bit binaries for Android #19536
Issues
-
React Native for Android is incompatible with 3rd-party 64-bit libraries #2814
-
[…Array(5).keys()] not working in Android #18426
-
React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) #19321
-
potentially (as @kmagiera wrote in core), this unfortunately would bring some significant footprint penalty: JSC built with intl enabled takes roughly 5M more than without it. This needs to be multiplied by the number of CPU archs included (e.g. x86, armv7, arm64, x86_64), which leads to an “Hello World” base app to ~40MBs - unless split apk is enabled. But this it potentially “automatically” fixed by Google via their new Android App Bundle feature.
Again, this issue is for discussing and keeping everyone updated with decisions around this subject (based on discussions happened with the core team and open issues in the repo). Please avoid going OT.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:140
- Comments:55 (33 by maintainers)
Long term, the plan should be to start using default V8 bundled within Android when using React Native. When RN Android was launched a year back, it supported Android versions down to API19 because of which it made sense to bundle a custom JSC binary into each and every RN app that is shipped to Android today. As you can imagine, this is not ideal.
With compilers like Babel and the
babel-preset-env
it should be possible to selectively compile JS given the feature set of the target JSC vs. V8. If we are anyways going to put in effort towards 64-bit support, I would believe it worthwhile to focus directly on V8 support rather than simply upgrading bundled JSC on Android.@hey99xx I can’t answer that just yet, but hopefully soon we can share more information. Let’s keep this issue scoped to what needs to be done to allow open source to use an arbitrary JSC.