System switching method and apparatus, device, and storage medium

Abstract

A system switching method and apparatus, a device, and a storage medium, which relate to the field of wearable devices. The method comprises: when a second processor is in a sleep state, processing a first event by means of a first system, the first system referring to a system run by a first processor (301); and in response to a triggered second event, switching the second processor to be in a wake-up state, and processing the second event by means of a second system, wherein the second system refers to a system run by the second processor, and the first processor does not meet processing capabilities required for the second event (302). In the method, a system switching mechanism is introduced to ensure the performance of a wearable device, reduce the power consumption of the wearable device, and increase the standby duration of the wearable device.

Description

TECHNICAL FIELD[2] This application relates to the field of wearable devices, and particularly to amethod and apparatus for system switching, a device, and a storage medium.BACKGROUND[3] A wearable device is a portable electronic device that can be worn directly orintegrated into clothes or accessories. Common wearable devices may include smartwatches, smart bracelets, smart glasses, etc.[4] For the sake of portability and wearability, the wearable device is generallydesigned to have a relatively small size, and the relatively small size means that thewearable device can only be equipped with a battery with a relatively small capacity,which leads to a short battery life of the wearable device, as a result, a user needs tocharge the wearable device frequently.SUMMARY[5] Implementations of the disclosure provide a method and apparatus forsystem switching, a device, and a storage medium. Technical solutions are as follows.[6] On the one hand, implementations of the disclosure provide a method forsystem switching. The method is applied to a wearable device. The wearable device is atleast equipped with a first processor and a second processor. The second processor hashigher power consumption than the first processor. The method includes the following.A first event is processed with a first system when the second processor is in a dormantstate, where the first system is a system run by the first processor. In response to asecond event triggered, the second processor is switched to a wake-up state and thesecond event is processed with a second system, where the second system is a systemrun by the second processor, and the first processor fails to meet a processing capacityrequired for the second event.[7] On the other hand, implementations of the disclosure provide an apparatusfor system switching. The apparatus is applied to a wearable device. The wearabledevice is at least equipped with a first processor and a second processor. The secondprocessor has higher power consumption than the first processor. The apparatus includesa first system module and a second system module. The first system module isconfigured to process a first event with a first system when the second processor is in adormant state, where the first system is a system run by the first processor. The secondsystem module is configured to switch the second processor to a wake-up state andprocess the second event with a second system, in response to a second event triggered,where the second system is a system run by the second processor, and the first processorfails to meet a processing capacity required for the second event.[8] On the other hand, implementations of the disclosure provide a wearabledevice. The wearable device includes a processor and a memory. The processor at leastincludes a first processor and a second processor. The second processor has higherpower consumption than the first processor. The memory stores at least one instruction.The at least one instruction, when executed by the processor, is operable to execute themethod for system switching described in the above aspect.[9] On the other hand, implementations of the disclosure provide a computerreadablestorage medium. The computer-readable storage medium stores at least oneinstruction which is operable with a processor to execute the method for systemswitching described in the above aspect.

[10] On the other hand, implementations of the disclosure provide a computerprogram product or computer program. The computer program product or computerprogram includes computer instructions. The computer instructions are stored in acomputer-readable storage medium. A processor of a computer device is configured toread the computer instructions from the computer-readable storage medium, andexecute the computer instructions, to make the computer device execute the method forsystem switching provided in the above aspect.BRIEF DESCRIPTION OF THE DRAWINGS

[11] FIG. 1 is a schematic diagram illustrating a dual-core communicationsoftware framework corresponding to a second processor provided in an exemplaryimplementation of the disclosure.

[12] FIG. 2 is a schematic diagram illustrating a dual-core communicationsoftware framework corresponding to a first processor provided in an exemplaryimplementation of the disclosure.

[13] FIG. 3 is a flowchart illustrating a method for system switching provided inan exemplary implementation of the disclosure.

[14] FIG. 4 illustrates schematic interface diagrams of a system process of asmart watch provided in an exemplary implementation of the disclosure.

[15] FIG. 5 is a flowchart illustrating a method for system switching provided inanother exemplary implementation of the disclosure.

[16] FIG. 6 is a timing diagram of a system switching process provided in anexemplary implementation of the disclosure.

[17] FIG. 7 is a flowchart illustrating a method for system switching provided inanother exemplary implementation of the disclosure.

[18] FIG. 8 is a flowchart illustrating a method for system switching provided inanother exemplary implementation of the disclosure.

[19] FIG. 9 is a timing diagram of an inter-system data synchronization processprovided in an exemplary implementation of the disclosure.

[20] FIG. 10 is a timing diagram of an inter-system data synchronization processprovided in another exemplary implementation of the disclosure.

[21] FIG. 11 is a timing diagram of a timing synchronization process provided inan exemplary implementation of the disclosure.

[22] FIG. 12 is a structural block diagram illustrating an apparatus for systemswitching provided in another implementation of the disclosure.

[23] FIG. 13 is a structural block diagram illustrating a wearable device providedin an exemplary implementation of the disclosure.DETAILED DESCRIPTION

[24] In order to make objects, technical solutions, and advantages of thedisclosure clearer, implementations of the disclosure will be further described in detailbelow with reference to accompanying drawings.

[25] The term "a plurality of / multiple" herein means two or more than two. Theterm "and / or" is used to describe the association of associated objects and indicates thatthere can be three relationships. For example, "A and / or B" may indicate: A exists alone,A and B exist simultaneously, and B exists alone. The character " / " generally indicatesthat associated objects before and after the character are in an "OR" relationship.

[26] In related technologies, a wearable device is equipped with a singleprocessor, and all system events generated during operation of the wearable device areprocessed with an operating system running on the processor, and thus, the processorneeds to have strong data processing capabilities and needs to remain in a working stateduring operation of the wearable device. However, in daily use, the wearable deviceonly needs to implement some functions with a low processing-performancerequirement in most cases. As an example, for a smart watch or smart bracelet, thesmart watch or smart bracelet only needs to display time and prompt messages in mostcases. Therefore, keeping the processor in the working state for a long time will notimprove performance of the wearable device, but will increase power consumption ofthe wearable device, resulting in a short battery life of the wearable device.

[27] In order to reduce the power consumption of the wearable device whileensuring the performance of the wearable device, in implementations of the disclosure,the wearable device is at least equipped with a first processor and a second processorwhich have different processing performance and power consumption, the firstprocessor and the second processor are used to run a first system and a second system(i.e., dual-core dual-system) respectively, and a system switching mechanism isdesigned for the dual-core dual-system.

[28] During operation of the wearable device, an event with a low-performanceprocessing requirement is processed with a first system running on a low powerconsumptionprocessor, and a high power-consumption processor is kept in a dormantstate (accordingly, a second system run by the high power-consumption processor is inthe dormant state), which can reduce the power consumption of the wearable devicewhile realizing basic functions of the wearable device. When there is an event with ahigh-performance processing requirement, the high power-consumption processor iswoken up, and the event is processed by switching to the second system, to ensure thatthe triggered event can be responded and processed in time and meet the performancerequirement of the wearable device. By adopting solutions of implementations of thedisclosure, the wearable device can automatically switch between systems according toa processing capability required for the triggered event and processing capabilities ofdifferent processors, which can reduce the power consumption of the wearable devicewhile ensuring the performance of the wearable device.

[29] In implementations of the disclosure, since the first processor and the secondprocessor work asynchronously, in order to ensure data consistency between differentsystems, the first system and the second system need to implement systemcommunication (or called dual-core communication). In a possible application scenario,the first system is a real time operating system (RTOS) running on a micro controllerunit (MCU), and the second system is an Android operating system running on acentral processing unit (CPU).

[30] As illustrated in FIG. 1, FIG. 1 illustrates a dual-core communicationsoftware framework of an Android operating system provided in an exemplaryimplementation of the disclosure. The dual-core communication software frameworkfollows a design principle of "low coupling, high reliability, and high reuse", andincludes development of kernel module, hardware abstraction layer (HAL) interfacedefinition language (HIDL) module, native service module, framework service module,framework application programming interface (API) module, and application (APP)module.

