CN108255674A - Method and device for collecting process logs of multi-process browser and mobile terminal - Google Patents

Abstract

The embodiment of the application discloses a method and a device for collecting process logs of a multi-process browser and a mobile terminal, and relates to the technical field of browsers. The method comprises the following steps: the method comprises the steps that a first process of the browser creates a shared memory and a mutual exclusion lock, the first process sends a file descriptor and the mutual exclusion lock of the shared memory to at least one second process of the browser, the mutual exclusion lock is obtained and locked by the first process or a target second process in the at least one second process, a process log is written into the shared memory pointed by the file descriptor, and the process log in the shared memory is written into a log file by the first process so as to be uploaded to a server through the log file. According to the method and the device, the problem that process logs of the multi-process browser are difficult to collect and normal operation of the browser is affected is solved by means of mutual exclusion locks and a shared memory shared by multiple processes.

Description

Multi-process browser process log collection method, device and mobile terminal

technical field

The present application relates to the technical field of browsers, and more specifically, to a method, device and mobile terminal for collecting multi-process browser process logs.

Background technique

A mobile terminal, such as a mobile phone, has become one of the most commonly used consumer electronic products in people's daily life, and web browsing using a browser of the mobile terminal has become a basic requirement of most people. After the browser product is released, it is necessary to collect relevant process logs and upload them to the server for error analysis or crash analysis. However, for multi-process browsers, it is difficult to collect process logs and it is easy to affect the normal operation of the browser.

Contents of the invention

In view of the above problems, the present application proposes a multi-process browser process log collection method, device and mobile terminal to solve the problems of difficulty in collecting multi-process browser process logs and affecting normal operation of the browser.

In the first aspect, the embodiment of the present application provides a multi-process browser process log collection method, the method comprising: the first process of the browser creates a shared memory and a mutex; The file descriptor and the mutex are sent to at least one second process of the browser; the first process or the target second process in the at least one second process acquires the mutex and adds lock, write the process log into the shared memory pointed to by the file descriptor; the first process writes the process log in the shared memory into a log file, so as to upload to the server through the log file .

In the second aspect, the embodiment of the present application provides a multi-process browser process log collection device, the device includes: a creation module, used for the first process of the browser to create a shared memory and a mutual exclusion lock; a sending module, used for The first process sends the file descriptor of the shared memory and the mutex to at least one second process of the browser; a process log writing module is used for the first process or the at least A target second process in a second process acquires the mutex and locks it, and writes the process log into the shared memory pointed to by the file descriptor; the file writing module is used for the first process Writing the process log in the shared memory into a log file, so as to upload to the server through the log file.

In a third aspect, an embodiment of the present application provides a mobile terminal, which includes a display, a memory, and a processor, the display and the memory are coupled to the processor, the memory stores instructions, and when the instructions are executed by When the processor executes, the processor executes the above method.

In a fourth aspect, the embodiment of the present application provides a computer-readable storage medium having a program code executable by a processor, and the program code causes the processor to execute the above method.

In the multi-process browser process log collection method, device, and mobile terminal provided by the embodiment of the present application, first, the first process of the browser creates a shared memory and a mutex, and the first process sends the file descriptor and the mutex of the shared memory to at least one second process of the browser, and then the first process or the target second process in at least one second process acquires and locks the mutex, writes the process log into the shared memory pointed to by the file descriptor, and finally The first process writes the process log in the shared memory into a log file, and uploads it to the server through the log file, so as to solve the difficulty of collecting multi-process browser process logs and the problem of sharing a piece of shared memory by mutual exclusion locks and multiple processes. Problems that affect the normal operation of the browser.

These or other aspects of the present application will be more concise and understandable in the description of the following embodiments.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings that need to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, other drawings can also be obtained based on these drawings without any creative effort.

FIG. 1 shows a schematic flow diagram of a multi-process browser process log collection method provided by the first embodiment of the present application;

FIG. 2 shows a schematic flowchart of a method for collecting multi-process browser process logs provided in the second embodiment of the present application;

FIG. 3 shows a schematic flowchart of step S230 of the multi-process browser process log collection method provided by the second embodiment of the present application;

FIG. 4 shows a schematic flowchart of step S250 of the multi-process browser process log collection method provided by the second embodiment of the present application;

