Mode switching method and terminal device

Abstract

The application provides a mode switching method and a terminal device, which are beneficial to improving the speed of switching the shooting mode of a camera application. The method comprises the following steps: in response to an operation of opening the camera application, displaying a first interface of the camera application, the first interface being an interface of a photographing mode; in response to an operation of switching the shooting mode to a multi-lens video recording mode at a first time point, displaying a second interface of the camera application at a second time point, the second interface being an interface of the multi-lens video recording mode; there is an overlap between a first time period and a second time period between the first time point and the second time point, the first time period being a time period for closing the photographing mode based on a closing thread, and the second time period being a time period for starting the multi-lens video recording mode based on a starting thread; and in response to an operation of switching the shooting mode to the photographing mode at a third time point, displaying a third interface of the camera application at a fourth time point, the third interface being an interface of the photographing mode.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202310208362.9, filed with the Chinese Patent Office on February 27, 2023, entitled “Mode Switching Method and Terminal Equipment”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminals, and more particularly to a mode switching method and a terminal device. Background Technology

[0003] Currently, most terminal devices' camera apps support multiple shooting modes, such as photo mode, video mode, and portrait mode, allowing users to freely choose shooting modes and experience different shooting effects.

[0004] When users switch shooting modes, the switching speed is slow due to the influence of system resource supply, which affects the user experience. Summary of the Invention

[0005] This application provides a mode switching method and terminal device, which helps to improve the speed of switching shooting modes and enhance the user experience.

[0006] In a first aspect, this application provides a mode switching method, which can be executed by a terminal device. The method includes: in response to an operation of opening a camera application, displaying a first interface of the camera application, the first interface being an interface for a shooting mode; in response to an operation of switching the shooting mode to a multi-lens recording mode at a first time point, displaying a second interface of the camera application at a second time point, the second interface being an interface for the multi-lens recording mode; the first time point and the second time point overlap; the first time point is a time period based on a shutdown thread to disable the shooting mode, and the second time point is a time period based on a startup thread to enable the multi-lens recording mode; in response to an operation of switching the shooting mode to a shooting mode at a third time point, displaying a third interface of the camera application at a fourth time point, the third interface being an interface for the shooting mode; the third time point and the fourth time point do not overlap; the third time point is a time period based on a shutdown thread to disable the multi-lens recording mode, and the fourth time point is a time period based on a startup thread to enable the shooting mode.

[0007] In this application, the close thread is used to close a shooting mode, which may specifically include releasing the camera service resources of that shooting mode. The open thread is used to start a shooting mode.

[0008] It should be understood that after the terminal device is powered on or restarted, the terminal device will create the first close thread, open thread, and configure_streams thread for the camera application, waiting for the camera application to issue instructions to call them.

[0009] Considering that there is no coupling between closing the photo mode based on the close thread and starting the multi-lens recording mode based on the open thread, based on the technical solution of this application, the terminal device can create a second close thread when the camera application calls the close interface. This second close thread can also be called an asynchronous close thread. The terminal device closes the photo mode based on this asynchronous close thread. In other words, the close process of the photo mode is carried out in the asynchronous close thread.

[0010] During the process of closing the photo mode based on the asynchronous close thread, the terminal device can start the multi-lens recording mode based on the open thread. That is, the open thread used to start the multi-lens recording mode does not need to wait for the close thread used to close the photo mode to finish before it can be executed. This achieves the simultaneous execution of the asynchronous close thread and the open thread. Therefore, between the first time point and the second time point, the time for closing the photo mode based on the close thread (in this case, the asynchronous close thread) and the time for starting the multi-lens recording mode based on the start thread overlap. This improves the speed of switching shooting modes and thus improves the user experience.

[0011] However, not all shooting modes can release camera service resources by creating an asynchronous close thread. For example, in the scenario where the shooting mode switches from multi-lens recording mode to photo mode, multi-lens recording mode does not support creating an asynchronous close process. Therefore, the terminal device closes the multi-lens recording mode based on the first close thread. After the first close thread ends, the photo mode is started based on the open thread. In other words, the first close thread and the open thread are executed serially. Therefore, between the third and fourth time points, the time when the multi-lens recording mode is closed based on the close thread (here, the first close thread) and the time when the photo mode is started based on the start thread do not overlap.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, after displaying the third interface of the camera application at the fourth time point in response to the operation of switching the shooting mode to the photo mode at the third time point, the method further includes: switching the shooting mode to the video recording mode at the fifth time point; switching the shooting mode to the photo mode at the sixth time point before configuring resources for the video recording mode; the fifth time period and the sixth time period do not overlap between the fifth time point and the sixth time point; the fifth time period is the time period based on the closing thread closing the video recording mode, and the sixth time period is the time period based on the starting thread starting the photo mode. It should be noted that the closing thread in this implementation is the first close thread.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, after responding to the operation of switching the shooting mode to multi-lens recording mode at the first time point, the method further includes: creating a shutdown thread; and closing the shooting mode based on the shutdown thread. It should be noted that the shutdown thread in this implementation is an asynchronous close thread.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, creating a shutdown thread includes: creating a shutdown thread under preset conditions. The preset conditions include: the application package name indicated by the first pre-configuration parameter includes the application package name of the camera application; the shooting mode indicated by the second pre-configuration parameter does not include the photo mode; the last shutdown thread (here, the asynchronous close thread from the last shooting mode switch) is idle at the current moment; and the CHI module has been initialized. The first pre-configuration parameter indicates the application package name that supports creating a shutdown thread, and the second pre-configuration parameter indicates the shooting mode that does not support creating a shutdown thread. It should be noted that the shutdown thread in this implementation is an asynchronous close thread.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, after creating the shutdown thread under preset conditions, the method further includes: starting the multi-camera recording mode based on the startup thread; after the multi-camera recording mode has started successfully, if the shutdown thread has completed, starting the configuration stream thread to configure resources for the multi-camera recording mode; and displaying the second interface of the camera application at a second time point, including: after the configuration stream thread has completed, displaying the second interface of the camera application at a second time point. It should be noted that the shutdown thread in this implementation is an asynchronous close thread.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, after the multi-camera recording mode has been started, the method further includes: obtaining the thread state of the closing thread; and determining whether the closing thread has completed based on the thread state of the closing thread. It should be noted that the closing thread in this implementation is an asynchronous close thread.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the completion of the closing thread is determined based on its thread state, including: if the closing thread's thread state is terminated, the closing thread is determined to be complete; if the closing thread's thread state is not terminated, the closing thread is determined to be incomplete. It should be noted that the closing thread in this implementation is an asynchronous close thread.

