Media content playing management method and device, electronic equipment and readable storage medium

Abstract

The invention discloses a media content playing management method, which comprises the following steps that: a player cache pool is created, and the player states of players in the cache pool comprise a preloading state, a playing state and a leaving state; monitoring a sliding operation of a user on the media content page; according to the sliding direction of the sliding operation and the state of the player, the player is selected from the player cache pool and bound to a target page, and the target page is a page to be displayed. The player is bound with the life cycle of a media content page, and the sliding trend change of a user is monitored, so that different player cache recovery strategies are formulated. The upper limit of the cache number of the player is reduced, the memory usage in the video playing scene is effectively reduced, the overall memory use efficiency of the system is improved, and the situations of application lagging or abnormal exit and the like caused by the memory problem are avoided.

Description

Technical Field

[0001] This application relates to the field of computers, specifically to a media content playback management method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Currently, in most immersive short video scenarios, such as Douyin and Xiaohongshu, to improve user experience and avoid loading delays when users swipe to new videos, a player is usually pre-built and video cache is pre-loaded. This approach trades increased memory usage for a smoother experience, but different users have different device performance and memory sizes, making it impossible to expand the cache indefinitely.

[0003] However, existing technical solutions have some shortcomings in implementation. First, existing solutions always require creating an additional player cache, which consumes more memory, especially when memory is insufficient, easily leading to application lag or abnormal exits. Second, when the user swipes the list, the system attempts to create new pages and reclaim old ones, resulting in frequent creation and destruction of the player, increasing system overhead; furthermore, when the swipe direction changes, it is easy for the player to preempt the currently playing player, causing page errors. Summary of the Invention

[0004] In view of this, this application provides a media content playback management method, device, electronic device, and computer-readable storage medium, which intuitively reflects the spatial distribution of the virtual backpack through a capacity occupancy heatmap, shortening the time for users to find target areas in the virtual backpack; at the same time, it combines the space management of the virtual backpack with the scroll bar function, making it convenient for players to perform quick item transfer operations.

[0005] In a first aspect, embodiments of this application provide a media content playback management method, the method comprising: Create a player cache pool, where the player states of the players in the cache pool include preload state, playback state, and exit state; Monitor user swiping actions on media content pages; Based on the swipe direction and player state, select a player from the player cache pool and bind it to the target page, which is the page that will be displayed.

[0006] Secondly, embodiments of this application provide a media content playback management device, which includes: a creation unit, a monitoring unit, and a selection unit; The creation unit is used to create a player cache pool, where the player states of the players in the cache pool include preload state, playback state, and exit state. The listening unit is used to monitor the user's swiping actions on the media content page; The selection unit is used to select a player from the player cache pool and bind it to the target page, which is the page that will be displayed, based on the swipe direction and player state.

[0007] Thirdly, embodiments of this application provide an electronic device, including: Processor; and The memory is used to store data processing programs, which, when the electronic device is powered on and run by the processor, execute the method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a data processing program that is executed by a processor to perform the method as described in the first aspect.

[0009] The media content playback management method provided in this application creates a player cache pool, wherein the player states of the players in the cache pool include preload state, playback state, and exit state; listens for user swiping operations on the media content page; and selects a player from the player cache pool and binds it to the target page, which is the page to be displayed, based on the swiping direction and the player state.

[0010] In this embodiment, by binding the lifecycle of the player to the media content page and monitoring changes in user scrolling trends, different player cache recycling strategies are formulated. This reduces the upper limit of the player cache size, effectively lowering memory usage in video playback scenarios, improving overall system memory efficiency, and preventing application stuttering or abnormal exits due to memory issues. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 An example system architecture diagram for implementing a media content playback management method provided in this application embodiment; Figure 2 A flowchart illustrating an example of a media content playback management method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a media content page in the prior art; Figure 4 A schematic diagram of a media content page provided in an embodiment of this application; Figure 5A flowchart illustrating an example of a media content playback management method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of the media content playback management device provided in the embodiments of this application; Figure 7 This application provides a structural block diagram of an electronic device for implementing a media content playback management method. Detailed Implementation

