CN110515814B

CN110515814B - Method and device for collecting full log of iOS client and mobile terminal

Info

Publication number: CN110515814B
Application number: CN201910760798.2A
Authority: CN
Inventors: 王硕; 盛鑫
Original assignee: Hainan Chezhiyi Communication Information Technology Co ltd
Current assignee: Hainan Chezhiyi Communication Information Technology Co ltd
Priority date: 2019-08-16
Filing date: 2019-08-16
Publication date: 2023-09-19
Anticipated expiration: 2039-08-16
Also published as: CN110515814A

Abstract

The application discloses a full log collecting method of an iOS client, which is suitable for being executed in a mobile terminal, and comprises the following steps: creating an instance of a full log in a single instance mode in a starting function of a client, and redirecting an NSlog function of the client to a DDLog log function in an initialization process of the instance; when the NSlog log function is called, jumping to the DDLog log function, and obtaining log information of the client by using the DDlog log function; converting the acquired log information into a target log format, storing the target log format into a log array of a memory, and caching the target log format into a full log path of a local sandbox file when the stored log information exceeds a preset number; and reporting the cached log information to a server, and deleting the cached log information after the report is successful. The application also discloses a corresponding total log collecting device of the iOS client and a mobile terminal.

Description

Method and device for collecting full log of iOS client and mobile terminal

Technical Field

The present application relates to the field of computers and internet technologies, and in particular, to a method and an apparatus for collecting a full log of an iOS client, and a mobile terminal.

Background

The iOS applications can have problems such as crashes, stuck and weak networks during running, and the investigation of the reasons for the problems not only needs log information when the problems occur, but also needs more context log information to analyze. The current log method for recording the iOS client has an NSLog function of the iOS system, and a third-party open source library CocoaLumberjack log library.

The NSLog function may print log information into an apple log system (ASL) for display, in the process of which it is typically necessary to open a client connection with the ASL daemon and send a message. However, each thread must use a separate client connection, so each time the NSLog function is called, a new ASL client connection will be opened to send the message, resulting in a very complex flow.

The cocoaLumberjack log library is a third party log library developed based on Mac and iOS systems using the Objective-C language, which uses a large number of GCD grammars to perform better. However, the migration cost of the scheme is high, and the cost of manually replacing NSLog sentences in the history codes with DDLog sentences is also high. Moreover, the scheme can not check the online problems, and the online users can not timely acquire the log information of the users to check the online problems.

Thus, there is a need for a cheaper and better performing iOS full log collection method.

Disclosure of Invention

In view of the above, the present application proposes a method, an apparatus and a mobile terminal for collecting a full log of iOS clients, in order to solve or at least solve the above-mentioned problems.

According to one aspect of the present application, there is provided a full log collection method of an iOS client adapted to be executed in a mobile terminal, the method comprising the steps of: creating an instance of the full log in a single instance mode in a starting function of the client, and redirecting an NSlog log function of the client to a DDLog log function in an initialization process of the instance; when an NSlog log function is called, jumping to the DDLog log function, and acquiring log information of the client by using the DDlog log function; converting the acquired log information into a target log format, storing the target log format into a log array of a memory, and caching the target log format into a full log path of a local sandbox file when the stored log information exceeds a preset number; and reporting the cached log information to a server, and deleting the cached log information after the report is successful.

Optionally, in the full log collection method according to the present application, an example of the full log is GlobalNote, which is created by calling setUpGlobalNote, and is initialized by shareInstance; the client realizes the initialization call of the full log by calling [ [ GlobalNote shareInstance ] setUpGlobalNote ] in the starting function.

Optionally, in the full log collection method according to the present application, the step of redirecting the NSlog log function of the client to the DDLog log function includes: the memory address of the NSLog log function is redirected to the memory address of the redirect_NSLog function by using a fishhook, and a DDLog function is created in the redirect_NSLog function through a construction function of the DDLog to be called.

Optionally, in the full log collection method according to the present application, the redirect_nslog function is redirected by a redirect_symbols function of the fisheok, the parameters that are entered are in log format, and the parameters are of character type.

Optionally, in the full log collection method according to the present application, the target log format includes at least one of a log print time, a log level, an application version, a print location, and a log description.

Optionally, in the full log collection method according to the present application, the method further includes a configuration step of the target log format and the full log path: and acquiring log content, log grade, log line number and log function name through an incoming parameter logMessage of the formatLogMessage, and splicing the acquired content, the current time, the current application version number and the full log path into a character string to serve as configuration information.