FIG. 5 shows a block diagram of a device for collecting multi-process browser process logs provided in the third embodiment of the present application;

FIG. 6 shows a block diagram of a device for collecting multi-process browser process logs provided by the fourth embodiment of the present application;

FIG. 7 shows a structural block diagram of a mobile terminal provided by an embodiment of the present application;

Fig. 8 shows a block diagram of a mobile terminal for executing the method for collecting multi-process browser process logs according to an embodiment of the present application.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the application with reference to the drawings in the embodiments of the application. Apparently, the described embodiments are only some of the embodiments of the application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of this application.

After a multi-process browser (such as chromium) is released (release), it is necessary to collect relevant process logs (log) and upload them to the server for error (bug) analysis or crash (crash) resolution, but the chromium browser uses Multi-process architecture, including multiple processes such as Browser process, Render process, and GPU process. Among them, the Render process cannot read and write files because it uses the sandbox mechanism. Therefore, the difficulty lies in how multiple processes write to a cache Inside to facilitate uploading to the server. A relatively easy implementation scheme, such as using ipc communication, sends the process log information to the Browser process through the Render process or GPU process through ipc communication. Although this method is easy to implement, it still takes up I/O processes , when there are many process logs, it will inevitably affect the normal operation of the browser. In view of the above problems, the inventor has studied for a long time, and proposed the multi-process browser process log collection method, device and mobile terminal provided by the embodiment of the present application, to solve the difficulty of collecting multi-process browser process logs and affecting the normal operation of the browser. As for the running problem, the specific method for collecting process logs of multi-process browsers will be described in detail in subsequent embodiments.

first embodiment

Please refer to FIG. 1 . FIG. 1 shows a schematic flowchart of a method for collecting multi-process browser process logs provided by the first embodiment of the present application. The method for collecting process logs of multi-process browsers aims to solve the problems of difficulty in collecting process logs of multi-process browsers and affecting the normal operation of browsers by means of mutual exclusion locks and sharing of a shared memory by multiple processes. In a specific embodiment, the multi-process browser process log collection method is applied to the multi-process browser process log collection device 200 as shown in Figure 5 and the mobile device configured with the multi-process browser process log collection device 200 Terminal 100 (FIG. 7). The following will take the mobile terminal as an example to illustrate the specific process of this embodiment. Of course, it can be understood that the mobile terminal applied in the embodiment of the present application can be a smart phone, a tablet computer, a wearable electronic terminal, etc., and is not limited here. . The process shown in Figure 1 will be described in detail below. The above-mentioned method for collecting process logs of multi-process browsers may specifically include the following steps:

Step S110: the first process of the browser creates a shared memory and a mutex.

In this embodiment, the browser is a multi-process browser, and the first process is a process with file writing capability, such as a Browser process and a GPU process, wherein the Browser process is the main process of the browser, The GPU process is an acceleration mechanism for system graphics, used to quickly form graphics composition and display, and is a separate process. It can be understood that when the browser starts, it first starts the Browser process, and then starts other processes such as the GPU. Therefore, as a way, the Browser process is used as the first process, on the one hand, it can ensure that the process of the browser when starting Logs can be written, and on the other hand, it can also avoid the problem that other process logs of the Render process cannot be written when the browser does not start the GPU process.

Further, when the first process of the browser is initialized, a shared memory (sharedMemory) and a mutual exclusion lock (Metex sharedMemory) are created, wherein the shared memory is used for each process to write a process log through this shared memory, and the Mutual exclusion locks are used to ensure the integrity of shared data operations. Each object corresponds to a tag that can be called a "mutual exclusion lock". This tag is used to ensure that only one thread can access the object at any time. .

Step S120: the first process sends the file descriptor of the shared memory and the mutex to at least one second process of the browser.

In this embodiment, the process that creates the shared memory and the mutex is defined as the first process, and the process that does not create the shared memory and the mutex is defined as the second process. It can be understood that The number of the first process is one, and the number of the second process is at least one. If the first process is a Browser process, the second process may include other processes such as a Render process and a GPU process.

Wherein, after the first process is started, the at least one second process is still in a non-started state, and when information that any one of the at least one second process is started is detected, the first process responds to the information and will The file descriptor of the shared memory and the mutex are sent to the second process and saved. Wherein, the file descriptor of the shared memory is sent to the second process, so that the second process can map the obtained file descriptor of the shared memory into the address space of the first process, and then the second process can access the second process. The shared memory created by a process.

