A portrait and landscape screen switching processing method and device and electronic equipment

Abstract

The application discloses a horizontal-vertical screen switching processing method and device and electronic equipment. The method comprises the following steps: when detecting that the screen of the electronic equipment is switched from horizontal to vertical or from vertical to horizontal, saving the user interface state data currently displayed by the electronic equipment; obtaining target layout parameters based on the horizontal-vertical screen switching, wherein the target layout parameters are used for dynamically calculating the user interface layout, so that the user interface is adaptively adjusted to a new screen direction according to the user interface layout when the horizontal-vertical screen switching occurs; and sending the user interface state data and the target layout parameters to an application program corresponding to the user interface, so that the application program obtains a redrawn user interface according to the target layout parameters, and recovers the interface state data in the redrawn user interface according to the user interface state data, and the redrawn user interface is adapted to the screen after the horizontal-vertical screen switching. The application alleviates the problem of UI state loss caused by screen rotation, significantly reduces the workload of the developer for manually recovering the UI state, and reduces the development complexity and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and electronic device for switching between portrait and landscape screens. Background Technology

[0002] Screen rotation is a common scenario in Android application development, especially in applications that support landscape and portrait switching, such as video players, electronic whiteboards, and e-readers.

[0003] However, by default, when the device rotates, the Android system destroys the current application interface (Activity) and recreates it to adapt to the new screen orientation. While this mechanism ensures that the UI adapts to different screen orientations, it also causes a series of problems. For example, because the Activity is destroyed and recreated, temporary UI states (such as text input, scroll position, playback progress, etc.) are lost. Developers need to write additional code to manually restore the state, which increases development complexity and maintenance costs. Summary of the Invention

[0004] One objective of this application is to provide a method, apparatus, and electronic device for switching between portrait and landscape modes, in order to solve the technical problem that some temporary UI states need to be manually restored by developers by writing additional code when the screen is rotated, which leads to increased development complexity and maintenance costs.

[0005] To address the aforementioned technical problems, one technical solution adopted in this application is: providing a screen orientation switching processing method applied to an electronic device, comprising: when a screen orientation switch is detected in the electronic device, saving the user interface state data currently displayed by the electronic device; obtaining target layout parameters based on the screen orientation switch, the target layout parameters being used to dynamically calculate the user interface layout so that the user interface adaptively adjusts to the new screen orientation according to the user interface layout during the screen orientation switch; sending the user interface state data and the target layout parameters to the application corresponding to the user interface, so that the application obtains a redrawn user interface according to the target layout parameters, and restores the interface state data in the redrawn user interface according to the user interface state data, the redrawn user interface being adapted to the screen after the screen orientation switch.

[0006] In this way, the UI state is automatically saved at the system layer and passed to the application layer. The system layer obtains the target layout parameters, which ensure the UI structure is adjusted, avoiding the need for developers to manually adjust the layout to adapt to screen orientation switching. The application layer only needs to parse the data provided by the system and restore the UI, which reduces the amount of manual coding. Therefore, this method not only alleviates the problem of UI state loss due to screen rotation, but also significantly reduces the workload of developers manually restoring the UI state, lowering development complexity and maintenance costs.

[0007] Optionally, when a screen orientation change is detected on the electronic device, the user interface state data currently displayed on the electronic device is saved, including: acquiring sensor data; triggering a save request when a screen orientation change is detected on the electronic device based on the sensor data; acquiring the user interface state data currently displayed on the electronic device based on the save request; and saving the user interface state data to the virtual stack.

[0008] By storing UI state through a virtual Activity stack and using sensors to detect screen orientation changes, seamless adaptation is achieved when switching between portrait and landscape modes. Compared to traditional Activity reconstruction methods, this approach avoids UI state loss, reduces the burden on developers to manually write state restoration code, and improves the smoothness of interface transitions.

[0009] Optionally, saving the user interface state data to a virtual stack includes: extracting the most recently stored user interface state data of the electronic device from the virtual stack; obtaining user interface state difference data based on the most recently stored user interface state data and the currently displayed user interface state data; and saving the user interface state difference data to the virtual stack.

[0010] In this way, by storing only the parts where the interface changes, storage and computational overhead are reduced, and state recovery efficiency is improved.

[0011] Optionally, the target layout parameters are obtained based on the screen orientation change, including: obtaining global adaptation parameters based on the screen orientation change, the global adaptation parameters including the screen aspect ratio change and the touch coordinate transformation matrix; obtaining local control adaptation parameters based on the screen orientation change; wherein, the screen aspect ratio change, the touch coordinate transformation matrix and the local control adaptation parameters constitute the target layout parameters.

[0012] In this way, the screen aspect ratio change, touch coordinate transformation matrix, and local control adaptation parameters are combined to form target layout parameters, which can provide a more comprehensive and accurate calculation basis for the layout adaptation of the entire user interface, thereby ensuring that the interface display can adapt smoothly and accurately under different screen orientations.

[0013] Optionally, global adaptation parameters are obtained based on screen orientation switching, including: obtaining the original screen size of the electronic device before screen orientation switching and the new screen size of the electronic device after screen orientation switching; calculating the change in screen aspect ratio of the electronic device based on the original screen size and the new screen size; calculating the corresponding touch point coordinates after screen orientation switching based on the corresponding touch point coordinates before screen orientation switching, the screen rotation angle, and the physical width and physical height of the electronic device, and the corresponding touch point coordinates after screen orientation switching constitute a touch coordinate transformation matrix.