[0018] Secondly, this application provides a terminal device, which includes: a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the terminal device to perform the method as described in the first aspect.

[0019] Thirdly, this application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method as described in the first aspect.

[0020] Fourthly, this application provides a computer program product, which includes a computer program that, when run, causes the computer to perform the method as described in the first aspect.

[0021] Fifthly, this application provides a chip including a processor for calling a computer program in memory to perform the method described in the first aspect.

[0022] It should be understood that the second to fifth aspects of this application correspond to the technical solutions of the first or second aspects of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the structure of a terminal device to which this application embodiment applies;

[0024] Figure 2 This is a software structure block diagram of a terminal device to which the embodiments of this application are applicable;

[0025] Figure 3 This is a schematic diagram of a mode switching interface provided in an embodiment of this application;

[0026] Figure 4 This is a schematic diagram of a mode switching method provided in an embodiment of this application;

[0027] Figure 5 This is a schematic diagram illustrating another mode switching method provided in an embodiment of this application;

[0028] Figure 6This is a schematic flowchart illustrating a mode switching method provided in an embodiment of this application;

[0029] Figure 7 This is a schematic flowchart of another mode switching method provided in the embodiments of this application;

[0030] Figure 8 This is a schematic diagram of another mode switching interface provided in an embodiment of this application;

[0031] Figure 9 This is a schematic flowchart illustrating another mode switching method provided in the embodiments of this application. Detailed Implementation

[0032] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0033] To facilitate a clear description of the technical solutions in the embodiments of this application, the relevant terms involved in this application will be described in detail below.

[0034] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect, without limiting their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0035] It should be noted that, in this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0036] Furthermore, "at least one" refers to one or more, while "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0037] Figure 1This is a schematic diagram of the structure of a terminal device to which this application embodiment applies. For example... Figure 1 As shown, the terminal device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a USB interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identity module (SIM) card interface 195, etc.

[0038] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the terminal device 100. In other embodiments of this application, the terminal 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.

[0039] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, display processing units (DPUs), and / or neural network processing units (NPUs). Different processing units may be independent devices or integrated into one or more processors. In some embodiments, terminal device 100 may also include one or more processors 110. The processor may serve as the central nervous system and command center of terminal device 100. The processor can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have been used or repeatedly used by processor 110. If processor 110 needs to reuse an instruction or data, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the terminal device 100.

[0040] The wireless communication function of terminal device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0041] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the terminal device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier, etc. The mobile communication module 150 can receive electromagnetic waves via the antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to the modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via the antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0042] The wireless communication module 160 can provide solutions for wireless communication applications on the terminal device 100, including wireless local area networks (WLAN), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0043] In some embodiments, antenna 1 of terminal device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling terminal device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include GSM, GPRS, CDMA, WCDMA, TD-SCDMA, LTE, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The aforementioned GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

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

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

[0046] Internal memory 121 can be used to store one or more computer programs, which include instructions. Processor 110 can execute the instructions stored in internal memory 121, thereby enabling terminal device 100 to perform various functional applications and data processing. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system; it may also store one or more application programs (such as a gallery, contacts, etc.). The data storage area may store data created during the use of terminal device 100 (such as photos, contacts, etc.). In addition, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. In some embodiments, processor 110 can execute instructions stored in internal memory 121 and / or instructions stored in memory disposed in processor 110 to enable terminal device 100 to perform various functional applications and data processing.

[0047] The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0048] In addition, the terminal device 100 runs an operating system, such as iOS, Android, or Windows. Applications can be installed and run on this operating system. In some embodiments, the terminal device 100 may run multiple operating systems.

[0049] It should be understood that Figure 1 The hardware modules included in the terminal device shown are merely illustrative and do not limit the specific structure of the terminal device. In fact, the terminal device provided in this application embodiment may also include other hardware modules that interact with the hardware modules shown in the figure, which are not specifically limited here. For example, the terminal device may also include a flash, a miniature projection device, etc. Furthermore, if the terminal device is a personal computer (PC), then the terminal device may also include components such as a keyboard and a mouse.

[0050] The software system of terminal device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of terminal device 100.

[0051] Figure 2 This is a software architecture block diagram of a terminal device to which this application embodiment applies. The layered architecture divides the software system of the terminal device 100 into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system may include an application layer (APP), an application framework layer, a hardware abstraction layer (HAL), and a kernel layer. In some embodiments, the terminal device also includes a hardware layer (e.g., a display screen). In some embodiments, the Android system also includes the Android runtime and system libraries.

[0052] For example, the application layer may include a series of application packages, and the application layer runs the application by calling the application programming interface (API) provided by the application framework layer. Figure 2 As shown, the application package may include applications such as camera, calendar, map, phone, music, WLAN, Bluetooth, video, social networking, gallery, navigation, and SMS.