As an implementation manner, the first process sends the file descriptor of the shared memory and the mutex to the at least one second process through inter-process communication ipc (Inter-Process Communication).

Step S130: The first process or the target second process in the at least one second process acquires and locks the mutex, and writes a process log into the shared memory pointed to by the file descriptor.

Further, when the first process or any second process has a process log output, then apply for the mutex, if the application is passed, then obtain the mutex and lock it, and then write the process log into the The shared memory pointed to by the file descriptor, wherein the file descriptor is used by the process to obtain the address space of the first process. Specifically, the first process or any second process can be understood as any process in the browser that saves the file descriptor and mutex of the shared memory. When any process has a process log to output , then apply for the mutex, wherein, when multiple processes all apply for the mutex, randomly assign the mutex to one of the processes for locking. It can be understood that after one of the processes acquires and locks the mutex, other processes cannot acquire the mutex until the process releases the mutex.

In this embodiment, the shared memory adopts a ring queue. As a method, when any target process in the first process or the second process acquires the mutex, check whether the shared memory is full Judgment, if the shared memory is not full, then continue to write the process log into the shared memory along the ring queue, if the shared memory is full, write the process log into the shared memory with ring coverage, thereby Avoid the problem of shared memory write overflow.

Step S140: the first process writes the process log in the shared memory into a log file, so as to upload to the server through the log file.

As a method, the first process may write the process log in the shared memory into a log file at a preset time interval, write the process log in the shared memory into the log file in real time, or Regularly write the process log in the shared memory into the log file, etc., which is not specifically limited in this embodiment, wherein the log file may be log.txt. It can be understood that the process log is written into the log file, which is convenient for uploading it to the server later. In this embodiment, because shared memory is used to write multi-process logs, no I/O pipelines are occupied, and the efficiency problem of process log writing is solved. At the same time, all processes share a shared memory, which ensures that process logs The output is orderly, and the shared memory adopts a circular queue, which effectively avoids the problem of shared memory write overflow.

In the multi-process browser process log collection method provided by the first embodiment of the present application, first, the first process of the browser creates a shared memory and a mutex, and the first process sends the file descriptor and the mutex of the shared memory to the browser At least one second process of the first process or at least one target second process in the second process acquires the mutex and locks it, writes the process log into the shared memory pointed to by the file descriptor, and finally the first process Write the process log in the shared memory to the log file, and upload it to the server through the log file, so as to solve the difficulty of collecting multi-process browser process logs and affect the browser through mutual exclusion lock and multi-process sharing of a shared memory Problems with normal operation.

second embodiment

Please refer to FIG. 2 , which shows a schematic flowchart of a method for collecting multi-process browser logs provided by the second embodiment of the present application. The mobile terminal will be taken as an example below to elaborate on the process shown in Figure 2. The method for collecting multi-process browser process logs may specifically include the following steps:

Step S210: the first process of the browser creates a shared memory and a mutex.

Step S220: the first process sends the file descriptor of the shared memory and the mutex to the at least one second process through ipc.

Step S230: the first process acquires and locks the mutex, and writes the first process log into the shared memory.

As an implementable manner, the first process first acquires and locks the mutex, and writes the first process log into the shared memory. It can be understood that, during the writing process of the first process log by the first process, the second process cannot acquire the mutex and cannot write to the second process log.

Please refer to FIG. 3 , which shows a schematic flowchart of step S230 of the method for collecting multi-process browser process logs provided by the second embodiment of the present application. The process shown in Figure 3 will be described in detail below, and the method may specifically include the following steps:

Step S231: the first process starts a first thread.

Specifically, the first process enables a new, independent first thread in the first process to write the log of the first process.

Step S232: the first thread acquires and locks the mutex, and writes the first process log into the shared memory.

Further, in the first thread, the mutex is acquired and locked by reading the mutex, and the first process log of the first process is written into the shared memory. Similarly, If the shared memory is full, the shared memory is overwritten circularly.

Step S240: After the first process finishes writing the first process log, release the mutex.

It can be understood that after the first process completes the writing of the first process log by locking, since it is no longer necessary to write the first process log, the mutex is released, so that the second Processes have the opportunity to acquire said mutex.

