Processing method, electronic device, program product, and storage medium

By adding a feedback mechanism and negotiating window boundary parameters between the browser kernel and the application framework, the problem of abnormal display of PC applications on mobile devices was solved, enabling flexible window adjustment and improving response speed.

CN122240103APending Publication Date: 2026-06-19HUAWEI TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HUAWEI TECH CO LTD
Filing Date
2024-12-17
Publication Date
2026-06-19

AI Technical Summary

Technical Problem

Due to the logical differences between PC and mobile devices, browser kernels are natively developed and packaged separately for PC and mobile devices. This causes issues with window display when applications developed for PC systems are directly deployed to mobile devices.

Method used

By adding a feedback mechanism between the browser kernel and the application framework, and by registering asynchronous callback functions and negotiating window boundary parameters, the browser kernel is notified to adjust the page when window adjustment fails, so as to achieve flexible window adjustment and display.

Benefits of technology

It reduces the probability of directly displaying an error after a window adjustment failure, improves the application's response speed and window flexibility on mobile devices, and enables seamless deployment of PC applications on mobile devices.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122240103A_ABST
    Figure CN122240103A_ABST
Patent Text Reader

Abstract

This application provides an application processing method, electronic device, program product, and storage medium, relating to the field of software technology. It helps to improve the anomalies caused by directly deploying applications developed on PC systems to mobile devices. The method includes: a browser kernel responding to a window adjustment request from an application framework and adjusting the window; the application framework notifying the browser kernel to adjust the page of the corresponding window when the window adjustment fails; the browser kernel responding to the notification and adjusting the page of the corresponding window; and the application framework displaying the window after successful window adjustment or after adjusting the page of the corresponding window.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of software technology, specifically to an application processing method, electronic device, program product, and storage medium. Background Technology

[0002] Browser engines are used to build the basic framework and functionality of a browser. Besides browser applications, they can also be applied to other types of applications. For example, Electron and CEF are two application frameworks based on the Chromium browser engine. Electron is a framework for building desktop applications using JavaScript, HTML, and CSS, while CEF is an abbreviation for Chromium Embedded Framework. Due to the logical differences between PC and mobile devices, browser engines are natively developed and packaged separately for PC and mobile to match different types of systems. However, if the system supports "develop once, deploy across multiple platforms"—that is, develop one project and deploy it on demand across multiple platforms—it can achieve the same features running on multiple platforms and a single interface adapting to multiple platforms, avoiding the use of different development frameworks and languages ​​for different platforms. For browser-based applications, if developed for a PC system and directly deployed to a mobile device, anomalies may occur. Summary of the Invention

[0003] In view of this, this application provides an application processing method, electronic device, program product, and storage medium, which are beneficial for improving the anomalies caused by directly deploying applications developed based on PC systems to mobile devices.

[0004] In a first aspect, an application processing method is provided, comprising: a browser kernel responding to a window adjustment request from an application framework and adjusting the window; the application framework notifying the browser kernel to adjust the page of the corresponding window when the window adjustment fails; the browser kernel responding to the notification and adjusting the page of the corresponding window; and the application framework displaying the window after the window adjustment is successful or the page of the corresponding window is adjusted.

[0005] During the window adjustment and display process, a feedback mechanism was added between the browser kernel and the application framework. This means that the page is adjusted when window adjustment fails. This reduces the probability of window display abnormalities caused by directly displaying the window after a failed adjustment, thus improving the anomalies caused by deploying applications developed on PC systems directly to mobile devices.

[0006] In some possible implementations, the above method further includes: the browser kernel responding to the application framework's window adjustment request by registering a callback function with the application framework, the callback function being used to notify the browser kernel to adjust the page of the corresponding window; the application framework notifying the browser kernel to adjust the page of the corresponding window when the window adjustment fails includes: the application framework triggering the callback function when the window adjustment fails; the callback function is an asynchronous callback function.

[0007] Setting asynchronous callback functions eliminates the need to wait for the callback function to complete before executing other processes, thus preventing the subsequent window rendering process from being blocked and improving the application's response speed.

[0008] In some possible implementations, the above method further includes: the browser kernel responding to the application framework's window adjustment request by obtaining window boundary parameters, which include the window size and window position; adjusting the window includes: calling the application framework's interface based on the window boundary parameters to set the window boundaries; window adjustment failure includes: the window size not matching the preset size; window adjustment success includes: the window size matching the preset size; the browser kernel adjusting the page of the corresponding window includes: the browser kernel adjusting the page of the corresponding window according to the window boundary parameters. Adding a negotiation mechanism based on window boundary parameters between the browser kernel and the application framework allows for timely notification of the browser kernel to adjust the page when window adjustment fails, thus achieving correct window display.

[0009] In some possible implementations, if the window resizing request is a window creation request made when the application is first launched, the window's position in the window boundary parameters is determined based on the screen size, and the window's size in the window boundary parameters is determined based on the window content and title bar. If the window resizing request is a window creation request made when the application is not first launched, the size and position of the most recent historical window are used as the window boundary parameters. In other words, when the application is not first launched, the window is set according to the previous historical window boundary parameters to improve the user experience.

