CN111064590A

CN111064590A - Abnormal state repairing method and device and readable storage medium

Info

Publication number: CN111064590A
Application number: CN201811205143.0A
Authority: CN
Inventors: 方昭潭; 潘林锋; 徐郎特
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2018-10-16
Filing date: 2018-10-16
Publication date: 2020-04-24
Anticipated expiration: 2038-10-16
Also published as: CN111064590B

Abstract

The application discloses a method and a device for repairing an abnormal state and a readable storage medium, and relates to the technical field of computers. The method comprises the following steps: starting an application process of a target application program; monitoring the running state of the application process through a daemon process; when the application process is in an abnormal state, generating an abnormal report through a daemon process; sending an exception report to a server; and receiving the target repair component sent by the server. The operating state of the application process is monitored by setting the daemon process which is independent and parallel to the application process, and the daemon process and the application process are independent from each other, namely the daemon process cannot be abnormal according to the abnormal state of the application process, so that even if the application process is in the abnormal state, the daemon process can normally monitor the operating state of the application process, monitor that the application process is in the abnormal state, generate an abnormal report and send the abnormal report to a server to repair the abnormal state.

Description

Abnormal state repairing method and device and readable storage medium

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a method and a device for repairing an abnormal state and a readable medium.

Background

In the process of using an application installed in a terminal by a user, the application is often in an abnormal state (such as stuck, crashed, flash back, black screen, and the like) due to a bug (english: bug) of the application itself, and in order to optimize the use experience of the user on the application, a developer needs to repair the bug after acquiring relevant information of the bug from the terminal, so as to reduce the occurrence of the abnormal state.

In the related art, a detection thread is provided in an application process of an application program, the detection thread sends a detection message to a host process of the application process, and the host process monitors whether the application process is in an abnormal state according to a reply message of the detection message. And if the bug is in the abnormal state, collecting related information of the abnormal state, uploading the related information to the server, and repairing the bug by the developer according to the related information.

However, when the application process of the application program is in an abnormal state, the resources allocated to the application process are occupied and cannot be released to the detection thread to run, that is, the detection thread cannot be allocated with resources to perform state detection, and the detection thread in the application process is also in an abnormal state, so that the detection thread cannot collect information related to the abnormal state, and the abnormal state detection fails.

Disclosure of Invention

The embodiment of the application provides a method and a device for repairing an abnormal state and a readable storage medium, which can solve the problem that detection of the abnormal state fails because a detection thread cannot normally send a detection message to an application process or collect related information of the abnormal state when the detection thread is in the abnormal state. The technical scheme is as follows:

in one aspect, a method for repairing an abnormal state is provided, and the method includes:

starting an application process of a target application program;

monitoring the running state of the application process through a daemon process, wherein the daemon process and the application process are two independent and parallel processes running in a terminal, the running state comprises an abnormal state or a normal state, a first account is logged in the application process, and a second account related to the first account is logged in the daemon process;

when the application process is in the abnormal state, acquiring abnormal information corresponding to the abnormal state through the daemon process;

generating an exception report according to the exception information through the daemon process, wherein the exception report is used for indicating that a target component in the application process causes the exception state in the running process;

sending the abnormal report to a server by adopting the second account through the daemon process, or sending the abnormal report to the server by adopting the first account through the application process;

receiving a target repair component sent by the server, wherein the target repair component is used for repairing the abnormal state by replacing the target component in the application process.

In another aspect, there is provided an apparatus for repairing an abnormal state, the apparatus including:

the starting module is used for starting the application process of the target application program;

the monitoring module is used for monitoring the running state of the application process through a daemon process, the daemon process and the application process are two independent and parallel processes running in a terminal, the running state comprises an abnormal state or a normal state, a first account is logged in the application process, and a second account related to the first account is logged in the daemon process;

the acquisition module is used for acquiring abnormal information corresponding to the abnormal state through the daemon process when the application process is in the abnormal state;

the generating module is used for generating an exception report according to the exception information through the daemon process, wherein the exception report is used for indicating that a target component in the application process causes the exception state in the running process;

a sending module, configured to send the exception report to a server through the daemon process by using the second account, or send the exception report to the server through the application process by using the first account;

a receiving module, configured to receive a target repair component sent by the server, where the target repair component is configured to repair the abnormal state by replacing the target component in the application process.

In another aspect, a terminal is provided, where the terminal includes a processor and a memory, where the memory stores at least one instruction, at least one program, a code set, or a set of instructions, and the at least one instruction, the at least one program, the code set, or the set of instructions is loaded and executed by the processor to implement the method for repairing an abnormal state according to the embodiment of the present application.

In another aspect, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a set of codes, or a set of instructions is stored, and the at least one instruction, the at least one program, the set of codes, or the set of instructions is loaded and executed by the processor to implement the method for repairing an abnormal state according to the embodiment of the present application.

In another aspect, a computer program product is provided, which when running on a computer, causes the computer to execute the method for repairing an abnormal state as described in the embodiments of the present application.

The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:

the operating state of the application process is monitored by setting the daemon process which is independent and parallel to the application process, and the daemon process and the application process are independent from each other, namely the daemon process cannot be abnormal according to the abnormal state of the application process, so that even if the application process is in the abnormal state, the daemon process can normally monitor the operating state of the application process, monitor that the application process is in the abnormal state, generate an abnormal report and send the abnormal report to a server to repair the abnormal state. The problem that the abnormal state cannot be repaired due to the fact that the detection thread in the application process cannot continue to detect along with the abnormal state of the application thread is solved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic diagram of an implementation environment of a method for repairing an abnormal state according to an exemplary embodiment of the present application;

FIG. 2 is a flow chart of a method for repairing an abnormal condition provided by an exemplary embodiment of the present application;

FIG. 3 is a flow chart of a method for repairing an abnormal condition provided by another exemplary embodiment of the present application;

FIG. 4 is a schematic diagram of information flow delivery provided by the present application based on the embodiment shown in FIG. 3;

FIG. 5 is a flow chart of a method for repairing an abnormal condition as provided by another exemplary embodiment of the present application;

FIG. 6 is an interface schematic diagram of a prompt interface provided by the present application based on the embodiment shown in FIG. 5;

FIG. 7 is a flow chart of a method for repairing an abnormal condition as provided by another exemplary embodiment of the present application;

FIG. 8 is a block diagram of an apparatus for repairing an abnormal condition according to an exemplary embodiment of the present application;

fig. 9 is a block diagram of a device for repairing an abnormal state according to another exemplary embodiment of the present application;

fig. 10 is a block diagram of a terminal according to an exemplary embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

First, terms referred to in the embodiments of the present application are briefly described:

