Camera application launch method and electronic device

Abstract

Provided in the present application are a camera application launch method and an electronic device. In the method, after the electronic device receives an operation to launch a camera and before stream configuration is executed, SurfaceFlinger is controlled to composite layers at a low frame rate, such that resources occupied for layer composition corresponding to launch animation are reduced, allowing more resources to be occupied for stream configuration, preview stream capture, etc., thereby rapidly outputting the first preview frame, improving the camera application launch speed, and enhancing user experience.

Description

A method for launching a camera application and an electronic device Technical Field

[0001] This application relates to the field of terminals, and more particularly to a camera application launch method and an electronic device. Background Technology

[0002] Currently, more and more electronic devices have camera apps installed. After the user enters the command to launch the camera app, it often takes a long time for the camera app to start.

[0003] Therefore, how to quickly launch the camera application is an urgent problem to be solved.

[0004] Summary of the Invention

[0005] This application provides a camera application launch method and an electronic device. In this method, after the electronic device receives an operation to launch the camera, and before executing stream configuration, the Surface flinger is controlled to use a low frame rate to composite layers. This reduces the resources occupied by the layer compositing corresponding to the launch animation, allowing more resources to be used for stream allocation, capturing the preview stream, etc., thereby quickly outputting the first preview frame, improving the launch speed of the camera application, and enhancing the user experience.

[0006] In a first aspect, this application provides, for example, a camera application launch method applied to an electronic device, the method comprising: displaying a first interface; at a first time point, in response to a first operation on the first interface, starting to launch a camera application; at the first time point, the composite frame rate of the electronic device is a first frame rate; after the first time point, setting the composite frame rate to a second frame rate, the second frame rate being less than the first frame rate; after setting the composite frame rate to the second frame rate, distributing the stream to the camera application; and after distributing the stream to the camera application, displaying a second interface, the second interface including a preview image.

[0007] After implementing the method provided in the first aspect, the system resource consumption of the compositing layer task can be reduced by lowering the compositing frame rate of the electronic device after the camera starts up and before the streaming is completed. The freed-up system resources can be used for streaming, accelerating the completion of streaming and the acquisition of preview images, thereby improving the startup speed of the camera application.

[0008] In conjunction with the method described in the first aspect, setting the synthesized frame rate to the second frame rate includes: setting the synthesized frame rate to the second frame rate based on the first frame rate being greater than a first threshold, and / or the number of foreground applications of the electronic device being less than or equal to a second threshold.

[0009] In this way, by reducing the composite frame rate to the second frame rate when the first frame rate is high, and / or reducing the composite frame rate to the second frame rate when only the camera application is running in the foreground, it avoids the impact on the running status of applications other than the camera application by using a low composite frame rate in multi-application running scenarios (split-screen, picture-in-picture, etc.), and can reduce the composite frame rate in high composite frame rate scenarios, thereby improving the startup speed of the camera application.

[0010] In conjunction with the method described in the first aspect, the method further includes: displaying the startup animation of the camera application based on the synthesized frame rate of the electronic device as a second frame rate.

[0011] This allows for a reduction in the composite frame rate before the launch animation is displayed (or played), using the reduced second frame rate to composite the launch animation layer, thereby freeing up more resources for streaming and improving the startup speed of the camera application.

[0012] In conjunction with the method described in the first aspect, playing the startup animation of the camera application includes: playing the startup animation of the camera application based on the first frame rate before setting the composite frame rate to the second frame rate; and playing the startup animation of the camera application based on the second frame rate after setting the composite frame rate to the second frame rate.

[0013] In this way, the first frame rate can be used to continue compositing the layer corresponding to the startup animation. If it is determined that a frame rate reduction is needed during the startup animation compositing process, the reduced second frame rate can be used to composite the layer corresponding to the startup animation. This ensures timely compositing of the layer corresponding to the startup animation in scenarios where frame rate reduction is not required, without waiting for a frame rate reduction determination before starting the compositing process. In conjunction with the method described in the first aspect, the electronic device also includes: a camera server, a camera hardware abstraction layer (camera HAL), and a camera. Stream allocation to the camera application includes: the camera server configuring the preview image stream corresponding to the parameters set in the camera application through the camera HAL; these parameters include any one or more of the following: the frame rate of the camera application, the resolution of the preview image, or the zoom ratio.

[0014] In conjunction with the method described in the first aspect, the electronic device includes a processor, which includes a first core; playing a startup animation of a camera application includes: using the first core to play a startup animation of launching the camera application; and distributing a stream to the camera application includes: using the first core to distribute a stream to the camera application. Wherein, if the processor is a multi-core processor, the first core may be a medium core or a large core in the processor.

[0015] In this way, in scenarios where compositing layers and streaming are usually assigned to the first core for execution, by coordinating the competition between compositing layers and streaming for the first core, the core resources occupied by SF compositing layers are reduced, and the core resources occupied by streaming are increased accordingly, thus accelerating the completion of streaming. This allows the first preview image to be output in a timely manner after the startup animation finishes playing, giving users a quick experience of launching the camera application.

[0016] In conjunction with the method described in the first aspect, after displaying the second interface, the method further includes setting the synthesized frame rate to any one or more of the following: the first frame rate, the second frame rate, or the fourth frame rate, wherein the fourth frame rate is lower than the second frame rate.

[0017] This allows you to continue using the second frame rate after successfully launching the camera app and displaying the preview image. Alternatively, you can revert to the first frame rate, ensuring timely updates to the preview image and improving the user's shooting experience. Another option is to further reduce the frame rate from the second to the fourth frame rate, which can save power and extend the device's battery life.

[0018] In conjunction with the method described in the first aspect, the method further includes: at a second time point, in response to a second operation on the second interface, starting the first application; after the second time point, setting the synthesized frame rate to a third frame rate, the third frame rate being equal to the first frame rate, or the third frame rate being equal to the frame rate of the first application.

[0019] This allows you to reset the composite frame rate based on the specific scenario after exiting the camera app or launching a second app other than the camera app.

[0020] In conjunction with the method described in the first aspect, the electronic device includes: a first module and a surface synthesizer (SF); setting the synthesized frame rate to a second frame rate specifically includes: the first module determining that the synthesized frame rate is set to the second frame rate; the first module sending the second frame rate to the SF; and the SF setting the synthesized frame rate to the second frame rate.

[0021] In conjunction with the method described in the first aspect, the first module determines that the synthesized frame rate is set to the second frame rate, specifically including: the first module obtaining the first frame rate and the number of foreground applications of the electronic device; based on the first frame rate being greater than a first threshold, and / or the number of foreground applications of the electronic device being less than or equal to a second threshold, determining that the synthesized frame rate is set to the second frame rate.

[0022] In conjunction with the method described in the first aspect, the electronic device includes: a second module; the first module obtains the first frame rate and the number of foreground applications of the electronic device, specifically including: the second module sending the following scene information to the first module: the first frame rate and the number of foreground applications of the electronic device.

[0023] In conjunction with the method described in the first aspect, the electronic device includes a camera server, which has a pre-configured staging function. Before the second module sends the following scene information to the first module, the method further includes: after the first operation, the second module determines that the camera application has started by using the staging function.

[0024] In a second aspect, this application provides an electronic device comprising: one or more memories, one or more processors, and one or more cameras; the memories are coupled to the one or more processors, the memories being used to store computer program code including computer instructions, and the one or more processors calling the computer instructions to cause the electronic device to perform the methods described in any of the first aspects.

[0025] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform the method described in any of the first aspects.

[0026] Fourthly, this application provides a computer program product including a computer program / instructions that, when run on an electronic device, cause the electronic device to perform the method described in any of the first aspects. Attached Figure Description

[0027] Figures 1A-1C are schematic diagrams of a set of operation interfaces for an optimized pre-cold start camera application provided in the embodiments of this application;

[0028] Figures 2A-2C are schematic diagrams of a set of operation interfaces for a pre-optimized hot-start camera application provided in the embodiments of this application;

[0029] Figure 3 is a schematic diagram comparing the camera application startup before and after optimization according to an embodiment of this application;

[0030] Figures 4A and 4B are schematic diagrams of a set of optimized cold-start camera application operation interfaces provided in the embodiments of this application;

[0031] Figures 5A and 5B are schematic diagrams of a set of optimized hot-start camera application operation interfaces provided in the embodiments of this application;

[0032] Figure 6 is a schematic diagram of the camera application startup method provided in an embodiment of this application;

[0033] Figure 7 is a schematic diagram of the hardware architecture of the electronic device provided in an embodiment of this application;

