iOS app performance analysis

Apple app fluency is generally better than Android, should be the same with the Apple system design concept, the early iphone4 is an absolute single task, can only do one thing, although the background can be added, music playback, positioning and other limited services, but most of the normal application switch to the background do not hang, Until it is killed by the system (10--15 minutes). A task of course, memory utilization and CPU scheduling management is much better management, efficiency is high. The app also does not serve as a server, and there is no problem with super-multiple socket links. Of course, app performance issues are completely different from the PC's application performance issues.
The app is mainly responsible for the data request and display, so the app is mainly performance in the data request, display aspects are also, but not many.
The specific scenarios that affect app performance are in the following categories:
1. The server needs to query the database, compare the time. Usually there are several cases: the server data is large, the database table classification is unreasonable, the table index settings in the database is not good enough, the database query statement is not optimized, the database has dirty data.
2. The client repeatedly sends a large number of duplicate requests, and there is a problem with duplicate downloads and code logic during the slice download.
3. A large number of concurrent send requests, resulting in partial requests time-out, such as the success of the post-logon status request, the number of messages requested, the amount of requests.
4. Use the Baidu Agent function to analyze the walking distance in bulk, by latitude.
5. Move large image memory directly into memory and display, big data into memory.
6. The program has a dead loop and often refreshes the entire table.
7. Send all requests to a server address for data requests, resulting in degraded server processing performance, which in turn affects client performance.
8. Receive a large number of push messages in a short period of time, continue to interrupt user operations, even the user can not operate the app in the short term.
9. Because the sending request is slow, the data of the request page is uncertain, the load page period is long, the user cannot see the complete page for a long time, send the request in front of the switch page, send the success before switching to the corresponding page.
The following are solutions to the above performance issues.
For Case 1, of course, optimize the tables in the database, set the index for all tables (the index of the table affects the query of the data is very large), optimize the query statement, abstract the query high-frequency table to optimize, remove dirty data.
In case 2, use Charles to grab the packet and print the log which requests have been sent repeatedly, eliminating this unreasonable logic and errors.
Situation 3, as far as possible or avoid concurrent requests, can merge requests to merge as far as possible, such as the number of requests to send after logging in, directly at the time of login to write parameters, log in the success of the response message you need to return all the results can be.
Situation 4, Baidu's walking distance calculation agent and address Jingwei Resolution agent does not support the instantaneous large batch resolution, light analysis time to get the results, the heavy server refused to resolve or only part of the resolution, so to use the analytic one to parse another event mode resolution, To prevent a litter peak of the entire table about walking distance and address resolution requests are handed over to Baidu elder brother. Of course there are just open the network into the application, network recovery, received the network after the normal notification immediately after the success of the walk to resolve the walking distance, Baidu elder brother told you the success of the network, authorization, in fact, you will resolve the failure, but you go to parse once the general can parse success.
In case 5, you can use UIImage *image = [AppManager resizeimage:[uiimage imagenamed:@ "My_backgroud_up_6.png"] tosize:cgsizemake ( window_width) scale:1]; This way compression is shown in memory. Of course, there is the case of moving big data into memory, generally only need to read the data you use in the part of the information can be, but I do not have specific examples of this. This prevents the app memory from soaring, of course, you do not use it after using it to put such a large object pointer empty, so that the system to recover the estimated effect better.
Situation 6, the dead cycle is not enough, into the dead loop if there is no match to the jump condition, the app is the equivalent of the fart. So try not to design such a cycle of waiting, if the complete cycle of death, as far as possible to use unit testing to find out, solve it. Circular brush table is not a great thing, to wait until all the data is processed and then brush the entire table ([Self.tableview reloaddata]), of course, you just brush a row of tables (such as the height of a row table and content changes) can be used [Self.tableview Reloadrowsatindexpaths:@[[nsindexpath IndexPathForRow:self.selectedIndex insection:0]] Withrowanimation: Uitableviewrowanimationnone]; Refreshes the local table refresh of a row of tables. If you only change one content of a page (Image transformation, label content) and do not affect the table, directly set its pointer to the cost of the global variable, directly modify it, and do not need to refresh the entire table or cell. If the death cycle refreshes the table, the whole program is finished, and Ken cannot have such logic.

The most app impact performance is related to the server side, weak network login This is the most annoying.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

iOS app performance analysis