Some methods to detect iOS APP performance

[[183880]]

First, if you encounter application lag or excessive memory usage, you can usually use Instruments to detect it. But for complex situations, you may need to use the child thread to monitor the main thread. Here are some introductions to these methods:

Time Profiler

You can view the methods that take too much time in multiple threads. First, check Hide System Libraries on the right to filter the information. Then, the Call Tree will be sorted by the time-consuming threads by default, and the single thread will also be sorted by the corresponding time-consuming methods. After selecting the method, you can double-click the Heaviest Stack Trace on the right to view the specific time-consuming operation code, so that you can optimize it in a targeted manner without over-optimizing in some places that will not affect performance much.

Allocations

Here you can perform Generations before and after each action, compare the memory increase, and view the specific method and code location that caused the memory increase. The specific operation is to click Mark Generation in Generation Analysis on the right, which will generate a Generation. When you switch to other pages or another event occurs after a period of time, click Mark Generation again to generate a new Generation. Repeat this process to generate multiple Generations. When you check these Generations, you will see the size of Growth. If it is too large, you can click in to view the corresponding thread that occupies a large amount of space and check the corresponding code block in the Heaviest Stack Trace on the right, and then perform corresponding processing.

Leak

You can see the overflow at the corresponding time point in the Leaks section in the upper area. After selecting it, you can see the leaked object in Statistics>Allocation Summary in the lower area. You can also view the specific corresponding code area through Stack Trace.

When developing, you need to pay attention to how to avoid some performance issues

NSDateFormatter

Through the detection of Instruments, it is found that the time consumption of creating NSDateFormatter or setting the properties of NSDateFormatter is always at the front. How to deal with this problem? It is recommended to add properties or create static variables, so that the number of creation and initialization can be reduced to ***. Another way is to directly use C or this NSData Category to solve it https://github.com/samsoffes/sstoolkit/blob/master/SSToolkit/NSData%2BSSToolkitAdditions.m

UIImage

The main thing here is that it will affect the memory overhead. You need to weigh imagedNamed and imageWithContentsOfFile. After understanding the characteristics of the two, use the latter for images that only need to be displayed once. This will reduce memory consumption, but page display will increase Image IO consumption, which needs to be paid attention to. Since imageWithContentsOfFile does not cache, it needs to be loaded once before each page display. This IO operation is also a point that needs to be considered.

Page Loading

If a page has too much content and too many views, the partial view content that needs to be scrolled to be seen in the long page will be loaded synchronously by starting a new thread.

Optimize *** loading time

You can use Time Profier to view the time taken for startup. If it is too long, you can use Heaviest Stack Trace to find time-consuming methods and modify them.

How to monitor lag

Another way is to monitor performance issues in the program. You can take a look at this Demo first, the address is https://github.com/ming1016/DecoupleDemo. In this way, you can use this program to record the user's lag operations after going online, and send them to your own server at a regular interval, so that you can collect performance issues on a larger scale. As we all know, the lags perceived at the user level come from the main thread that handles all UIs, including large calculations performed on the main thread, a large number of IO operations, or heavier drawing work. How to monitor the main thread? First of all, you need to know that the main thread, like other threads, is driven by NSRunLoop. You can first take a look at the general logic of CFRunLoopRun.

 int32_t __CFRunLoopRun() 
 
 { 
 
    __CFRunLoopDoObservers(KCFRunLoopEntry); 
 
 do 
 
 { 
 
        __CFRunLoopDoObservers(kCFRunLoopBeforeTimers); 
 
 __CFRunLoopDoObservers(kCFRunLoopBeforeSources); //The processing time from here to kCFRunLoopBeforeWaiting is the key to perceive the jam 
 
  
 
        __CFRunLoopDoBlocks(); 
 
 __CFRunLoopDoSource0(); //Handle UI events 
 
  
 
        //GCD dispatch main queue 
 
        CheckIfExistMessagesInMainDispatchQueue(); 
 
  
 
 //Before sleep 
 
        __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting); 
 
  
 
 //wait for msg 
 
        mach_port_t wakeUpPort = SleepAndWaitForWakingUpPorts(); 
 
  
 
 //Waiting 
 
  
 
 //After sleeping, wake up 
 
        __CFRunLoopDoObservers(kCFRunLoopAfterWaiting); 
 
  
 
 //Timer wake up 
 
        if (wakeUpPort == timerPort) 
 
            __CFRunLoopDoTimers(); 
 
  
 
 //Asynchronous processing 
 
 else if (wakeUpPort == mainDispatchQueuePort) 
 
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 
 
  
 
 //UI, animation 
 
 else   
 
            __CFRunLoopDoSource1(); 
 
  
 
 // Ensure synchronization 
 
        __CFRunLoopDoBlocks(); 
 
  
 
    } while (!stop && !timeout); 
 
  
 
 //Exit RunLoop 
 
    __CFRunLoopDoObservers(CFRunLoopExit); 
 
 }