Step S250: the target second process acquires and locks the mutex, and writes the second process log into the shared memory.

Further, when the target second process has a second process log output, since the first process has released the mutex, the target second process can apply for and acquire the mutex and lock the second process. Process logs are written to said shared memory. Similarly, during the writing process of the second process log by the target second process, neither the first process nor any other second process can acquire the mutex, nor can it write the process log.

Please refer to FIG. 4 , which shows a schematic flowchart of step S250 of the method for collecting multi-process browser process logs provided by the second embodiment of the present application. The process shown in Figure 4 will be described in detail below, and the method may specifically include the following steps:

Step S251: The target second process starts a second thread.

Similarly, the target second process starts and starts a new, independent second thread in the target second process for writing the second process log.

Step S252: the second thread acquires the mutex and retrieves, and writes the second process log into the shared memory.

Further, in the second thread, the mutex is acquired and locked by reading the mutex, and the second process log of the second process is written into the shared memory. Similarly, If the shared memory is full, the shared memory is overwritten circularly.

It should be noted that the sequence between step S220-step S230 and step S240-step S250 is not limited in this embodiment, that is, step S220-step S230 can be set before step S240-step S250, or can be set before Step S240-after step S250.

Step S260: the target second process releases the mutex lock after finishing writing the second process log.

It can be understood that after the second process completes the writing of the second process log by locking, since it is no longer necessary to write the second process log, the mutex is released, so that the first process or other second process has the opportunity to acquire the mutex.

Step S270: The first process writes the process log in the shared memory into a log file, so as to upload to the server through the log file.

In the multi-process browser process log collection method provided by the second embodiment of the present application, the first process of the browser creates a shared memory and a mutex, and sends the file descriptor and the mutex of the shared memory to at least one second process, and then the first process and the target second process respectively acquire the mutex and complete the writing of the process log, and then write the process log in the shared memory into the log file through the first process, so as to upload it to the server through the log file, wherein , the scheme of shared memory plus mutex solves the efficiency problem of multi-process log writing, and ensures the orderliness of process log upload. Write overflow problem.

third embodiment

Please refer to Fig. 5, Fig. 5 has shown the module block diagram of the multi-process browser process log collection device 200 provided by the third embodiment of the present application, the module block diagram shown in Fig. 5 will be explained below, the multi-process browser The process log collection device 200 includes: a creation module 210, a sending module 220, a process log writing module 230 and a file writing module 240, wherein:

The creation module 210 is used for the first process of the browser to create a shared memory and a mutex.

The sending module 220 is used for the first process to send the file descriptor of the shared memory and the mutex to at least one second process of the browser.

The process log writing module 230 is used for the first process or the target second process in the at least one second process to acquire the mutex and lock it, and write the process log to the file descriptor pointed to of the shared memory.

The file writing module 240 is used for the first process to write the process log in the shared memory into a log file, so as to upload the log file to the server through the log file.

Fourth embodiment

Please refer to FIG. 6 , which shows a block diagram of a multi-process browser process log collection device 300 provided by the fourth embodiment of the present application. The module block diagram shown in Figure 6 will be described below, the multi-process browser log collection device 300 includes: a creation module 310, a sending module 320, a process log writing module 330 and a file writing module 340, wherein:

The creation module 310 is used for the first process of the browser to create a shared memory and a mutex.

The sending module 320 is used for the first process to send the file descriptor of the shared memory and the mutex to at least one second process of the browser. Further, the sending module 320 includes: a sending submodule 321, wherein:

The sending submodule 321 is used for the first process to send the file descriptor of the shared memory and the mutex to the at least one second process through ipc.

The process log writing module 330 is used for the first process or the target second process in the at least one second process to acquire the mutex and lock it, and write the process log to the file descriptor pointed to of the shared memory. Further, the process log writing module 330 includes: a mutex acquiring submodule 331, a judging submodule 332, an overlay submodule 333, a first process log writing submodule 334, and a first mutex releasing submodule 335 , the second process log writing submodule 336 and the second mutex release submodule 337, wherein:

The mutex acquiring submodule 331 is used for the first process or the target second process to acquire and lock the mutex.

The judging submodule 332 is configured to judge whether the shared memory is full.