Optionally, in the full log collection method according to the present application, the step of converting the acquired log information into the target log format and then storing the target log format in the log array of the memory includes: initializing a log array stored in a memory; and converting each piece of acquired log information into a target log format, splicing the converted pieces of log information into a long character string through a line feed character, and storing the long character string in the log array.

Optionally, in the full log collection method according to the present application, the step of buffering in the full log path of the local sandbox file when the saved log information exceeds a predetermined number includes: and adding an observation callback method to the log array, and callback db_save function when the stored log information exceeds a preset number so as to write the stored log data into a local sandbox file of the full log for caching.

Optionally, in the full log collecting method according to the present application, the step of reporting the cached log information to the server side includes: and triggering and calling a dosendLog function to upload log information after the log information is successfully cached in the local sandbox file.

According to another aspect of the present application, there is provided a full log collection device of an iOS client adapted to reside in a mobile terminal, the device comprising: the initialization module is suitable for creating an instance of the full log in a single instance mode in a starting function of the client, and redirecting an NSlog log function of the client to the DDLog log function in the initialization process of the instance; the log acquisition module is suitable for jumping to the DDLog log function when the NSlog log function is called, and acquiring log information of the client by using the DDlog log function; the log caching module is suitable for converting the acquired log information into a target log format, storing the target log format into a log array of a memory, and caching the target log format into a full log path of a local sandbox file when the stored log information exceeds a preset number; and the log reporting module is suitable for reporting the cached log information to the server side and deleting the cached log information after the report is successful.

According to still another aspect of the present application, there is provided a mobile terminal including: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, which when executed by the processors implement the steps of the methods described above.

According to yet another aspect of the present application there is provided a readable storage medium storing one or more programs, the one or more programs comprising instructions which when executed by a mobile terminal implement the steps of the method as described above.

According to the technical scheme of the application, a full log single case is created in the starting function, and the log function NSlog function is redirected to the DDLog function of the CocoaLumberjack log library in the initializing process of the single case. Thus, each time NSlog function is called, the log is obtained by automatically jumping to the DDLog function. The scheme can be compatible with the history codes, NSlog log sentences are not required to be manually replaced by DDLog log sentences, and the modification cost of NSlog in the history codes is reduced. The access to the full log singleton creation and function redirection is also very simple without modifying large amounts of code. In addition, the log information is buffered through the memory, and the safe reporting processing mechanism for buffering and reporting the log information locally after a certain number of log information is achieved ensures the hundred percent reporting of the log information.

The foregoing description is only an overview of the present application, and is intended to be implemented in accordance with the teachings of the present application in order that the same may be more clearly understood and to make the same and other objects, features and advantages of the present application more readily apparent.

Drawings

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings, which set forth the various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to fall within the scope of the claimed subject matter. The above, as well as additional objects, features, and advantages of the present disclosure will become more apparent from the following detailed description when read in conjunction with the accompanying drawings. Like reference numerals generally refer to like parts or elements throughout the present disclosure.

Fig. 1 illustrates a block diagram of a mobile terminal 100 according to one embodiment of the present application;

FIG. 2 illustrates a flow diagram of a full log collection method 200 of an iOS client, according to one embodiment of the application; and

fig. 3 shows a block diagram of a full log collection device 300 of an iOS client according to one embodiment of the application.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

Fig. 1 illustrates a block diagram of a mobile terminal 100 according to one embodiment of the present application. As shown in fig. 1, the mobile terminal 100 includes: a memory interface 102, one or more data processors, an image processor and/or a central processing unit 104, and a peripheral interface 106. The memory interface 102, the one or more processors 104, and/or the peripheral interface 106 may be discrete components or may be integrated in one or more integrated circuits. In the mobile terminal 100, various elements may be coupled by one or more communication buses or signal lines. Sensors, devices, and subsystems may be coupled to peripheral interface 106 to facilitate various functions. For example, the motion sensor 110, light sensor 112, and distance sensor 114 may be coupled to the peripheral interface 106 to facilitate orientation, lighting, and ranging functions. Other sensors 116 may also be coupled to the peripheral interface 106, such as a positioning system (e.g., a GPS receiver), a temperature sensor, a biometric sensor, or other sensing device, to facilitate relevant functions.

