1. Analyze the method invocation time in App

Reference Documents:

LLVM pile is inserted in iOS: www.jianshu.com/p/4d392b16d…

If you want to analyze time-consuming calls during iOS development, there are three methods:

Method 1: The TimeProfile tool.

Method 2: Hook objc_msgSend method, which is relatively simple to implement, but has a limitation, only for Objective-C methods, C functions and blocks.

Method 3: LLVM peg can count all functions, but the implementation is complicated.

Conclusion:

Direct POD into the author’s open source POD library, and then run. Just remove the POD when you don’t need it.

pod 'LYFunTime', :configurations => ['Debug'], :git=>'https://github.com/lyleyang/LYFunTime.git'

Copy the code

Then do some customization by modifying the logic of _LY_fun_B and _LY_func_e for lyfuntime. c in the POD library. For example, print only function calls that take more than 100us:

void _ly_fun_e(char *name, long b){
    struct timeval end;
    gettimeofday(&end, NULL);
    long e = end.tv_sec * 1000000 + end.tv_usec;
    long t = e - b;
    
    if (t > 100) {
        printf("%s %ld us\n",name, t); }}Copy the code

Through the POD library, the following functions can be achieved:

  • Get time-consuming function calls;

  • Gets all function calls for an operation. For example, in reverse analysis, large apps often have complex business logic, which can be useful if you want to know exactly what methods are called when a button is clicked.

2. Memory leaks

Problem: UI needs to be updated when data changes; The breakpoint on the View/ViewController is fine, but the UI interface does not change to new data, click the button on the interface, etc., can also respond to normal. The first thing you should think about is whether the View/ViewController is leaking memory. That is, you see one instance on the interface, and a breakpoint breaks another instance object.

Method 1: Use the memory map to see if there are multiple instances; Method 2: Run a breakpoint to see the current instance memory address and PVC to see if the current navigation stack is the same instance.

3.App function: Debug is normal, release is abnormal

Background:

App integrates several static libraries, developed by several departments, all of which are C/C++. A library. There was no problem during the debugging of the real App, but the function of the release package was abnormal. The last check was that there was a function name conflict in the. A library, which led to the abnormal function.

Solution: Compile the App project and search the build log:

1) C function conflict: search compilation log: Duplicate symbol

2) OC category method conflicts: search compilation log: conflicts with same method from another category

3) If Jenkins + Fastlane autopackaging is used, the Fastlane packaging log output can be redirected to the file and then filtered: ld: Duplicate Symbol

4) or search: ld: warning:

Get in the habit of clearing up all compile warnings in time during development!