How to "spell out" a page-Game Center Modular Practice

1. Background

Vivo Game Center is a vertical application store that provides users with diversified game download channels. With the enrichment of the game center mobile game categories, the magnitude of users in each category is also increasing, and the core concerns of users with different game preferences are also different. From appointment, testing, first release, update to maintenance, the operation needs of different game life cycle nodes The salient points are different.

In view of the above-mentioned different business scenarios, in order to serve the vast number of vivo game users, operators need to perform refined operations and present them to different users in different visual styles. For example, for users in the independent game category, if the platform provides activities, strategy and other content, it can promote users to download and consume more. Activities, strategies and other content are presented in different visual styles, and the operation needs to verify the effect through experiments to determine the final delivery plan. These requirements need to be re-developed. Limited by the long release time of the game center APP, the expected effect of operation is often not good.

Therefore, we hope that the system has the following capabilities: through the abstraction and reuse of different visual styles, quickly and flexibly adjust the page layout, deliver to different groups of people, and finally determine the best delivery plan through experiments.

How can these system functions be realized? The answer is modularity. Here is an introduction to the modular practice of the game center.

Second, what is modularity

The so-called modularity, in fact, is a modular design idea, which refers to the ability to analyze the functions of products with the same or different functions, performances, and specifications, and design a series of functional modules.

Customizing products through the various options of modules can meet many different needs of the market. Then the game center modularization is based on the visual style of the same or different functions of the game center, conduct business scenario analysis, and design a series of functional modules. Through the various choices of modules, different pages can be quickly and flexibly built to meet the needs of different users.

Modularization has three capabilities: componentization, configuration and experimentation.

• componentization , that is, the page layout is split into multiple components, and these components are abstracted to achieve the purpose of reuse. Component is a combination of UI style and data. Componentization divides the UI style into independent and reusable areas.
• configuration , that is, through the splicing of different components, you can quickly build various pages. Component is the basic unit that constitutes a page, so each page is composed of several components. The components are abstract, the external output is unified, and the order and position can be flexibly adjusted according to different needs.
• experimental , that is, through the multi-layer test framework and DMP system, different pages can be quickly put on the user's mobile phone with different characteristics, in order to achieve the purpose of multi-version operation. The multi-layer experiment framework is the ABtest framework implemented inside vivo. The DMP system is the data management platform. It can be simply understood as a data pool to receive data from all parties, and then use these after fusion, processing and optimization. data.

As you can see, the three functions correspond to three concepts. Componentization corresponds to components, configuration corresponds to pages, and experimentalization corresponds to solutions. They are the relationship of inclusion, that is, a plan contains several pages, and a page also contains several components.

Before modularization, the homepage of the game center was composed of the top advertising banner, navigation bar, game list and interspersed components. The interspersed component is an advertisement composed of visual styles and data inserted horizontally in the game list for operation and promotion. From the point of view of the definition of interspersed components, it is actually the concept of componentization, but componentization and the game list were distinguished accordingly. The visual style of interspersed components is relatively single, with only topics, videos, hot words, activities, forums, etc. As shown in Figure 1, the editor recommendation, Hot Tour Station, and the first recommendation are interspersed with 1*4 game topics, similar to Jiugongge (eight hot search words) interspersed with hot words.

(Picture 1: Before modularization)

The interspersed components are interspersed in any position of the game list according to certain rules, but the advertising banner and navigation bar are fixed, the layout of the entire page is chaotic, the form is fixed, and it is not easy to change. If the top banner is moved to the bottom recommended by the editor, it can only be solved by publishing. Change the "more" in the upper right corner of the topic to "change for another", or change some games in the game list to the introduction of their content, which also needs to be resolved through the release.

After modularization, the use of componentization capabilities can flexibly adjust the sequence and dynamically change the visual style of the components. Even the game list can also be dynamically configured. Using the sequential arrangement of multiple components, you can quickly build a page.

