Page display method, device, apparatus and storage medium

Abstract

This application discloses a page display method, apparatus, device, and storage medium, belonging to the field of computer technology. The method includes: displaying a page of a native program, the page including a first display area; in response to an instruction to open a webpage, obtaining scaling parameters, the scaling parameters being determined by the webpage based on its content size; and through the native program, scaling the first display area according to the scaling parameters when displaying the webpage, so that the webpage and the scaled first display area coexist on the same screen without obstructing each other. This solution, while ensuring a good video viewing experience, achieves dynamic, adaptive, and collaborative display of the webpage and video area on the same screen, significantly enhancing the user's immersive interactive experience.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a page display method, apparatus, device, and storage medium. Background Technology

[0002] With the development of mobile internet, embedding web pages (such as interactive games, gacha games, and surveys) in video applications has become a common way to enhance user engagement. When users watch video content through the native application, they often need to open a web page to participate in the activity at the same time, thus creating a need for the video and web page to be displayed on the same screen.

[0003] Currently, a common implementation method is the floating window mode, which shrinks the video into a floating window and floats above the webpage, thus achieving the appearance of both being on the same screen. However, the floating window mode has the following drawbacks: the video image is significantly reduced, resulting in a significantly worse viewing experience; the floating window is in a fixed position and obstructs part of the webpage's interactive area, affecting normal user interaction. Summary of the Invention

[0004] This application provides a page display method, apparatus, device, and storage medium, which, while ensuring a good video viewing experience, achieves dynamic and adaptive simultaneous display of web pages and video areas, significantly enhancing the user's immersive interactive experience. The technical solution is as follows: According to one aspect of this application, a page display method is provided, the method comprising: The page that displays the native program includes a first display area; In response to an instruction to open a webpage, scaling parameters are obtained, wherein the scaling parameters are determined by the webpage based on its own content size; The native program, based on the scaling parameters, scales the first display area when displaying the webpage, so that the webpage and the scaled first display area coexist on the same screen without obstructing each other.

[0005] According to another aspect of this application, a page display device is provided, the device comprising: The display module is used to display the page of the native program, the page including a first display area; The acquisition module is used to acquire scaling parameters in response to an instruction to open a webpage, wherein the scaling parameters are determined by the webpage based on its own content size; The display module is further configured to scale the first display area according to the scaling parameters when displaying the webpage, through the native program, so that the webpage and the scaled first display area coexist on the same screen without obstructing each other.

[0006] According to another aspect of this application, a terminal device is provided, the terminal device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the page display method as described above.

[0007] According to another aspect of this application, a computer-readable storage medium is provided, wherein a computer program is stored therein, the computer program being loaded and executed by a processor to implement the page display method as described above.

[0008] According to another aspect of this application, a computer program product is provided, comprising a computer program executed by a processor to implement the page display methods provided in various alternative implementations of the above aspects.

[0009] This application provides a page display solution where the scaling parameters are calculated and determined by the webpage based on its own content dimensions, rather than being unilaterally set by the native program. This allows webpages with different content heights to autonomously determine the scaling ratio of the video area, achieving adaptive collaborative display. After scaling according to these parameters, the video area coexists on the same screen as the webpage without obstructing it, avoiding the problem of the video being too small and obscuring the operation area in floating window mode. Simultaneously, the native program does not need to preset layout parameters for different webpages, improving the solution's versatility across various activity scenarios. In summary, this solution, while ensuring a good video viewing experience, achieves dynamic, adaptive, and collaborative display of the webpage and video area on the same screen, significantly enhancing the user's immersive interactive experience. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0011] Figure 1 This is a schematic diagram of the implementation environment of a page display method provided in an embodiment of this application; Figure 2 This is a flowchart of a page display method provided according to an embodiment of this application; Figure 3 This is an interactive flowchart of another page display method provided according to an embodiment of this application; Figure 4 This is a schematic diagram of a display area provided according to an embodiment of this application; Figure 5This is a schematic diagram illustrating the interaction between a web page and a client according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a page display device provided according to an embodiment of this application; Figure 7 This is a structural block diagram of a terminal device provided according to an embodiment of this application.

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Detailed Implementation

[0013] 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.

[0014] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0015] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0016] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the scaling parameters involved in this application were obtained with full authorization.

[0017] First, we will explain the terms involved.

[0018] Native applications are applications that run directly on the mobile device's operating system, developed using the platform's native language (such as Swift / Objective-C for iOS, and Kotlin / Java for Android) and compiled into machine code. Native applications have the ability to directly call the device's underlying graphics rendering interfaces, enabling efficient handling of video decoding and image rendering.

[0019] A web page refers to a page built using Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript, and is loaded and rendered using a WebView component embedded in the native application. In this embodiment, a web page specifically refers to an interactive activity page in a live streaming scenario, such as a lucky draw wheel, treasure chest, golden egg smashing, or questionnaire survey.

[0020] Figure 1 This is a schematic diagram illustrating the implementation environment of a page display method provided in an embodiment of this application. See also... Figure 1 The implementation environment specifically includes: terminal device 101 and server 102. Terminal device 101 can be connected to server 102 via wireless network or wired network.

[0021] Terminal device 101 can be at least one of the following: smartphone, smartwatch, desktop computer, laptop, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), and laptop computer. An application can be installed and run on terminal device 101. This application is compatible with various media content platforms, covering scenarios such as music playback, online singing, live streaming, and on-demand video streaming, and can be in the form of a standalone app or mini-program. This application is associated with server 102, which provides background services to terminal device 101.

[0022] Terminal device 101 can refer to one of a plurality of terminal devices. This embodiment uses terminal device 101 as an example. Those skilled in the art will know that the number of the above-mentioned terminal devices can be more or less. For example, there can be several, dozens or hundreds, or more terminal devices. This application embodiment does not limit the number or type of terminal devices.

[0023] Server 102 can be at least one of a single server, multiple servers, a cloud computing platform, and a virtualization center. Optionally, the number of servers can be more or less, and this embodiment does not limit this. Of course, server 102 may also include other functional servers to provide more comprehensive and diversified services. In some embodiments, server 102 undertakes the main computing work, and terminal device 101 undertakes the secondary computing work; or, server 102 undertakes the secondary computing work, and terminal device 101 undertakes the main computing work; or, server 102 and terminal device 101 collaborate on computing using a distributed computing architecture. Server 102 can be connected to terminal device 101 and other terminal devices via a wireless network or a wired network. Optionally, the number of servers can be more or less, and this embodiment does not limit this.