[0034] Figure 8 is a schematic diagram of the software architecture of the electronic device provided in the embodiment of this application. Detailed Implementation

[0035] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0036] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0037] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0038] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with a user. It realizes the conversion between the internal form of information and the form that the user can receive. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0039] First, let me introduce the relevant concepts involved in this application.

[0040] Camera application startup includes the process of the electronic device receiving a user input to start the application, outputting a startup animation, and displaying the first preview frame. The camera application is considered successfully started only after stream configuration is completed, the first preview frame in the preview stream is synthesized, and a preview interface containing the first preview image is displayed.

[0041] Key threads involved in the camera application startup process:

[0042] (1) UI thread (also known as the main thread). This main thread is mainly responsible for executing tasks related to the user interface, such as performing layer compositing tasks corresponding to the user interface, including compositing the layers corresponding to the startup animation during the camera application startup process through the Surfaceflinger (SF), and compositing the layers corresponding to the preview interface after the camera application has successfully started.

[0043] The startup animations include cold start animations and warm start animations. For the user interfaces corresponding to these two types of startup animations, please refer to the descriptions of Figures 1A-1C and 2A-2C below. They will not be elaborated here.

[0044] (2) Preview Thread. This thread is mainly responsible for performing tasks that communicate with the hardware camera, such as stream configuration and controlling the camera to capture preview streams.

[0045] (3) Other threads. Taking the image processing thread as an example, when performing operations such as autofocus, touch focus, face detection, position management, rotation management, zoom, etc., additional threads may be involved to handle these tasks.

[0046] CPU scheduling for camera applications: When a camera application is in the aforementioned multi-threaded state, one or more of the following resource scheduling methods can be used to execute the multi-threading.

[0047] (1) Time-sharing execution: In a multi-threaded environment, the CPU can allocate execution time to each thread through time-slicing. Each thread is allocated a time slice, during which the thread can obtain the CPU's execution right. When the time slice is used up, even if the thread's task is not completed, it will be paused, and the CPU will transfer to another thread to continue execution.

[0048] (2) Multi-core parallel execution: In a multi-threaded environment, if an electronic device is configured with multiple cores, it can run multiple threads simultaneously, that is, distribute different threads to different cores for parallel execution. Usually, since the large cores among multiple cores have stronger computing power, multiple threads can also be distributed to medium and large cores and executed in a time-sharing or priority manner.

[0049] Currently, launching camera applications on electronic devices is relatively slow. Specifically, after a user inputs the command to launch the camera application, the device begins launching the application. This launch includes displaying a launch animation and, after the animation ends, displaying a preview image captured by the camera application. The process of displaying the launch animation involves compositing the corresponding layer using Flash (SF), and streaming the camera application before outputting the preview image. However, the compositing layer and streaming are typically assigned to mid-core and high-core processors, meaning there is a conflict between them competing for resources. Therefore, when the SF compositing layer consumes a significant amount of the device's resources, while the streaming consumes relatively few, the streaming becomes slow. This results in a prolonged wait after the launch animation finishes playing before the first preview frame is output, causing the camera application to launch slowly for the user.

[0050] To address the aforementioned technical problems, this application provides a camera application launch method and an electronic device. In this method, after the electronic device receives an operation to launch the camera, and before executing stream configuration, the Surface Flinger (SF) is controlled to composite layers using a low compositing frame rate. This allows the UI thread involved in layer compositing to release some core resources, enabling the preview thread involved in stream allocation and capturing preview images to occupy more core resources, thereby quickly outputting the first preview frame, improving the camera application launch speed, and enhancing the user experience.

[0051] In this embodiment of the application, the composite frame rate of the electronic device refers to the frame rate of the SF composite layer, for example, the number of frames of the composite layer per second.

[0052] Next, we will take Figures 1A-1C as an example to introduce in detail the operation interface of the cold start camera application before optimizing the camera application startup speed.

[0053] A cold start occurs when an electronic device launches an application before it has a background process running, requiring the device to create a new process for the application. In this case, the application needs to load all resources and data from scratch, resulting in a relatively long startup time. Cold starts typically occur when a user first opens an application or when an application is restarted after being killed by the system.

[0054] Figure 1A illustrates the cold start phase 1 of the camera application. Phase 1 includes: receiving an operation to launch the camera application, and in response to the operation, starting the camera application. Since no process for the camera application was running in the background of the electronic device before this launch, this launch of the camera application can be understood as a cold start. The cold start includes starting streaming and playing a cold start animation. This cold start animation includes refreshing the current user interface, i.e., adding a window displaying the camera application to the current user interface. Typically, before playing the cold start animation, the electronic device also needs to draw and render the interface elements of the cold start animation, and composite the layers corresponding to the cold start animation.

[0055] For example, upon receiving an operation on the camera application icon 111 in user interface 11, the system responds to this operation by starting the camera and displaying a cold start animation. This cold start animation includes refreshing from user interface 11 to user interface 12. User interface 11 is the desktop of the electronic device, and user interface 12 is also the desktop of the electronic device, the difference being that user interface 12 includes a new window 121 provided by the camera application, which can be a black and white image window.

[0056] Figure 1B illustrates the cold start phase 2 of the camera application. Phase 2 includes: continuing to launch the camera application, but displaying a non-preview image in the preview interface because no preview image has been acquired. Specifically, since the streaming and displaying of the launch animation for launching the camera application takes a long time, the camera launch process is lengthy. That is, after starting the camera application as described in Phase 1, streaming and cold start animations must continue to be executed. Continuing to output the cold start animations includes: continuously refreshing the user interface. As the user interface refreshes, the windows of the camera application contained in each user interface gradually enlarge until the preview interface is displayed in full screen. After the preview interface is displayed, if the camera application fails to stream successfully and does not acquire a preview image, a non-preview image is displayed in the refreshed preview window until the camera application successfully streams and acquires a preview image, at which point the real-time acquired preview image is displayed in the refreshed preview window.

[0057] For example, refreshing from display user interface 12 to display user interface 13, and refreshing from display user interface 13 to display user interface 14, etc. User interface 12 includes a window 121 provided by the camera application, and user interface 13 includes a window 131 provided by the camera application, where the area of ​​window 131 is larger than that of window 121. User interface 14 is the preview interface, which includes a preview window 151. At this time, since the camera application has not yet acquired a preview image, the preview window 151 does not display a preview image; for example, it displays a black image.

[0058] Figure 1C illustrates the cold start phase 3 of the camera application, which includes: successfully launching the camera application and displaying the preview image in the preview interface. Specifically, as the camera application launches, it completes the streaming and acquires the preview image, thus displaying it in the refreshed preview interface.

[0059] For example, refresh from displaying user interface 14 to displaying user interface 15, and from displaying user interface 15 to displaying user interface 16. In user interface 15, the preview window 151 still does not display the preview image, while the preview window 161 in user interface 16 displays the preview image. This is because the camera application has already acquired the preview image, so the preview window 161 displays the preview image.

[0060] The foregoing examples, using Figures 1A-1C as examples, exemplify an interface for cold-starting a camera application and should not be construed as limiting this application. For instance, the methods for triggering a cold start of the camera application are not limited to operations on the camera application icon 111, but may also include: calling the camera application through other applications, through voice commands, gestures, etc. Furthermore, the animation output during the cold start process is not limited to gradually enlarging the black window until a preview interface is displayed; it may include more or fewer display effects. For example, the gradually enlarging window may be a different color not shown in Figure 1A, or it may be a window with transparency or blur. This application embodiment does not specifically limit the display form of the window color, transparency, shape, position, etc., in this startup animation. In addition, while outputting the gradually enlarging window, a mask can be added on top of the underlying interface content to ensure that the user can focus on key user interaction tasks.

[0061] The cold start stages 1 to 3 shown in Figures 1A-1C are merely for illustrating the images played at different points in time during the cold start animation playback process. These three stages are used as examples to illustrate the process, and they do not have any practical limiting significance. The number of stages should not constitute a limitation on this application.

[0062] Next, we will take Figures 2A-2C as an example to introduce in detail the operation interface of warm-starting the camera application before optimizing the camera application startup speed.

[0063] A warm start refers to a situation where an application's process already exists in the background before the electronic device launches it. When the device launches the application again, the system directly uses the existing background process. In this case, the application doesn't need to reload all resources, thus resulting in a faster startup speed. Warm starts typically occur when a user reopens the application through a multitasking interface.

[0064] Figure 2A illustrates the camera application warm start phase 1, which includes receiving an operation to start the camera application.