[0013] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0014] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0015] It should be understood that in the embodiments of this application, "at least one" refers to one or more, "several" refers to one or more, and "more than" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "Contains A, B, and / or C" means containing any one, two, or three of A, B, and C.

[0016] It should be understood that in the embodiments of this application, "B corresponding to A", "B corresponding to A", "A corresponds to B" or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0017] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0018] Based on the problems described above, embodiments of this application provide a media content playback management method, apparatus, electronic device, and computer-readable storage medium.

[0019] The media content playback management method provided in this application can be executed by an electronic device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, or other similar device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can be hardware or software. When the server is hardware, it can be implemented as a distributed server cluster composed of multiple servers or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., software or software modules used to provide distributed services) or as a single software program or software module. This application does not specifically limit this aspect.

[0020] For example, in conjunction with the above description, Figure 1This illustration shows a system architecture diagram for implementing a media content playback management method according to an embodiment of this application. The system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, or other similar device. It has a display function and can display a graphical user interface, which may include the operating system interface or the application interface. An application, such as a video application, is installed on the terminal device 110. The server 120 generally refers to the backend system providing the video service in this exemplary embodiment; it may be a single server or a cluster of multiple servers. Exemplarily, a server-side program is deployed on the server 120 to perform server-side data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this disclosure can be executed by any one or more of the terminal device 110 and the server 120.

[0021] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to perform management functions and execute the method described above.

[0022] According to one embodiment of this disclosure, a media content playback management method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0023] like Figure 2 As shown, Figure 2 This is an example flowchart of a media content playback management method provided in an embodiment of this application. It should be noted that the steps shown may be executed in a different logical order than that shown in the flowchart. The method may include the following steps S210 to S250.

[0024] Step S210: Create a player cache pool, wherein the player states of the players in the cache pool include preload state, playback state, and exit state; Step S230: Listen for user swiping actions on the media content page; Step S250: Based on the sliding direction of the sliding operation and the player state, select a player from the player cache pool and bind it to the target page, which is the page that will be displayed.

[0025] By binding the player's lifecycle to the media content page and monitoring changes in user scrolling trends, different player cache recycling strategies can be formulated. Reducing the upper limit of the player's cache size effectively lowers memory usage in video playback scenarios, improves overall system memory efficiency, and prevents application stuttering or abnormal exits due to memory issues.

[0026] Next, we will provide a detailed introduction to steps S210 to S250.

[0027] Step S210: Create a player cache pool, wherein the player states of the players in the cache pool include preload state, playback state, and exit state.

[0028] In this exemplary embodiment, the purpose of creating a player cache pool is to manage and reuse player resources, avoiding the performance overhead caused by frequently creating and destroying players. The player states in the cache pool are divided into preload, playing, and leaving states, each corresponding to a different stage of the page lifecycle. The preload state indicates that the player is ready but has not yet started playing; the playing state indicates that the player is playing video; and the leaving state indicates that the page containing the player has been scrolled out of the current display. By monitoring the user's scrolling actions on the media content page, the user's scrolling direction can be obtained in real time, allowing the appropriate player to be selected for reuse based on the scrolling direction and player state. The target page refers to the page the user is about to see. By binding the player to the target page, it can be ensured that the user can watch the video smoothly during scrolling.

[0029] In this exemplary embodiment, the capacity of the player cache pool can be set according to actual needs. By comprehensively considering various factors, more efficient player cache management can be achieved, thereby improving the user's viewing experience.

[0030] Optionally, the player cache pool capacity can be determined based on the number of media content pages cached. As the number of pages the application needs to cache increases, the player cache pool capacity will increase accordingly to ensure that each page has a player. Conversely, when the number of pages decreases, the player cache pool capacity will decrease, thereby freeing up excess memory resources.