The camera subsystem 120 and optical sensor 122, which may be, for example, a Charge Coupled Device (CCD) or a Complementary Metal Oxide Semiconductor (CMOS) optical sensor, may be used to facilitate implementation of camera functions such as recording photographs and video clips. Communication functions may be facilitated by one or more wireless communication subsystems 124, which may include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The particular design and implementation of the wireless communication subsystem 124 may depend on the one or more communication networks supported by the mobile terminal 100. For example, the mobile terminal 100 may include a communication subsystem 124 designed to support a GSM network, a GPRS network, an EDGE network, a Wi-Fi or WiMax network, and a BlueBooth network. The audio subsystem 126 may be coupled with a speaker 128 and a microphone 130 to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions.

The I/O subsystem 140 may include a touch screen controller 142 and/or one or more other input controllers 144. The touch screen controller 142 may be coupled to a touch screen 146. For example, the touch screen 146 and touch screen controller 142 can detect contact and movement or suspension therewith using any of a variety of touch sensing technologies including, but not limited to, capacitive, resistive, infrared and surface acoustic wave technologies. One or more other input controllers 144 may be coupled to other input/control devices 148, such as one or more buttons, rocker switches, thumbwheels, infrared ports, USB ports, and/or pointing devices such as a stylus. The one or more buttons (not shown) may include up/down buttons for controlling the volume of speaker 128 and/or microphone 130.

The memory interface 102 may be coupled with a memory 150. The memory 150 may include high-speed random access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). The memory 150 may store an operating system 152, such as an operating system like Android, IOS, or Windows Phone. The operating system 152 may include instructions for handling basic system services and performing hardware-dependent tasks. The memory 150 may also store applications 154. These applications, when in operation, are loaded from the memory 150 onto the processor 104 and run on top of the operating system already being run by the processor 104, and utilize the operating system and interfaces provided by the underlying hardware to implement various user-desired functions, such as instant messaging, web browsing, picture management, and the like. The application may be provided independently of the operating system or may be self-contained with the operating system. In addition, when the application 154 is installed in the mobile terminal 100, a driving module may be added to the operating system.

Among the above-described various applications 154, one of them is the iOS client total log collecting apparatus 200 related to the present application. In some embodiments, the mobile terminal 100 is configured to perform the full log collection method 200 of the iOS client according to the application.

FIG. 2 illustrates a flow diagram of a method 200 for full log collection for an iOS client, according to one embodiment of the application. The method 200 is performed in a mobile terminal, such as the mobile terminal 100, in order to collect a full log of iOS clients.

As shown in fig. 2, the method starts at step S210. In step S210, an instance of the full log is created in single instance mode in the boot function of the client, and the NSlog log function of the client is redirected to the DDLog log function during initialization of the instance.

The single instance mode is a common software design mode, and only contains a special class called a single instance in the core structure, and the single instance mode can ensure that only one instance of a class applying the mode in the system. The example object of the log file is obtained in a single-case mode, the file can be accessed by only one process, and the exception caused by multiple times of opening of one file is avoided. The single instance mode is usually in the forms of lazy, hunger, double, etc., and one skilled in the art can select one way to create an instance of the full log on his own as needed, which the present application is not limited to.

According to one embodiment, the client's start-up function is (BOOL) application application didFinishLaunchingWithOptions (NSdictionary) launchlops. An example of a full log is GlobalNote, which is created by calling setUpGlobalNote and initialized by shareInstance. The client realizes the initialization call of the full log by calling [ [ GloballNoteshareInstance ] setUpGlobalNote ] in the starting function.

The relevant code for opening the full log is as follows:

global full log management guarantees a unique singleton through a GCD function dispatch_once, and initializes a singleton object through obj= [ [ global note alloc ] init ] statement, and related codes are as follows:

according to another embodiment, the step of redirecting the NSlog log function of the client to the DDLog log function comprises: the memory address of the NSLog log function is redirected to the memory address of the redirect_NSLog function by using a fishhook, and a DDLog function is created in the redirect_NSLog function through a construction function of the DDLog to be called. Wherein, the fishhook is a function for binding the symbols pointing to the system method (external function) again to point to the inside. The system method is exchanged with the self-defined method, and the purpose of the C function hook is achieved by modifying the pointer of the lazy load table (NSLog in the lazy load table) by utilizing the MachO file loading principle.

The relevant code for the redirection configuration function is as follows:

the parameters transmitted by the redirect_NSLog function are in a log format, and the types of the parameters are characters. The use of va_start and va_end in combination may obtain the first address of the first parameter. The redirect_NSLog function is redirected through a redirect_symbols function of the fisheok, the symbol nslog_rebinding of NSLog pointing to the system is rebinding to be pointing to the redirect_NSLog function, and DDLog is called inside the redirect_NSLog to realize specific logic. That is, redirect_NSLog sets the configuration of DDLog and achieves creation of DDlog by calling the following construction function of DDlog:

subsequently, in step S220, when the NSlog log function is called, a jump is made to the DDLog log function, and log information of the client is acquired using the DDLog log function.

Subsequently, in step S230, the obtained log information is converted into a target log format, and then stored in the log array of the memory, and when the stored log information exceeds a predetermined number, the log information is cached in the full log path of the local sandbox file.

According to one embodiment, the target log format includes at least one of log print time, log level, application version, print location, and log description. Thus, when each piece of log information is subjected to standard format conversion, the log printing time, the log grade, the application version, the printing position and the log description are sequentially added.

Furthermore, given that NSLog is the default log statement provided by the iOS system, it is necessary to configure the log format of the present application and the cache path of the full log in the local sandbox file. The sandbox is an independent, closed, secure file system directory created by the iOS application for itself. It is not possible for two programs to share a sandbox, and the sandbox of each application can only be used by itself, and the application cannot flip over its own enclosure to access the contents of another storage space. Each folder in the sandbox has its own unique deletion channel, so long as it is not manually deleted, the file is always present.

According to one embodiment, the configuration of the log format and local cache paths may be implemented as follows: and acquiring log content, log grade, log line number and log function name through an incoming parameter logMessage of the formatLogMessage, and splicing the acquired content, the current time, the current application version number and the total log path in the local sandbox file into a character string to serve as configuration information. The relevant configuration codes are as follows:

according to another embodiment, when the memory is saved, the log array stored in the memory may be initialized first, each piece of obtained log information is converted into the target log format, and the converted pieces of log information are spliced into a long string through the line-wrapping symbol and then saved in the log array. In general, db_log function is called each time a log is printed, so as to convert original log information logMessage into log information in a target format, and store the formatted log information in a log array_logmessage srray of a memory. In addition, an observation callback method can be added to the log array, and the db_save function is called back when the stored log information exceeds a preset number (such as 500 pieces) so as to write the stored log data into the local sandbox file of the full log for caching. It should be understood that, here, when the log data stored in the log array and not written into the local cache reaches 500 pieces, the db_save function is triggered to be called to write into the local cache file first, and the local cache is not performed when the log data is already cached. The relevant codes are as follows:

subsequently, in step S240, the cached log information is reported to the server, and the cached log information is deleted after the reporting is successful.

Specifically, after log information is successfully cached in the local sandbox file, triggering and calling a doSendLog function to upload the log information. And if the network uploading log data is successful, deleting the locally cached log file, and if the network uploading fails, continuing uploading or temporarily not uploading according to whether the current network is abnormally selected, and continuing uploading after the network is recovered to be normal. If the network is normal, the upload may continue. When uploading the log, judging whether the log is in a GCD queue of a log recorder (log), starting an independent log recorder queue when uploading the log, and exiting the execution if the log is not in the log recorder queue currently (belonging to abnormal conditions). The application does not report to the server side directly from the memory, and mainly prevents the report from losing due to network abnormality in the reporting process, if the user exits the application, the log data in the memory is lost, and the report can ensure that 100% of the log data is successfully reported after the log data is written into the local buffer, and the local buffer is deleted after the report is successful, and the new log information is waited to be buffered from the memory. The relevant codes are as follows:

/>

in addition, when uploading log information, the cache path of the whole log in the local sandbox file can be obtained, the path for compressing the user log to the local is obtained, the user log is compressed and then stored in the path, and the server side is reported. After log compression, network traffic can be saved, and data transmission speed is also improved. The relevant codes are as follows:

fig. 3 shows a block diagram of a full log collection device 300 of an iOS client according to one embodiment of the application, which device 300 may reside in a mobile terminal 100. As shown in fig. 3, the apparatus 300 includes: an initialization module 310, a log acquisition module 320, a log caching module 330 and a log reporting module 340.