and (3) application process: refers to an activity of supporting the running of a target application when the target application runs in a terminal. Optionally, the target application further includes a function module, the function in the target application is implemented by the function module through code logic, different functions are implemented by different function modules through different code logic, and the granularity of division of the function module can be controlled by a developer, for example: in the target application program, the sending function and the receiving function can be realized by the sending module and the receiving module respectively through code logic, or can be realized by the communication module through the code logic in a unified way. The functional module can be implemented as a component in an application process, that is, the component is a functional module in a running state. Illustratively, the application a includes a function module a, a function module b, and a function module c, where the function module a is a module corresponding to receiving and sending a message, and the function module b is a module corresponding to information setting, and when the application a receives a message, a component corresponding to the function module a is operated to receive the message.

And (3) daemon process: refers to a kind of process running in the background of the terminal for executing the management task. Optionally, in this embodiment of the present application, the daemon process is a process that is set for the target application program and is used for monitoring the running state of the target application program. Optionally, the operational state includes an abnormal state or a normal state. Optionally, the daemon process is a process that is started when the target application program is installed in the terminal, and the daemon process does not stop running along with the stop of the application process of the target application program, that is, the daemon process is a process that continuously runs in a terminal background, when a power supply of the terminal is turned off, the daemon process stops running along with the turn-off of the terminal, and when the power supply of the terminal is powered on, the daemon process starts up automatically or starts along with the start of the application process when the application process is started; or, the daemon process is started along with the starting of the application process and is stopped along with the stopping of the application process.

Abnormal state: the running state of the application process of the target application program is different from the normal running state in the running process, and optionally, the abnormal state includes but is not limited to at least one of a stuck state, a crash state, a flash back state and a black screen state. The blocking state refers to a state that the application process cannot complete a task corresponding to an operation instruction when the terminal receives the operation instruction aiming at the target application program in the operation process of the application process; the crash state refers to a state in which the operation of the application process causes the operation error of the terminal operating system and any instruction for the operating system cannot be completed; the flash quit state is a state after the application process does not receive a termination instruction in the running process and terminates the running; the black screen state refers to a state that the display screen of the terminal cannot display the display content corresponding to the application process and presents a black screen in the running process of the application process.

Optionally, in the embodiment of the present application, a stuck state is mainly taken as an example for description.

Referring to fig. 1, an implementation environment in the embodiment of the present application is described with reference to the above noun introduction and application scenarios, where the implementation environment includes a terminal 11 and a server 12.

An operating system 110 and an enterprise client 120 are installed in the terminal 11, an application process 111 runs in the operating system 110, the application process 111 is a carrier when the enterprise client 120 runs, a daemon process 112 also runs in the operating system 110, and the daemon process 112 is used for monitoring the running state of the application process 111 and sending an exception report to the server 12 when the application process 111 is in an exception state.

Optionally, in this embodiment, the example that the enterprise client 120 is installed in the terminal 11 is taken as an example for description, and the enterprise client 120 may also be implemented as another client, which is not limited in this embodiment of the present application.

Alternatively, the terminal 11 sends the abnormality report to the server 12 through a communication network, which may be a wired network or a wireless network.

Optionally, a Client-Server (CS) connection and a HyperText Transfer Protocol (HTTP) connection are established between the daemon 112 and the Server 12, when the CS connection is established between the daemon 112 and the Server 12, the daemon 112 may send a message (e.g., an exception report) to the Server 12 through the CS Protocol, and the Server 12 may send a message or a component (e.g., a target repair component) to the daemon 112 through the Server-Client (SC) Protocol. Optionally, an HTTP connection is also established between the daemon 112 and the server 12, and when the daemon 112 needs to send content in the form of a file to the server 12, the content in the form of the file (e.g., exception information) is sent to the server 12 by using an HTTP protocol as a transmission protocol through the HTTP connection.

Optionally, a long connection is established between the application process 111 and the server 12, where the long connection means that the application process 111 can send the content to be sent to the server 12 multiple times without performing communication authentication again with the server 12 after performing communication authentication with the server 12 once. Alternatively, when it is intercepted that the daemon 112 transmits the exception information through the HTTP protocol, the exception information may be transmitted through a long connection established between the application process 111 and the server. Optionally, other connection manners may also be established between the application process 111 and the server 12, and in this embodiment, the connection manner established between the application process 111 and the server 12 is not limited.

Alternatively, the number of the terminals 11 in fig. 1 is illustrated as 1, and in actual operation, the number of the terminals 11 may be more.

Optionally, the server 12 may be an independent server or a group of servers, and the server 12 may be a physical server or a cloud server, which is not limited in this embodiment of the application.

With reference to the foregoing implementation environment and the introduction of noun, a method for repairing an abnormal state in the embodiment of the present application is described, as shown in fig. 2, by taking an example that the method is applied to the terminal 11 shown in fig. 1, and the method includes:

step 201, starting an application process of a target application program.

Alternatively, the target application may be at least one of an enterprise application, a video application, an instant messaging application, a shopping application, a financial application, a navigation application, and a gaming application.

Optionally, the application process is a carrier of the target application program when running in the terminal, that is, the running of the target application program is realized by running the application process in the terminal.

Optionally, after the user selects the icon of the target application program in the display screen, the terminal receives the selection signal and runs the target application program according to the selection signal, that is, starts the application process of the target application program.

Step 202, monitoring the running state of the application process through the daemon process.

Optionally, the daemon process and the application process are two independent and parallel processes running in the terminal, that is, the daemon process does not change correspondingly according to the change of the running state of the application process. Illustratively, when the application process is in an abnormal state during running in the terminal, the daemon process can still run in a normal running state.

Optionally, a first account is logged in the application process, and a second account associated with the first account is logged in the daemon process.

Optionally, the daemon process is a process started when the target application program is installed in the terminal; or, when the daemon process is used for updating the version of the target application program, a starting process is added in the terminal; or, the daemon process is a process which is installed in the terminal for long-term running through the application process of the target application program when the target application program runs. That is, the daemon process is a process carried by the target application program and used for monitoring the application process in the terminal.

Optionally, the running state includes a normal state or an abnormal state, where the normal state and the abnormal state are two parallel states, that is, the application process may be in the normal state or in the abnormal state during the running process.

Optionally, when the daemon process monitors the running state of the application process, at least one of the following modes is included:

firstly, a detection message is periodically sent to an application process through a daemon process, the detection message is used for indicating the application process to reply a response message to the daemon process, the response message is used for indicating that the application process is not in an abnormal state, and when the daemon process does not receive the response message within a preset time length, the application process is determined to be in the abnormal state. Optionally, the daemon process sending the detection message periodically means that the daemon process sends the detection message to the application process every preset time.

During execution, after the daemon is started in the terminal, the application process sends a window handle to the daemon, wherein the window handle is a window identifier which is set in an operating system and is used for operating a window, the daemon sends a detection message (SendMessageTimeout) with a blocking delay to the application process through the window handle, and when a response message sent by the application process is not received within the blocking delay, the application process is confirmed to be in an abnormal state.