The overlay submodule 333 is configured to, if the shared memory is full, overwrite the shared memory into the process log in a ring.

The first process log writing sub-module 334 is used for the first process to acquire and lock the mutex, and write the first process log into the shared memory. Further, the first process log writing submodule 334 includes: a first thread opening unit and a first process log writing unit, wherein:

A first thread starting unit, configured for the first process to start a first thread.

The first process log writing unit is used for the first thread to acquire and lock the mutex, and write the first process log into the shared memory.

The first mutex release submodule 335 is configured to release the mutex after the first process finishes writing the first process log.

The second process log writing sub-module 336 is used for the target second process to acquire and lock the mutex, and write the second process log into the shared memory. Further, the second process log writing submodule 336 includes:

The first thread start unit is used for the target second process to start a second thread.

The first process log writing unit is used for the second thread to acquire and retrieve the mutex, and write the second process log into the shared memory.

The second mutex release submodule 337 is configured to release the mutex after the target second process finishes writing the second process log.

The file writing module 340 is used for the first process to write the process log in the shared memory into a log file, so as to upload to the server through the log file.

fifth embodiment

The fifth embodiment of the present application provides a mobile terminal, which includes a display, a memory, and a processor, the display and the memory are coupled to the processor, the memory stores instructions, and when the instructions are executed by the When the processor executes said processor executes:

The first process of the browser creates shared memory and mutex;

The first process sends the file descriptor of the shared memory and the mutex to at least one second process of the browser;

The first process or the target second process in the at least one second process acquires the mutex and locks it, and writes a process log into the shared memory pointed to by the file descriptor;

The first process writes the process log in the shared memory into a log file, so as to upload to the server through the log file.

Sixth embodiment

The sixth embodiment of the present application provides a storage medium, which is a computer-readable storage medium having program code executable by a processor, and the program code causes the processor to execute:

The first process of the browser creates shared memory and mutex;

The first process sends the file descriptor of the shared memory and the mutex to at least one second process of the browser;

The first process or the target second process in the at least one second process acquires the mutex and locks it, and writes a process log into the shared memory pointed to by the file descriptor;

The first process writes the process log in the shared memory into a log file, so as to upload to the server through the log file.

To sum up, in the multi-process browser process log collection method, device, and mobile terminal provided by the embodiment of the present application, first, the first process of the browser creates a shared memory and a mutex, and the first process uses the file descriptor of the shared memory and the mutex are sent to at least one second process of the browser, and then the first process or the target second process in at least one second process acquires the mutex and locks it, and writes the process log to the file descriptor pointed to The shared memory, and finally the first process writes the process log in the shared memory into a log file, and uploads it to the server through the log file, so as to solve the problem of multi-process browsers by sharing a shared memory with mutual exclusion locks and multiple processes. Difficulties in collecting process logs and problems affecting the normal operation of the browser.

It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. For the same and similar parts in each embodiment, refer to each other, that is, Can. As for the device-type embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for related parts, please refer to part of the description of the method embodiments. Any of the processing methods described in the method embodiments can be implemented by corresponding processing modules in the device embodiments, and details will not be repeated in the device embodiments.

Please refer to FIG. 7 again. Based on the above-mentioned multi-process browser process log collection method and device, the embodiment of the present application also provides a mobile terminal 100, which includes an electronic body part 10, and the electronic body part 10 includes a housing 12 and The main display screen 120 arranged on the housing 12 . The housing 12 can be made of metal, such as steel or aluminum alloy. In this embodiment, the main display screen 120 generally includes a display panel 111 , and may also include a circuit for responding to a touch operation on the display panel 111 . The display panel 111 may be a liquid crystal display panel (Liquid Crystal Display, LCD), and in some embodiments, the display panel 111 is also a touch screen 109 .

Please refer to FIG. 8 at the same time. In an actual application scenario, the mobile terminal 100 can be used as a smartphone terminal. In this case, the electronic main body 10 usually includes one or more (only shown in the figure a) A processor 102 , a memory 104 , an RF (Radio Frequency, radio frequency) module 106 , an audio circuit 110 , a sensor 114 , an input module 118 , and a power module 122 . Those skilled in the art can understand that the structure shown in FIG. 8 is only a schematic diagram, which does not limit the structure of the electronic body part 10 . For example, the electronic body part 10 may also include more or fewer components than shown in FIG. 8 , or have a different configuration than that shown in FIG. 7 .