[0024] Figure 2 This is a flowchart of a page display method provided according to an embodiment of this application, such as... Figure 2 As shown, this method is executed by a terminal device, which can be... Figure 1 The terminal device 101 shown includes the following steps: Step 201: Display the native program's page, which includes the first display area.

[0025] In this embodiment, after a user launches an application (native application), the computer device executes the corresponding program code to render the live streaming page of the native application on the display screen. The native application's page includes a first display area occupying the upper half or the entire screen for playing video content. The video content can be a live video stream, a video-on-demand file, or a real-time video call.

[0026] Optionally, the native application receives the live video stream from the network through a system-provided video player component (such as AVPlayer on iOS, MediaPlayer or ExoPlayer on Android), decodes it, and renders the video frame images to the first display area. At this time, the first display area can be full screen, or it can be the display area of ​​about 60% to 70% at the top of the interface, with the remaining area used to display native UI (User Interface) components such as the comment section.

[0027] It should be noted that the size and position of the first display area are predefined by the native program in the layout file, or adjusted by the user through gestures (such as screen rotation and zoom). In the initial state where the user has not triggered any web pages, the video content plays normally, and the user experience is in a simple video viewing mode.

[0028] Step 202: In response to the instruction to open a webpage, obtain the scaling parameters, which are determined by the webpage based on its own content size.

[0029] In this embodiment, when a user clicks an activity entry button such as "Participate in the lottery" or "Open the gift box" during a live stream, the native program receives an instruction to trigger a webpage. At this time, instead of the native program calculating the scaling ratio of the video area itself, the webpage to be opened determines a scaling parameter based on its own content size, and the native program then obtains this scaling parameter. This scaling parameter can be a proportional scaling parameter or a fixed-height scaling parameter.

[0030] Optionally, after calculating the scaling parameters, the webpage carries them in a data channel agreed upon with the native application. The scaling parameters are then passed to the native application through this data channel.

[0031] Step 203: Using the native program, scale the first display area according to the scaling parameters when displaying the webpage, so that the webpage and the scaled first display area coexist on the same screen without obstructing each other.

[0032] In this embodiment, after the native program obtains the scaling parameters, it performs a scaling operation on the first display area according to the parameters while displaying the web page, so that the two can coexist on the screen without obstructing each other.

[0033] Optionally, the native application first parses and obtains the scaling parameters. Then, the native application rearranges the interface using a view layout manager (such as Auto Layout on iOS or ConstraintLayout on Android). The first display area is allocated to the area at the top of the screen, and the boundary size of the video rendering layer is adjusted to scale the video image to fit the new area size. The web page view component is allocated to the area at the bottom of the screen, and the URL (Uniform Resource Locator) of the web page is loaded. The final interface layout is as follows: the upper part of the screen is the scaled first display area, continuously playing the video image; the lower part of the screen is the web page, displaying the complete event content. The boundaries between the two areas are clear and do not overlap, allowing users to fully participate in interactive operations on the web page while watching the video, without having to repeatedly switch between the video and the event.

[0034] This application provides a page display solution where the scaling parameters are calculated and determined by the webpage based on its own content dimensions, rather than being unilaterally set by the native program. This allows webpages with different content heights to autonomously determine the scaling ratio of the video area, achieving adaptive collaborative display. After scaling according to these parameters, the video area coexists on the same screen as the webpage without obstructing it, avoiding the problem of the video being too small and obscuring the operation area in floating window mode. Simultaneously, the native program does not need to preset layout parameters for different webpages, improving the solution's versatility across various activity scenarios. In summary, this solution, while ensuring a good video viewing experience, achieves dynamic, adaptive, and collaborative display of the webpage and video area on the same screen, significantly enhancing the user's immersive interactive experience.

[0035] The above Figure 2 The diagram shows the main flow of a page display method provided in this application. The following is a further explanation of the page display scheme. Figure 3 This is an interactive flowchart of another page display method provided according to an embodiment of this application, such as... Figure 3 As shown, an exemplary illustration illustrates the interaction between a web page and a client in a terminal device. The method includes: Step 301: The web page determines the scaling parameters based on its own content size.

[0036] In this embodiment of the application, the decision-making power for the scaling ratio of the video region is transferred from the native program (i.e., the client) to the web page, making the web page the active maker of the scaling strategy.

[0037] In traditional hybrid development models, after a webpage is loaded by the native application's web view component, the size of the webpage's display area is entirely determined by the native application's preset layout file. The webpage can only passively adapt to the rectangular area allocated to it by the native application and cannot influence the native application's layout decisions based on the actual needs of its content.

[0038] This solution breaks away from the traditional, passive model. When designing the event page, the webpage developer determines the ideal display size for the page content based on a specific UI design. When the webpage needs to be displayed alongside a video area, it actively reads its own design size or desired aspect ratio at runtime, quantifies it into a scaling parameter, and passes it to the native application. The native application then adjusts the size of the video area based on this scaling parameter, thus freeing up just the right amount of display space for the webpage. This mechanism allows webpages in different event scenarios to inform the native application how much display area they need, rather than the native application guessing or pre-setting a fixed value, truly achieving content-driven adaptive collaborative display.

[0039] Alternatively, web pages can determine scaling parameters based on their own content size in two main ways: proportional scaling and fixed height scaling.

[0040] The first method is proportional scaling. Proportional scaling is suitable for web pages where the content has a clear aspect ratio design constraint and needs to be scaled proportionally to maintain the visual effect.