The initialization module 310 creates an instance of the full log in single instance mode in the client's startup function and redirects the client's NSlog log function to the DDLog log function during initialization of the instance. According to one embodiment, the initialization module 310 uses a fisheok to redirect the memory address of the NSLog log function to the memory address of the redirect_NSLog function and creates the DDLog function in the redirect_NSLog function by its constructor to make the call. In addition, the initialization module 310 may further obtain the log content, the log level, the log line number and the log function name through the incoming parameter logMessage of the format logMessage, and splice the obtained content, the current time, the current application version number and the full log path into a character string as the configuration information. The initialization module 310 may perform a process corresponding to the process described above in step S210, and a detailed description thereof will not be repeated here.

The log acquisition module 320 jumps to the DDLog log function when the NSlog log function is called, and acquires log information of the client using the DDLog log function. The log obtaining module 320 may perform the process corresponding to the process described above in step S220, and a detailed description thereof will not be repeated here.

The log buffer module 330 converts the obtained log information into a target log format, then stores the target log format into a log array of the memory, and buffers the target log format into a full log path of the local sandbox file when the stored log information exceeds a predetermined number. According to one embodiment, the log buffer module 330 initializes a log array stored in the memory, then converts each piece of obtained log information into a target log format, and concatenates the converted pieces of log information into a long string through a line feed character and stores the long string in the log array. The log caching module 330 may also add an observation callback method to the log array, and callback db_save function when the stored log information exceeds a predetermined number, so as to write the stored log data into the local sandbox file of the full log for caching. The log buffer module 330 may perform a process corresponding to the process described above in step S230, and a detailed description thereof will not be repeated here.

The log reporting module 340 reports the cached log information to the server, and deletes the cached log information after the report is successful. According to one embodiment, the log reporting module 340 triggers the transfer of the doSendLog function to upload log information after the log information is successfully cached in the local sandbox file. The log reporting module 340 may perform the process corresponding to the process described above in step S240, and a detailed description will not be repeated here.

According to the technical scheme of the application, a C/S structure is used for designing, under an iOS framework, an Xcode is adopted as a development platform, cocoaLumberjack is used as a log library, a fisheok is used for redirecting an iOS log function NSLog to DDLog, and the log is reported to a server after writing a full log into a local file. Therefore, when the on-line problem of the application needs to be positioned as soon as possible and the problem is solved, a developer can acquire the full log of the application, so that the on-line problem of the application is more efficiently and accurately solved. The scheme adopts slice-oriented programming, does not invade the original log system, is not perceived by a user, and can collect the full log by only needing a small amount of access codes (initialization and function redirection of the full log). The scheme has outstanding performance, and a single log is faster than that of the traditional scheme by more than 0.004s during the test of a true machine.

The method of any one of A1-A7, wherein the step of buffering into a full log path of the local sandboxed file when the saved log information exceeds a predetermined number comprises: and adding an observation callback method to the log array, and callback db_save function when the stored log information exceeds a preset number so as to write the stored log data into a local sandbox file of the full log for caching. The method of any one of A1-A8, wherein the step of reporting the cached log information to the server side includes: and triggering and calling a dosendLog function to upload log information after the log information is successfully cached in the local sandbox file.

The various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present application, or certain aspects or portions of the methods and apparatus of the present application, may take the form of program code (i.e., instructions) embodied in tangible media, such as removable hard drives, U-drives, floppy diskettes, CD-ROMs, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the application.

In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to execute the full log collection method of the iOS client of the application according to instructions in said program code stored in the memory.

By way of example, and not limitation, readable media comprise readable storage media and communication media. The readable storage medium stores information such as computer readable instructions, data structures, program modules, or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of readable media.

In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with examples of the application. The required structure for a construction of such a system is apparent from the description above. In addition, the present application is not directed to any particular programming language. It will be appreciated that the teachings of the present application described herein may be implemented in a variety of programming languages, and the above description of specific languages is provided for disclosure of enablement and best mode of the present application.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the application may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the application, various features of the application are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be construed as reflecting the intention that: i.e., the claimed application requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this application.

Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment, or alternatively may be located in one or more devices different from the devices in this example. The modules in the foregoing examples may be combined into one module or may be further divided into a plurality of sub-modules.

Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component and, furthermore, they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination of all features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, may be used in combination, except insofar as at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

Furthermore, some of the embodiments are described herein as methods or combinations of method elements that may be implemented by a processor of a computer system or by other means of performing the functions. Thus, a processor with the necessary instructions for implementing the described method or method element forms a means for implementing the method or method element. Furthermore, the elements of the apparatus embodiments described herein are examples of the following apparatus: the apparatus is for carrying out the functions performed by the elements for carrying out the objects of the application.