Those skilled in the art can understand that, relative to the processor 102 , all other components belong to peripherals, and the processor 102 is coupled to these peripherals through a plurality of peripheral interfaces 124 . The peripheral interface 124 can be implemented based on the following standards: Universal Asynchronous Receiver/Transmitter (UART), General Purpose Input Output (GPIO), Serial Peripheral Interface (Serial Peripheral Interface) , SPI), inter-integrated circuit (Inter-Integrated Circuit, I2C), but not limited to the above standards. In some examples, the peripheral interface 124 may only include a bus; in other examples, the peripheral interface 124 may also include other components, such as one or more controllers, for example for connecting the display panel 111 display controller or memory controller for connecting memory. In addition, these controllers can also be separated from the peripheral interface 124 and integrated in the processor 102 or corresponding peripherals.

The memory 104 can be used to store software programs and modules, and the processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104 . The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory that is remotely located relative to the processor 102 , and these remote memories may be connected to the electronic main body 10 or the main display 120 through a network. Examples of the aforementioned networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The RF module 106 is used to receive and send electromagnetic waves, realize mutual conversion between electromagnetic waves and electrical signals, and communicate with communication networks or other devices. The RF module 106 may include various existing circuit elements for performing these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption/decryption chips, Subscriber Identity Module (SIM) cards, memory, etc. . The RF module 106 can communicate with various networks such as the Internet, intranet, wireless network or communicate with other devices through the wireless network. The wireless network mentioned above may include a cellular telephone network, a wireless local area network or a metropolitan area network. The above-mentioned wireless network can use various communication standards, protocols and technologies, including but not limited to Global System for Mobile Communication (GSM), Enhanced Data GSM Environment (EDGE), wideband code Division multiple access technology (wideband code division multiple access, W-CDMA), code division multiple access technology (Code division access, CDMA), time division multiple access technology (time division multiple access, TDMA), wireless fidelity technology (Wireless, Fidelity, WiFi) (such as IEEE 802.10A, IEEE 802.11b, IEEE802.11g and/or IEEE 802.11n), VoIP (Voice over internet protocal, VoIP), Worldwide Interoperability for Microwave Access, Wi-Max), other protocols for mail, instant messaging, and short messages, and any other suitable communication protocols, even those that have not yet been developed.

The audio circuit 110 , the earpiece 101 , the sound jack 103 , and the microphone 105 jointly provide an audio interface between the user and the electronic main body 10 or the main display 120 . Specifically, the audio circuit 110 receives sound data from the processor 102 , converts the sound data into electrical signals, and transmits the electrical signals to the earpiece 101 . The earpiece 101 converts electrical signals into sound waves that can be heard by the human ear. The audio circuit 110 also receives electrical signals from the microphone 105, converts the electrical signals into sound data, and transmits the sound data to the processor 102 for further processing. Audio data may be retrieved from the memory 104 or through the RF module 106 . In addition, audio data can also be stored in the memory 104 or sent through the RF module 106 .

The sensor 114 is arranged in the electronic main body 10 or in the main display screen 120, examples of the sensor 114 include but not limited to: light sensor, running sensor, pressure sensor, gravity acceleration sensor, and other sensors .

Specifically, the light sensor may include a light sensor 114F and a pressure sensor 114G. Among them, the pressure sensor 114G may be a sensor for detecting pressure generated by pressing on the mobile terminal 100 . That is, the pressure sensor 114G detects pressure generated by contact or press between the user and the mobile terminal, eg, pressure generated by contact or press between the user's ear and the mobile terminal. Therefore, the pressure sensor 114G can be used to determine whether contact or pressure occurs between the user and the mobile terminal 100, and the magnitude of the pressure.

Please refer to FIG. 8 again. Specifically, in the embodiment shown in FIG. 8 , the light sensor 114F and the pressure sensor 114G are disposed adjacent to the display panel 111 . The light sensor 114F can turn off the display output of the processor 102 when an object is close to the main display screen 120 , for example, when the electronic main body 10 moves to the ear.

