Geek Answers Handbook

Why UIImageView is so full of memory compared to CGContextDrawImage

Developing the iPad PDF-Reader, we decided to prepare high-quality images for rendering intensive pages (many ways in them) and use them instead of PDF pages to avoid performance problems. We decided that this is a good compromise between readability and rendering performance, which leads to ~ 1.5 MB jpegs . 3*768 by 3*1024

However, we tested two implementations for displaying image pages. One that uses a subclass CATiledLayerthat is also responsible for processing the "normal" PDF pages (drawing with CGContextDrawImage), and the other - UIImageView. The latter has the advantage that the display and scaling are very fast, but the memory usage is really bad - 30 MB in memory is required (which is consistent with the size of the bitmap image). Other approaches ( CATiledLayer) take longer to first render the page and take another two seconds to re-render after scaling (similar to PDF pages, but much faster), but do not take up more memory than it takes to display a much smaller image or PDF page.

Does anyone know what is going on behind the scenes, and if you can combine low-memory usage CGContextDrawImagewith high-performance UIImageViewusing the Quartz Framework.

+5
source share
1 answer

Not sure if this question still matters, but if so, maybe this will help:

I fought for the battle to effectively display large views in mine as a tiled image . There is a problem with the main causes of the problem:

  • UIView, UIImageView, -, . drawRect:, , , . , , 4 .
  • CATiledLayer . , - . , , . , API, CATiledLayer CALayer, , .
  • , drawRect: , . UIKit, , .

:

  • , CATiledLayer. fadeDuration 0,25 , , . , , 1.0/60.0, .. . , , , 256x256 . JPEG , .
  • CATiledLayer , UIImageView subviews UIView, . . , UIKit , JPEG .
  • UIImageViews , UIKit, , , JPEG drawRect:. , CALayers, . , .

, , (). / .

+3

More articles:


All Articles