As used herein, unless otherwise specified the use of the ordinal terms "first," "second," "third," etc., to describe a general object merely denote different instances of like objects, and are not intended to imply that the objects so described must have a given order, either temporally, spatially, in ranking, or in any other manner.

While the application has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated within the scope of the application as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the appended claims. The disclosure of the present application is intended to be illustrative, but not limiting, of the scope of the application, which is defined by the appended claims.

Claims

1. A method of full log collection for iOS clients, adapted to be executed in a mobile terminal, the method comprising the steps of:

creating an instance of a full log in a single instance mode in a starting function of the client, redirecting a memory address of an NSlog function of the client to a memory address of a redirect_NSLog function by using a fishek in an initialization process of the instance, and creating a DDLog log function in the redirect_NSLog function through a construction function of the DDLog to call;

when the NSlog log function is called, jumping to the DDLog log function, and acquiring log information of the client by using the DDlog log function;

converting the acquired log information into a target log format, then storing the target log format into a log array of a memory, adding an observation callback method to the log array, and when the stored log information exceeds a preset number, callback db_save function, and caching the stored log data into a full log path of a local sandbox file; and

reporting the cached log information to a server, deleting the cached log information after successful reporting, if reporting is lost, selecting to continue reporting or temporarily not reporting according to whether the current network environment is abnormal, and continuing reporting after the network is recovered to be normal;

when uploading the log, an independent log recorder queue is started, whether the log information is in a GCD queue of the log recorder is judged, and if the log information is not in the log recorder queue, the execution is stopped.

2. The method of claim 1, wherein,

an example of the full log is GlobalNote, which is built by calling setUpGlobalNote and is initialized by shareInstance;

the client realizes the initialization call of the full log by calling [ [ GlobalNote shareInstance ] setUpGlobalNote ] in the starting function.

3. The method of claim 1, wherein the redirect_nslog function is redirected by a redirect_symbols function of a fisheok, the incoming parameters of which are in log format, and the type of parameters are character type.

4. A method as recited in claims 1-3, wherein the target log format includes at least one of log print time, log rating, application version, print location, and log description.

5. The method of claim 4, further comprising the step of configuring the target log format and the full log path:

and acquiring log content, log grade, log line number and log function name through an incoming parameter logMessage of the formatLogMessage, and splicing the acquired content, the current time, the current application version number and the full log path into a character string to serve as configuration information.

6. The method of claim 1, wherein the step of converting the obtained log information into the target log format and then saving the target log format in the log array of the memory comprises:

initializing a log array stored in a memory;

and converting each piece of acquired log information into a target log format, splicing the converted pieces of log information into a long character string through a line feed character, and storing the long character string in the log array.

7. The method of claim 1, wherein the step of reporting the cached log information to the server side comprises:

and triggering and calling a dosendLog function to upload log information after the log information is successfully cached in the local sandbox file.

8. A full log collection device of an iOS client adapted to reside in a mobile terminal, the device comprising:

the initialization module is suitable for creating an instance of the full log in a single instance mode in a starting function of the client, redirecting a memory address of an NSlog function of the client to a memory address of a redirect_NSLog function by using a fisheok in an initialization process of the instance, and creating a DDLog log function in the redirect_NSLog function through a construction function of the DDLog to call;

the log acquisition module is suitable for jumping to the DDLog log function when the NSlog log function is called, and acquiring log information of the client by using the DDlog log function;

the log caching module is suitable for converting the acquired log information into a target log format and then storing the target log format in a log array of a memory, adding an observation callback method to the log array, and when the stored log information exceeds a preset number, calling back a db_save function to cache the stored log data into a full log path of a local sandbox file; and

the log reporting module is suitable for reporting the cached log information to the server, deleting the cached log information after successful reporting, if reporting fails, selecting to continue reporting or temporarily not reporting according to whether the current network environment is abnormal, and continuing reporting after the network is recovered to be normal, wherein an independent log recorder queue is started when the log is uploaded, judging whether the log information is in a GCD queue of the log recorder, and if not, exiting the execution.

9. A mobile terminal, comprising:

one or more processors;

a memory; and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, which when executed by the processor implement the steps of the method of any of claims 1-7.

10. A readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a mobile terminal, implement the steps of the method of any of claims 1-7.