Illustratively, the daemon sends a detection message to the application process, a 50ms blocking delay is set, the daemon sends the detection message to the application process every 100ms, the daemon sends a response message to the daemon after sending the detection message to the application process for the first time and sending the response message to the daemon after 10ms, the daemon determines that the application process is not in an abnormal state, the daemon sends the detection message to the application process for the second time after 100ms is separated from the first detection message sending, and the daemon determines that the application process is in the abnormal state if no response message is sent to the daemon within 50 ms. Optionally, the daemon process may also send the next detection message at an interval of 100ms after receiving the response message sent by the application process, which is not limited in this embodiment of the application.

Secondly, a heartbeat detection mechanism is set in the application process, the application process is set to send heartbeat detection messages to the daemon process every other preset time after being started, and when the time from the daemon process to the last time when the heartbeat detection message is received exceeds the preset time, the application process is determined to be in an abnormal state.

And 203, when the application process is in the abnormal state, acquiring abnormal information corresponding to the abnormal state through the daemon process.

Optionally, the daemon process calls an information obtaining thread and a Dynamic Link Library (DLL) to obtain the exception information corresponding to the exception state, and optionally, the information obtaining thread may be a thread provided by the system for obtaining system information.

Optionally, the exception information includes system information of the terminal and/or operation information of the target application program. Optionally, the anomaly information includes at least one of the following information: memory occupation information, Central Processing Unit (CPU) resource occupation information, Input/Output (IO) resource occupation information, version information of a target application program, stack information of an application process, and the like.

And step 204, generating an exception report according to the exception information through the daemon process.

Optionally, the exception report is used to instruct a target component in the application process to raise an exception state during running. Optionally, the target component is a component in the target application that runs when a function is called. Illustratively, the target application program is an enterprise client, and when a user applies a notification sending function in the enterprise client and the enterprise client is stuck, the exception report is used to indicate that a target component corresponding to the notification sending function in the application process causes an exception state in the running process.

Optionally, the manner in which the daemon generates the exception report includes any one of the following manners:

firstly, after acquiring abnormal information corresponding to the abnormal state, a daemon calculates a corresponding hash value according to the abnormal information to generate an abnormal report, wherein the abnormal report comprises the calculated hash value;

secondly, after acquiring the abnormal information corresponding to the abnormal state, the daemon generates an abnormal report including the abnormal information, such as: the exception information includes an exception identifier corresponding to the exception status, and the exception report includes the exception identifier.

And step 205, sending an exception report to the server by adopting the second account through the daemon process.

Optionally, the exception report may be sent by a daemon process, or may be sent by an application process.

Optionally, when the exception report is sent by the daemon process, the daemon process sends the exception report to the server by using the CS protocol.

Optionally, the daemon process logs in a second account, so that when the daemon process sends the exception report, the second account is used as a sending account to send the exception report to the server.

And step 206, sending an exception report to the server by the application process through the first account.

When an exception report is sent to the server by the application process, the exception report may be sent to the server over a long connection established by the application process with the server.

Optionally, regarding step 205 and step 206, since the application process is in an abnormal state, the daemon process may preferentially send the abnormal report by using the CS protocol as a communication protocol, and when the daemon process cannot send the abnormal report by using the CS protocol, for example: and when the CS connection fails, the abnormal report is sent by taking the long connection established between the application process and the server as a sending channel through the application process.

Optionally, since the application process is in an abnormal state, the application process needs to send the abnormal report when the application process is started next time; or when the application process stops the abnormal state, the abnormal report is sent by the application process. Such as: and after the application process is in the stuck state and the stuck state of the application process is stopped, sending an exception report to the server through the application process.

Optionally, the daemon process may also carry the abnormal information in an abnormal report and send the abnormal information to the server, and the server repairs the abnormal state through the abnormal information in the abnormal report; or the exception report is an exception identifier generated according to the exception information, the server may store a target repair component corresponding to the exception identifier, and the target repair component is sent to the terminal according to the exception identifier to repair the exception state.

Step 207, receiving the target repair component sent by the server.

The target component is used for replacing the target component in the application process to repair the abnormal state.

Optionally, the target repair component is configured to repair the abnormal state, where the target repair component may be obtained by repairing the target component according to the abnormal state on the basis of the target component, or may be obtained by editing a code of a function module corresponding to the target component again according to the abnormal state, that is, the target repair component may be considered as a brand-new component with respect to the target component.

Alternatively, the exception state may be an exception state that has been processed in the server, or may be an exception state that has not been processed in the server. When the abnormal state is the processed abnormal state in the server, the terminal receives a first target repairing component sent by the server, wherein the first target repairing component is a component which is stored in the server and corresponds to the abnormal report; when the abnormal state is an unprocessed abnormal state in the server, the server may repair the abnormal state according to the abnormal report, or may send an instruction message to the terminal to instruct the terminal to send abnormal information to the server, and repair the abnormal state according to the abnormal information sent by the terminal to the server.

To sum up, in the abnormal state repairing method provided in the embodiment of the present application, the daemon process that is independent and parallel to the application process is set to monitor the running state of the application process, and since the daemon process and the application process are independent from each other, that is, the daemon process does not generate an abnormality according to the abnormal state of the application process, even if the application process is in the abnormal state, the daemon process can normally monitor the running state of the application process, monitor that the application process is in the abnormal state, and generate and send an abnormal report to the server to repair the abnormal state. The problem that the abnormal state cannot be repaired due to the fact that the detection thread in the application process cannot continue to detect along with the abnormal state of the application thread is solved.

In an optional embodiment, when the target component corresponding to the abnormal state is stored in the server, the target component may be directly acquired from the server according to the abnormal information for replacement. As shown in fig. 3, fig. 3 is a method for repairing an abnormal state according to another exemplary embodiment of the present application, which is described by taking an application of the method in the terminal 11 shown in fig. 1 as an example, and includes:

step 301, the terminal starts an application process of the target application program.

Step 302, the terminal monitors the running state of the application process through the daemon process.

firstly, a detection message is periodically sent to an application process through a daemon process, the detection message is used for indicating the application process to reply a response message to the daemon process, the response message is used for indicating that the application process is not in an abnormal state, and when the daemon process does not receive the response message within a preset time length, the application process is determined to be in the abnormal state.

Step 303, when the application process is in the abnormal state, the terminal acquires abnormal information corresponding to the abnormal state through the daemon process.

And step 304, the terminal calculates the hash value corresponding to the abnormal information through the daemon process.

Alternatively, the daemon process may calculate the hash value only by some item of the exception information, such as: calculating a hash value through stack information of an application process; or after the values of all items in the abnormal information are connected in sequence, the hash value is calculated, for example: if the memory usage is 35%, the CPU usage is 12%, and the IO usage is 18%, a hash value is calculated for the string 351218.

Optionally, when the hash value is calculated by using the anomaly information, any one of the following calculation methods is included: message Digest (MD 5) Algorithm, Secure Hash Algorithm (SHA), and the like.

The operation process of the MD5 algorithm is briefly introduced as follows: grouping the abnormal information by 512 bits, dividing each group into 16 32-bit sub-groups, processing the divided groups and sub-groups to obtain 4 32-bit groups, and cascading the 4 32-bit groups to generate a 128-bit hash value which is the hash value; the SHA algorithm is further divided into SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512, and the operation logic applied by different SHA algorithms is different.