[0014] In this way, by calculating the change in screen aspect ratio and the touch coordinate transformation matrix, it is possible to accurately adapt to different screen orientations and sizes, maintaining the accuracy and consistency of controls and touch.

[0015] Optionally, the adaptation parameters of local controls are obtained based on the screen orientation change, including: calculating the screen scaling ratio of the electronic device based on the original screen size and the new screen size; obtaining the original anchor point coordinates of the controls displayed in the user interface before the screen orientation change; calculating the new anchor point coordinates of the controls after the screen orientation change based on the original anchor point coordinates and the touch coordinate transformation matrix; and calculating the position information of the controls after the screen orientation change based on the new anchor point coordinates and the screen scaling ratio; wherein the new anchor point coordinates and the position information of the controls after the screen orientation change constitute the adaptation parameters of the local controls.

[0016] In this way, the new anchor point coordinates and changes in control position ensure that the controls can dynamically adjust their position and size according to the screen size and orientation after switching between portrait and landscape modes. The controls can accurately adapt to the new layout and touch requirements, improving the application's adaptability, responsiveness, and user experience.

[0017] Optionally, the method further includes: calibrating the coordinates of the new anchor point and the position information of the control after switching between landscape and portrait modes to obtain the adaptation parameters of the calibrated local control.

[0018] In this way, by calibrating the adaptation parameters of local controls (including the coordinates of the new anchor point and the position information of the controls after switching between landscape and portrait modes), we can ensure a smooth transition and accurate adaptation of the controls when switching between landscape and portrait modes.

[0019] Optionally, sending user interface state data and target layout parameters to the application corresponding to the user interface includes: encapsulating the user interface state data and target layout parameters into a context object; and using the Binder mechanism to pass the context object to the application corresponding to the user interface.

[0020] By encapsulating user interface state data and target layout parameters in a context object and passing them to the application via the Binder mechanism, the application is able to restore its state before the screen rotation, such as text and scroll position, thus improving the continuity and consistency of the user experience.

[0021] To address the aforementioned technical problems, one technical solution adopted in this application is: providing a screen orientation switching processing device applied to an electronic device, comprising: a user interface state data storage module, used to store the currently displayed user interface state data of the electronic device when a screen orientation switch is detected; a target layout parameter acquisition module, used to acquire target layout parameters based on the screen orientation switch, the target layout parameters being used to dynamically calculate the user interface layout so that the user interface adaptively adjusts to the new screen orientation according to the user interface layout during the screen orientation switch; and a data processing module, used to send the target layout parameters and user interface state data to the application corresponding to the user interface, so that the application obtains a redrawn user interface according to the target layout parameters, and restores the interface state data in the redrawn user interface according to the user interface state data; the redrawn user interface is adapted to the screen after the screen orientation switch. This screen orientation switching processing device has the beneficial effects corresponding to the aforementioned screen orientation switching processing method.

[0022] To address the aforementioned technical problems, one technical solution adopted in this application is to provide an electronic device, including a memory and a processor. The memory is connected to the processor, and the processor executes one or more computer programs stored in the memory. When the processor executes the one or more computer programs, it enables the electronic device to implement a screen orientation switching method applicable to the electronic device. This electronic device possesses the beneficial effects corresponding to the aforementioned screen orientation switching method applicable to the electronic device. Attached Figure Description

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

[0024] Figure 1 This is a flowchart of a screen switching method provided in an embodiment of this application;

[0025] Figure 2 This is a flowchart of a method for saving the user interface state data currently displayed on an electronic device when the screen of an electronic device is detected to be switching between portrait and landscape modes, according to an embodiment of this application.

[0026] Figure 3 This is a flowchart of a method for obtaining target layout parameters based on landscape / portrait screen switching, provided in an embodiment of this application.

[0027] Figure 4 This is a flowchart of a landscape / portrait screen switching method provided in another embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the structure of a landscape / portrait screen switching processing device provided in an embodiment of this application;

[0029] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of 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.

[0031] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be performed in a different order than the module division in the device or the order in the flowchart.

[0032] In the Android system, this is achieved through configuration files (such as the AndroidManifest.xml file). <activity>Setting the `screenOrientation` parameter in the `<activity>` element controls the screen orientation adaptation of the Activity. `screenOrientation` is defined in `AndroidManifest.xml`. <activity>An attribute of the `<activity>` element specifies the screen orientation of an `Activity`, preventing or allowing screen rotation. An `Activity` is an application interface component in an Android application, representing a screen that a user can interact with. Each application typically has multiple `Activities`, which can be navigated between each other.

[0033] When the device rotates, by default, the system destroys the current Activity and recreates it to load a UI layout suitable for the new screen orientation (landscape or portrait). This is the default behavior of the Android system to adapt to different screen orientations and ensure that the UI layout adapts to the new orientation. When an Activity is destroyed and recreated, the temporary UI state is lost; the data corresponding to this temporary UI state is stored in the Activity's memory. For example, text input will be cleared; scroll position may return to the top; playback progress may be reset; selected state may revert to the default option; pop-up state may disappear, etc.

