Live interaction method and device, terminal and storage medium

Abstract

This application discloses a live streaming interaction method, apparatus, terminal, and storage medium, belonging to the field of Internet technology. The method includes: obtaining an interaction display configuration sent by a server, the interaction display configuration being used to configure the display style of interactive components in a live streaming room under different interaction states, wherein the interactive component includes at least two interaction states and there is a state transition between different interaction states; obtaining a target display style corresponding to the current interaction state from the interaction display configuration based on the current interaction state of the interactive component in the current live streaming room; and displaying the interactive component in the current interaction state in the target display style on the live streaming interface of the current live streaming room. The solution provided by this application embodiment can change the display effect of interactive components in different interaction states in real time through the display style configuration of interactive components in different interaction states sent by the server.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a live interactive method, device, terminal and storage medium. Background Technology

[0002] With the development of internet technology, live streaming applications have incorporated various features to enhance interaction between the streamer and viewers, such as distributing virtual red envelopes during the live stream. Currently, to achieve rich interactive visual effects, these effects are typically pre-written into the client's layout file, allowing for switching between different layouts. Summary of the Invention

[0003] This application provides a live interactive method, apparatus, terminal, and storage medium. The technical solution is as follows: On one hand, embodiments of this application provide a live interactive method, the method comprising: Obtain the interactive display configuration sent by the server. The interactive display configuration is used to configure the display style of interactive components in the live room under different interactive states. The interactive components include at least two interactive states and there is a state transition between different interactive states. Based on the current interaction status of the interactive components in the current live broadcast room, obtain the target display style corresponding to the current interaction status from the interaction display configuration; In the live streaming interface of the current live streaming room, the interactive components in the current interactive state are displayed in the target display style.

[0004] On the other hand, embodiments of this application provide a live interactive device, the device comprising: The first acquisition module is used to acquire the interactive display configuration sent by the server. The interactive display configuration is used to configure the display style of the interactive components in the live room under different interactive states. The interactive components include at least two interactive states and there is a state transition between different interactive states. The second acquisition module is used to acquire the target display style corresponding to the current interaction state from the interaction display configuration based on the current interaction state of the interactive component in the current live broadcast room. An execution module is used to display the interactive components in the current interactive state in the target display style on the live broadcast interface of the current live broadcast room.

[0005] On the other hand, embodiments of this application provide a terminal, the terminal including a processor and a memory, the memory storing at least one computer instruction, the at least one computer instruction being loaded and executed by the processor to implement the live interactive method as described above.

[0006] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one computer instruction, which is executed by a processor to implement the live interactive method as described above.

[0007] On the other hand, embodiments of this application provide a computer program product, which includes computer instructions, and a processor executes the computer instructions to implement the live interactive method as described above.

[0008] In this embodiment, the interactive display configuration sent by the server can be obtained. This configuration is used to configure the display style of interactive components in different interactive states within the live stream. Each interactive component includes at least two interactive states with transitions between them. Based on the current interactive state of the interactive component in the live stream, the target display style corresponding to the current interactive state can be obtained from the interactive display configuration. This allows the interactive component in the current interactive state to be displayed in the live stream interface with the target display style. Thus, the interactive process experienced by the interactive component can be described using multiple interactive states. The server can send display style configurations for the interactive component in different interactive states at the component level. When the client needs to display the interactive component, it can directly read the required display style from the server-sent configuration based on the current interactive state and apply it for display. This allows for real-time changes to the visual effect of the interactive component, supporting personalized configuration updates for various operational scenarios such as holiday events and brand collaborations, without requiring client version updates. This greatly improves operational flexibility and enhances the user experience. Attached Figure Description

[0009] Figure 1 This is a block diagram of a live interactive system provided in an exemplary embodiment of this application; Figure 2 This is a flowchart of a live interactive method provided in an exemplary embodiment of this application; Figure 3 This is a flowchart illustrating a live interactive method based on the MVVM architecture, as shown in an exemplary embodiment of this application; Figure 4 This is a flowchart illustrating a live-streaming room red envelope display component, as shown in an exemplary embodiment of this application; Figure 5A This is a timing diagram illustrating the transition of a live-streaming red envelope component between different interactive states, as shown in an exemplary embodiment of this application. Figure 5B This is a schematic diagram illustrating the display effect of the live streaming red envelope component under different interactive states, as shown in an exemplary embodiment of this application; Figure 6 This is an exemplary embodiment of the live interactive system shown in this application, illustrating the overall architecture of the system. Figure 7 This is an overall flowchart illustrating a live interactive method in an exemplary embodiment of this application; Figure 8 This is a flowchart of the network request management process in a live interactive method provided by an exemplary embodiment of this application; Figure 9 This is a structural block diagram of a live interactive device provided in an exemplary embodiment of this application; Figure 10 This is a schematic diagram of the structure of a terminal provided in an exemplary embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0011] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0012] Figure 1 The diagram illustrates a block diagram of a live interactive system provided in an exemplary embodiment of this application. The live interactive system may include a terminal 110 and a server 120. The number of terminals 110 in the live interactive system can be multiple, and each terminal 110 has a communication connection with the server 120.

[0013] Optionally, terminal 110 can be a smartphone, tablet, laptop, or desktop computer. Server 120 can be a single server, a server cluster consisting of several servers, or a cloud computing service center.

[0014] Optionally, terminal 110 runs a client application for a live streaming application, which provides live streaming functionality. Server 120 can be the server-side application for the live streaming application, providing background services to the client application. After logging into their account on the live streaming application client, users can watch or participate in live streams; users participating in live streams are called streamers. Each streamer has their own live streaming room, which is a playback page. When a streamer is live streaming, their live video will be played in their corresponding live streaming room. Users can enter different live streaming rooms by clicking to watch the live stream of the corresponding streamer.

[0015] Taking a live interactive system comprising a first terminal and a second terminal as an example, the first terminal is logged into a broadcaster's account, and the second terminal is logged into a viewer's account. After the broadcaster's account opens a live room, the viewer's account can enter the live room to watch the live content. The server 120 provides technical support for the implementation of various functions of the live streaming application, such as live stream data transmission. The server 120 stores data related to the live streaming application, processes the large amount of data generated during the live stream, and receives the live video and audio streams pushed by the first terminal, transmitting them stably to the second terminal.

[0016] Optionally, the live streaming application client provides various interactive components for the live streaming room to realize various interactive functions, such as the virtual red envelope function, where users can send virtual red envelopes in the live streaming room, and the host and viewers can receive the sent virtual red envelopes in the host's live streaming room.

[0017] The live interactive method provided in this application embodiment is used for... Figure 1 The client of the live streaming application in terminal 110 shown.

[0018] In related technologies, for interactive functions in live streaming rooms (such as red envelopes), to achieve rich interactive visual effects, all user interface (UI) visual effects are usually hard-coded into the client's resource files, allowing switching through different layout files or themes. This means that when facing operational scenarios that require immediate changes to the visual style, such as holiday events or brand collaborations, a new client version needs to be released. Alternatively, multiple sets of theme resources can be pre-installed in the client, and themes can be switched according to predetermined conditions. This method of pre-embedding all resources in the client not only increases the client's package size but also requires writing a large number of if-else statements in the code to set different pre-installed resources based on different conditions. This results in the skinning logic (judgment conditions, resource settings) being mixed in with the business code, increasing code complexity and maintenance costs.