And 305, generating an exception report by the terminal through a daemon process.

Optionally, the exception report includes the hash value obtained by the above calculation.

And step 306, sending an exception report to the server by adopting the second account through the daemon process.

Step 307, sending an exception report to the server by the application process through the first account.

Optionally, regarding step 306 and step 307, since the application process is in an abnormal state, the daemon process may preferentially send the abnormal report by using the CS protocol as a communication protocol, and when the daemon process cannot send the abnormal report by using the CS protocol, for example: and when the CS connection fails, the abnormal report is sent by taking the long connection established between the application process and the server as a sending channel through the application process.

Optionally, the steps 306 and 307 are executed alternatively, that is, the step 306 is executed or the step 307 is executed, and when the step 306 is failed to be executed, the step 307 may be executed continuously.

Optionally, since the application process is in an abnormal state, the application process may send the abnormal report when the application process is started next time; or when the application process stops the abnormal state, the abnormal report is sent by the application process. Such as: and after the application process is in the stuck state and the stuck state of the application process is stopped, sending an exception report to the server through the application process.

In step 308, the server determines whether a first target repair component corresponding to the hash value is stored.

Optionally, the server stores a corresponding relationship between the repaired repair component and the hash value, and determines whether a target repair component corresponding to the received hash value is stored in the server according to the received hash value and the corresponding relationship between the stored hash value and the repair component.

Illustratively, the correspondence between the repaired repair component stored in the server and the hash value is shown in the following table one, where the repair component includes a component identifier, and the repair component is represented by the component identifier in the table one:

watch 1

Serial number	Hash value	Repair component identification
			1	56468155 64615645	001
2	23151515 69716667	002
			3	14664489	003

Illustratively, if the hash value received by the server is "2315151569716667", the server obtains the repair component corresponding to the hash value as "002" according to the first table, and the server determines that the first target repair component corresponding to the hash value has been stored.

Optionally, when the hash value does not store the corresponding target repair component in the server, the server repairs the target component according to the abnormal information to obtain the target repair component, and then stores the target repair component and the hash value in a corresponding manner, and when an abnormal state identical to the hash value occurs in the target application program of another terminal, the server may directly send the target repair component to the another terminal.

Step 309, when the first target repairing component corresponding to the hash value is stored in the server, the server sends the first target repairing component to the terminal.

Alternatively, the Server may transmit the first targeted remediation component to the terminal via a Server-Client (SC) protocol.

In step 310, the terminal receives the first target repair component sent by the server.

The first target repair component is used for replacing a target component in the application process to repair the abnormal state. Optionally, the terminal may receive the first target repair component through a daemon process, and replace the target component in the application process.

And 311, when the first target repairing component corresponding to the hash value is not stored in the server, the server sends an indication message to the terminal.

Optionally, the indication message is used to instruct the terminal to send exception information to the server. Alternatively, the indication message may be expressed in the form of a value that the server and the target application have agreed to, such as: the indication message is "key 032", where 032 is a value agreed by the server and the target application program to indicate that the exception information is sent; it may also be expressed in the form of instructions, such as: the indication message is "key ═ msg", where msg is used to indicate anomaly information.

Alternatively, the server may transmit the indication message to the terminal through the SC protocol.

In step 312, the terminal receives the indication message sent by the server.

Optionally, the terminal may receive the indication message through a daemon process.

And 313, the terminal sends abnormal information to the server by adopting the second account according to the indication message through the daemon process, or the terminal sends the abnormal information to the server by adopting the first account according to the indication message through the application process.

Optionally, the exception information is sent to the server in an exception file.

Firstly, when a terminal sends abnormal information to a server through a daemon process, the daemon process takes an HTTP protocol as a communication protocol to upload the abnormal information to the server. Optionally, a first account is logged in the application process, and a second account associated with the first account is logged in the daemon process. And when the abnormal information is uploaded by the daemon process by taking the second account as the sending account, the second account is used for completing login state verification in the server.

Optionally, the server is further configured to store the abnormal information in an account directory corresponding to the sending account according to the sending account corresponding to the received abnormal information.

Optionally, when the terminal sends the abnormal information to the server through the daemon process, the terminal additionally sends login state information, where the login state information includes account information logged in the daemon process, a timestamp, and a login ticket, where the account information mainly refers to an account identifier of the second account, the timestamp mainly refers to a time when the daemon process sends the abnormal information, and the login ticket mainly proves that the account logged in the daemon process is the second account.

Illustratively, a first account logged in an application process is "abc", a second account logged in a daemon process is "def", the second account and the first account are binding accounts, when a server receives abnormal information sent by the daemon process, it is first checked whether an account sending the abnormal information is a second account associated with a first account corresponding to a stored application process, that is, the server reads that an account sending the abnormal information is "def", and the association relationship between the stored first account and the second account includes the association relationship between the first account "abc" and the second account ", and then the second account is considered to complete login state verification.

Secondly, when uploading abnormal information is intercepted by taking the HTTP as a communication protocol through the daemon process, the abnormal information is uploaded to the server by taking a long connection established between the application process and the server as a communication channel through the application process. When the terminal is in the enterprise network, that is, the local area network connected to the terminal is the enterprise network, the enterprise network generally intercepts the HTTP request to prevent the leakage of the important files transmitted through the enterprise network.

That is, the terminal preferentially uploads the abnormal information by using the HTTP protocol as the communication protocol through the daemon process, and when the abnormal information cannot be uploaded in this manner, the abnormal information is uploaded by using the application process through the long connection established between the application process and the server.

Optionally, in the mode of uploading the abnormal information by the daemon process and the mode of uploading the abnormal information by the application process, the servers receiving the abnormal information may be different, and after the different servers receive the abnormal information, the abnormal information is sent to the storage server for aggregation. Illustratively, the abnormal information is uploaded to the enterprise file storage server through the daemon process, the enterprise file storage server sends the received abnormal information to the storage server for storage, the abnormal information is uploaded to the client storage server through the application process, and the client storage server sends the received abnormal information to the storage server for storage.

In step 314, the server sends the second target repair component to the terminal.

Optionally, the second target repair component is a component after repairing the abnormal state according to the abnormal information.

In step 315, the terminal receives the second target repair component sent by the server.

The second target repair component is used for replacing the target component in the application process to repair the abnormal state.

According to the method provided by the embodiment, the hash value is calculated through the abnormal information, the hash value is sent to the server, when the first target repairing component corresponding to the hash value is stored in the server, the first target repairing component is directly sent to the terminal to replace the target component, the abnormal state can be repaired through the hash value without repairing the abnormal state according to the abnormal information, namely, the same abnormal state which occurs already can be identified through the hash value, the first target repairing component is directly provided for the terminal, and the efficiency of repairing the abnormal state is improved.

According to the method provided by the embodiment, the HTTP connection between the daemon process and the server is preferentially established to send the abnormal information, so that the problem that the abnormal information cannot be sent through the application process when the application process is in an abnormal state is solved, the daemon process is logged with the second account, the second account is used for log-in state verification in the server, and data stored in the server is prevented from being maliciously acquired.