Through the ABtest framework and the DMP system, different pages can be quickly presented to the corresponding people in the way of placement plans, and multi-version operations can be carried out. Figures 1 and 2 are the recommended comparison diagrams of the front page before and after the modularization. Although there is not much change from the large style, the style before the modularization is relatively single, and after the modularization, the single game big picture and King Kong are arranged in the game list. Position, small speaker, topic, new tour reservation, download list and other components.

(Figure 2: After modularization)

Different components can meet different business scenarios. For example, the single game big picture component, supplemented by recommendations, can quickly promote new and hot games, and meet the needs of different users for different game nodes; the new game reservation component can satisfy users from more perspectives for subscribing to the content or content of a single game in advance. Pay attention to its real-time dynamic needs.

Three, how to achieve modularity

As you can see from the previous introduction, modularization uses componentization to quickly build pages and deliver them to people with different tags. It has powerful functions and flexible configuration, which saves us a lot of development costs. Then our bottom layer How is it achieved?

3.1 Model abstraction and unification

According to the component layout, we can abstract the component into two parts: visual style and data; visual style can be simply understood as UI style, that is, the presentation form presented to the user, we can simply summarize the visual style as a template.

The template defines the most basic form of the current component, such as whether the current component is in the form of a slider or a fixed form; some variable styles are also defined on the template, that is, it defines which positions in the current template can be completed through configuration. For example, the length, width and height of the template, the combination style (2*2, 1*4), the number of lists, etc., can be dynamically configured depending on the definition of the template.

The so-called data is divided into recommended data and manual scheduling data according to the source. The recommended data comes from algorithms and big data, while manual scheduling is configured by the operation in the background. Because the logic behind the recommended data is more complicated, this article only discusses manual scheduling data. Manual scheduling is a four-dimensional data. In addition to the "business nature" of the data itself, it is time-sensitive, and the display of the game center's advertising space is time-limited. For example, the banner at the top of the game center homepage is different from what was displayed today and yesterday; secondly, It is "spatial", that is, different users may see different data; in addition, it is actionable, that is, events generated after clicking. For example, clicking on a component can pop up a floating window or switch to another page.

Therefore, modularity can be simply understood as a combination of templates and manual scheduling. In layman's terms, a component is actually like a class. The different components on each page are the object of the component, and the object will instantiate some data and behaviors. Through componentization, we not only solved the coupling between the end-side and the server-side, but also realized the reuse of components on different pages.

The composition of the scheduling data is divided into three levels (namely, materials, promotional materials, and scheduling). The bottom-level data is of course pictures, videos, testimonials, comments, etc. Of course, game information will also include game icons, background pictures, and simple videos, but the pictures here do not refer to game icons, but are more refined than icons. Material images used to advertise advertisements. This type of data is collectively referred to as material. The upper-level promotional materials are composed of materials.

What are promotional materials? Promotional materials are actually a collection of content displayed in a certain form based on a certain purpose. For example, a banner is actually a picture plus the associated content behind it. The image is to attract users to click, and the purpose is to promote the associated content behind it. Promotional materials plus time, space and action attributes become scheduling. Material, promotional materials and scheduling are all unified and abstracted.

As shown in Figure 3 below, the promotion materials include banners, topics, events, web pages, etc.; there are capsule banners, travel information, grass planters, heavy updates, etc.; for example, grass planters are composed of web pages (content links) plus time; The entire structure presents an inverted pyramid structure.

(image 3)

Originally, the scheduling data of each resource slot of the game center was placed in different places, such as the top banner scheduling, and the online game banner scheduling had their own tables to save. In this case, the number of database tables may be relatively large, which is more complicated for unified expansion. If I need to add to the top banner and online game banner to display different data for different groups of people (DMP system), I usually need to add a DMP field in each table to indicate the tag id that needs to be displayed to the user in the current schedule.

After modularization, we treat all the resource locations of the game center as modules, that is, they can all be regarded as scheduling data. We only need two tables to display the three-dimensional data of the scheduling: the scheduling data table And the specific material table associated with the scheduling. Therefore, when designing the scheduling table, we save the material information (material\_id and material\_type in Figure 4) data in the scheduling table, and store DMP or other unified information in the scheduling table. The advantage of this is that a unified process can take effect for all schedules.

