UITableView optimization Notes (i)

Recommendation: HTTP://CODE4APP.COM/IOS/VVEBOTABLEVIEW/565D75A3594B90BF268B49FF

1:heightforrowatindexpath Method Small Fuss

Cause: TableView inherits from ScrollView and needs to be calculated when TableView is loaded. So this method is called frequently the first time it is loaded, such as: Table has 100 rows, then this method calls 100 times, and each result is added to get contentsize. It's like setting the Contentsize property every time you use ScrollView scrolling.

Small Fuss 1: If table is fixed at a height of each cell, use _tableview.rowheight = 200;

Little Fuss 2: If the cell is highly variable, do not call Cellforrowatindexpath in Heightforrowatindexpath to calculate. Instead, the cell's factory method. Such as:

Little Fuss 3: When data is obtained, it is highly calculated and stored in the data, and the Heightforrowatindexpath method uses the data directly. Such as:

Summary: Use the third method as much as possible and analyze the following

The second method of time analysis is as follows:

The third method of time analysis is as follows:

Both methods essentially traverse the data to get the corresponding height, and the code that calculates the height is exactly the same. However, in the second method, the Heightforrowatindexpath run time is very large, and as the table scrolls, it is shown that each time the user scrolls the table, the method of calculating the height is executed once, if the method used to calculate the height is more, such as my current

Each time the calculation is 330 units up and down, then if the data volume is large, rolling quickly, this is simply a disaster.

The third method of calculating the height of the code is that after fetching the data, the table executes before loading and executes only once. The 210ms time does not increase with the scrolling of the table. And our Heightforrowatindexpath method, the execution time has dropped to 1ms, almost negligible.

Of course, in a demo with only table, this optimization basically doesn't work.

2: Add less than Draw: Cellforrowatindexpath method Big Trouble

The most common way to use Cellforrowatindexpath usually is to addsubview in the cell's Init method as

This is the way to add a sub-view to fill the data in the cell.

The method of drawing is in the first recommended demo method, thanks to the author.

Like this:

Draw a lot of code, basically belong to the coregraphics framework of east, said big fee, the basic is in this.

The method time analysis for adding a child view is as follows:

The method of drawing time analysis is as follows:

The truth is, this painting method code execution time really is scared me to jump, draw cell thread really is-_-#

However, the User scrolling table is not felt, because all the threads of the painting are sub-threads, and the main thread accounted for only a trivial 2%, is the SetImage method.

In turn, the method of adding a child view Cellforrowatindexpath is almost all executed on the main thread, and the child thread only finds a way to cache the picture. This method is really Kaka's ah.

Real machine run, obviously feel the way to draw more than the method of adding a child view.

PS: Only the code execution time is analyzed and memory consumption is not analyzed.

UITableView optimization Notes (i)