In an exemplary embodiment, as shown in FIG. 4, enterprise client 40 is running daemon 41 and application 42, respectively. The daemon process 41 detects whether the application process 42 is in an abnormal state by sending a detection message to the application process 42, and the application process 42 is configured to send a response message to the daemon process 41 to indicate that the application process 42 is not in the abnormal state. Alternatively, when the application process 42 does not send a response message to the daemon 41, then the application process 42 is in an abnormal state. When the application process 42 is in an abnormal state, the daemon process 41 analyzes the stack information of the application process 42, calculates a hash value, and uploads the hash value to the enterprise client server 43 through a CS protocol; when the corresponding relation of the target repair module corresponding to the hash value is not stored in the enterprise client server 43, an indication message is replied to the daemon process, the daemon process 41 uploads the abnormal information to the enterprise file storage server 44 through an HTTP request according to the indication message, and when the HTTP request is intercepted, the abnormal information is uploaded to the client storage server 45 through the application process 42 in a long connection manner; alternatively, both the enterprise file storage server 44 and the client storage server 45 may send the received exception information to a storage server 46 for aggregating the exception information. When uploading the abnormal information through the HTTP request, the daemon 41 receives the target repair component sent by the enterprise file storage server 44, and replaces the target component in the application process; when uploading the abnormal information through the long connection, the daemon 41 receives the target repair component sent by the client storage server 45 and replaces the target component in the application process.

In an optional embodiment, the daemon process may further read an operation received by the terminal before the abnormal state occurs, and when receiving the operation again, prompt the user that the abnormal state may occur. Fig. 5 is a method for repairing an abnormal state according to another exemplary embodiment of the present application, and as shown in fig. 5, the method is described as applied to the terminal 11 shown in fig. 1, and includes:

step 501, an application process of a target application program is started.

Step 502, monitoring the running state of the application process through the daemon process.

Step 503, recording the operation for the application process received by the terminal through the application process.

Alternatively, the receipt of the application process record for the operation of the application process may be ongoing. Illustratively, the operation on the application process includes at least one of the following operations: clicking a button, dragging a file, dragging a window, opening an audio function, opening a video function, and the like. Wherein, clicking the button can also mark the identifier of the clicked button, dragging the window can also mark the identifier of the dragged window, opening the window can also mark the identifier of the opened window, such as: click on button a.

Step 504, when the application process is in the abnormal state, a recorded operation before the abnormal state occurs is read through the daemon process.

Optionally, after the application process has an abnormal state, the application process sends a recorded operation before the abnormal state occurs to the daemon process, and optionally, the recorded operation may be the latest recorded operation or any one of the recorded at least two operations.

Optionally, the daemon process records the operation in a preset file, where the preset file is a number file corresponding to the first account logged in the application process.

Illustratively, the operations for the application process received by the terminal recorded by the application process are sequentially: and after the application program is in an abnormal state, the application program sends the recorded latest operation before the abnormal state, namely the click button D, to the daemon process for recording.

And 505, when the terminal receives the operation again, displaying a prompt interface.

Optionally, the prompt interface is used for performing early warning prompt on the abnormal state.

Optionally, at the time when the terminal receives the operation again, the abnormal state is stopped, that is, the application process is temporarily restored to the normal state, but since the abnormal state is not repaired, it cannot be confirmed that the abnormal state does not occur again, so that when the terminal receives the operation again, a prompt interface is displayed.

Referring to fig. 6, schematically, in a user interface 61 of a target application program, a terminal receives a click operation on a control 62, where the click operation causes an application process to be in a stuck state, and cannot continue to jump to an interface corresponding to the control 62, illustratively, as shown in a user interface 63, content in the user interface 63 is consistent with content in the user interface 61, and a prompt message of "no response" is prompted in the user interface 63, that is, the application process is indicated in the stuck state. When the user clicks the control 62 again after the card pause is ended, a prompt interface 64 is displayed, and a prompt message "whether the operation will cause the card pause and continue" is displayed in the prompt interface 64.

Step 506, when the application process is in the abnormal state, reading an operation sequence group recorded before the abnormal state occurs through the daemon process.

Optionally, after the application process has an abnormal state, the application process sends a recorded operation sequence group before the abnormal state occurs to the daemon process, and optionally, the recorded operation sequence group may be the last n recorded operations.

Optionally, the daemon process records the operation sequence group in a preset file, where the preset file is a number file corresponding to the first account logged in the application process.

Illustratively, the operations for the application process received by the terminal recorded by the application process are sequentially: and after the application program is in an abnormal state, the application program sends the recorded latest 3 operations before the abnormal state, namely 'dragging window B, dragging file C and clicking button D', to the daemon process for recording.

And step 507, when the terminal receives the operation sequence group again, displaying a prompt interface.

Optionally, at the time when the terminal receives the operation again, the abnormal state is stopped, that is, the application process is temporarily restored to the normal state, but since the abnormal state is not repaired, it cannot be confirmed that the abnormal state does not occur again, so when the terminal receives the operation sequence group again, a prompt interface is displayed, and occurrence of the same abnormal state due to the same operation is avoided.

And step 508, when the application process is in an abnormal state and is restored to a normal state, unloading the target component through the application process.

Optionally, after the application process is in the abnormal state, the target component may be uninstalled directly through the application process, or the target component may be uninstalled after the user is prompted and confirmed by the user.

Optionally, when the duration of the abnormal state exceeds a preset duration, uninstalling the target component after the application process is restored to a normal state; and/or, when the class of the abnormal state belongs to a target class, uninstalling the target component after the application process is restored to a normal state, illustratively, the target class includes: and flashing back and blank screen, and unloading the target assembly when the abnormal state is the blank screen state and the application process is recovered to the normal state.

Optionally, since the application process is in an abnormal state, the target component is uninstalled after the application process is restored to a normal state. Optionally, the restoring to the normal state refers to when the running state of the application process changes, and the abnormal state of the application process is not repaired yet, that is, the target component is not replaced by the target repair component yet.

Illustratively, in

steps

505 and 507, when the prompt interface is displayed, the prompt message may be limited to "the operation will cause a jam, whether the component is deleted" and when the user confirms the deletion, the target component is uninstalled.

That is, step 508 can be implemented after step 505 or step 507, or before step 505, when step 508 is implemented before step 505, and when the target component is uninstalled after step 508 is executed, then step 505 to step 507 need not be executed again.

It is worth noting that when the target component is uninstalled and the target repair component is not installed yet, and the user needs to apply the function corresponding to the target component, the target component may be forcibly started in a manner of configuring a command line parameter, or the function corresponding to the recorded operation that may cause an abnormal state may be deleted in a manner of cleaning the local number file, so as to forcibly start the target component.

Step 509, receiving the target repair component sent by the server.

