Performance optimization for iOS development

1. Avoid too large a xib

When loading xib, put everything in memory, including any images, and if there is a view that is not immediately available, it will waste valuable memory resources.

When you load a nib that references a picture or a sound resource, the nib load code writes the picture and sound file into memory.

2. Do not block the main thread

Uikit all work, rendering, managing touch, response input, etc. on the main thread need to be done on top.

Place time-consuming operations on child threads.

3. Adjust the size of the picture in Imageviews

If you want to display a picture from the bundle in Uiimageview, you should ensure that the size of the picture is the same as the size of the Uiimageview. Scaling a picture in the run is resource intensive, especially if the Uiimageview is nested in Uiscrollview.

If you are loading from a remote server, the size of the picture cannot be controlled locally. After the download is complete, it is best to use background thread, scale once, and then work with the scaled image in Uiimageview.

4. Select the correct collection

Arrays: An ordered set of values. Using index to lookup quickly, using value lookup is slow, and insert/delete is slow.

Dictionaries: Stores key-value pairs. Use values to find faster.

Sets: An unordered set of values. Use values to find quick, insert/delete soon.

5. Reuse or delay loading views

If you click on a button you need to render a view scene.

The first: Create and hide this view when this screen is loaded and show it when needed. (Consumes more memory)

Second: Create and show when needed. (slower than the previous one)

6.cache,cache, or cache!?

Cache needs cache (that is, things that are unlikely to change but need to be read frequently)

7. How to weigh the rendering

In a nutshell, it's faster to use a pre-rendered picture, because iOS eliminates the program that creates a picture and then draws something up and then displays it on the screen. The problem is that you need to put all the images you need into the app bundle, which adds to the volume – this is a better place to use a variable-sized picture: You can save some unnecessary space and do not need to make different diagrams for different elements (such as buttons).
However, using a picture also means that you have lost the flexibility of using the code to adjust the picture, you need to repeatedly re-do them over and over again, it is a waste of time, and if you want to do an animated effect, although each picture is only a few details of the changes you need a lot of images resulting in the increasing size of the bundle.

In the end, you need to weigh the pros and cons, whether you want performance or bundle to keep the right size.

8. Reusing significant overhead objects

To avoid using this object's bottlenecks you need to reuse them, either by adding attributes to your class or by creating static variables.
Note that if you choose the second method, the object will persist in memory while your app is running, similar to the Singleton (singleton).

9. Avoid repeated processing of data

For example, if you need data to show a tableview, it is best to broadcast the data from the server to the array structure to avoid additional intermediate data structure changes.

If the data needs to be taken from a particular key, then the dictionary of the key-value pair is used;

10. Set back picture correctly

Use Uicolor's colorwithpatternimage to set the background color;

Add a uiimageview as a child view in the view;

If you use full-frame backgrounds, you must use Uiimageview because Uicolor's colorwithpatternimage is used to create small duplicate images as backgrounds.

If you use a small tiling to create a background, you need to do it with Uicolor Colorwithpatternimage, which will render faster and will not cost much memory

11. Optimize Table View

Use reuseidentifier correctly to reuse cells

Try to make all the view opaque, including the cell itself

Avoid gradients, picture scaling, background selection

Cache Row Height

If the real content within the cell comes from the web, using asynchronous loading, the cache request results

Use Shadowpath to draw shadows

Reduce the number of subviews

Try not to apply Cellforrowatindexpath: If you need to use it, use it only once and then cache the result

Use the correct data structure to store the information

Try to use RowHeight, Sectionfooterheight and sectionheaderheight to set the fixed height, do not request delegate

12. Use the correct data storage options

Use Nsuserdefaults (only some small data, such as some simple Boolean setting options)

Use Xml,json or plist (need to read files into memory to parse, this is very economical)

Nscoding (also file read and write, also have the above problem)

Sqlite (Big data can be stored)

13. Speed Up startup time

Do as many asynchronous tasks as possible

Avoid using huge xib because they are loaded on the main thread and use storyboards as much as possible. (The device must be disconnected from Xcode to test the boot speed)

14. Using Autorelease Pool

Create multiple temporary objects, and find that memory has been reduced until these objects are released, because only memory is freed when the Autorelease pool is available.

Performance optimization for iOS development