[0010] In some possible implementations, the window adjustment request is generated in response to a user's creation of a new window. Obtaining window boundary parameters includes: if the application has an active window, then using the size and position of the active window as window boundary parameters; if the application does not have an active window but has a saved window boundary, then using the size and position of the saved window as window boundary parameters; if the application has neither an active window nor a saved window boundary, then determining the window's position in the window boundary parameters based on the screen size, and determining the window's size in the window boundary parameters based on the window content and title bar. When a user creates a new window, the window boundary parameters can be set in corresponding ways depending on whether an active window exists or a saved window exists, thereby improving the user experience in different scenarios.

[0011] In some possible implementations, the window is maximized before the browser kernel responds to the application framework's window resizing request; the window resizing request is generated in response to the user's action; resizing the window includes shrinking the window from a maximized window to a free window; displaying the window includes displaying the window as a free window after shrinking it from a maximized window. By adding a negotiation mechanism between the browser kernel and the application framework to the functionality of shrinking the window from a maximized window to a free window, a free window implementation can be provided when PC applications are directly applied to mobile devices. This allows for adjustment of the free window's size and draggability, thereby improving window flexibility.

[0012] In some possible implementations, window adjustment requests include window adjustment requests for multiple windows; window adjustment includes adjusting multiple windows; and window display includes displaying multiple floating windows. By adding a negotiation mechanism between the browser kernel and the application framework on top of the multiple window functionality, a floating multi-window implementation can be provided when PC applications are directly applied to mobile devices, thereby improving window flexibility.

[0013] In some possible implementations, before the browser kernel responds to the application framework's window resizing request and resizes the window, a first window of the first application is displayed on the page; the resizing window includes: creating a second window for the first application; the display window includes: displaying the first window and the second window, with at least a portion of the second window located outside the first window. By adding a negotiation mechanism between the browser kernel and the application framework to the functionality of free pop-up windows, the ability to display a second window outside the first window can be provided when a PC application is directly applied to a mobile device, thereby improving window flexibility.

[0014] In some possible implementations, window adjustments include showing, hiding, maximizing, minimizing, or setting window boundaries. By adding a negotiation mechanism between the browser kernel and the application framework on top of various window functions, more diverse window implementations can be provided when PC applications are directly applied to mobile devices, thus improving window flexibility.

[0015] In some possible implementations, if the window is the main window, the callback function is the main window callback function, and adjusting the window involves calling the main window adjustment interface through the Alpha kernel interaction (AQI) to set the main window boundaries. If the window is not the main window and is a child window, the callback function is the child window callback function, and adjusting the window involves calling the child window adjustment interface through the Alpha kernel interaction (AQI) to set the child window boundaries. Different window types are adjusted according to their classification to improve window diversity.

[0016] In some possible implementations, during the window display process, different areas of the window are drawn by different controls of the application framework to achieve more complex event handling and improve the window's degree of freedom.

[0017] In some possible implementations, during the window display process, the browser kernel performs content self-drawing through the embedded graphics interface egl, wherein the self-drawn control area and the web page content area are drawn using controls of the XComponent component, and the free child window is drawn using child window controls.

[0018] In some possible implementations, a window adjustment request includes a mouse movement event request, adjusting the window includes executing a mouse movement event, adjusting the page of the corresponding window includes adjusting the page effect, and window adjustment failure includes mouse movement speed being lower than a mouse speed threshold.

[0019] In some possible implementations, a window adjustment request includes a multimedia playback request, adjusting the window includes playing multimedia, adjusting the page of the corresponding window includes adjusting the multimedia loading speed or multimedia latency, and window adjustment failure includes the system load exceeding a load threshold.

[0020] In a second aspect, an electronic device is provided, comprising: a processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, causes the electronic device to perform the method described above.

[0021] Thirdly, a computer-readable storage medium is provided, including a program or instructions, wherein the above-described methods are executed when the program or instructions are run on a computer.

[0022] Fourthly, a computer program product is provided, which includes executable instructions that, when executed on a computer, cause the computer to perform the methods described above. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments 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.

[0024] Figure 1 This is a schematic diagram illustrating the interaction between the browser kernel and the system in related technologies;

[0025] Figure 2 This is a flowchart illustrating the application of PC-side window logic to mobile devices in related technologies.

[0026] Figure 3 This diagram illustrates an abnormal display situation that may occur when applying native PC window logic directly to a native mobile system.

[0027] Figure 4 This diagram illustrates another abnormal display situation that may occur when applying native PC window logic directly to a native mobile system.

[0028] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application;

[0029] Figure 6 Examples of applications and scenarios involved in the embodiments of this application;

[0030] Figure 7 This is a schematic diagram of a system architecture in an embodiment of this application;

[0031] Figure 8 This is a timing diagram of an application processing method in an embodiment of this application;

[0032] Figure 9 This is a flowchart illustrating an application processing method in an embodiment of this application.

[0033] Figure 10 This is a flowchart illustrating another application processing method in an embodiment of this application;

[0034] Figure 11 This is a flowchart illustrating another application processing method in an embodiment of this application;

[0035] Figure 12This is a schematic diagram illustrating the interface changes of an electronic device when switching from normal mode to free window mode in an embodiment of this application.

