The 10 most common problems on Android

[[156039]]

Here are the most common React native android related cases.

1. After the app is started, the red interface shows "unable to load jsbundle"

Solution: Generally speaking, you are using the dev-serve method, and your server is not correctly matched. If you are running on a mobile phone, the PC and the mobile phone need to be on the same wifi, and the menu-ip must be set to the PC's ip through the menu key. If it is an emulator, you do not need to manually set the ip. If you do, an error will occur.

2. After the app is started, the red interface shows unRegisteredProject

• What is the prompt? Your app is not registered at startup.
• Solution: This is also an obvious error, which is the one written at the bottom of your index.android.bundle
• 'componetNameInYourLocalProject' is not called this name in your Java code, check it yourself and you can fix it immediately AppRegistry.registerComponent('componetNameInYourLocalProject', () => JSObjAndroid);

3.Require("xxx") component failed

• Sometimes require("xxx") components will appear in js code. Solution: Check whether the node component exists on your server. If it is a NativeModule encapsulated by yourself, you can use it directly.
• var CustomMoudle = React.NativeModules.YourCustomModule CustomMoudle.yourMethodDeclearInYourNative('someparms');

4. Debugging

• Solution: You can use the debug tool of Chrome on the PC to debug the js side. For native debugging, you can only use logcat to track. Currently, most of the errors are caused by your own code. ReactAndroid itself has fewer crashes.

5.so library problem

• For gradle, you can control it through ndk filter: android { defaultConfig { ndk { abiFilters "x86", "armeabi-v7a" } }
• For maven, you can manually solve the problem by copying so under libs.
• There is a big pitfall here. The jsc.aar imported by default has an armabi folder, but no jsc.so in it. This causes ndk to report errors when encoding source code in multiple places.

6. About device MinSdkVerison

• By default, Android 4.1 or higher devices are required (4.0 accounts for about 0.7% according to network data. As most apps no longer support devices below 4.0, this is acceptable)
• At the beginning, I always used a 5.0 device for ReactAndorid testing and development. Later, I found that it would be more efficient to use a 5.0+ genymotion emulator for joint debugging.

7. UIExplorer demo issue

• Before, I had been looking at the specific access and code implementation. When I look back at the bulk of the work, I realized that if I had started with the UIExploror, the efficiency and progress would have been greatly improved.
• This requires compiling the react source code. If you encounter the problem https://github.com/facebook/react-native/issues/3976, you can use the method I replied below to hook, but the fundamental reason is still the problem of armabi jsc.so
  

8. Capability coverage

• Based on the team's previous experience with React iOS, following the main code and relying on the UI components provided by RN itself can meet most business scenarios.
• Of course, if you want to reuse what the previous team has accumulated, the workload itself is not too large in conjunction with UIManager and UIModule.
• However, the protocol interface should be kept consistent with the team's future JS and iOS terminals as much as possible, so that the significance of React*** can be brought into play, "lean once run everywhere"

9. Data Security

• Before 0.14, only dev-pc and assert methods were supported. Starting from version 0.14.0 realease, local file patch loading method is supported, and the latest version is 0.15.1.
• Because if dynamic capabilities are required, js must be sent from the network end, and js itself is plain text (even if JS is obfuscated), data anti-hijacking protection must still be done, which can be done with https anti-tampering + sign verification

10. Impact of JNI message training

• Due to the communication limitations of JNI, the communication between the Java layer and Native is one-way, and in order to ensure the 16ms rendering frequency of RN, all Java-Native-jscore layer communications are asynchronous, which may be a performance issue for the UI rendering of the JAVA layer.
• When the message volume is very large or the Listview page is very complex, the rendering of each layer of Cell requires continuous drawing of the UI thread using the Css-ScrowllerView model. There may be performance issues for the waterfall flow listview, but this problem itself is definitely better than the H5 experience.