[0065] For example, upon receiving a swipe-up action at the bottom of user interface 21, user interface 22, also known as a multitasking interface, is output in response to the action. This user interface 22 includes cards corresponding to multiple background applications, such as card 221 corresponding to the camera application. Upon receiving an action on card 221, the electronic device enters the camera application warm-start phase 2 in response to the action.

[0066] The content displayed on card 221 includes the content displayed when the camera application last exited from the foreground to the background. Taking the user interface shown in Figure 1C as an example, if the electronic device detects a "return to desktop" operation on user interface 16, the camera application exits from the foreground to the background. Therefore, the content displayed on card 221 includes the preview image displayed in the preview window 161. Optionally, the content displayed on card 221 may have a certain blur effect, or it may have a certain transparency effect, or it may be content displaying a black image, etc. This embodiment of the application does not specifically limit the display form of the content on card 221.

[0067] Figure 2B illustrates the camera application warm-start phase 2, which includes: in response to the aforementioned operation for launching the camera application, starting the camera application. Since the camera application process was running in the background on the electronic device prior to this launch, this launch can be understood as a warm-start. The warm-start includes starting streaming and playing the warm-start animation. This animation includes: continuously refreshing the user interface; as the user interface refreshes, the windows of the camera application contained in each user interface gradually enlarge until a full-screen preview interface is displayed. After displaying the preview interface, if the camera application has not acquired a preview image, a non-preview image is displayed in the refreshed preview window until the camera application acquires a preview image, at which point the real-time preview image is displayed in the refreshed preview window. Typically, before playing the warm-start animation, the electronic device also needs to draw and render the interface elements of the warm-start animation, and composite the layers corresponding to the cold-start animation.

[0068] For example, the display user interface 22 refreshes to the display user interface 23, and then refreshes to the display user interface 24. User interface 23 includes a window 231 provided by the camera application, which contains the content of the aforementioned card 221. User interface 24 is the preview interface, which includes a preview window 241. At this time, since the camera application has not yet acquired a preview image, the preview window 241 does not display the currently acquired preview image, but instead displays the content previously contained in card 221. Optionally, the preview window 241 may also display a completely black image, or the displayed content may have a certain blur effect. This embodiment does not specifically limit the display format of the content in the preview window 241.

[0069] Figure 2C illustrates stage 3 of the camera application's warm-up process. Stage 3 includes: successfully launching the camera application and displaying the preview image in the preview interface. Specifically, as the camera application launches, it completes the streaming and acquires the preview image, thus displaying it in the refreshed preview interface.

[0070] For example, the user interface refreshes from displaying user interface 24 to displaying user interface 25, and then refreshes from displaying user interface 25 to displaying user interface 26. User interface 25 includes a preview window 251. Since the camera application has not yet acquired a preview image, preview window 251 continues to display the content from the previous preview window 241. User interface 26 includes a preview window 261. Since the camera application has acquired a preview image, preview window 261 displays the real-time preview image.

[0071] The foregoing examples, using only Figures 2A-2C, exemplify a user interface for a hot-start camera application and should not be construed as limiting this application. For instance, the methods for triggering a hot-start camera application are not limited to operations on card 221 in the multitasking interface; they can also include operations on the camera application icon, the camera application capsule, invoking the camera application through other applications, voice commands, and gesture operations. Furthermore, the animation effects output during the hot-start process are not limited to gradually enlarging the interface content from the previous exit until a preview interface is displayed; they can also include more or fewer display effects. For example, while outputting a gradually enlarging window, a mask might be added above the underlying interface content to ensure the user focuses on the key user interaction task, i.e., the camera startup animation.

[0072] The warm-start stages 1 to 3 shown in Figures 2A-2C are merely for demonstrating the images played at different points in time during the warm-start animation playback process. The warm-start animation is exemplarily divided into 3 stages, and these stages do not have any practical limiting significance, nor should the number of stages constitute a limitation on this application.

[0073] Based on the aforementioned operation interfaces for cold and warm starts of the camera application, it can be seen that without optimizing the camera application startup speed, starting the camera application involves: after the startup operation, waiting for the startup animation to finish playing, and after the startup animation ends, waiting for a certain amount of time before the preview image is displayed. In other words, before optimizing the camera application startup speed, successfully starting the camera application takes a long time. However, by using the camera application startup method provided in this application embodiment, the startup speed of the camera application can be optimized. For a detailed comparison of the situation before and after optimization, please refer to the description of Figure 3 below; for a detailed description of the optimized startup effect, please refer to the description of Figures 4A-4B and 5A-5B below; and for a detailed description of the startup method, please refer to the description of Figure 6 below. These details will not be elaborated upon here.

[0074] Figure 3 illustrates a comparison of camera application startup before and after optimization.

[0075] Figure 3 shows the system resource usage and startup time of the camera application before and after optimization.

[0076] (1) Before optimization, the threads involved in launching the camera application include, but are not limited to: the preview thread, the UI thread, and other threads. For a detailed introduction to these three types of threads, please refer to the conceptual introduction above, which will not be repeated here.

[0077] During camera startup (including cold or warm starts), the aforementioned threads may experience resource contention. Specifically, taking the system resource as the primary core of an electronic device as an example, the preview thread, UI thread, and other threads may be allocated to execute on the primary core. Multiple threads allocated to the primary core can utilize it in a time-sharing manner. For example, during the startup period, the total utilization rate of the primary core by the preview thread is x, the total utilization rate of the primary core by the UI thread is y, and the total utilization rate of the primary core by other threads is z.

[0078] Based on the foregoing analysis, the camera application is considered successfully launched only when the aforementioned threads execute successfully—that is, when the electronic device successfully displays the startup animation and outputs the first preview frame. Therefore, under the resource contention among these threads, the preview thread has a lower utilization rate of the first core, and the allocation of bandwidth and acquisition of the preview image take longer, resulting in a longer startup time for the camera application, for example, 711 milliseconds (ms).

[0079] (2) After optimization, the threads involved in launching the camera application include, but are not limited to: preview thread, UI thread and other threads. For a detailed introduction to these three types of threads, please refer to the concept introduction above. They will not be repeated here.

[0080] During camera startup (including cold or warm start), the frame rate of layer composition in the preview thread can be reduced, so that the system resources used by the preview thread are appropriately tilted towards the preview thread and other threads. For example, during the startup period, the total utilization of the UI thread on the first core is reduced from y to yab, and correspondingly, the total utilization of the preview thread on the first core is increased from x to x+a, and the total utilization of other threads on the first core is increased from z to z+b.

[0081] Based on the foregoing analysis, although the frame rate of layer compositing executed in the UI thread is reduced, the startup animation is still displayed, providing a smooth visual experience (see the descriptions of Figures 4A-4B and 5A-5B below). Furthermore, some system resources released in the UI thread can be used by the preview thread, thereby accelerating the stream configuration and preview image acquisition performed by the preview thread, achieving the goal of quickly launching the camera application, for example, reducing the time for the camera application to successfully launch to 668ms.

[0082] Next, we will introduce in detail the operation interface of the camera application after optimizing the camera application startup speed, with reference to Figures 4A and 4B.

[0083] Figure 4A illustrates the cold start phase 1 of the camera application. Phase 1 includes: receiving an operation to launch the camera application, and in response to the operation, starting the camera application. Since no process for the camera application was running in the background of the electronic device before this launch, this launch can be understood as a cold start. The cold start includes starting streaming and playing a cold start animation. This cold start animation includes: refreshing the current user interface, i.e., adding a window for the camera application to the current user interface, and continuously playing a window that gradually enlarges. Furthermore, in response to the operation to launch the camera application, the electronic device's composite frame rate is reduced, thereby reducing the system resource usage of the composite launch animation layer, allowing streaming to consume more system resources. Typically, before playing the cold start animation, the electronic device also needs to draw and render the interface elements of the cold start animation, as well as the layers corresponding to the composite cold start animation.

[0084] For example, upon receiving an operation applied to the camera application icon 411 in user interface 41, in response to this operation, the task of launching the camera is initiated, and a cold start animation effect is output. This cold start animation effect includes refreshing from user interface 41 to user interface 42. User interface 41 is the desktop of the electronic device, and user interface 42 is also the desktop of the electronic device, the difference being that user interface 42 includes a window 421 provided by the camera application, which can be a black-and-white image window. User interface 41 can also be referred to as the first interface, and the operation applied to the camera application icon 411 in user interface 41 at the first point in time can also be referred to as the first operation.

