Architecture and Data Flow of Bilibili Live Room: MVVM Design, View Interaction, and Business Segmentation

Background

The Bilibili live room is one of the most complex single‑page interaction modules in the app, handling a traffic volume comparable to a small standalone app. Unlike typical Activity‑based pages, the live room consists of many independent Views that together form the whole room.

Each View can be regarded as a business unit, similar to an Activity in the overall app architecture.

Current Interaction Situation

The business logic follows an MVVM pattern with three layers (Service as the Model layer). Ideally, each business unit should be cohesive and unaware of others; the ViewModel supplies the View with the required data and state.

In practice, however, a View’s displayed data is often affected by other Views. Consequently, a View must not only handle its own logic but also react to data changes from other Views.

Problems Caused by the Existing Interaction Logic

Improper use of LiveData and tangled business logic lead to excessive ViewModel references, increasing coupling between Views. Two main reasons for cross‑View ViewModel references are:

The View’s own ViewModel cannot provide the needed data, so it references another ViewModel that holds it.

A View’s action or data change must notify other business units, so it calls methods in another ViewModel.

This results in a chaotic reference graph and a vicious cycle of tighter coupling and more complex data distribution.

Analysis of the Root Cause

The visible symptom is chaotic ViewModel reference relationships. The underlying cause is non‑standard data access across business units, which amplifies coupling, loading complexity, and data distribution overhead.

To break this cycle, a script was used to analyze more than 60 business modules in the live room, identifying over 1,400 concrete ViewModel usage scenarios and proposing an ideal data provider model for future refactoring.

Business Data Based on View Segmentation

Each business module follows the MVVM structure with a unified template. Data and state are confined to their respective layers and must not be accessed across layers. The data usage is divided into three scenarios:

Initialization Data : Provided during room loading tasks, transformed into business‑specific data structures for internal logic and view rendering.

Interaction Data : Generated by user actions (clicks, swipes) or by network responses (Socket/HTTP). These events may affect the originating View or trigger cascaded logic across multiple Views.

External Provision Data : Each business decides which events and data to expose via its API. Consumers obtain data through provideData methods or subscribe to changes via notifyChange methods. Direct exposure of raw Data objects is prohibited.

Data Flow

When entering a live room, an initialization API batch is requested. The response is handled by a data dispatcher that distributes data to each business’s Service.

Each Service manages its own data; ViewModels obtain or modify data by holding references to the corresponding Service.

ViewModels combine raw data from multiple Services and expose it to Views via LiveData. Views can also push modifications back through the ViewModel.

Pure UI events between Views are routed through a ViewEventManager, which carries one‑time data that must not be reused elsewhere.

Live Room View Structure and Business Zones

The room is divided into two zones:

Global (Container) Zone : Contains the sliding component and dialog‑level business (e.g., topics, guides). Created when entering a room and destroyed with the Activity.

Room Zone : Contains room‑level business and the player. Each RoomItem corresponds to a room; resources are released when the item is scrolled out.

Developers only need to declare whether a business belongs to Global or Room and implement creation/destruction callbacks; the framework handles the actual lifecycle.

Thoughts on Architectural Evolution

The architecture must serve evolving business scenarios. As the live room shifted from non‑slidable to vertically slidable, and from legacy to new versions, the architecture needed to adapt. Over‑time, quick‑fix code accumulates, leading to architectural decay. The author proposes two goals for evolution:

Break team dissatisfaction by regularly refactoring and addressing technical debt.

Cultivate a shared sense of architectural ownership, encouraging every developer to think like an architect.