[0053] The application framework layer provides an application programming interface (API) and programming services to the applications in the application layer. The framework layer includes some predefined functions. The framework layer provides these programming services to the application layer through the API interface. It should be noted that, in this embodiment, the programming service may be, for example, a camera service. In some embodiments, such as... Figure 2 As shown, the framework layer includes a camera service framework and a media framework. The media framework includes an encoder.

[0054] The hardware abstraction layer (HAL) is an interface layer located between the kernel layer and the hardware, used to abstract hardware. For example, such as... Figure 2 As shown, the hardware abstraction layer includes the camera interface.

[0055] The aforementioned kernel layer provides the underlying drivers for various hardware components of the mobile phone. For example, such as... Figure 2As shown, the kernel layer includes the camera driver module. The kernel layer also includes a process and thread manager, responsible for creating and terminating processes and threads. Low-level support for processes and threads is provided within the kernel layer.

[0056] The terminal device in this application embodiment can also be referred to as a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The terminal device can be a mobile phone, PC, smart TV, wearable device, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc.

[0057] By way of example and not limitation, in this embodiment, the terminal device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0058] Furthermore, the terminal device can also be a terminal device in an Internet of Things (IoT) system. IoT is an important component of future information technology development, its main technical characteristic being the connection of objects to networks via communication technology, thereby realizing an intelligent network of human-machine interconnection and machine-to-machine interconnection. This application does not limit the specific form of the terminal device. It should be understood that in the embodiments of this application, the terminal device can be a device for implementing the functions of the terminal device, or a device that supports the terminal device in implementing those functions, such as a chip system, which can be installed in the terminal. In the embodiments of this application, the chip system can be composed of chips, or it can include chips and other discrete components.

[0059] Figure 3 This is a schematic diagram of a mode switching interface provided in an embodiment of this application. Figure 3 The system includes interfaces A, B, and C. Taking a mobile phone as an example, in response to the user clicking the camera app icon on interface A, the phone displays the camera interface as shown in interface B. Interface B includes a preview area 01 and a shooting mode selection area 02. Preview area 01 displays a preview of the object to be photographed, and the user can select controls 03 on interface B to take a picture of the object.

[0060] For example, a user can tap a shooting mode in the shooting mode selection area 02 to switch shooting modes, or a user can swipe left or right in the shooting mode selection area 02 to switch shooting modes.

[0061] For example, the camera app can support multiple shooting modes, such as photo, video, multi-lens video (also known as multi-view video), time-lapse photography, ultra-wide-angle, large aperture, night mode, portrait mode, etc. The shooting mode of the camera app in interface B is photo.

[0062] In response to the user's selection of recording mode on interface B, the phone displays the recording interface as shown in interface C. Preview area 01 can display a preview of the object to be recorded, and the user can select control 03 on interface C to record the object.

[0063] based on Figure 2 The software architecture of the described terminal device, and Figure 3 The scenario described below, where the camera application switches from photo mode to video mode, is illustrated in the following example. Figure 4 This diagram illustrates a mode switching mechanism.

[0064] like Figure 4As shown, during the process of switching from photo mode to video mode, the camera application first calls the hardware abstraction layer's `close` procedure to close the photo mode. This closing process may include releasing channels established by the photo mode and resources requested, such as subsystem services, memory resources, and input / output (I / O) resources. After closing the photo mode, the camera application calls the hardware abstraction layer's `open` procedure to start the video mode and acquire camera parameters and resources. After the start procedure, the camera application calls the hardware abstraction layer's `configure_streams` procedure to configure the platform session, pipeline, and node, and performs hardware initialization, such as camera sensor initialization and configuring the video stream to be displayed. Then, the camera application sends a `repeating` command to the hardware abstraction layer to request images captured by the camera sensor. The hardware abstraction layer returns multiple frames of images to the camera application, which then displays a preview image in the preview area based on these frames. Figure 4 The process of switching shooting modes, as shown, takes approximately 810ms.

[0065] During the aforementioned mode switching process, the camera application first flushes the camera's use case resources, then calls the `close` procedure to close the photo-taking mode. After the photo-taking mode closure process is complete, the camera application calls the `open` procedure to start the video recording mode. After the video recording mode startup process is complete, the camera application calls the `configure_streams` procedure to configure the platform session, pipeline, and node. The `close` procedure for photo-taking mode and the `open` procedure for video recording mode are executed sequentially; in other words, the camera application only calls the `open` procedure to start video recording mode after the photo-taking mode closure process is complete. For some low-performance terminal devices, when closing the camera application's photo-taking mode, operations such as memory release, thread scheduling, and data processing cannot promptly acquire central processing unit (CPU) resources. This results in a longer time to close the photo-taking mode, reducing the speed of switching shooting modes and thus affecting the user experience.