[0085] Figure 4B illustrates the cold start phase 2 of the camera application, which includes: successfully launching the camera application and displaying a preview interface containing the preview image. Specifically, because the composite frame rate of the electronic device is reduced during the camera application launch process, the resource consumption of the composite launch animation involved in launching the camera application is reduced. Therefore, the streaming involved in launching the camera application can occupy more electronic device resources, thereby accelerating the completion of streaming, acquiring the preview image, and promptly displaying the preview image in the refreshed preview interface.

[0086] For example, refreshing from display user interface 42 to display user interface 43, and refreshing from display user interface 43 to display user interface 44, etc. User interface 43 includes a window 431 provided by the camera application, and the area of ​​window 431 is larger than the aforementioned window 421. User interface 44 is the preview interface, which includes a preview window 441. At this time, since the camera application has already acquired a preview image, the preview image is displayed in the preview window 441. User interface 44 can also be referred to as a second interface.

[0087] The foregoing examples, using Figures 4A and 4B as illustrations, describe an operational interface for a cold-start camera application and should not constitute a limitation of this application. For instance, the methods for triggering a cold start of the camera application are not limited to operations on the camera application icon 411; they can also include calling the camera application through other applications, or through voice commands, gestures, etc. Furthermore, the animation output during the cold start process is not limited to gradually enlarging a black window until a preview interface is displayed; it can include more or fewer display effects. For example, the gradually enlarging window can be a different color not shown in Figure 4A, or it can be a window with transparency, blur, etc. This application embodiment does not specifically limit the display form of the window color, transparency, shape, position, etc., in the startup animation. In addition, while outputting the gradually enlarging window, a mask can be added on top of the underlying interface content to ensure that the user can focus on the key user interaction task, namely, the camera startup animation.

[0088] The cold start stages 1 to 2 shown in Figures 4A and 4B are merely examples to illustrate the images played at different points in time during the cold start animation playback process. These two stages are used as examples and do not have any practical limiting significance. The number of stages should not constitute a limitation on this application.

[0089] Next, we will introduce in detail, with reference to Figures 5A and 5B, the operation interface of the camera application after optimizing the camera application startup speed.

[0090] Figure 5A illustrates the camera application warm start phase 1, which includes receiving an operation to start the camera application.

[0091] For example, upon receiving a swipe-up action at the bottom of user interface 51, user interface 52, also known as a multitasking interface, is output in response to this action. This user interface 52 includes cards corresponding to multiple background applications, such as card 521 corresponding to the camera application. Upon receiving an action on card 521, the camera application is warm-launched and a warm-launch animation is output in response to this action. Furthermore, in response to the action used to warm-launch the camera application, the composite frame rate of the electronic device is reduced, thereby reducing the system resource usage of the composite launch animation layer, allowing the streaming to consume more system resources.

[0092] The content displayed on card 521 includes the content displayed when the camera application last exited from the foreground to the background. Taking the user interface shown in Figure 1C as an example, if the electronic device detects a "return to desktop" operation on user interface 16, the camera application exits from the foreground to the background. Therefore, the content displayed on card 521 includes the preview image displayed in the preview window 161. Optionally, the content displayed on card 521 may have a certain blur effect, or it may have a certain transparency effect, or it may be a black image, etc. This application embodiment does not specifically limit the display form of the content on card 521. User interface 52 may also be called a first interface, and the operation on card 521 on user interface 52 at a first time point may also be called a first operation.

[0093] Figure 5B illustrates the camera application warm-start phase 2, which includes: in response to the aforementioned operation for launching the camera application, starting the camera application. Since the camera application process was running in the background on the electronic device prior to this launch, this launch can be understood as a warm-start. The warm-start includes starting streaming and playing the warm-start animation. This animation includes: continuously refreshing the user interface; as the user interface refreshes, the windows of the camera application contained in each user interface gradually enlarge until a full-screen preview interface is displayed. After displaying the preview interface, if the camera application has not acquired a preview image, a non-preview image is displayed in the refreshed preview window until the camera application acquires a preview image, at which point the real-time preview image is displayed in the refreshed preview window. Because the electronic device's composite frame rate is reduced during this camera application launch process, thereby reducing the resource consumption of the composite launch animation involved in launching the camera application, the streaming involved in this launch can consume more electronic device resources, thus accelerating the completion of streaming, acquiring the preview image, and timely displaying the preview image in the refreshed preview interface.

[0094] For example, the user interface refreshes from display user interface 52 to display user interface 53, and then refreshes from display user interface 53 to display user interface 54. User interface 53 includes a window 531 provided by the camera application, which contains the content of the aforementioned card 521. User interface 54 is the preview interface, which includes a preview window 541. Since the camera application has already acquired a preview image, the preview window 541 displays the currently acquired preview image. User interface 54 can also be referred to as a second interface.

[0095] The foregoing examples, using Figures 5A and 5B as illustrations, describe an operational interface for a camera application that can be warmed up, and should not be construed as limiting this application. For instance, the methods for triggering a warm-up of the camera application are not limited to operations on card 521 in the multitasking interface; they can also include operations on the camera application icon, the camera application capsule, invoking the camera application through other applications, voice commands, and gesture operations. Furthermore, the animation effects output during the warm-up process are not limited to gradually enlarging the interface content from the previous exit until a preview interface is displayed; they can also include more or fewer display effects. For example, while outputting a gradually enlarging window, a mask might be added above the underlying interface content to ensure that the user focuses on the key user interaction task, i.e., the camera startup animation.

[0096] The warm-start stages 1 to 2 shown in Figures 5A and 5B are merely examples to illustrate the images played at different points in time during the warm-start animation playback process. These two stages are used as examples and do not have any practical limiting significance. The number of stages should not constitute a limitation on this application.

[0097] By comparing and analyzing the operation interface of the camera application before and after optimization (cold / warm startup) as described above, it can be found that the optimized camera application (cold / warm startup) has the following effects:

[0098] (1) Improved camera application startup speed. Specifically, before optimization, the camera application startup time was relatively long. For example, after the startup animation finished playing, there was still a certain amount of time before the preview image was output. After optimization, the camera application startup time was significantly shortened. For example, the preview image could be output quickly after the startup animation finished playing. This is because, after starting the camera and before completing the streaming, by reducing the composition frame rate of the electronic device, the system resource occupation of the layer corresponding to the composition startup animation is reduced. The freed system resources can be used for streaming, accelerating streaming and the acquisition of preview images, thereby quickly completing the camera application startup.

[0099] (2) Continue to provide smooth transition startup animations. Specifically, although the frame rate of layer composition is reduced after reducing the frame rate of layer composition, it is still possible to use a lower frame rate to compose layers without affecting the user's visual experience. This allows the output of smooth transition cold start animations during the interface refresh process. For example, a smooth output of a cold start animation from window 421 to window 431 and then from window 431 to the preview interface, or a smooth output of a hot start animation from card 521 to window 531 and then from window 531 to the preview interface.

[0100] Next, referring to Figure 6, we will introduce in detail the method for launching the camera application provided in this application.

[0101] As shown in Figure 6, this method involves modules such as the Camera App in the Application (APP) layer, the Camera server, Advanced Graphics Platform (AGP), and Surface Flinger (SF) in the Framework layer, and the Camera HAL in the Hardware Abstraction Layer (HAL). For detailed information on the functions of these modules, please refer to the detailed description of the software architecture of the electronic device shown in Figure 8 later in this document; it will not be elaborated upon here.

[0102] Referring again to Figure 6, the method may specifically include the following steps:

[0103] S101, the Camera APP received the command to start the camera.

[0104] Specifically, after the electronic device receives an operation to trigger the launch of the Camera App, the Camera App can receive an instruction to start the camera.

[0105] The methods for triggering the launch of the camera application on an electronic device include, but are not limited to, the cold start method shown in Figure 4A and the warm start method shown in Figure 4B. In addition, the methods for triggering the launch of the camera application on an electronic device may also include any of the following: gesture operation, voice command, invocation through other applications, etc., and this application embodiment does not impose any limitations on these methods.

[0106] S102, the Camera App calls the SF composite layer and sends the Surface to SF.

[0107] Specifically, after receiving the command to launch the camera, the Camera app begins executing the task of outputting the launch animation. This task includes: the Camera app calling the SF composite layer and sending the Surface to SF.

[0108] Here, Surface refers to graphics buffer data, which typically contains user interface elements of the camera application, such as text, images, and controls. Surface can be carried in the notification of the composite layer or sent separately; this embodiment does not impose any limitations on this. Since the camera application's user interface is updated in real time, the camera application can continuously send Surface to SF via buffer rotation. The Surface sent by the Camera App to SF includes elements in each frame corresponding to the camera application's startup animation. Optionally, Surface may specifically include elements corresponding to the cold start animation as shown in Figures 4A-4B above, or elements corresponding to the warm start animation as shown in Figures 5A-5B above.