[31] The APP module includes functional modules such as launcher, setting, andsystem user interface (SystemUI). The framework API module includes managementmodules such as MCU manager, sensor manager, location manager, etc. The frameworkservice module includes service modules such as MCU manager service, system sensormanager, location manager service, etc. The native service module includes servicemodules such as dcc service, sensor service, etc. The HIDL module includes modulessuch as sensor HAL, global positioning system (GPS) HAL, etc. The kernel moduleincludes DCC transfer drivers such as dcc_datah, dcc_data, Mcu_sensor, Mcu_gps, andMcu_factory.

[32] A transfer layer, as an interface layer connecting higher layers and lowerlayers in the dual-core communication software framework, can shield transmissiondetails of communication of the lower layer (e.g., DataLink layer) of the system for anapplication layer, and provide service channels for application scenarios. Theapplication layer, as a service provider, can respond to human-computer interaction,transfer data generated during the human-computer interaction through the transfer layer,and respond to an external data request.

[33] The RTOS is designed according to a peer-to-peer principle. Taking a smartwatch as an example of the wearable device, as illustrated in FIG. 2, FIG. 2 illustrates adual-core communication software framework of an RTOS provided in an exemplaryimplementation of the disclosure.

[34] The dual-core communication software framework of the RTOS is dividedinto an application layer, a service layer, a framework layer, an HAL, and a platformlayer.

[35] The application layer includes application modules such as watch face, dailytracker, message center, voice around Apps, health Apps, and settings. The service layerincludes service modules such as sport & health task, system manager task, activitymanagement service (AMS), audio service, log service, Odette file transfer protocol(OFTP) service, Bluetooth (BT) service, delegate service, remote procedure call (RPC)service, sensor service, and storage service. The framework layer includes frameworkmodules such as message pub, user interface (UI) framework, genesis2D (G2D) engine,audio middleware, preference, file system, algorithms, Aios, and AsycEvent. The HALincludes hardware abstraction modules such as screen / touch panel (TP), audio, GPS,sensors, keypad, and motor. The platform layer includes board support package (BSP)and low level driver, where the BSP includes screen / TP, keys, GPS, codec, sensors,flash, motor, pseudo-static random access memory (PSRAM), etc., and the low leveldriver includes a universal asynchronous receiver / transmitter (UART), an analog-todigitalconverter (ADC), general-purpose input and output (GPIO), a serial peripheralinterface (SPI), an inter-integrated circuit (I2C), an input output system (IOS), pulsecode modulation (PCM), an inter-IC sound (I2S), hardware timer (HWTimer), etc.

[36] It is to be noted that, the above dual-core communication softwareframework is only for schematic illustration, those skilled in the art can also add, delete,or modify the framework according to actual needs, and the specific structure of thedual-core communication software framework is not limited in implementations of thedisclosure.

[37] The method for system switching of implementations of the disclosure canbe applied to a wearable device. The wearable device is at least equipped with a firstprocessor and a second processor. Power consumption of the second processor is higherthan that of the first processor. The method includes the following. When the secondprocessor is in a dormant state, a first event is processed with a first system, where thefirst system is a system run by the first processor. In response to a second eventtriggered, the second processor is switched to a wake-up state and the second event isprocessed with a second system, where the second system is a system run by the secondprocessor, and the first processor fails to meet a processing capacity required for thesecond event.

[38] Optionally, the second event is processed with the second system as follows.A first switch instruction is sent to the first system with the second system, to make thefirst system transfer a graphical user interface (GUI) display permission to the secondsystem according to the first switch instruction. The second event is processed with thesecond system, and a GUI corresponding to the second event is displayed.

[39] Optionally, the second event is processed with the second system as follows.Event data of the second event is sent to the second system with the first system, tomake the second system process the event data to obtain event feedback data. The eventfeedback data sent by the second system is received with the first system, and a GUIcorresponding to the second event is displayed according to the event feedback data.

[40] Optionally, after the second event is processed with the second system, themethod further includes the following. In response to completion of processing of thesecond event, the second processor is switched to the dormant state and the first event isprocessed with the first system.

[41] Optionally, the second system has a GUI display permission in a process ofprocessing the second event. Before the second processor is switched to the dormantstate, the method further includes the following. A second switch instruction is sent tothe first system with the second system, to make the first system obtain the GUI displaypermission from the second system according to the second switch instruction.

[42] Optionally, the method further includes the following. When the secondprocessor is in the dormant state, first data is cached with the first system, where thefirst data is cached in a data storage space corresponding to the first system. After thesecond processor is switched to the wake-up state, the method further includes thefollowing. When the second processor is in the wake-up state, the first data issynchronized to the second system with the first system.

[43] Optionally, synchronizing the first data to the second system with the firstsystem includes: binding, according to a data type of the first data, a datasynchronization service through a data communication service provided by the secondsystem, where different data types correspond to different data synchronization services;and synchronizing the first data to a target application in the second system through thedata synchronization service bound, where the target application is used to process thefirst data.

[44] Optionally, synchronizing the first data to the second system with the firstsystem further includes: synchronizing target data in the first data to the second systemwith the first system, where a data volume of the target data is less than a data-volumethreshold.

[45] Optionally, after the first data is cached with the first system, the methodfurther includes the following. In response to a data volume of the first data cachedreaching a storage-capacity threshold, the second processor is switched to the wake-upstate and the first data is synchronized to the second system with the first system.

[46] Optionally, after the first data is cached with the first system, the methodfurther includes the following. In response to the first data cached containing instantdata, the second processor is switched to the wake-up state and the instant data issynchronized to the second system with the first system.

[47] Optionally, after the first data is cached with the first system, the methodfurther includes the following. In response to a data alignment time point being reached,the second processor is switched to the wake-up state and the first data is synchronizedto the second system with the first system.

[48] Optionally, the second processor is switched to the wake-up state in responseto the data alignment time point being reached as follows. A target data alignment timepoint corresponding to the first data is determined according to a real-time requirementof the first data, where data with different real-time requirements correspond to differentdata alignment time points, and a time interval between data alignment time points isnegatively correlated with the real-time requirement. In response to the target dataalignment time point being reached, the second processor is switched to the wake-upstate.

[49] Optionally, a communication component is mounted on the first processor.Before the first data is synchronized to the second system with the first system, themethod further includes the following. When the second processor is in the wake-upstate, in response to receiving, by the communication component, second data sent byan external device, the second data is synchronized to the second system with the firstsystem.

[50] Optionally, after the second event is processed with the second system, themethod further includes the following. Third data is synchronized to the first systemthrough a data communication service provided by the second system, where the thirddata is data generated in a process of processing the second event.

[51] Optionally, after the second event is processed with the second system, themethod further includes the following. In response to completion of processing of thesecond event, the second processor is maintained in the wake-up state within a dormantdelay duration corresponding to the second event, where the dormant delay duration isdetermined according to a wake-up frequency of the second processor after the secondevent and / or determined according to an event type of the second event. In response tothe dormant delay duration being reached, the second processor is switched to thedormant state and the first event is processed with the first system.

[52] Referring to FIG. 3, FIG. 3 is a flowchart illustrating a method for systemswitching provided in an exemplary implementation of the disclosure. Thisimplementation is illustrated by exemplarily applying the method to a wearable device.The method includes the following.

[53] At 301, when a second processor is in a dormant state, a first event isprocessed with a first system, where the first system is a system run by a first processor.

[54] In implementations of the disclosure, processing performance of the firstprocessor is lower than that of the second processor (a processing capability of the firstprocessor is lower than that of the second processor, and a processing speed of the firstprocessor is lower than that of the second processor), and power consumption of thefirst processor is lower than that of the second processor. Accordingly, a second systemcan process an event processed by the first system, but the first system may notnecessarily be able to process an event processed by the second system.

[55] For example, the first processor is an MCU, the second processor is a CPU,the first system i s an RTOS, and the second system is an Android system.

[56] In some implementations, a working mode of the wearable device includes aperformance mode, a hybrid mode, and a low power-consumption mode. In theperformance mode, both the second processor and the first processor are maintained in awake-up state. In the low power-consumption mode, the first processor is maintained ina working state while the second processor is maintained in a turned-off state. In thehybrid mode, when the first event is processed with the first system, the secondprocessor is maintained in a dormant state.

[57] In a possible implementation, the first system is configured to process a firstevent, and the second system is configured to process a second event, where aprocessing capacity required for the first event is lower than a processing capacityrequired for the second event.