[0034] To preserve UI state during screen rotation, developers need to write additional code to manually restore the state, increasing development complexity and maintenance costs. Since the Activity is destroyed upon rotation, developers must manually save UI data, such as text input, scroll position, and selection status, and then restore this data. If the Activity contains multiple interactive components (such as a video player), developers need to store and restore the state of each component separately, significantly increasing the amount of code. Furthermore, if the UI logic is adjusted (e.g., a new input field is added), developers need to manually update the state saving logic; otherwise, the newly added component may not restore the correct data during rotation. In large projects, multiple Activities may have different state management methods, and team members need to understand these methods to avoid introducing bugs, further increasing maintenance costs. Therefore, writing additional code to manually restore UI state does indeed increase development complexity and maintenance costs.

[0035] Therefore, this application provides a method and apparatus for handling screen orientation switching. By detecting changes in the screen orientation of the electronic device, the current user interface state data is saved in real time, and target layout parameters are calculated based on screen rotation, enabling the interface layout to dynamically adapt to the new screen orientation. Subsequently, the user interface state data and target layout parameters are transmitted to the application to redraw the user interface and restore the original interface state in the new layout, ensuring that the user maintains a consistent interactive experience after screen rotation. In this application embodiment, the UI state is automatically saved at the system layer and transmitted to the application layer, which can seamlessly adapt to screen rotation, improve UI state recovery capability, reduce development costs, and optimize user experience. The system layer obtains the target layout parameters, which ensure UI structure adjustment and avoid developers manually adjusting the layout to adapt to screen orientation switching. The application layer only needs to parse the data provided by the system and restore the UI, which reduces the amount of manual coding. Therefore, the solution of this application embodiment not only alleviates the problem of UI state loss caused by screen rotation, but also significantly reduces the workload of developers manually restoring UI state, reduces development complexity and maintenance costs, and improves user experience.

[0036] Additionally, under the default screen rotation mechanism of the Android system, the destruction and reconstruction of the Activity may cause layout misalignment issues. Among these, fixed aspect ratio controls (such as video players, images, game screens, etc.) are prone to black border issues, stretching and distortion issues, and UI component position disorder issues when the screen ratio changes abruptly.

[0037] To address the aforementioned issues, the landscape / portrait screen switching processing method of this application calculates global adaptation parameters and local control adaptation parameters to ensure seamless UI adaptation to the new screen orientation, preventing layout misalignment, control deformation, and touch offset. Global adaptation parameters are calculated to apply to the entire screen, primarily by obtaining the screen dimensions before and after the landscape / portrait screen switch and calculating the change in screen aspect ratio to ensure the UI adapts to the proportional changes in different orientations. A touch coordinate transformation matrix is ​​calculated using the screen rotation angle, device physical dimensions, and touch point coordinates to ensure accurate touch point positions after rotation. Local control adaptation parameters are calculated to apply to individual UI controls, primarily by calculating the screen scaling ratio to ensure control sizes adjust according to screen changes. The anchor point coordinates of the control before rotation are obtained, and the new anchor point coordinates after rotation are calculated using the touch coordinate transformation matrix. The new position of the control after rotation is calculated by combining the screen scaling ratio and the new anchor point coordinates, ensuring the interface layout remains unchanged and does not shift. This solution, based on screen ratio and touch coordinate transformation matrix, enables precise adjustment of interface layout and touch position with rotation. When switching between portrait and landscape modes, the position, size, and interaction logic of controls remain consistent to avoid issues such as black borders, stretching, or misalignment. The system also correctly maps the user's touch position after rotation, preventing touch point shift.

[0038] Building upon the aforementioned solutions, to ensure accurate positioning and smooth transition of local controls after switching between portrait and landscape orientations, this application also introduces a calibration mechanism for anchor point coordinates and position information. This optimizes the touch experience and prevents control position drift or misalignment. By calibrating the local control adaptation parameters (new anchor point coordinates + control position information), UI adaptation accuracy is further improved, enabling a smooth layout transition during screen orientation switching and accurately matching the new screen direction. This optimizes the user interaction experience and reduces development and maintenance costs.

[0039] The landscape / portrait screen switching method provided in this application is applied to electronic devices, which can be large-screen electronic devices, including electronic whiteboards, all-in-one conference machines, smart TVs, and in-vehicle central control screens. These large-screen electronic devices run Android or a customized Android-based system. Alternatively, these electronic devices can be small-screen electronic devices such as smartphones, which also run Android or a customized Android-based system.

[0040] The following specific embodiments illustrate the landscape / portrait screen switching method proposed in this application.

[0041] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for switching between portrait and landscape modes according to an embodiment of this application. The method includes:

[0042] S1. When a screen switching between portrait and landscape modes is detected on an electronic device, the user interface state data currently displayed on the electronic device is saved.

[0043] This user interface state data refers to information related to the interface currently displayed on the electronic device screen, including but not limited to the hierarchical structure and attributes (such as visibility, position, size, color, etc.) of all UI components (such as buttons, text boxes, images, lists, etc.) contained in the current interface. This includes the text content of input boxes, the progress value of sliders, the enabled / disabled state of buttons, the current application's interface navigation stack, including the previous Activity and the state of the current Activity, currently executing animations (such as interface transitions, pop-ups, etc.), and the business data of the current interface (such as the text being entered, selected list items, etc.).