It should be noted that the method in this embodiment may be implemented in combination with the above-described embodiments of fig. 2 and/or fig. 3, that is, the method for sending the exception report or the exception information to the server before the receiving server sends the target repair component may be implemented in the embodiment of fig. 5 by combining the embodiments of fig. 2 and/or fig. 3.

According to the method provided by the embodiment of the application, the operation aiming at the application process received by the terminal is recorded, and one or a group of operations before the abnormal state occurs are confirmed, when the terminal receives the one or the group of operations again, the prompt interface can be displayed to give an early warning prompt for the abnormal state, and the same abnormal state caused by the same reason can be avoided to a certain extent.

According to the method provided by the embodiment, the target component is unloaded after the abnormal state occurs, so that the phenomenon that the abnormal state occurs again due to the fact that the function corresponding to the target component is called again is avoided, and a user can normally use other functions of the target application program.

Fig. 7 is a flowchart of a method for repairing an abnormal state according to another exemplary embodiment of the present application, which is described by taking the abnormal state as katon as an example, and as shown in fig. 7, the method includes:

step 701, detecting whether the application process is in a stuck state through a daemon process.

Optionally, the application process may be an application process of an enterprise client, or may be an application process of another client. When the application process is not in the stuck state, the loop execution step 701 is executed continuously.

In step 702, when the application process is in a stuck state, stack information is collected.

Optionally, the stack information is current stack information of the target application.

Step 703, calculate the hash value.

Optionally, the hash value is calculated according to the stack information, and a specific calculation manner has been described in the step 304, which is not described herein again.

And step 704, uploading the hash value.

Step 705, when the hash value exists in the server, the terminal downloads the corresponding module for replacement.

Optionally, when a target repair module corresponding to the hash value exists in the server, the target repair module is downloaded to replace the target module.

In step 706, the card pause file is stored when the application process is in the pause state.

Optionally, the morton file is the morton information, and the morton file includes at least one of memory occupation information, CPU resource occupation information, IO resource occupation information, version information of the target application program, and stack information of the application process.

And step 707, uploading the morton file.

At step 708, when the application process is in the stuck state, the operation steps are recorded.

And step 709, displaying a prompt interface when the operation steps are repeated.

Optionally, the prompt interface is used for prompting the user that the operation step may cause the generation of an abnormal state, and/or the prompt interface is used for prompting the user to delete the module causing the stuck state.

In step 710, when the application process is in the stuck state, the module is unloaded.

Fig. 8 is a block diagram of a device for repairing an abnormal state according to an exemplary embodiment of the present application, and as shown in fig. 8, the device includes a starting module 81, a monitoring module 82, an obtaining module 83, a generating module 84, a sending module 85, and a receiving module 86;

a starting module 81 for starting an application process of the target application program;

a monitoring module 82, configured to monitor an operating state of the application process through a daemon process, where the daemon process and the application process are two independent and parallel processes running in a terminal, the operating state includes an abnormal state or a normal state, a first account is logged in the application process, and a second account associated with the first account is logged in the daemon process;

an obtaining module 83, configured to obtain, by the daemon, exception information corresponding to the exception state when the application process is in the exception state;

a generating module 84, configured to generate, by the daemon process, an exception report according to the exception information, where the exception report is used to indicate that a target component in the application process causes the exception state in a running process;

a sending module 85, configured to send the exception report to a server through the daemon process by using the second account, or send the exception report to the server through the application process by using the first account;

a receiving module 86, configured to receive a target repair component sent by the server, where the target repair component is configured to repair the abnormal state by replacing the target component in the application process.

In an alternative embodiment, the exception state is a processed exception state in the server;

the receiving module 86 is further configured to receive a first target repair component sent by the server, where the first target repair component is a component corresponding to the exception report and stored in the server.

In an alternative embodiment, as shown in fig. 9, the generating module 84 includes:

the calculation submodule 841 is configured to calculate, through the daemon process, a hash value corresponding to the abnormal information;

the generating module 84 is further configured to generate the exception report through the daemon process, where the exception report includes the hash value, and the first target repair component is a component that is stored in the server and corresponds to the hash value.

In an optional embodiment, the receiving module 86 is further configured to receive an indication message sent by the server, where the indication message is sent to the terminal when a repair component corresponding to the exception report is not stored in the server, and the indication message is used to instruct the terminal to send the exception information to the server;

the sending module 85 is further configured to send the abnormal information to the server through the daemon process by using the second account according to the indication message, or send the abnormal information to the server through the application process by using the first account according to the indication message;

the receiving module 86 is further configured to receive a second target repair component sent by the server according to the exception information, where the second target repair component is a component after the exception state is repaired according to the exception information.

In an optional embodiment, the sending module 85 is further configured to upload the abnormal information to the server through the daemon process by using a hypertext transfer protocol as a communication protocol and using the second account.

In an optional embodiment, the sending module 85 is further configured to, when uploading the abnormal information is intercepted by using the hypertext transfer protocol as a communication protocol through the daemon process, use a long connection established between the application process and the server as a communication channel through the application process, and upload the abnormal information to the server by using the first account.

In an optional embodiment, the monitoring module 82 is further configured to send, by the daemon process, a detection message to the application process periodically, where the detection message is used to instruct the application process to reply to the daemon process with a response message, and the response message is used to indicate that the application process is not in the abnormal state; and when the daemon process does not receive the response message within a preset time length, determining that the application process is in the abnormal state.

In an optional embodiment, the apparatus further comprises:

a recording module 87, configured to record, by the application process, an operation for the application process received by the terminal;

the display module 88 is configured to read, by the daemon, an operation recorded before the abnormal state occurs after the abnormal state occurs in the application process, and when the terminal receives the operation again, display a prompt interface, where the prompt interface is used to perform an early warning prompt on the abnormal state; or reading an operation sequence group recorded before the abnormal state occurs through the daemon process, and displaying the prompt interface when the terminal receives the operation sequence group again.

In an optional embodiment, the apparatus further comprises:

and the unloading module 89 is configured to unload the target component through the application process when the application process is in the abnormal state and is restored to the normal state.

To sum up, the abnormal state repairing apparatus provided in this embodiment of the present application monitors the running state of the application process by setting the daemon process that is independent and parallel to the application process, and since the daemon process is independent from the application process, that is, the daemon process does not generate an abnormality according to the abnormal state of the application process, even if the application process is in the abnormal state, the daemon process can normally monitor the running state of the application process, monitor that the application process is in the abnormal state, and generate and send an abnormal report to the server to repair the abnormal state, thereby avoiding a problem that the abnormal state cannot be repaired because a detection thread in the application process cannot continue to detect along with the abnormal state of the application thread.

Fig. 10 shows a block diagram of a terminal 1000 according to an exemplary embodiment of the present invention. The terminal 1000 can be: a smart phone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio layer iii, motion video Experts compression standard Audio layer 3), an MP4 player (Moving Picture Experts Group Audio layer IV, motion video Experts compression standard Audio layer 4), a notebook computer, or a desktop computer. Terminal 1000 can also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or the like by other names.

In general, terminal 1000 can include: a processor 1001 and a memory 1002.

