ReactNative’s practice and Exploration in the game Marketing scene – Background brief

Author: Xiong Wenyuan, Byte Game Client team

Client cross-end frameworks have been developed for many years. Recently popular aprons, Flutter and ReactNative are all successful and mature frameworks, which are targeted at different developers and widely used by many large apps. I was fortunate to participate in learning and using these excellent cross-end solutions early. In recent years of development and architecture design, in addition to supporting tens of millions of DAU in the App, ReactNative cross-terminal scheme was gradually applied to the game to improve the efficiency of development and iteration. In this article, we are going to introduce some of our explorations and practices in games in five chapters, which you can learn from:

• Part 1: Background on using ReactNative in games
• How to integrate ReactNative into a game
• ReactNative performance optimization in games
• ReactNative Hermes Engine Introduction
• Chapter 5: Introduction to ReactNative’s new architecture

(This is the first in a series)

ReactNative is a popular cross-terminal solution, currently supporting Android, iOS, Windows and other platforms, which can solve the problems of manpower and dual-terminal unity in development. It supports hot update and can be online anytime and anywhere. When it comes to ReactNative, people will certainly compare with Flutter. Flutter is also a universal cross-end framework. Both of them have their own advantages and disadvantages, and there are many discussions about Flutter. How we developed some active pages using ReactNative.

ReactNative, as a cross-end framework, is widely used in native apps, from Foreign Facebook to various domestic manufacturers. Moreover, there are many cross-end frameworks based on this design idea, such as WEEX, etc., but it is seldom used in games. The main reason is that the development and operation principle of the game is too different from the original. At present, there are many kinds of game operating environments, mainly Unity, Cocos and UE4. These game platforms have the ability to cross mobile platforms, support Android, iOS and other devices, and have hot update ability.

Many rapid iteration in the native App development page of H5 development has been adopted, the main integration, to develop simple, are more similar to the game, the H5 page did multi-platform support at the same time, but the response speed, start, speed, memory and other performance indicators will seem a bit less, but it’s hard to do in the game environment immersive experience. Therefore, the industry has made a lot of solutions to solve the problems of rapid iteration, release, high performance, and immersive experience. Referring to and learning from these experiences, we also did a lot of comparative tests, and finally selected ReactNative as the basic engine in the early solution.

Introduction to game Environment

• Self-rendering engine: Now games are generally based on OpengL design, self-built UI rendering engine, UI content updated to the native surface to display, so there is a big difference with the native UI component system, the native system component is no longer applicable, and the whole game is an Activity on Android device. In addition, the game’s self-rendering engine provides many animation attributes that allow for high-quality animation and immersive experiences that are not shared on the native side.
• Development language differences: There are also great differences in the development language (such as Unity C#/Lua, etc.), different from Android and iOS system development language and IDE, relatively few developers are involved in this aspect, which also limits the use of many native frameworks in the game, of course, the game also needs to access some resources of the device. This is often referred to as bridge. The game calls the system or the API provided by the developer through the bridge, but the UI cannot be directly shared. Although there are some texture sharing schemes on the Internet to get through the game and the native UI, there are still great limitations in the use
• High performance requirements: Compared with APP, the game has higher requirements on picture quality and rendering performance, which also leads to high memory and CPU consumption. It has strict requirements on access services, page memory peak value and stable value. It is best to release the game when exiting the page
• Hotfix: Games generally support hotfix, such as Unity, which itself supports JavaScript and Lua development, so there is Unity +Lua hotfix, and many activities or game business will use hotfix and dynamic entry, reduce the size of the installation package, improve flexibility
• Complex supporting devices: In addition to common Android and iOS platforms, the running environment of the game also includes PC and Android emulators, so the compatibility and experience requirements are higher than those of common apps. The test found that the existing Android emulators generally adopt x86 architecture and support 32 and 64 bits, while mobile devices are generally ARM V7 and V8. Although the emulators also support COMPATIBLE modes of V7 and V8, they are completed by converting ARM to Intel instructions. There are many compatibility problems in actual measurement, and it is quite difficult to support

Choose ReactNative

From the data in the game, except for the core of the game itself, some activities and functions need to be rapidly iterated, so the game uses a lot of H5 activity scenes, and provides a lot of API and data capabilities for the game, but there is still a big gap with the game in memory, performance and immersive experience. Also because of difference of game, H5 and primary side solution, native UI components cannot be used directly in the game, need to develop, this is similar to Flutter, so in order to better compatible with native side some ability, scenarios, choose UI interactions, across different platforms can support system, we choose priority conditions. From a technical point of view, there are in-game solutions and there are client-side solutions. When considering the options, we mainly consider the following issues:

1. The game has many different platforms, and the development language is not consistent, the adoption of in-game plan, will involve the maintenance of multiple sets of engines, it is difficult to achieve the unity of the architecture, such as xLua, PureTS and other popular
2. There are many popular cross-platform solutions for clients. The H5 page mentioned above can well solve cross-platform problems, which is also the solution adopted by many game activities at present. However, due to the difference between its performance and experience and the native client, ReactNative, which is open source by Facebook, was developed later. It does a great job of supporting the unified native experience and greatly improving performance, leading the big front end wave. Flutter, which is now developing rapidly, has been gradually adopted by many big factory apps with its self-rendering engine and UI consistency. In addition, domestic suppliers have also proposed their own cross-end solution Weex, which is similar to ReactNative in principle.

Why didn’t we choose Flutter and Weex as our cross-end engines? Comparatively, the engineering of Flutter is more complex and overall, and it is difficult to adapt to the scene where game and activity business are developed separately. Weex is also not within our perspective due to the ecological gap between WeeX and ReactNative. In addition, xLua+Unity in the game terminal and pureTS, which has been open source by Tencent, are also widely used in the industry. We also made a comparative analysis together:

Among them, xLua and PureTS adopt UI rendering in the game end, which is relatively mature in the game. The reason why they are not within the scope of our early evaluation is as follows: It is not a bad scheme, but not suitable. Of course, the application of ReactNative end scheme also has limitations, such as UI cannot be mixed with the game. This is also the reason why PureTS solution has been continuously iterated after ReactNative was built. The specific principle will not be explained here. This is an open source project, and the principle is not complicated:

1. Both use game UI components, developers must have a deep understanding of the design and architecture of the game itself, more suitable for the team with rich experience in game development, and we are the client team
2. These solutions are all designed for a certain game platform, and are not specific about the Unity of the whole platform. They need to be adapted to support Cocos, Unity, UE4 and other platforms, resulting in high maintenance costs
3. It is difficult to reuse many of the client’s complex components, such as maps, livestreaming, maps, etc., which are not supported in the game, and of course these solutions are also difficult to support

ReactNative is not the best choice. Compared with the recent rapid development of Flutter, ReactNative is far inferior. There has been little progress in the past two years, and its development is increasingly restricted by the bottleneck of rendering performance. Many developers have announced that they will no longer develop and maintain ReactNative, but will switch to native development or the embrace of Flutter. However, we still firmly choose ReactNative and are more optimistic about its future architecture development. For details, you can refer to my article “Cook up Electricity! In-depth Analysis of React Native Next-generation Architecture Reconfiguration”. In the following chapters, I will also focus on the features of the new architecture.