[0066] In view of this, embodiments of this application provide a mode switching method, taking into account the previous shooting mode (e.g., Figure 3 The closing process of the shooting mode and the next shooting mode (e.g.) Figure 3The open processes of the recording modes are not coupled, so the terminal device can create an asynchronous close thread when the camera application calls the close interface. This asynchronous close thread is used to close the previous shooting mode. The camera application can then start the next shooting mode based on the open thread while closing the previous shooting mode using the asynchronous close thread. In this way, the close process of the previous shooting mode and the open process of the next shooting mode can occur simultaneously, reducing the time spent waiting for the close process of the previous shooting mode to complete. This improves the speed of switching shooting modes and enhances the user experience.

[0067] The previous shooting mode and the next shooting mode described in the embodiments of this application are relative to the operation of switching shooting modes. The shooting mode before the operation of switching shooting modes is the previous shooting mode, and the shooting mode after the operation of switching shooting modes is the next shooting mode.

[0068] It should be noted that, in the embodiments of this application, the close process refers to the process of closing a shooting mode based on the close thread (the asynchronous close thread or the first close thread in this document), and the process of closing a shooting mode based on the asynchronous close thread can also be called the asynchronous close process; the open process refers to the process of starting a shooting mode based on the open thread; the configure_streams process refers to the process of configuring camera service resources for a shooting mode based on the configure_streams thread.

[0069] based on Figure 2 The software architecture of the described terminal device, and Figure 3 The scenario described below, where the camera application switches from photo mode to video mode, is illustrated in the following example. Figure 5 This diagram illustrates another process for switching shooting modes.

[0070] Figure 5 This is a schematic diagram illustrating another mode switching method provided in an embodiment of this application. For example... Figure 5As shown, the camera application first calls the hardware abstraction layer's `close` procedure to close the photo-taking mode. The hardware abstraction layer creates an asynchronous `close` thread to handle the closing process. Simultaneously, the camera application calls the hardware abstraction layer's `open` procedure to start the camera application's recording mode. After the start-up process completes, the camera application calls the hardware abstraction layer's `configure_streams` procedure to configure the platform session, pipeline, and node, initialize the camera sensor, and configure the recording stream to be displayed. Then, the camera application requests images to be drawn from the hardware abstraction layer, which returns multiple frames to the camera application. The camera application then displays a preview image in the preview area based on these multiple frames. Figure 5 The process of switching shooting modes, as shown, takes approximately 700ms.

[0071] Figure 5 This is a schematic diagram illustrating the use of an asynchronous close thread to switch shooting modes, as provided in an embodiment of this application. Figure 4 and Figure 5 As can be seen, since the closing process of the photo mode is carried out in the asynchronous close thread, the camera application does not need to wait for the closing process of the photo mode to finish before it can quickly call the starting process of the video recording mode. The closing process of the photo mode and the starting process of the video recording mode can be executed simultaneously, which improves the speed of switching shooting modes.

[0072] Combination Figure 2 , Figure 6 Is Figure 5 Based on this, a more detailed flowchart of mode switching method 600 is provided. The steps of method 600 can be derived from... Figure 2 The camera application, application framework layer, hardware abstraction layer, and kernel layer interact and execute as shown.

[0073] The application layer and hardware abstraction layer require instruction translation via the Java Native Interface (JNI) of the application framework layer. This translates Java instructions from the application layer into C++ instructions that the hardware abstraction layer can recognize. The JNI interface includes interfaces such as `close`, `open`, and `configure_streams`.

[0074] exist Figure 6 In the described embodiments, the first shooting mode refers to the previous shooting mode or the shooting mode before switching (e.g., Figure 3 The second shooting mode indicates the next shooting mode or the shooting mode after switching (e.g., the shooting mode in the image). Figure 3(The video recording mode). Here, we will use the example where the first shooting mode is photo mode and the second shooting mode is video mode. In addition, the second shooting mode can also be other modes such as multi-lens video recording mode, which are not limited here.

[0075] It should be understood that the transmission between layers or modules in this embodiment is actually achieved through function calls.

[0076] Method 600 includes steps S601 to S630, and the specific steps are as follows:

[0077] S601, in response to the user's operation of switching the first shooting mode to the second shooting mode in the camera interface, the camera application sends a mode switching instruction to the application framework layer, which is used to instruct the camera application to switch the first shooting mode to the second shooting mode.

[0078] Optionally, the com.hihonor.camera process of the camera application sends the mode switching instruction to the camera server process of the application framework layer by calling the close interface of the application framework layer.

[0079] S602, the application framework layer sends this mode switching instruction to the hardware abstraction layer.

[0080] Optionally, the application framework layer sends the mode switching instruction to the android.hardware.camera.provider@2.4-server_64 process (hereinafter referred to as the provider process) of the hardware abstraction layer via the close interface.

[0081] After S601 and S602, the camera application can pass the mode switching instruction to the hardware abstraction layer by calling the close interface of the application framework layer, thereby calling the close thread of the hardware abstraction layer to close the first shooting mode.

[0082] It should be understood that after the terminal device is powered on or restarted, the hardware abstraction layer provider process will create the first close thread, open thread, and configure_streams thread for the camera application, waiting for the camera application to issue instructions to call them.

[0083] In step S603, the hardware abstraction layer determines whether the conditions for creating an asynchronous close thread are met. If so, step S604 is executed.

[0084] It should be noted that the asynchronous close thread in this application can also be referred to as the second close thread. The first close thread and the second close thread are two different threads.

[0085] In this step, the asynchronous close thread is used to close the first shooting mode and release the camera service resources requested by the first shooting mode. Optionally, determining whether to create an asynchronous close thread requires considering the following preset conditions: whether the current application package name and the current application shooting mode meet the requirements for creating an asynchronous close thread, whether the asynchronous close thread during the last mode switch (which can be called the previous asynchronous close thread) is in an idle state at the current moment, and the current initialization state of the CHI module.

[0086] The conditions that meet the preset conditions include: the current application package name and the current application shooting mode meet the requirements for creating an asynchronous close thread, the previous asynchronous close thread is in an idle state at the current moment, and the CHI module has been initialized.

[0087] Optionally, when determining whether the current application package name and shooting mode meet the requirements for creating an asynchronous close thread, the hardware abstraction layer can check the configuration parameters in the product.xml file to determine whether the asynchronous close thread switch is turned on, whether the application package name matches the configured application package name, and whether the current application's shooting mode supports the creation of an asynchronous close thread. It should be noted that in this embodiment, the current application is a camera application, the current application package name is the camera application's application package name, and the current application's shooting mode refers to the previous shooting mode of the camera application, i.e., the first shooting mode in this embodiment.

[0088] For example, the "isAvailable" parameter in the configuration parameters of the product.xml file is the master switch for configuring the asynchronous close thread. When the "isAvailable" parameter is configured as "0", it means that the asynchronous close thread is not turned on; when the "isAvailable" parameter is configured as "1", it means that the asynchronous close thread is turned on.

[0089] For example, the "avoidMode" parameter (which may be referred to as the second pre-configured parameter) in the product.xml file indicates that certain shooting modes for the camera application do not perform or support the creation of an asynchronous close thread. For example, shooting modes that do not support the creation of an asynchronous close thread include multi-camera recording. Obtaining the "avoidMode" parameter requires querying the camera application or printing the value of "tag:cameraSceneMode" at the hardware abstraction layer.

[0090] For example, the “supportAppNameList” parameter (which may be referred to as the first pre-configured parameter) in the product.xml file indicates the pre-configured application package names that can support the creation of asynchronous close threads.

[0091] Optionally, when determining whether the previous asynchronous close thread was in an idle state, the hardware abstraction layer can determine this based on whether the global handle of the asynchronous thread is null. If the global handle of the previous asynchronous close thread is null, it means that the previous asynchronous close thread was in an idle state, that is, the previous asynchronous close thread has completed execution; if the global handle of the previous asynchronous close thread is not null, it means that the previous asynchronous close thread was not in an idle state, that is, the previous asynchronous close thread has not completed.

[0092] It's important to note that if the current asynchronous close thread starts before the previous one has finished, the two asynchronous close threads might simultaneously operate on the same data structure or global variable, leading to data corruption and thread safety issues. Therefore, checking whether the previous asynchronous close thread was idle can prevent data corruption and improve the safety of the current asynchronous close thread.

[0093] Optionally, in some abnormal or test scenarios, the terminal device may immediately begin executing the close process for the second shooting mode after the open process, without executing the configure_streams process, meaning no resources are configured for the second shooting mode. This eliminates the need to release resources for the second shooting mode, and such situations constitute abnormal camera processes. In these abnormal camera processes, since no resources need to be released, the execution speed of the close process for the second shooting mode can be accelerated, without creating an asynchronous close thread to handle the close process.

[0094] Optionally, the hardware abstraction layer can determine whether the current camera flow is normal by detecting the initialization status of the CHI module. The initialization of the CHI module is related to the configure_streams process. If the terminal device does not execute the configure_streams process, the CHI module is not initialized; if the terminal device executes the configure_streams process, the CHI module will be initialized. For example, the terminal device can set a flag to indicate the initialization status of the CHI module. When the flag is "true", it indicates that the CHI module has been initialized; when the flag is "false", it indicates that the CHI module has not been initialized.

[0095] Optionally, the hardware abstraction layer can configure thread attributes and priorities for the asynchronous close thread when it is created, to ensure that the asynchronous close thread works properly.

[0096] Optionally, if the hardware abstraction layer determines that the conditions for creating an asynchronous close thread are not met, the terminal device executes as follows: Figure 4 The described process for switching shooting modes does not create an asynchronous close thread. The camera application calls the established close thread in the hardware abstraction layer to execute the close process for the first shooting mode. After the close process for the first shooting mode ends, the open process for the second shooting mode is executed.

[0097] S604, the Hardware Abstraction Layer sends an instruction to the kernel layer to create an asynchronous close thread.

[0098] Optionally, the Hardware Abstraction Layer (HAL) sends the instruction to create the asynchronous close thread to the kernel layer by calling the application programming interface (API) provided by the kernel layer. For example, the API provided by the kernel layer is the "thread_create" interface.

[0099] S605, the kernel layer creates an asynchronous close thread.

[0100] Optionally, the hardware abstraction layer writes parameters for creating an asynchronous close thread into its API interface, and the kernel-level thread manager creates the asynchronous close thread based on these parameters. After the asynchronous close thread is created, the kernel-level thread manager starts the asynchronous close thread to release the camera service resources for the first shooting mode.

[0101] S606, the kernel layer starts an asynchronous close thread to execute the close process of the first shooting mode.

[0102] Taking the Android system as an example, processes and threads are managed by the kernel-level thread manager. The thread manager is responsible for allocating processes or threads to be executed by the CPU, and the CPU executes the processes or threads allocated by the thread manager. Optionally, the kernel layer starts an asynchronous close thread, including: the kernel-level thread manager allocating the asynchronous close thread to the CPU, and the CPU starting the asynchronous close thread to release the camera service resources of the first shooting mode.

[0103] S607, the kernel layer sends the creation result to the hardware abstraction layer.

[0104] In this step, the creation result indicates that the asynchronous close thread has been created successfully.

[0105] S608, the hardware abstraction layer sends the first feedback result to the application framework layer, indicating that the close process of the first shooting mode has been completed.

[0106] In this step, after receiving the creation result, the hardware abstraction layer does not need to wait for the close process of the first shooting mode to finish. Instead, it immediately returns the first feedback result to the application framework layer by calling the close interface of the application framework layer. It should be understood that the hardware abstraction layer returns the first feedback result to the application framework layer based on the first close thread; in reality, the asynchronous close thread used to close the first shooting mode is still in progress.

[0107] S609, the application framework layer sends the first feedback result to the camera application.

[0108] Following steps S608 and S609, the hardware abstraction layer can pass the first feedback result to the camera application by calling the close interface of the application framework layer. After receiving the first feedback result, the camera application can execute S610, and the open process does not need to wait for the close process to finish, enabling the asynchronous close thread and open thread to execute simultaneously.

[0109] S610, the camera application sends an instruction to the application framework layer to execute the open procedure, which is used to instruct the open thread to start the second shooting mode.

[0110] Optionally, the com.hihonor.camera process of the camera application sends the instruction to execute the open process to the camera server process of the application framework layer by calling the open interface of the application framework layer.

[0111] S611, the application framework layer sends the instruction to the hardware abstraction layer to execute the open procedure.

[0112] Optionally, the application framework layer sends the instruction to execute the open process to the provider process of the hardware abstraction layer via the open interface.

[0113] After S610 and S611, the camera application can pass the instruction to execute the open process to the hardware abstraction layer by calling the open interface of the application framework layer, thereby starting the open thread of the hardware abstraction layer to execute the open process of the second shooting mode.

[0114] S612, the hardware abstraction layer sends an instruction to the kernel layer to start the open thread. This instruction instructs the kernel layer to start the open thread to execute the open process of the second shooting mode.

[0115] S613, the kernel layer starts the open thread to execute the open process of the second shooting mode.

[0116] Optionally, the kernel layer starts the open thread, which includes: the kernel layer's thread manager assigning the open thread to the CPU, the CPU starting to execute the open process of the second shooting mode, and configuring the camera parameters and resources of the second shooting mode.

[0117] S614: After the open process of the second shooting mode is completed, the kernel layer sends the second feedback result to the hardware abstraction layer.

[0118] In this step, the second feedback result is used to indicate that the opening process of the second shooting mode has ended.

[0119] S615, the hardware abstraction layer sends this second feedback result to the application framework layer.

[0120] S616, the application framework layer sends this second feedback result to the camera application.

[0121] S617, the camera application sends an instruction to the application framework layer to execute the configure_streams process, which is used to instruct the configure_streams thread to start the second shooting mode.

[0122] S618, the application framework layer sends the instruction to the hardware abstraction layer to execute the configure_streams process.

[0123] Optionally, the application framework layer sends the instructions to execute the configure_streams process to the hardware abstraction layer's provider process via the configure_streams interface.

[0124] After S617 and S618, the camera application can pass the instruction to execute the configure_streams process to the hardware abstraction layer by calling the configure_streams interface of the application framework layer, thereby starting the configure_streams thread of the hardware abstraction layer to execute the configure_streams process of the second shooting mode.

[0125] S619, the hardware abstraction layer detects whether the asynchronous close thread has ended.

[0126] In this step, after receiving the instruction from the application framework layer to execute the `configure_streams` process, the Hardware Abstraction Layer (HAL) first checks whether the asynchronous `close` thread has ended, i.e., whether the resource release based on the asynchronous `close` thread has been completed. After confirming the asynchronous `close` thread has ended, the HAL then instructs the kernel layer to start the `configure_streams` thread. Because the asynchronous `close` thread and the `configure_streams` thread are highly coupled in channel creation and memory allocation—for example, if they allocate the same memory space—the memory space allocated for the second shooting mode might be released by the asynchronous `close` thread, causing anomalies in the camera application's acquisition of camera service resources for the second shooting mode. Therefore, before instructing the kernel layer to start the `configure_streams` thread, the HAL needs to check whether the asynchronous `close` thread has ended. Only if the asynchronous `close` thread has ended should the `configure_streams` thread be started. This ensures the camera application can normally acquire camera service resources for the second shooting mode and avoids camera process anomalies.

[0127] As described in the S606 description, the kernel-level thread manager allocates the asynchronous close thread to the CPU, which then executes the asynchronous close thread for the first shooting mode to release the camera service resources for that mode.

[0128] For example, in the code logic, the Hardware Abstraction Layer (HAL) can configure thread blocking in the configure_streams process. If the asynchronous close thread has not yet finished, but the camera application has already been scheduled to the configure_streams process, then during the execution of the configure_streams process, the HAL checks whether the asynchronous close thread has completed. If it has not completed, the HAL instructs the thread manager not to allocate the configure_streams thread to the CPU by calling the thread manager's sleep interface. After the asynchronous close thread completes, the HAL instructs the thread manager to allocate the configure_streams thread to the CPU, and the CPU executes the configure_streams process. If it has already completed, the HAL instructs the kernel layer to start the configure_streams thread.

[0129] The asynchronous close thread has different thread states from start to finish, such as initial state (new), running state (runnable), waiting state (waiting), and terminated state (terminated). To check if the asynchronous close thread has terminated, the hardware abstraction layer (HAL) calls the thread manager's `pthread_join` interface, instructing the thread manager to check the CPU stack to see if the asynchronous close thread's state is terminated. When the HAL calls the `pthread_join` interface in the `configure_streams` thread, the `configure_streams` thread will be blocked until the CPU returns a termination instruction to the thread manager via `pthread_join`, indicating that the asynchronous close thread's state is terminated. Only then will the `configure_streams` thread continue execution. After receiving the termination instruction via `pthread_join`, the thread manager notifies the HAL that the `configure_streams` thread can continue execution.

[0130] In the S620, when the asynchronous close thread ends, the hardware abstraction layer sends an instruction to the kernel layer to start the configure_streams thread. This instruction instructs the kernel layer to start the configure_streams thread to execute the configure_streams process of the second shooting mode.

[0131] S621, the kernel layer starts the configure_streams thread to execute the configure_streams process for the second shooting mode.

[0132] Optionally, the kernel layer starts the configure_streams thread, including: the kernel layer's thread manager assigns the configure_streams thread to the CPU, and the CPU starts executing the configure_streams process of the second shooting mode, configuring the platform session, pipeline, and node of the second shooting mode.

[0133] S622, after the configure_streams process in the second shooting mode ends, the kernel layer sends the third feedback result to the hardware abstraction layer.

[0134] In this step, the third feedback result is used to indicate that the configure_streams process for the second shooting mode has ended.

[0135] S623, the kernel layer sends image data to the hardware abstraction layer.

[0136] During the `configure_streams` process, after the camera sensor node is created, the Hardware Abstraction Layer (HAL) sends a hardware initialization command to the kernel layer. Upon receiving the command, the kernel layer begins initializing the camera sensor. After hardware initialization is complete, the camera sensor begins acquiring image data and returns the data to the HAL through the kernel layer.

[0137] S624, the hardware abstraction layer sends this third feedback result to the application framework layer.

[0138] S625, the application framework layer sends this third feedback result to the camera application.

[0139] S626, the camera application sends a start instruction to the application framework layer, which is used to request image data.

[0140] In this step, the image data, as described in S623, is image data acquired by the camera sensor.

[0141] S627, the application framework layer sends a repeating instruction to the hardware abstraction layer. This repeating instruction is used to instruct the hardware abstraction layer to return image data frame by frame and to indicate the storage space of the image data.

[0142] S628, the hardware abstraction layer sends image data to the application framework layer.

[0143] In this step, the hardware abstraction layer copies each frame of image data to storage for transmission.

[0144] S629, the application framework layer sends image data to the camera application.

[0145] In the description of method 600 above, because the camera application's close and open processes are decoupled when switching shooting modes, the hardware abstraction layer's open thread can be called to execute the open process of the second shooting mode when executing the close process of the first shooting mode. Furthermore, there is idle time between the end of the open process of the second shooting mode and the start of the configure_streams process of the second shooting mode, typically long enough to accommodate the time required to execute the close process of the first shooting mode. In this way, the terminal device can fully utilize its hardware resources (CPU and memory) and fully schedule idle CPUs to handle asynchronous close threads through software parallel processing, without imposing additional cost burdens on the terminal device, and effectively improving the speed of mode switching.

[0146] In summary, the following is a combination of... Figure 6 The described internal interaction process of the terminal device and Figure 8 The scene shown is described as follows: Figure 7 Another mode switching method is shown.

[0147] Figure 7 This is a schematic flowchart of another mode switching method 700 provided in this application embodiment. The steps of method 700 can be executed by a terminal device; this application embodiment uses a mobile phone as an example for description. Method 700 includes S701 to S703, and the specific steps are as follows:

[0148] S701, in response to the operation of opening the camera application, displays the first interface of the camera application, which is the interface of the shooting mode.

[0149] See Figure 8 The diagram shows an interface for mode switching. The first interface displayed after the user opens the camera application on their device can be referenced. Figure 8 Interface A in the middle.

[0150] In response to the operation of switching the shooting mode to multi-lens video recording mode at the first time point, the S702 displays the second interface of the camera application at the second time point, which is the interface of multi-lens video recording mode.

[0151] At the second time point, the second interface displayed on the terminal device can be referenced. Figure 8 Interface B in the middle.

[0152] Combination Figure 6 As described above, after responding to the operation of switching the shooting mode to multi-lens recording mode at the first time point, the terminal device can execute S601 to S630. The second interface in this step can be understood as the preview interface in S630.

[0153] Between the first and second time points, there is an overlap between the first and second time periods. The first time period is the period when the photo-taking mode is closed based on the closing thread, and the second time period is the period when the multi-camera recording mode is started based on the starting thread. It should be understood that the closing thread here refers to the second close thread mentioned above, i.e., the asynchronous closing thread. Since the close process of the photo-taking mode is implemented based on the second close thread, during the execution of the close process of the photo-taking mode by the second close thread, the open thread is also simultaneously executing the open process of the multi-camera recording mode. Therefore, the time period when the photo-taking mode is closed based on the closing thread overlaps with the time period when the multi-camera recording mode is started based on the starting thread.

[0154] In response to the operation of switching the shooting mode to photo mode at the third time point, the S703 displays the third interface of the camera application at the fourth time point. The third interface is the photo mode interface.

[0155] At the fourth time point, the third interface displayed on the terminal device can be referenced. Figure 8 The C interface in the program.

[0156] Combination Figure 6 The description states that after switching the shooting mode to photo mode, the terminal device first executes S601 to S603. In S603, when determining whether the condition for creating an asynchronous close thread is met, since multi-camera recording mode does not support the creation of asynchronous close threads, the result of determining the condition "whether the current application's shooting mode supports asynchronous close threads" is no. Therefore, the terminal device can execute as follows: Figure 4 The described serial approach means that the terminal device does not create an asynchronous close thread to handle the close process of the multi-camera recording mode. Instead, it calls the first close thread already established in the hardware abstraction layer to execute the close process of the multi-camera recording mode first. After the close process of the multi-camera recording mode is completed, the open process of the photo-taking mode is executed. After the open process of the photo-taking mode is completed, the configure_streams process of the photo-taking mode is executed. Therefore, between the third and fourth time points, the third time period is the period when the multi-camera recording mode is closed based on the close thread, and the fourth time period is the period when the photo-taking mode is started based on the start thread. Here, the close thread refers to the first close thread.

[0157] It should be noted that for multi-camera recording, because the rear camera needs to be activated first, followed by the front camera, and both cameras operate independently, the terminal device cannot maintain two asynchronous close threads simultaneously. Therefore, it's impossible to close multi-camera recording by creating an asynchronous close thread. Consequently, the time period between the third and fourth time points—where the photo-taking mode is closed based on the closing thread—does not overlap with the time period where the multi-camera recording mode is started based on the starting thread.

[0158] Typically, in scenarios where a terminal device malfunctions or when testing the stability of the terminal device's camera application, the camera application will rapidly switch between one shooting mode and another. The following will combine... Figure 8 Introducing another method for switching modes.

[0159] Figure 9This is a schematic flowchart of another mode switching method 900 provided in this application embodiment. The steps of method 900 can be executed by a terminal device; this application embodiment uses a mobile phone as an example for description. The steps of method 900 can be executed after S703. Method 900 includes S901 and S902, and the specific steps are as follows:

[0160] The S901 switches the shooting mode to video mode at the fifth time point;

[0161] The S902 switches the shooting mode to photo mode at the sixth time point before configuring resources for video recording mode.

[0162] Between the fifth and sixth time points, the fifth time period is the period when the recording mode is turned off based on the closing thread, and the sixth time period is the period when the photo-taking mode is turned on based on the starting thread.

[0163] It's important to note that the time intervals between the fourth and fifth time points, and between the fifth and sixth time points, are very short. This can be understood as the terminal device rapidly switching from photo mode to video mode, and then rapidly switching back to photo mode. During this rapid and frequent switching, the terminal device immediately executes the close procedure for video mode after the open procedure for video mode ends, without executing the configure_streams procedure for video mode. Therefore, camera service resources are not allocated for video mode. When quickly switching back from video mode to photo mode, the terminal device also does not need to release camera service resources for video mode, thus speeding up the execution of the close procedure for video mode, completing it in a very short time. Therefore, in this scenario, the phone does not create an asynchronous close thread to handle the close procedure for video mode.

[0164] This application provides a terminal device, which can be a first terminal device, a second terminal device, or a third terminal device. The terminal device includes: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the terminal device to perform the aforementioned method.

[0165] This application provides a chip. The chip includes a processor, which is used to call a computer program in memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those in the related embodiments described above, and will not be repeated here.

[0166] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0167] In one possible implementation, a computer-readable medium may include random access memory (RAM), read-only memory (ROM), compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0168] This application provides a computer program product, which includes a computer program that, when run, causes a computer to perform the above-described method.