[0044] When an electronic device screen switches between portrait and landscape orientations, saving this user interface state data is crucial for correctly restoring the UI state after the switch, preventing the loss of user actions or display anomalies after interface reconstruction. For example, generating a snapshot of the original state using a GL texture handle and differentially compressing the Activity stack data using Huffman coding can efficiently store and restore the interface state.

[0045] In some embodiments, please refer to Figure 2 Step S1 specifically includes:

[0046] S11. Acquire sensor data. For example, detect changes in screen orientation using accelerometers or gyroscopes. Based on the data collected by these sensors, determine whether the device's posture has changed (e.g., from portrait to landscape, or from landscape to portrait).

[0047] S12. When sensor data detects a screen orientation change in the electronic device, a save request is triggered. For example, by analyzing the X, Y, and Z axis data of the accelerometer, the screen rotation angle is determined; if a change in screen orientation is detected (e.g., from 0° to 90° or from 90° to 0°), a save request is triggered. For example, if a change in the X-axis or Y-axis acceleration direction is detected, and the gyroscope rotational angular velocity exceeds a set threshold, a save request is triggered. For example, if a change in the X-axis or Y-axis acceleration direction is detected, i.e., the X-axis or Y-axis acceleration value exceeds a certain threshold, and the duration of this change exceeds a preset time window (e.g., 200ms), a save request is triggered.

[0048] S13. Obtain the current user interface state data displayed by the electronic device according to the save request.

[0049] It can collect information such as the hierarchy of the currently displayed user interface, control states, and GL texture handles. It can also obtain Activity stack information, including the Activity to which the current screen belongs and its lifecycle state. Furthermore, it can obtain the screen frame buffer, which is used to preserve visual snapshots of the interface.

[0050] S14. Save the user interface state data to the virtual stack.

[0051] A virtual stack refers to a memory structure used to store user interface state data. A virtual Activity stack can be created within WindowManagerServic. WindowManagerServic is a core service of the Android system, responsible for window management, screen rotation, focus switching, and input event scheduling. WindowManagerServic runs in the System Server process and is a system service primarily managing windows and display. WindowManagerServic can directly interact with SurfaceFlinger to control the application window's hierarchy, animation, size, and focus. When the screen rotates, application windows change, or multiple screens are displayed on the device, WindowManagerServic is responsible for adjusting the UI. Creating a virtual Activity stack within WindowManagerServic allows for saving and restoring Activity states during screen rotation, avoiding UI reconstruction issues. WindowManagerServic can maintain multiple virtual stacks, managing multi-screen and multi-task stacks to achieve smooth interface switching and efficient resource utilization.

[0052] Normally, when the screen rotates, the system destroys the current Activity and recreates it, which causes UI flickering and loss. By creating a virtual stack in WindowManagerService, the state of the current Activity stack can be saved before rotation and restored after rotation, avoiding the re-creation of Activities. This way, users will not perceive any delay or interface change, providing a smooth rotation experience.

[0053] This embodiment stores UI state through a virtual Activity stack and uses sensors to detect changes in screen orientation, achieving seamless adaptation when switching between portrait and landscape modes. Compared to traditional Activity reconstruction methods, this solution avoids UI state loss, reduces the burden on developers to manually write state restoration code, and improves the smoothness of interface switching.

[0054] In some embodiments, saving user interface state data to a virtual stack includes: extracting the most recently stored user interface state data from the virtual stack; obtaining user interface state difference data based on the most recently stored user interface state data and the currently displayed user interface state data; and saving the user interface state difference data to the virtual stack. The system can obtain a snapshot of the user interface from the virtual stack at the time of the last rotation or state change. This snapshot includes all relevant state information (such as the activity stack, window size, position, and state of interface elements). Next, based on the most recently stored user interface state data and the currently displayed user interface state data, the interface state difference data is calculated. This difference data includes newly added, modified, or deleted interface elements and states. This difference data can be compressed before storage to reduce storage space. For example, Huffman coding can be used to compress these changed parts, reducing unnecessary redundant storage. To optimize storage space, Huffman coding is used to compress the difference data. Huffman coding is a lossless data compression algorithm that can compress frequently occurring parts to a smaller size, reducing storage space. Assuming the variance data includes some common changes (such as button state, scroll position, etc.), Huffman coding can assign shorter codes to these changes and longer codes to less common changes, thereby effectively reducing storage space.

[0055] This embodiment only stores the parts where the interface changes, thereby reducing storage and computational overhead and improving state recovery efficiency.

[0056] S2. Obtain target layout parameters based on landscape / portrait screen switching.

[0057] Target layout parameters refer to a set of calculated parameters used during user interface (UI) adaptation to ensure that UI elements display correctly across different screen sizes, orientations (portrait and landscape), and resolutions. These parameters describe how controls (or other UI elements) adjust to screen changes to maintain UI layout adaptability and consistency. Target layout parameters include screen aspect ratio changes, touch coordinate transformation matrices, and adaptation parameters for local controls.