[0019] To address the aforementioned issues, this application provides a live streaming interaction method. This method acquires an interaction display configuration sent by a server. The interaction display configuration configures the display style of interactive components within the live streaming room under different interaction states. Each interactive component contains at least two interaction states, and there is a state transition between these states. Based on the current interaction state of the interactive component in the live streaming room, the method retrieves the target display style corresponding to the current interaction state from the interaction display configuration. The interactive component in the current interaction state is then displayed in the live streaming interface of the current live streaming room using the target display style. This allows the interaction process experienced by the interactive component to be described using multiple interaction states. Furthermore, the server can send the display style configuration of the interactive component under different interaction states at the component level. Therefore, when the client needs to display the interactive component, it can directly read the display style required by the current interaction state from the display style configuration sent by the server and apply it for display. This allows for real-time changes to the visual effect of the interactive component, supporting personalized configuration updates for various operational scenarios such as holiday activities and brand collaborations. No client version updates are required, greatly improving operational flexibility and user experience.

[0020] Please refer to Figure 2 This illustration shows a flowchart of a method provided in an exemplary embodiment of this application. This embodiment describes the method as being provided by... Figure 1 Taking the client execution in terminal 110 as an example, the process includes the following steps: Step 201: Obtain the interactive display configuration sent by the server. The interactive display configuration is used to configure the display style of interactive components in the live room under different interactive states. The interactive component includes at least two interactive states and there is a state transition between different interactive states.

[0021] Interactive components can be functional components with interactive features in the live stream, such as red envelope components, gift components, entrance animation components, live stream background components, live stream vehicle components, etc., without limitation. The client can dynamically update the display style of interactive components. This display style can include, but is not limited to, the configuration of style fields such as background color, icon, background image, foreground image, widgets, and control colors (selected and unselected colors).

[0022] Optionally, the interactive state of an interactive component is determined based on its interactive flow. Since an interactive component needs to go through multiple interactive flows sequentially throughout its lifecycle, each flow reflecting an interactive state, there are state transition relationships between these states; that is, the next interactive flow will begin after the previous one ends. For example, taking a red envelope component as an example, throughout its lifecycle, the component needs to go through multiple interactive flows sequentially, including creation, display, grabbing the red envelope, waiting for the draw, and displaying the result. Each flow reflects a red envelope state. For instance, the creation flow reflects the red envelope loading state, the grabbing flow reflects the red envelope receiving state, and the waiting for the draw flow reflects the waiting for the result state. There are state transitions between these states; for example, after completing the grabbing flow, the component will enter the waiting for the draw flow.

[0023] Since the icons, colors, and backgrounds of red envelopes may differ under different interactive states, and each interactive component in a live stream is in a different interactive state, the server can configure the display style of interactive components under different interactive states and send the configured interactive display settings to the client. Therefore, regardless of the current interactive state of the interactive component, the required display style can be read from the sent interactive display settings.

[0024] In some embodiments, taking the red envelope component as an example, the interactive state of the red envelope component includes, but is not limited to, at least one of the following: red envelope loading state, which indicates that the display content of the red envelope component is being loaded; red envelope verification state, which indicates that the red envelope component verifies the eligibility to receive the red envelope; red envelope receiving state, which indicates that the red envelope component is available to receive the red envelope; waiting for result state, which indicates that the red envelope component is waiting for the receiving result; and result display state, which indicates that the red envelope component displays the receiving result.

[0025] Optionally, the server may send the interactive display configuration automatically when the client enters the live stream, or in response to a client's configuration retrieval request, or automatically push (e.g., via socket push) the updated interactive display configuration to the client when the server detects that the operator has updated the interactive display configuration. The client may send a configuration retrieval request to the server when entering the live stream, or when triggering an interactive component within the live stream. This embodiment does not limit the timing of the server sending the interactive display configuration.

[0026] Optionally, the interactive display configurations issued by the server correspond to the types of interactive components, with different interactive display configurations issued for different types of interactive components. Thus, multiple interactive components of the same type can apply the same set of display style configurations, while different types of interactive components apply different display style configurations.

[0027] Optionally, the client can cache the interactive display configuration issued by the server this time, so that the interactive components can be displayed directly through the cached interactive display configuration in the future.

[0028] Optionally, after the interactive display configuration issued by the server is updated, the client can replace the previously issued interactive display configuration, thereby reducing the client's memory usage. This ensures that the client always displays interactive components using the latest interactive display configuration issued by the server.

[0029] Step 202: Based on the current interaction status of the interactive components in the current live room, obtain the target display style corresponding to the current interaction status from the interaction display configuration.

[0030] It is understandable that since interactive components display different styles under different interactive states, when interactive components need to be displayed in the current live room, the client can read the target display style required for the current interactive state from the interactive display configuration based on the current interactive state of the interactive components in the current live room.

[0031] Optionally, when the current live stream contains multiple interactive components of the same type, such as multiple red envelope components, the client can determine the current interactive state of each interactive component separately, so as to read the target display style required by each interactive component in the current interactive state from the interactive display configuration. For example, if the current interactive state of red envelope component 1 is "waiting for result", the client can read the target display style corresponding to the waiting for result state from the interactive display configuration, such as the background gradient color and icon color of the waiting result interface.

[0032] Optionally, the client's local storage space stores the default display style of the interactive components. The client can check whether the target display style corresponding to the current interactive state exists in the interactive display configuration sent by the server. If the target display style corresponding to the current interactive state exists, it retrieves the target display style from the interactive display configuration. If the target display style corresponding to the current interactive state does not exist, it retrieves the default display style corresponding to the current interactive state from the local storage space.

[0033] Step 203: In the live broadcast interface of the current live broadcast room, display the interactive components in the current interactive state in the target display style.

[0034] It is understandable that after reading the target display style corresponding to the current interactive state from the interactive display configuration, the target display style can be applied to the display of the interactive component to ensure that the display effect of the current interactive component matches the current interactive state.

[0035] For example, taking a foreground image as the target display style, the client can use the image loading tool Glide to load the foreground image onto the view corresponding to the interactive component. It's understandable that besides using Glide, an image loading interface can be abstracted to support integration with other image loading libraries such as Picasso and Coil, or the native Android ImageLoader can be used. No specific limitations are specified here.

[0036] Optionally, if a target display style corresponding to the current interactive state exists in the interactive display configuration, the client can display the interactive components in the current interactive state in the live broadcast interface of the current live broadcast room using the target display style. If a target display style corresponding to the current interactive state does not exist in the interactive display configuration, the client retrieves the default display style corresponding to the current interactive state from the local storage space and then displays the interactive components in the current interactive state in the default display style in the live broadcast interface of the current live broadcast room.

[0037] In this embodiment, the interactive process experienced by the interactive component can be described by multiple interactive states. The server can issue the display style configuration of the interactive component in different interactive states at the granular level. Thus, when the client needs to display the interactive component, it can directly read the display style configuration issued by the server in real time according to the display style required by the current interactive state of the interactive component and apply it to the display. This changes the visual effect of the interactive component in real time, supports personalized configuration updates for various operational scenarios such as holiday activities and brand cooperation, and does not require client version updates, greatly improving operational flexibility and the freshness of user experience.

[0038] Live interactive implementation based on MVVM architecture In this embodiment, the client adopts an MVVM (Model-View-ViewModel) architecture. This architecture includes a data layer (Model), a view layer (View), and a view model layer (ViewModel). The data layer transmits the interactive display configuration of interactive components from the server to the client, the view layer displays the interactive components, and the view model layer connects the data layer and the view layer and performs logic processing.

[0039] In this embodiment, the data layer acts as a transmission channel between the server and the client, allowing the interactive display configuration sent by the server to be transmitted to the client. Thus, the view model layer can read the interactive display configuration sent by the server from the data layer.