[0169] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0170] The above specific embodiments further illustrate the purpose, technical solution and beneficial effects of this application. It should be understood that the above are only specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A mode switching method, characterized in that, include: In response to the operation of opening the camera application, the first interface of the camera application is displayed, which is the interface of the first shooting mode; In response to the operation of switching the first shooting mode to the second shooting mode at a first time point, at a second time point, the second interface of the camera application is displayed, the second interface being the interface of the second shooting mode; In a first time period, the first shooting mode is turned off, and in a second time period, the second shooting mode is turned on. The first time period is between the first time point and the second time point, and the second time period is between the first time point and the second time point. The first time period and the second time period overlap, and the start time of the first time period is before the start time of the second time period. The first time period is the time period in which the first shooting mode is turned off, and the second time period is the time period in which the second shooting mode is turned on.

2. The method according to claim 1, characterized in that, The second interface includes images captured by at least two cameras; the method further includes: In response to the operation of switching the second shooting mode to the first shooting mode at a third time point, at a fourth time point, a third interface of the camera application is displayed, the third interface being the interface of the first shooting mode; In the third time period, the second shooting mode is turned off, and in the fourth time period, the first shooting mode is turned on. The third time period is between the third time point and the fourth time point, and the fourth time period is between the third time point and the fourth time point. The third time period and the fourth time period do not overlap.