[0031] Optionally, the capacity of the player cache pool can be determined based on the device's performance and memory size. For example, when the device has sufficient memory, the capacity of the cache pool can be increased appropriately to improve the caching effect; when the device has limited memory, the capacity of the cache pool can be reduced appropriately to avoid stuttering caused by insufficient memory.

[0032] Optionally, the capacity of the player cache pool can be determined based on network conditions. For example, when the network conditions are good, the number of players in the preload state can be increased to improve the caching effect; when the network conditions are poor, the number of players in the preload state can be reduced to avoid stuttering caused by network latency.

[0033] Optionally, the size of the player cache pool can be determined based on user habits. For example, if users frequently pause and resume videos, the number of players in playback mode can be increased to improve the user experience. Similarly, if users frequently perform fast swiping, the number of players in preload mode can be increased to improve the smoothness of swiping.

[0034] Step S230: Listen for the user's swiping actions on the media content page.

[0035] In this exemplary embodiment, by listening to the user's swipe operation, the user's swipe direction can be obtained in real time, thereby selecting a suitable player for reuse based on the swipe direction and the player's state. The swipe direction can be determined by detecting the user's swipe trajectory.

[0036] Step S250: Based on the sliding direction of the sliding operation and the player state, select a player from the player cache pool and bind it to the target page, which is the page that will be displayed.

[0037] In this exemplary embodiment, the target page refers to the page the user is about to see. By binding the player to the target page, it can be ensured that the user can watch the video smoothly during swiping. The target page can be determined by the swiping direction and page position. For example, when the user swipes up, the target page is the next page after the current page; when the user swipes down, the target page is the previous page of the current page. By properly managing the player cache, unnecessary player creation can be reduced, memory usage efficiency can be improved, and the user experience can be enhanced.

[0038] In this exemplary embodiment, selecting a player from the player cache pool and assigning it to the target page based on the swiping direction and the player state includes: When it is detected that the direction of the user's current swipe operation is the same as the direction of the previous swipe operation, the player that is in the "away" state is selected and assigned to the target page; When it is detected that the direction of the user's current swipe operation is opposite to the direction of the previous swipe operation, the player in the preloaded state is selected and assigned to the target page.

[0039] By selecting the appropriate player based on the user's swipe direction, the number of player creations can be effectively reduced, memory usage efficiency can be improved, and stuttering issues caused by insufficient memory can be avoided.

[0040] When a user swipes on a media content page, the system detects the direction of the current swipe and compares it to the direction of the previous swipe. If the current swipe direction matches the previous one, the system selects a player in a "Leaving" state to assign to the target media content page. A "Leaving" player is one that has already played content and left the current display screen, thus fully utilizing existing player resources and avoiding the creation of a new player, thereby saving memory. If the current swipe direction is opposite to the previous one, the system selects a player in a "Preload" state to assign to the target media content page. A "Preload" player is one that has been preloaded but not yet played, ensuring that the user can quickly see previously preloaded content when swiping in the opposite direction, improving the user experience.

[0041] Most existing solutions use the Least Recently Used (LRU) algorithm to pre-cache three to four pages within a video stream. As the page scrolls, the player data from destroyed pages is continuously recycled and reused for the next preloaded page. In other words, existing solutions technically always require creating an additional player cache, consuming more memory and making them more prone to stuttering and buffering issues in scenarios with insufficient memory. Figure 3 This is a schematic diagram of a media content page in the prior art, such as... Figure 3 As shown, suppose the video stream caches three pages: Fragment2 is playing, Fragment3 is preloading, and Fragment1 has finished playing. When a page is created, it attempts to acquire a player for video preloading. When a page is destroyed, a player is recycled to the cache pool and marked as unused. When swiping the list to view the next video, when loading a new page (Fragment4), the system first creates a new page, and the old page awaits recycling. Therefore, a list can contain a maximum of four pages simultaneously, and the corresponding player remains idle in the cache pool after a page is recycled, occupying additional memory. If this were changed to a maximum of three players, during vertical swiping, one player would need to be preempted for use by the new page. With the current logic, when directional swiping occurs, it's easy for the currently playing player to be preempted, leading to page errors.

