try to do the following
- Decreasing app launch time improves the user experience, and reduces the chances of the iOS watchdog timer terminating the app.
- Decreasing overall memory use reduces the likelihood of iOS freeing your app’s memory in the background and improves responsiveness when a user switches back to your app.
- Reducing disk writes speeds up your app’s overall performance, makes it more responsive, and reduces wear on users’ device storage.
- Decreasing hang rate and hang duration improves your users’ perception of your app’s performance and responsiveness.
- Reducing battery consumption and the use of power-hungry device features makes your app more reliable and helps ensure that the rest of the user’s device is available when needed.
Even when your measurements and observations show no pressing performance problems, it’s a good idea to run through the performance-improvement cycle and do preventive work to keep your app’s performance from regressing.
1- Gather Data About Your App’s Current Performance
To thoroughly understand your app’s performance, combine information from multiple sources:
- Use the Metrics organizer in Xcode to view metrics for launch time, hang rate, writes to storage, memory use, and energy use. The Organizer lets you break down measurements by device model and app version.
- Use MetricKit to gather metrics and record them in your own tools. These metrics are in the form of histograms that record the frequency of observed values over a day. MetricKit goes beyond the metrics shown in the Metrics organizer to include average pixel luminance, cellular network conditions, and durations associated with custom
OSSignpostevents in your app.
- Investigate feedback from your users about their experiences with released versions of your app. Invite users to send their feedback through email or a dedicated interface within your app. Ask them about their experiences using the app — both what works well and any problems they encounter.
2- Determine the Most Important Aspect to Improve
Use the information gained in your observations and your understanding of your app’s purpose and expected use patterns to spot the greatest opportunities for improvement. Some performance issues are independent of the type of app under investigation. An app that takes a long time to launch or is unresponsive to users’ attempts to manipulate the interface results in users feeling they have no control over the app.
On the other hand, the largest value for a metric you see in the Metrics organizer or in MetricKit may not indicate the most important issue to address if that value represents your app being used as expected. For example, energy use associated with background-audio playing is probably not a problem for a podcast player, which users expect to play in the background. However, it would be surprising to see that metric dominate if your app is a game that has no background component to its gameplay.
Seeing that figure dominate the metric reports could indicate that efficiency savings are possible, but the most impactful changes may be in the use of auxiliary services that don’t impact the app’s main features. The podcast player might infrequently need to use coarse-grained location services to recommend local-interest podcasts to the listener, but the high-energy consumption associated with the frequent tracking of the user’s precise location may be a sign that a change is needed.
3- Profile Your App
Use Instruments to profile your app, choosing a profiling template that’s relevant to the metric you’re considering:
You’ll get higher-fidelity measurements by profiling on a device, instead of the simulator. If the information you gather shows that your app performs poorly on a particular class or model of device, profile on that device.
Find the code that’s causing the performance problem, and create a plan for improving it. Keep in mind that your change may not be localized to a particular line or even function, and you may need to make significant architectural changes to your app. For example, to mitigate a hang caused by synchronously downloading network resources, introduce background operations to handle the networking (see Downloading Files in the Background), and perform a UI update on the main thread when the downloads are complete.
4- Make the Next Change
Implement the change you’ve planned as a result of your investigation. Create an “after” profile in Instruments that you can compare with the “before” profile, to ensure your change resulted in an improvement. Consider writing a performance test in XCTest, to protect against future regressions in performance and as a record that this problem existed and has been fixed.
5- Compare the Changed Behavior with Your Original Data
After you change your app to address the most important performance issue you observed, confirm that the change had the desired effect and that the level of improvement is sufficient. Use the graphs of performance metrics for each version of your app in Xcode’s Metrics organizer, to see whether the change resulted in an improvement or a regression.
Finally, decide whether the metric on which you were working is still the most important to address, or whether the data points to another metric for the next iteration of the performance improvement cycle.