3. The method according to claim 2, characterized in that, After the operation of switching the second shooting mode to the first shooting mode at a third time point in response to the operation of switching the second shooting mode to the first shooting mode at a fourth time point, the method further includes: At the fifth time point, switch the first shooting mode to the third shooting mode; Before configuring resources for the third shooting mode, the third shooting mode is switched to the first shooting mode at the sixth time point; In the fifth time period, the third shooting mode is turned off, and in the sixth time period, the first shooting mode is turned on. The fifth time period is between the fifth time point and the sixth time point, and the sixth time period is between the fifth time point and the sixth time point. The fifth time period and the sixth time period do not overlap.

4. The method according to claim 1, characterized in that, After the operation of switching the first shooting mode to the second shooting mode at the first time point, the method further includes: Create a shutdown thread; The first shooting mode is turned off based on the shutdown thread.

5. The method according to claim 4, characterized in that, The creation of the shutdown thread includes: The shutdown thread is created when the preset conditions are met; The preset conditions include: the application package name indicated by the first pre-configuration parameter includes the application package name of the camera application; the shooting mode indicated by the second pre-configuration parameter does not include the first shooting mode; the last closed thread is in an idle state at the current moment; and the CHI module has been initialized. The first pre-configured parameter indicates the application package name that supports the creation of the shutdown thread, and the second pre-configured parameter indicates the shooting mode that does not support the creation of the shutdown thread.