[0040] Optionally, by defining a data class for interactive display configuration in the data layer, the view model layer can read the interactive display configuration from the data layer and execute logic processing after the server-side interactive display configuration is transmitted to the client through the data layer. The data class for interactive display configuration contains fields for all display styles of the interactive component in all interactive states.

[0041] Optionally, the display style includes, but is not limited to, at least one of the following: top display style; foreground display style; background display style; control display style; and widget display style. Optionally, the top display style can be a top image, top icon, etc.; the foreground display style can be a foreground image, foreground color gradient, etc.; the background display style can be a background color, background color gradient, etc.; and the control display style can be the selected color of the control, the unselected color of the control, etc. The widget display style can be a widget image, widget animation, etc. No limitations are imposed here.

[0042] As an example, taking the red envelope component as an example, a data class `RedEnvelopeSkinEntity` is created to configure the red envelope skin. This class contains `topImg` (the URL of the top image), `startColor` / `endColor` (the start and end color strings for the gradient), `fgImg` / `bgImg` (the URLs of the foreground and background images), `pendantImg` / `pendantBigImg` (the URLs of the widget's size image), and color fields for the selected / unselected states of various controls. Simultaneously, an extension function `toColorInt(defaultValue: Int)` is provided for the String type to safely convert the color string to an Android `ColorInt`, providing default values ​​to enhance robustness. It can be understood that the defined data class `RedEnvelopeSkinEntity` can serve as a data transmission contract for the red envelope skin configuration between the server and the client.

[0043] It's understandable that interactive display configurations can use more flexible JSONObjects or Maps in addition to predefined fields.<String,String> A set of key naming conventions is defined, enabling the server to dynamically expand configuration items. Clients can then look up and apply these items using the key names, further enhancing configuration flexibility. In addition to supporting #RRGGBB or #AARRGGBB string formats, color configuration can also be extended to support Hue-Saturation-Lightness (HSL) and Hue-Saturation-Value (HSV) notations, or directly support color resource names, which are mapped to specific color values ​​by the client.

[0044] Optionally, the view layer can include a series of views of the interactive components, and the view model layer contains the state machine of the interactive components and a business logic coordinator. The state machine is a computational model used to describe the sequence of interactive states experienced by the interactive component during its lifecycle, as well as the triggering events and response actions that lead to state transitions. The business logic coordinator is used to execute the logic processing related to the interactive components. Thus, by defining the complete state machine of the interactive component (such as the loading, follow-up, available for grabbing, and prize-winning states of the red envelope component) through enumeration or sealed classes, and having the view model layer centrally manage the state and core data as a single trusted source, the problem of chaotic state management in real-time interactive functions in live streaming scenarios can be effectively solved.

[0045] In this embodiment, the interactive state of the interactive component is maintained by the ViewModel layer so that when a change in the interactive state is observed, the ViewModel layer is driven to update the display, such as displaying the component in the style corresponding to the changed interactive state.

[0046] Please refer to Figure 3 This illustrates a flowchart of a live interactive method provided in another exemplary embodiment of this application. This embodiment uses this method... Figure 1 Taking the client execution in terminal 110 as an example, the process includes the following steps: Step 301: Obtain the interactive display configuration sent by the server through the view model layer.

[0047] Optionally, the interactive display configuration sent by the server can be read from the data layer through the view model layer. In one possible implementation, upon entering the current live stream room, the client sends a configuration retrieval request to the server through the view model layer. This request instructs the server to send the interactive display configuration. Then, the interactive display configuration returned by the server is read from the data layer through the view model layer.

[0048] Optionally, a configuration retrieval request can refer to a request that retrieves the display style configuration of an interactive component. A configuration retrieval request can be for the entire display style configuration of an interactive component, such as the configuration retrieval request `requestRedEnvelopeConfig` for a red envelope component, or it can be for a partial display style configuration of an interactive component, such as the configuration retrieval request `requestRedEnvelopePendant` for a red envelope widget. There is no limitation here; for example, it could also be other requests that only require the callback to carry the display style configuration of the interactive component.

[0049] In one possible implementation, in response to the triggering operation of the interactive component in the current live room, the client sends a configuration retrieval request to the server through the view model layer, and then receives the interactive display configuration sent by the server from the data layer through the view model layer.

[0050] Optionally, the triggering operation for the interactive component can be the current live stream's activation of the interactive component, or it can be the current live stream's direct display of the interactive component after another live stream has activated it. There are no limitations here. Taking the red envelope component as an example, the triggering operation can be the sending or receiving of a red envelope, requesting the server to issue the interactive display configuration when a red envelope needs to be sent or received.

[0051] Step 302: Send the interactive display configuration to the view layer through the view model layer.

[0052] Optionally, after reading the interactive display configuration issued by the server from the data layer through the view model layer, a notification message can be sent to the view layer, which carries the interactive display configuration.

[0053] Optionally, after the view model layer reads the interactive display configuration issued by the server from the data layer, it can detect whether the interactive display configuration is updated compared to the historical interactive display configurations issued by the server. If it is updated, a notification message carrying the updated interactive display configuration is sent to the view layer in response to the update. Thus, the view model layer can promptly notify the view layer when the interactive display configuration changes, ensuring that the view layer's display is updated synchronously.

[0054] Optionally, through the view model layer, LiveData objects can be created based on the data class of the interactive display configuration to observe the interactive display configuration through the LiveData mechanism. In other words, when the view model layer observes changes in the interactive display configuration through the LiveData object, it automatically notifies the view layer that the interactive display configuration has been updated. This achieves the effect of driving UI responsive updates through LiveData.

[0055] Step 303: Through the view layer, based on the current interaction status of the interactive components in the current live room, obtain the target display style corresponding to the current interaction status from the interaction display configuration.

[0056] Optionally, in the view layer, the relevant views of each interactive component will read the target display style corresponding to the current interactive state from the interactive display configuration based on the current interactive state of the interactive component, and apply it to the relevant views.

[0057] Taking the red envelope component as an example, the result page view of the red envelope component will read the background image required by the result page view from the interactive display configuration, so that the background image can be displayed in the result page view when the result page view of the red envelope component is displayed.

[0058] Step 304: Through the view layer, display the interactive components in the current interactive state in the live broadcast interface of the current live broadcast room in the target display style.

[0059] Optionally, if the target display style includes image resources, these image resources can be preloaded through the view layer. Then, through the view layer, the interactive components in the current interactive state are displayed in the live broadcast interface of the current live broadcast room according to the target display style and the preloaded image resources. This allows for the preloading of large resources that require loading time, ensuring that the image resources are ready when the UI of the interactive components is displayed, avoiding blank or flickering during the loading process.

[0060] In one possible implementation, taking the red envelope component as an example, when the red envelope component is in the red envelope sending state, the client first checks whether the top image `topImg` exists in the target display style. If it exists, since top images usually take time to load, the client does not directly create the red envelope sending dialog box. Instead, it uses Glide to preload the image using `preload()` and registers a listener. After preloading is complete, the client creates and displays the dialog box `RedEnvelopeSendDialogFragment` in the listener's `onResourceReady` method, and simultaneously passes the preloaded image resource via `Arguments`. This ensures that when the red envelope sending dialog box is displayed, the critical network image resources it requires are ready or loading, avoiding layout flickering or blanking during image loading.

[0061] In some embodiments, when the current live stream contains multiple interactive components, these components can be switched between display modes. Optionally, when the first interactive component is displayed in the current live stream, the target display style corresponding to the second interactive component to be switched can be preloaded. This ensures that when the second interactive component is switched to display, its required key network image resources are ready or loading, avoiding layout flickering or blanking during image loading.

[0062] Optionally, for the first interactive component that is no longer displayed in the current live stream, the animation effects of the first interactive component, such as the gradient animation of the background color, can be paused. The animation effects, such as the gradient animation of the background color, will be seamlessly restored when the first interactive component is redisplayed in the current live stream.

[0063] As an example, please refer to the red envelope component. Figure 4The diagram illustrates a flowchart of a live interactive method provided in an exemplary embodiment of this application.

[0064] Step 401: Send a red envelope loading request to the view model layer through the view layer.

[0065] Optionally, upon entering the live stream room or receiving a red envelope in the live stream, the client sends a red envelope loading request to the view model layer through the view layer, such as executing loaddata(), to request the loading of the red envelope component to be displayed. At this time, the red envelope component is in the red envelope loading state. During the red envelope loading state, the client completes the creation of the red envelope component and the loading of information. Optionally, the loaded information may include the current interaction state of the red envelope component.

[0066] Optionally, the red envelope component to be displayed can be the red envelope component corresponding to a recently received red envelope, or the red envelope component corresponding to red envelopes received in the past in the live broadcast room.

[0067] Step 402: In response to the red envelope loading request, a red envelope information retrieval request is sent to the server through the view model layer.

[0068] Optionally, the client sends a request to the server to obtain red envelope information through the view model layer, requesting the server to provide the red envelope information to be displayed. This red envelope information includes, but is not limited to, the interactive display configuration of the red envelope component, the ID of the red envelope component, the conditions for receiving the red envelope component, the current interactive status of the red envelope component, and a series of initialization data.

[0069] Step 403: Obtain the red envelope information sent by the server through the view model layer.

[0070] As an example, the client can read the red envelope information sent by the server from the data layer through the view model layer.

[0071] Step 404: Send the red envelope information to the view layer through the view model layer.

[0072] Optionally, after obtaining the red envelope information sent by the server through the view model layer, it can provide the view layer with the red envelope information it needs so that the view layer can display the red envelope component.

[0073] Step 405: Through the view layer, display the red envelope component in the corresponding interactive state according to the red envelope information.

[0074] Optionally, for the red envelope component corresponding to the newly received red envelope, the red envelope component in the loading state can be displayed through the view layer based on the red envelope information.

[0075] Optionally, for the red envelope component corresponding to red envelopes received in the live stream history, the view layer can display the red envelope component in the current interaction state according to the red envelope information. For example, if the current interaction state of a red envelope received in the live stream history is in the result display state, the red envelope component in the result display state can be directly displayed through the view layer.

[0076] In this way, when there are multiple red envelope components in the live broadcast room, the display of the red envelope component in the corresponding interactive state can be accurately realized according to the red envelope status of each component.

[0077] Interactive state management of interactive components In some embodiments, the client can obtain state data sent by the server through the view model layer. This state data may include triggering events and response actions that cause the interactive state of interactive components to change.

[0078] For example, taking the red envelope component as an example, when the eligibility for receiving the red envelope component requires following the streamer, after the client follows the streamer, the server will send the status data of successful following to the view model layer, so that the view model layer can determine that the verification status of the interactive component has been completed.

[0079] Optionally, the status data sent by the server can be transmitted to the client through the data layer, so that the client can read the status data sent by the server from the data layer through the view model layer.

[0080] Optionally, after obtaining the status data, the client can determine the current interactive state of the interactive component based on the status data through the view model layer. For example, when the view model layer determines that the verification status of the interactive component has been completed based on the status data of successful following, it can automatically transition to the next interactive state, such as the red envelope receiving status. At this time, the view model layer can determine the current interactive state of the interactive component by transitioning to the next interactive state.

[0081] In some embodiments, the client can also obtain event information distributed by the event bus through the view model layer to determine the current interaction state of the interactive component. For example, taking the red envelope component as an example, when the red envelope component requires a gift to be sent to receive it, after the client successfully sends the gift, the event bus will distribute a gift-sending event to the view model layer, so that the view model layer can determine that the verification state of the interactive component has been completed.

[0082] Optionally, the view model layer can store state transition paths, as well as triggering events and response actions that lead to interactive state transitions. Thus, the current interactive state of an interactive component can be determined based on the state data and state transition paths through the view model layer. It is understood that due to the complexity of the scenario, different red envelope components may have different state transition paths, and the same red envelope component may also include multiple state transition paths; this is not limited here.

[0083] As an example, taking Red Packet Component 1 and Red Packet Component 2 as examples, the state transition path of Red Packet Component 1 is: Red Packet loading state - Red Packet verification state "Need to follow" - Red Packet verification state "Need to send a gift" - Red Packet receiving state - Waiting for result state - Result display state. The state transition path of Red Packet Component 2 is: Red Packet loading state - Red Packet verification state "Need to follow" - Red Packet receiving state - Waiting for result state - Result display state.

[0084] In some embodiments, the current live stream includes at least one interactive component. The view model layer includes a first view model and at least one second view model corresponding to each interactive component. Each second view model stores the interaction state of its corresponding interactive component. The first view model centrally manages the state data of each second view model. Thus, the interaction state of an interactive component can be maintained through a single view model, achieving isolation of interaction states. Simultaneously, a centralized view model centrally manages the state data of each interactive component distributed by the server, effectively avoiding the problem of chaotic state management.

[0085] For example, taking the red envelope component as an example, the view model layer includes a first view model, RedEnvelopeListViewModel, and second view models, RedEnvelopeViewModel, for each red envelope component. Thus, RedEnvelopeListViewModel can serve as a single trusted source to centrally manage the state and core data, while each RedEnvelopeViewModel maintains the red envelope state of its respective red envelope component.

[0086] Optionally, the client can read the status data sent by the server from the data layer through the first view model. If the current live stream contains multiple interactive components, the server can send the status data that causes the interaction states of these components to change to the client in a unified manner. The client can then centrally retrieve the status data from the data layer through the first view model. This eliminates the need for the server to interface with the second view models of each interactive component.

[0087] After receiving the status data sent by the server, the client can distribute the status data to each second view model through the first view model. Optionally, the status data carries the component identifier of the interactive component. Thus, upon receiving the distributed status data, each second view model can check whether the component identifier corresponds to the component identifier of the interactive component it maintains. If so, it indicates that the status data is related to the interactive component it maintains, and the second view model can determine the current interactive state of the interactive component based on the status data. In this way, for each interactive component, the current interactive state of the interactive component in the current live stream can be determined through the second view model corresponding to the interactive component, based on the status data related to the interactive component.

[0088] Optionally, for each interactive component, the client can determine the current interactive state of the interactive component in the current live broadcast room based on the state data and the state transition path of the interactive component through the second view model corresponding to the interactive component. Taking the live broadcast room including the first interactive component as an example, if the state transition path of the first interactive component includes a transition from the first interactive state to the second interactive state, and the previous interactive state is the first interactive state, and the currently obtained state data indicates that the first interactive state of the first interactive component has been completed, the client can determine the second interactive state as the current interactive state of the first interactive component in the current live broadcast room in response to the state data through the second view model corresponding to the first interactive component.

[0089] Optionally, the second view model corresponding to each interactive component, after determining the current interactive state of the interactive component, will send the current interactive state of the interactive component to the view layer. This allows the view layer to be notified promptly when the interactive state changes, ensuring that the display effect of the interactive component is updated synchronously with the current interactive state. Taking a live broadcast room containing a first interactive component and a second interactive component as an example, the client can send the current interactive state of the first interactive component in the current live broadcast room to the view layer through the second view model corresponding to the first interactive component, and send the current interactive state of the second interactive component in the current live broadcast room to the view layer through the second view model corresponding to the second interactive component.

[0090] In some embodiments, since the interactive components are of the same type, and the interactive display configurations of interactive components of the same type can be reused, the interactive display configurations of interactive components of the same type can also be centrally managed through the first view model. Optionally, the first view model can interface with the server, and the client can obtain the interactive display configuration sent by the server from the data layer through the first view model. Then, in the event of an update to the interactive display configuration, the client responds to the update by sending the interactive display configuration to the view layer through the first view model. Thus, interactive components of the same type can update their display style based on this interactive display configuration.

[0091] Thus, based on the MVVM state machine architecture for managing complex business flows, a centralized, responsive interactive display configuration data stream is introduced, enabling the interactive display configuration data stream to be synchronized to the view layer through the first view model, thereby achieving responsive UI updates.

[0092] Optionally, after reading the interactive display configuration issued by the server from the data layer through the first view model, it can detect whether the interactive display configuration is updated compared to the historical interactive display configurations issued by the server. If it is updated, a notification message is sent to the view layer through the first view model, carrying the updated interactive display configuration. This allows the first view model to promptly notify the view layer when the interactive display configuration changes, ensuring that the view layer's display is updated synchronously.

[0093] Optionally, in the first view model, a LiveData object can be created based on the data class of the interactive display configuration to observe the interactive display configuration through the LiveData mechanism. It can be understood that in the first view model, when a change in the interactive display configuration is observed through the LiveData object, the view layer will be automatically notified that the interactive display configuration has been updated.

[0094] Taking the red envelope component as an example, in the first view model RedEnvelopeListViewModel, a LiveData object is created, such as defining MutableLiveData.<RedEnvelopeSkinEntity?> A `_skin` variable of type `RedEnvelopeSkinEntity` is provided, along with the `updateSkin(entity: RedEnvelopeSkinEntity?)` method. This method internally determines the red envelope skin data based on global feature switches and then posts it to the `_skin` variable. Therefore, in all API callbacks that retrieve red envelope-related information from the server (such as retrieving configuration, red envelope widget lists, and red envelope lists), the `skin` field is extracted upon receiving the response, and the `updateSkin` method is called. Thus, the red envelope skin data becomes a centralized, observable state source; once an update is observed, the view layer is automatically notified to perform a responsive UI update.

[0095] As an example, the UI components of the red envelope component reactively apply red envelope skins by observing the LiveData of the skin in RedEnvelopeListViewModel. Taking the dialog UI component when sending a red envelope as an example, the dialog skin can be changed: when a user triggers the sending of a red envelope in the live room through the client, the client sends a configuration retrieval request requestRedEnvelopeConfig to the server, and then obtains the red envelope skin data in the request callback. When the red envelope skin data is updated, the passed-in red envelope skin data is read in the onViewCreated method of the UI component RedEnvelopeSendDialogFragment. Then, the top image of the dialog UI component is loaded using Glide.with(context).load(skin.topImg).into(headerImageView). Then, the gradient color of the background view of the dialog UI component is set using GradientDrawable: GradientDrawable(Orientation.TOP_BOTTOM,intArrayOf(skin.startColorInt, skin.endColorInt)). The background colors of the option buttons in the dialog UI component are also dynamically created using StateListDrawable, applying the unselected (topColorInt / bottomColorInt) and selected (topSelectedColorInt / bottomSelectedColorInt) colors defined in the red envelope skin respectively.

[0096] Taking the UI components for the details page and the results page of a red envelope as examples, skinning for both pages can be implemented: By observing the LiveData of the skin in the RedEnvelopeListViewModel within the RedEnvelopeDetailViewManager and RedEnvelopeResultViewManager UI components, when the red envelope skin data is updated and contains the foreground image (fgImg) or background image (bgImg) required by the red envelope details page and red envelope results page UI components, Glide is used to load it onto the corresponding ImageView; otherwise, the view is hidden or cleared.

[0097] Optionally, for red envelope widgets, the application's skin dynamic configuration capability can be smoothly integrated into existing, complex live streaming widget architectures through adapter designs such as PendantData, reducing the risk and cost of system modification.

[0098] As an example, for a red envelope widget, a `PendantData` class is defined in the data layer to wrap the original widget list and widget display style. In the widget delegate `RightTopPendantDelegate` and the widget animation delegate `RedAppearAnimDelegate`, when processing the red envelope widget, the widget display style is extracted from the `PendantData` in the data layer. If the widget display style `skin.pendantImg` or `skin.pendantBigImg` exists, a network image loaded using Glide is used to replace the original static resource icon (`R.drawable.fx_red_envelope_pendant_fg`).

[0099] In other embodiments, if the scene requires a specific interactive component to use a personalized interactive display configuration, the interactive display configuration of that interactive component can also be managed independently by the second view model corresponding to that interactive component. In this case, the second view model corresponding to that interactive component interfaces with the server. No limitations are imposed here.

[0100] Status-driven display updates In some embodiments, after determining the current interaction state of an interactive component through a second view model in the view model layer, it can detect whether the current interaction state has been updated. If it has been updated, a notification message is sent to the view layer through the second view model, carrying the updated current interaction state. This allows the view model layer to promptly notify the view layer when the current interaction state undergoes a transition update, ensuring that the view layer's display is updated synchronously.

[0101] Optionally, a LiveData object is created based on the interaction state of the interactive component through the second view model of the view model layer, so as to observe the interaction state of the interactive component through the LiveData mechanism. It can be understood that when the interaction state of an interactive component changes as observed through the LiveData object in the view model layer, the view layer is automatically notified that the interaction state of that interactive component has been updated. Thus, the view layer displays the interactive component corresponding to the updated interaction state.

[0102] As an example, please refer to the red envelope component. Figure 5A The diagram illustrates a flowchart of a live interactive method provided by another exemplary embodiment of this application.

[0103] Step 4051: Through the view layer, display the red envelope component in the loading state on the live broadcast interface of the current live broadcast room. For example, when displaying the red envelope component, display the loading interface of the red envelope component.

[0104] Step 4052: With the red envelope loading state complete, display the red envelope component in the red envelope verification state in the live broadcast interface of the current live broadcast room through the view layer.

[0105] Optionally, upon successful loading of the red envelope, the view model layer transitions the red envelope status from the loading state to the verification state. In the verification state, eligibility to receive the red envelope needs to be verified before transitioning to the receiving state.

[0106] For example, if the eligibility requirements for receiving a red envelope include following the streamer and gifting popularity votes, the red envelope component, when displayed in the view layer, will show a verification interface. This interface will display any incomplete eligibility requirements, such as displaying a "Follow" button. Optionally, the verification interface can also display completed eligibility requirements, such as showing that gifting popularity votes has been completed.

[0107] Step 4053: If the red envelope verification status has been completed, display the red envelope component in the current live broadcast interface through the view layer.

[0108] Optionally, if the eligibility to receive the red envelope is met (i.e., all eligibility verifications are successful), the red envelope status is transitioned from the verification state to the receiving state through the view model layer. At this point, the red envelope component in the receiving state is displayed through the view layer. For example, a red envelope receiving interface is displayed, which includes a "Grab Red Envelope" button. Users can click this "Grab Red Envelope" button to receive the red envelope.

[0109] Step 4054: If the red envelope claiming status has been completed, display the red envelope component in the waiting result status in the live broadcast interface of the current live broadcast room through the view layer.

[0110] Optionally, upon successfully claiming the red envelope, the view model layer transitions the red envelope status from the claiming state to the waiting-for-result state. At this point, the view layer displays the red envelope component in the waiting-for-result state, for example, showing a countdown animation for the lottery draw.

[0111] Optionally, after the countdown animation ends, a delayed query is initiated through the view model layer. At this time, the view model layer can query the server for the red envelope lottery results. Optionally, when multiple red envelope components exist, the view model layer polls the server for results in a round-robin fashion. It can be understood that if the red envelope is successfully drawn, the view model layer can obtain the lottery results from the server and then proceed to the result display state. If the red envelope is not drawn, the view model layer can also obtain the undrawn results from the server, and then the view model layer can re-query after a preset delay.

[0112] Step 4055: When the waiting result status is complete, display the red envelope component in the result display status in the live broadcast interface of the current live broadcast room through the view layer.

[0113] Optionally, upon successfully obtaining the lottery results, the view model layer transitions the red envelope status from the waiting-for-results state to the results-display state. At this point, the view layer displays the red envelope component in the results-display state. For example, it displays the claim results, such as "won," "did not win," or a list of winners.

[0114] In this way, by maintaining the interactive state and executing the state transition logic through the view model layer, the view layer can be promptly notified to update the display style when the interactive state changes, thereby driving the red envelope component to display the visual effects of the corresponding interactive state. For example... Figure 5B As shown, the view layer can sequentially display the red packet components corresponding to the interactive states according to the state transition path. During this process, since the display styles of backgrounds, colors, icons, etc., involved in different interactive states may be different, it is necessary to extract the display styles required for the current interactive state from the interactive display configuration issued by the server and apply them to the red packet components of the current interactive state.

[0115] Please refer to Figure 6 This diagram illustrates the overall architecture of a live interactive system provided in an exemplary embodiment of this application. The live interactive system includes a server and a client. The client's architecture comprises a data layer, a view model layer, and a view layer. The data layer is used to implement data transmission between the server and the client.

[0116] The view model layer includes a first view model and second view models corresponding to each interactive component. The first view model is used to centrally manage the state data and interactive display configurations of each interactive component. Optionally, the first view model can obtain the state data and interactive display configurations of the interactive components sent by the server through the data layer.

[0117] Optionally, the server can send the status data and interactive display configuration of the interactive component to the client by pushing socket messages, or it can carry the status data and interactive display configuration of the interactive component in the response information when responding to the client's API call request.

[0118] Optionally, a LiveData object is created in the first view model to observe updates to the interactive display configuration. A LiveData object is also created in the second view model to observe updates to the interactive state of the interactive components.

[0119] Optionally, the first view model, through updates to the interactive display configuration observed by the LiveData object, drives the view layer to update the display style of interactive components. The second view model, through updates to the interactive state observed by the LiveData object, drives the view layer to update the display of interactive components in the corresponding interactive state.

[0120] Optionally, the interactive display configuration updates of interactive components of the same type can be implemented using the interactive delegate pattern. For example, the interactive display configuration updates of the red envelope component are implemented through the interactive delegate RedEnvelopeDelegate, and the interactive display configuration updates of the widget component are implemented through the interactive delegates RightTopPendantDelegate and RedAppearAnimDelegate.

[0121] Optionally, the client can connect to the server through an interactive delegate. After obtaining the interactive display configuration sent by the server through the delegate, the client can distribute it to the first view model.

[0122] Please refer to Figure 7 The diagram illustrates an overall flowchart of a live interactive method provided in an exemplary embodiment of this application.

[0123] Step 701: Obtain the interactive display configuration sent by the server through the interactive proxy.

[0124] Optionally, when a user triggers the sending of a red envelope, the interaction delegate calls the configuration request method `viewModel.requestRedEnvelopeConfig` of the first view model to send a configuration retrieval request to the server. After a successful callback, the interaction delegate can retrieve the interactive display configuration sent by the server.

[0125] Step 702: Invoke the configuration update method of the first view model through the interactive proxy.

[0126] Optionally, the configuration update method updateSkin(entity:RedEnvelopeSkinEntity?) can be invoked via the interaction proxy to post the interaction display configuration to the _skin field.

[0127] Step 703: In response to the method call, update the interactive display configuration through the first view model.

[0128] Optionally, after the _skin field is updated via the first view model, the _skin update can be observed via the LiveData object, and then the same UI component in the view layer is automatically notified.

[0129] Step 704: Notify the view layer that the interactive display configuration has been updated through the first view model.

[0130] Step 705: Apply interactive display configuration through the view layer.

[0131] Step 706: Preload the image resources of the dialog box in the interactive display configuration through the view layer.

[0132] Optionally, when a user triggers the sending of a red envelope, the view layer preloads the image resources required for the red envelope sending dialog box.

[0133] Step 707: After preloading is complete, create and display the dialog box through the view layer, and apply the dialog box display style from the interactive display configuration.

[0134] In this way, by using a preloading mechanism for critical configuration resources (such as the top image of the dialog box), we can ensure that the resources are in place when the UI is displayed, thus avoiding blank or flickering during the loading process.

[0135] The lifecycle of a network request is bound to the lifecycle of the view model. In related technologies, the interactive functions of live streaming rooms often adopt the MVC / MVP architecture, which suffers from complex state management and coupling between business logic and UI. Furthermore, network requests are usually initiated directly by Activities or Fragments, and request cancellation is manually managed in their lifecycle callbacks. This can easily lead to oversights, resulting in UI destruction or Activity leaks when the request callback occurs. For example, during page switching (such as changing rooms), outdated requests may continue to be callbacked and attempt to update views that have already been destroyed, causing errors or wasting resources.

[0136] To address the aforementioned issues, this embodiment of the application binds network requests to the lifecycle of the view model layer. This allows all requests sent to the server through the view model layer to be cancelled even when the view model layer's lifecycle state is in a destroyed state.

[0137] Optionally, the view model layer's lifecycle state being in a destroyed state could mean that the current live stream's lifecycle state is destroyed when switching to another live stream. In this case, when switching to another live stream, all requests sent to the server through the view model layer corresponding to the current live stream are cancelled.

[0138] Optionally, the client can create a network request management base class, FANetViewModel, in the view model layer, which inherits from Android ViewModel, enabling it to automatically manage the lifecycle of network requests. Its core mechanism is to maintain a list of weak references (refs) for network request sessions and a session map (refMap) with the request ID (ReqId) as the key. This FANetViewModel base class provides the async() and sync() methods for initiating network requests.

[0139] Optionally, the ViewModel related to interactive components inherits from FANetViewModel. For example, the RedEnvelopeViewModel and RedEnvelopeListViewModel of the red envelope component both inherit from FANetViewModel. As a result, all network request APIs (such as requestRedEnvelopeConfig and requestRedEnvelopePendant) are refactored into extension functions of FANetViewModel, thereby binding the request lifecycle to the ViewModel.

[0140] The request ID is used to check if the requests are the same. Optionally, when two requests initiated through the view model layer are for the same content, the two requests have the same ID.

[0141] In some embodiments, when there is a request to send, the client can use the FANetViewModel in the view model layer to manage network requests and search for a target request that matches the current request to be sent from the unfinished historical requests. Optionally, the client can check if the request ID of the current request to be sent exists through the session map (refMap). If it exists, it means that there is a target request that matches the current request to be sent from the unfinished historical requests, i.e., there is a duplicate request. If it does not exist, it means that there is no target request that matches the current request to be sent from the unfinished historical requests.

[0142] Optionally, if the target request is found in the incomplete historical request list, the client can cancel the incomplete target request through the FANetViewModel network request management in the view model layer. In this case, the client can send a notification to the server through the FANetViewModel network request management in the view model layer to notify the server to cancel the target request.

[0143] Optionally, if the target request is successfully cancelled, the client can send the currently pending request to the server through the FANetViewModel network request management in the view model layer.

[0144] Optionally, the first view model includes the aforementioned network request management to maintain a session mapping (refMap) for each second view model, with the request ID (ReqId) as the key. This avoids multiple interactive components repeatedly initiating the same image network request.

[0145] Optionally, the second view model may also include the aforementioned network request management to maintain a session mapping (refMap) of the second view model with the request ID (ReqId) as the key. This can prevent it from repeatedly initiating the same request.

[0146] Please refer to Figure 8 The diagram illustrates a network request management flowchart in a live interactive method provided by an exemplary embodiment of this application.

[0147] Step 801: Through the view layer, initiate a network request carrying the request identifier ID to the network request management in the view model.

[0148] For example, you can initiate a network request to download the top image directly through an Activity or Fragment using the method async(viewModel, id, callback).

[0149] Step 802: Check whether there is a target request matching the request identifier in the historical sent requests through the network request management in the view model.

[0150] Optionally, the network request management in the view model can be used to detect whether a target request with the same request ID exists in the session map (refMap) maintained by the view model. The session map (refMap) maintained by the view model records incomplete historical requests.

[0151] Step 803: If a target request exists, cancel the target request to the server through network request management in the view model. That is, cancel the target request session.

[0152] Step 804: Remove the target request from the recorded history of sent requests.

[0153] Optionally, the target request with the same request ID can be removed from the session map (refMap) maintained by the view model through network request management in the view model, that is, the request session of the target request can be removed.

[0154] Step 805: Send the network request to the server through the network request management in the view model. At this time, a new request session will be generated.

[0155] Step 806: Record the network request in the historical sent requests through network request management in the view model.

[0156] Optionally, through network request management in the view model, the request session of the currently newly sent network request can be recorded in the session map (refMap) maintained by the view model, using the request ID as the key.

[0157] Step 807: Trigger the end of the view model's lifecycle through the view layer.

[0158] For example, when a user switches live stream rooms, it triggers the end of the view model's lifecycle.

[0159] Optionally, calling the onCleared() method through the view layer triggers the end of the view model's lifecycle.

[0160] Step 808: Cancel all requests sent to the server through the view model via network request management in the view model.

[0161] Optionally, network request management in the view model can be used to iterate through and cancel all requests sent to the server through the view model layer.

[0162] Optionally, in response to a call to the onCleared() method, the network request management in the view model will automatically traverse and cancel all tracked request sessions and coroutine continuations.

[0163] In one possible implementation, network request management in the view model iterates through all requests in the session map (refMap) and the weak reference list (refs) of the network request session, using the request ID as the key, and cancels the request session for each incomplete request. Then, the session map (refMap) and the weak reference list (refs) are cleared.

[0164] In this way, by managing the FANetViewModel base class through network requests, the lifecycle of network requests and the ViewModel is automatically bound, effectively solving the problems of request backlog, callback exceptions, and potential memory leaks during page switching (especially live room switching). At the same time, the automatic cancellation mechanism with IDs for requests avoids duplicate requests and resource contention.

[0165] This solution, through an MVVM architecture and server-side interactive display configuration, completely decouples business logic, state management, and visual presentation. It resolves issues such as high code coupling, rigid UI styles, inability to support dynamic skinning, and memory leaks caused by poor network request resource management in traditional implementations. This significantly improves maintainability, visual personalization, and system stability. It also separates operational needs from client-side development, enhancing the overall system's flexibility and maintainability.

[0166] Please refer to Figure 9 This illustration shows a structural block diagram of a live interactive device provided in an exemplary embodiment of this application. The device includes: The first acquisition module 901 is used to acquire the interactive display configuration sent by the server. The interactive display configuration is used to configure the display style of the interactive components in the live broadcast room under different interactive states. The interactive components include at least two interactive states and there is a state transition between different interactive states. The second acquisition module 902 is used to acquire the target display style corresponding to the current interaction state from the interaction display configuration based on the current interaction state of the interactive component in the current live broadcast room. The execution module 903 is used to display the interactive component in the current interactive state in the target display style in the live broadcast interface of the current live broadcast room.

[0167] Optionally, the client architecture includes a data layer, a view layer, and a view model layer. The first acquisition module 901 is used for: The interactive display configuration sent by the server is read from the data layer through the view model layer; The second acquisition module 902 is used for: The interactive display configuration is sent to the view layer through the view model layer; Through the view layer, the target display style corresponding to the current interaction state is obtained from the interaction display configuration based on the current interaction state of the interactive component in the current live room.

[0168] Optionally, the current live stream room includes at least one of the interactive components, and the view model layer includes a first view model and a second view model corresponding to each of the at least one interactive component, wherein the second view model is used to store the interaction state of the interactive component; the device further includes a state determination module, used for: The status data sent by the server is read from the data layer through the first view model; The state data is distributed to each of the second view models through the first view model; The current interaction state of each interactive component in the current live broadcast room is determined based on the state data through each of the second view models. The current interaction state of each interactive component is sent to the view layer through each of the second view models.

[0169] Optionally, the first acquisition module 901 is used for: The interactive display configuration sent by the server is read from the data layer using the first view model. The second acquisition module 902 is used for: The interactive display configuration is sent to the view layer through the first view model.

[0170] Optionally, the status determination module is used for: Based on the state data and the state transition path of each interactive component, the current interactive state of each interactive component in the current live broadcast room is determined using each of the second view models.

[0171] Optionally, the current live stream room includes a first interactive component, and the state transition path of the first interactive component includes a transition from a first interactive state to a second interactive state; the state determination module is used for: When the status data indicates that the first interactive state of the first interactive component has been completed, in response to the status data, the second interactive state is determined to be the current interactive state of the first interactive component in the current live broadcast room through the second view model corresponding to the first interactive component.

[0172] Optionally, the device further includes a configuration trigger module for: Upon entering the current live stream room, a configuration retrieval request is sent to the server through the view model layer. This configuration retrieval request instructs the server to send the interactive display configuration; or... In response to the triggering operation of the interactive component in the current live room, a configuration retrieval request is sent to the server through the view model layer. The configuration retrieval request is used to instruct the server to send the interactive display configuration.

[0173] Optionally, the device further includes a request management module for: When there is a request to send, the view model layer searches for a target request that matches the current request to be sent from the unfinished historical requests. If the target request is found in the incomplete historical request list, the target request is cancelled through the view model layer. If the target request is successfully cancelled, the current request to be sent is sent to the server through the view model layer.

[0174] Optionally, the request management module is also used for: If the lifecycle state of the view model layer is in the destroyed state, cancel all requests sent to the server through the view model layer.

[0175] Optionally, a request management module is used for: When switching to another live stream room, cancel all requests sent to the server through the view model layer corresponding to the current live stream room.

[0176] Optionally, execution module 903 is used for: If the target display style includes image resources, the image resources are preloaded through the view layer; Through the view layer, the interactive components in the current interactive state are displayed in the live broadcast interface of the current live broadcast room according to the target display style and the preloaded image resources.

[0177] Optionally, the second acquisition module 902 is used for: If the target display style corresponding to the current interactive state exists in the interactive display configuration, the target display style is obtained from the interactive display configuration.

[0178] Optionally, the second acquisition module 902 is also used for: If the target display style corresponding to the current interactive state does not exist in the interactive display configuration, the default display style corresponding to the current interactive state is obtained from the local storage space.

[0179] In summary, the system can obtain the interactive display configuration sent by the server. This configuration is used to set the display style of interactive components in the live stream under different interactive states. Each interactive component contains at least two interactive states with transitions between them. Based on the current interactive state of the component in the live stream, the system can retrieve the target display style corresponding to that state from the configuration, allowing the component to be displayed in the live stream interface with the target style. This allows the interactive process of a component to be described using multiple interactive states. The server can send display style configurations for each component in different interactive states at the component level. When the client needs to display an interactive component, it can directly read the required display style from the server's configuration based on the current interactive state, thus changing the visual effect of the component in real time. This supports personalized configuration updates for various operational scenarios such as holiday events and brand collaborations, without requiring client version updates, greatly improving operational flexibility and user experience.

[0180] It should be noted that the apparatus provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and their implementation process can be found in the method embodiments, which will not be repeated here.

[0181] See Figure 10 , Figure 10 This is a schematic diagram of the structure of a terminal provided in an exemplary embodiment of this application. The terminal may also include one or more of the following components: processor 1010, memory 1020, and communication component 1030.

[0182] Optionally, the processor 1010 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1020, and by calling data stored in the memory 1020. Optionally, the processor 1010 can be implemented in at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA).

