Are you hungry? Evolution of mobile App architecture

0 Introduction

The evolution of the Times and the development of technology. Today, apps have become the core channel for most Internet companies to get users. At the same time, as the volume of business grows, the growing and increasing number of apps is constantly and continuously challenging the depth of knowledge of every mobile developer, and our mobile technicians are in the process of continuing to embrace the challenges that have made today's mobile internet era. Are you hungry? Mobile app is such a challenge, multi-user volume, multi-service, in the acceptance of more and more critical users, while silently, constantly evolving the mobile-side architecture.

• Home
• All articles
• Industry News
• iOS development
• Swift Development
• Product Promotion
• Product design
• I want to contribute
• More channels

Bole Online >ios-Bó Lè online > All articles > IOS development > Hungry Mobile App Architecture evolution is hungry? Architecture evolution of mobile apps

2016/03/07 · iOS Development · Architecture

Share to:6Source: Saint Dizier (@Cendy_ saint Dizier) 0 introduction

The evolution of the Times and the development of technology. Today, apps have become the core channel for most Internet companies to get users. At the same time, as the volume of business grows, the growing and increasing number of apps is constantly and continuously challenging the depth of knowledge of every mobile developer, and our mobile technicians are in the process of continuing to embrace the challenges that have made today's mobile internet era. Are you hungry? Mobile app is such a challenge, multi-user volume, multi-service, in the acceptance of more and more critical users, while silently, constantly evolving the mobile-side architecture.

1 MVC

We often say that out of business talk about architecture is pure brush rogue. Are you hungry? The development of mobile apps is also a mirror of its business development.

In the early days of a hungry business, mobile apps went from scratch. In order to seize the market quickly, traditional mobile app development of the MVC frame constitutes the "fast track approach" idea of the first choice:

Figure 1 MVC Architecture

This architecture is simple and clear in its hierarchy, and the code is easily developed and accepted by most people.

In the MVC architecture, the controller layer is responsible for the implementation of the main logical functions of the entire app; The model layer is responsible for the description of the data structure and the function of the persistence, while the view layer is responsible for rendering the entire app's UI as the presentation layer. The Division of labor is clear and concise, and this system architecture is supported by Apple at the language framework level, so it is well suited for startup development of apps.

Then, this architecture in the late development due to its ultra-high coupling and nature, so as to create a large controller layer, which has been criticized by people. The final MVC went from Model-view-controller to the end of Massive-view-controller.

2 Module decoupled

The MVC architecture of "Fast track approach" helps hungry mobile apps quickly grab the market. And as the code volume continues to increase, the bloated controller layer is also in the emerging corner, and business, Hungry mobile app also from a single app developed into a multi-app landscape. In this case, if the coupling is reduced, reusing the existing modules becomes the first priority of the architecture.

In architecture, the first requirement of module reuse is the functional component of code. Component means that code with independent functionality is abstracted and stripped from the system, and then plugged back into the original system as a "plug-in". This stripped-down functional component can be used by other apps to reduce the decoupling and interoperability between modules and modules in the system, while also improving the reusability of code between apps.

Are you hungry? There are two definitions for a component: public components and business components. Public components refer to some of the more well-packaged SDKs, including some third-party components and components that are used internally. Such components are represented by Okhttp, the most famous network SDK in iOS, afnetworking,android. For business components, it is defined as a whole that contains a series of business functions, such as logging into business components and registering business components, which are typical representatives of such components.

For public components, hungry Mobile has a versioned management approach, and this is a relatively mature solution on iOS and Android platforms. For example, for the iOS platform, Cocoapods is basically the standard for code-component management, and Gradle is a very mature and robust solution on Android platforms. Another reason for using the above management tools is that code is also a trade secret for enterprise development. Based on the purpose of confidentiality, it is necessary to support private server building in intranet. These operations are well supported by the above management tools.

For the component of the business, we adopt the method of the business module registration mechanism to achieve the purpose of decoupling. Each business module provides the corresponding business interface to the outside, while the scheme of registering its own module to the Excalibur system when the system is started (Excalibur is hungry, moving the system to save the mapping between scheme and module, Can also be returned by class reflection according to scheme). When other business modules are dependent on the business module, the relevant instances are obtained from the Excalibur system, and the corresponding interfaces are invoked to implement the decoupling purpose of the business modules.