6. The method according to claim 5, characterized in that, After creating the shutdown thread under the condition that the preset conditions are met, the method further includes: The second shooting mode is initiated based on the startup thread; After the second shooting mode is started, if the shutdown thread is completed, start the configuration stream thread to configure resources for the second shooting mode; At the second time point, displaying the second interface of the camera application includes: After the configuration stream thread completes, at the second time point, the second interface of the camera application is displayed.

7. The method according to claim 6, characterized in that, After the second shooting mode is activated, the method further includes: Obtain the thread state of the closed thread; Based on the thread state of the thread being shut down, determine whether the shutdown of the thread has been completed.

8. The method according to claim 7, characterized in that, Determining whether the shutdown of a thread has been completed based on the thread state of the shutdown thread includes: If the thread state of the thread to be closed is terminated, it is determined that the thread closure is complete; If the thread state of the thread to be closed is not terminated, it is determined that the closure of the thread has not been completed.

9. A terminal device, characterized in that, include: Processor and memory, of which, The memory is used to store computer programs; The processor is used to invoke and execute the computer program to cause the terminal device to perform the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, Used to store computer programs that, when run on a computer, cause the computer to perform the method as described in any one of claims 1 to 8.

11. A computer program product, characterized in that, Includes a computer program that, when run, causes a computer to perform the method as described in any one of claims 1 to 8.

Images