[0183] The processor 1010 can integrate one or more of the following: a central processing unit (CPU), a graphics processing unit (GPU), a neural network processing unit (NPU), and a baseband chip. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content displayed on the touchscreen; the NPU implements artificial intelligence (AI) functions; and the baseband chip handles wireless communication. It is understood that the baseband chip can also be implemented as a separate chip without being integrated into the processor 1010.

[0184] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include a non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1020 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function, instructions for implementing the various method embodiments described above, etc.; the data storage area may store data created based on the use of the electronic device, etc.

[0185] Optionally, the communication component 1030 is a component used to enable communication between the terminal and the server. After the terminal communicates with the server through the communication component 1030, data transmission between the terminal and the server can be realized.

[0186] In addition, those skilled in the art will understand that the structure of the terminal shown in the above figures does not constitute a limitation on the terminal. The terminal may include more (e.g., power supply components, display components, sensor components) or fewer components than shown, or combine certain components, or have different component arrangements.

[0187] This application provides a computer-readable storage medium storing at least one computer instruction, which is executed by a processor to implement the live interactive method as described in the above embodiments.

[0188] On the other hand, this application provides a computer program product, which includes computer instructions. A processor executes the computer instructions to implement the live interactive method as described in the above embodiments.

[0189] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0190] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A live streaming interactive method, characterized in that, Applied to a client, the method includes: Obtain the interactive display configuration sent by the server. The interactive display configuration is used to configure the display style of interactive components in the live room under different interactive states. The interactive components include at least two interactive states and there is a state transition between different interactive states. Based on the current interaction status of the interactive components in the current live broadcast room, obtain the target display style corresponding to the current interaction status from the interaction display configuration; In the live streaming interface of the current live streaming room, the interactive components in the current interactive state are displayed in the target display style.