[0036] Figure 13 This is a schematic diagram of an interface for displaying a first window and a second window in an embodiment of this application;

[0037] Figure 14 This is a schematic diagram illustrating the interaction between a browser kernel and a system in an embodiment of this application;

[0038] Figure 15 This is a flowchart illustrating another application processing method in an embodiment of this application;

[0039] Figure 16 This is a schematic diagram of an electronic device display interface according to an embodiment of this application;

[0040] Figure 17 This is a timing diagram of an application processing method in an embodiment of this application;

[0041] Figure 18 This is a schematic diagram of an Ozone architecture in an embodiment of this application. Detailed Implementation

[0042] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0043] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0044] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0045] It should be understood that the term "and / or" used in this article 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, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0046] Before introducing the embodiments of this application, the relevant technologies and their technical problems will be explained first. Taking the display of windows in an application based on the Chromium browser kernel as an example, the native PC solution will be introduced first.

[0047] The native PC solution uses Aura to create a native window for display. Ozone is a platform abstraction layer within the Aura window system, used for low-level input and graphics. Ozone supports various types of underlying systems and invokes Aura by providing platform interface implementations. Figure 1 As shown, in the Ozone-based browser process, the Chromium browser kernel interface and the system interface communicate through a synchronization interface to implement actions such as showing, hiding, maximizing, minimizing, and setting boundaries of the window, as well as exception handling. For example, after the Chromium browser kernel sets the boundaries, it is assumed that the boundaries have been changed as required.

[0048] For native mobile solutions, such as those for tablet systems, a single window is used. While tab switching is possible, it is not possible to create new independent windows or split and drag tabs. In other words, it cannot achieve the more flexible window implementation method found in native PC solutions.

[0049] If you directly apply the native PC window logic to a native mobile system, such as Figure 2 As shown, taking the creation of a new window as an example, in the PC-side logic, since the window is not of a fixed size, the boundaries of the window to be displayed are first determined, including the window's size and position. Then, the interface of the mobile system is called to adjust the window. However, because the mobile system uses a single window, the window size cannot be changed, and the window cannot be moved. This leads to anomalies in window adjustment, which in turn causes display anomalies after the window is drawn and rendered. This is a window compatibility issue caused by different device types. On the PC, the content determines the window, while on the mobile device, the window determines the content. The window implementation method on the PC is more flexible, while the window implementation method on the mobile device is full-screen and has only one window by default. Figure 3 and Figure 4 This illustrates the potential display issues that may arise from directly applying native PC-side window logic to a native mobile system, such as mismatched window sizes. Figure 3 The middle window is full-screen, but its content only occupies a portion of the available area within the window. Figure 4 The content exceeds the window boundaries and is truncated, preventing normal display. In addition, other page errors or unresponsiveness may occur.

[0050] This application embodiment allows applications developed for PCs to be directly applied to mobile systems. On the one hand, it enables mobile devices to achieve more flexible windows like those on PCs. On the other hand, it eliminates the need for separate application development and packaging for mobile devices. The technical solution of this application embodiment is described below.

[0051] Figure 5 A schematic diagram of the structure of an electronic device 100 according to an embodiment of this application is shown.

[0052] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, display screen 194, etc.

[0053] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0054] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0055] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0056] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0057] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0058] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0059] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0060] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0061] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0062] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0063] Electronic device 100 can be a tablet computer or a personal computer (PC), etc. Figure 6 This illustration depicts application scenarios for embodiments of this application, involving various types of applications developed under the OpenHarmony (OH) operating system development framework for various application scenarios. The OH development framework includes Electron, CEF, and Chromium application frameworks, all three of which are implemented based on the Chromium browser kernel. The application scenarios involved may include: 1. Application initial launch, 2. Independent window, 3. Flexible multi-window, 4. Window transition between different devices, 5. Window resizing, 6. Full-screen window, 7. Window splitting and merging, etc. The developed applications may include: 1. Browser applications, 2. Word processing applications, 3. Instant messaging applications, 4. Online classroom applications, 5. Software development applications, 6. Web applications (e.g., video applications, email applications, social applications), etc. Figure 7This section illustrates the window event propagation process based on the software architecture. The process will be explained later; first, the software architecture is introduced. The software architecture includes an application framework based on the ETS language and a browser kernel framework based on the C++ language. ETS (extended TypeScript) is an application development language in the HarmonyOS ecosystem, extending TypeScript (TS) with declarative UI. The ETS-based application framework includes the UIAbility component, an application component in HarmonyOS that contains a UI interface, primarily used for user interaction. After an instance of the UIAbility component is created, the system creates a local window manager, WindowStage, to manage window-related content. WindowStage creates XComponents, a fundamental component of the HarmonyOS system, which enables window drawing or rendering. The C++-based browser kernel framework includes the Chromium browser kernel and the Bridge module. The Bridge module has native XComponent components and is used for conversion between the ETS and C++ languages. The software architecture also includes the Software Development Kit (SDK) and Native Development Kit (NDK) provided by OH. The NDK is the native application programming interface (API) provided by the SDK. The Chromium browser kernel calls the NDK through the embedded graphics interface (EGL), thereby enabling the GPU to render and display windows. Figure 7 In the text, the Bridge module and the process indicated by the arrows are improvements related to the embodiments of this application, and the process will be described in detail in the following content.

