Texture (ASDK) is a must-try for iOS developers

Preface

I will judge the performance issues involved in this article based on the smoothness of sliding, including frame drops and some actual experience

• Compilation environment: MacOS 10.13.3, Xcode 9.2
• Test models: iPhone 6 10.3.3, iPhone 7 11.2.1, iPhone X 11.2.5, default iPhone 6

TableView / TableNode contains TableViewCell / CellNode: The default complexity is average, including 1~2 pictures and 2~4 text displays, and the pictures have rounded corners

Reasons and optimizations for list sliding lag

The experts have explained the reasons very clearly. The result is that 16ms is not enough to render a frame, resulting in frame drops and lags.

Here are some optimizations that we tried:

Rounded Corners

Use a rounded image to cover, the classic article Corner Rounding (http://texturegroup.org/docs/corner-rounding.html), HYBImageCliped (http://texturegroup.org/docs/corner-rounding.html) also does this

Asynchronous image cropping: Cropping images through UIGraphics may cause memory usage to surge

Data pre-processing

Specifically, after converting JSON to Model, the text is converted to rich text, some weak logic is processed, and then the value can be directly displayed.

Ahem, this doesn't seem to have any effect.

Graphics pre-processing

For example, processing image masks or fixed icons is usually achieved directly using multi-layer views

I once tried to draw three small pictures on a large picture and then display them. So, apart from the asynchronous reuse problem, the memory exploded. In the end, I still used multiple views to implement it.

Why use ASDK?

Asynchronous graphics rendering

Usually we think that UIKit cannot render on non-main threads. Once you do this, it may cause crashes, abnormal display and other problems. Why can ASDK do this? Because ASDisplayNode is thread-safe. When a Node is created, it will not immediately create a new UIView and CALayer inside it. The corresponding objects will not be generated until the main thread accesses it for the first time. In addition, it also has better performance through layer pre-synthesis and asynchronous concurrency based on Runloop ASAsyncTransactionGroup (https://github.com/TextureGroup/Texture/blob/b7cd0b16567a9eb10e58f4cc0886a145dc5273b8/Source/Details/Transactions/_ASAsyncTransactionGroup.m)

The practical experience brought by this feature is: you can safely perform asynchronous drawing, such as rounded corner clipping, adding masks, etc., which is enough to destroy your life in UIKit, with skyrocketing memory, asynchronous reuse, and extremely poor performance.

However, there will still be obvious blank spaces on low-performance devices

Preloading data and objects

First, let's take a look at a Gif to experience it. In fact, the comparison is the same after the development is completed using ASDK. There is an illusion that the network speed has become faster.

Compared with UIKit native controls, ASRangeController, ASTableView, and ASCollectionView in ASDK can be used to monitor the visible area of ​​the view, maintain the working area, trigger network requests and drawing at the right time, and asynchronously layout cells.

Different reuse mechanism from native controls

Single Cell

This means that a List has only one display style, and TableView only needs to register one Cell.

In this case, if some conventional optimizations are done properly, the scrolling smoothness is still acceptable (the difference with ASDK is small, but still discernible to the naked eye)

The difference at this time is mainly reflected in the first display of a certain data in the list, and the long waiting time when the TableView is loading the pages. Of course, these two points can also be further optimized and solved.

On the contrary, if you slide back and forth through the data that has been displayed, the difference between the two is very small, about the difference between 59.7 - 59.9 and 59.9 (I'm making this up)

In summary, with proper optimization, the gap between UIKit and ASDK is not obvious in a single cell.

Multiple Cells

Indicates that there are multiple different styles in a List, and TableView must register N Cells to implement it

In this case, assuming there are 5 types of cells, the screen can display 6 cells at the same time. If the first screen happens to display all 5 types of cells, the subsequent sliding will be consistent with the performance of a single cell. If the first screen displays only one type of content, and the other 4 types have never appeared on the screen, then when one type of cell appears on the screen, there will be obvious lag. I have tried to solve this problem by creating all Cell instance objects in advance, caching and reusing the same subviews, and asynchronously pre-drawing as an image and caching (pitfall), but the results are gradually decreasing.

ASDK is still 59.9

The difference between reuse

I both love and hate the reuse mechanism of TableView. The convenience lies in that after binding directly to the data, it can be easily updated and modified. Just make sure that setModel is simple. However, it is more troublesome when there are many business bindings.

The following is a focus on TableNode. The reuse mechanism of TableNode is no reuse, only caching. Each CellNode is brand new, so there are some special features:

• CellNode is not bound to the data source: Even if the data source is deleted after creation, TableNode can still be displayed normally
• The data directly determines what kind of CellNode to create: This is very important. The display of TableViewCell is roughly: add empty fake data subview -> data filling -> refresh. It will be more complicated when it involves layout or graphics.
• CellNode has only one step: adding a subview of real data; therefore, controls and layouts can be processed directly according to business logic without refreshing once or multiple times.
• Demo: The requirement here is one large picture + N small pictures per group, 3 or 5 per group

• Solution: The way to create TableView is to create 5, show or hide the two or two types of Cell according to the number, and correspond to the 3 and 5 situations respectively. In addition, the most important thing is: pray that the data is normal, and the number of each group of data is only 3 or 5

At this time, if you use TableNode, it will be much more flexible. You can add the required subviews according to your needs (number of data). My idea is to fix the large image at the top and add the remaining two in a row. Even if the total number is an even number, there is no extra consumption. For details, see ASDKDemo (https://github.com/didez/ASDK-Demo/tree/master/ASDKDemo)

Flex Layout

ASDK uses Flex layout and is object-oriented

Steal a picture

Simply put, the only disadvantage is that the learning curve is steeper than that of Frame AutoLayout, while the advantage is that the performance is comparable to Frame and it is easier to use than AutoLayout once you get started.