[0109] S103, SF uses the first frame rate to composite the Surface into a layer, and sends the composited layer to the display driver to start displaying the switching animation.

[0110] Specifically, after receiving the notification from the Camera App and the Surface, the SF can use the first frame rate to composite the Surface into a layer. The SF can also pass the composited layer to the display driver via the Hardware Composer (HWC), and the display driver then sends the composited layer to the display screen for displaying the camera application's interface. The display screen can be a component within an electronic device or a device independent of the electronic device; this embodiment does not impose any limitations on this. Optionally, the interface displayed on the display screen based on the SF-composite layer includes a progressively enlarging window 421 as shown in Figure 4A above, or a progressively enlarging card 521 as shown in Figure 5A above.

[0111] The first frame rate is the frame rate used by the electronic device by default or the frame rate set by the camera application by default, such as 90 frames per second (FPS) or 120 FPS.

[0112] In this context, "layer" refers to an interface that can be displayed on a screen based on Surface composition. This interface is composed of a series of elements, controls, etc., displayed in a specific area.

[0113] Optionally, the aforementioned S102-S103 can be understood as a stage in the camera application startup process (which may be called stage 1). Stage 1 mainly executes the output startup animation. In this embodiment, stage 1 is a stage defined artificially for ease of understanding and does not imply any limitation.

[0114] The method for launching a camera application provided in this application includes S201-S206 after S103.

[0115] S201, Camera APP calls Camera server to start camera.

[0116] Specifically, after the Camera App receives the instruction to start the camera, it can call a function to start the camera (such as Open camera) to start the camera. Optionally, it can call the Camera manager in the Camera server to start the camera through Open camera. In the embodiments of this application, starting the camera can also be understood as opening the camera, turning on the camera, and enabling the camera, etc. The embodiments of this application do not specifically limit the name, and the corresponding implementation methods have been described in the embodiments of this application.

[0117] The notification to launch the camera can include information such as the Camera ID. When an electronic device has multiple cameras, the Camera ID can be used to indicate which camera is to be activated. Typically, the camera that is initially activated when the camera application is launched is the primary camera, so the Camera ID can specifically be the identifier of the primary camera.

[0118] S202, the Camera server sends the camera start event to AGP via the power-saving wizard.

[0119] Specifically, the Power Saving Wizard can pre-mark points in the Camera device imp in the Camera server using stub functions (such as POWERPUSH). This allows the Camera server to send a camera start event to the Power Saving Wizard when the camera is called and started. Optionally, the Camera server can send the camera start event to the Power Saving Wizard after the Camera APP calls the function to start the camera and before the streaming is completed. Then, the Power Saving Wizard notifies the AGP of the camera start event via binder communication.

[0120] Optionally, the power-saving tool can also obtain camera startup events using methods other than stub functions. For example, it can register a camera startup event detection service in the Camera server. After successful registration, the Camera server will notify the power-saving tool when it detects a camera startup. In this embodiment, the power-saving tool can be an application, component, service, etc., in the application layer of the electronic device.

[0121] S203, the power-saving wizard sends scene information to AGP.

[0122] Specifically, after the power-saving wizard (which can also be called the second module) receives the aforementioned camera start event, it can send the scene information to AGP via binder communication.

[0123] The scene information includes, but is not limited to, the current frame rate and the foreground package name. The current frame rate (e.g., the first frame rate) refers to the composite frame rate of the layer corresponding to the currently output user interface, which can be the frame rate of the composite layer of SurfaceFlinger. The foreground package name refers to the package name of the application running in the foreground. When a user can directly interact with the application providing the interface through the interface displayed on the electronic device, the application providing the interface is considered to be the application running in the foreground.

[0124] In this application embodiment, the number of foreground package names can vary in different scenarios. These scenarios include, but are not limited to, split-screen scenarios, picture-in-picture scenarios, and full-screen scenarios. Specifically, in a split-screen scenario, the number of foreground package names is usually greater than or equal to the number of split screens, i.e., at least greater than 1; in a picture-in-picture scenario, the number of foreground package names is also at least greater than 1; and in a full-screen scenario, the number of foreground package names is 1. The full-screen scenario referred to in this application includes displaying one foreground running interface across the entire area of ​​the electronic device screen, or displaying one foreground application interface in the non-status bar and navigation bar area of ​​the electronic device screen.

[0125] In this application embodiment, the synthesized frame rate may vary under different scenarios, including but not limited to: interactive scenarios, non-interactive scenarios, special application scenarios, and non-special application scenarios. Interactive scenarios have higher refresh rates and correspondingly higher synthesized frame rates, such as 90FPS or 120FPS. Non-interactive scenarios have lower refresh rates and correspondingly lower synthesized frame rates, such as 60FPS or 30FPS. Special application scenarios have higher synthesized frame rates; for example, games have higher synthesized frame rates, such as 90FPS or 120FPS, while reading applications have lower synthesized frame rates, such as 60FPS or 30FPS. The aforementioned interactive and non-interactive scenarios are relative concepts. Interactive scenarios refer to scenarios where the user interacts frequently with the application interface through visual, physical, and gestural interactions. Conversely, non-interactive scenarios refer to scenarios where the user interacts with the application interface with little or no visual, physical, or gestural interactions. The aforementioned special and non-special applications are also relative concepts; different electronic devices can preset corresponding synthesized frame rates for various applications, and this application embodiment does not impose specific limitations on this.

[0126] S204, AGP determines the synthesized frame rate based on scene information.

[0127] Specifically, after receiving the aforementioned camera activation event, AGP (which can also be referred to as the first module) can determine the frame rate of the composite layer based on the received scene information. This determination method includes:

[0128] (1) Determine whether the current frame rate in the scene information is less than or equal to the preset frame rate (e.g., 60 FPS, i.e., the first threshold). If the current frame rate is less than or equal to 60 FPS, end the process of reducing the composite frame rate corresponding to launching the camera application, which is equivalent to continuing to use the aforementioned current frame rate to synthesize the layer. If the current frame rate is greater than 60 FPS, continue to determine whether the number of foreground package names is greater than 1. Here, a scene with a current frame rate less than or equal to 60 FPS usually refers to a non-interactive scene, and a scene with a current frame rate greater than 60 FPS usually refers to an interactive scene. Optionally, for a period of time after the electronic device receives the operation to launch the camera application, the electronic device is in an interactive scene. In this interactive scene, the frame rate of the electronic device usually increases to greater than 60 FPS. Based on the composite frame rate of greater than 60 FPS, the electronic device can further determine whether to reduce the composite frame rate based on the number of foreground applications.

[0129] (2) If the number of foreground package names is greater than 1 (also known as the second threshold), the process of optimizing the composite frame rate corresponding to the camera application is terminated, which is equivalent to continuing to use the current frame rate to synthesize the layer; if the number of foreground package names is not greater than 1, the reduced new frame rate (also known as the second frame rate) is used for layer synthesis, which can be, for example, 60 FPS. Among them, the scenarios where the number of foreground package names is greater than 1 usually include split-screen scenarios and picture-in-picture scenarios, and the scenarios where the number of foreground package names is equal to 1 usually include full-screen scenarios. Optionally, when the electronic device is running only the camera application in the foreground, the electronic device is in a full-screen scenario. In this full-screen scenario, if the electronic device is in the process of launching the camera application due to receiving a launch operation, the electronic device is also in an interactive scenario at the same time. Therefore, the frame rate of the electronic device is usually increased to greater than 60 FPS. Based on the composite frame rate of greater than 60 FPS and the number of foreground package names of 1, the electronic device can determine to reduce the composite frame rate to 60 FPS. If the electronic device is in a split-screen or picture-in-picture scenario, the frame rate of the electronic device usually needs to be determined by multiple foreground applications. This application embodiment does not limit this.

[0130] Optionally, in addition to determining the composite frame rate based on both the current composite frame rate and the number of foreground packet names, as mentioned above, AGP can also determine the composite frame rate solely based on the current composite frame rate, or solely based on the number of foreground packet names. For example, determining the composite frame rate based on the current composite frame rate includes: if the current composite frame rate is less than or equal to 60 FPS, then the process of reducing the composite frame rate corresponding to the camera application launch is terminated, equivalent to continuing to use the aforementioned current composite frame rate to composite the layer; if it is determined that the current composite frame rate is greater than 60 FPS, then the composite frame rate is set to 60 FPS. Similarly, determining the composite frame rate based on the number of foreground packet names includes: if the number of current foreground packet names is greater than 1, then the process of reducing the composite frame rate corresponding to the camera application launch is terminated, equivalent to continuing to use the aforementioned current composite frame rate to composite the layer; if it is determined that the number of current foreground packet names is not greater than 1, then the composite frame rate is set to 60 FPS.