[58] In another possible implementation, the first event and the second event areclassified according to an application scenario. As an example, an event in a weakinteraction scenario (i.e., a scenario with a low human-computer interaction frequencyand a low processing performance requirement) is classified as the first event, while anevent in a strong interaction scenario (i.e., a scenario with frequent human-computerinteraction and a high processing performance requirement) is classified as the secondevent.

[59] Taking a smart watch as an example of the wearable device, the first eventmay include events such as watch face display, watch face interface switching, andnotification message display, and the second event may include events such as incomingcall answering, application launching, watch face editing, and function setting. Thespecific types and classification manners of events are not limited in implementations ofthe disclosure.

[60] Different from an electronic device with a strong interaction property such asa smart phone, the wearable device, as an auxiliary electronic device, has weakinteraction with users in most usage scenarios. For instance, in most scenarios, userssimply use smart watches to check the time by raising their wrists. Therefore, whenprocessing the first event with the first system, the wearable device controls the secondprocessor to be in the dormant state (the second system is in the dormant state), therebyreducing the overall power consumption of the wearable device.

[61] At 302, in response to a second event triggered, the second processor isswitched to a wake-up state and the second event is processed with a second system,where the second system is a system run by the second processor, and the first processorfails to meet a processing capacity required for the second event.

[62] Due to the limited processing capacity of the first system, the first systemcannot process all events. Therefore, in order to ensure that an event with a highprocessing capacity requirement can be processed in time, in implementations of thedisclosure, when a second event requiring a processing capacity beyond a processingcapacity of the first processor is triggered, the wearable device switches the secondprocessor from the dormant state to the wake-up state, and switches a system for eventprocessing from the first system to the second system, to process the second event withthe second system.

[63] The first processor failing to meet the processing capability required for thesecond event can be understood as: the first processor is unable to process the secondevent, or the first processor can process the second event, but a processing effect (e.g., aprocessing speed) cannot meet a processing effect requirement of the second event.

[64] In implementations of the disclosure, when a processor is in the dormantstate, a system run by the processor is in the dormant state. When the processor isswitched from the dormant state to the wake-up state, the system run by the processor isalso switched to the wake-up state.

[65] In a possible implementation, a triggered event is recognized duringoperation of the first system. If the triggered event belongs to the second event, thesecond system is woken up; otherwise, the second system continues to remain in thedormant state. Optionally, the first system stores an event list containing various secondevents, and the first system determines whether the triggered event belongs to thesecond event according to the event list.

[66] In some implementations, the first processor wakes up the second processorby sending an interrupt to the second processor, thereby waking up the second system toprocess the event.

[67] Optionally, when the second processor is in the wake-up state, the firstprocessor is in the wake-up state to prevent the first processor from frequently switchingbetween the dormant state and the wake-up state, or the first processor is switched fromthe wake-up state to the dormant state to further reduce the power consumption of thedevice.

[68] In sum, in implementations of the disclosure, the wearable device isequipped with the first processor with low power consumption and the second processorwith high power consumption, and the first processor is configured to run the firstsystem and the second processor is configured to run the second system. By introducinga system switching mechanism, the first event with a low processing capacityrequirement is processed by the first system, and the second processor remains in thedormant state; when the second event requiring a processing capacity beyond aprocessing capacity of the first processor is triggered, the second processor is woken upand the second event is processed by switching to the second system, to ensure timelyprocessing of the event. By adopting solutions of implementations of the disclosure, thepower consumption of the wearable device can be reduced while ensuring theperformance of the wearable device, thereby prolonging a battery life of the wearabledevice.

[69] It is to be noted that, under the multi-processor architecture ofimplementations of the disclosure, since the first processor of the wearable device is inthe working state most of the time and the second processor of the wearable device ismostly in the dormant state (because mostly some simple events need to be processedby the first processor), that is, most of the time, the first processor is a master processorof the wearable device and the second processor is a slave processor of the wearabledevice, logics of determining whether to wake up the processor and switch the operatingsystem are executed by the first processor (the first system), and there is no need toadditionally set a manager in the wearable device to monitor and evaluate eventsprocessed by different processors and there is no need to additionally set a switcher inthe wearable device to switch between different processors, which is beneficial toreducing complexity of the system architecture in the wearable device.

[70] In order to further reduce the power consumption of the wearable device,after the second system completes processing of the second event, the second processoris switched back to the dormant state, and processing of the first event is continued withthe first system, so that the wearable device maintains high performance (and highpower consumption) in few scenarios, but maintains low power consumption (and lowperformance) in most scenarios. In a possible implementation, after the operations at302, the method further includes the following.

[71] At 303, in response to completion of processing of the second event, thesecond processor is switched to the dormant state, and the first event is processed withthe first system.

[72] In order to keep the wearable device in a low power-consumption state inmost scenarios, when processing of the second event is completed, the wearable devicecontrols the second processor to enter the dormant state, and switches a system for eventprocessing from the second system to the first system, so that the first system cancontinue to process the first event.

[73] Optionally, the first processor is in the dormant state when the second systemprocesses the second event, and the first processor is switched from the dormant state tothe wake-up state when processing of the second event is completed. The secondprocessor may wake up the first processor by sending an interrupt to the first processor.

[74] By adopting the above dual-core dual-system switching mechanism, thewearable device can automatically switch between the first system and the secondsystem according to processing capacity requirements in different application scenarios,which can rich application functions while prolonging the battery life.

[75] Taking a smart watch as an example of the wearable device, in a schematicapplication scenario, the smart watch has an RTOS and an Android system, where theRTOS is responsible for sensor data processing and watch face display, and theAndroid system is responsible for implementing application functions. As illustratedin FIG. 4, the RTOS displays watch face 41, while the Android system is in thedormant state, to maintain low power consumption. When a user needs to makepayment by scanning a code with the wearable device, a scanning-code application canbe launched through a physical button, and accordingly, when the smart watch detectsan event of launching of the scanning-code application, the Android system is wokenup, and the scanning-code application is launched by switching to the Android system,so that a two-dimensional payment barcode is displayed on scanning-code interface 42.In response to completion of the payment and returning to the watch face, the Androidsystem enters the dormant state, and the Android system is switched to the RTOS tocontinue to display watch face 41.

[76] In implementations of the disclosure, when processing of the second event iscompleted, the wearable device can switch the second processor back to the dormantstate, and switch to the first system for event processing, so that the wearable device canbe in a low power-consumption state in most scenarios, which can further prolong thebattery life of the wearable device.

[77] It is found in practical applications that, after switching to the second systemto process the second event, the user generally performs operations related to the secondevent on the wearable device. If the second processor is switched back to the dormantstate immediately upon completion of processing of the second event, the secondprocessor may be re-awakened within a short time period, resulting in frequentswitching of the second processor.

[78] In order to avoid unnecessary switching between the wake-up state and thedormant state of the processor, in a possible implementation, in response to completionof processing of the second event, the wearable device maintains the second processorin the wake-up state within a dormant delay duration corresponding to the second event,switches the second processor to the dormant state when the dormant delay duration haselapsed, and processes the first event with the first system.

[79] The dormant delay duration herein may be determined according to a wakeupfrequency of the second processor after the second event and / or determinedaccording to an event type of the second event.

[80] Optionally, after the second processor is woken up in response to the secondevent each time, the second system records a wake-up frequency in a preset time periodafter the second event (the wake-up frequency may be determined by recording a timepoint of each wake-up), to determine the dormant delay duration of the secondprocessor according to the wake-up frequency, where the dormant delay duration ispositively correlated with the wake-up frequency, and the dormant delay duration has anupper limit. For example, the dormant delay duration ranges from 15 seconds to 2minutes.

[81] Optionally, the second system can also determine the dormant delay durationaccording to the event type of the second event, where a correspondence between eventtypes and dormant delay durations may be set by default, or may be determinedaccording to user's historical / previous usage records (which can be determinedaccording to user's operation frequencies after different types of second events aretriggered). Exemplarily, if the second event is an alarm-clock event, the dormant delayduration is 10 seconds (the user usually does not perform subsequent operations afterturning off the alarm clock); if the second event is a notification-message event, thedormant delay duration is 30 seconds (the user usually performs a series of subsequentoperations after reading the notification message).