2. The method according to claim 1, characterized in that, The client-side architecture comprises a data layer, a view layer, and a view model layer. The step of obtaining the interactive display configuration sent by the server includes: The interactive display configuration sent by the server is read from the data layer through the view model layer; The step of obtaining the target display style corresponding to the current interaction state from the interaction display configuration based on the current interaction state of the interactive components in the current live broadcast room includes: The interactive display configuration is sent to the view layer through the view model layer; Through the view layer, the target display style corresponding to the current interaction state is obtained from the interaction display configuration based on the current interaction state of the interactive component in the current live room.

3. The method according to claim 2, characterized in that, The current live stream room contains at least one of the interactive components. The view model layer contains a first view model and a second view model corresponding to each of the at least one interactive component. The second view model is used to store the interaction state of the interactive component. The method further includes: The status data sent by the server is read from the data layer through the first view model; The state data is distributed to each of the second view models through the first view model; The current interaction state of each interactive component in the current live broadcast room is determined based on the state data through each of the second view models. The current interaction state of each interactive component is sent to the view layer through each of the second view models.

4. The method according to claim 3, characterized in that, The step of reading the interactive display configuration sent by the server from the data layer through the view model layer includes: The interactive display configuration sent by the server is read from the data layer using the first view model. Sending the interactive display configuration to the view layer through the view model layer includes: The interactive display configuration is sent to the view layer through the first view model.

