How Do I Avoid JSON.parse() Parsing Errors in Quick Apps - Huawei Developers

Symptom​The data returned by the fetch request in the code is a JSON character string by default and the logic of parsing JSON objects is used.
Once the server permission verification fails, an HTML page with error code 503 may be returned, meaning the JSON parsing logic is not suitable.
Solution​Solution 1: Add try-catch to each place where JSON.parse() is executed to capture and handle errors.
Solution 2: Process JSON.parse() in the app.ux file in advance and add try-catch to the code. Record event tracing data or return the default normal data when an exception occurs.
Solution 2 is recommended and the sample code is as follows:
Code:
export function parseProxy () {
const rawParse = JSON.parse
JSON.parse = function (str, defaults) {
try {
return rawParse(str)
}
catch (err) {
console.error(`JSON parsing failure:${str}, ${err.stack}`)
return defaults
}
}
}

after adding try-catch does it parse JSON data or does it just handles the crash part?

Related

[Q] NullPointerException when trying to access MainActivity from different class

Hi!
I am trying to develop an android app with a google map v2, location service and some control buttons.
But I don't want to put all these things inside one MainActivity class. So I thought I could split all the code into some more classes. The MainActivity shall controll all the GUI things and react on map or location events...
Now I have the following problem. Inside my onCreate I instanziate the additional classes:
Code:
// Preferences as singleton
pref = Prefs.getInstance(this.getApplicationContext());
pref.loadSettings();
// Set up the location
loc = new Locations(pref);
loc.setCallback(this);
map = new MyMap(pref);
It seems to work fine. But inside the MyMap class every time I start the app a null pointer exception is thrown. When I am calling MyMap() the following code will be executed:
Code:
[...]
private Prefs pref;
private GoogleMap mMap;
[...]
public MyMap(Prefs prefs) {
pref = (Prefs) prefs;
if (mMap == null) {
FragmentManager fmanager = getSupportFragmentManager();
mMap = ((SupportMapFragment) fmanager.findFragmentById(R.id.map)).getMap();
[...]
}
The line with the findFragmentById is the one that causes the exception.
If I write
Code:
SupportMapFragment f = ((SupportMapFragment) fmanager.findFragmentById(R.id.map));
f is allways null. But how can I access the fragments and view elements defined within my MainActivity?
It works if I put the code inside my MainAcitivity.
Every class extends "android.support.v4.app.FragmentActivity"
I tried to save the application context within my Prefs() class, so that I can access it from everywhere.
But I don't know how to use it inside my additional classes.
How to share the "R" across all my classes?
Can someone help me please?
Thank you very much!!
Thorsten
Are you having trouble adding a Map to a Fragment? If so, then you may take a look at this tutorial. I haven't tried it myself since I couldn't install Google Play Services on my development device. If it helps, do write back, as I am definitely going to try it myself soon.

Build can’t find dependency injection from Foursquare library in Graddle

Hello guys: I’m using the next scenario for Android native applications development:
Android Studio 3.6.2
Graddle plugin 3.6.2
Graddle version 5.6.4
Kotlin version 1.3.61
When I make this dependency injection in my build.graddle
Implementation 'com.foursquare:foursquare-android-oauth:1.1.0'
The next class: android.net.ConnectivityManager
can’t be found in the build process. Or at least it hasn't the expected properties.
I have implemented the next method to detect internet connection:
package com.example.ejoauth.networkconnection
import android.content.Context
import android.net.ConnectivityManager
import android.net.NetworkCapabilities
class NetworkConnectionStatus {
companion object {
// This code depends on the target SDK version
fun isInternetAvailable(context: Context): Boolean {
var result : Boolean = false
val connectivityManager: android.net.ConnectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as android.net.ConnectivityManager
val network : android.net.Network = connectivityManager.activeNetwork ?: return false // <---- Error
val nwCap : android.net.NetworkCapabilities = connectivityManager.getNetworkCapabilities(network) ?: return false // <---- Error
result = when {
nwCap.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) -> true
nwCap.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) -> true
nwCap.hasTransport(NetworkCapabilities.TRANSPORT_ETHERNET) -> true
else -> false
}
return result
}
}
}
In build process, the next errors are thrown (only appears after "Foursquare" dependency injection)
D:\clcwork\kotlin\EjOauth\app\src\main\java\com\example\ejoauth\networkconnection\NetworkConnectionStatus.kt: (15, 69): Unresolved reference: activeNetwork D:\clcwork\kotlin\EjOauth\app\src\main\java\com\example\ejoauth\networkconnection\NetworkConnectionStatus.kt: (16, 79): Unresolved reference: getNetworkCapabilities
It seems like "Foursquare" libraries overwrite some clases or packages with another implementation in which attributes or methods are lost. The only solution I have found so far is not implementing this method “NetworkConnectionStatus.isInternetAvailable”. But this is not a solution. As you can see, I'm indicating packages explicitly in my code.
Can you help me, please?
Thank you in advance.

Failed to Call configuration.setLocale() During Page Initialization

Symptom
The global method changeLocaleConfiguration is defined in the app.ux file of a quick app to set the app language. When the changeLocaleConfiguration() method is called and configuration.setLocale() in it is successfully triggered in the lifecycle method onInit of the home page, the app language does not change.
Code in app.ux:
HTML:
changeLocaleConfiguration() {
this.localeObject = configuration.getLocale()
if (this.localeObject.language === 'zh') {
configuration.setLocale({
language: 'en',
countryOrRegion: 'US'
})
}
else {
configuration.setLocale({
language: 'zh',
countryOrRegion: 'CN'
})
}
}
Code of the home page:
HTML:
onInit() {
this.$app.$def.changeLocaleConfiguration()
}
Cause Analysis
Page initialization takes a short time, but language setting takes a long time. As a result, the page cannot be rendered in time.
Solution
Add a delay when calling the language setting API during page initialization. The code is as follows:
HTML:
onInit() {
setTimeout(() => {
this.$app.$def.changeLocaleConfiguration()
}, 100);
}
Suggestions and Summary
You are advised not to call time-consuming operations in onInit. If you must call the operations, add a delay.

React Native Startup Speed Optimization - Native Chapter (Including Source Code Analysis)