(Figure 4)

3.2 Unification and visualization of back-end business processes

Such a complicated business process definitely requires back-end cooperation. After the unification of materials, promotional materials and scheduling, we also standardized the back-end configuration process.

The specific configuration process is shown in Figure 5 and 6. Figure 5 is biased towards the background configuration process, which is a bottom-up configuration. Figure 6 is a top-down structure for the convenience of everyone's understanding. The user-level display is a specific plan, which consists of several pages, but will be displayed according to the user's portrait, that is, the number of configured pages is not necessarily the number of displayed pages. The page is made up of several components, and the components are made up of templates and data... decomposing layer by layer, you can understand the modular structure as a whole.

(Figure 5)

(Image 6)

Before modularization, to configure the homepage banner scheduling, you need to go to the tab column of the homepage banner, add the relevant scheduling in all the banner scheduling, and then select all the data in the banner scheduling in the homepage banner scheduling, and configure others The page banner scheduling also requires related operations in a similar directory structure. The banners between each other are separated and cannot be used universally; for operations, the configuration workload has also increased a lot.

After modularization, the operation becomes very simple. At the component level, through database configuration, we can save the template information in the database in advance. At the data level, we store all banner data uniformly in the promotion material management and bind it to the scheduling to achieve reuse. In the business component management page, select the template according to the component application scenario, and then configure the corresponding scheduling data.

As shown in Figure 7, the current heavy update scenario is associated with manual scheduling (if it is associated with recommendation, the corresponding code is recommended). After the style is configured, the entire business component is configured. Then add the components you want to configure to a page in the page management, and set the corresponding DMP. After configuring the components, you can scroll to preview the overall page effect on the background page.

(Picture 7)

As shown in Figure 8. Finally, the page can be reused in different delivery schemes, and the operation background will finally be displayed on the user interface after passing the review flow and on-line check. The current configuration process is bottom-up, clear in logic, and in line with operational configuration habits.

(Picture 8)

3.3 Abstraction and unification of front-end business processes

At present, the homepage of the game center and the new travel area have been transformed into modular pages. The homepage is a very important distribution channel for the game center. Modularization requires a variety of page forms. At the same time, if the modularization is not approved by users, it must be able to dynamically roll back.

Therefore, there are three types of modular pages on the homepage:

• Purely modular pages,
• Interspersed with modular pages and
• H5 modular page

The so-called pure modular page means that all elements in the page are composed of componentized data. The so-called interspersed modular page, its page structure is that a number of components are interspersed in the game list according to a certain rule, which is exactly the same as the page organization structure before the modularization, but the background implementation is different.

interspersed with the modular page The list in 1619317ba833e8 has two different forms, divided into game list and mixed data stream list. Interspersed pages can display the game on one screen with maximum efficiency.

The last H5 modular page can be considered as a page composed of H5 components, provided by our Wukong website. The process of obtaining different solutions and different pages through the multi-layer test framework and DMP will not be repeated here. Here we talk about the most complex interspersed page flow in the entire process, and how we abstract and design in such a complex flow.

(Picture 9)

3.3.1 Unified process