[0131] S205, AGP sends the second frame rate to SF.

[0132] Specifically, once AGP determines to use the second frame rate in S204, it sends the second frame rate to SF via binder communication, so that SF uses the second frame rate for layer composition.

[0133] S206, SF uses the second frame rate to composite the Surface into a layer, and sends the composited layer to the display driver to continue displaying the switching animation.

[0134] Specifically, the SF continuously acquires the latest Surface provided by the camera application. Therefore, after receiving a notification to adopt the second frame rate, the SF can use the second frame rate to composite the Surface into a layer. The SF can also pass the composited layer to the display driver via the Hardware Composer (HWC). The display driver then sends the composited layer to the display screen for it to continue displaying the camera application's interface, such as continuing to display the camera application's startup animation. The display screen can be a component within an electronic device or a device independent of the electronic device; this embodiment does not impose any limitations on this. Optionally, the display screen can display a cold start animation as shown in Figure 4B, or a warm start animation as shown in Figure 5B, based on the composited layer. Optionally, the aforementioned S201-S206 can be understood as another stage in the camera application startup process (which can be called stage 2). This stage 3 mainly performs the reduction of the composite frame rate. In this embodiment, stage 2 is a defined execution stage for ease of understanding and does not imply any limitation.

[0135] Figure 6 illustrates an example where stage 1 is executed first, followed by stage 2. In this implementation, the original frame rate (i.e., the aforementioned first frame rate) can be used to synthesize the layer corresponding to the startup animation. If a frame rate reduction is determined during startup animation synthesis, the reduced frame rate (i.e., the aforementioned second frame rate) is used to synthesize the layer corresponding to the startup animation. This ensures timely synthesis of the layer corresponding to the startup animation in scenarios where a frame rate reduction is not required, without waiting for a frame rate reduction determination before starting the synthesis. In another optional implementation, stage 2 can be executed first, followed by stage 1. That is, after the application receives the startup command, the electronic device can first perform the task of reducing the layer synthesis frame rate. After determining the reduction frame rate, the reduced second frame rate is used to start layer synthesis. This avoids using the first frame rate first and then the second frame rate for layer synthesis, achieving timely frame rate reduction and resource release.

[0136] In the camera application startup method provided in this application, after S206, it also includes S301-S310. In S301, the Camera server calls the Camera HAL to create a preview stream.

[0137] Specifically, the Camera HAL includes a Camera Device Client, which allows the Camera server to create preview streams and configure data streams. Creating preview streams, often simply called stream creation, refers to creating a data stream used to acquire preview images.

[0138] S302, the Camera server calls Camera HAL to configure the data stream.

[0139] Specifically, configuration data streams can be abbreviated as Configurestreams, or also referred to as configuration preview streams, configuration image streams, etc. Configurestreams refer to configuring the data stream used to acquire preview images. Specifically, this involves the camera server configuring the preview image stream corresponding to the parameters set in the camera application to the camera via CameraHal. These parameters include, but are not limited to, one or more of the following: the frame rate of the camera application, the resolution of the preview image, or the zoom level.

[0140] S303, Camera HAL returns a message to Camera server indicating successful stream allocation.

[0141] S304, Camera server calls Camera hal to create a capture session.

[0142] Specifically, the Camera HAL contains a Camera Capture Session, which provides control over the camera's image capture behavior. After the Camera server creates a capture session with the Camera HAL, the Camera Capture Session can support interaction with the camera using the following methods:

[0143] The `setRepeatingRequest()` method is used to repeatedly request image data, typically in scenarios requiring continuous image acquisition, such as previewing or burst shooting. Repeatedly requesting image data means that the Camera HAL will continuously request image capture from the camera multiple times according to the set parameters. The camera will continuously capture images and transmit the continuously captured multi-frame image data (i.e., the preview stream) to the application for processing via callbacks. During this process, the Camera HAL does not stop after requesting from the camera only once, but continues to request image capture according to the settings of the `setRepeatingRequest()` method. For example, when allocating streaming, the Camera server sends the camera application's frame rate to the Camera HAL. For instance, if the camera application's frame rate is 30 FPS, the Camera HAL will also set the display frame rate to 30 FPS when it calls `setRepeatingRequest()`. Based on a single `RepeatingRequest()` request, the camera driver can control the camera to capture one frame and return it to the Camera HAL. The Camera HAL then transmits this frame to the camera application via the Camera server, and the electronic device displays this frame. When the camera application's frame rate is 30 FPS, the Camera HAL sends 30 `RepeatingRequest()` calls per second based on this 30 FPS frame rate, and the camera driver returns 30 frames per second to the upper layer. Optionally, the camera application's frame rate is the same as the frame rate at which the camera captures images.

[0144] The capture() method is used to capture an image in a single shot, and is suitable for scenarios such as taking a photo where an image is captured in one go.

[0145] S305, Camera HAL returns the configured information to Camera server via a callback.

[0146] S306, the Camera server sends a capture request to the Camera HAL.

[0147] Specifically, after successful stream allocation and capture session creation, the Camera server can send a request to the Camera HAL to capture preview images. This request can instruct the Camera HAL to continuously request preview images from the camera. Optionally, this continuous preview image capture request can be implemented using the setRepeatingRequest() method described earlier.

[0148] S307, Camera hal returns a preview image to Camera server.

[0149] Specifically, after receiving a capture request, Camera HAL controls the corresponding camera to continuously capture preview images through the corresponding camera driver, and then returns the continuously captured multi-frame preview images to the Camera server in the form of a data stream (referred to as a preview stream).

[0150] S308, the Camera server returns a preview image to the Camera app.

[0151] After receiving the returned preview image, the Camera app can draw and render based on the preview image to obtain the corresponding Surface. The drawn and rendered Surface is then written to a buffer for SF to read from the buffer for layer compositing. Optionally, the camera app can also draw and render based on the preview image and other interface elements to obtain the corresponding Surface, and then write the drawn and rendered Surface to a buffer for SF to read from the buffer for layer compositing.

[0152] S309, SF acquires preview image.

[0153] Specifically, SF can read the Surface corresponding to the preview image written by the camera application from the aforementioned buffer, so that layers can be composited based on that Surface later.

[0154] S310, SF uses the second frame rate to composite the Surface into a layer, and sends the composited layer to the display driver to display the preview interface.

[0155] Specifically, SF composites a layer based on the Surface corresponding to the preview image read from the buffer. Optionally, SF can also read other interface elements provided by the camera application from the aforementioned buffer, and then composite the layer together with the surface corresponding to the preview image. SF can also pass the composited layer to the display driver via HWC, and the display driver will then send the composited layer to the display screen for further display of the camera application's interface, such as displaying the camera application's preview interface. Optionally, this preview interface can be the preview interface including preview window 441 as shown in Figure 4B, or the preview interface including preview window 541 as shown in Figure 5B.

[0156] Optionally, besides maintaining the second frame rate to continue compositing the Surface and preview stream into a layer, SF can also use other frame rates to continue compositing the Surface and preview stream into a layer. For example, reverting to the first frame rate ensures timely refresh of the preview image, improving the user's camera experience. Alternatively, further reducing the frame rate from the second to the fourth frame rate can save power consumption and increase battery life; therefore, this application does not limit this approach.

[0157] In S206-S310, the electronic device can quickly output a preview image after the startup animation finishes playing, that is, quickly complete the camera startup. This is because after executing S206, the composite frame rate of the electronic device can be controlled to be reduced, which reduces the system resources occupied by the composite startup animation. The freed system resources can be used for distribution and acquisition of the preview stream, so the preview image can be quickly output, that is, quickly complete the camera startup.

[0158] Optionally, the aforementioned S302-S310 can be understood as another stage in the camera application startup process (which can be called stage 3). Stage 3 mainly performs tasks such as stream allocation and obtaining preview streams. In this application embodiment, stage 3 is an execution stage defined artificially for ease of understanding and does not imply any limitation.

[0159] Figure 6 illustrates an example where stage 1 is executed first, followed by stage 3. This application does not restrict the order in which stage 1 and stage 3 are executed. Specifically, since stage 1 and stage 3 are two independent tasks, they are executed through different threads. Therefore, the order in which stage 1 and stage 3 are executed can also be implemented in other ways. For example, stage 1 and stage 3 can be executed simultaneously after the camera application receives the start command, or stage 3 can be executed first, followed by stage 1.