5. The method according to claim 3, characterized in that, The step of determining the current interaction state of each interactive component in the current live broadcast room based on the state data through each of the second view models includes: Based on the state data and the state transition path of each interactive component, the current interactive state of each interactive component in the current live broadcast room is determined using each of the second view models.

6. The method according to claim 5, characterized in that, The current live broadcast room includes a first interactive component, and the state transition path of the first interactive component includes a transition from a first interactive state to a second interactive state. The step of determining the current interactive state of each interactive component in the current live broadcast room through each of the second view models, based on the state data and the state transition path of each interactive component, includes: When the status data indicates that the first interactive state of the first interactive component has been completed, in response to the status data, the second interactive state is determined to be the current interactive state of the first interactive component in the current live broadcast room through the second view model corresponding to the first interactive component.

7. The method according to any one of claims 2-6, characterized in that, Before reading the interactive display configuration sent by the server from the data layer through the view model layer, the method further includes: Upon entering the current live stream room, a configuration retrieval request is sent to the server through the view model layer. This configuration retrieval request instructs the server to send the interactive display configuration; or... In response to the triggering operation of the interactive component in the current live room, a configuration retrieval request is sent to the server through the view model layer. The configuration retrieval request is used to instruct the server to send the interactive display configuration.

8. The method according to any one of claims 2-7, characterized in that, The method further includes: When there is a request to send, the view model layer searches for a target request that matches the current request to be sent from the unfinished historical requests. If the target request is found in the incomplete historical request list, the target request is cancelled through the view model layer. If the target request is successfully cancelled, the current request to be sent is sent to the server through the view model layer.