[0042] This application binds the player's lifecycle to that of the Fragment, monitoring changes in user scrolling patterns to formulate different player cache recycling strategies. For example... Figure 4 As shown, Figure 4This is a schematic diagram of a media content page provided in an embodiment of this application. In the initial state, the media content page includes three pages: Fragment1 is a page that has been played and has left the current display interface, and the player state of the player corresponding to this page is Leaving; Fragment2 is the page currently displayed on the display interface, and the player state of the player corresponding to this page is Playing; and Fragment3 is a page that has not yet been played but has been preloaded, and the player state of the player corresponding to this page is Preload.

[0043] When swiping through media content pages in the same direction (e.g., swiping up before and again), the user will see the pre-loaded page Fragment3. Therefore, the Leaving player is reused first, utilizing existing player resources and avoiding the creation of a new player. When swiping in reverse direction (e.g., swiping up before and now swiping down), the user will see the already viewed page Fragment1, so the Preload player should be reused first. This allows for the reuse of players that are not intended to be used, thus avoiding the need to create an additional player, improving memory efficiency, and preventing stuttering issues caused by insufficient memory.

[0044] Players in the "away" state have already played content and occupy memory resources but no longer provide actual playback functionality; players in the "preload" state have not yet played content but have been preloaded, occupying memory resources but can quickly provide playback functionality. This dynamic adjustment strategy can effectively cope with the different needs brought about by different swipe directions, improving the overall system performance and user experience.

[0045] In this exemplary embodiment, the method further includes: obtaining a player from the player cache pool according to a preset priority rule, wherein the priority rule includes: prioritizing obtaining a player that is currently in use on the same page; if no player is used on the same page, obtaining an unused player from the player cache pool; and if there are not enough unused players in the player cache pool, creating a new player.

[0046] Optional, such as Figure 5 As shown, Figure 5 This is a flowchart illustrating an example of a media content playback management method provided in an embodiment of this application. When a page requires a player, the system prioritizes retrieving a player currently in use on the same page; if no player is being used on the same page, it retrieves an unused player from the player cache pool; if the unused player in the player cache pool is insufficient, a new player is created; if the player cache pool reaches its maximum capacity, a player is selected based on the direction of the swipe operation.

[0047] Optionally, this player allocation strategy is not only applicable to media content playback management but can also be extended to other scenarios requiring dynamic resource management. For example, in game development, the allocation strategy for game resources can be dynamically adjusted based on the user's scrolling direction, improving game smoothness and user experience. In web browsing, the loading strategy for page resources can be dynamically adjusted based on the user's scrolling direction, improving page loading speed and user experience. In this way, the system can flexibly respond to different needs in different scenarios, improving the overall system performance and user experience.

[0048] Optionally, to further improve system performance and user experience, machine learning algorithms can be introduced to predict user swiping behavior. By analyzing users' swiping history data, the system can predict the user's next swipe direction and thus pre-select and allocate appropriate players. For example, if the system predicts that the user will swipe in the same direction, it can pre-select a player in the "away" state; if the system predicts that the user will swipe in the opposite direction, it can pre-select a player in the "pre-loaded" state. In this way, the system can intelligently adjust the player allocation strategy, improving system response speed and user experience.

[0049] In this exemplary embodiment, the method further includes: when the lifecycle of the target page enters the destruction phase, releasing the player bound to the target page and returning it to the player cache pool.