[0064] like Figure 8 As shown, this application embodiment provides an application processing method that can be applied to the above-mentioned electronic device. The method includes:

[0065] The application framework executes step 101: sending a window adjustment request to the browser kernel;

[0066] like Figure 7As shown, the browser engine is, for example, the Chromium browser engine in the application. If the application is developed for a PC, the application framework is, for example, an application framework based on the ETS language, which can be a UIAbility component or a system framework including UIAbility components. This application framework can be a mobile system application framework, such as an application framework in a tablet computer system; that is, the execution subject of this method is a tablet computer. In other words, this embodiment of the application can be used for scenarios where a PC-based application is directly applied to a mobile system. The window adjustment request can include new window events, split window events, and other window events involving window adjustment.

[0067] The browser kernel responds to the application framework's window resizing request and executes step 201: resizing the window;

[0068] For example, when a user launches the application for the first time or creates a new window, the application framework detects the event and sends a request to the Chromium browser kernel to adjust the window. This request is called a window adjustment request. The Chromium browser kernel responds to this request by adjusting the window, for example, by obtaining window boundary parameters and calling the application framework's interface based on these parameters. Similarly, in scenarios such as splitting the window, resizing the window, or dragging the window, the application framework sends a window adjustment request to the Chromium browser kernel, which can then respond to the corresponding requests and adjust the window. Specifically, window adjustment can be achieved by obtaining window adjustment parameters and then calling the application framework's interface.

[0069] When the application framework fails to adjust the window, it executes step 102, which notifies the browser kernel to adjust the page of the corresponding window.

[0070] The browser kernel responds to the notification by executing step 202, adjusting the page of the corresponding window;

[0071] For example, a tablet computer has a screen resolution of 1920×1200, and the default logic is to adjust the window size according to 1920×1200. The Chromium browser kernel adjusts the window size to 800×600 according to the PC logic. However, for the mobile application framework, the actual adjusted window size of 800×600 is inconsistent with the default window size of 1920×1200, meaning the window adjustment fails. In this case, the application framework notifies the Chromium browser kernel. Upon receiving this notification, the Chromium browser kernel adjusts the page size of the corresponding window. The corresponding window page is the content page of that window. For example, the Chromium browser kernel adjusts the content page size of the window according to the actual 800×600 window size, so that the adjusted window size matches the content page. Step 102 can be executed when the window adjustment fails. Figure 7 The exception callback process shown can execute step 202 as follows: Figure 7 The exception handling process is shown.

[0072] After the application framework successfully adjusts the window or adjusts the page of the corresponding window, it executes step 103: Display the window.

[0073] If the window adjustment is successful in step 201, it means that the adjusted window and the page match, and the window can be displayed based on the successfully adjusted window. If the window adjustment fails, the page can be readjusted in step 202 to make the adjusted window and the page match, and then the window can be displayed.

[0074] The application processing method in this embodiment adds a feedback mechanism between the browser kernel and the application framework during the adjustment and display of the window. That is, the page is adjusted when the window adjustment fails. In this way, the probability of window display abnormalities caused by directly displaying the window after the window adjustment fails can be reduced, which improves the abnormalities caused by the direct deployment of applications developed on PC systems to mobile devices.

[0075] In some embodiments, such as Figure 9 As shown, the above method also includes:

[0076] In response to the application framework's window adjustment request, the browser kernel executes step 2010: registering a callback function with the application framework. The callback function is used to notify the browser kernel to adjust the page of the corresponding window.

[0077] Step 102 above specifically involves triggering a callback function to notify the browser kernel to adjust the page of the corresponding window. The callback function is an asynchronous callback function, which means that subsequent steps do not need to wait for the callback function to complete. That is, subsequent steps do not need to wait for the browser kernel to complete the adjustment of the page of the corresponding window before proceeding. Instead, other processes can continue to be executed after the callback function is triggered. In fact, there are other steps before drawing and rendering the window. Under normal circumstances, after the browser kernel completes the adjustment of the page of the corresponding window, it can still draw and render based on the adjusted window without causing drawing and rendering abnormalities. Furthermore, since it does not need to wait for the callback function to complete before executing other processes, it will not block the subsequent window rendering process, thereby improving the application's response speed.

[0078] In some embodiments, such as Figure 9 As shown, the above method also includes:

[0079] In response to the application framework's window adjustment request, the browser kernel executes step 2009: obtain window boundary parameters. The window boundary parameters include the window size and the window position, which are the parameters of the window to be adjusted.

[0080] Step 201 above, adjusting the window, includes: calling the application framework's interface based on window boundary parameters to set the window boundaries.