Based on this RunLoop, we can measure it through CFRunLoopObserverRef. Use dispatch_semaphore_t in GCD to start a new thread, set a limit value and the number of occurrences, and then obtain the scenes on the main thread that exceed the limit value and the number of occurrences between kCFRunLoopBeforeSources to kCFRunLoopBeforeWaiting and then to kCFRunLoopAfterWaiting, dump the stack, and send it to the server for collection. Through the stack, we can find the method that has the problem.

 static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) 
 
 { 
 
    MyClass *object = (__bridge MyClass*)info; 
 
    object->activity = activity; 
 
 } 
 
  
 
 static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){ 
 
    SMLagMonitor *lagMonitor = (__bridge SMLagMonitor*)info; 
 
    lagMonitor->runLoopActivity = activity; 
 
  
 
    dispatch_semaphore_t semaphore = lagMonitor->dispatchSemaphore; 
 
    dispatch_semaphore_signal(semaphore); 
 
 } 
 
  
 
 - (void)endMonitor { 
 
 if (!runLoopObserver) { 
 
 return ; 
 
 } 
 
    CFRunLoopRemoveObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes); 
 
    CFRelease(runLoopObserver); 
 
 runLoopObserver = NULL ; 
 
 } 
 
  
 
 - (void)beginMonitor { 
 
 if (runLoopObserver) { 
 
 return ; 
 
 } 
 
 dispatchSemaphore = dispatch_semaphore_create(0); //Dispatch Semaphore ensures synchronization 
 
 //Create an observer 
 
    CFRunLoopObserverContext context = {0,(__bridge void*)self, NULL , NULL }; 
 
    runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault, 
 
                                              kCFRunLoopAllActivities, 
 
                                              YES, 
 
                                              0, 
 
                                              &runLoopObserverCallBack, 
 
                                              &context); 
 
 //Add the observer to the common mode observation of the main thread runloop 
 
    CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes); 
 
  
 
 //Create a child thread monitoring 
 
    dispatch_async(dispatch_get_global_queue(0, 0), ^{ 
 
 //The child thread starts a continuous loop for monitoring 
 
 while (YES) { 
 
            long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 30*NSEC_PER_MSEC)); 
 
            if (semaphoreWait != 0) { 
 
                if (!runLoopObserver) { 
 
                    timeoutCount = 0; 
 
                    dispatchSemaphore = 0; 
 
                    runLoopActivity = 0; 
 
 return ; 
 
 } 
 
 //Two runloop states, BeforeSources and AfterWaiting, can detect whether there is a freeze. 
 
                if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) { 
 
 // The result appears three times 
 
                    if (++timeoutCount 3) { 
 
 continue ; 
 
 } 
 
  
 
 //Put the code for reporting stack information to the server here 
 
  
 
                } // end activity 
 
            }// end semaphore wait 
 
 timeoutCount = 0; 
 
 }// end while 
 
 }); 
 
  
 
 }

Sometimes the jam is caused by abnormal, excessive, or large data, or by abnormal operation. Such situations may be difficult to encounter in daily development and testing, but they will occur in real life, especially when the user audience is wide. In this way, this method of collecting jams is still valuable.

Stack dump method

The first is to directly call the system function to obtain the stack information. This method can only obtain simple information. It cannot cooperate with dSYM to obtain the specific line of code that has a problem, and the types are also limited. The main idea of ​​this method is to obtain the error signal through signal. The code is as follows

 static   int s_fatal_signals[] = { 
 
 SIGABRT, 
 
 SIGBUS, 
 
 SIGFPE, 
 
 SIGILL, 
 
 SIGSEGV, 
 
 SIGTRAP, 
 
 SIGTERM, 
 
 SIGKILL, 
 
 }; 
 
  
 
 static   int s_fatal_signal_num = sizeof(s_fatal_signals) / sizeof(s_fatal_signals[0]); 
 
  
 
 void UncaughtExceptionHandler(NSException *exception) { 
 
 NSArray *exceptionArray = [exception callStackSymbols]; //Get the current call stack information 
 
 NSString *exceptionReason = [exception reason]; // Very important, the reason for the crash 
 
 NSString *exceptionName = [exception name ]; //Exception type 
 
 } 
 
  
 
 void SignalHandler( int code) 
 
 { 
 
    NSLog(@ "signal handler = %d" ,code); 
 
 } 
 
  
 
 void InitCrashReport() 
 
 { 
 
 //System error signal capture 
 
 for ( int i = 0; i signal(s_fatal_signals[i], SignalHandler); 
 
 } 
 
  
 
 //oc does not capture the exception 
 
    NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler); 
 
 } 
 
 int main( int argc, char * argv[]) { 
 
 @autoreleasepool { 
 
 InitCrashReport(); 
 
 return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); 
 
 } 
 
 }

The report generated by PLCrashReporter seems to be able to locate the specific location of the problematic code.

 NSData *lagData = [[[PLCrashReporter alloc] 
 
                                          initWithConfiguration:[[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]] generateLiveReport]; 
 
 PLCrashReport *lagReport = [[PLCrashReport alloc] initWithData:lagData error: NULL ]; 
 
 NSString *lagReportString = [PLCrashReportTextFormatter stringValueForCrashReport:lagReport withTextFormat:PLCrashReportTextFormatiOS]; 
 
 //Upload the string to the server 
 
 NSLog(@"lag happen, detail below: 
 
 %@",lagReportString);

The content in the stack in the test demo exceeds the number of characters in the WeChat text, so it is omitted in this article.