[0050] Optionally, when the target media content page enters the destruction phase of its lifecycle, meaning the page no longer needs to be displayed and its corresponding player no longer needs to occupy memory resources, the system will automatically trigger a page destruction operation, removing the page from memory. During this process, the system will check whether the page is bound to a player. If so, the player will be detached from the page and returned to the player cache pool. This effectively reclaims unused players, ensuring that player resources are used rationally, reducing memory consumption, avoiding unnecessary memory waste, and improving the efficiency of system resource utilization. For example, when a user scrolls to a new page, the player on the old page will be released and returned to the cache pool so that the new page can reuse these players first, thereby reducing the number of times new players are created and improving the overall performance of the system. In addition, this method ensures that the number of players in the player cache pool remains within a reasonable range, avoiding memory problems caused by an excessive number of players.

[0051] In this exemplary embodiment, the method further includes updating the player state according to changes in the lifecycle of the media content page.

[0052] Optionally, the lifecycle changes of a media content page refer to the transitions between different states, such as the process from creation to destruction. These lifecycle changes include, but are not limited to, the page creation phase (onCreate), interactive phase (onResume), paused phase (onPause), and destruction phase (onDestroy). In the creation phase (onCreate), the page has just been created but has not yet been interacted with by the user; in the interactive phase (onResume), the page has been loaded and the user can interact with it; in the paused phase (onPause), the page is temporarily not interactive with the user but still exists in memory; in the destruction phase (onDestroy), the page is completely removed, releasing all resources. By monitoring these lifecycle changes, the player's state can be updated in real time, ensuring the correct use of the player in different page states, ensuring efficient use of player resources, reducing unnecessary player creation and destruction, thereby optimizing memory usage and improving the user experience.

[0053] In this exemplary embodiment, updating the player state according to changes in the lifecycle of the media content page includes: marking the player state as preloaded when the media content page enters the creation phase; marking the player state as playing when the media content page enters the interactive phase; and marking the player state as exited when the media content page enters the pause phase.