[0081] The aforementioned window adjustment failure includes situations where the window size in the window boundary parameters does not match the preset size. For example, in the previous example, the preset size is 1920×1200, while the obtained window boundary parameters show a window size of 800×600, meaning the window size in the window boundary parameters does not match the preset size. In other possible embodiments, window adjustment failure can be due to at least one of the obtained window boundary parameters not matching the preset window boundary parameters. Besides a mismatch in window size, other window boundary parameters could also be mismatched, such as a mismatch in window position compared to a preset position. Mismatches between the obtained window boundary parameters and the preset window boundary parameters can lead to subsequent display anomalies, and therefore, all can be considered as window adjustment failures, facilitating page adjustments in subsequent steps.

[0082] The above-mentioned successful window adjustment includes: the window size matching the preset size. For example, if the preset size is 1920×1200, and the obtained window boundary parameters also show a window size of 1920×1200, then the window adjustment is successful and no further page adjustments are needed. In other possible embodiments, successful window adjustment can mean that all obtained window boundary parameters match the preset window boundary parameters, including both the window size and the window position.

[0083] Step 202, adjusting the page of the corresponding window, includes adjusting the page of the corresponding window according to the obtained window boundary parameters. For example, in the previous example, the preset size is 1920×1200, while the window size in the obtained window boundary parameters is 800×600. In step 202, the page is adjusted according to the size of 800×600 so that the page matches the actual window.

[0084] In some embodiments, the window boundary parameters obtained in step 2009 can vary depending on the scenario. For example, if the window adjustment request is a window creation request when the application is first launched, the window position in the window boundary parameters is determined based on the screen size, and the window size in the window boundary parameters is determined based on the window content and title bar. That is, when the application is first launched, the window can be set according to the actual screen parameters. If the window adjustment request is a window creation request when the application is not first launched, the size and position of the most recent historical window are used as the window boundary parameters. That is, when the application is not first launched, the window is set according to the previous historical window boundary parameters to improve the user experience.

[0085] In some embodiments, such as Figure 10 As shown, taking the application browser or the creation of a new browser window as an example, the above method includes step 1001, where the user creates a new window. For example, when the user clicks the browser application icon, the browser application is launched, and a new window is created, which generates a window adjustment request. Alternatively, if the user selects the "create new window" option in the current browser application, a window adjustment request will also be generated. In other words, the window adjustment request can be generated in response to the user's operation of creating a new window. Then, the application framework executes step 1002, creating a native window, and then executes step 101. In response to the application framework's window adjustment request, the browser kernel executes step 2009, obtaining window boundary parameters. The obtained window boundary parameters include:

[0086] Step 20091: Determine if an active window exists. If yes, if the application has an active window, proceed to step 20092. If no, proceed to step 20093.

[0087] Step 20092: Use the size and position of the active window as window boundary parameters. For example, if the browser application has already opened a website A, the window of website A is the active window. When the user creates a new window, the size and position of window A are used as the size and position of the new window. That is, the window boundary parameters of the new window are set according to the size and position of the active window.

[0088] Step 20093: Determine if there is a saved window boundary. If yes, that is, if the application does not have an active window but has a saved window boundary, then proceed to step 20094. If no, that is, if the application does not have an active window and does not have a saved window boundary, then proceed to step 20095.

[0089] Step 20094: Use the saved window size and saved window position as window boundary parameters. For browser applications that are not launched for the first time, for example, when the browser application is launched for the first time, there is no active window. However, the browser application will save the window boundary parameters when it exits. When the browser application is launched this time, it will adjust the window according to the window boundary parameters saved when the browser application last exited, so that the browser application will still display the window according to the size and position of the window when it last exited after the launch.

[0090] Step 20095: Determine the position of the window in the window boundary parameters based on the screen size, and determine the size of the window in the window boundary parameters based on the window content and title bar. For a browser application launched for the first time, there are no active or saved windows. Therefore, determine the window boundary parameters based on the actual screen size, window content, and title bar so that the application window launched for the first time is displayed in an appropriate manner.

[0091] It should be noted that the technical solutions of this application embodiment can be applied not only to scenarios of launching an application or creating a new window, but also to scenarios such as dragging and dropping windows after the application has been launched.

[0092] In some embodiments, such as Figure 11 and Figure 12 As shown, before the browser kernel responds to the application framework's window adjustment request, the window is maximized. At this time, the user can control the tablet to switch from normal mode to free window mode. In normal mode, the tablet can only display a full-screen window; in free window mode, a free window can be displayed, and the window size and position can be adjusted. When the user controls the tablet to switch from normal mode to free window mode, a free window adjustment request is generated. That is, the window adjustment request in step 101 can be generated in response to the user's operation of switching from normal mode to free window mode. Adjusting the window includes shrinking the window from a maximized window to a free window; that is, in step 2009, the window boundary parameters corresponding to the shrunken free window are obtained. Step 103, displaying the window, includes shrinking the maximized window to a free window for display.

[0093] Specifically, for example, if the current window is a maximized window with a size of 1920×1200, and the user switches the tablet from normal mode to free window mode, a window adjustment request will be generated. Then, the window boundary parameters corresponding to the shrunk free window will be obtained. For example, if the saved free window size is 800×600, in step 2009, the 800×600 window size will be used as the window boundary parameter. Then, the application framework's interface will be called based on the 800×600 window size to set the window boundary. Since the preset size is 1920×1200, which does not match the 800×600 window size, the window adjustment will fail. At this time, a callback function will be triggered to notify the browser kernel to adjust the page according to the actual 800×600 window size. After the adjustment, the displayed window size will be 800×600, which means that the maximized window can be shrunk to a free window on the mobile device.