[0058] Please see Figure 3 The target layout parameters obtained based on screen orientation switching include:

[0059] S21. Obtain global adaptation parameters based on screen orientation switching. Global adaptation parameters include screen aspect ratio change and touch coordinate transformation matrix.

[0060] Specifically, the original screen size of the electronic device before switching between portrait and landscape orientations is obtained, as well as the new screen size of the electronic device after the switch. Based on the original and new screen sizes, the change in the screen aspect ratio of the electronic device is calculated. Based on the touch point coordinates before the switch, the screen rotation angle, and the physical width and height of the electronic device, the touch point coordinates after the switch are calculated, and the touch point coordinates after the switch constitute a touch coordinate transformation matrix.

[0061] In this context, "portrait / landscape switching" refers to switching from landscape to portrait mode, or vice versa. Assuming the current screen is switching from landscape to portrait, the original screen size of the electronic device before the switch refers to the screen size when the device is in landscape mode. Specifically, this size can be the ratio of the screen's width to height in landscape mode; this ratio is the original aspect ratio. The new screen size of the electronic device after the switch refers to the screen size when the device is in portrait mode. Specifically, this size can also be the ratio of the screen's width to height in portrait mode; this ratio is the new aspect ratio. The change in the screen's aspect ratio is the ratio of the new aspect ratio to the original aspect ratio. This ratio reflects the change in the screen's aspect ratio during the switch. This change in aspect ratio is fundamental to the entire adaptation process, determining the scaling ratio of the entire UI.

[0062] When a device switches from portrait to landscape or vice versa, the screen's coordinate system changes. The aspect ratios of portrait and landscape screens differ, requiring non-linear interpolation of the coordinates, especially when the aspect ratio changes. To accurately achieve this transformation, the rotation angle and the physical dimensions of the electronic device can be considered. This process can utilize trigonometric functions (such as cosine and tangent values) to establish rules for the coordinate transformation.

[0063] For example, assuming the screen aspect ratio is 16:9, the touch coordinates x and y need to be non-linearly interpolated proportionally when switching between portrait and landscape modes. In portrait mode, assuming the aspect ratio is 9:16, it will become 16:9 when switching to landscape mode. Assuming the touch point coordinates are (x_before, y_before) before the screen switch, these coordinates correspond to the user's touch position. The rotation angle during the screen switch is assumed to be 90° or 270°. The physical width (screenWidth) and physical height (screenHeight) of the electronic device are also obtained. When calculating the touch point coordinates after the screen switch, for a 90° rotation (assuming a change from portrait to landscape), the touch point coordinates (x_before, y_before) will be converted to (y_before, screenHeight - x_before). For a 270° rotation (assuming a reverse rotation from portrait to landscape), the touch point coordinates (x_before, y_before) are converted to (screenWidth - y_before, x_before). Based on the rotation angle and the physical width and height of the electronic device, the coordinate transformation formulas can be defined: For a 90° rotation, the touch point coordinates in landscape mode are: x = y_before, y = screenHeight - x_before. For a 270° rotation, the touch point coordinates in landscape mode are: x = screenWidth - y_before, y = x_before. Therefore, the touch point coordinates after switching between portrait and landscape modes can be obtained.

[0064] To ensure accurate conversion of touch point coordinates across different device orientations, a touch coordinate transformation matrix can be constructed. This matrix adjusts the coordinate system based on the device's physical dimensions and rotation angle. During screen orientation changes, the matrix helps convert the user's touch point coordinates from the original coordinate system (e.g., portrait coordinate system) to the target coordinate system (e.g., landscape coordinate system). By mapping touch coordinates from one coordinate system to another through matrix transformation, the user's touch operations are accurately reflected during screen orientation changes.

[0065] S22. Obtain the adaptation parameters of local controls based on landscape / portrait screen switching.

[0066] Specifically, the screen scaling ratio of the electronic device is calculated based on the original screen size and the new screen size; the original anchor point coordinates of the controls displayed in the user interface before the screen orientation change are obtained; the new anchor point coordinates of the controls after the screen orientation change are calculated based on the original anchor point coordinates and the touch coordinate transformation matrix; and the position information of the controls after the screen orientation change is calculated based on the new anchor point coordinates and the screen scaling ratio. Among these, the new anchor point coordinates and the position information of the controls after the screen orientation change constitute the adaptation parameters of the local controls.

[0067] In this embodiment, when switching between portrait and landscape modes, the UI controls can be adapted according to changes in screen size and the anchor point coordinates of the controls, including adjusting the size and position of the controls.

[0068] When switching between portrait and landscape modes, the screen size changes. The screen scaling ratio refers to the ratio of the original screen size to the new screen size. It reflects the change in screen size and affects the scaling of controls. Assuming the original screen width is W1 and the original height is H1, and the new screen width is W2 and the new height is H2, then the screen scaling ratio can be calculated as: Scaling Ratio = W2 / W1, H2 / H1. This scaling ratio determines how the size of controls changes, especially the width and height, which are scaled proportionally.

