iOS image loading speed limit optimization-fastimagecache analysis

this article reprinted to http://blog.cnbang.net/tech/2578/

Fastimagecache is an open source library developed by the path team to increase the loading and rendering speed of images, and to slide the picture-based list to a smoother look at how it is done.

Optimization point

iOS loading a picture from disk, using Uiimageview display on the screen, you need to go through the following steps:

1. Copy data from disk to kernel buffer
2. Copy data from kernel buffers to user space
3. Generate Uiimageview and assign the image data to Uiimageview
4. If the image data is a png/jpg that is not decoded, it is decoded as bitmap data
5. Catransaction captures changes to the Uiimageview layer tree
6. The main thread Runloop commits the catransaction and begins the image rendering
   • 6.1 If the data is not byte-aligned, Core animation copies one copy of the data for byte alignment.
   • The 6.2 GPU processes bitmap data for rendering.

Fastimagecache optimized the 2,4,6.1 three steps respectively:

1. The use of mmap memory mapping eliminates the operation of copying the 2nd step data from the kernel space to the user space.
2. Caches decoded bitmap data to disk, eliminating the 4th step decoding operation the next time you read from disk.
3. Generates byte-aligned data to prevent the above step 6.1 coreanimation from copying a copy of the data at render time.

The next step is to introduce the three optimization points and its implementation.

Memory mapping

Normally we read a file on the disk, the upper API call to the end will use the System method read () reads the data, the kernel reads the disk data into the kernel buffer, the user then reads the data from the kernel buffer to the user memory space, there is a time consumption of memory copy, And after reading the entire file data already exists in the user memory, occupies the process memory space.

Fastimagecache uses another way to read and write files, is to use Mmap to map the file to the virtual memory in the user space, the location of the file in the virtual memory has a corresponding address, you can operate the same as the memory operation of the file, the equivalent of the entire file into memory, But before the actual use of these data will not consume physical memory, there will not be read and write disk operations, only when the actual use of the data, that is, when the image is ready to render on the screen, the virtual memory management system VMS from the disk load the corresponding data block to the physical memory, and then render. Such a file read and write files in a way less data from the kernel cache to the user space copy, high efficiency.

Decode image

Generally we use the image is jpg/png, these image data is not a bitmap, but is encoded compressed data, use it to render to the screen before it needs to be decoded to the bitmap data, this decoding operation is relatively time-consuming, and no GPU hard decoding, only through the CPU, iOS decodes an image on the main thread by default. Many libraries have solved the problem of image decoding, but because the decoded image is too large to be cached to disk, it is sdwebimage to move the decoding operation from the main thread to the child thread, so that the time-consuming decoding operation does not occupy the main thread.

Fastimagecache also decodes an image on a sub-thread, unlike it caches the decoded image to disk. Because the decoded image volume is very large, fastimagecache to these image data to do a series of cache management, see the implementation section below. In addition, the cached image size is also used to read the file memory mapping reasons, small files using memory mapping no advantage, the amount of memory copy less, copy after the user memory is not high, the larger the file memory mapping advantage.

byte alignment

Core animation A copy of the image data before rendering in the case of non-byte alignment of the image data, the official document does not explain the copy behavior, the simulator and instrument have highlighted "copied images" function, but it seems to have a bug, Even if a picture is not highlighted to be copied at render time, the Ca::render::copy_image method is still visible from the call stack:

What is byte alignment, according to my understanding, in order to performance, the underlying rendering image is not a pixel one pixel rendering, but a piece of rendering, the data is a block to take, you may encounter this piece of contiguous memory data in the end of the data is not the content of the image, is the memory of other data, Possible cross-reading causes some strange things to get mixed up, so before rendering coreanimation to copy the data for processing, make sure each piece is image data, and empty the data for less than one piece. Approximate figure: (pixel is the image pixel data, the data is other in memory)