[0094] In some embodiments, a window adjustment request includes a window adjustment request for multiple windows; adjusting windows includes adjusting multiple windows; displaying windows includes displaying multiple floating windows.

[0095] Specifically, window adjustment requests can include window splitting requests, requests to resize multiple free windows, requests to drag multiple free windows, etc. By making window adjustment requests for multiple windows, floating multi-window functionality can be achieved on mobile devices.

[0096] In some embodiments, such as Figure 13 As shown, before the browser kernel responds to the application framework's window resizing request and resizes the window, the page displays a first window A1 of the first application; the resized window includes: a newly created second window A2 of the first application; the displayed window includes: displaying the first window A1 and the second window A2, with at least a portion of the second window A2 located outside the first window A1.

[0097] Specifically, taking a browser application as an example, the first window A1 can be the main window of the browser application. When the user clicks the menu bar and moves the mouse to an option, the application framework generates a window adjustment request to create a new second window A2. In response to this request, the application obtains the window size and position of the second window A2. The window position of the second window A2 exceeds the boundary of the first window A2. On mobile devices, there is no such setting method, so the window adjustment will fail. At this time, a callback function is triggered, which notifies the browser kernel to adjust the page according to the actual window size and position of the second window A2. After the adjustment, the second window A2 can be displayed outside the first window A1 on the mobile device, so that the sub-menu can be displayed through the second window A2, thus realizing a more flexible window display method.

[0098] In some embodiments, such as Figure 14As shown, adjusting a window includes showing, hiding, maximizing, minimizing, or setting its boundaries. Figure 14 The system in this context refers to the application framework. Window display refers to the window being displayed in the foreground, while window hiding refers to the application running in the background without the window interface being displayed in the foreground. Setting boundaries includes actions that require setting window boundaries in various situations, such as window dragging. The technical solution of this application embodiment, in these scenarios, compared with traditional technical solutions, adds an exception callback mechanism between the browser kernel and the application framework. That is, through negotiation between the browser kernel and the application framework, the application framework can adjust the page in a timely manner through the browser kernel when handling window exceptions, so as to improve the display problems caused by adjusting window exceptions.

[0099] In addition, Figure 6 In scenarios involving window transitions between different devices, more flexible window implementation methods are also required. Therefore, the methods described in this application can also be used to achieve this.

[0100] In some embodiments, such as Figure 15 As shown, after obtaining the window boundary parameters in step 2009, step 301 is executed to determine whether the window is the main window. If yes, that is, if the window is the main window, then the callback function is the main window callback function, i.e., step 20101 is executed to register the main window callback function with the application framework, and the window is adjusted as in step 2011, by calling the main window adjustment interface through Alpha Kernel Interacting (aki) to set the main window boundary. If it is determined not to be the main window in step 301, then step 302 is executed to determine whether the window is a child window. If yes, that is, if the window is not the main window and the window is a child window, then the callback function is the child window callback function, i.e., step 20102 is executed to register the child window callback function with the application framework, and the window is adjusted as in step 2012, by calling the child window adjustment interface through Alpha Kernel Interacting (aki) to set the child window boundary. If the result is negative in step 302 (i.e., the window is neither the main window nor a child window), then step 20103 is executed to register other window callback functions with the application framework, and step 2013 is executed to call other window adjustment interfaces through AKI to set the boundaries of other windows. After steps 2011, 2012, and 2013, subsequent steps are executed depending on whether window adjustment fails.

[0101] Specifically, for window adjustment, corresponding window callback functions can be registered for different window types, and corresponding window adjustment interfaces can be called to set the corresponding window boundaries. Based on differences in window display formats, windows can be divided into various types. For example, windows can include main windows, child windows, and other windows. Child windows can be, for example, menus, and other windows can be, for example, pop-ups. For instance, during window adjustment, it can first be determined whether the window to be adjusted is the main window. If it is the main window, then according to the characteristics of a main window, the corresponding callback function is registered and the main window adjustment interface is called to set the main window boundaries. If it is not the main window, then it can be determined whether the window to be adjusted is a menu. If it is a menu, then according to the characteristics of a menu, the corresponding callback function is registered and the menu adjustment interface is called to set the menu boundaries. If it is not a menu, then it can be determined whether the window to be adjusted is a pop-up window, that is, according to the characteristics of a pop-up window, the corresponding callback function is registered and the pop-up window adjustment interface is called to set the pop-up window. It should be noted that subsequent steps also adjust the settings according to the window type. For example, in step 102, the callback function registered earlier will be executed here. In step 202, the window type will be determined, and the page will be adjusted according to the characteristics of that window type. It's important to understand that this window type classification is merely an example; window types can be classified based on the actual characteristics of the window.

[0102] In some embodiments, during the window display process, different areas of the window are drawn by different controls of the application framework. By mapping different areas of the window to different controls of the application framework, more complex event handling can be achieved, increasing the window's flexibility and enabling a more flexible window display method. For example, the Chromium browser engine's window framework Ozone is layered to correspond to different controls of the application framework.