[0069] Before switching between portrait and landscape modes, the position of controls can be represented by anchor point coordinates, which are the control's position relative to the screen or container. These anchor point coordinates can be a reference point of the control (e.g., top left corner, center point, etc.) and are determined relative to the screen's dimensions. After switching between portrait and landscape modes, the screen's coordinate system changes, and touch coordinates need to be adapted to the new coordinate system using a transformation matrix. The transformation matrix maps the original touch coordinates to the new coordinate system. This process, through the touch coordinate transformation matrix, converts the original control anchor point coordinates to the new coordinates after the screen orientation switch.

[0070] After switching between portrait and landscape orientations, the positions of controls also need to be adjusted. Percentage layouts (referring to percentages relative to the screen size) can be used to calculate the new positions of controls. For example, calculate the new anchor coordinates of the control: `anchor_x = (x_new / W_old)*W_new`, `anchor_y = (y_new / H_old)*H_new`. Here, `(x_new / W_old)` represents the relative position of the control before the screen orientation switch, that is, the proportion of the control's anchor coordinates relative to the original screen width. Then, multiplying by the new screen width `W_new` gives the absolute position of the control's anchor point on the new screen after the orientation switch. Similarly, `(y_new / H_old)` calculates the relative position of the control within the original screen height, and multiplying by the new screen height `H_new` gives the new absolute position. This ensures that the position of controls adapts to changes in screen size, and that the size and position of controls are calculated based on relative positions. Controls refer to various interactive or display elements in the user interface, such as buttons, text boxes, scrollbars, and sliders.

[0071] Therefore, the new position and anchor point coordinates of the control after switching between portrait and landscape orientations constitute the adaptation parameters of the local control. These local control adaptation parameters help the system accurately locate the position and size of the control under different screen sizes, ensuring that the user interface adapts to different devices and screen orientations.

[0072] In this embodiment, the changes in the coordinates of the new anchor point and the position of the control ensure that the control can dynamically adjust its position and size according to the screen size and orientation after switching between portrait and landscape modes. The control can accurately adapt to the new layout and touch requirements, improving the application's adaptability, responsiveness, and user experience.

[0073] In some embodiments, the method further includes calibrating the new anchor point coordinates and the corresponding position information of the control after switching between landscape and portrait orientations to obtain calibrated adaptation parameters for the local control. The Bezier compensation model can be used to calibrate the adaptation parameters of the local control (including the new anchor point coordinates and the control position information after switching between landscape and portrait orientations) to ensure a smooth transition and accurate adaptation of the control during screen orientation switching. A Bezier curve is a mathematical curve used for smooth transitions. Its shape is defined by control points, and it is widely used in animation and graphics rendering, especially in scenarios requiring smooth changes. In this embodiment, the purpose of calibrating these adaptation parameters is to ensure a smooth transition in the position and size of the control during screen rotation (e.g., from landscape to portrait or vice versa), without sudden jumps or unnatural changes, thereby improving the user experience. By adjusting the control points, the Bezier curve can smooth the changes in position and size of the control during screen orientation switching, avoiding abrupt changes and enhancing the smoothness of the interface. Through Bezier curve interpolation, it is ensured that the position and size of the control are accurately adapted to the new screen size and orientation, without offset or deformation.

[0074] For example, a control's original position is (x_old, y_old), its screen size in landscape mode is W_old, H_old, and its new screen size in portrait mode is W_new, H_new. After calculating the touch coordinate transformation matrix, the new anchor point coordinates (x_new, y_new) are obtained. However, to smoothly transition to the new coordinates, a Bezier compensation model is used to adjust them. Assuming the control points of the Bezier curve are (x_old, y_old) and (x_new, y_new), interpolation is used to calculate the control's intermediate position at various moments during the landscape / portrait switching process, ensuring that the control's position change does not occur abruptly, thus achieving a smooth transition.

[0075] S3. Send user interface state data and target layout parameters to the application corresponding to the user interface, so that the application can obtain the redrawn user interface according to the target layout parameters, and restore the interface state data in the redrawn user interface according to the user interface state data. The redrawn user interface is adapted to the screen after the landscape / portrait screen switch.

[0076] The process involves encapsulating user interface state data and target layout parameters into a context object (such as a Context object), and then using the Binder mechanism to pass the context object to the application corresponding to the user interface. The Context object is an object in Android that transmits environment information; it can store some global state information and pass it between different components. The Binder mechanism is an important method of inter-process communication (IPC) in Android. Through the Binder mechanism, the system can pass objects and data between different processes, ensuring efficient exchange of information between applications and system services.

[0077] After receiving the target layout parameters, the application adjusts the layout based on information such as changes in screen aspect ratio and touch coordinate transformation matrix. The position and size of controls, as well as interface elements, are rearranged according to the new screen size and orientation to ensure that the interface displays well in the new orientation.

[0078] This embodiment encapsulates user interface state data and target layout parameters in a context object and passes them to the application through the Binder mechanism. This ensures that the application can restore the state before the switch, such as text and scroll position, after the screen is rotated, thus improving the continuity and consistency of the user experience.

[0079] Please see Figure 4 , Figure 4 This is a flowchart illustrating a screen orientation switching method according to another embodiment of this application. In this embodiment, the Android system layer includes three core modules: a dynamic layout engine, an input event remapping module, and a state persistence module. These three modules work together within the Android system to optimize the screen orientation switching experience and ensure user interface adaptation, accurate input event processing, and persistent state preservation.