In the case of business components, which are internal to the business module, different code architectures can be implemented according to the preferences of different developers. As now discussed in the fire of the MVVM, MVP, etc., can be carried out within the module without affecting the overall system architecture.

This time the architecture looks more like this:

Figure 2 EMC Architecture

This e (Excalibur) M (Modules) C (Common) architecture, with high cohesion and low coupling as the main feature, takes the interface programming as the starting point and reduces the connection between modules and modules.

Another big benefit of this architecture is that it addresses compatibility issues with different system versions. This is illustrated here as an example of WebView under the iOS platform. Apple has provided a better Web support framework--webkit from the iOS8 system, but it is not compatible under IOS7 systems, resulting in crash. With this type of architecture, you can still register with the traditional WebView to render the Web page under the IOS7 system, while the iOS8 and above systems register WebKit as the kernel to render the Web page. This avoids the strict audit mechanism of Apple, and achieves the purpose of dynamic loading.

3 Hybrid

There are two different routes for mobile app development, Native app and web App. The difference between the two routes is similar to the C/s architecture and B/s architecture when developing applications in the PC era.

All we've talked about is a typical native APP, where all the programs are rendered by local components. The advantages of this kind of app are obvious, the rendering speed is fast, the user experience is good, the disadvantage is also very prominent: there is an error must wait for the next user to update the app to be able to repair.

The advantage of the Web app is precisely the disadvantage of native app, its pages are all written in H5 and stored on the server side. The latest page is requested from the server each time the page is rendered. Once the page has the wrong server side to update it can be resolved immediately. But its drawbacks are also easy to see: Each page needs to request the server, resulting in a long wait time for rendering, resulting in the user experience is not perfect, and the performance of the native app is 1-2 times slower than the number of orders, while also causing more user traffic consumption. Another drawback is that the Web app has some inconvenience in calling the local hardware device on the mobile side. However, these drawbacks also have a corresponding solution, such as PhoneGap the Web page in advance to reduce the network request time, but also provide a series of plug-ins to access local hardware devices. However, there is still a slight gap in the rendering speed.

The Hybrid app is a solution that combines the pros and cons of both. Are you hungry? Mobile for this two-class app, the idea is that purely display modules will be more suitable for the use of Web pages to achieve the purpose of rendering, while more data manipulation, animation rendering of the module is more suitable for the use of native way.

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

Figure 3 HYBRID-EMC Architecture

HYBRID-EMC architecture, the web as a sub-module, register to join the entire system, so that the business needs to quickly iterate over the module to achieve real-time update effect.

4 React-native & Hot Patch

After years of business development, Hybrid offers a display interface update solution that is gradually unable to meet the needs of the app update iteration. As a result, more and more dynamic deployment scenarios have been raised, such as Jspatch under iOS, Waxpatch,android Dexpose,andfix, ClassLoader, are all relatively mature hot patch dynamic deployment solutions. The idea of these scenarios is to dynamically update local code behavior by downloading the remote server's code.

React-native is another dynamic deployment scenario, with the core principle of invoking native components for rendering interface through JavaScript.

And hungry? Mobile app development today, the total number of users of various apps has been billions. Therefore, the problem of a very small bug can directly affect the use of tens of thousands of people. In order to ensure the stability and robustness of the app, the hot patch solution is now the most unsolved problem.

Based on the 80/20 principle that 80% of users access the 20% page, the stability of the 20% most visited pages is guaranteed to be the stability of the 80% app. So, hungry? The move is a react-native backup of some of the most frequently accessed modules. When this part of the page has a problem, the app can automatically switch to React-native's backup page via the server's configuration, while the developer develops a small and refined hot patch to fix the problem. When the hot patch is patched, switch back to the native feature of the native app.

The architecture looks like this:

Figure 4 HOTPATCH-EMC Architecture

The main goal of HOTPATCH-EMC's architecture is to solve the stability problem of mobile apps. With the main preparation of Rn and native, we can reduce the cost of errors caused by System app errors.

5 Conclusion

As we all know, there is no silver bullet in this world for software engineering. In fact, the architecture is also very applicable. The continuous updating of the business has brought a hungry mobile app architecture to evolve.

Architecture is not really good or bad points, as long as the application of their own business, is the best architecture!

Hungry? Evolution of mobile app architecture