[82] In this implementation, by setting the dormant delay duration, the secondprocessor is switched to the dormant state again when processing of the second event iscompleted and the dormant delay duration has elapsed, which can avoid frequent wakeupof the second processor.

[83] In a possible implementation, since the first processor is always in the wakeupstate during operation of the wearable device, the first system monitors the event(whether the first system can process the triggered event), and wakes up the secondprocessor according to the monitoring result. When performing system switching, thesystems need to switch a GUI display permission, to ensure correct display of a UI aftersystem switching. The following are schematic implementations for illustration.

[84] Referring to FIG. 5, FIG. 5 is a flowchart illustrating a method for systemswitching provided in another exemplary implementation of the disclosure. Thisimplementation is illustrated by exemplarily applying the method to a wearable device.The method includes the following.

[85] At 501, when a second processor is in a dormant state, a first event isprocessed with a first system.

[86] For details of implementation of the above operations, reference may bemade to the foregoing operations at 301, which will not be repeated in thisimplementation.

[87] In a possible implementation, when the wearable device is powered on, thesecond processor pulls up a first processor in a startup process, and the second processornotifies the first processor after startup of the second processor is completed (i.e.,startup of the second system is completed). After the startup of the second processor iscompleted (i.e., the startup of the second system is completed), the second processorsends a notification message to the first processor and enters the dormant state, and thefirst processor obtains a GUI display permission according to the notification messageto display a UI (displaying a GUI of the first event).

[88] Schematically, as illustrated in FIG. 6, in a startup process, a CPU pulls upan MCU with a reset signal (reset pin), and the MCU notifies the CPU when startup ofthe RTOS is completed. After startup of the Android system is completed, the CPUsends a startup completion notification to the MCU, and the MCU sends a hybrid-modeenter request (MSG_ENTER_HYBRID_MODE_REQ) to the pref task. In response toreceiving the hybrid-mode enter request, the pref task enters a hybrid mode by callingenter_hybrid_mode_api(), and instructs the GUI task to transfer a display permission tothe first system (give lcd semaphore). In response to receiving a hybrid-mode enterresponse (MSG_HYBRID_MODE_RSP) fed back by the pref task, the MCU displays awatch face.

[89] At 502, in response to a second event triggered, the second processor iswoken up with a first processor.

[90] Optionally, the second event that triggers system switching and processorwake-up may be set in the first system by the developer in advance. During operation ofthe first system, when a triggered event is received, whether the event belongs to thesecond event is detected. If the event belongs to the second event, determine that systemswitching needs to be performed, and the second processor is woken up with the firstprocessor; if the event does not belong to the second event, determine that the firstprocessor can process the event, and the second processor remains in the dormant state.

[91] In a possible implementation, when receiving the triggered second event, thefirst processor wakes up the second processor in the dormant state by sending aninterrupt to the second processor.

[92] In some implementations, the second event is an event triggered by aspecified user operation. For instance, the wearable device is a smart watch, thespecified user operation may include an operation of entering an application list(entering the application list by clicking an icon), an operation of launching a functioncard (enabling a corresponding function by clicking the function card), an operation ofediting a watch face, an operation of launching a watch face window component, anoperation of launching a shortcut application (triggered by a physical button), anoperation of notification-based application launching (launching a correspondingapplication by clicking an application notification), an operation of status-bar enteringsetting (entering a setting interface through a status bar), etc.

[93] In other implementations, the second event is an event triggered by anapplication. For instance, the wearable device is a smart watch, the second event may bean event triggered by a call application (incoming-call reminder), a timer application(timer reminder), or an alarm-clock application (alarm-clock reminder). The specifictriggering manner and the type of the second event are not limited in implementationsof the disclosure.

[94] At 503, a first switch instruction is sent to the first system with a secondsystem, to make the first system transfer a GUI display permission to the second systemaccording to the first switch instruction.

[95] Since the GUI display permission belongs to the first system (i.e., thewearable device displays a GUI of the first event processed by the first system) whenthe second processor is in the dormant state,, and the wearable device needs to display aGUI of the second event during processing of the second event, the second system inthe wake-up state instructs the first system to transfer the GUI display permission to thesecond system by sending a first switch instruction to the first system.

[96] Schematically, as illustrated in FIG. 6, when receiving a user-triggeredoperation such as entering an application list, launching a function card, editing a watchface, launching a watch face window component, button-based quick applicationlaunching, notification-based application launching, and status-bar entering setting, theCPU and the Android system are woken up, and the CPU sends to the MCU anotification of switching to the Android system. In response to receiving a switchnotification, the MCU sends a hybrid-mode exit request(MSG_EXIT_HYBRID_MODE_REQ) to the pref task. In response to receiving thehybrid-mode exit request, the pref task exits a hybrid mode by callingexit_hybrid_mode_api(), and instructs the GUI task to transfer a display permission tothe Android system (take lcd semaphore). In response to receiving a hybrid-mode exitresponse (MSG_HYBRID_MODE_RSP) fed back by the pref task, the MCU exits watchface display, and the CPU controls a display to display a UI.

[97] Similarly, when receiving an incoming-call reminder triggered by a callapplication, a timer reminder triggered by a timer application, or an alarm-clockreminder triggered by an alarm-clock application, the MCU wakes up the CPU for eventprocessing.

[98] At 504, the second event is processed with the second system, and a GUIcorresponding to the second event is displayed.

[99] Since the GUI display permission has been transferred to the second system,the second system can display the UI on a display screen of the wearable device duringprocessing of the second event, and the second event can be completed under userinteraction.

[100] In a schematic example, the smart watch currently displays, with the RTOS,a watch face, when receiving a triggered alarm-clock reminder event, the smart watchstops using the displayed watch face, and wakes up and switches to the Androidsystem to display an alarm-clock application interface, so that the user can turn off thealarm clock in the alarm-clock application interface.

[101] At 505, in response to completion of processing of the second event, asecond switch instruction is sent to the first system with the second system, to make thefirst system obtain the GUI display permission from the second system according to thesecond switch instruction.

[102] In a possible implementation, after processing of the second event iscompleted, if a triggered first event is received, the second processor enters the dormantstate, and switch to the first system again; or, if processing of the second event iscompleted and no other triggered second event is received within a preset duration, thesecond processor enters the dormant state, and switch to the first system again.

[103] As an example, when processing of the alarm-clock reminder event iscompleted and an operation of returning to a watch face is received, the Androidsystem running in the smart watch enters the dormant state and is switched to the RTOSto display the watch face again.

[104] Since the GUI display permission belongs to the second system duringprocessing of the second event, the second system needs to transfer the GUI displaypermission to the first system when the second system is switched to the first system, sothat the first system can display a UI.

[105] In some implementations, before the second processor is switched to thedormant state, the second system sends a second switch instruction to the first system,and the first system obtains the GUI display permission according to the second switchinstruction.

[106] Schematically, as illustrated in FIG. 6, when the Android system completesprocessing of the event and an operation of returning to a watch face is received, theCPU sends a switch notification to the MCU and enters the dormant state, and the MCUobtains a display permission again according to the switch notification and displays thewatch face.

[107] At 506, the second processor is switched to the dormant state, and the firstevent is processed with the first system.

[108] Further, the wearable device continues to process the first event with the firstsystem, and displays a GUI of the first event. When the triggered second event isreceived again, the wearable device performs the operations at 502-505 repeatedly.

[109] In some implementations, the above system switching process is executedwhen a power of the wearable device is higher than a threshold. In order to ensure thatthe wearable device can realize most basic functions such as time display function of asmart watch, the second processor in the wearable device is turned off when the powerof the wearable device is lower than the threshold, a mode switch instruction is sent tothe first processor, and the first processor is switched to a low power-consumption modein response to receiving the mode switch instruction. In the low power-consumptionmode, the first system stops processing of the triggered second event.

[110] Schematically, as illustrated in FIG. 6, when a (remaining) power of thesmart watch is lower than 5%, the CPU sends to the MCU a mode switch instruction ofentering a low power-consumption mode and is turned off. In response to receiving themode switch instruction, the MCU enters the low power-consumption mode.

[111] In this implementation, when an event that cannot be processed by the firstprocessor is triggered, the second processor is woken up, and the second system notifiesthe first system to perform system switching, to obtain the GUI display permission,which can ensure that the UI of the second event can be displayed normally duringprocessing of the event by the second system. Moreover, when the second system isswitched back to the first system, the first system obtains the GUI display permissionfrom the second system again, to ensure normal display of the UI of the first event. Assuch, seamless switching between the dual systems can be realized.