9. The method according to any one of claims 2-8, characterized in that, The method further includes: If the lifecycle state of the view model layer is in the destroyed state, cancel all requests sent to the server through the view model layer.

10. The method according to claim 9, characterized in that, When the lifecycle state of the view model layer is in the destroyed state, cancel all requests sent to the server through the view model layer, including: When switching to another live stream room, cancel all requests sent to the server through the view model layer corresponding to the current live stream room.

11. The method according to any one of claims 2-10, characterized in that, Displaying the interactive components in the current interactive state in the target display style on the live streaming interface of the current live streaming room includes: If the target display style includes image resources, the image resources are preloaded through the view layer; Through the view layer, the interactive components in the current interactive state are displayed in the live broadcast interface of the current live broadcast room according to the target display style and the preloaded image resources.

12. The method according to any one of claims 1-11, characterized in that, The step of obtaining the target display style corresponding to the current interaction state from the interaction display configuration includes: If the target display style corresponding to the current interaction state exists in the interactive display configuration, the target display style is obtained from the interactive display configuration; The method further includes: If the target display style corresponding to the current interactive state does not exist in the interactive display configuration, the default display style corresponding to the current interactive state is obtained from the local storage space. In the live streaming interface of the current live streaming room, the interactive components in the current interactive state are displayed in the default display style.

13. A terminal, characterized in that, The terminal includes a processor and a memory, the memory storing at least one computer instruction, which is loaded and executed by the processor to implement the live interactive method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer instruction, which is executed by a processor to implement the live interactive method as described in any one of claims 1 to 12.

15. A computer program product, characterized in that, The computer program product includes computer instructions, which are executed by a processor to implement the live interactive method as described in any one of claims 1 to 12.

Images