[0041] The first step is to obtain the dimensions of the UI design draft. During the development phase, web pages are typically laid out based on a standard UI design draft, which has a fixed pixel width (denoted as ). ) and pixel height (denoted as This size information is written into the script code of the web page as constants.

[0042] The second step is to calculate the aspect ratio. During runtime, the webpage's script code reads the preset design width and height, calculates the ratio of height to width, and multiplies it by 100 to obtain an integer value. The calculation formula is as follows (1).

[0043] (1).

[0044] Here, scaleRatio represents the scaling parameter. Indicates pixel height. Indicates pixel width.

[0045] For example, taking the "XX Treasure Chest" interactive game activity of a certain e-commerce live streaming application as an example, its UI design draft adopts the vertical layout common on mobile devices, with a design size of 1080 pixels wide and 720 pixels high (the example shown here is the design draft in portrait mode, the width is the device's logical width, and the height is the ideal height of the content area). However, in reality, the effective content area of ​​the core game content treasure chest graphic display and clickable interaction area on this activity page is approximately 1.58 times its width. Therefore, the calculated value set in the script code is: scaleRatio=158. The technical meaning of this value 158 is: the expected aspect ratio of the effective content area of ​​the webpage is 158 / 100=1.58. This means that if the native program allocates a display area for this webpage on the screen, the ideal height of that area should be 1.58 times its width. Correspondingly, the remaining display space on the screen is the area that can still be used after the first display area is scaled.

[0046] For example, suppose another webpage for a "smash the golden egg" activity has a design of 1080 pixels × 900 pixels. The calculated scaling parameter would be: scaleRatio = 900 / 1080 × 100 ≈ 83. This value indicates that the desired aspect ratio of the "smash the golden egg" page is 0.83, meaning the content height is relatively low, requiring less vertical display space, and the first display area can retain a larger display area.

[0047] The second method is the fixed-height ratio method. The fixed-height ratio method is suitable for scenarios where the height of the webpage content is relatively fixed, proportional scaling is not strictly required, but it is desired to occupy a specific proportion of the screen height. The calculation formula is as follows (2).

[0048] (2).

[0049] For example, consider a webpage for "daily check-in to earn points." Its content consists of only a check-in button and text displaying the points, requiring minimal vertical space. The page developer sets `scaleRatio = 40`, meaning the page aims to occupy 40% of the screen's total height. Correspondingly, the primary display area can be scaled to approximately 60% of the screen's top area, ensuring the video remains the dominant element.

[0050] For example, a "After-Sales Application" webpage containing a complex form requires users to fill in multiple lines of information, necessitating a significant screen height. The page developer can set `scaleRatio = 75`, indicating a desired screen height of 75%, providing ample space for form operations and scrolling.

[0051] In some embodiments, CSS Viewport units can be used instead of scaling parameters. That is, the vh / vw units allow elements within the H5 page to automatically adjust their layout according to the visible area of ​​the WebView container. Here, vh and vw are CSS Viewport Units, used to set the size of elements based on the size of the browser's visible area (viewport), providing excellent responsiveness. It's important to note that the WebView container's position and size on the screen, as well as the scaling of the video area, are entirely controlled by the native side; CSS cannot cross the boundary between H5 and native to instruct the native side to adjust the external video area.

[0052] In some embodiments, dynamic calculations can be replaced by predefined templates. Accordingly, the scaling ratio of the video area is limited to three fixed values: "large / medium / small," from which the H5 page can select one.

[0053] Step 302: The client displays the native application's page, which includes the first display area.

[0054] In this embodiment of the application, the client (i.e., the native program running on the computer device) is responsible for creating and managing a display area for playing video content, which is referred to as the "first display area" in this scheme.

[0055] When a native program starts or enters the video playback function module, it performs a series of initialization operations.

[0056] First, native applications create a view hierarchy using the system-provided view management framework. Within this hierarchy, the primary display area is typically implemented as a dedicated video rendering view component. On iOS, this component can be a layer rendering node based on AVPlayerLayer; on Android, it can be a video output carrier based on SurfaceView or TextureView. These underlying components can directly receive decoded video frame data and utilize the graphics processor for hardware-accelerated rendering, thus presenting a smooth video on the screen.

[0057] Secondly, the native application manages the acquisition and playback of video streams through a video player instance. The sources of video content include, but are not limited to: live video streams based on Real-Time Messaging Protocol (RTP) or HTTP Real-Time Streaming Protocol (RTSP), video files based on Content Delivery Network (CDN), and audio / video call footage based on real-time communication signaling. The player module in the native application is responsible for low-level processing such as network connection, data buffering, audio / video decoding, and audio-visual synchronization, and continuously outputs the decoded video frames to the rendering carrier in the primary display area.

[0058] Finally, the native application determines the position and size of the first display area on the screen based on preset layout parameters. In the initial state where the user has not triggered any web pages, the first display area typically occupies the majority of the screen's display space. The specific layout can be statically defined by the native application in the interface layout file, or it can be dynamically calculated based on runtime environment parameters such as device screen size and screen orientation.

[0059] In this state, the client's screen displays the native application's page, which uses the primary or sole visual focus area.

[0060] Optionally, the first display area can be in full-screen mode. In this mode, the boundary of the video rendering view completely overlaps with the display area of ​​the screen, filling the entire screen and providing the user with an immersive viewing experience. In full-screen mode, the vertex coordinates of the first display area are aligned with the origin of the screen coordinate system, and the logical pixel values ​​of its width and height are equal to the logical width and logical height of the screen, respectively. Alternatively, the first display area can occupy a portion of the screen space, such as the common half-screen video layout in interfaces. In this layout, the first display area occupies approximately 60% to 70% of the display area at the top of the screen, while the remaining area below is used to display other UI components of the native application, such as product lists, comment scrolling areas, host information bars, and gift sending panels. These native UI components are also directly managed and rendered by the native application, maintaining a defined relative positional relationship with the first display area through layout constraints.

[0061] It should be noted that in the initial state described in this step, the size and position of the first display area are set by the native program according to its own logic. Regardless of whether the first display area is in full-screen or half-screen mode, no web page is loaded at this time, and there are no web page view components on the screen. The user focuses on watching the video content or interacting with the native UI components. This state constitutes the starting point of the user's "video viewing" experience and is also the baseline state for scaling and adjusting the video area in subsequent steps of this solution.

[0062] In some embodiments, the first display area is a live video area.

[0063] For example, taking a live shopping scenario, after a user opens the live streaming channel of an e-commerce app, the client displays the native program's live stream page. On this page, the first display area shows the live stream of the host introducing and showcasing the products in full screen or a large area. Users can clearly view the live stream content in the initial state, providing a good visual experience.

[0064] However, when users want to participate in an interactive activity during a live stream, such as clicking a "lottery" button or "open gift box" entry on the screen, the native application needs to open a corresponding webpage. At this point, using traditional full-screen overlay or floating window solutions would disrupt the user's initial, complete video viewing experience. This is precisely the core problem that this solution aims to solve.

[0065] Before the webpage loads, the video area is in a normal display state controlled by the native program. Subsequent scaling operations use this initial state as a reference. By obtaining scaling parameters provided by the webpage, the first display area is dynamically adjusted, allowing the video area to transition from its initial full-screen or large-area state to a collaborative display state where it coexists with the webpage on the same screen.

[0066] Step 303: In response to the instruction to open a webpage, the webpage sends scaling parameters through at least one of the Uniform Resource Locator (URL) channel and the JavaScript (JS) bridge interface channel.

[0067] In this embodiment of the application, this step describes the specific communication mechanism for transmitting scaling parameters from the web page to the native application.

[0068] Optionally, this step is performed only if the instruction to "open a webpage" is triggered. In practice, this instruction is usually generated by user interaction within the native application interface.

[0069] For example, while watching a live stream, a user might click on activity entry buttons displayed on the native app's page, such as "Participate in the lottery," "Open the treasure chest," "Claim a coupon," or "Fill out the questionnaire." These buttons can be native UI controls rendered by the native app itself, or interactive hotspots superimposed at specific coordinates in the primary display area. When the user's touch operation hits one of these entry points, the native app's underlying operating system event dispatch mechanism encapsulates the touch event into a corresponding operation command and passes it to the native app's main thread processing logic.

[0070] Upon receiving this instruction, the native application does not immediately calculate the scaling ratio of the video area. Instead, it initiates the process of loading the webpage and waits to obtain the scaling parameters from the webpage. In other words, the webpage has the authority to determine the scaling parameters, and the native application merely acts as the receiver and executor of those parameters.

[0071] To ensure that scaling parameters are reliably transmitted from the web page to the native application, this embodiment provides two communication channels: a Uniform Resource Locator (URL) channel and a JavaScript Bridge channel. The web page can use at least one of these channels when sending scaling parameters.

[0072] The first type of communication channel is the Uniform Resource Locator (URI) channel. The URI channel refers to the webpage encoding the calculated scaling parameters into the query string of the target URL corresponding to the webpage, and then passing these parameters through the native program's URL parsing process when loading the webpage.

[0073] Optionally, when a user triggers the instruction to open a webpage, the webpage appends the scaling parameters and their type identifiers as key-value pairs to the query string portion of the URL when constructing the target URL.

[0074] For example, for the proportional scaling parameter of the "XX Treasure Chest" activity, the generated URL could be: https: / / activity.example.com / baoxiang?scaleRatio=158&scaleMode=aspectFit. Here, scaleRatio=158 indicates the scaling parameter value is 158, and scaleMode=aspectFit indicates the scaling mode is proportional scaling. For the fixed-height scaling parameter of the "Sign in to Earn Points" activity, the generated URL could be: https: / / activity.example.com / signin?scaleRatio=40&scaleMode=fixedHeight. Here, scaleRatio=40 indicates the webpage is expected to occupy 40% of the screen height, and scaleMode=fixedHeight indicates the scaling mode is fixed-height scaling.

[0075] The core advantage of URL channels lies in their time-series nature. Before parsing the URL address and initiating a network request to load the webpage content, native applications can extract scaling parameters from the URL query string. This means that native applications can obtain the scaling intent of the webpage before the HTML, CSS, and JavaScript code are downloaded, parsed, and executed, thus determining the layout mode for this collaborative display in advance and avoiding layout flickering or visual jumps such as full-screen followed by scaling during page loading.

[0076] The second type of communication channel is the JS bridging interface channel. The JS bridging interface channel refers to a bridging method pre-injected into the webpage view component by the webpage's native application, which directly passes scaling parameters to the native application as function call arguments.

[0077] Optionally, when creating a webpage view component, the native application can inject a global bridge object into the component's JavaScript execution environment. This object carries configuration methods exposed by the native application. For example, the bridge object injected by the native application might be `window.NativeBridge`. This object provides a configuration method: `window.NativeBridge.setDisplayConfig(configObject)`. When the JavaScript code of the webpage executes, this method can be called to pass a configuration object containing scaling parameters to the native application.

[0078] The core advantage of the JS bridging interface lies in its continuous communication capability. Unlike URL channels, which only pass parameters once when the page loads, the JS bridging interface allows the web client to call it multiple times during page runtime, dynamically updating scaling parameters. This enables the web client to recalculate scaling parameters and notify the native application in real time via the JS bridging interface when content changes occur within the webpage—for example, when a user expands or collapses a collapsed area of ​​the page, or when the page loads additional content modules via asynchronous requests. The native application then dynamically adjusts the size of the primary display area accordingly, achieving runtime adaptive scaling.

[0079] In some embodiments, the JS bridge interface can also function when the webpage switches between shown and hidden states, maintaining the continuous transmission of scaling parameters through FxApp.halfView.config().

[0080] For example, if a user temporarily switches to another native page while participating in a web activity, and then returns to the activity page, the web page can resend the scaling parameters through the JS bridging interface to ensure that the native program maintains the correct collaborative display state and prevents the video area from reverting to the default full-screen state and obscuring the web page.

[0081] It should be noted that, in the embodiments of this application, the two communication channels can be used independently or in combination to form a complementary dual-channel communication mechanism.

[0082] Optionally, one collaborative working mode is as follows: the web page uses both a URL channel and a JS bridging channel to pass scaling parameters. The URL channel is responsible for passing scaling parameters to the native application in the early stages of page loading, enabling the native application to determine the display mode and complete layout preparation before the page content is displayed, thus eliminating layout flickering. The JS bridging channel is responsible for maintaining the dynamic updating capability of scaling parameters during page runtime, promptly synchronizing the latest scaling configuration to the native application when the page content changes or the page display state switches.

[0083] This dual-channel collaborative mechanism ensures that scaling parameters are accurately and timely transmitted to the native application throughout the entire lifecycle of the webpage, from the initial moment of page loading to each switch in page display state, and then to the dynamic changes in page content, thus guaranteeing information consistency between the H5 and native ends.

[0084] This step establishes an efficient control link from the web page to the native application, enabling the web page to communicate its layout requirements to the native application in a structured manner. This control link is the key connecting link between the aforementioned "H5 side autonomously calculates scaling parameters" step and the subsequent "Native side executes video area scaling" step, and is the technical guarantee for transferring decision-making power from the native application to the web page. The dual-channel design of the URL channel and the JS bridging channel takes into account both the timeliness and continuity of parameter transmission. The URL channel utilizes the system behavior of URL parsing that the native application will inevitably perform when loading the web page, completing the initial transmission of parameters with extremely low implementation cost. The JS bridging channel compensates for the limitation of the URL channel's inability to communicate dynamically during page runtime, ensuring the synchronization capability of parameters at all stages of the page lifecycle. This complementary design makes this solution more reliable in terms of communication than implementations that rely on only a single channel.

[0085] In some embodiments, the native application can proactively detect changes instead of the H5 page proactively notifying the user. Accordingly, after loading the H5 page, the native application injects a JavaScript script to obtain the actual rendered height of the H5 page and then calculates the scaling ratio itself.

[0086] Step 304: The client obtains the scaling parameters.

[0087] In this embodiment of the application, this step is the technical process by which the native program receives and parses the scaling parameters from the communication channel.

[0088] The Uniform Resource Locator (URL) channel is the first method for clients to obtain scaling parameters. In this method, the scaling parameters are encoded into the query string of the target URL by the webpage, and the client extracts these scaling parameters from the URL during the webpage loading process. Accordingly, obtaining scaling parameters via the URL channel includes: retrieving the scaling parameters encoded in the target URL so that the native application can determine the display mode before loading the webpage.

[0089] Optionally, before creating the webpage view component and calling its load method, the client first parses the URL. The URL parsing module extracts key-value pairs from the query string according to standard Uniform Resource Locator (URL) syntax rules, reading the value of the `scaleRatio` parameter (e.g., 158) and the value of the optional `scaleMode` parameter (e.g., `aspectFit` or `fixedHeight`). The client stores the parsed scaling parameters in a configuration object in memory for use in subsequent layout adjustment steps. Then, the client initiates a network request using this URL to load the webpage's HTML document and related resources.

[0090] In some embodiments, URL parameters can be replaced by real-time WebSocket communication. Accordingly, a WebSocket channel is established between the H5 page and the native application to synchronize scaling information in real time.

[0091] The JS bridging interface channel is the second way for the client to obtain scaling parameters. In this method, the scaling parameters are directly passed by the JavaScript code on the webpage through a bridging interface pre-injected by the native program. Accordingly, obtaining scaling parameters through the JS bridging interface channel includes: receiving the scaling parameters through the JS bridging interface and maintaining the transmission of the scaling parameters through the JS bridging interface when switching webpages.

[0092] Optionally, when creating a webpage view component, the client registers a global bridge object and its contained methods in the component's JavaScript execution environment through the system-provided script injection mechanism. When the webpage calls the bridge method and passes in the configuration object, the client's bridge message handling callback function is triggered. The client parses the configuration object from the parameters carried by the callback function, extracts the values ​​of fields such as scaleRatio and scaleMode, and updates them to the configuration object in memory. Subsequently, the client adjusts the video area layout accordingly based on the updated scaling parameters. Compared to the URL channel, the core advantage of the JS bridge channel lies in its continuous communication capability. The communication of the URL channel is limited to the initial stage of page loading, while the JS bridge channel allows the webpage to send data to the client at any time during page execution.

[0093] It's important to note that in actual mobile application use, users might temporarily switch to other native pages (such as viewing product details or replying to messages) while the webpage is in small-screen collaborative display mode, and then return to the activity page. If the client loses the scaling parameters during the page switching process, the video area may revert to the default full-screen state, obscuring the webpage again and disrupting the continuity of the collaborative display. To address this issue, this solution further incorporates a parameter retention mechanism based on the JS bridging channel. Accordingly, when the webpage is in small-screen display mode, in response to interactive operations on the webpage, the scaling parameter transmission state is maintained through the JS bridging interface to prevent the webpage from being accidentally closed.

[0094] Optionally, after obtaining the scaling parameters, the client associates and stores these parameters with the identifier of the current webpage. When the webpage is detected to have resumed display from a hidden state, the client checks whether the page identifier is associated with a valid scaling parameter. If so, the client directly uses this parameter to restore the collaborative display layout without waiting for the webpage to resend the parameter. Simultaneously, when the webpage detects a page display state switch event, it can also proactively resend the scaling parameters via the JS bridge interface, verifying them against the parameters stored on the client, thus providing double protection.

[0095] Additionally, when the webpage is in small-screen collaborative display mode, users may perform various interactive operations on the page, such as clicking a lottery button, sending virtual gifts, or filling out form information. These interactive operations should not cause the webpage to be closed or its zoom state to be reset. The client continuously maintains the transmission state of zoom parameters through a JS bridge interface to ensure that the zoom ratio of the video area remains stable during the user's above operations, preventing the webpage from being accidentally closed and effectively ensuring the continuity of user participation in the activity.

[0096] Step 305: The client displays the webpage in a second display area outside the first display area through the native program, and scales the first display area according to the scaling parameters so that the first display area and the second display area do not overlap.

[0097] In this embodiment of the application, this step is the final collaborative rendering operation performed by the client after obtaining the scaling parameters, that is, the screen layout is re-divided according to the scaling parameters to achieve the coexistence of web page and video area on the same screen.

[0098] First, after obtaining the scaling parameters, the client divides the available display area of ​​the screen into two non-overlapping areas based on the type and value of the scaling parameters: a first display area for continuing to play video content, and a second display area for displaying web pages.

[0099] For the proportional scaling parameter, the partitioning process is as follows.

[0100] The client obtains the logical width of the current screen or the current video display area, denoted as W. Based on the scaleRatio parameter passed from the web page, the display height that the web page should occupy is calculated. The calculation formula is as follows (3).

[0101] (3).

[0102] For example, when scaleRatio is 158, This height value indicates that the expected display height of the webpage is 1.58 times its width. The client records the screen height as... The height allocated to the first display area is The first display area is located in the upper half of the screen, with its vertex coordinates aligned with the origin of the screen coordinate system. Its width is W and its height is [missing information]. The second display area is located below the first display area, and its vertex ordinate is... Width is W, height is .

[0103] For a fixed height scaling parameter, the partitioning process is as follows.

[0104] The client obtains the overall logical height of the current screen. Calculate the display height that the webpage should occupy based on the scaleRatio parameter (representing a percentage value). The height of the first display area is... The coordinate assignment method for the two regions is consistent with that of the proportional scaling parameter scenario.

[0105] It should be noted that in actual implementation, the client can also consider the device's safe area (such as the top notch area and bottom indicator bar area of ​​a full-screen phone) and make appropriate offset adjustments to the boundaries of the calculated areas to ensure that the interactive controls of the web page are not obscured by system UI elements and that the main content of the video remains within a safe and visible range.

[0106] Finally, after determining the target size and position of the first display area, the client performs a scaling operation on the first display area through the native program's view management mechanism.

[0107] The first step is for the client to update the layout constraint parameters of the view component corresponding to the first display area using the native application's layout manager. On iOS, this can be achieved by updating the constant values ​​of the Auto Layout constraints or directly setting the view's frame property. On Android, this is accomplished by updating the layout parameter object and triggering the view's requestLayout process. The client updates the width constraint of the first display area to W and the height constraint to [value missing]. Then update its position constraints in the parent view to top alignment and horizontal centering.

[0108] The second step involves updating the layout constraints. The native application's layout engine then triggers a layout traversal to recalculate the final frame rectangles of each view in the view hierarchy. The first display area is placed at the top of the screen according to the new frame rectangles, its size reduced from full-screen or large-area to the target size.

[0109] The third step involves adapting the video rendering pipeline within the first display area to the new display size. After receiving notification of the view size change, the video player module adjusts the scaling transformation matrix of the video frames to ensure the video image is displayed completely and proportionally within the new area boundaries. For implementations using native video rendering components such as AVPlayerLayer or SurfaceView, this adaptation is typically handled automatically by the system; for implementations using custom rendering pipelines such as OpenGL ES or Metal, the viewport transformation parameters need to be updated in the shaders or vertex coordinate calculations.

[0110] The fourth step involves scaling the first display area, after which the client displays the webpage in a second display area outside the first. The key to this step is ensuring that the two areas truly do not overlap, rather than merely being visually roughly separated.

[0111] Optionally, the client uses the following technical means to ensure that the two regions do not overlap.

[0112] First, at the view hierarchy management level, the client ensures that the view component corresponding to the first display area and the webpage view component have non-intersecting frame rectangles in the layout coordinate system. The Auto Layout engine on iOS and the layout manager on Android strictly follow constraint rules when calculating view frame rectangles, ensuring that sibling views at the same level do not overlap. The client eliminates the possibility of overlap from a layout logic perspective by setting correct layout constraints (such as aligning two views to the top and bottom of their parent view respectively, with their boundaries determined by their respective height constraints).

[0113] Secondly, at the rendering level, the client's graphics rendering system composites the data layer by layer according to the view hierarchy and frame rectangle. Even if there is a slight error in the calculation of the frame rectangle of a certain view, the rendering pipeline will perform pixel-level clipping based on the view's clipping boundaries to ensure that the content of one view is not drawn within the frame rectangle of another view. This mechanism provides a fallback guarantee at the rendering level for preventing overlap.

[0114] Finally, users see two clearly defined and orderly arranged areas on the screen: the upper area is the scaled-down first display area, where the broadcaster's live feed plays completely and smoothly; the lower area is the webpage, displaying the full content of the event, with all interactive controls visible and operable. The two areas can be arranged in a closely adjacent, demarcated manner, or they can maintain a certain distance between them, but there should never be any pixel-level overlap or obstruction.

[0115] The following example, a live shopping scenario, illustrates the page display method provided in this solution.

[0116] ShopLive, a mobile live-streaming e-commerce application, provides users with real-time live shopping services. Hosts showcase and explain products in the live stream, which users can watch simultaneously. To enhance user engagement and conversion rates, the application launches various interactive web page activities during the live stream, such as a "treasure chest" lottery game, daily check-in for points, and a "limited-time flash sale" product list. These interactive activities are all developed as web pages and loaded and displayed through web view components embedded in the native application.

[0117] Simulate the complete operation process of a user "Xiao A" to demonstrate how this technical solution can achieve adaptive and collaborative display of live video and web activity pages in different activity scenarios.

[0118] Xiao A opens the ShopLive app on her smartphone and enters the "Trendy Clothing" live stream. The app's native interface displays the live stream page on the device screen, which includes a primary video area. Initially, this area occupies approximately 65% ​​of the upper half of the screen, displaying live video of the host showcasing clothing styles. The video is clear and smooth, with the host introducing the fabric and cut of a new spring coat. The remaining 35% of the screen is occupied by native UI components, displaying product purchase links, scrolling comments, and a like button, among other native controls.

[0119] At this time, Xiao A is focused on watching the live stream and has not yet triggered any web page activity. The screen is in the initial display state described in step 302 of this solution.

[0120] Halfway through the live stream, the host announced a "treasure chest" giveaway. Xiao A saw a floating "Open Treasure Chest" button appear in the bottom right corner of the screen. Clicking the button triggered a webpage in the native application.

[0121] In this technical architecture, the scaling parameters for the video area are not determined by the native program itself, but rather by the upcoming "treasure chest" event webpage. The webpage's developers had already calculated these scaling parameters based on the UI design during the initial page design phase. The "treasure chest" event page includes a treasure chest graphic, a clickable area, and animation effects. The design height of the effective content area is approximately 1.58 times its width; therefore, the preset scaling parameter `scaleRatio` in the page script is 158.

[0122] The webpage sends the scaling parameters simultaneously through two channels. In the URL channel, the target address constructed by the webpage is: https: / / activity.shoplive.com / baoxiang?scaleRatio=158&scaleMode=aspectFit. When the native application parses this URL, it extracts the two parameter values, scaleRatio=158 and scaleMode=aspectFit, from the query string, determining that a proportional scaling mode should be used before loading the webpage content. Simultaneously, the webpage's JavaScript code passes the same scaling parameters to the native application through a JS bridge interface during initialization.

[0123] After obtaining the scaling parameters, the native application immediately performs layout adjustments. Assume the current screen's logical width is 375 pixels and the total screen height is 812 pixels. Based on the proportional scaling parameter of 158, the required display height for the webpage is calculated to be 375 × 1.58 ≈ 592 pixels. Accordingly, the first video area is scaled to a height of 812 - 592 = 220 pixels.

[0124] The native application's layout manager updates the height constraint of the first video area to 220 pixels, placing it at the top of the screen. Upon receiving the size change notification, the video player module automatically adjusts the scaling transformation matrix of the video frames to ensure the live stream is displayed completely and proportionally within the shrunk area. Simultaneously, the native application creates a second area below the first video area, with a height of 592 pixels, loads the webpage view component, and displays the "Treasure Chest" activity page.

[0125] The final interface that Xiao A sees is as follows: The top quarter of the screen continues to play the streamer's live broadcast. Although the size is reduced, the image is clear and complete, and the streamer's facial expressions and clothing details are still visible. The bottom three-quarters of the screen displays the "treasure chest" game interface, with each layer of the treasure chest fully displayed. The click button is located in the lower half of the screen for easy finger touch. The boundaries between the two areas are clear and do not overlap. Xiao A can watch the streamer's live commentary while clicking the treasure chest to participate in the lottery, without having to switch between the two interfaces repeatedly.

[0126] During the activity, Xiao A clicked on a prize link in a treasure chest, which opened a native product details page. The activity page was temporarily hidden, but the native application did not close it. After Xiao A finished viewing the product details and clicked the back button, the activity page reappeared.

[0127] During this page transition, the native application maintains the scaling parameter transmission state through the JS bridge interface. When the webpage resumes from a hidden state, the native application checks the scaling parameters associated with the page, finds them still valid, and directly restores the previous aspect ratio layout: the first video area maintains a height of 220 pixels, and the second area maintains a height of 592 pixels. The webpage also detects the page's re-display through the page visibility change event, and sends the scaling parameters again through the JS bridge interface, verifying them against the parameters stored in the native application to ensure accurate layout restoration.

[0128] After completing the treasure chest lottery, Xiao A clicked the "Daily Check-in" entry on the screen. At this point, a new web activity page needed to be opened. Unlike the treasure chest, the "Daily Check-in" page was simple, containing only a check-in button, points display text, and simple decorative patterns. Based on the actual needs of the page content, the developer set the scaleRatio parameter to 40, indicating that it was expected to occupy only 40% of the screen height.

[0129] The native program parses the URL to obtain scaling parameters and then performs layout calculations. The total screen height is 812 pixels, and the webpage is expected to occupy 40%, or approximately 325 pixels. The first video area is scaled to a height of 812 - 325 = 487 pixels, occupying approximately 60% of the display area at the top of the screen.

[0130] Xiao A noticed a significant difference in the updated interface layout compared to the "Treasure Chest" event: the top three-fifths of the screen continued to play the live stream, with a much larger video display area than during the "Treasure Chest" event, and the streamer's viewing experience was almost unaffected. The bottom two-fifths of the screen displayed a clean check-in page, with the check-in button clearly visible. This layout difference visually demonstrates the core advantage of this solution: different web page events provide different scaling parameters based on their content size, and the native program dynamically adjusts the video area size accordingly, achieving an adaptive effect that uses a single universal protocol to suit various event scenarios. Xiao A clicked the check-in button to complete the check-in process smoothly, and the live stream remained visible throughout.

[0131] It should be noted that, in the above description of this embodiment, taking the most common vertical screen usage posture of mobile devices as an example, the first display area and the second display area (web page) are distributed vertically, with the video on top and the web page on the bottom. This layout conforms to the visual path of the user holding the phone vertically, that is, the line of sight naturally moves from top to bottom, the video screen is located on the screen for easy continuous viewing, and the web page operation area is located at the bottom of the screen closer to the hand position for easy touch interaction.

[0132] For example, see Figure 4 , Figure 4This is a schematic diagram of a display area provided according to an embodiment of this application. For example... Figure 4 As shown, Figure 4 (a) in the example shows a display scheme using the conventional mode, where the video content in the first display area is severely obscured. Figure 4 (b) in the example shows the display result when this solution is used. It can be seen that the video content in the first display area is not obscured. The web page content in the second display area is also fully displayed.

[0133] This solution's protection scope is not limited to the vertical layout of a portrait screen. For other screen ratios or device usage postures, the client can flexibly adjust the distribution of the two areas based on scaling parameters. For example, in landscape mode, the first and second display areas can be arranged side-by-side, with the video area on the left and the webpage area on the right. The heights of the two areas are equal, and their widths are determined by the proportional relationship in the scaling parameters, thus also satisfying the technical constraint of non-overlapping. In the unfolded state of a foldable screen device, the usable screen area is larger. The client can scale the first display area to the upper left corner or center of the screen based on the scaling parameters, with the webpage area occupying the remaining space. The distribution method is dynamically adapted according to the actual screen ratio. Regardless of the distribution method used, the core principle remains consistent: the scaling parameters are calculated and determined by the webpage based on its own content size, and the client scales the first display area and divides the second display area according to these parameters, ensuring that both coexist on the same screen without overlapping.

[0134] To make the page display scheme provided in this application easier to understand, see [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram illustrating the interaction between a web page (H5 layer) and a client (Native layer) according to an embodiment of this application. Figure 5 As shown, the process includes the following steps: 501. Calculate the content height. 502. Determine the scaling method and scaling ratio, i.e., the scaling parameters. 503. Send the scaling parameters via at least one of the Uniform Resource Locator (URL) channel and the JavaScript (JS) bridge interface channel. 504. Receive and parse the scaling parameters, such as parameters passed via a URL query string and configuration items passed via the JS bridge interface. 505. Scale the first display area using the video area scaling engine. 506. Divide the video area into a second video area and display the webpage.

[0135] This application provides a page display solution where the scaling parameters are calculated and determined by the webpage based on its own content dimensions, rather than being unilaterally set by the native program. This allows webpages with different content heights to autonomously determine the scaling ratio of the video area, achieving adaptive collaborative display. After scaling according to these parameters, the video area coexists on the same screen as the webpage without obstructing it, avoiding the problem of the video being too small and obscuring the operation area in floating window mode. Simultaneously, the native program does not need to preset layout parameters for different webpages, improving the solution's versatility across various activity scenarios. In summary, this solution, while ensuring a good video viewing experience, achieves dynamic, adaptive, and collaborative display of the webpage and video area on the same screen, significantly enhancing the user's immersive interactive experience.

[0136] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0137] It should be noted that the order of the method steps provided in the embodiments of this application can be appropriately adjusted, and the steps can also be added or removed as appropriate. Any method variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0138] Figure 6 This is a schematic diagram of the structure of a page display device provided according to an embodiment of this application. For example... Figure 6 As shown, the device includes a display module 601 and an acquisition module 602.

[0139] Display module 601 is used to display the page of the native program, the page including a first display area; The acquisition module 602 is used to acquire scaling parameters in response to the instruction to open a web page. The scaling parameters are determined by the web page based on its own content size. The display module 601 is also used to scale the first display area according to the scaling parameters when displaying the web page through the native program, so that the web page and the scaled first display area can coexist on the same screen without obstructing each other.

[0140] In some embodiments, the scaling parameter is a proportional scaling parameter calculated based on the ratio of the webpage's content height to its content width; or, The scaling parameter is a fixed-height scaling parameter calculated based on the percentage of screen height that the webpage expects to occupy according to its content.

[0141] In some embodiments, the acquisition module 602 is used to acquire scaling parameters through at least one of a Uniform Resource Locator channel and a JavaScript (JavaScript) Bridge Interface channel.

[0142] In some embodiments, the acquisition module 602 is used to acquire scaling parameters encoded into a target Uniform Resource Locator (URL) so that the native application can determine the display mode before loading the web page.

[0143] In some embodiments, the acquisition module 602 is used to receive scaling parameters through a JS bridge interface and maintain the transmission of scaling parameters through a JS bridge interface when switching web pages.

[0144] In some embodiments, the acquisition module 602 is used to maintain the transmission state of scaling parameters through a JS bridge interface in response to interactive operations on the webpage when the webpage is in small-screen display mode, so as to avoid the webpage being accidentally closed.

[0145] In some embodiments, the display module 601 is further configured to display a web page in a second display area outside the first display area via a native program, and to scale the first display area according to scaling parameters so that the first display area and the second display area do not overlap.

[0146] In some embodiments, the first display area is a live video area.

[0147] This application provides a page display device in which the scaling parameters are calculated and determined by the webpage based on its own content size, rather than being unilaterally set by the native program. This allows webpages with different content heights to autonomously determine the scaling ratio of the video area, achieving adaptive collaborative display. After scaling according to these parameters, the video area coexists on the same screen as the webpage without obstructing it, avoiding the problem of the video being too small and obstructing the operation area in floating window mode. Simultaneously, the native program does not need to preset layout parameters for different webpages, improving the versatility of the solution for different activity scenarios. In summary, this solution, while ensuring a good video viewing experience, achieves dynamic and adaptive collaborative display of the webpage and video area on the same screen, significantly enhancing the user's immersive interactive experience.

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

[0149] Embodiments of this application also provide a terminal device, which includes a processor and a memory. The memory stores a computer program, which is loaded and executed by the processor to implement the page display method provided in the above-described method embodiments.

[0150] Figure 7 This is a structural block diagram of a terminal device 700 provided according to an embodiment of this application. The terminal device 700 may be: a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The terminal device 700 may also be referred to as a user device, portable terminal device, laptop terminal device, desktop terminal device, or other names.

[0151] Typically, terminal device 700 includes a processor 701 and a memory 702.

[0152] Processor 701 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 701 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 701 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 701 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 701 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0153] The memory 702 may include one or more computer-readable storage media, which may be non-transitory. The memory 702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 702 are used to store at least one instruction, which is executed by the processor 701 to implement the page display method provided in the method embodiments of this application.