[0160] Figure 6 illustrates an example where stage 2 is executed first, followed by stage 3. This application does not restrict the order in which stages 2 and 3 are executed. Specifically, since stages 2 and 3 are two independent tasks, they are executed through different threads. Therefore, the order in which stages 2 and 3 are executed can also be implemented in other ways. For example, stages 2 and 3 can be executed simultaneously after the camera application receives the start command, or stage 3 can be executed first, followed by stage 2. Specifically, the execution order of the SF layer using the reduced second frame rate described in S206 of stage 2 can be before or after the stream creation described in S301 of stage 3, but the execution order of S206 must be earlier than the successful stream allocation described in S303 of stage 3. This is because the electronic device takes a relatively long time to create and allocate the stream, and during this process, the electronic device has already reduced the composite frame rate.

[0161] The method for launching a camera application provided in this application includes S401-S403 after S310.

[0162] S401, the power-saving wizard detects a switch in the foreground application and determines the composite frame rate corresponding to the current foreground application.

[0163] Specifically, the power-saving tool can pre-program the Activity Manager service (AMS) so that AMS can promptly notify the power-saving tool when it detects a switch between foreground and background applications. Once the power-saving tool is aware of the foreground application switch, it can determine the corresponding composite frame rate based on the current foreground application. Optionally, foreground application switching includes scenarios such as exiting the camera application or adding another foreground application. For example, after receiving a second operation, a first application other than the camera application is launched, and the camera application's interface is switched from full-screen to split-screen, picture-in-picture, or other display methods to show both the camera application's interface and the first application's interface.

[0164] Optionally, the power-saving wizard can also obtain foreground application switching events in ways other than stub functions. For example, by registering a foreground application switching event detection service in AMS, AMS will notify the power-saving wizard when it detects a foreground application switch after successful registration.

[0165] S402, the power-saving wizard sends the third frame rate to SF via AGP.

[0166] S403, SF uses the third frame rate to synthesize the layer and sends the synthesized layer to the display driver to display the corresponding user interface.

[0167] Specifically, at this time, SF will continuously receive the Surface provided by the current foreground application (such as the desktop or other applications). Therefore, after SF receives the notification to use the third frame rate, it can use the third frame rate to continue to composite the Surface provided by the current foreground application into a layer. SF can also pass the composited layer to the display driver through HWC. The display driver then sends the composited layer to the display screen for displaying the interface of the current foreground application.

[0168] The third frame rate can be the same as or different from the first frame rate. Both the third and first frame rates depend on the context of the electronic device. If the application currently running in the foreground is the same as the application running before the camera app was launched, then the third frame rate and the first frame rate are the same. If the application currently running in the foreground is different from the application running before the camera app was launched, then the third frame rate and the first frame rate may be different. Optionally, taking the desktop as an example, the third frame rate can be the same as the first frame rate, such as 90Hz or 120Hz. Taking a reading application as an example, the third frame rate can be different from the first frame rate, such as 60Hz or 30Hz.

[0169] It is understandable that the layer compositing steps using SF, as shown in Figure 6, span stages 1, 2, and 3. That is, layer compositing is involved in all processes, including outputting startup animations, reducing frame rate, stream allocation, and acquiring preview streams. Therefore, reducing the frame rate of layer compositing can effectively free up system resources for executing other critical tasks related to camera startup, thereby accelerating camera startup. Furthermore, to ensure that the freed resources are used for critical tasks involved in camera startup, the following measures can be taken: when the background load is heavy, a memory watershed will be triggered, and a rapid kill technique can be activated to clean up background tasks, ensuring that the freed resources are used to centrally process camera startup-related tasks; when the background load is light, the camera application starts, and the system can rapidly freeze background tasks, ensuring that the freed resources are used to process high-priority critical tasks such as camera stream allocation.

[0170] Based on the preceding introduction to the camera application launch method provided in this application, the form and hardware / software architecture of the electronic device involved in this method will be described next.

[0171] Electronic devices can be equipped with Or other portable terminal devices with different operating systems, such as mobile phones, tablets, desktop computers, laptops, handheld computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices and / or smart city devices, etc.

[0172] Figure 7 shows a schematic diagram of the structure of the electronic device 100.

[0173] Electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, sensor module 180, camera 193, and display screen 194, etc. The sensor module 180 may include pressure sensor 180A and touch sensor 180K, etc.

[0174] It is understood that the structures illustrated in the embodiments of this application 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.

[0175] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0176] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

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

[0178] In this embodiment, the processor 110 is used in conjunction with the camera 193, the display screen 194, the touch sensor 180K, etc., to jointly implement the camera application launch method provided in this application. For the specific implementation of this method, please refer to the previous description of Figure 6, which will not be repeated here.

[0179] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include a Universal Serial Bus (USB) interface, etc. The USB interface 130 is an interface compliant with the USB standard specification, specifically a Mini USB interface, a Micro USB interface, a USB Type-C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used for data transfer between the electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0180] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0181] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0182] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the electronic device 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0183] In this embodiment of the application, the electronic device 100 may store in the aforementioned memory an implementation program for the application startup method, a preset frame rate, and information such as the frame rate corresponding to each scene.

[0184] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0185] In this embodiment, the pressure sensor 180A can be used to detect various clicks, swipes, and other operations involved in Figures 4A and 5A.

[0186] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch screen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0187] In this embodiment, the touch sensor 180K is used to detect various clicks, swipes, and other operations involved in Figures 4A and 5A.

[0188] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0189] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye. The ISP can also perform algorithmic optimization on image noise and brightness. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0190] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0191] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0192] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

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

[0194] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD). The display panel can also be manufactured using organic light-emitting diodes (OLEDs), active-matrix organic light-emitting diodes (AMOLEDs), flexible light-emitting diodes (FLEDs), miniled, microLEDs, micro-OLEDs, quantum dot light-emitting diodes (QLEDs), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0195] In this embodiment of the application, the electronic device can control the display screen 194 to output corresponding feedback information based on the detected operation. Specifically, it can output user interfaces as shown in Figures 4A-4B and 5A-5B as described above.

[0196] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture. Taking the system as an example, the software structure of electronic device 100 is illustrated.

[0197] Figure 8 is a software structure block diagram of an electronic device 100 according to an embodiment of this application.

[0198] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, [the following is omitted as the text is incomplete and likely refers to a specific implementation or feature]. The system is divided into four layers, from top to bottom: application layer, application framework layer, hardware abstraction layer (HAL), and driver layer.

[0199] The application layer can include a series of application packages.

[0200] As shown in Figure 8, the application package may include a camera, gallery, or applications not shown in Figure 8 such as calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0201] The application framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The application framework layer includes a set of predefined functions.

[0202] As shown in Figure 8, the application framework layer may include a camera server, an advanced graphics platform (AGP), a surface flinger (SF), and a power-saving feature, etc. Alternatively, it may include an activity manager service (AMS) and a view system, not shown in Figure 8.

[0203] The Camera server is responsible for optimizing performance during camera startup, ensuring that the camera application can respond quickly to user requests. In addition to performance optimization and resource management, the Camera server also ensures the correct execution and efficient operation of camera functions. Through close collaboration with other system components, the Camera Server enables the camera application to smoothly complete image capture and processing tasks.

[0204] Surface Components (SF) are primarily responsible for compositing and displaying screen content. Specifically, SF can use OpenGL and Hardware Composer to composite a set of Surfaces into layers to generate the final screen image. These Surfaces can be provided by one or more application and system UI elements.

[0205] AGP and the power-saving utility can work together to provide services such as accelerating camera startup. For example, as described earlier in this application, the power-saving utility can use a stubbing function to stubbing the camera device imp in, for example, the camera server, so that it can promptly notify the power-saving utility after detecting a camera startup event. The power-saving utility can also obtain scene data such as the current foreground application package name and the corresponding frame rate, and then determine whether to reduce the frame rate based on the scene data, or notify AGP to determine whether to reduce the frame rate based on the scene data after the camera startup event occurs.

[0206] AMS is responsible for managing the lifecycle of Activities in the application, including creation, startup, pause, resumption, and destruction, as well as events such as foreground / background switching.

[0207] The view system includes visual controls, such as controls for displaying text and controls for displaying images. The view system can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0208] The Hardware Abstraction Layer (HAL) is an interface layer located between the application framework layer and the driver layer, providing a virtual hardware platform for the operating system.