[0080] The dynamic layout engine adjusts the layout of controls in real time based on device rotation or screen orientation changes, ensuring the application displays correctly across different screen orientations. This includes real-time reception of sensor data, dynamically acquiring information such as device rotation angle and acceleration changes through gyroscope and accelerometer data. This data is used to detect whether the device has switched between portrait and landscape orientations or changed screen orientation. It also employs a hybrid algorithm combining constraint layout and percentage layout. This means that the layout position and size of controls are dynamically calculated and adjusted not only based on traditional dimensions and positions but also on the screen aspect ratio, ensuring accurate adaptation of control size and relative position across different screen orientations. Furthermore, it uses `Matrix.postRotate()` to rotate the canvas instead of rearranging controls. This allows all drawn content on the canvas to be rotated directly without needing to re-layout controls. This avoids layout rebuilding caused by screen orientation changes, improving performance and reducing interface flickering and lag. The dynamic layout engine can adjust the layout in real time according to device orientation changes, optimizing the user experience during screen orientation changes and improving system performance.

[0081] The input event remapping module ensures correct processing and mapping of touch events when the device orientation changes, preventing touch coordinate errors caused by screen orientation switching. It includes establishing a touch coordinate transformation matrix, as the screen's aspect ratio and coordinate system change after orientation switching. By acquiring the original coordinates of the touch event, new touch coordinates are calculated based on the cosine of the rotation angle and the device's physical width and height. Additionally, it features non-linear interpolation, using an interpolation algorithm to smoothly transition the touch event coordinates, avoiding abrupt changes and inaccurate coordinate mapping.

[0082] The state preservation module ensures that the user's interface state is saved and restored when the device switches between portrait and landscape modes or other contextual changes, preventing the user from losing input data or the progress of the current interface. It creates a virtual Activity stack and uses the Binder mechanism to pass serialized data to the application. It also employs differential storage technology, saving only layout differences instead of saving the entire layout state each time.

[0083] These three modules improve the user experience when switching between portrait and landscape modes by adjusting the layout, handling input events, and saving and restoring the state.

[0084] Please see Figure 5 , Figure 5 This is a schematic diagram of a landscape / portrait screen switching processing device provided in an embodiment of this application. The device 20 includes:

[0085] The user interface state data saving module 201 is used to save the user interface state data currently displayed by the electronic device when the screen of the electronic device is detected to be switching between landscape and portrait modes.

[0086] The target layout parameter acquisition module 202 is used to acquire target layout parameters based on the screen orientation change. The target layout parameters are used to dynamically calculate the user interface layout so that the user interface can adaptively adjust to the new screen orientation according to the user interface layout when the screen orientation changes.

[0087] The data processing module 203 is used to send target layout parameters and user interface state data to the application corresponding to the user interface, so that the application can obtain the redrawn user interface according to the target layout parameters, and restore the interface state data in the redrawn user interface according to the user interface state data; the redrawn user interface is adapted to the screen after the landscape and portrait screen switching.

[0088] The aforementioned landscape / portrait screen switching processing device 20 can be a software module. The software module includes several instructions, which are stored in a memory. The processor can access the memory, call the instructions, and execute them to complete the landscape / portrait screen switching processing method described in the above embodiments.

[0089] In some embodiments, the aforementioned screen orientation switching processing device 20 can also be constructed from hardware devices. For example, the screen orientation switching processing device 20 can be constructed from one or more chips, and the chips can work in coordination to complete the screen orientation switching processing method described in the various embodiments. As another example, the aforementioned screen orientation switching processing device 20 can also be constructed from various logic devices, such as general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), microcontrollers, ARM (Acorn RISC Machine) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these components.

[0090] It should be noted that the above-mentioned screen orientation switching processing device 20 can execute the screen orientation switching processing method for electronic devices provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in the embodiments of the screen orientation switching processing device 20 can be found in the above-mentioned screen orientation switching processing method for electronic devices provided in the embodiments of this application.

[0091] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 30 includes one or more processors 301 and a memory 302. The memory 302 is connected to one or more processors 301, for example, via a bus.

[0092] Processor 301 is configured to support the electronic device 30 in performing the corresponding functions in the methods described in the above method embodiments. Processor 301 may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0093] Memory 302 is used to store program code, etc. Memory 302 may include volatile memory (VM), such as random access memory (RAM); memory may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 302 may also include combinations of the above types of memory.

[0094] The memory 302 can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the screen orientation switching processing method in the embodiments of this application. The processor 301 executes various functional applications and data processing of the screen orientation switching processing method and the screen orientation switching processing device by running the non-volatile software programs, instructions, and modules stored in the memory 302, thereby realizing the functions of each module or unit of the screen orientation switching processing method and the screen orientation switching processing device provided in the above method embodiments.

[0095] The memory 302 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function. The data storage area may store data created based on the use of the screen orientation switching processing device. In some embodiments, the memory 302 may include memory remotely located relative to the processor 301, and this remote memory may be connected to the screen orientation switching processing device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0096] The one or more modules are stored in the memory 302. When executed by the one or more processors 301, they perform the screen switching processing method in any of the above method embodiments. For example, they perform the method steps described in the above method embodiments to realize the functions of the modules described in the above device embodiments.

