Architecture evolution of Ele. me mobile APP

0 the introduction

As times evolve, so does technology. Today, APP has become the core channel used by most Internet enterprises to acquire users. At the same time, with the growth of business volume, more and more APPS are constantly and continuously challenging the depth of knowledge of every mobile terminal developer, and our mobile terminal technicians have achieved today’s mobile Internet era in the process of constantly accepting challenges. Ele. me mobile APP is such a challenge. With multiple users and multiple business volumes, it is silently evolving the mobile terminal architecture while accepting more and more picky users.

1 MVC

We often say that leaving business to talk about architecture is pure brush rogue. The development of ele. me’s mobile APP is also a mirror of its business development.

In the early stage of ele. me’s business development, mobile APP experienced a stage from scratch. In order to quickly go online and seize the market, the MVC architecture of traditional mobile APP development has become the first choice of “short and smooth” thinking:

This architecture is accepted by most people for its simple and clear hierarchy and easy code development.

In the MVC architecture, the Controller layer is responsible for the realization of the main logical functions in the entire APP. The Model layer is responsible for the description of data structure and data persistence. The View layer, as the presentation layer, is responsible for rendering the UI of the entire APP. The division of labor is clear and concise; And this system architecture is supported by Apple in the language framework layer, so it is very suitable for startup development of APP.

Later in development, however, this architecture will result in a huge Controller layer due to its high coupling and capability, which is always criticized. The final MVCS all went from model-view-Controller to Massive view-Controller.

2 Module Decoupled

The MVC architecture of “short, flat and fast” helped Ele. me mobile APP seize the market quickly. As the amount of code increases, so does the bloated Controller layer; In terms of business, Ele. me mobile APP has also developed from a single APP to multiple apps. At this point, reusing existing modules becomes an architectural priority if coupling is reduced.

In architecture, the first requirement of module reuse is the functional componentization of code. Componentization means that code with independent functions is abstracted and stripped from the system, and then inserted back into the original system as “plug-ins”. In this way, the stripped functional components can be used by other apps, thus reducing the decoupling between modules in the system; It also improves the reuse of code between apps.

Ele. me Mobile has two definitions for components: public components and business components. Public components are SDKS that are packaged well, including third-party components and components for internal use. For example, AFNetworking, the most famous network SDK in iOS, and OKHttp under Android are representatives of such components. For a business component, it is defined as a whole that contains a series of business functions, such as logging in to a business component and registering a business component, which are typical representatives of such components.

For public components, Ele. me Mobile adopts versioning management mode, which has mature solutions on iOS and Android platforms. For example, on iOS, CocoaPods is almost standard for componentized code management; Gradle is also a very mature and robust solution on the Android platform. Another reason to use the above management tools is that code is also a trade secret for enterprise development. For the purpose of confidentiality, it is necessary to support Intranet to set up private servers. These operations are well supported by the above management tools.

For the componentization of business, we take the way of business module registration mechanism to achieve the purpose of decoupling. Each business module provides the corresponding business interface and registers its own module Scheme with Excalibur system when the system is started. Excalibur moves the system used to store the mapping between Scheme and module, and can also reflect the Class back according to Scheme. When other business modules are dependent on this business module, the related instance is obtained from Excalibur system and the corresponding interface is invoked to realize the invocation, so as to realize the decoupling between business modules.

Inside business components, or business modules, different code architectures can be implemented according to the preferences of different developers. Such as MVVM, MVP, etc., which are discussed very popular now, can be carried out within the module without affecting the overall system architecture.

The architecture looks more like this:

The E(Excalibur)M(Modules)C(Common) architecture is characterized by high cohesion and low coupling. It takes interface programming as the starting point and reduces the connection between Modules.

Another benefit of this architecture is that it resolves compatibility issues between different system versions. Here, take the WebView of iOS platform as an example. Apple provided a better Web support framework — WebKit from iOS8, but it was not compatible with iOS7, resulting in Crash. With this architecture, you can still register the traditional WebView to render web pages in iOS7, and register WebKit as the kernel for rendering web pages in iOS8 and above. It avoids Apple’s strict audit mechanism and achieves the purpose of dynamic loading.

3 Hybrid

There are two different routes of mobile APP development, Native APP and Web APP. The difference between the two approaches is similar to the C/S and B/S architectures of developing applications in the PC era.

All the above mentioned are typical Native apps, that is, all the programs are rendered by local components. The advantages of such apps are obvious, such as fast rendering speed and good user experience. The disadvantages are also significant: errors must wait for the next APP update before being fixed.

The advantages of Web APP are exactly the disadvantages of Native APP. Its pages are all written in H5 and stored on the server side. The latest page is requested from the server every time a page is rendered. As soon as the page has an error, the server side updates it immediately. However, its disadvantages are also easy to see: each page needs to request the server, resulting in a long waiting time for rendering, resulting in imperfect user experience, and the performance is 1-2 orders of magnitude slower than Native APP. At the same time, it will lead to more user traffic consumption. Another disadvantage is that it is inconvenient for Web Apps to call local hardware devices on mobile. PhoneGap packs web pages locally in advance to reduce network request times. It also provides a series of plug-ins to access local hardware devices. However, despite this, there is still a slight gap in rendering speed.

Hybrid APP is a solution that combines the advantages and disadvantages of both. Ele. me Mobile’s view of this type of APP is that purely display modules are more suitable for Web pages to achieve the purpose of rendering; However, modules with more data operability and animation are more suitable to adopt Native mode.

Based on the previous EMC architecture, we re-architecting some modules:

In hybrid-EMC architecture, Web, as a sub-module, is registered and added to the whole system, so as to achieve the effect of real-time update for modules that need rapid iteration in business.

4 React-Native & Hot Patch

After years of business development, the display interface update scheme provided by Hybrid gradually fails to meet the needs of APP update iteration. Therefore, more and more dynamic deployment solutions have been proposed, such as JSPatch and waxPatch in iOS, Dexpose,AndFix and ClassLoader in Android, all of which are relatively mature dynamic deployment solutions for Hot Patch. The idea is to dynamically update local code behavior by downloading code from a remote server.

React-native is another dynamic deployment solution, whose core principle is to call local components through JavaScript for interface rendering.

While ele. me mobile APP development to today, each APP comprehensive user number has exceeded 100 million. So even a very small Bug can directly affect tens of thousands of people. In order to ensure the stability and robustness of APP, Hot Patch has become the most pending problem.

Based on the 80/20 principle that 80% of users visit 20% of the pages, ensuring the stability of the 20% most frequently visited pages guarantees the stability of 80% of the APP. Therefore, Ele. me Mobile makes a React-native backup for some of the most frequently accessed modules. When problems occur in this part of the page, the APP can automatically switch to the React-Native backup page through the configuration of the server. At the same time, the developer developed a small but refined Hot Patch to fix the problems. After Hot Patch is repaired, switch back to the Native function of the Native APP.

The architecture would look something like this:

The hotPatch-EMC architecture is designed to address the stability of mobile apps. Through the primary and standby of RN and Native, the error cost caused by system APP error can be reduced.

5 conclusion

As we all know, there is no silver bullet when it comes to software engineering. It is also very applicable to architecture. Continuous business updates have led to the evolution of ele. me mobile APP architecture.

Architecture is not really good or bad, as long as it works for your business, it is good architecture!