[112] In the implementation illustrated in FIG. 5, when switching between the firstsystem and the second system, switching of the GUI display permission is required. Inanother possible implementation, when the second event that cannot be processed by thefirst processor is triggered, the wearable device processes the second event with thesecond system, and data obtained by processing the second event by the second systemis fed back to the first system, and the first system displays the GUI according to thedata, that is, there is no need to switch the GUI display permission between the firstsystem and the second system.

[113] Referring to FIG. 7, FIG. 7 is a flowchart illustrating a method for systemswitching provided in another exemplary implementation of the disclosure. Thisimplementation is illustrated by exemplarily applying the method to a wearable device.The method includes the following.

[114] At 701, when a second processor is in a dormant state, a first event isprocessed with a first system.

[115] At 702, in response to a triggered second event, the second processor iswoken up with a first processor.

[116] For details of implementation of the operations at 701-702, reference may bemade to the foregoing operations at 501-502, which will not be repeated in thisimplementation.

[117] At 703, event data of the second event is sent to a second system with thefirst system, to make the second system process the event data to obtain event feedbackdata.

[118] After the second processor is woken up, the second system is in the wake-upstate. Different from the foregoing implementation in which the second system needs toobtain the GUI display permission from the first system, in this implementation, thesecond system is in a background silent processing state after being woken up, and isonly used for data processing in the background. The GUI display permission stillbelongs to the first system, that is, there is no need to switch the GUI display permission.

[119] Moreover, in order to enable the second system to process the second event,the first system sends the event data of the second event to the second system, and thesecond system processes the second event according to the event data.

[120] The event data herein may be service request data of a service requested bythe second event or application request data of a requested application. Accordingly, theevent feedback data obtained by processing the second event by the second system maybe service data or application data.

[121] At 704, the event feedback data sent by the second system is received withthe first system, and a GUI corresponding to the second event is displayed according tothe event feedback data.

[122] Further, the second system sends the event feedback data to the first system,and the first system further processes the event feedback data, and packs data (UI data)required for displaying a GUI in the foreground, so that the GUI of the second event canbe displayed subsequently according to the packaged UI data.

[123] At 705, in response to completion of processing of the second event, thesecond processor is switched to the dormant state, and the first event is processed withthe first system.

[124] After processing of the second event is completed, the wearable deviceswitches the second processor to the dormant state (without switching the GUI displaypermission), processes the first event with the first system, and displays the GUI of thefirst event.

[125] In this implementation, when the second event that cannot be processed bythe first processor is triggered, the second processor is woken up, and the second systemperforms silent processing on the second event and sends the obtained event feedbackdata to the first system, so that the first system can display the GUI of the second eventaccording to the event feedback data, which can realize timely processing of aperformance event without switching the GUI display permission, thereby reducingimplementation complexity of system switching.

[126] Since the first processor and the second processor work asynchronously,during system switching (the first system is switched to the second system, or thesecond system is switched to the first system), data synchronization between thesystems is required to ensure data consistency between different systems. The followingare schematic implementations for illustration.

[127] Referring to FIG. 8, FIG. 8 is a flowchart illustrating a method for systemswitching provided in another exemplary implementation of the disclosure. Thisimplementation is illustrated by exemplarily applying the method to a wearable device.The method includes the following.

[128] At 801, when a second processor is in a dormant state, a first event isprocessed with a first system.

[129] For details of implementation of the above operations, reference may bemade to the foregoing operations at 501, which will not be repeated in thisimplementation.

[130] At 802, first data is cached with the first system, where the first data iscached in a data storage space corresponding to the first system.

[131] In a possible implementation, the first processor and the second processoreach correspond to a data storage space. When the second processor is in the dormantstate, in order to avoid the problem of high power consumption caused by frequentwake-up of the second processor, the first system caches data generated when the firstsystem processes the first event or the first system caches data received from an externaldevice.

[132] Schematically, as illustrated in FIG. 8, when the wearable device is coupledwith a mobile phone via Bluetooth and collects synchronization data (SyncData) to theMCU through Bluetooth, the MCU caches the received synchronization data, and sendssynchronization completion feedback (syncOK) to the mobile phone through Bluetoothafter completing the synchronization.

[133] At 803, in response to a triggered second event, the second processor iswoken up with a first processor.

[134] For details of implementation of the above operations, reference may bemade to the foregoing operations at 502, which will not be repeated in thisimplementation.

[135] At 804, when the second processor is in a wake-up state, the first data issynchronized to a second system with the first system.

[136] In a possible implementation, after the second processor is woken up, inorder to ensure that data of the second system is consistent with data of the first systemwhen the second system processes an event later, the first system initiates datasynchronization to the second system, to synchronize all or part of the first data to thesecond system. Synchronization policies (partial synchronization or full synchronization)for different types of data may be the same or different.

[137] Optionally, the second system of implementations of the disclosure providesa data communication service for data transfer (this service may be located in theframework service of the application layer), and the first system and the second systemexchange data through the data communication service. When performing datasynchronization, the first system binds, according to a data type of the first data, a datasynchronization service through a data communication service, to synchronize the firstdata to a target application in the second system through the bound data synchronizationservice, where the target application is used to process the first data.

[138] Optionally, different data types correspond to different data synchronizationservices. The data type is related to an application used to process the data, and differentapplications correspond to different data synchronization services. The first data is, forexample, pedometer data, a data synchronization service corresponding to a pedometerapplication is bound, and the pedometer data is sent to the pedometer applicationthrough the data synchronization service. The first data is, for example, alarm-clocksetting data, a data synchronization service corresponding to an alarm-clock applicationis bound, and the alarm-clock setting data is sent to the alarm-clock application throughthe data synchronization service.

[139] Optionally, after the target application processes the synchronized first data,the processed data is further synchronized to the first system through the datacommunication service, to maintain data consistency between the dual systems.

[140] Schematically, as illustrated in FIG. 9, after the second system is woken up,the MCU sends synchronization data (SyncData) to the MCUService provided by thesecond system, and the MCUService finds a corresponding data synchronization service(findSyncDataService) according to a data type of the synchronization data, to bind thesynchronization data with the found data synchronization service(bindSyncDataService), where the MCUService uses a retry mechanism when findingthe data synchronization service. After binding of the data synchronization service iscompleted, the MCUService sends synchronization data to a target application forprocessing the synchronization data through service (SyncMcuDataService), where thetarget application is bound to the service (onBind).

[141] After the target application processes the synchronization data, the processeddata is fed back through the MCUService. Accordingly, the MCU synchronizes thereceived data and feeds back a synchronization completion instruction to the targetapplication. In response to receiving the synchronization completion instruction, thetarget application sends the synchronization completion instruction to the MCUService,to instruct the MCUService to unbind the data synchronization service(unBindSyncDataService).

[142] In a possible application scenario, a communication component (e.g., aBluetooth component) is mounted on the first processor, before data is synchronized tothe second system with the first system, in response to receiving, by the communicationcomponent, second data sent by an external device, the second data is synchronized tothe second system with the first system, and the first data is synchronized aftersynchronization of the second data is completed.

[143] As an example, in a process of synchronizing stored alarm-clock data by thefirst system to the second system, if the first system receives alarm-clock data sent bythe mobile phone through Bluetooth, the first system synchronizes the alarm-clock datareceived through Bluetooth to the second system, and then synchronizes the cachedalarm-clock data to the second system.

[144] At 805, a first switch instruction is sent to the first system with the secondsystem, to make the first system transfer a GUI display permission to the second systemaccording to the first switch instruction.

[145] At 806, the second event is processed with the second system, and a GUIcorresponding to the second event is displayed.

[146] For details of implementation of the operations at 805-806, reference may bemade to the foregoing operations at 503-504, which will not be repeated in thisimplementation.

[147] At 807, third data is synchronized to the first system through a datacommunication service provided by the second system, where the third data is datagenerated in a process of processing the second event.

[148] The second system will generate new data in a process of processing thesecond event, and the generated new data may not be consistent with data in the firstsystem. The second event is, for example, an operation of setting a watch face, a watchface pattern may change before and after the operation of setting the watch face.Therefore, the second system needs to synchronize the generated new data (i.e., thethird data) to the first system.