As a kind of motion sensor, the acceleration of gravity sensor can detect the magnitude of acceleration in various directions (generally three axes), and can detect the magnitude and direction of gravity when it is stationary, and can be used to identify the application of the posture of the mobile terminal 100 (such as horizontal and vertical Screen switching, related games, magnetometer attitude calibration), vibration recognition related functions (such as pedometer, tap), etc. In addition, the electronic main body 10 can also be equipped with other sensors such as gyroscope, barometer, hygrometer, thermometer, etc., which will not be repeated here.

In this embodiment, the input module 118 may include the touch screen 109 arranged on the main display screen 120, and the touch screen 109 may collect the user's touch operations on or near it (for example, the user uses a finger, a stylus) operation of any suitable object or accessory on the touch screen 109 or near the touch screen 109), and drive the corresponding connection device according to the preset program. Optionally, the touch screen 109 may include a touch detection device and a touch controller. Wherein, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, and The touch information is converted into touch point coordinates, and then sent to the processor 102, and can receive and execute commands sent by the processor 102. In addition, the touch detection function of the touch screen 109 can be realized by various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch screen 109 , in other modified implementation manners, the input module 118 may also include other input devices, such as keys 107 . The keys 107 may include, for example, character keys for inputting characters, and control keys for triggering control functions. Examples of the control buttons include a "return to main screen" button, a power on/off button, and the like.

The main display screen 120 is used to display information input by the user, information provided to the user, and various graphical user interfaces of the electronic main body 10. These graphical user interfaces can be composed of graphics, text, icons, numbers, video and Any combination thereof may be used. In one example, the touch screen 109 may be disposed on the display panel 111 so as to form an integral body with the display panel 111 .

The power module 122 is used to provide power supply to the processor 102 and other components. Specifically, the power module 122 may include a power management system, one or more power sources (such as batteries or alternating current), a charging circuit, a power failure detection circuit, an inverter, a power status indicator light, and any other components related to the electronic body. Part 10 or the components related to the generation, management and distribution of power in the main display screen 120 .

The mobile terminal 100 further includes a locator 119, and the locator 119 is used to determine the actual location of the mobile terminal 100. In this embodiment, the locator 119 uses a positioning service to realize the positioning of the mobile terminal 100. The positioning service should be understood as obtaining the position information (such as longitude and latitude coordinates) of the mobile terminal 100 through a specific positioning technology. ), a technology or service that marks the position of a positioned object on an electronic map.

It should be understood that the above-mentioned mobile terminal 100 is not limited to a smart phone terminal, but refers to a computer device that can be used on the move. Specifically, the mobile terminal 100 refers to a mobile computer device equipped with an intelligent operating system, and the mobile terminal 100 includes but is not limited to a smart phone, a smart watch, a tablet computer, and the like.

In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structure, material or characteristic is included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

In addition, the terms "first" and "second" are used for descriptive purposes only, and cannot be interpreted as indicating or implying relative importance or implicitly specifying the quantity of indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include at least one of these features. In the description of the present application, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

Any process or method descriptions in flowcharts or otherwise described herein may be understood to represent modules, segments or portions of code comprising one or more executable instructions for implementing specific logical functions or steps of the process , and the scope of preferred embodiments of the present application includes additional implementations in which functions may be performed out of the order shown or discussed, including in substantially simultaneous fashion or in reverse order depending on the functions involved, which shall It should be understood by those skilled in the art to which the embodiments of the present application belong.

The logic and/or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium, For use with instruction execution systems, devices, or devices (such as computer-based systems, systems including processors, or other systems that can fetch instructions from instruction execution systems, devices, or devices and execute instructions), or in conjunction with these instruction execution systems, devices or equipment used. For the purposes of this specification, a "computer-readable medium" may be any device that can contain, store, communicate, propagate or transmit a program for use in or in conjunction with an instruction execution system, device or device. More specific examples (non-exhaustive list) of computer readable media include the following: electrical connection with one or more wires (mobile terminal), portable computer disk case (magnetic device), random access memory (RAM), Read Only Memory (ROM), Erasable and Editable Read Only Memory (EPROM or Flash Memory), Fiber Optic Devices, and Portable Compact Disc Read Only Memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program can be printed, since the program can be read, for example, by optically scanning the paper or other medium, followed by editing, interpretation or other suitable processing if necessary. The program is processed electronically and stored in computer memory.