[0103] In some embodiments, such as Figure 16 As shown, during the window display process, the browser kernel performs content self-drawing through the embedded graphics interface egl. The self-drawn control area B1 and the webpage content area B2 are drawn using controls from the XComponent component, while the free child window B3 is drawn using the Subwindow control. The self-drawn control area B1 can be used to display window controls, such as maximize and minimize controls, while the webpage content area B2 can be used to display the window's page content. Figure 16 In this context, region B4 refers to the region provided by the application framework, which can interface with the title bar and buttons of the OH application framework. In some possible implementations, controls in the self-drawn control region B1 can be set in region B4 and directly implemented by the application framework. B5 is an independent window, which can be implemented using the UIAbility component in the application framework.

[0104] like Figure 17 As shown below, the process of creating a window is illustrated using an example. The UIAbility component creates a window manager (WindowStage) and loads the page content. The WindowStage creates an XComponent component, which loads a bridge component (Bridge). The Bridge component initializes and registers bridge-related callbacks, then returns the callbacks to the XComponent component. The Bridge component sends a window creation request to the browser kernel. The browser kernel obtains window boundary parameters based on this request, such as the window size, and then registers a callback function based on these parameters. This callback function is used to notify the browser kernel to adjust the screen if window adjustment fails. After registering the callback function, the browser kernel can notify the XComponent component to adjust the window by calling an API. The XComponent component then creates a canvas and causes the Bridge component to adjust the window according to the obtained window boundary parameters. If the window size in the window boundary parameters does not match the preset size, the adjustment fails, triggering the callback function to notify the browser kernel. The browser kernel then triggers this callback function, adjusting the screen, or page, according to the window size in the window boundary parameters. If the adjustment is successful, the subsequent process is executed directly. The Bridge component creates an eglsurface through the window component. The browser kernel sends a request to the Bridge component to display the window. The Bridge component then causes the XComponent component to draw the window to complete the creation of the canvas. Figure 16 The diagram also illustrates the window resizing process outside of window creation. The XComponent sends a window resizing request to the Bridge component. The Bridge component resizes the window through the embedded graphics interface egl. If the resizing fails, it notifies the browser kernel to adjust the canvas and finally displays the window, completing the window resizing. Figure 16 The document also illustrates the window destruction process: when the application exits, the XComponent sends a window destruction request to the Bridge component. After the Bridge component executes the window destruction, the window destruction is complete.

[0105] like Figure 17As shown, the embodiments of this application can be applied to the Ozone platform framework. Taking window implementation as an example, the Ozone platform framework has an X11 interface and its window module to implement window functionality. The Ozone platform framework also has a Wayland interface and its window module to implement window functionality. This embodiment adds an interface and its window module for OHOS on top of these. The OHOS interface and OHOS window module can be configured with browser core functions mentioned in the above methods. Furthermore, the OHOS application framework can be configured with application framework functions mentioned in the above methods. Thus, applications developed on the PC based on Ozone can be directly applied to mobile devices without the need for separate mobile application development and packaging. Through the negotiation mechanism between the browser kernel and the application framework, more flexible window functionality is achieved.

[0106] In some possible implementations, a window adjustment request includes a mouse movement event request, adjusting the window includes executing a mouse movement event, adjusting the page of the corresponding window includes adjusting the page effect, and window adjustment failure includes mouse movement speed being lower than a mouse speed threshold.

[0107] Specifically, for example, when the mouse moves, the browser kernel responds to the application framework's mouse movement event request, executes the mouse movement event, and displays the mouse trajectory; when the mouse movement speed is lower than a mouse speed threshold, the application framework notifies the browser kernel to adjust the page effects to reduce the adverse impact of page effects on mouse movement smoothness; the browser kernel responds to the notification and adjusts the page effects; the application framework displays the window after the mouse movement speed is not lower than the mouse speed threshold or after adjusting the page effects. During mouse movement, a feedback mechanism is added between the browser kernel and the application framework, that is, adjusting the page effects when the mouse movement speed is slow. This reduces the adverse impact of page effects on mouse movement smoothness, thus improving the anomalies caused by directly deploying applications developed for PC systems to mobile devices.

[0108] In some possible implementations, a window adjustment request includes a multimedia playback request, adjusting the window includes playing multimedia, adjusting the page of the corresponding window includes adjusting the multimedia loading speed or multimedia latency, and window adjustment failure includes the system load exceeding a load threshold.

[0109] Specifically, for example, when playing a video, the browser kernel responds to the multimedia playback request and plays the multimedia. When the system load is high, such as exceeding 80%, the application framework notifies the browser kernel to adjust the multimedia loading speed or latency, for example, by reducing the multimedia loading speed or increasing the playback latency, to free up system resources for other functions and improve system efficiency. The browser kernel responds to the notification and adjusts the multimedia loading speed or latency accordingly. When the system load is low, such as below 80%, or after adjusting the multimedia loading speed or latency, the application framework displays the window. During multimedia playback, a feedback mechanism is added between the browser kernel and the application framework. That is, when the system load is high, the multimedia loading speed or latency is adjusted, thus freeing up system resources for other functions and improving system efficiency. This improves the anomaly of high system load caused by directly deploying applications developed for PC systems to mobile devices.