[149] Optionally, the second system synchronizes the third data to the first systemthrough a data communication service. For this process, reference may be made to aprocess of synchronizing data by the first system to the second system, which will notbe repeated in this implementation.

[150] In a possible implementation, the second system synchronizes to the firstsystem data generated in a process of processing the second event in real time, or thesecond system synchronizes the generated data to the first system when processing ofthe second event is completed.

[151] Schematically, as illustrated in FIG. 10, in the wake-up state, the App in theAndroid system runs and receives user interaction operations, and the Appsynchronizes data generated during user interaction to the MCU in real time through theMCUService (i.e., sync in the figure). After receiving the data synchronized by the App,the MCU feeds back a synchronization completion instruction (syncOK) to the App.

[152] At 808, in response to completion of processing of the second event, asecond switch instruction is sent to the first system with the second system, to make thefirst system obtain a GUI display permission from the second system according to thesecond switch instruction.

[153] For details of implementation of the above operations, reference may bemade to the foregoing operations at 505, which will not be repeated in thisimplementation.

[154] It is to be noted that, if the third data is not fully synchronized whenswitching to the first system again, the second system needs to fully synchronize thethird data to the first system before entering the dormant state; if the third data is fullysynchronized in real time, there is no need to perform a synchronization process.

[155] Schematically, as illustrated in FIG. 10, when switching to the first system,since the third data has not been fully synchronized, before entering the dormant state, itis necessary to continue to synchronize the third data to the MCU through theMCUService until the third data is fully synchronized.

[156] At 809, the second processor is switched to the dormant state, and the firstevent is processed with the first system.

[157] For details of implementation of the above operations, reference may bemade to the foregoing operations at 506, which will not be repeated in thisimplementation.

[158] In this implementation, after the second system is woken up, the first systemsynchronizes data generated or received when the second processor is in the dormantstate to the second system through the data communication service provided by thesecond system; the second system synchronizes data generated during operation to thefirst system, to realize data seamless connection before and after system switching,which can avoid the problem of data inconsistency before and after system switching,thereby ensuring data consistency between the dual systems.

[159] For data of different types, data synchronization strategies adopted by thefirst system may be different. In a possible implementation, the data synchronizationstrategies include the following four synchronization strategies: 1. real-timesynchronization; 2. fixed-length synchronization; 3. combined synchronization; 4.timing synchronization. The four synchronization strategies will be depictedrespectively below.

[160] 1. Real-time synchronization

[161] For data with a high real-time requirement such as alarm-clock data, ifsynchronization is performed when the second system is woken up by an event, theproblem of untimely synchronization may occur. Therefore, in a possibleimplementation, when cached first data contains instant data, the first processor activelywakes up the second processor, to synchronize the instant data to the second systemwith the first system.

[162] In a schematic scenario, when the second processor is in the dormant state, ifthe first system receives alarm-clock data synchronized by a mobile phone throughBluetooth, the first processor wakes up the second processor and the alarm-clock data issynchronized to the second system.

[163] Optionally, when the first system synchronizes data to the second system inreal time, the first system still has a GUI display permission, that is, the wearable devicestill displays a GUI of the first system, and the second system and the first systemperform silent synchronization in the background.

[164] 2. Fixed-length synchronization

[165] A data storage space corresponding to the first processor is generallyrelatively small, and accordingly, a volume of data (i.e., data volume) that the firstsystem can cache is relatively small. When the volume of the cached data reaches anupper limit of the data storage space, the first system overwrites the cached data. Inorder to avoid data loss caused by data overwriting, in a possible implementation, inresponse to a data volume of the first data cached reaching a storage-capacity threshold,the first processor wakes up the second processor, to synchronize the first data to thesecond system with the first system.

[166] In a schematic example, when a remaining storage space of a data storagespace corresponding to the first system is less than 20%, the first processor activelywakes up the second processor in the dormant state, and the cached data is synchronizedto the second system.

[167] Optionally, when the first system uses a fixed-length synchronizationstrategy to synchronize data to the second system, the first system still has a GUIdisplay permission, that is, the wearable device still displays a GUI of the first system,and the second system and the first system perform silent synchronization in thebackground.

[168] 3. Combined synchronization

[169] In a possible implementation, for cached data with a small data volume,when the second processor is in the wake-up state, the first system combines the cacheddata and then synchronizes the combined data to the second system.

[170] Optionally, when the first system synchronizes the first data to the secondsystem, the first system synchronizes target data in the first data to the second system,where a data volume of the target data is less than a data-volume threshold. Optionally,the target data may be non-instant data. For instance, the target data is notificationmessagedata or health data whose bytes are less than 100 bytes, and the specific type ofthe target data is not limited in this implementation.

[171] 4. Timing synchronization

[172] In order to avoid frequent wake-up of the second processor, in a possibleimplementation, the wearable device adopts a timing synchronization mechanism, andthe second processor is switched to the wake-up state in response to a data alignmenttime point being reached, to synchronize the first data cached in the data storage spaceto the second system with the first system. Moreover, after the data synchronization iscompleted, the second processor is switched to the dormant state again, therebyreducing the power consumption of the wearable device.

[173] Schematically, as illustrated in FIG. 11, when the Android system is in thedormant state, the mobile phone sends Bluetooth data to the RTOS through a Bluetoothconnection. Since a data synchronization time point has not been reached, the RTOScaches the Bluetooth data. Once the data synchronization time point is reached, theAndroid system is woken up and receives the Bluetooth data synchronized by theRTOS. After the data synchronization is completed, the Android system enters thedormant state again.

[174] Moreover, considering that different data may have different real-timerequirements, in a possible implementation, different data alignment time points are setin advance for data with different real-time requirements. Accordingly, whenperforming data synchronization, the first system determines, according to a real-timerequirement of the first data cached in the data storage space, a target data alignmenttime point corresponding to the first data, to wake up the second processor and performdata synchronization when the target data alignment time point is reached.

[175] A time interval between adjacent data alignment time points is negativelycorrelated with the real-time requirement. That is, the higher a real-time requirement ofthe data, the shorter a time interval between corresponding data alignment time points,and accordingly, the higher a timing synchronization frequency of the data, which canensure that data with a high real-time requirement can be synchronized to the secondsystem as soon as possible, thereby ensuring data consistency between the dual systems.

[176] Optionally, the time interval between adjacent data alignment time points is afixed value, such as 1 minute, 5 minutes, etc. The time interval between adjacent dataalignment time points may also be a dynamic value. For instance, an event interval isadjusted dynamically according to a corresponding time period or historical datasynchronization condition (e.g., a time interval at night can be longer than a timeinterval during the day).

[177] Optionally, a correspondence between different data and real-timerequirements is set in the first system in advance. For example, the first system isprovided with a correspondence between data types and real-time requirement levels,where a higher real-time requirement level indicates that data belonging to the data typehas a higher real-time requirement for synchronization.

[178] In a schematic example, the first system receives function-card update datasent by a terminal through Bluetooth at 11:01:10, receives watch face update data sentby the terminal through Bluetooth at 11:01:45 (a user modify a watch face of thewearable device at a terminal side), and updates pedometer data at 11:01:55. The firstsystem caches the function-card update data, the watch face update data, and thepedometer data in the data storage space in sequence. Once a data synchronization timepoint of 11:02:00 is reached, the second processor is woken up, and the first systemsynchronizes the function-card update data, the watch face update data, and thepedometer data to the second system.

[179] Optionally, the four synchronization strategies may be executed individuallyor in combination.

[180] In some implementations, fixed-length synchronization and combinedsynchronization are implemented in combination. Once a data volume of the first datareaches a storage-capacity threshold, the first processor wakes up the second processor,and the first system combines cached data with a small data volume (e.g., health datacollected by a sensor) are merged, to synchronize the combined cached data to thesecond system.

[181] In some implementations, timing synchronization and combinedsynchronization are implemented in combination. When a data synchronization timepoint is reached, the first processor wakes up the second processor, and the first systemcombines cached data with a small data volume, to synchronize the combined cacheddata to the second system.

[182] In some implementations, real-time synchronization and combinedsynchronization are implemented in combination. When the cached first data containsinstant data, the first processor wakes up the second processor, and the instant data issynchronized to the second system with the first system. Also, the first system combinescached data with a small data volume, to synchronize the combined cached data to thesecond system.