It should be understood that each part of the present application may be realized by hardware, software, firmware or a combination thereof. In the embodiments described above, various steps or methods may be implemented by software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques known in the art: Discrete logic circuits, ASICs with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

Those of ordinary skill in the art can understand that all or part of the steps carried by the methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. During execution, one or a combination of the steps of the method embodiments is included. In addition, each functional unit in each embodiment of the present application may be integrated into one processing module, each unit may exist separately physically, or two or more units may be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software function modules. If the integrated modules are realized in the form of software function modules and sold or used as independent products, they can also be stored in a computer-readable storage medium.

The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, and the like. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limitations on the present application, and those skilled in the art can make the above-mentioned The embodiments are subject to changes, modifications, substitutions and variations.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: it can still Modifications are made to the technical solutions described in the foregoing embodiments, or equivalent replacements are made to some of the technical features; and these modifications or replacements do not drive the essence of the corresponding technical solutions away from the spirit and scope of the technical solutions of the various embodiments of the present application.

Claims (10)

1. a kind of multi-process browser process log collecting method, which is characterized in that the method includes：

The the first process creation shared drive and mutual exclusion lock of browser；

The filec descriptor of the shared drive and the mutual exclusion lock are sent to the browser at least by first process One the second process；

The second process of target in first process or at least one second process obtains the mutual exclusion lock and locks, will The shared drive pointed by the filec descriptor is written in process daily record；

Journal file is written in the process daily record in the shared drive by first process, to pass through the journal file It is uploaded to server.

2. according to the method described in claim 1, it is characterized in that, in first process or at least one second process The second process of target obtain the mutual exclusion lock and lock, process daily record is written described common pointed by the filec descriptor Memory is enjoyed, including：

First process or the second process of the target obtain the mutual exclusion lock and lock；

It is full to judge whether the shared drive has been write；

If the shared drive has write full, the annular covering shared drive write-in process daily record.

3. according to the method described in claim 1, it is characterized in that, in first process or at least one second process The second process of target obtain the mutual exclusion lock and lock, process daily record is written described common pointed by the filec descriptor Memory is enjoyed, including：

First process obtains the mutual exclusion lock and locks, and the first process daily record is written the shared drive；

First process discharges the mutual exclusion lock after the write-in for completing the first process daily record；

Second process of target obtains the mutual exclusion lock and locks, and the second process daily record is written the shared drive；

Second process of target discharges the mutual exclusion lock after the write-in for completing the second process daily record.

It 4., will according to the method described in claim 3, it is characterized in that, first process obtains the mutual exclusion lock and locks The shared drive is written in first process daily record, including：

First process opens first thread；

The first thread obtains the mutual exclusion lock and locks, and the first process daily record is written the shared drive.

5. method according to claim 3 or 4, which is characterized in that second process of target obtains the mutual exclusion lock simultaneously It locks, the shared drive is written into the second process daily record, including：

Second process of target opens the second thread；

Second thread obtains the mutual exclusion lock and retrieves, and the second process daily record is written the shared drive.

6. according to the method described in claim 1, it is characterized in that, first process describes the file of the shared drive Symbol and the mutual exclusion lock are sent at least one second process of the browser, including：

The filec descriptor of the shared drive and the mutual exclusion lock are sent to described at least one by first process by ipc A second process.

7. according to the method described in claim 1, it is characterized in that, first process is Browser processes.

8. a kind of multi-process browser process log collection device, which is characterized in that described device includes：

Creation module, for the first process creation shared drive and mutual exclusion lock of browser；

The filec descriptor of the shared drive and the mutual exclusion lock are sent to described by sending module for first process At least one second process of browser；

Process daily record writing module obtains for the second process of target in first process or at least one second process It takes the mutual exclusion lock and locks, the shared drive pointed by the filec descriptor is written into process daily record；

For first process journal file is written in the process daily record in the shared drive by file writing module, To be uploaded to server by the journal file.

9. a kind of mobile terminal, which is characterized in that including display, memory and processor, the display and described deposit Reservoir is couple to the processor, the memory store instruction, the when executed by the processor processing Device performs such as claim 1-7 any one of them methods.

A kind of 10. computer read/write memory medium of program code that can perform with processor, which is characterized in that the journey Sequence code makes the processor perform such as claim 1-7 any one of them methods.