0. React Native Startup Process
React Native is a web front-end friendly hybrid development framework that can be divided into two parts at startup:
· Running of Native Containers
· Running of JavaScript code
The Native container is started in the existing architecture (the version number is less than 1.0.0). The native container can be divided into three parts:
· Native container initialization
· Full binding of native modules
· Initialization of JSEngine
After the container is initialized, the stage is handed over to JavaScript, and the process can be divided into two parts:
· Loading, parsing, and execution of JavaScript code
· Construction of JS components
Finally, the JS Thread sends the calculated layout information to the Native end, calculates the Shadow Tree, and then the UI Thread performs layout and rendering.
I have drawn a diagram of the preceding steps. The following table describes the optimization direction of each step from left to right:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Note: During React Native initialization, multiple tasks may be executed concurrently. Therefore, the preceding figure only shows the initialization process of React Native and does not correspond to the execution sequence of the actual code.
1. Upgrade React Native
The best way to improve the performance of React Native applications is to upgrade a major version of the RN. After the app is upgraded from 0.59 to 0.62, no performance optimization is performed on the app, and the startup time is shortened by 1/2. When React Native's new architecture is released, both startup speed and rendering speed will be greatly improved.
2. Native container initialization
Container initialization must start from the app entry file. I will select some key code to sort out the initialization process.
iOS source code analysis
1.AppDelegate.m
AppDelegate.m is the entry file of the iOS. The code is simple. The main content is as follows:
// AppDelegate.m
- (BOOL)applicationUIApplication *)application didFinishLaunchingWithOptionsNSDictionary *)launchOptions {
// 1. Initialize a method for loading jsbundle by RCTBridge.
RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
// 2. Use RCTBridge to initialize an RCTRootView.
RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
moduleName"RN64"
initialProperties:nil];
// 3. Initializing the UIViewController
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
// 4. Assigns the value of RCTRootView to the view of UIViewController.
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
return YES;
}
In general, looking at the entry document, it does three things:
Ø Initialize an RCTBridge implementation method for loading jsbundle.
Ø Use RCTBridge to initialize an RCTRootView.
Ø Assign the value of RCTRootView to the view of UIViewController to mount the UI.
From the entry source code, we can see that all the initialization work points to RCTRootView, so let's see what RCTRootView does.
2.RCTRootView
Let's take a look at the header file of RCTRootView first. Let's just look at some of the methods we focus on:
/ RCTRootView.h
@interface RCTRootView : UIView
// Initialization methods used in AppDelegate.m
- (instancetype)initWithBridgeRCTBridge *)bridge
moduleNameNSString *)moduleName
initialPropertiesnullable NSDictionary *)initialProperties NS_DESIGNATED_INITIALIZER;
From the header file:
Ø RCTRootView inherits from UIView, so it is essentially a UI component;
Ø When the RCTRootView invokes initWithBridge for initialization, an initialized RCTBridge must be transferred.
In the RCTRootView.m file, initWithBridge listens to a series of JS loading listening functions during initialization. After listening to the completion of JS Bundle file loading, it invokes AppRegistry.runApplication() in JS to start the RN application.
We find that RCTRootView.m only monitors various events of RCTBridge, but is not the core of initialization. Therefore, we need to go to the RCTBridge file.
3.RCTBridge.m
In RCTBridge.m, the initialization invoking path is long, and the full pasting source code is long. In short, the last call is (void)setUp. The core code is as follows:
- (Class)bridgeClass
{
return [RCTCxxBridge class];
}
- (void)setUp {
// Obtains the bridgeClass. The default value is RCTCxxBridge.
Class bridgeClass = self.bridgeClass;
// Initializing the RTCxxBridge
self.batchedBridge = [[bridgeClass alloc] initWithParentBridge:self];
// Starting RTCxxBridge
[self.batchedBridge start];
}
We can see that the initialization of the RCTBridge points to the RTCxxBridge.
4.RTCxxBridge.mm
RTCxxBridge is the core of React Native initialization, and I looked at some material, and it seems that RTCxxBridge used to be called RCTBatchedBridge, so it's OK to crudely treat these two classes as the same thing.
Since the start method of RTCxxBridge is called in RCTBridge, let's see what we do from the start method.
// RTCxxBridge.mm
- (void)start {
// 1. Initialize JSThread. All subsequent JS codes are executed in this thread.
_jsThread = [[NSThread alloc] initWithTarget:[self class] selectorselector(runRunLoop) object:nil];
[_jsThread start];
// Creating a Parallel Queue
dispatch_group_t prepareBridge = dispatch_group_create();
// 2. Register all native modules.
[self registerExtraModules];
(void)[self _initializeModules:RCTGetModuleClasses() withDispatchGrouprepareBridge lazilyDiscovered:NO];
// 3. Initializing the JSExecutorFactory Instance
std::shared_ptr<JSExecutorFactory> executorFactory;
// 4. Initializes the underlying instance, namely, _reactInstance.
dispatch_group_enter(prepareBridge);
[self ensureOnJavaScriptThread:^{
[weakSelf _initializeBridge:executorFactory];
dispatch_group_leave(prepareBridge);
}];
// 5. Loading the JS Code
dispatch_group_enter(prepareBridge);
__block NSData *sourceCode;
[self
loadSource:^(NSError *error, RCTSource *source) {
if (error) {
[weakSelf handleError:error];
}
sourceCode = source.data;
dispatch_group_leave(prepareBridge);
}
onProgress:^(RCTLoadingProgress *progressData) {
}
];
// 6. Execute JS after the native module and JS code are loaded.
dispatch_group_notify(prepareBridge, dispatch_get_global_queue(QOS_CLASS_USER_INTERACTIVE, 0), ^{
RCTCxxBridge *strongSelf = weakSelf;
if (sourceCode && strongSelf.loading) {
[strongSelf executeSourceCode:sourceCode sync:NO];
}
});
}
The preceding code is long, which uses some knowledge of GCD multi-threading. The process is described as follows:
Initialize the JS thread_jsThread.
Register all native modules on the main thread.
Prepare the bridge between JS and Native and the JS running environment.
Create the message queue RCTMessageThread on the JS thread and initialize _reactInstance.
Load the JS Bundle on the JS thread.
Execute the JS code after all the preceding operations are complete.
In fact, all the above six points can be drilled down, but the source code content involved in this section is enough. Interested readers can explore the source code based on the reference materials and the React Native source code.
Android source code analysis
1.MainActivity.java & MainApplication.java
Like iOS, the startup process starts with the entry file. Let's look at MainActivity.java:
MainActivity inherits from ReactActivity and ReactActivity inherits from AppCompatActivity:
// MainActivity.java
public class MainActivity extends ReactActivity {
// The returned component name is the same as the registered name of the JS portal.
@override
protected String getMainComponentName() {
return "rn_performance_demo";
}
}
Let's start with the Android entry file MainApplication.java:
// MainApplication.java
public class MainApplication extends Application implements ReactApplication {
private final ReactNativeHost mReactNativeHost =
new ReactNativeHost(this) {
// Return the ReactPackage required by the app and add the modules to be loaded,
// This is where a third-party package needs to be added when a dependency package is added to a project.
@override
protected List<ReactPackage> getPackages() {
@SuppressWarnings("UnnecessaryLocalVariable")
List<ReactPackage> packages = new PackageList(this).getPackages();
return packages;
}
// JS bundle entry file. Set this parameter to index.js.
@override
protected String getJSMainModuleName() {
return "index";
}
};
@override
public ReactNativeHost getReactNativeHost() {
return mReactNativeHost;
}
@override
public void onCreate() {
super.onCreate();
// SoLoader:Loading the C++ Underlying Library
SoLoader.init(this, /* native exopackage */ false);
}
}
The ReactApplication interface is simple and requires us to create a ReactNativeHost object:
public interface ReactApplication {
ReactNativeHost getReactNativeHost();
}
From the above analysis, we can see that everything points to the ReactNativeHost class. Let's take a look at it.
2.ReactNativeHost.java
The main task of ReactNativeHost is to create ReactInstanceManager.
public abstract class ReactNativeHost {
protected ReactInstanceManager createReactInstanceManager() {
ReactMarker.logMarker(ReactMarkerConstants.BUILD_REACT_INSTANCE_MANAGER_START);
ReactInstanceManagerBuilder builder =
ReactInstanceManager.builder()
// Application Context
.setApplication(mApplication)
// JSMainModulePath is equivalent to the JS Bundle on the application home page. It can transfer the URL to obtain the JS Bundle from the server.
// Of course, this can be used only in dev mode.
.setJSMainModulePath(getJSMainModuleName())
// Indicates whether to enable the dev mode.
.setUseDeveloperSupport(getUseDeveloperSupport())
// Redbox callback
.setRedBoxHandler(getRedBoxHandler())
.setJavaScriptExecutorFactory(getJavaScriptExecutorFactory())
.setUIImplementationProvider(getUIImplementationProvider())
.setJSIModulesPackage(getJSIModulePackage())
.setInitialLifecycleState(LifecycleState.BEFORE_CREATE);
// Add ReactPackage
for (ReactPackage reactPackage : getPackages()) {
builder.addPackage(reactPackage);
}
// Obtaining the Loading Path of the JS Bundle
String jsBundleFile = getJSBundleFile();
if (jsBundleFile != null) {
builder.setJSBundleFile(jsBundleFile);
} else {
builder.setBundleAssetName(Assertions.assertNotNull(getBundleAssetName()));
}
ReactInstanceManager reactInstanceManager = builder.build();
return reactInstanceManager;
}
}
3.ReactActivityDelegate.java
Let's go back to ReactActivity. It doesn't do anything by itself. All functions are implemented by its delegate class ReactActivityDelegate. So let's see how ReactActivityDelegate implements it.
public class ReactActivityDelegate {
protected void onCreate(Bundle savedInstanceState) {
String mainComponentName = getMainComponentName();
mReactDelegate =
new ReactDelegate(
getPlainActivity(), getReactNativeHost(), mainComponentName, getLaunchOptions()) {
@override
protected ReactRootView createRootView() {
return ReactActivityDelegate.this.createRootView();
}
};
if (mMainComponentName != null) {
// Loading the app page
loadApp(mainComponentName);
}
}
protected void loadApp(String appKey) {
mReactDelegate.loadApp(appKey);
// SetContentView() method of Activity
getPlainActivity().setContentView(mReactDelegate.getReactRootView());
}
}
OnCreate() instantiates a ReactDelegate. Let's look at its implementation.
4.ReactDelegate.java
In ReactDelegate.java, I don't see it doing two things:
Ø Create ReactRootView as the root view
Ø Start the RN application by calling getReactNativeHost().getReactInstanceManager()
public class ReactDelegate {
public void loadApp(String appKey) {
if (mReactRootView != null) {
throw new IllegalStateException("Cannot loadApp while app is already running.");
}
// Create ReactRootView as the root view
mReactRootView = createRootView();
// Starting the RN Application
mReactRootView.startReactApplication(
getReactNativeHost().getReactInstanceManager(), appKey, mLaunchOptions);
}
}
Basic Startup Process The source code content involved in this section is here. Interested readers can explore the source code based on the reference materials and React Native source code.
Optimization Suggestions
For applications with React Native as the main body, the RN container needs to be initialized immediately after the app is started. There is no optimization idea. However, native-based hybrid development apps have the following advantages:
Since initialization takes the longest time, can we initialize it before entering the React Native container?
This method is very common because many H5 containers do the same. Before entering the WebView web page, create a WebView container pool and initialize the WebView in advance. After entering the H5 container, load data rendering to achieve the effect of opening the web page in seconds.
The concept of the RN container pool is very mysterious. It is actually a map. The key is the componentName of the RN page (that is, the app name transferred in AppRegistry.registerComponent(appName, Component)), and the value is an instantiated RCT RootView/ReactRootView.
After the app is started, it is initialized in advance. Before entering the RN container, it reads the container pool. If there is a matched container, it directly uses it. If there is no matched container, it is initialized again.
Write two simple cases. The following figure shows how to build an RN container pool for iOS.
@Property (nonatomic, strong) NSMutableDictionary<NSString *, RCTRootView *> *rootViewRool;
// Container Pool
-(NSMutableDictionary<NSString *, RCTRootView *> *)rootViewRool {
if (!_rootViewRool) {
_rootViewRool = @{}.mutableCopy;
}
return _rootViewRool;
}
// Cache RCTRootView
-(void)cacheRootViewNSString *)componentName pathNSString *)path propsNSDictionary *)props bridgeRCTBridge *)bridge {
// initialization
RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
moduleName:componentName
initialPropertiesrops];
// The instantiation must be loaded to the bottom of the screen. Otherwise, the view rendering cannot be triggered
[[UIApplication sharedApplication].keyWindow.rootViewController.view insertSubview:rootView atIndex:0];
rootView.frame = [UIScreen mainScreen].bounds;
// Put the cached RCTRootView into the container pool
NSString *key = [NSString stringWithFormat"%@_%@", componentName, path];
self.rootViewRool[key] = rootView;
}
// Read Container
-(RCTRootView *)getRootViewNSString *)componentName pathNSString *)path propsNSDictionary *)props bridgeRCTBridge *)bridge {
NSString *key = [NSString stringWithFormat"%@_%@", componentName, path];
RCTRootView *rootView = self.rootViewRool[key];
if (rootView) {
return rootView;
}
// Back-to-back logic
return [[RCTRootView alloc] initWithBridge:bridge moduleName:componentName initialPropertiesrops];
}
Android builds the RN container pool as follows:
private HashMap<String, ReactRootView> rootViewPool = new HashMap<>();
// Creating a Container
private ReactRootView createRootView(String componentName, String path, Bundle props, Context context) {
ReactInstanceManager bridgeInstance = ((ReactApplication) application).getReactNativeHost().getReactInstanceManager();
ReactRootView rootView = new ReactRootView(context);
if(props == null) {
props = new Bundle();
}
props.putString("path", path);
rootView.startReactApplication(bridgeInstance, componentName, props);
return rootView;
}
// Cache Container
public void cahceRootView(String componentName, String path, Bundle props, Context context) {
ReactRootView rootView = createRootView(componentName, path, props, context);
String key = componentName + "_" + path;
// Put the cached RCTRootView into the container pool.
rootViewPool.put(key, rootView);
}
// Read Container
public ReactRootView getRootView(String componentName, String path, Bundle props, Context context) {
String key = componentName + "_" + path;
ReactRootView rootView = rootViewPool.get(key);
if (rootView != null) {
rootView.setAppProperties(newProps);
rootViewPool.remove(key);
return rootView;
}
// Back-to-back logic
return createRootView(componentName, path, props, context);
}
Each RCTRootView/ReactRootView occupies a certain memory. Therefore, when to instantiate, how many containers to instantiate, how to limit the pool size, and when to clear containers need to be practiced and explored based on services.
3. Native Modules Binding
r/HuaweiDevelopers - React Native Startup Speed Optimization - Native Chapter (Including Source Code Analysis)
iOS source code analysis
The iOS Native Modules has three parts. The main part is the _initializeModules function in the middle:
// RCTCxxBridge.mm
- (void)start {
// Native modules returned by the moduleProvider in initWithBundleURL_moduleProvider_launchOptions when the RCTBridge is initialized
[self registerExtraModules];
// Registering All Custom Native Modules
(void)[self _initializeModules:RCTGetModuleClasses() withDispatchGrouprepareBridge lazilyDiscovered:NO];
// Initializes all native modules that are lazily loaded. This command is invoked only when Chrome debugging is used
[self registerExtraLazyModules];
}
Let's see what the _initializeModules function does:
// RCTCxxBridge.mm
- (NSArray<RCTModuleData *> *)_initializeModulesNSArray<Class> *)modules
withDispatchGroupdispatch_group_t)dispatchGroup
lazilyDiscoveredBOOL)lazilyDiscovered
{
for (RCTModuleData *moduleData in _moduleDataByID) {
if (moduleData.hasInstance && (!moduleData.requiresMainQueueSetup || RCTIsMainQueue())) {
// Modules that were pre-initialized should ideally be set up before
// bridge init has finished, otherwise the caller may try to access the
// module directly rather than via `[bridge moduleForClass:]`, which won't
// trigger the lazy initialization process. If the module cannot safely be
// set up on the current thread, it will instead be async dispatched
// to the main thread to be set up in _prepareModulesWithDispatchGroup:.
(void)[moduleData instance];
}
}
_moduleSetupComplete = YES;
[self _prepareModulesWithDispatchGroup:dispatchGroup];
}
According to the comments in _initializeModules and _prepareModulesWithDispatchGroup, the iOS initializes all Native Modules in the main thread during JS Bundle loading (in the JSThead thread).
Based on the previous source code analysis, we can see that when the React Native iOS container is initialized, all Native Modules are initialized. If there are many Native Modules, the startup time of the Android RN container is affected.
Android source code analysis
For the registration of Native Modules, the mainApplication.java entry file provides clues:
// MainApplication.java
protected List<ReactPackage> getPackages() {
@SuppressWarnings("UnnecessaryLocalVariable")
List<ReactPackage> packages = new PackageList(this).getPackages();
// Packages that cannot be autolinked yet can be added manually here, for example:
// packages.add(new MyReactNativePackage());
return packages;
}
Since auto link is enabled in React Native after 0.60, the installed third-party Native Modules are in PackageList. Therefore, you can obtain the modules of auto link by simply gettingPackages().
In the source code, in the ReactInstanceManager.java file, createReactContext() is run to create a ReactContext. One step is to register the registry of nativeModules.
// ReactInstanceManager.java
private ReactApplicationContext createReactContext(
JavaScriptExecutor jsExecutor,
JSBundleLoader jsBundleLoader) {
// Registering the nativeModules Registry
NativeModuleRegistry nativeModuleRegistry = processPackages(reactContext, mPackages, false);
}
According to the function invoking, we trace the processPackages() function and use a for loop to add all Native Modules in mPackages to the registry:
// ReactInstanceManager.java
private NativeModuleRegistry processPackages(
ReactApplicationContext reactContext,
List<ReactPackage> packages,
boolean checkAndUpdatePackageMembership) {
// Create JavaModule Registry Builder, which creates the JavaModule registry,
// JavaModule Registry Registers all JavaModules to Catalyst Instance
NativeModuleRegistryBuilder nativeModuleRegistryBuilder =
new NativeModuleRegistryBuilder(reactContext, this);
// Locking mPackages
// The mPackages type is List<ReactPackage>, which corresponds to packages in the MainApplication.java file
synchronized (mPackages) {
for (ReactPackage reactPackage : packages) {
try {
// Loop the ReactPackage injected into the application. The process is to add the modules to the corresponding registry
processPackage(reactPackage, nativeModuleRegistryBuilder);
} finally {
Systrace.endSection(TRACE_TAG_REACT_JAVA_BRIDGE);
}
}
}
NativeModuleRegistry nativeModuleRegistry;
try {
// Generating the Java Module Registry
nativeModuleRegistry = nativeModuleRegistryBuilder.build();
} finally {
Systrace.endSection(TRACE_TAG_REACT_JAVA_BRIDGE);
ReactMarker.logMarker(BUILD_NATIVE_MODULE_REGISTRY_END);
}
return nativeModuleRegistry;
}
Finally, call processPackage() for real registration:
// ReactInstanceManager.java
private void processPackage(
ReactPackage reactPackage,
NativeModuleRegistryBuilder nativeModuleRegistryBuilder
) {
nativeModuleRegistryBuilder.processPackage(reactPackage);
}
As shown in the preceding process, full registration is performed when Android registers Native Modules. If there are a large number of Native Modules, the startup time of the Android RN container will be affected.
Optimization Suggestions
To be honest, full binding of Native Modules is unsolvable in the existing architecture: regardless of whether the native method is used or not, all native methods are initialized when the container is started. In the new RN architecture, TurboModules solves this problem (described in the next section of this article).
If you have to talk about optimization, you have another idea. Do you want to initialize all the native modules? Can I reduce the number of Native Modules? One step in the new architecture is Lean Core, which is to simplify the React Native core. Some functions/components (such as the WebView component) are removed from the main project of the RN and delivered to the community for maintenance. You can download and integrate them separately when you want to use them.
The main benefits of this approach are as follows:
· The core is more streamlined, and the RN maintainer has more energy to maintain main functions.
· Reduce the binding time of Native Modules and unnecessary JS loading time, and reduce the package size, which is more friendly to initialization performance. (After the RN version is upgraded to 0.62, the initialization speed is doubled, which is basically thanks to Lean Core.)
· Accelerate iteration and optimize development experience.
Now that Lean Core's work is almost complete, see the official issue discussion section for more discussion. We can enjoy Lean Core's work as long as we upgrade React Native.
4. How to optimize the startup performance of the new RN architecture
The new architecture of React Native has been skipping votes for almost two years. Every time you ask about the progress, the official response is "Don't rush, don't rush, we're doing it."
I personally looked forward to it all year last year, but didn't wait for anything, so I don't care when the RN will update to version 1.0.0. Although the RN official has been doing some work, I have to say that their new architecture still has something. I have watched all the articles and videos on the new architecture in the market, so I have an overall understanding of the new architecture.
Because the new architecture has not been officially released, there must be some differences in details. The specific implementation details will be subject to the official React Native.
JSI
The full name of JSI is JavaScript Interface, a framework written in C++ that allows JS to call native methods directly instead of communicating asynchronously through Bridge.
How do I understand how JavaScript directly invokes Native? Let's take a simple example. When an API such as setTimeout document.getElementById is invoked on a browser, Native Code is directly invoked on the JavaScript side. You can verify the function on the browser console.
For example, I executed an order:
let el = document.createElement('div')
The variable el does not hold a JS object, but an object that is instantiated in C++. For the object held by el, set the following attributes:
el.setAttribute('width', 100)
In this case, JS synchronously invokes the setWidth method in C++ to change the width of the element.
The JSI in the new architecture of React Native is used for this purpose. With the JSI, we can use JS to directly obtain the reference of C++ objects (Host Objects), control the UI, and directly invoke methods of Native Modules, saving the overhead of bridge asynchronous communication.
Let's take a small example of how Java/OC uses JSI to expose synchronous invocation methods to JS.
#pragma once
#include <string>
#include <unordered_map>
#include <jsi/jsi.h>
// SampleJSIObject inherits from HostObject and represents an object exposed to JS
// For JS, JS can directly invoke the properties and methods on the object synchronously
class JSI_EXPORT SampleJSIObject : public facebook::jsi::HostObject {
public:
// The first step
// Exposes window.__SampleJSIObject to JavaScript
// This is a static function that is generally called from ObjC/Java during application initialization
static void SampleJSIObject::install(jsi::Runtime &runtime) {
runtime.global().setProperty(
runtime,
"__sampleJSIObject",
jsi::Function::createFromHostFunction(
runtime,
jsi:ropNameID::forAscii(runtime, "__SampleJSIObject"),
1,
[binding](jsi::Runtime& rt, const jsi::Value& thisVal, const jsi::Value* args, size_t count) {
// Returns the content of a call to window.__SampleJSIObject
return std::make_shared<SampleJSIObject>();
}));
}
// Similar to a getter, this method is used each time the JS accesses the object. The function is similar to a wrapper
// For example, if we call window.__sampleJSIObject.method1(), this method will be called
jsi::Value TurboModule::get(jsi::Runtime& runtime, const jsi:ropNameID& propName) {
// Invoking method name
// For example, when window.__sampleJSIObject.method1() is called, propNameUtf8 is method1
std::string propNameUtf8 = propName.utf8(runtime);
return jsi::Function::createFromHostFunction(
runtime,
propName,
argCount,
[](facebook::jsi::Runtime &rt, const facebook::jsi::Value &thisVal, const facebook::jsi::Value *args, size_t count) {
if (propNameUtf8 == 'method1') {
// Function processing logic when method1 is invoked
}
});
}
std::vector<PropNameID> getPropertyNames(Runtime& rt){
}
}
The above example is short. To learn more about JSI, read the React Native JSI Challenge article or read the source code directly.
TurboModules
According to the previous source code analysis, in the current architecture, native modules are fully loaded during native initialization. As services are iterated, the number of native modules increases, which takes a longer time.
TurboModules solves this problem all at once. In the new architecture, native modules are loaded in lazy mode. That is, the loading is initialized only when you invoke the corresponding native modules. This solves the problem that initializing full loading takes a long time.
The calling path of TurboModules is as follows:
1. Use JSI to create a top-level Native Modules Proxy, which is called global.__turboModuleProxy.
2.Access a Native Module. For example, to access the SampleTurboModule, execute require('NativeSampleTurboModule') on the JavaScript side.
3.In the NativeSampleTurboModule.js file, we call TurboModuleRegistry.getEnforcing() and then call global.__turboModuleProxy("SampleTurboModule").
4.When global.__turboModuleProxy is invoked, the Native method exposed by the JSI in step 1 is invoked. In this case, the C++ layer finds the ObjC/Java implementation through the input string "SampleTurboModule". Finally, a corresponding JSI object is returned.
5.Now that we have the JSI object of SampleTurboModule, we can use JavaScript to synchronously invoke the properties and methods of the JSI object.
Through the preceding steps, we can see that with TurboModules, Native Modules are loaded only when they are invoked for the first time. This completely eliminates the time required for fully loading Native Modules during initialization of the React Native container. In addition, we can use JSI to implement synchronous invoking of JS and Native, which takes less time and improves efficiency.
Summary
This document analyzes the startup process of the existing architecture of React Native from the perspective of Native and summarizes the performance optimization points of the Native layer. Finally, we briefly introduce the new architecture of React Native. In the next article, I'll explain how to start with JavaScript and optimize React Native's startup speed.
By Halogenated Hydrocarbons
Original Link: https://segmentfault.com/a/1190000039797508