Processor 1001 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and so forth. The processor 1001 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 1001 may also include a main processor and a coprocessor, where the main processor is a processor for processing data in an awake state, and is also referred to as a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 1001 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the display screen. In some embodiments, the processor 1001 may further include an AI (Artificial Intelligence) processor for processing a computing operation related to machine learning.

Memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in memory 1002 is used to store at least one instruction for execution by processor 1001 to implement a method of repairing an exception condition as provided by method embodiments herein.

In some embodiments, terminal 1000 can also optionally include: a peripheral interface 1003 and at least one peripheral. The processor 1001, memory 1002 and peripheral interface 1003 may be connected by a bus or signal line. Various peripheral devices may be connected to peripheral interface 1003 via a bus, signal line, or circuit board. Specifically, the peripheral device includes: at least one of radio frequency circuitry 1004, touch screen display 1005, camera 1006, audio circuitry 1007, positioning components 1008, and power supply 1009.

The peripheral interface 1003 may be used to connect at least one peripheral related to I/O (Input/Output) to the processor 1001 and the memory 1002. In some embodiments, processor 1001, memory 1002, and peripheral interface 1003 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1001, the memory 1002, and the peripheral interface 1003 may be implemented on separate chips or circuit boards, which are not limited by this embodiment.

The Radio Frequency circuit 1004 is used for receiving and transmitting RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuitry 1004 communicates with communication networks and other communication devices via electromagnetic signals. The radio frequency circuit 1004 converts an electrical signal into an electromagnetic signal to transmit, or converts a received electromagnetic signal into an electrical signal. Optionally, the radio frequency circuit 1004 comprises: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and so forth. The radio frequency circuit 1004 may communicate with other terminals via at least one wireless communication protocol. The wireless communication protocols include, but are not limited to: the world wide web, metropolitan area networks, intranets, generations of mobile communication networks (2G, 3G, 4G, and 5G), Wireless local area networks, and/or WiFi (Wireless Fidelity) networks. In some embodiments, the rf circuit 1004 may further include NFC (Near Field Communication) related circuits, which are not limited in this application.

The display screen 1005 is used to display a UI (user interface). The UI may include graphics, text, icons, video, and any combination thereof. When the display screen 1005 is a touch display screen, the display screen 1005 also has the ability to capture touch signals on or over the surface of the display screen 1005. The touch signal may be input to the processor 1001 as a control signal for processing. At this point, the display screen 1005 may also be used to provide virtual buttons and/or a virtual keyboard, also referred to as soft buttons and/or a soft keyboard. In some embodiments, display screen 1005 can be one, providing a front panel of terminal 1000; in other embodiments, display 1005 can be at least two, respectively disposed on different surfaces of terminal 1000 or in a folded design; in still other embodiments, display 1005 can be a flexible display disposed on a curved surface or on a folded surface of terminal 1000. Even more, the display screen 1005 may be arranged in a non-rectangular irregular figure, i.e., a shaped screen. The Display screen 1005 may be made of LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), and the like.

The camera assembly 1006 is used to capture images or video. Optionally, the camera assembly 1006 includes a front camera and a rear camera. Generally, a front camera is disposed at a front panel of the terminal, and a rear camera is disposed at a rear surface of the terminal. In some embodiments, the number of the rear cameras is at least two, and each rear camera is any one of a main camera, a depth-of-field camera, a wide-angle camera and a telephoto camera, so that the main camera and the depth-of-field camera are fused to realize a background blurring function, and the main camera and the wide-angle camera are fused to realize panoramic shooting and VR (Virtual Reality) shooting functions or other fusion shooting functions. In some embodiments, camera assembly 1006 may also include a flash. The flash lamp can be a monochrome temperature flash lamp or a bicolor temperature flash lamp. The double-color-temperature flash lamp is a combination of a warm-light flash lamp and a cold-light flash lamp, and can be used for light compensation at different color temperatures.

The audio circuit 1007 may include a microphone and a speaker. The microphone is used for collecting sound waves of a user and the environment, converting the sound waves into electric signals, and inputting the electric signals to the processor 1001 for processing or inputting the electric signals to the radio frequency circuit 1004 for realizing voice communication. For stereo sound collection or noise reduction purposes, multiple microphones can be provided, each at a different location of terminal 1000. The microphone may also be an array microphone or an omni-directional pick-up microphone. The speaker is used to convert electrical signals from the processor 1001 or the radio frequency circuit 1004 into sound waves. The loudspeaker can be a traditional film loudspeaker or a piezoelectric ceramic loudspeaker. When the speaker is a piezoelectric ceramic speaker, the speaker can be used for purposes such as converting an electric signal into a sound wave audible to a human being, or converting an electric signal into a sound wave inaudible to a human being to measure a distance. In some embodiments, the audio circuit 1007 may also include a headphone jack.

A location component 1008 is employed to locate a current geographic location of terminal 1000 for navigation or LBS (location based Service). The positioning component 1008 may be a positioning component based on the GPS (global positioning System) in the united states, the beidou System in china, or the galileo System in russia.

Power supply 1009 is used to supply power to various components in terminal 1000. The power source 1009 may be alternating current, direct current, disposable batteries, or rechargeable batteries. When the power source 1009 includes a rechargeable battery, the rechargeable battery may be a wired rechargeable battery or a wireless rechargeable battery. The wired rechargeable battery is a battery charged through a wired line, and the wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery may also be used to support fast charge technology.

In some embodiments, terminal 1000 can also include one or more sensors 1010. The one or more sensors 1010 include, but are not limited to: acceleration sensor 1011, gyro sensor 1012, pressure sensor 1013, fingerprint sensor 1014, optical sensor 1015, and proximity sensor 1016.

Acceleration sensor 1011 can detect acceleration magnitudes on three coordinate axes of a coordinate system established with terminal 1000. For example, the acceleration sensor 1011 may be used to detect components of the gravitational acceleration in three coordinate axes. The processor 1001 may control the touch display screen 1005 to display a user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 1011. The acceleration sensor 1011 may also be used for acquisition of motion data of a game or a user.