[0154] In some embodiments, the terminal device 700 may optionally include a peripheral device interface 703 and at least one peripheral device. The processor 701, memory 702, and peripheral device interface 703 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 703 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: radio frequency circuitry 704, display screen 705, camera assembly 706, audio circuitry 707, and power supply 708. Those skilled in the art will understand that... Figure 7 The structure shown does not constitute a limitation on the terminal device 700, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0155] This application also provides a computer-readable storage medium storing a computer program, which is loaded and executed by a processor to implement the page display method provided in the above-described method embodiments.

[0156] This application also provides a computer program product, which includes a computer program executed by a processor to implement the page display methods provided in the above-described method embodiments.

[0157] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

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

Claims

1. A page display method characterized by comprising: The method comprises: displaying a page of a native program, the page comprising a first display area; in response to an instruction to open a web page, obtaining a zoom parameter determined by the web page according to a content size of the web page; scaling, by the native program, the first display area according to the zoom parameter when displaying the web page, so that the web page and the scaled first display area coexist on the screen and do not block each other.

2. The method of claim 1, wherein, The zoom parameter is an equal ratio zoom parameter calculated by the web page according to a ratio of a content height to a content width; or The zoom parameter is a fixed height zoom parameter calculated by the web page according to a percentage of a content expected to occupy a screen height.