The size of the block should be related to CPU cache line, ARMV7 is 32byte,a9 is 64byte, under A9 coreanimation should be 64byte as a piece of data to read and render, Aligning the image data to 64byte prevents Coreanimation from copying a copy of the data for patching. The byte alignment that Fastimagecache does is the thing.

Realize

Fastimagecache the same type and size of the image are placed in a file, according to the file offset to take a single picture, similar to the web-based CSS Sprite, called ImageTable. This is mainly to facilitate the unified management of the image cache, control the size of the cache, the whole fastimagecache is in the management of imagetable data. The data structure of the whole implementation

Some additions and explanations:

ImageTable

1. A imageformat corresponding to a imagetable,imageformat specified in the ImageTable image Rendering format/size information, imagetable image data are defined by the ImageFormat uniform size, The size of each image is the same.
2. One imagetable an entity file, and there is another file that holds the meta information for this imagetable.
3. The image uses Entityuuid as a unique identifier, defined by the user, usually the hash value of the image URL. The indexmap of the ImageTable Meta records the Entityuuid->entryindex mapping, and the entityuuid of the image can be used to find the location of the cached data in imagetable by Indexmap.

Imagetableentry

1. ImageTable Entity Data is imagetableentry, each entry has two parts of data, part of the image data is aligned, the other part is meta information, meta-Save the image of the UUID and the original UUID, to verify the correctness of the image data.
2. Entry data is aligned in memory paging size, which is an integer multiple of the memory paging size, which ensures that virtual memory pages are loaded with a minimal amount of memory to load an image.
3. The image data is byte-aligned, and coreanimation is used without having to process the copy. The Cgbitmapcontextcreate method is to create a bit drawing cloth when the Bytesperrow parameter is passed 64 times times.

Chunk

• ImageTable and Entity Data entry between the layer Chunk,chunk is the logical data division, n entry as a chunk, the memory map mmap operation is in chunk units, Each chunk executes a mmap to map this chunk content to virtual memory. Why should a layer of chunk, according to my understanding, this is to flexibly control the size and number of calls Mmap, if the entire imagetable execution mmap, loaded virtual memory of the file is too large, if each entry do mmap, the number of calls will be too many.

Cache Management

• The user can define the maximum number of cached images in the entire imagetable, and if the cache does not exceed the limit, the file size will be extended in chunk, in sequence, when a new image needs to be cached. If the maximum cache limit has been exceeded, the least-used cache will be replaced by inserting the UUID into the beginning of the mruentries array each time the image is used, mruentries the image uuid in the most recent order, and the last image in the array is the least used. The replaced image next time you need to use, go again to take the original-unzip-the stored process.

Use

The Fastimagecache is ideal for caching images of the same size on each cell in TableView, with the advantage of greatly speeding up the first time the images are loaded from disk. But it has two obvious drawbacks: one is that it occupies a large space. Since the decoded bitmap to disk is cached, the bitmap is large, and the wide-100*100 image needs to be 200*200*4byte/pixel=156kb under the 2x HD screen device, which is why Fastimagecache to limit the size of the cache. Second, the interface is not friendly, you need to pre-defined a good cache image size. Fastimagecache cannot seamlessly access Uiimageview like Sdwebimage, using it to configure imagetable, define the dimensions, manually provide the original artwork, and each entity image to define a ficentity model to complicate the logic.

Fastimagecache is already a limit optimization, do image loading/rendering optimization should give priority to some low-cost high-return optimization points, such as Calayer instead of Uiimageview, reduce GPU computing (de-transparent/pixel alignment), image sub-thread decoding, Avoid Offscreen-render and so on. When other optimizations are in place, image rendering still has performance problems, consider using Fastimagecache to further enhance the performance of the first load, but the optimization of byte alignment can be directly applied to the project from Fastimagecache, You only need to set the bytesperrow of the bitmap canvas to a multiple of 64 when decoding the image.

iOS image loading speed limit optimization-fastimagecache analysis