From the above figure (you don't need to pay too much attention to the business logic of each step in the flowchart, the flowchart is just to show the complexity of the original process) we can see that a user request needs to go through N steps. Such lengthy steps, if written in a service, will cause logical confusion, low maintainability and poor scalability, so we can divide and conquer. In Figure 9, we use different colors to distinguish the steps, which can be a simple process summary.

The summarized process is shown in the figure below. We can summarize the submission of the asynchronous thread pool, which can be understood as two steps to obtain the component list and the mixed data list.

(Figure 10)

After we generalize and abstract, the entire modularized page acquisition process can be simplified into four steps: initialization phase, component list phase acquisition, construction phase, and merge phase, as shown in the figure;

(Figure 11)

In the book "Pyramid Principle", it was said that when reading an article, readers must read and understand every sentence, and look for the connection between each sentence, thinking back and forth. If your article structure presents a pyramid shape, and the idea of the article gradually expands from the top of the pyramid, then readers will definitely find your article easier to read. This phenomenon reflects the basic laws of human thinking, so reading codes is actually the same logic. Good code is a comment of business logic, and the main business process can be roughly judged by reading the code. In the construction phase, different strategies can be combined to obtain different scheduling data. Strategies and components are decoupled. When a strategy is added, there is no need to change the original business logic. The different strategies here can also be obtained using the factory model method.

The component display logic of the homepage is more complicated, especially for interspersed modular pages. As mentioned earlier, the interspersed page is composed of game lists and business components, that is, in a game list, various business components are interspersed. If the data list is a game data list, then each game is arranged in a certain proportion, and the underlying data that needs to be promoted in the component is the game's deduplication. For example, games are displayed according to the ratio of online games, stand-alone and independent games. If the previous component has displayed the current game, then this game needs to be filtered, and there is also a logic for the supplementary game. For example, if the online game is filtered, then the supplementary game The games in the list are supplemented by online games, and then topped by the games below. There are two types of de-duplication logic, one is that it can be filtered by the previous game and the game below; the other is that it can only de-duplicate the game below, and will not be de-duplicated by the game above.

(Figure 12)

When obtaining the scheduling data in the business component (as shown in the figure above, which also contains game information), there will also be access to ABTest information (different users display different game information), game black and white list filtering, installed filtering, and exposure Filtering, additional information processing, component data assembly and other processes. Each scheduling data acquisition will be processed by a different Handler. Each Handler has its own processing logic. For so many schedules and their expansion, if there is no unified logic for processing, it would be a disaster. Newcomers may miss a lot of details when scheduling data in the development of new components. In addition, there are some general logics between the promotion materials. If these logics are not deposited in the domain model, the logic cannot be reused and will be scattered in each Handler. We will explain in detail the steps in orange in the following figure.

3.3.2 Unification of the process of promoting materials

On the one hand, we will unify the process of acquiring and processing promotional materials. In the process shown in the figure below, in fact, it basically contains the logic of the steps that need to be processed for all promotional materials (unimportant steps have been ignored). After unification, we can sink some common logic to form a unified method call. For example, we can use factory method design patterns to shield the logic of obtaining promotional materials based on manual scheduling, recommended scheduling, etc. Of course, in order to improve performance, for manual scheduling data, we use a unified cache method to obtain the universal scene code; then we use different filtering strategies to filter out the games or content that enter the black and gray list. After processing the additional information, use the data in the list to remove the duplicate data in the component.

(Figure 13)

3.3.3 The logical abstraction and precipitation of the model

On the other hand, we precipitate the logic of unified processing components and promotion materials into the corresponding domain model, as shown in the figure;

(Figure 14)

The entire process of filtering duplicate data is performed on components, so at the component level, there will be a lot of repetitive logic. For example, each component needs to deal with the number of data returned at the end, and the number returned by different components is different. Yes, then it will be more appropriate to write this part of the logic in the component domain model. For example, exposed and installed processing, this logic can be processed at the component level, of course, it is not a problem to place it at the Handler level. At the level of promotional materials, there are also some general logics, such as a topic composed of 1*4 games and a topic composed of 2*2 games. Behind them, there is a set of logic to connect to the recommendation system and cover the bottom, which can also be deposited in the topic. Domain model to deal with.

Four, write at the end

At present, many business development students, especially after they are familiar with the business, usually fall into a misunderstanding: the business is basically CRUD, and there is no technical content. However, in the development process, there is often a lack of corresponding thinking, which leads to repeated development. So how can we make business development more attractive and technical?

In the process of modular transformation of the game center, the use of component abstraction and reuse improves the componentization, configuration and experimentation capabilities, and quickly supports business needs. At the same time, the business code is continuously improved through the unified standard process and the use of domain model knowledge. , Improve the maintainability and scalability of the code. With the continuous development of business, even the current very reasonable architecture will become bloated and difficult to expand, but the methodology of how to do business is indeed unchanged. Therefore, as a business development classmate, you should think more about how to deepen your business and improve your ability to quickly realize business value.

Author: vivo Internet server team—Chen Wenyang