iOS app performance analysis

The fluency of Apple apps is generally much better than that of Android. Should be the same with the Apple system design concept, the early iphone4 was once an absolute single task, can only do one thing, although added backstage can. Music playback, positioning and other limited services. However, most ordinary applications switch to the background and do not hang until they are 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 is not also a server. There is also no problem with hyper-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 a table of data requests today, there are also, but not many.
The details that affect app performance are in the following categories of situations:
1.server need to query the database. It's more time-consuming.

There are usually cases where the amount of server data is large. The table classification of the database is not reasonable. The table index settings in the database are not good enough, the database query statements are not optimized, and the database has dirty data.
2.client repeatedly sends a large number of repeated requests, the downloading process of the download and the Code logic problems.

3. A large number of concurrent send requests, causing some requests to time out. Send a Commute status request if there is a successful login. The number of messages requested. Amount requests, and so on.

4. Use the Baidu Agent function to analyze the walking distance in bulk, by latitude.
5. Move the large image memory directly into the memory and display it. Big data moved into memory.

6. The program appears dead loops and often refreshes the entire table.
7. Send all requests to a server address for data requests. Causes the server's processing performance to degrade, which in turn affects client performance.
8. Receive a large number of push messages in a short period of time, constantly interrupting user operations. Even the user cannot operate the app in the short term.

9. Because the sending request is slow, the data on the requested page is not deterministic. Load page period long, the user cannot see the full page for a long time, send the request before the switch page, send the success to switch 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 very large), optimize the query statement, abstract the query high-frequency table to optimize. Remove dirty data.

In case 2, using Charles to grab packets and print logs which requests have been sent repeatedly, eliminate this unreasonable logic and errors.
Situation 3. Try or avoid concurrent requests. Can merge requests to merge as far as possible, such as a large number of requests sent after login, directly at the login to write the 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 instantaneous high-volume resolution, the light of the resolution is very time to get results, the heavy server refused to resolve or only part of the resolution. So we have to use analytic one again to resolve there is a way to resolve the incident, to prevent a litter peak of the entire table about walking distance and address resolution requests are disposable 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 successful login to resolve the walking distance. Baidu Brother told you that the success of the network, authorization, in fact, you will resolve the failure, but you go to parse once the general can parse success.
Situation 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 displayed in memory.

Of course there is the case of moving big data into memory. It is generally only necessary to read the part of the data you use to be able to. It's just that I don't have a detailed example of this. This prevents the app memory from soaring, of course, you do not use it after using it to put such large object pointer empty, so that the system to recover the expected effect better.
In case 6, the dead cycle is not an abomination. Enter the dead loop if there is no bounce condition to match. The app is the equivalent of a fart. So try not to design such a cycle of waiting, if the total cycle of death, as far as possible to use the unit test to find out, solve it.

The

Cycle brush table is not desirable. To wait until all the data has been 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 of tables and content changes) can be used [Self.tableview reloadrowsatindexpaths : @[[nsindexpath indexPathForRow:self.selectedIndex insection:0]] withrowanimation:uitableviewrowanimationnone]; This refreshes the local table refresh of a row of tables. If you change only one content of a page (Image transformation, label content) without affecting the table. Set its pointer directly to the global variable of the cost polygon. Direct changes are possible, and there is no need to refresh the entire table or cell. If the dead loop refreshes the table. The whole program is finished. Kemben cannot have this logic. Found a dry dead one. But certainly no one wants to write this code, this is the purpose of writing code and the actual implementation of the processing inconsistency, the unit test tested to reach the branch coverage is very easy to find this serious bug. This type of problem is only so, it could be a logical design error, or it could be a misspelling. It is also possible that the code copied from other code is not completely altered or altered. When the cyclomatic complexity of each function is reduced to less than 15, it is very easy to write a test sample. If a main function is thousands of lines. Talk about what unit to test.
in case 7, each request corresponds to a request webpage address, which sends an HTTP request with afnetworking. Stitch the requested parameter into the request, as in http://test.zuixiandao.cn/fhl/phone/psy/startWorkJsonPhone.htm?cmdCode=0003&key= bf233049ec74b822eb5520a6ada30a76&phoneid=ios_120e438f-9757-451d-b980-0d87824b02eb&visittime=1437550879 &workkey=1.

Server one page processing. There is a performance issue with easy access when a large number of users visit. And it's not easy to differentiate individual requests. Cause internal logic to be super complex. The performance of the server is affected and, of course, the response time of the client must be affected. This method of each request corresponding to a sub-page also on the individual page state of the synchronization requirements are very high, the operation of the database concurrency should also be controlled. Fortunately, conversational information can be placed in cookies.
Situation 8. The server's push is divided into different types, each sending the type of the push message. Client to the high-frequency messages by time and type of appropriate discard, such as the maximum ability to pop up a new order message in 3 seconds.

If your push recording is playing very long. Do not intercept problems that may occur with sound overlays. Fortunately, Apple has a limited number of push messages per minute to an app, which is not very obvious, but whether Android is a serious phenomenon. Some push messages may be lost due to Apple's limit on the number of push messages per minute.
In case 9, it is best to switch the page and send the request first. Unless there is a special need to do so, do not allow people to feel slow performance problems.

Of course, jump to a page to have a data loading progress animation effect, such as a human-type pattern loading process. The page will show a daisy that is too unfriendly.

The most app impact performance is related to the server side, weak network login This is the most annoying, so to have their own active login time-out can also enter the home page, no network can also go to the home page Pop yellow bar can be. Their own active login to trigger the login according to the network notification event, no network also sent to the service, of course, the hair is also a failure, there is a normal network in the sending situation. This is also not controllable. Also do not waste the power of a timer silly waiting for network events, although the normal network network notification within 1 seconds to receive. Some weak network is slower, why not triggered by the network notification event logon? So it is the best choice to receive the network notification to initiate your own active login.

This also improves performance on your own active login, allowing the user app to start very quickly.

iOS app performance analysis