[0097] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 301 can enable the above-described one or more processors to execute the landscape / portrait screen switching processing method in any of the above method embodiments, for example, to execute the above-described... Figures 1 to 4 The method steps in the text are to achieve the following: Figure 5 The functionality of the modules within.

[0098] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by the electronic device, enable the electronic device to perform the screen orientation switching method in any of the above method embodiments, for example, to perform the above-described... Figures 1 to 4 The method steps in the text are to achieve the following: Figure 5 The functionality of the modules within.

[0099] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0100] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.< / activity> < / activity>

Claims

1. A method for switching between portrait and landscape screens, applied to electronic devices, characterized in that, include: When a screen orientation switch is detected in the electronic device, the user interface state data currently displayed by the electronic device is saved. Based on the screen orientation switching, target layout parameters are obtained. These target layout parameters are used to dynamically calculate the user interface layout so that the user interface can adaptively adjust to the new screen orientation according to the user interface layout when switching between screen orientations. The user interface state data and the target layout parameters are sent to the application corresponding to the user interface, so that the application obtains the redrawn user interface according to the target layout parameters, and restores the interface state data in the redrawn user interface according to the user interface state data. The redrawn user interface is adapted to the screen after the landscape / portrait screen switch.

2. The method according to claim 1, characterized in that, When a screen orientation change is detected on the electronic device, the current user interface state data displayed on the electronic device is saved, including: Acquire sensor data; When the sensor data detects a screen orientation change in the electronic device, a save request is triggered. Obtain the current user interface status data displayed by the electronic device according to the save request; Save the user interface state data to the virtual stack.

3. The method according to claim 2, characterized in that, Saving the user interface state data to the virtual stack includes: Extract the most recently stored user interface state data of the electronic device from the virtual stack; Based on the most recently stored user interface state data and the currently displayed user interface state data, obtain user interface state difference data; The user interface state difference data is saved to the virtual stack.

4. The method according to claim 1, characterized in that, The step of obtaining the target layout parameters based on the screen orientation switch includes: The global adaptation parameters are obtained based on the screen orientation switching, and the global adaptation parameters include the screen aspect ratio change and the touch coordinate transformation matrix; Based on the landscape / portrait screen switching, the adaptation parameters of local controls are obtained; The target layout parameters consist of the screen aspect ratio change, the touch coordinate transformation matrix, and the adaptation parameters of the local controls.

5. The method according to claim 4, characterized in that, The process of obtaining global adaptation parameters based on the landscape / portrait screen switching includes: Obtain the original screen size of the electronic device before switching between landscape and portrait modes, and the new screen size of the electronic device after switching between landscape and portrait modes; Calculate the change in screen aspect ratio of the electronic device based on the original screen size and the new screen size; Based on the touch point coordinates before the screen orientation switch, the screen rotation angle, and the physical width and height of the electronic device, the touch point coordinates after the screen orientation switch are calculated, and the touch point coordinates after the screen orientation switch constitute the touch coordinate transformation matrix.

6. The method according to claim 5, characterized in that, The process of obtaining adaptation parameters for local controls based on the screen orientation switch includes: Calculate the screen scaling ratio of the electronic device based on the original screen size and the new screen size; Obtain the original anchor point coordinates of the controls displayed in the user interface before switching between portrait and landscape modes; Calculate the new anchor point coordinates of the control after switching between landscape and portrait modes based on the original anchor point coordinates and the touch coordinate transformation matrix. Based on the new anchor point coordinates and the screen scaling ratio, calculate the position information of the control after switching between portrait and landscape modes; The coordinates of the new anchor point and the position information of the control after switching between portrait and landscape modes constitute the adaptation parameters of the local control.

7. The method according to claim 6, characterized in that, The method further includes: The coordinates of the new anchor point and the position information of the control after switching between landscape and portrait modes are calibrated to obtain the adaptation parameters of the local control after calibration.

8. The method according to claim 1, characterized in that, Sending the user interface state data and the target layout parameters to the application corresponding to the user interface includes: The user interface state data and the target layout parameters are encapsulated into a context object; The context object is passed to the application corresponding to the user interface using the Binder mechanism.

9. A landscape / portrait screen switching processing device, applied to electronic devices, characterized in that, include: The user interface state data saving module is used to save the user interface state data currently displayed by the electronic device when the screen of the electronic device is detected to be switching between portrait and landscape modes. The target layout parameter acquisition module is used to acquire target layout parameters based on the screen orientation switching. The target layout parameters are used to dynamically calculate the user interface layout so that the user interface can adaptively adjust to the new screen orientation according to the user interface layout when switching between screen orientations. The data processing module is used to send the target layout parameters and the user interface state data to the application corresponding to the user interface, so that the application can obtain the redrawn user interface according to the target layout parameters and restore the interface state data in the redrawn user interface according to the user interface state data; the redrawn user interface is adapted to the screen after the landscape / portrait screen switch.

10. An electronic device, characterized in that, include: A memory and a processor, the memory being connected to the processor, the processor being configured to execute one or more computer programs stored in the memory, the processor, when executing the one or more computer programs, causing the electronic device to perform the method as described in any one of claims 1-8.

Images