[0054] The player's state is updated by listening to page lifecycle events. In the Android development framework, a Fragment is a lifecycle-aware component that can detect the current page's creation (onCreate), interactivity (onResume), pause (onPause), and destruction (onDestroy) states. The player is further categorized into three states based on its cached state: Leaving (the page has finished playing and the user has left), Playing (the currently visible page), and Preload (the page is being preloaded and hasn't started playing yet). By binding the player's lifecycle to that of the Fragment, dynamic updates to the player's state can be achieved. For example, when the page enters the creation phase (onCreate), the player state is marked as preloaded, indicating that the player is ready but has not yet started playing; when the page enters the interactive phase (onResume), the player state is marked as playing, indicating that the player is playing video; when the page enters the pause phase (onPause), the player state is marked as leaving, indicating that the player has paused playback but still exists in memory; when the page enters the destruction phase (onDestroy), the player state is marked as unused (NoPlayer), indicating that the player can be recycled to the player cache pool and reassigned to other pages.

[0055] Optionally, updating the player state ensures the rational allocation and recycling of player resources when switching between different pages. For example, when a user swipes from one page to a new page, the player state on the current page changes from playing to leaving, while the player state on the new page changes from preloading to playing. Furthermore, when a user swipes a page, the system selects an appropriate player for allocation based on the swipe direction and player state. For example, when the user swipes in the same direction, the player in the leaving state is prioritized; when the user swipes in the opposite direction, the player in the preloading state is prioritized. This ensures efficient use of player resources, enables dynamic management of player resources, reduces unnecessary player creation, thereby reducing memory usage and improving system performance.

[0056] Understandably, the relationship we perceive is as follows: when the page is interactive, the player's state is defined as Playing; the state of the previously swiped player is Leaving; and the newly loaded player is Preload. The relationship between the player and Fragment in the program: When the Fragment lifecycle reaches onCreate, the player state is defined as Preload; when it reaches onResume, the player state is defined as Playing; when the Fragment reaches onPause, the player state is defined as Leaving.

[0057] In this exemplary embodiment, the capacity of the player cache pool is determined based on the number of cached media content pages.

[0058] Optionally, the player cache pool capacity can be dynamically adjusted based on the number of cached media content stream pages to adapt to different usage scenarios. Specifically, when the number of pages that the application needs to cache increases, the player cache pool capacity will also increase accordingly to ensure that each page has a player. Conversely, when the number of pages decreases, the player cache pool capacity will decrease, thereby freeing up excess memory resources. This dynamic adjustment mechanism can be flexibly configured according to actual usage scenarios, improving the system's resource utilization. For example, when a user is browsing short videos, if the user frequently scrolls through the page, the system can automatically increase the player cache pool capacity to ensure a smooth playback experience; while when the user stays on a certain page for a long time, the system can reduce the player cache pool capacity to free up unnecessary memory resources, thereby optimizing system performance.

[0059] Optionally, the player cache pool capacity can be dynamically adjusted based on the number of cached media content stream pages to adapt to different device performance. Different user devices may have different memory capacities and processing capabilities; therefore, the player cache pool capacity needs to be adjusted according to the actual situation of the device. For example, for devices with more memory, a larger player cache pool capacity can be set to provide a better user experience; while for devices with less memory, a smaller player cache pool capacity can be set to avoid stuttering issues caused by insufficient memory.

[0060] Optionally, the player cache pool capacity can be adjusted based on the number of cached media content stream pages to optimize memory usage. In practical applications, the player cache pool capacity needs to be dynamically adjusted based on the number of cached pages to ensure that each page has a player while avoiding unnecessary memory consumption. For example, when a user scrolls through a page, the system dynamically adjusts the player cache pool capacity based on the number of currently cached pages, thereby ensuring that each page can load and play quickly. Optionally, the player cache pool size can be adjusted based on the number of cached media content stream pages to adapt to different network environments. Video loading speed and playback smoothness may vary under different network conditions. For example, a larger player cache pool size can be set under better network conditions to provide a better user experience; conversely, a smaller player cache pool size can be set under poor network conditions to reduce memory usage and improve system responsiveness.

[0061] In this exemplary embodiment, the method further includes: switching the media content page displayed in the graphical user interface in response to a swipe operation.

[0062] Optionally, in response to the swipe operation, the system switches the media content page displayed in the graphical user interface. Specifically, when the user performs a swipe operation, the system needs to accurately identify the user's swipe direction and distance to determine the next or previous media content page the user wishes to view. For example, when the user swipes up, the system recognizes that the user wishes to view the next video page; when the user swipes down, the system recognizes that the user wishes to return to the previous video page.

[0063] In this exemplary embodiment, listening to the user's swiping operation on the media content page includes: detecting and recording the swiping trajectory of the swiping operation.

[0064] Optionally, detecting and recording the swipe trajectory can include recording the movement path of the user's finger on the screen. By analyzing these paths, the user's swipe direction can be determined more accurately, such as swiping up, down, left, or right. This accurate determination helps to quickly find and assign the appropriate player when the user swipes the page, avoiding incorrect player assignment due to misjudgment of direction, thereby improving the user's viewing experience.

[0065] In this exemplary embodiment, the method further includes: determining the consistency of the sliding direction between the current sliding operation and the previous sliding operation based on the sliding trajectory and a preset threshold.

[0066] Optionally, the swipe trajectory refers to the path left by the user as they swipe across the screen, which can be obtained through touchscreen sensor data. A preset threshold is a standard value used to determine the consistency of the swipe direction, and can be adjusted according to the needs of the actual application. For example, if the user swipes from top to bottom and the vertical component of the swipe trajectory is greater than the preset threshold, it is considered a downward swipe; if the user swipes from bottom to top and the vertical component of the swipe trajectory is less than the preset threshold, it is considered an upward swipe. In this way, the user's swipe direction can be accurately determined, allowing the system to select an appropriate player for reuse. For example, when the user swipes upwards continuously, the system will prioritize reusing players that are in an abandoned state, as these players are no longer used by the current page, effectively reducing memory usage. When the user swipes in the opposite direction, the system will prioritize reusing players that are in a preloaded state, as these players have not yet been used, avoiding interference with the currently playing page.

[0067] Optionally, the consistency judgment of swipe direction can be analyzed in conjunction with the user's swipe history. For example, the system can record the user's most recent swipe operations, including swipe direction, swipe speed, and swipe time. Using this historical data, the system can more accurately predict the user's swipe intentions. For instance, if a user swipes upwards multiple times in a short period, the system can assume the user intends to browse multiple pages consecutively and can preload more players. Conversely, if a user frequently swipes backwards in a short period, the system can assume the user intends to return to the previous page and can prioritize reusing players that are already preloaded. This approach improves the system's predictive accuracy, allowing for the selection of appropriate players for reuse and enhancing the user experience.

[0068] In this exemplary embodiment, the method further includes: when the number of available players in the player cache pool does not reach a preset upper limit, creating a new player to supplement the player cache pool.

[0069] Optionally, when the number of available players in the cache pool falls below the preset limit, the system will automatically create new players to replenish the cache pool. The "preset limit" here refers to a maximum number of players pre-set based on system performance and memory size. When the number of available players in the cache pool falls below this limit, the system will detect this and automatically create new players and add them to the cache pool. This is to ensure that the system has enough players available when the user scrolls through the page, thus avoiding stuttering caused by insufficient players. For example, assuming the preset limit is 5 players and there are currently 3 available players in the cache pool, the system will detect this and automatically create 2 new players and add them to the cache pool, bringing the number of available players in the cache pool to the preset limit. In this way, the system can dynamically adjust the number of players, ensuring that new players are added promptly when the number of players in the cache pool is insufficient, thereby guaranteeing smooth system operation, avoiding stuttering caused by insufficient players, and ensuring a smooth user experience in different usage scenarios.

[0070] In this exemplary embodiment, the method further includes: when there are insufficient available players in the player cache pool, creating a new player and adding it to the player cache pool.

[0071] Optionally, a new player is created when the number of available players in the cache pool is insufficient to meet the needs of the current page. Specifically, when a user swipes to a new page, the system first checks the cache pool for available players. If no player is available, the system immediately creates a new player and adds it to the cache pool. This mechanism ensures that the system can provide new players promptly as the user swipes, thus avoiding playback stuttering or abnormalities due to insufficient players. For example, suppose a user is rapidly swiping up and down pages in a video streaming application, requiring a player for each page to load video content. If the number of players in the cache pool is insufficient, the system will immediately create a new player to meet the needs of the current page. In this way, the system can dynamically adjust the number of players, ensuring that users do not encounter a player shortage problem while swiping pages, thereby improving the user experience.

[0072] In this exemplary embodiment, the method further includes: setting a player threshold in the player cache pool, and prohibiting the creation of new players when the number of players in the cache pool reaches the threshold.

[0073] Optionally, setting a player threshold aims to rationally allocate and manage player resources when memory resources are limited. When the number of players in the cache pool reaches the preset threshold, the system will no longer create new players, but will prioritize reusing existing players. This avoids memory shortages due to an excessive number of players, which could lead to stuttering or crashes, thus improving system stability and smoothness. The threshold setting can be adjusted according to the device's memory size and performance to achieve optimal resource utilization. For example, a lower threshold can be set for devices with less memory, while a higher threshold can be set for devices with more memory to fully utilize the device's resources.

[0074] Corresponding to the media content playback management method provided in the embodiments of this application, the embodiments of this application also provide a media content playback management device 600, such as... Figure 6 As shown, Figure 6 This is a schematic diagram of the structure of a media content playback management device provided in an embodiment of this application. The device 600 includes: a creation unit 601, a monitoring unit 602, and a selection unit 603; Create unit 601 to create a player cache pool, wherein the player states of the player in the cache pool include preload state, playback state and exit state; The listening unit 602 is used to listen to the user's swiping operations on the media content page; Selection unit 603 is used to select a player from the player cache pool and bind it to the target media content page based on the sliding direction of the sliding operation and the player state. The target media content page is the page that will be displayed soon.

[0075] Corresponding to the media content playback management method provided in the embodiments of this application, the embodiments of this application also provide an electronic device 700 for implementing the media content playback management method, such as... Figure 7 As shown, the electronic device 700 includes: a processor 701; and a memory 702 for storing a program for a media content playback management method. After the device is powered on and the program for the media content playback management method is run by the processor, it executes any of the steps in the above method embodiments. For example, the following steps may be performed: Create a player cache pool, where the player states of the players in the cache pool include preload state, playback state, and exit state; Monitor user swiping actions on media content pages; Based on the swipe direction and player state, select a player from the player cache pool and bind it to the target page, which is the page that will be displayed.

[0076] Corresponding to the media content playback management method provided in the embodiments of this application, the embodiments of this application also provide a computer-readable storage medium storing a program for the media content playback management method. This program is executed by a processor to perform any of the steps described in the above method embodiments, for example, the following steps: Create a player cache pool, where the player states of the players in the cache pool include preload state, playback state, and exit state; Monitor user swiping actions on media content pages; Based on the swipe direction and player state, select a player from the player cache pool and bind it to the target page, which is the page that will be displayed.

[0077] It should be noted that for a detailed description of the apparatus, electronic device and computer-readable storage medium provided in the embodiments of this application, please refer to the relevant description of the media content playback management method embodiments provided in the embodiments of this application, which will not be repeated here.

[0078] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

[0079] In a typical configuration, an electronic device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0080] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0081] 1. Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable operations, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0082] 2. Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0083] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A media content playback management method, characterized in that, The method includes: Create a player cache pool, wherein the player states of the players in the cache pool include preload state, playback state, and exit state; Monitor user swiping actions on media content pages; Based on the sliding direction of the sliding operation and the player state, a player is selected from the player cache pool and bound to the target page, which is the page that will be displayed soon.