3. The method according to claim 1 or 2, characterized in that, The obtaining of the zoom parameter comprises: obtaining the zoom parameter through at least one of a uniform resource locator channel and a JS (JavaScript) bridge interface channel.

4. The method of claim 3, wherein, The obtaining of the zoom parameter through the uniform resource locator channel comprises: obtaining the zoom parameter encoded into a target uniform resource locator, so that the native program determines a display mode before loading the web page.

5. The method of claim 3, wherein, The obtaining of the zoom parameter through the JS bridge interface channel comprises: receiving the zoom parameter through the JS bridge interface, and maintaining transmission of the zoom parameter through the JS bridge interface when the web page is switched.

6. The method of claim 5, wherein, The maintaining of the transmission of the zoom parameter through the JS bridge interface when the web page is switched comprises: when the web page is in a small screen display mode, in response to an interactive operation on the web page, maintaining a transmission state of the zoom parameter through the JS bridge interface to avoid the web page being mistakenly closed.

7. The method according to any one of claims 1 to 6, characterized in that, The scaling, by the native program, of the first display area according to the zoom parameter when displaying the web page comprises: displaying, by the native program, the web page in a second display area outside the first display area, and scaling the first display area according to the zoom parameter, so that the first display area and the second display area do not overlap each other.

8. The method according to any one of claims 1 to 7, characterized in that, The first display area is a live video area.

9. A page display device characterized by comprising: The apparatus comprises: a display module configured to display a page of a native program, the page comprising a first display area; an obtaining module configured to obtain a zoom parameter in response to an instruction to open a web page, the zoom parameter being determined by the web page according to a content size of the web page; the display module is further configured to scale, by the native program, the first display area according to the zoom parameter when displaying the web page, so that the web page and the scaled first display area coexist on the screen and do not block each other.

10. A terminal device, comprising: The terminal device comprises a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the page display method of any one of claims 1 to 8.

11. A computer readable storage medium, characterized in that, The readable storage medium stores a computer program, the computer program being loaded and executed by a processor to implement the page display method of any one of claims 1 to 8.

12. A computer program product, characterised in that, The computer program product comprises a computer program which is executed by a processor to implement the page display method according to any one of claims 1 to 8. The computer program product comprises a computer program which is executed by a processor to implement the page display method according to any one of claims 1 to 8.

Images