What do I do when the app crashes on the line?

1. How to track app crash rate, how to resolve online flash back

When apps on an iOS device flash back, the operating system generates a crash log that is on the device. There is a lot of useful information on the crash log, such as the full stack trace and memory image of each executing thread, to find out why the app is being flashed by parsing the information and then locating the code logic at the time the crash occurred. Typically, crash comes from two types of problems: crash that violate the crash and app code logic bugs caused by iOS system rules, and analyze them separately.

There are three types of crash that violate iOS system rules:

(1) Memory alarm flash Back

When iOS detects that memory is too low, its VM system emits a low memory warning notification, attempts to reclaim some memory, and if the situation is not improved enough, iOS terminates the background app to reclaim more memory, and finally, if the memory is insufficient, the running app may be terminated. In debug mode, you can actively write the client's action logic into a log file, so that the program child shoes can write the logic of memory warning to the log file, when the following memory alarm occurs, is to remind the current client performance memory is tight, Memory allocation issues and memory leak issues can be identified through the allocations and leaks library in the instruments tool.

(2) Response timeout

When an application is not responding to specific events (such as Start, suspend, resume, end), Apple's watchdog mechanism kills the application and generates a corresponding crash log. These events correspond to the following uiapplicationdelegate methods, and when you encounter the watchdog log, you can check that there are several ways in which the action of a heavier blocking UI is in order.

Application:didFinishLaunchingWithOptions:applicationWillResignActive:applicationDidEnterBackground: ApplicationWillEnterForeground:applicationDidBecomeActive:applicationWillTerminate:

(3) User forced to quit

Once you see "User forced Exit", you might first think of double-clicking the Home key and then closing the application. However, this scenario generally does not produce a crash log, because when you double-click the Home key, all applications are in the background state, and iOS can turn off the background process at any time, and this scenario generates crash logs when the blocking interface is applied and stops responding. This refers to the "user forced exit" scenario, which is a slightly more complex operation: Press and hold the Power key until the "swipe off" interface appears, then press and hold the home button, and the current application is terminated and a crash log of the corresponding event is generated.

Bugs that apply logic

Most flash crash logs are generated due to bugs in the app, which have many errors, such as:

• SEGV: (segmentation violation, Segment violation), invalid memory address, such as null pointer, uninitialized pointer, stack overflow, etc.;

• SIGABRT: Receive abort signal, may call abort () or receive external signal sent over;

• Sigbus: Bus error. Unlike SIGSEGV, SIGSEGV accesses an invalid address (such as a virtual memory mapping is not physical), and Sigbus accesses a valid address, but bus access exceptions (such as address alignment issues);

• Sigill: Attempt to execute an illegal instruction that may not be recognized or has no authority;

• Sigfpe:floating point Error, mathematical calculation related problems (may not be limited to floating points calculation), such as except 0 operations;

• Sigpipe: No process at the other end of the pipeline takes over data;

The most common causes of crashes are code logic problems or resource problems, such as array out-of-bounds, access to wild pointers or resources that do not exist, or resource capitalization errors.

Collection of crash

If you are on Windows, you can view the history crash logs generated by the system via itools or PP helper tools, and then view them according to the app. If it is on a Mac system, just open xcode->windows->devices, select Device logs to view, for example, these crash files can be exported, and then separate the crash file for processing analysis.

Look at the log

Commercial software available on the market provides crash collection services, which basically provide services such as log storage, log symbolic parsing, and service-side visual management:

• Crashlytics (www.crashlytics.com)

• Crittercism (www.crittercism.com)

• Bugsense (www.bugsense.com)

• HOCKEYAPP (www.hockeyapp.net)

• Flurry (www.flurry.com)

Open source software can also be used to collect crash logs, such as Razor,quincykit (git link), etc., these software collection crash principle is actually very similar, are based on the crash log generated by the system is extracted or encapsulated once, The encapsulated crash file is then uploaded to the corresponding service side for parsing processing. Many commercial software uses plcrashreporter this open source tool to upload and parse crash, such as Hockeyapp,flurry and Crittercism.

Crash information

An example was found because of the length of his crash message:

1) The crash identity is some identifying information when the application process generates crash, which describes the unique identifier (E838FEFB-ECF6-498C-8B35-D40F0F9FEAE4) of the crash, the type of hardware device that occurs (Iphone3, 1 for iphone4), as well as information related to the app process;

2) The basic information describes the time and the system version of the crash occurrence;

3) The exception type describes the exception type and error code that are thrown when crash occurs;

4) Thread backtracking describes the trace information of the thread at the time of the crash, each of which corresponds to the function call information in each frame (here because of the space constraints are not all listed);

5) A binary image is a binary file that is loaded when crash occurs. The above is a copy of all the information contained in the crash log, the next need to use this information to resolve the code logic that causes crash to occur, which requires the process of symbolic parsing (called: symbolication).

Resolve on-line flash-back

First guarantee, fully tested before release. There is still a flashback after publishing, review the crash log, fix it and publish it in time.

What do I do when the app crashes on the line?