[0209] In this embodiment of the application, the hardware abstraction layer may include the camera hardware abstraction layer (CameraHAL) and the camera algorithm library.

[0210] Among them, Camera HAL can provide virtual hardware for camera modules. Camera HAL is mainly used to control the corresponding sensors to collect scene data, such as controlling the image sensor to collect images. It can also transmit the acquired image data, illumination data, etc. to the camera algorithm library.

[0211] The algorithm module includes several algorithms for processing images, which can be used to capture images with the target zoom magnification.

[0212] The driver layer is the layer between hardware and software. It includes drivers for various hardware components.

[0213] In some embodiments, the driver layer may include a camera driver, a digital signal processor driver, an image processor driver, and a display driver, etc.

[0214] Among them, the camera driver is used to drive the corresponding sensor of the camera module to acquire images, the digital signal processor driver is used to drive the digital signal processor to process images, and the image processor driver is used to drive the image signal processor to process images.

[0215] The hardware layer mainly includes components in the camera module, such as image sensor 1, image sensor 2, TOF, multispectral sensor, image signal processor (ISP), digital signal processor, and image processor, etc. Sensor 1 and Sensor 2 refer to the photosensitive elements in the camera. The image processor includes one or more processors besides the ISP, such as a video processing unit (VPU) and a display processing unit (DPU). The ISP can be used to perform post-processing on the signal output from the image sensor to improve image quality. Typically, the ISP's processing includes, but is not limited to, functions such as automatic exposure control (AEC), automatic gain control (AGC), automatic white balance (AWB), color correction, lens shading correction, gamma correction, dead pixel removal, automatic black level, and automatic white level. The image processor can be used in conjunction with the ISP to participate in image processing and optimization. In this embodiment, the image processor and its corresponding corresponding image processor are optional modules. For some software architectures, image processing and optimization can be achieved through the camera algorithm library in HAL without using an image processor.

[0216] The following example, using a scene of capturing a photograph, illustrates the workflow of the software and hardware of the electronic device 100.

[0217] When touch sensor 180K receives a touch operation, a corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, etc.). The raw input event is stored in the kernel layer. The application framework layer retrieves the raw input event from the kernel layer and identifies the control corresponding to the input event. Taking a touch click as an example, where the corresponding control is the camera application icon, the camera application calls the application framework layer's interface to launch the camera application, and then calls the kernel layer to launch the camera driver, capturing still images or videos through camera 193.

[0218] The following example, using user-triggered camera application launch, illustrates the workflow of the software and hardware of electronic device 100. In a possible implementation, the touch sensor 180K of electronic device 100 receives a user's touch click operation, and the corresponding hardware interrupt is sent to the kernel driver layer. The kernel driver layer processes the touch operation into raw input events (including touch coordinates, touch operation timestamps, etc.). The raw input events are stored in the kernel driver layer. The application framework layer obtains the raw input events from the kernel driver layer and identifies the control corresponding to the input event as the camera application icon. The camera application (APP) of electronic device 100 calls the Camera server in the application framework layer, and executes the camera application's launch thread (open thread) through the Camera HAL to obtain camera parameters. After obtaining the camera parameters, the camera application calls the HAL layer's streaming thread to configure the camera application's data stream. Stream configuration includes creating the capture session channel (such as a session handle) corresponding to the camera application. After the camera application's data stream configuration is complete, the camera application of electronic device 100 sends a preview request and a rotation buffer to the camera hardware abstraction layer. The process of sending preview requests and using a rotation buffer is called repeating. The camera hardware abstraction layer of electronic device 100 calls image algorithms from the camera algorithm library to process the scene image output by the sensor, and then writes the processed image to the rotation buffer. The camera application displays the image preview in the rotation buffer on the camera application's user interface (UI). The user can then take photos or record videos of the scene. Taking photos or recording videos represents saving the image displayed on the interface.

[0219] It should be understood that the steps in the above-described method embodiments provided in this application can be implemented by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0220] This application also provides an electronic device that may include a memory and a processor. The memory may be used to store a computer program; the processor may be used to invoke the computer program in the memory to cause the electronic device to perform the method in any of the above embodiments.

[0221] This application also provides a chip system including at least one processor for implementing the functions involved in the methods performed by the electronic device in any of the above embodiments.

[0222] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0223] The chip system can consist of chips or include chips and other discrete components.

[0224] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0225] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

[0226] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0227] This application also provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the method executed by the electronic device in any of the above embodiments.

[0228] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the electronic device in any of the above embodiments.

[0229] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0230] 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 disk).

[0231] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0232] In summary, the above description is merely an embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made according to the disclosure of the present invention should be included within the scope of protection of the present invention.

Claims

1. A camera application starting method, characterized by, The method is applied to an electronic device, and the method comprises: displaying a first interface; starting to launch a camera application in response to a first operation on the first interface at a first time point; at the first time point, a composition frame rate of the electronic device is a first frame rate; after the first time point, the composition frame rate is set to a second frame rate, the second frame rate being less than the first frame rate; after the composition frame rate is set to the second frame rate, streaming the camera application; after streaming the camera application, displaying a second interface, the second interface comprising a preview image.

2. The method of claim 1, wherein, The composition frame rate being set to the second frame rate comprises: based on the first frame rate being greater than a first threshold value, and / or a number of foreground applications of the electronic device being less than or equal to a second threshold value, the composition frame rate being set to the second frame rate.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: based on the composition frame rate of the electronic device being the second frame rate, displaying a launch animation of the camera application.

4. The method of claim 3, wherein, Displaying the launch animation of the camera application comprises: before the composition frame rate is set to the second frame rate, based on the composition frame rate being the first frame rate, displaying the launch animation of the camera application; after the composition frame rate is set to the second frame rate, based on the composition frame rate being the second frame rate, displaying the launch animation of the camera application.

5. The method according to any one of claims 1-4, characterized in that, The electronic device further comprises a camera server, a camera hardware abstraction layer (camera HAL), and a camera, and streaming the camera application comprises: the camera server configuring, through the camera HAL, a preview image stream corresponding to parameters set in the camera application to the camera based on the parameters; the parameters comprising any one or more of a frame rate of the camera application, a resolution of the preview image, or a zoom ratio.

6. The method according to any one of claims 1-5, characterized in that, The electronic device comprises a processor, and the processor comprises a first core; playing the launch animation of the camera application comprises playing the launch animation of the camera application using the first core; streaming the camera application comprises streaming the camera application using the first core.

7. The method according to any one of claims 1 to 6, characterized in that, After displaying the second interface, the method further comprises: setting the composition frame rate to any one or more of the first frame rate, the second frame rate, or a fourth frame rate, the fourth frame rate being lower than the second frame rate.

8. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: starting to launch a first application in response to a second operation on the second interface at a second time point; after the second time point, setting the composition frame rate to a third frame rate, the third frame rate being equal to the first frame rate, or the third frame rate being equal to a frame rate of the first application.

9. The method according to any one of claims 1-8, characterized in that, The electronic device comprises a first module and a surface compositor (SF), and setting the composition frame rate to the second frame rate specifically comprises: the first module determining that the composition frame rate is set to the second frame rate; the first module sending the second frame rate to the SF; the SF setting the composition frame rate to the second frame rate.

10. The method of claim 9, wherein, The first module determining that the composition frame rate is set to the second frame rate specifically comprises: The first module obtains the first frame rate and the number of foreground applications of the electronic device; Based on the first frame rate being greater than a first threshold value, and / or the number of foreground applications of the electronic device being less than or equal to a second threshold value, the synthesized frame rate is set to a second frame rate.

11. The method of claim 10, wherein, The electronic device comprises a second module; the first module obtains the first frame rate and the number of foreground applications of the electronic device, specifically comprising: The second module sends the following scene information to the first module: the first frame rate, the number of foreground applications of the electronic device.

12. The method of claim 11, wherein, The electronic device comprises a camera server, and a stub function is preset in the camera server; before the second module sends the following scene information to the first module, the method further comprises: After the first operation, the second module determines that the camera application starts to start through the stub function.

13. An electronic device, comprising: The electronic device comprises one or more memories, one or more processors, and one or more cameras; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors invoke the computer instructions to enable the electronic device to execute the method according to any one of claims 1-12.

14. A computer-readable storage medium comprising instructions, wherein: When the instructions run on the electronic device, the electronic device executes the method according to any one of claims 1-12.

15. A computer program product comprising computer programs / instructions, characterized in that, When the computer program / instructions run on the electronic device, the electronic device executes the method according to any one of claims 1-12.

Images