[0110] This application also provides an electronic device, including a processor and a memory, wherein the memory stores at least one instruction, which, when loaded and executed by the processor, causes the electronic device to perform the method described in any of the above embodiments. This electronic device can be the electronic device 100 described above.

[0111] The electronic devices involved in this application may be any product such as smart TVs, mobile phones, tablets, personal computers (PCs), personal digital assistants (PDAs), smartwatches, wearable electronic devices, augmented reality (AR) devices, virtual reality (VR) devices, in-vehicle devices, drone devices, smart cars, smart speakers, robots, smart glasses, etc.

[0112] This application also provides a computer-readable storage medium, including a program or instructions, wherein the methods of any of the above embodiments are executed when the program or instructions are run on a computer.

[0113] This application also provides a computer program product containing executable instructions that, when executed on a computer, cause the computer to perform the methods of any of the above embodiments.

[0114] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0115] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0116] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An application processing method, characterized in that, include: The browser kernel responds to the application framework's window resizing request and resizes the window accordingly. When the window adjustment fails, the application framework notifies the browser kernel to adjust the page corresponding to the window. The browser kernel responds to the notification by adjusting the page corresponding to the window; The application framework displays the window after the window adjustment is successful or the page corresponding to the window is adjusted.

2. The method according to claim 1, characterized in that, Also includes: In response to the application framework's window adjustment request, the browser kernel registers a callback function with the application framework. The callback function is used to notify the browser kernel to adjust the page corresponding to the window. When the application framework fails to adjust the window, it notifies the browser kernel to adjust the page corresponding to the window, including: the application framework triggers the callback function when the window adjustment fails; The callback function is an asynchronous callback function.

3. The method according to claim 2, characterized in that, Also includes: The browser kernel responds to the application framework's window adjustment request by obtaining window boundary parameters, which include the window size and the window position. The adjustment window includes: calling the application framework's interface based on the window boundary parameters to set the window boundaries; The failure to adjust the window includes: the size of the window does not match the preset size; The successful adjustment of the window includes: the size of the window matching the preset size; The browser kernel adjusts the page corresponding to the window by adjusting the page corresponding to the window according to the window boundary parameters.

4. The method according to claim 3, characterized in that, If the window adjustment request is a window creation request when the application is first launched, then the position of the window in the window boundary parameters is determined according to the screen size, and the size of the window in the window boundary parameters is determined according to the window content and the title bar; If the window adjustment request is a window creation request that is not made when the application is first launched, then the size and position of the most recent historical window are used as the window boundary parameters.

5. The method according to claim 3, characterized in that, The window adjustment request is generated in response to the user's operation of creating a new window; The acquisition of window boundary parameters includes: If the application has an active window, the size and position of the active window will be used as window boundary parameters. If the application does not have an active window, but has a saved window boundary, then the size and position of the saved window will be used as the window boundary parameters. If the application does not have an active window and no saved window boundaries, the window position in the window boundary parameters is determined based on the screen size, and the window size in the window boundary parameters is determined based on the window content and title bar.

6. The method according to claim 3, characterized in that, Before the browser kernel responds to the application framework's window resizing request, the window is a maximized window. The window adjustment request is generated in response to the user's action; The adjustment window includes shrinking the window from a maximized window to a free window; The display of the window includes shrinking the maximized window to a free window display.

7. The method according to claim 3, characterized in that, The window adjustment request includes window adjustment requests for multiple windows; The adjustment window includes adjusting multiple windows; The display of the window includes: displaying multiple floating windows.

8. The method according to claim 3, characterized in that, Before the browser kernel responds to the application framework's window resizing request, the first window of the first application is displayed on the page. The adjustment window includes: a second window for creating a new first application; The display of the window includes: displaying the first window and the second window, wherein at least a portion of the second window is located outside the first window.

9. The method according to claim 3, characterized in that, The adjustment window includes showing, hiding, maximizing, minimizing, or setting boundaries of the window.

10. The method according to claim 3, characterized in that, If the window is the main window, then the callback function is the main window callback function, and the adjustment window is to set the main window boundary by calling the main window adjustment interface through the Alpha kernel interaction (aki). If the window is not the main window and is a child window, then the callback function is the child window callback function, and the adjustment window is to set the child window boundary by calling the child window adjustment interface through the Alpha kernel interaction (AQI).

11. The method according to claim 1, characterized in that, During the display of the window, different areas of the window are drawn by different controls of the application framework.

12. The method according to claim 11, characterized in that, During the display of the window, the browser kernel performs content self-drawing through the embedded graphics interface egl. The self-drawing control area and the web page content area are drawn using controls of the XComponent component, and the free child window is drawn using child window controls.

13. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store at least one instruction that, when loaded and executed by the processor, causes the electronic device to perform the method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, Includes a program or instructions that, when run on a computer, execute the method as described in any one of claims 1 to 12.

15. A computer program product, characterized in that, The computer program product includes executable instructions that, when executed on a computer, cause the computer to perform the method described in any one of claims 1 to 12.