2. The method according to claim 1, characterized in that, The step of selecting a player from the player cache pool and assigning it to the target page based on the swiping direction and player state includes: When it is detected that the direction of the user's current swipe operation is the same as the direction of the previous swipe operation, the player in the "away" state is selected and assigned to the target page; When it is detected that the direction of the user's current swipe operation is opposite to the direction of the previous swipe operation, the player in the preloaded state is selected and assigned to the target page.

3. The method according to claim 1, characterized in that, The method further includes: When the lifecycle of the target page enters the destruction phase, the player bound to the target page is released and returned to the player cache pool.

4. The method according to claim 1, characterized in that, The method further includes: Update the player status based on changes in the lifecycle of the media content page.

5. The method according to claim 4, characterized in that, The step of updating the player state based on changes in the lifecycle of the media content page includes: When the lifecycle of the media content page enters the creation phase, the player state is marked as the preload state; When the lifecycle of the media content page enters the interactive stage, the player state is marked as the playback state; When the lifecycle of the media content page enters the pause phase, the player state is marked as the "away state".

6. The method according to claim 1, characterized in that, The capacity of the player cache pool is determined based on the number of media content pages cached.

7. The method according to claim 1, characterized in that, The method further includes: In response to the swipe operation, switch the media content page displayed in the graphical user interface.

8. A media content playback management device, characterized in that, The device includes: a creation unit, a listening unit, and a selection unit; The creation unit is used to create a player cache pool, wherein the player states of the player in the cache pool include preload state, playback state, and exit state. The monitoring unit is used to monitor the user's swiping operations on the media content page; The selection unit is used to select a player from the player cache pool and bind it to a target page, which is the page to be displayed, based on the sliding direction of the sliding operation and the player state.

9. An electronic device, characterized in that, include: processor; as well as A memory for storing a data processing program, which, when powered on and run by the processor, executes the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The system contains a data processing program that is executed by a processor to perform the method as described in any one of claims 1 to 7.

Images