[183] In some implementations, fixed-length synchronization and timingsynchronization are implemented in combination. On condition that a data alignmenttime point has not been reached, if a data volume of the first data reaches a storagecapacitythreshold, the first processor wakes up the second processor, and the firstsystem combines cached data with a small data volume, to synchronize the combinedcached data to the second system. On condition that the data alignment time point isreached, the first processor wakes up the second processor, and the cached data issynchronized to the second system with the first system.

[184] It is to be noted that, the above implementations only schematically illustratecombination of synchronization policies. In actual application, all, any two, or any threeof the four synchronization policies can be combined and executed, and combinationand execution of synchronization policies are not limited in implementations of thedisclosure.

[185] In these implementations, different data synchronization mechanisms areadopted, which can ensure that data can be synchronized to the second system timelyand accurately while shortening a wake-up duration of the second system, and can avoiddata loss, thereby further ensuring the data consistency between the dual systems, andimproving stability during switching of the dual systems.

[186] It is to be noted that, in the foregoing implementations, only the firstprocessor (corresponding to the first system) and the second processor (correspondingto the second system) are used for schematic illustration. When the wearable device isequipped with three or more processors, the wearable device can switch among three ormore systems (different systems are run under different performance-requirementscenarios), which is not limited in implementations.

[187] Referring to FIG. 12, FIG. 12 is a structural block diagram illustrating anapparatus for system switching provided in an implementation of the disclosure. Theapparatus can be implemented as all or part of a wearable device through software,hardware, or combination of the software and the hardware. The apparatus includes afirst system module 1201 and a second system module 1202. The first system module1201 is configured to process a first event with a first system when the second processoris in a dormant state, where the first system is a system run by the first processor. Thesecond system module 1202 is configured to switch the second processor to a wake-upstate and process the second event with a second system, in response to a second eventtriggered, where the second system is a system run by the second processor, and the firstprocessor fails to meet a processing capacity required for the second event.

[188] Optionally, the second system module 1202 includes a first instructionsending unit and a first display unit. The first instruction sending unit is configured tosend a first switch instruction to the first system with the second system, to make thefirst system transfer a GUI display permission to the second system according to thefirst switch instruction. The first display unit is configured to process the second eventwith the second system, and display a GUI corresponding to the second event.

[189] Optionally, the first system module 1201 includes a data feedback unit and asecond display unit. The data feedback unit is configured to send event data of thesecond event to the second system with the first system, to make the second systemprocess the event data to obtain event feedback data. The second display unit isconfigured to receive the event feedback data sent by the second system with the firstsystem, and display a GUI corresponding to the second event according to the eventfeedback data.

[190] Optionally, the first system module 1201 is further configured to switch thesecond processor to the dormant state and process the first event with the first system, inresponse to completion of processing of the second event.

[191] Optionally, the second system has a GUI display permission in a process ofprocessing the second event. The second system module 1202 is further configured tosend a second switch instruction to the first system with the second system, to make thefirst system obtain the GUI display permission from the second system according to thesecond switch instruction.

[192] Optionally, the apparatus further includes a caching module and a firstsynchronization module. The caching module is configured to cache first data with thefirst system when the second processor is in the dormant state, where the first data iscached in a data storage space corresponding to the first system. The firstsynchronization module is configured to synchronize the first data to the second systemwith the first system when the second processor is in the wake-up state.

[193] Optionally, the first synchronization module is configured to: bind,according to a data type of the first data, a data synchronization service through a datacommunication service provided by the second system, where different data typescorrespond to different data synchronization services; and synchronize the first data to atarget application in the second system through the data synchronization service bound,where the target application is used to process the first data.

[194] Optionally, the first synchronization module is further configured tosynchronize target data in the first data to the second system with the first system, wherea data volume of the target data is less than a data-volume threshold.

[195] Optionally, the apparatus further includes a second synchronization module.The second synchronization module is configured to switch the second processor to thewake-up state and synchronize the first data to the second system with the first system,in response to a data volume of the first data cached reaching a storage-capacitythreshold.

[196] Optionally, the apparatus further includes a third synchronization module.The third synchronization module is configured to switch the second processor to thewake-up state and synchronize instant data to the second system with the first system, inresponse to the first data cached containing the instant data.

[197] Optionally, the apparatus further includes a fourth synchronization module.The fourth synchronization module is configured to switch the second processor to thewake-up state and synchronize the first data to the second system with the first system,in response to a data alignment time point being reached.

[198] Optionally, the fourth synchronization module is specifically configured to:determine a target data alignment time point corresponding to the first data according toa real-time requirement of the first data, where data with different real-timerequirements correspond to different data alignment time points, and a time intervalbetween data alignment time points is negatively correlated with the real-timerequirement; and switch the second processor to the wake-up state in response to thetarget data alignment time point being reached.

[199] Optionally, a communication component is mounted on the first processor.The apparatus further includes a fourth synchronization module. The fourthsynchronization module is configured to synchronize second data to the second systemwith the first system in response to receiving, by the communication component, thesecond data sent by an external device, when the second processor is in the wake-upstate.

[200] Optionally, the apparatus further includes a fifth synchronization module.The fifth synchronization module is configured to synchronize third data to the firstsystem through a data communication service provided by the second system, where thethird data is data generated in a pr ocess of processing the second event.

[201] Optionally, the apparatus further includes a wake-up maintaining module.The wake-up maintaining module is configured to maintain the second processor in thewake-up state within a dormant delay duration corresponding to the second event inresponse to completion of processing of the second event, where the dormant delayduration is determined according to a wake-up frequency of the second processor afterthe second event and / or determined according to an event type of the second event. Thefirst system module 1201 is further configured to switch the second processor to thedormant state and process the first event with the first system, in response to thedormant delay duration being reached.

[202] In sum, in implementations of the disclosure, the wearable device isequipped with the first processor with low power consumption and the second processorwith high power consumption, and the first processor is configured to run the firstsystem and the second processor is configured to run the second system. By introducinga system switching mechanism, the first event with a low processing capacityrequirement is processed by the first system, and the second processor is maintained inthe dormant state; when the second event requiring a processing capacity beyond aprocessing capacity of the first processor is triggered, the second processor is woken upand the second event is processed by switching to the second system, to ensure timelyprocessing of the event. By adopting solutions of implementations of the disclosure, thepower consumption of the wearable device can be reduced, while ensuring theperformance of the wearable device, thereby prolonging a battery life of the wearabledevice.

[203] In implementations of the disclosure, when processing of the second event iscompleted, the wearable device can switch the second processor back to the dormantstate, and switch to the first system for event processing, so that the wearable device canbe in a low power-consumption state in most scenarios, which can further prolong thebattery life of the wearable device.

[204] In implementations of the disclosure, by setting the dormant delay duration,the second processor is switched to the dormant state again when processing of thesecond event is completed and the dormant delay duration has elapsed, which can avoidfrequent wake-up of the second processor.

[205] In implementations of the disclosure, when an event that cannot beprocessed by the first processor is triggered, the second processor is woken up, and thesecond system notifies the first system to perform system switching, to obtain the GUIdisplay permission, which can ensure that the UI of the second event can be displayednormally during processing of the event by the second system. Moreover, when thesecond system is switched back to the first system, the first system obtains the GUIdisplay permission from the second system again, to ensure normal display of the UI ofthe first event. As such, seamless switching between the dual systems can be realized.

[206] In implementations of the disclosure, when the second event that cannot beprocessed by the first processor is triggered, the second processor is woken up, and thesecond system performs silent processing on the second event and sends the obtainedevent feedback data to the first system, so that the first system can display the GUI ofthe second event according to the event feedback data, which can realize timelyprocessing of a performance event without switching the GUI display permission,thereby reducing implementation complexity of system switching.

[207] In implementations of the disclosure, after the second system is woken up,the first system synchronizes data generated or received when the second processor is inthe dormant state to the second system through the data communication serviceprovided by the second system; the second system synchronizes data generated duringoperation to the first system, to realize data seamless connection before and after systemswitching, which can avoid the problem of data inconsistency before and after systemswitching, thereby ensuring data consistency between the dual systems.