React Native Startup Speed Optimization - Native Chapter (Including Source Code Analysis) 0. React Native Startup Process React Native is a web fron

0. React Native Startup Process
React Native is a web front-end friendly hybrid development framework that can be divided into two parts at startup:
Running of Native Containers​
Running of JavaScript code​
The Native container is started in the existing architecture (the version number is less than 1.0.0). The native container can be divided into three parts:
Native container initialization​
Full binding of native modules​
Initialization of JSEngine​
After the container is initialized, the stage is handed over to JavaScript, and the process can be divided into two parts:
Loading, parsing, and execution of JavaScript code​
Construction of JS components​
Finally, the JS Thread sends the calculated layout information to the Native end, calculates the Shadow Tree, and then the UI Thread performs layout and rendering.
I have drawn a diagram of the preceding steps. The following table describes the optimization direction of each step from left to right:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Note: During React Native initialization, multiple tasks may be executed concurrently. Therefore, the preceding figure only shows the initialization process of React Native and does not correspond to the execution sequence of the actual code.
1. Upgrade React Native
The best way to improve the performance of React Native applications is to upgrade a major version of the RN. After the app is upgraded from 0.59 to 0.62, no performance optimization is performed on the app, and the startup time is shortened by 1/2. When React Native's new architecture is released, both startup speed and rendering speed will be greatly improved.
2. Native container initialization
Container initialization must start from the app entry file. I will select some key code to sort out the initialization process.
iOS source code analysis
1.AppDelegate.m
AppDelegate.m is the entry file of the iOS. The code is simple. The main content is as follows:
Code:
// AppDelegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// 1. Initialize a method for loading jsbundle by RCTBridge.
RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
// 2. Use RCTBridge to initialize an RCTRootView.
RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
moduleName:@"RN64"
initialProperties:nil];
// 3. Initializing the UIViewController
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
// 4. Assigns the value of RCTRootView to the view of UIViewController.
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
return YES;
}
In general, looking at the entry document, it does three things:
Initialize an RCTBridge implementation method for loading jsbundle.
Use RCTBridge to initialize an RCTRootView.
Assign the value of RCTRootView to the view of UIViewController to mount the UI.
From the entry source code, we can see that all the initialization work points to RCTRootView, so let's see what RCTRootView does.
2.RCTRootView
Let's take a look at the header file of RCTRootView first. Let's just look at some of the methods we focus on:
Code:
// RCTRootView.h
@interface RCTRootView : UIView
// Initialization methods used in AppDelegate.m
- (instancetype)initWithBridge:(RCTBridge *)bridge
moduleName:(NSString *)moduleName
initialProperties:(nullable NSDictionary *)initialProperties NS_DESIGNATED_INITIALIZER;
From the header file:
RCTRootView inherits from UIView, so it is essentially a UI component;
When the RCTRootView invokes initWithBridge for initialization, an initialized RCTBridge must be transferred.
In the RCTRootView.m file, initWithBridge listens to a series of JS loading listening functions during initialization. After listening to the completion of JS Bundle file loading, it invokes AppRegistry.runApplication() in JS to start the RN application.
We find that RCTRootView.m only monitors various events of RCTBridge, but is not the core of initialization. Therefore, we need to go to the RCTBridge file.
3.RCTBridge.m
In RCTBridge.m, the initialization invoking path is long, and the full pasting source code is long. In short, the last call is (void)setUp. The core code is as follows:
Code:
- (Class)bridgeClass
{
return [RCTCxxBridge class];
}
- (void)setUp {
// Obtains the bridgeClass. The default value is RCTCxxBridge.
Class bridgeClass = self.bridgeClass;
// Initializing the RTCxxBridge
self.batchedBridge = [[bridgeClass alloc] initWithParentBridge:self];
// Starting RTCxxBridge
[self.batchedBridge start];
}
We can see that the initialization of the RCTBridge points to the RTCxxBridge.
4.RTCxxBridge.mm
RTCxxBridge is the core of React Native initialization, and I looked at some material, and it seems that RTCxxBridge used to be called RCTBatchedBridge, so it's OK to crudely treat these two classes as the same thing.
Since the start method of RTCxxBridge is called in RCTBridge, let's see what we do from the start method.
Code:
// RTCxxBridge.mm
- (void)start {
// 1. Initialize JSThread. All subsequent JS codes are executed in this thread.
_jsThread = [[NSThread alloc] initWithTarget:[self class] selector:@selector(runRunLoop) object:nil];
[_jsThread start];
// Creating a Parallel Queue
dispatch_group_t prepareBridge = dispatch_group_create();
// 2. Register all native modules.
[self registerExtraModules];
(void)[self _initializeModules:RCTGetModuleClasses() withDispatchGroup:prepareBridge lazilyDiscovered:NO];
// 3. Initializing the JSExecutorFactory Instance
std::shared_ptr<JSExecutorFactory> executorFactory;
// 4. Initializes the underlying instance, namely, _reactInstance.
dispatch_group_enter(prepareBridge);
[self ensureOnJavaScriptThread:^{
[weakSelf _initializeBridge:executorFactory];
dispatch_group_leave(prepareBridge);
}];
// 5. Loading the JS Code
dispatch_group_enter(prepareBridge);
__block NSData *sourceCode;
[self
loadSource:^(NSError *error, RCTSource *source) {
if (error) {
[weakSelf handleError:error];
}
sourceCode = source.data;
dispatch_group_leave(prepareBridge);
}
onProgress:^(RCTLoadingProgress *progressData) {
}
];
// 6. Execute JS after the native module and JS code are loaded.
dispatch_group_notify(prepareBridge, dispatch_get_global_queue(QOS_CLASS_USER_INTERACTIVE, 0), ^{
RCTCxxBridge *strongSelf = weakSelf;
if (sourceCode && strongSelf.loading) {
[strongSelf executeSourceCode:sourceCode sync:NO];
}
});
}
The preceding code is long, which uses some knowledge of GCD multi-threading. The process is described as follows:
1. Initialize the JS thread_jsThread.
2. Register all native modules on the main thread.
3. Prepare the bridge between JS and Native and the JS running environment.
4. Create the message queue RCTMessageThread on the JS thread and initialize _reactInstance.
5. Load the JS Bundle on the JS thread.
6. Execute the JS code after all the preceding operations are complete.
In fact, all the above six points can be drilled down, but the source code content involved in this section is enough. Interested readers can explore the source code based on the reference materials and the React Native source code.
Android source code analysis
1.MainActivity.java & MainApplication.java
Like iOS, the startup process starts with the entry file. Let's look at MainActivity.java:
MainActivity inherits from ReactActivity and ReactActivity inherits from AppCompatActivity:
Code:
// MainActivity.java
public class MainActivity extends ReactActivity {
// The returned component name is the same as the registered name of the JS portal.
@Override
protected String getMainComponentName() {
return "rn_performance_demo";
}
}
Let's start with the Android entry file MainApplication.java:
Code:
// MainApplication.java
public class MainApplication extends Application implements ReactApplication {
private final ReactNativeHost mReactNativeHost =
new ReactNativeHost(this) {
// Return the ReactPackage required by the app and add the modules to be loaded,
// This is where a third-party package needs to be added when a dependency package is added to a project.
@Override
protected List<ReactPackage> getPackages() {
@SuppressWarnings("UnnecessaryLocalVariable")
List<ReactPackage> packages = new PackageList(this).getPackages();
return packages;
}
// JS bundle entry file. Set this parameter to index.js.
@Override
protected String getJSMainModuleName() {
return "index";
}
};
@Override
public ReactNativeHost getReactNativeHost() {
return mReactNativeHost;
}
@Override
public void onCreate() {
super.onCreate();
// SoLoader:Loading the C++ Underlying Library
SoLoader.init(this, /* native exopackage */ false);
}
}
The ReactApplication interface is simple and requires us to create a ReactNativeHost object:
Code:
public interface ReactApplication {
ReactNativeHost getReactNativeHost();
}
From the above analysis, we can see that everything points to the ReactNativeHost class. Let's take a look at it.
2.ReactNativeHost.java
The main task of ReactNativeHost is to create ReactInstanceManager.
Code:
public abstract class ReactNativeHost {
protected ReactInstanceManager createReactInstanceManager() {
ReactMarker.logMarker(ReactMarkerConstants.BUILD_REACT_INSTANCE_MANAGER_START);
ReactInstanceManagerBuilder builder =
ReactInstanceManager.builder()
// Application Context
.setApplication(mApplication)
// JSMainModulePath is equivalent to the JS Bundle on the application home page. It can transfer the URL to obtain the JS Bundle from the server.
// Of course, this can be used only in dev mode.
.setJSMainModulePath(getJSMainModuleName())
// Indicates whether to enable the dev mode.
.setUseDeveloperSupport(getUseDeveloperSupport())
// Redbox callback
.setRedBoxHandler(getRedBoxHandler())
.setJavaScriptExecutorFactory(getJavaScriptExecutorFactory())
.setUIImplementationProvider(getUIImplementationProvider())
.setJSIModulesPackage(getJSIModulePackage())
.setInitialLifecycleState(LifecycleState.BEFORE_CREATE);
// Add ReactPackage
for (ReactPackage reactPackage : getPackages()) {
builder.addPackage(reactPackage);
}
// Obtaining the Loading Path of the JS Bundle
String jsBundleFile = getJSBundleFile();
if (jsBundleFile != null) {
builder.setJSBundleFile(jsBundleFile);
} else {
builder.setBundleAssetName(Assertions.assertNotNull(getBundleAssetName()));
}
ReactInstanceManager reactInstanceManager = builder.build();
return reactInstanceManager;
}
}
3.ReactActivityDelegate.java
Let's go back to ReactActivity. It doesn't do anything by itself. All functions are implemented by its delegate class ReactActivityDelegate. So let's see how ReactActivityDelegate implements it.
Code:
public class ReactActivityDelegate {
protected void onCreate(Bundle savedInstanceState) {
String mainComponentName = getMainComponentName();
mReactDelegate =
new ReactDelegate(
getPlainActivity(), getReactNativeHost(), mainComponentName, getLaunchOptions()) {
@Override
protected ReactRootView createRootView() {
return ReactActivityDelegate.this.createRootView();
}
};
if (mMainComponentName != null) {
// Loading the app page
loadApp(mainComponentName);
}
}
protected void loadApp(String appKey) {
mReactDelegate.loadApp(appKey);
// SetContentView() method of Activity
getPlainActivity().setContentView(mReactDelegate.getReactRootView());
}
}
OnCreate() instantiates a ReactDelegate. Let's look at its implementation.
4.ReactDelegate.java
In ReactDelegate.java, I don't see it doing two things:
Create ReactRootView as the root view​
Start the RN application by calling getReactNativeHost().getReactInstanceManager()​
Code:
public class ReactDelegate {
public void loadApp(String appKey) {
if (mReactRootView != null) {
throw new IllegalStateException("Cannot loadApp while app is already running.");
}
// Create ReactRootView as the root view
mReactRootView = createRootView();
// Starting the RN Application
mReactRootView.startReactApplication(
getReactNativeHost().getReactInstanceManager(), appKey, mLaunchOptions);
}
}
Basic Startup Process The source code content involved in this section is here. Interested readers can explore the source code based on the reference materials and React Native source code.
Optimization Suggestions
For applications with React Native as the main body, the RN container needs to be initialized immediately after the app is started. There is no optimization idea. However, native-based hybrid development apps have the following advantages:
Since initialization takes the longest time, can we initialize it before entering the React Native container?
This method is very common because many H5 containers do the same. Before entering the WebView web page, create a WebView container pool and initialize the WebView in advance. After entering the H5 container, load data rendering to achieve the effect of opening the web page in seconds.
The concept of the RN container pool is very mysterious. It is actually a map. The key is the componentName of the RN page (that is, the app name transferred in AppRegistry.registerComponent(appName, Component)), and the value is an instantiated RCT RootView/ReactRootView.
After the app is started, it is initialized in advance. Before entering the RN container, it reads the container pool. If there is a matched container, it directly uses it. If there is no matched container, it is initialized again.
Write two simple cases. The following figure shows how to build an RN container pool for iOS.
Code:
@property (nonatomic, strong) NSMutableDictionary<NSString *, RCTRootView *> *rootViewRool;
// Container Pool
-(NSMutableDictionary<NSString *, RCTRootView *> *)rootViewRool {
if (!_rootViewRool) {
_rootViewRool = @{}.mutableCopy;
}
return _rootViewRool;
}
// Cache RCTRootView
-(void)cacheRootView:(NSString *)componentName path:(NSString *)path props:(NSDictionary *)props bridge:(RCTBridge *)bridge {
// initialization
RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
moduleName:componentName
initialProperties:props];
// The instantiation must be loaded to the bottom of the screen. Otherwise, the view rendering cannot be triggered
[[UIApplication sharedApplication].keyWindow.rootViewController.view insertSubview:rootView atIndex:0];
rootView.frame = [UIScreen mainScreen].bounds;
// Put the cached RCTRootView into the container pool
NSString *key = [NSString stringWithFormat:@"%@_%@", componentName, path];
self.rootViewRool[key] = rootView;
}
// Read Container
-(RCTRootView *)getRootView:(NSString *)componentName path:(NSString *)path props:(NSDictionary *)props bridge:(RCTBridge *)bridge {
NSString *key = [NSString stringWithFormat:@"%@_%@", componentName, path];
RCTRootView *rootView = self.rootViewRool[key];
if (rootView) {
return rootView;
}
// Back-to-back logic
return [[RCTRootView alloc] initWithBridge:bridge moduleName:componentName initialProperties:props];
}
Android builds the RN container pool as follows:
Code:
private HashMap<String, ReactRootView> rootViewPool = new HashMap<>();
// Creating a Container
private ReactRootView createRootView(String componentName, String path, Bundle props, Context context) {
ReactInstanceManager bridgeInstance = ((ReactApplication) application).getReactNativeHost().getReactInstanceManager();
ReactRootView rootView = new ReactRootView(context);
if(props == null) {
props = new Bundle();
}
props.putString("path", path);
rootView.startReactApplication(bridgeInstance, componentName, props);
return rootView;
}
// Cache Container
public void cahceRootView(String componentName, String path, Bundle props, Context context) {
ReactRootView rootView = createRootView(componentName, path, props, context);
String key = componentName + "_" + path;
// Put the cached RCTRootView into the container pool.
rootViewPool.put(key, rootView);
}
// Read Container
public ReactRootView getRootView(String componentName, String path, Bundle props, Context context) {
String key = componentName + "_" + path;
ReactRootView rootView = rootViewPool.get(key);
if (rootView != null) {
rootView.setAppProperties(newProps);
rootViewPool.remove(key);
return rootView;
}
// Back-to-back logic
return createRootView(componentName, path, props, context);
}
Each RCTRootView/ReactRootView occupies a certain memory. Therefore, when to instantiate, how many containers to instantiate, how to limit the pool size, and when to clear containers need to be practiced and explored based on services.
3. Native Modules Binding
iOS source code analysis
The iOS Native Modules has three parts. The main part is the _initializeModules function in the middle:
Code:
// RCTCxxBridge.mm
- (void)start {
// Native modules returned by the moduleProvider in initWithBundleURL_moduleProvider_launchOptions when the RCTBridge is initialized
[self registerExtraModules];
// Registering All Custom Native Modules
(void)[self _initializeModules:RCTGetModuleClasses() withDispatchGroup:prepareBridge lazilyDiscovered:NO];
// Initializes all native modules that are lazily loaded. This command is invoked only when Chrome debugging is used
[self registerExtraLazyModules];
}
Let's see what the _initializeModules function does:
Code:
// RCTCxxBridge.mm
- (NSArray<RCTModuleData *> *)_initializeModules:(NSArray<Class> *)modules
withDispatchGroup:(dispatch_group_t)dispatchGroup
lazilyDiscovered:(BOOL)lazilyDiscovered
{
for (RCTModuleData *moduleData in _moduleDataByID) {
if (moduleData.hasInstance && (!moduleData.requiresMainQueueSetup || RCTIsMainQueue())) {
// Modules that were pre-initialized should ideally be set up before
// bridge init has finished, otherwise the caller may try to access the
// module directly rather than via `[bridge moduleForClass:]`, which won't
// trigger the lazy initialization process. If the module cannot safely be
// set up on the current thread, it will instead be async dispatched
// to the main thread to be set up in _prepareModulesWithDispatchGroup:.
(void)[moduleData instance];
}
}
_moduleSetupComplete = YES;
[self _prepareModulesWithDispatchGroup:dispatchGroup];
}
According to the comments in _initializeModules and _prepareModulesWithDispatchGroup, the iOS initializes all Native Modules in the main thread during JS Bundle loading (in the JSThead thread).
Based on the previous source code analysis, we can see that when the React Native iOS container is initialized, all Native Modules are initialized. If there are many Native Modules, the startup time of the Android RN container is affected.
Android source code analysis
For the registration of Native Modules, the mainApplication.java entry file provides clues:
Code:
// RCTCxxBridge.mm
- (NSArray<RCTModuleData *> *)_initializeModules:(NSArray<Class> *)modules
withDispatchGroup:(dispatch_group_t)dispatchGroup
lazilyDiscovered:(BOOL)lazilyDiscovered
{
for (RCTModuleData *moduleData in _moduleDataByID) {
if (moduleData.hasInstance && (!moduleData.requiresMainQueueSetup || RCTIsMainQueue())) {
// Modules that were pre-initialized should ideally be set up before
// bridge init has finished, otherwise the caller may try to access the
// module directly rather than via `[bridge moduleForClass:]`, which won't
// trigger the lazy initialization process. If the module cannot safely be
// set up on the current thread, it will instead be async dispatched
// to the main thread to be set up in _prepareModulesWithDispatchGroup:.
(void)[moduleData instance];
}
}
_moduleSetupComplete = YES;
[self _prepareModulesWithDispatchGroup:dispatchGroup];
}
Since auto link is enabled in React Native after 0.60, the installed third-party Native Modules are in PackageList. Therefore, you can obtain the modules of auto link by simply gettingPackages().
In the source code, in the ReactInstanceManager.java file, createReactContext() is run to create a ReactContext. One step is to register the registry of nativeModules.
Code:
// ReactInstanceManager.java
private ReactApplicationContext createReactContext(
JavaScriptExecutor jsExecutor,
JSBundleLoader jsBundleLoader) {
// Registering the nativeModules Registry
NativeModuleRegistry nativeModuleRegistry = processPackages(reactContext, mPackages, false);
}
According to the function invoking, we trace the processPackages() function and use a for loop to add all Native Modules in mPackages to the registry:
Code:
// ReactInstanceManager.java
private NativeModuleRegistry processPackages(
ReactApplicationContext reactContext,
List<ReactPackage> packages,
boolean checkAndUpdatePackageMembership) {
// Create JavaModule Registry Builder, which creates the JavaModule registry,
// JavaModule Registry Registers all JavaModules to Catalyst Instance
NativeModuleRegistryBuilder nativeModuleRegistryBuilder =
new NativeModuleRegistryBuilder(reactContext, this);
// Locking mPackages
// The mPackages type is List<ReactPackage>, which corresponds to packages in the MainApplication.java file
synchronized (mPackages) {
for (ReactPackage reactPackage : packages) {
try {
// Loop the ReactPackage injected into the application. The process is to add the modules to the corresponding registry
processPackage(reactPackage, nativeModuleRegistryBuilder);
} finally {
Systrace.endSection(TRACE_TAG_REACT_JAVA_BRIDGE);
}
}
}
NativeModuleRegistry nativeModuleRegistry;
try {
// Generating the Java Module Registry
nativeModuleRegistry = nativeModuleRegistryBuilder.build();
} finally {
Systrace.endSection(TRACE_TAG_REACT_JAVA_BRIDGE);
ReactMarker.logMarker(BUILD_NATIVE_MODULE_REGISTRY_END);
}
return nativeModuleRegistry;
}
Finally, call processPackage() for real registration:
Code:
// ReactInstanceManager.java
private void processPackage(
ReactPackage reactPackage,
NativeModuleRegistryBuilder nativeModuleRegistryBuilder
) {
nativeModuleRegistryBuilder.processPackage(reactPackage);
}
As shown in the preceding process, full registration is performed when Android registers Native Modules. If there are a large number of Native Modules, the startup time of the Android RN container will be affected.
Optimization Suggestions
To be honest, full binding of Native Modules is unsolvable in the existing architecture: regardless of whether the native method is used or not, all native methods are initialized when the container is started. In the new RN architecture, TurboModules solves this problem (described in the next section of this article).
If you have to talk about optimization, you have another idea. Do you want to initialize all the native modules? Can I reduce the number of Native Modules? One step in the new architecture is Lean Core, which is to simplify the React Native core. Some functions/components (such as the WebView component) are removed from the main project of the RN and delivered to the community for maintenance. You can download and integrate them separately when you want to use them.
The main benefits of this approach are as follows:
The core is more streamlined, and the RN maintainer has more energy to maintain main functions.
Reduce the binding time of Native Modules and unnecessary JS loading time, and reduce the package size, which is more friendly to initialization performance. (After the RN version is upgraded to 0.62, the initialization speed is doubled, which is basically thanks to Lean Core.)
Accelerate iteration and optimize development experience.
Now that Lean Core's work is almost complete, see the official issue discussion section for more discussion. We can enjoy Lean Core's work as long as we upgrade React Native.
4. How to optimize the startup performance of the new RN architecture
The new architecture of React Native has been skipping votes for almost two years. Every time you ask about the progress, the official response is "Don't rush, don't rush, we're doing it."
​I personally looked forward to it all year last year, but didn't wait for anything, so I don't care when the RN will update to version 1.0.0. Although the RN official has been doing some work, I have to say that their new architecture still has something. I have watched all the articles and videos on the new architecture in the market, so I have an overall understanding of the new architecture.
Because the new architecture has not been officially released, there must be some differences in details. The specific implementation details will be subject to the official React Native.
JSI
The full name of JSI is JavaScript Interface, a framework written in C++ that allows JS to call native methods directly instead of communicating asynchronously through Bridge.
How do I understand how JavaScript directly invokes Native? Let's take a simple example. When an API such as setTimeout document.getElementById is invoked on a browser, Native Code is directly invoked on the JavaScript side. You can verify the function on the browser console.
For example, I executed an order:
Code:
let el = document.createElement('div')
The variable el does not hold a JS object, but an object that is instantiated in C++. For the object held by el, set the following attributes:
Code:
el.setAttribute('width', 100)
In this case, JS synchronously invokes the setWidth method in C++ to change the width of the element.
The JSI in the new architecture of React Native is used for this purpose. With the JSI, we can use JS to directly obtain the reference of C++ objects (Host Objects), control the UI, and directly invoke methods of Native Modules, saving the overhead of bridge asynchronous communication.
Let's take a small example of how Java/OC uses JSI to expose synchronous invocation methods to JS.
Code:
#pragma once
#include <string>
#include <unordered_map>
#include <jsi/jsi.h>
// SampleJSIObject inherits from HostObject and represents an object exposed to JS
// For JS, JS can directly invoke the properties and methods on the object synchronously
class JSI_EXPORT SampleJSIObject : public facebook::jsi::HostObject {
public:
// The first step
// Exposes window.__SampleJSIObject to JavaScript
// This is a static function that is generally called from ObjC/Java during application initialization
static void SampleJSIObject::install(jsi::Runtime &runtime) {
runtime.global().setProperty(
runtime,
"__sampleJSIObject",
jsi::Function::createFromHostFunction(
runtime,
jsi::PropNameID::forAscii(runtime, "__SampleJSIObject"),
1,
[binding](jsi::Runtime& rt, const jsi::Value& thisVal, const jsi::Value* args, size_t count) {
// Returns the content of a call to window.__SampleJSIObject
return std::make_shared<SampleJSIObject>();
}));
}
// Similar to a getter, this method is used each time the JS accesses the object. The function is similar to a wrapper
// For example, if we call window.__sampleJSIObject.method1(), this method will be called
jsi::Value TurboModule::get(jsi::Runtime& runtime, const jsi::PropNameID& propName) {
// Invoking method name
// For example, when window.__sampleJSIObject.method1() is called, propNameUtf8 is method1
std::string propNameUtf8 = propName.utf8(runtime);
return jsi::Function::createFromHostFunction(
runtime,
propName,
argCount,
[](facebook::jsi::Runtime &rt, const facebook::jsi::Value &thisVal, const facebook::jsi::Value *args, size_t count) {
if (propNameUtf8 == 'method1') {
// Function processing logic when method1 is invoked
}
});
}
std::vector<PropNameID> getPropertyNames(Runtime& rt){
}
}
The above example is short. To learn more about JSI, read the React Native JSI Challenge article or read the source code directly.
TurboModules
According to the previous source code analysis, in the current architecture, native modules are fully loaded during native initialization. As services are iterated, the number of native modules increases, which takes a longer time.
TurboModules solves this problem all at once. In the new architecture, native modules are loaded in lazy mode. That is, the loading is initialized only when you invoke the corresponding native modules. This solves the problem that initializing full loading takes a long time.
The calling path of TurboModules is as follows:
Use JSI to create a top-level Native Modules Proxy, which is called global.__turboModuleProxy.
Access a Native Module. For example, to access the SampleTurboModule, execute require('NativeSampleTurboModule') on the JavaScript side.
In the NativeSampleTurboModule.js file, we call TurboModuleRegistry.getEnforcing() and then call global.__turboModuleProxy("SampleTurboModule").
When global.__turboModuleProxy is invoked, the Native method exposed by the JSI in step 1 is invoked. In this case, the C++ layer finds the ObjC/Java implementation through the input string "SampleTurboModule". Finally, a corresponding JSI object is returned.
Now that we have the JSI object of SampleTurboModule, we can use JavaScript to synchronously invoke the properties and methods of the JSI object.
Through the preceding steps, we can see that with TurboModules, Native Modules are loaded only when they are invoked for the first time. This completely eliminates the time required for fully loading Native Modules during initialization of the React Native container. In addition, we can use JSI to implement synchronous invoking of JS and Native, which takes less time and improves efficiency.
Summary
This document analyzes the startup process of the existing architecture of React Native from the perspective of Native and summarizes the performance optimization points of the Native layer. Finally, we briefly introduce the new architecture of React Native. In the next article, I'll explain how to start with JavaScript and optimize React Native's startup speed.
By Halogenated Hydrocarbons
Original Link: https://segmentfault.com/a/1190000039797508
is RN container same as google map?

Categories

Resources