The gyro sensor 1012 may detect a body direction and a rotation angle of the terminal 1000, and the gyro sensor 1012 and the acceleration sensor 1011 may cooperate to acquire a 3D motion of the user on the terminal 1000. From the data collected by the gyro sensor 1012, the processor 1001 may implement the following functions: motion sensing (such as changing the UI according to a user's tilting operation), image stabilization at the time of photographing, game control, and inertial navigation.

Pressure sensor 1013 may be disposed on a side frame of terminal 1000 and/or on a lower layer of touch display 1005. When pressure sensor 1013 is disposed on a side frame of terminal 1000, a user's grip signal on terminal 1000 can be detected, and processor 1001 performs left-right hand recognition or shortcut operation according to the grip signal collected by pressure sensor 1013. When the pressure sensor 1013 is disposed at a lower layer of the touch display screen 1005, the processor 1001 controls the operability control on the UI interface according to the pressure operation of the user on the touch display screen 1005. The operability control comprises at least one of a button control, a scroll bar control, an icon control and a menu control.

The fingerprint sensor 1014 is used to collect a fingerprint of the user, and the processor 1001 identifies the user according to the fingerprint collected by the fingerprint sensor 1014, or the fingerprint sensor 1014 identifies the user according to the collected fingerprint. Upon identifying that the user's identity is a trusted identity, the processor 1001 authorizes the user to perform relevant sensitive operations including unlocking a screen, viewing encrypted information, downloading software, paying, and changing settings, etc. Fingerprint sensor 1014 can be disposed on the front, back, or side of terminal 1000. When a physical key or vendor Logo is provided on terminal 1000, fingerprint sensor 1014 can be integrated with the physical key or vendor Logo.

The optical sensor 1015 is used to collect the ambient light intensity. In one embodiment, the processor 1001 may control the display brightness of the touch display screen 1005 according to the intensity of the ambient light collected by the optical sensor 1015. Specifically, when the ambient light intensity is high, the display brightness of the touch display screen 1005 is increased; when the ambient light intensity is low, the display brightness of the touch display screen 1005 is turned down. In another embodiment, the processor 1001 may also dynamically adjust the shooting parameters of the camera assembly 1006 according to the intensity of the ambient light collected by the optical sensor 1015.

Proximity sensor 1016, also known as a distance sensor, is typically disposed on a front panel of terminal 1000. Proximity sensor 1016 is used to gather the distance between the user and the front face of terminal 1000. In one embodiment, when proximity sensor 1016 detects that the distance between the user and the front surface of terminal 1000 gradually decreases, processor 1001 controls touch display 1005 to switch from a bright screen state to a dark screen state; when proximity sensor 1016 detects that the distance between the user and the front of terminal 1000 is gradually increased, touch display screen 1005 is controlled by processor 1001 to switch from a breath-screen state to a bright-screen state.

Those skilled in the art will appreciate that the configuration shown in FIG. 10 is not intended to be limiting and that terminal 1000 can include more or fewer components than shown, or some components can be combined, or a different arrangement of components can be employed.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, which may be a computer readable storage medium contained in a memory of the above embodiments; or it may be a separate computer-readable storage medium not incorporated in the terminal. The computer readable storage medium has at least one instruction, at least one program, a set of codes, or a set of instructions stored therein, which is loaded and executed by the processor to implement the method for repairing an abnormal state described in the above embodiments.

Optionally, the computer-readable storage medium may include: a Read Only Memory (ROM), a Random Access Memory (RAM), a Solid State Drive (SSD), or an optical disc. The Random Access Memory may include a resistive Random Access Memory (ReRAM) and a Dynamic Random Access Memory (DRAM). The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method of repairing an abnormal condition, the method comprising:

starting an application process of a target application program;

2. The method of claim 1, wherein the exception state is a processed exception state in the server;

the receiving the target repair component sent by the server includes:

receiving a first target repair component sent by the server, wherein the first target repair component is a component which is stored in the server and corresponds to the exception report.

3. The method of claim 2, wherein generating, by the daemon, an exception report comprises:

calculating a hash value corresponding to the abnormal information through the daemon process;

and generating the exception report through the daemon process, wherein the exception report comprises the hash value, and the first target repair component is a component which is stored in the server and corresponds to the hash value.

4. The method of claim 1, wherein receiving the target repair component sent by the server comprises:

receiving an indication message sent by the server, wherein the indication message is sent to the terminal when a repair component corresponding to the abnormal report is not stored in the server, and the indication message is used for indicating the terminal to send the abnormal information to the server;

sending the abnormal information to the server by the daemon process according to the indication message by adopting the second account, or sending the abnormal information to the server by the application process according to the indication message by adopting the first account;

and receiving a second target repairing component sent by the server according to the abnormal information, wherein the second target repairing component is a component after the abnormal state is repaired according to the abnormal information.

5. The method according to claim 4, wherein the sending, by the daemon process, the exception information to the server using the second account according to the indication message comprises:

and uploading the abnormal information to the server by adopting the second account through the daemon process by taking a hypertext transfer protocol as a communication protocol.

6. The method according to claim 5, wherein the sending, by the application process, the exception information to the server using the first account according to the indication message includes:

when uploading the abnormal information is intercepted by the daemon process by taking the hypertext transfer protocol as a communication protocol, uploading the abnormal information to the server by adopting the first account by taking a long connection established between the application process and the server as a communication channel through the application process.

7. The method according to any one of claims 1 to 6, wherein the monitoring the running state of the application process by a daemon process comprises:

sending a detection message to the application process periodically through the daemon process, wherein the detection message is used for indicating the application process to reply a response message to the daemon process, and the response message is used for indicating that the application process is not in the abnormal state;

and when the daemon process does not receive the response message within a preset time length, determining that the application process is in the abnormal state.

8. The method according to any one of claims 1 to 6, wherein before replacing the target component in the application process with the target repair component, further comprising:

recording the operation aiming at the application process received by the terminal through the application process;

when the abnormal state occurs in the application process, reading an operation recorded before the abnormal state occurs through the daemon process, and when the terminal receives the operation again, displaying a prompt interface which is used for carrying out early warning prompt on the abnormal state; or reading an operation sequence group recorded before the abnormal state occurs through the daemon process, and displaying the prompt interface when the terminal receives the operation sequence group again.

9. The method of any of claims 1 to 6, further comprising:

and when the abnormal state occurs in the application process and the application process is recovered to the normal state, unloading the target assembly through the application process.

10. An abnormal state restoration apparatus, comprising:

11. The apparatus of claim 10, wherein the exception state is a processed exception state in the server;

the receiving module is further configured to receive a first target repair component sent by the server, where the first target repair component is a component corresponding to the exception report and stored in the server.

12. The apparatus of claim 11, wherein the generating module comprises:

the calculation submodule is used for calculating a hash value corresponding to the abnormal information through the daemon process;

the generating module is further configured to generate the exception report through the daemon process, where the exception report includes the hash value, and the first target repair component is a component corresponding to the hash value and stored in the server.

13. The apparatus according to claim 10, wherein the receiving module is further configured to receive an indication message sent by the server, where the indication message is sent to the terminal when a repair component corresponding to the exception report is not stored in the server, and the indication message is used to instruct the terminal to send the exception information to the server;

the sending module is further configured to send the abnormal information to the server through the daemon process by using the second account according to the indication message, or send the abnormal information to the server through the application process by using the first account according to the indication message;

the receiving module is further configured to receive a second target repair component sent by the server according to the exception information, where the second target repair component is a component after the exception state is repaired according to the exception information.

14. The apparatus according to claim 13, wherein the sending module is further configured to upload the exception information to the server through the daemon process by using a hypertext transfer protocol as a communication protocol using the second account.

15. A computer-readable storage medium having stored therein at least one instruction, at least one program, a set of codes, or a set of instructions, which is loaded and executed by a processor to implement a method of repairing an abnormal state according to any one of claims 1 to 9.