[208] In implementations of the disclosure, different data synchronizationmechanisms are adopted, which can ensure that data can be synchronized to the secondsystem timely and accurately while shortening a wake-up duration of the second system,and can avoid data loss, thereby further ensuring the data consistency between the dualsystems, and improving stability during switching of the dual systems.

[209] Referring to FIG. 13, FIG. 13 is a structural block diagram illustrating awearable device provided in an exemplary implementation of the disclosure. Thewearable device of the disclosure may include one or more of the following components:a processor 1310 and a memory 1320.

[210] The processor 1310 at least includes a first processor 1311 and a secondprocessor 1312, where the first processor 1311 is used to run a first system and thesecond processor 1312 is used to run a second system, power consumption of the firstprocessor 1311 is lower than that of the second processor 1312, and performance of thefirst processor 1311 is lower than that of the second processor 1312. The processor 1310uses various interfaces and lines to connect various parts of the entire electronic device,and executes various functions of the electronic device and processes data by running orexecuting instructions, programs, code sets or instruction sets stored in the memory1320 and calling data stored in the memory 1320. Optionally, the processor 1310 maybe implemented in at least one of the following hardware forms: digital signalprocessing (DSP), field-programmable gate array (FPGA), and programmable logicarray (PLA). The processor 1310 may integrate combination of one or more of a CPU, agraphics processing unit (GPU), a neural-network processing unit (NPU), a modem, etc.,where the CPU mainly handles the operating system, UI, and application programs, etc.;the GPU is responsible for rendering and drawing of contents that needs to be displayedon a touch screen; the NPU is used to realize artificial intelligence (AI) functions; themodem is used to process wireless communication. It can be understood that, themodem may not be integrated into the processor 1310, but may be realized through asingle chip.

[211] The memory 1320 may include a random access memory (RAM), and mayalso include a read-only memory (ROM). Optionally, the memory 1320 includes a non25transitory computer-readable storage medium. The memory 1320 may be used to storeinstructions, programs, codes, codes sets or instructions sets. The memory 1320 mayinclude a program storage region and a data storage region. The program storage regionmay store instructions for implementing an operating system, instructions for at leastone function (e.g., a touch function, a sound playback function, and an image playbackfunction), instructions for realizing various method implementations, etc. The datastorage region may store data created according to use of the wearable device (e.g.,audio data and phonebook), etc.

[212] The wearable device of implementations of the disclosure may furtherinclude a communication component 1330 and a display component 1340. Thecommunication component 1330 may be a Bluetooth component, a wireless-fidelity(Wi-Fi) component, a near field communication (NFC) component, etc., and is used tocommunicate with an external device (a server, or other terminal devices) through awired or wireless network. The display component 1340 is used to display a GUI and / orreceive a user interaction operation.

[213] In addition, those skilled in the art can understand that the structure of thewearable device illustrated in the accompanying drawings does not constitute anylimitation on the wearable device. The wearable device may include more or fewercomponents than illustrated, or may combine certain components, or may have differentcomponent arrangements. As an example, the wearable device further includescomponents such as a radio frequency circuit, an input unit, a sensor, an audio circuit, aspeaker, a microphone, and a power supply, which will not be repeated herein.

[214] Implementations of the disclosure further provide a computer-readablestorage medium. The computer-readable storage medium stores at least one instructionwhich, when executed by a processor, is operable to execute the method for systemswitching provided in the foregoing implementations.

[215] Implementations of the disclosure further provide a computer programproduct or computer program. The computer program product or computer programincludes computer instructions stored in a computer-readable storage medium. Aprocessor of a computer device is configured to read the computer instructions from thecomputer-readable storage medium, and execute the computer instructions, to make thecomputer device execute the method for system switching provided in the foregoingimplementations.

[216] Those skilled in the art should realize that, in one or more of the foregoingexamples, functions described in implementations of the disclosure may beimplemented in hardware, software, firmware, or any combination thereof. Whenimplemented in software, the functions may be stored on a computer-readable mediumor transmitted as one or more instructions or codes on the computer-readable medium.The computer-readable medium may include a computer storage medium and acommunication medium. The communication medium includes any medium thattransfers computer programs from one place to another place. The storage medium maybe any available medium that can be accessed by a general-purpose or special-purposecomputer.

[217] The above merely depicts some exemplary implementations of the disclosure,which however is not intended to limit the disclosure. Any modifications, equivalentsubstitutions, or improvements made thereto without departing from the spirits andprinciples of the disclosure shall all be encompassed within the protection of thedisclosure.

Claims

1. A method for system switching, applied to a wearable device at least equipped with a first processor and a second processor, the second processor having higher power consumption than the first processor, and the method comprising: processing a first event with a first system when the second processor is in a dormant state, the first system being a system run by the first processor; and switching the second processor to a wake-up state and processing the second event with a second system, in response to a second event triggered, the second system being a system run by the second processor, and the first processor failing to meet a processing capacity required for the second event.

2. The method as claimed in claim 1, wherein processing the second event with the second system comprises: sending a first switch instruction to the first system with the second system, to make the first system transfer a graphical user interface (GUI) display permission to the second system according to the first switch instruction; and processing the second event with the second system, and displaying a GUI corresponding to the second event.

3. The method as claimed in claim 1, wherein processing the second event with the second system comprises: sending event data of the second event to the second system with the first system, to make the second system process the event data to obtain event feedback data; and receiving the event feedback data sent by the second system with the first system, and displaying a GUI corresponding to the second event according to the event feedback data.

4. The method as claimed in any of claims 1 to 3, wherein after processing the second event with the second system, the method further comprises: switching the second processor to the dormant state and processing the first event with the first system, in response to completion of processing of the second event.

5. The method as claimed in claim 4, wherein the second system has a GUI display permission in a process of processing the second event; before switching the second processor to the dormant state, the method further comprises: sending a second switch instruction to the first system with the second system, to make the first system obtain the GUI display permission from the second system according to the second switch instruction.

6. The method as claimed in any of claims 1 to 3, wherein the method further comprises: caching first data with the first system when the second processor is in the dormant state, wherein the first data is cached in a data storage space corresponding to the first system; and after switching the second processor to the wake-up state, the method further comprises: synchronizing the first data to the second system with the first system when the second processor is in the wake-up state.

7. The method as claimed in claim 6, wherein synchronizing the first data to the second system with the first system comprises: binding, according to a data type of the first data, a data synchronization service through a data communication service provided by the second system, wherein different data types correspond to different data synchronization services; and synchronizing the first data to a target application in the second system through the data synchronization service bound, wherein the target application is used to process the first data.

8. The method as claimed in claim 7, wherein synchronizing the first data to the second system with the first system further comprises: synchronizing target data in the first data to the second system with the first system, wherein a data volume of the target data is less than a data-volume threshold.

9. The method as claimed in claim 6, wherein after caching the first data with the first system, the method further comprises: switching the second processor to the wake-up state and synchronizing the first data to the second system with the first system, in response to a data volume of the first data cached reaching a storage-capacity threshold.

10. The method as claimed in claim 6, wherein after caching the first data with the first system, the method further comprises: switching the second processor to the wake-up state and synchronizing instant data to the second system with the first system, in response to the first data cached containing the instant data.

11. The method as claimed in claim 6, wherein after caching the first data with the first system, the method further comprises: switching the second processor to the wake-up state and synchronizing the first data to the second system with the first system, in response to a data alignment time point being reached.

12. The method as claimed in claim 11, wherein switching the second processor to the wake-up state in response to the data alignment time point being reached comprises: determining a target data alignment time point corresponding to the first data according to a real-time requirement of the first data, wherein data with different real-time requirements correspond to different data alignment time points, and a time interval between data alignment time points is negatively correlated with the real-time requirement; and switching the second processor to the wake-up state in response to the target data alignment time point being reached.

13. The method as claimed in claim 6, wherein a communication component is mounted on the first processor, and before synchronizing the first data to the second system with the first system, the method further comprises: synchronizing second data to the second system with the first system in response to receiving, by the communication component, the second data sent by an external device, when the second processor is in the wake-up state.

14. A wearable device, comprising: a processor, at least comprising a first processor and a second processor; and a memory, storing at least one instruction; the second processor having higher power consumption than the first processor; the at least one instruction, when executed by the processor, being operable to execute the method for system switching as claimed in any of claims 1 to 13.