您好,登錄后才能下訂單哦!
這篇文章主要介紹怎么在iOS中高效的加載圖片,文中介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們一定要看完!
在iOS中使用 UIImage和UIImageView來(lái)記載圖片,他倆遵守經(jīng)典的MVC架構(gòu),UIImage相當(dāng)于Model,UIImageView相當(dāng)于View:
UIImage負(fù)責(zé)加載圖片,UIImageView負(fù)責(zé)渲染圖片。
圖片的渲染流程分為3個(gè)階段:加載(Load),解碼(Decoder)和渲染(Render)
在每個(gè)階段都會(huì)有相對(duì)應(yīng)的緩沖區(qū):數(shù)據(jù)緩沖區(qū)(DataBuffer),圖像緩沖區(qū)(imageBuffer)和幀緩沖區(qū)(framebuffer)。
我們以加載一個(gè)圖片的尺寸為:2048 px * 1536 px,在磁盤(pán)上的大小為:590kb的圖片為例,來(lái)分析前兩個(gè)階段的緩沖區(qū)。
DataBuffer只是一種包含一系列字節(jié)的緩沖區(qū)。通常以某些元數(shù)據(jù)開(kāi)頭,元數(shù)據(jù)描述了存儲(chǔ)在數(shù)據(jù)緩沖區(qū)中的圖像大小,包含圖形數(shù)據(jù)本身,圖像數(shù)據(jù)以某種形式編碼 如 JPEG壓縮或PNG,這意味著,該字節(jié)并不直接描述圖像中像素的任何內(nèi)容。此時(shí)的 DataBuffer大小為 590kb。
在SDWebImage中,圖片加載完成后,在 sd_imageFormatForImageData的方法中,是通過(guò)DataBuffer的第一個(gè)字節(jié)來(lái)判斷圖片的格式的。
uint8_t c; [data getBytes:&c length:1]; switch (c) { case 0xFF: return SDImageFormatJPEG; case 0x89: return SDImageFormatPNG; case 0x47: retur SDImageFormatGIF; case 0x49: case 0x4D: return SDImageFormatTIFF; ...... }
在圖片加載完后,需要將Data Buffer的JPEG,PNG或其他編碼的數(shù)據(jù),轉(zhuǎn)換為每個(gè)像素的圖像信息,這個(gè)過(guò)程,稱(chēng)為Decoder(解碼),將像素信息存放在ImageBuffer。
圖片占用的內(nèi)存大小與圖像的尺寸有關(guān),與它的文件大小無(wú)關(guān),在iOSSRGB顯示格式中(4byte空間顯示一個(gè)像素),如果解析所有的像素,需要 2048 px * 1536 px * 4 byte/px = 10MB的空間,此時(shí)的 ImageBuffer的大小為10MB。
在ImageBuffer解析完后,提交給frameBuffer進(jìn)行渲染顯示。
總的來(lái)說(shuō),圖片加載過(guò)程和消耗的內(nèi)存如下圖所示:
在Xcode工程中,當(dāng)push新頁(yè)面的時(shí)候,只加載一個(gè)圖片。
加載前內(nèi)存值:
加載后內(nèi)存值:
大多數(shù)情況下,我們并不需要如此高精度的顯示圖片,占用了這么多的內(nèi)存,能否減少加載圖片時(shí)占用的內(nèi)存值呢?
在蘋(píng)果官方文檔中,建議我們使用向下采樣(Downsampleing)的技術(shù),來(lái)加載圖片,減少I(mǎi)mageBuffer的大小。
方法如下:
func downsample(imageAt imageURL: URL, to pointSize:CGSize, scale:CGFloat) ->UIImage { let imageSourcesOptions = [kCGImageSourceShouldCache: false] as CFDictionary let imageSource = CGImageSourceCreateWithURL(imageURL as CFURL, imageSourcesOptions)! let maxDimensionInPixels = max(pointSize.width, pointSize.height) * scale let downsampleOptions = [ kCGImageSourceCreateThumbnailFromImageAlways: true, kCGImageSourceShouldCacheImmediately: true, kCGImageSourceCreateThumbnailWithTransform: true, kCGImageSourceThumbnailMaxPixelSize:maxDimensionInPixels ] as CFDictionary let downsampledImage = CGImageSourceCreateThumbnailAtIndex(imageSource, 0, downsampleOptions)! return UIImage(cgImage: downsampledImage) }
我們來(lái)測(cè)試一下:
let imageStr = Bundle.main.path(forResource: "view_site.jpeg", ofType: nil) let imageURL = URL(string: "file://" + (imageStr ?? "")) guard let imgURL = imageURL else { return } imageView.image = downsample(imageAt:imgURL , to: CGSize(width: 200, height: 200), scale: UIScreen.main.scale)
加載之前時(shí)是13M,加載之后是 17M,效果是很明顯的,節(jié)省了大約 5M的內(nèi)存空間。
在對(duì)圖片進(jìn)行壓縮時(shí),我們應(yīng)首選向下采樣技術(shù)。
在SDWebIamge中,一共有3種類(lèi)型的解碼器:SDImageIOCoder, SDImageGIFCoder, SDImageAPNGCoder,根據(jù)DataBuffer的編碼類(lèi)型,使用相對(duì)應(yīng)的編碼器。
在 -(UIImage *)decodedImageWithData:(NSData *)data方法中,配置解碼參數(shù),開(kāi)始進(jìn)行解碼操作。
在 + (UIImage *)createFrameAtIndex:(NSUInteger)index source:(CGImageSourceRef)source scale:(CGFloat)scale preserveAspectRatio:(BOOL)preserveAspectRatio thumbnailSize:(CGSize)thumbnailSize options:(NSDictionary )options 中,完成圖像解碼
在 iOS中,渲染圖片格式有4種
Alpha 8 Format:1字節(jié)顯示1像素,擅長(zhǎng)顯示單色調(diào)的圖片。
Luminance and alpha 8 format: 亮度和 alpha 8 格式,2字節(jié)顯示1像素,擅長(zhǎng)顯示有透明度的單色調(diào)圖片。
SRGB Format: 4個(gè)字節(jié)顯示1像素。
Wide Format: 廣色域格式,8個(gè)字節(jié)顯示1像素。適用于高精度圖片,
正確的思路是:不選擇渲染格式,讓渲染格式選擇你。
使用 UIGraphicsImageRender來(lái)替換UIGraphicsBeginImageContextWithOptions,前者在iOS12以后,會(huì)自動(dòng)選擇渲染格式,后者默認(rèn)都會(huì)選擇SRGB Format。
func render() -> UIImage{ let bounds = CGRect(x: 0, y: 0, width: 300, height: 100) let render = UIGraphicsImageRenderer(size: bounds.size) let image = render.image { context in UIColor.blue.setFill() let path = UIBezierPath(roundedRect: bounds, byRoundingCorners: UIRectCorner.allCorners, cornerRadii: CGSize(width: 20, height: 20)) path.addClip() UIRectFill(bounds) } return image }
此時(shí),系統(tǒng)為自動(dòng)選擇Alpha 8 Format格式,內(nèi)容空間占用,將會(huì)減少75%。
在需要繪制帶有子視圖的View時(shí),不使用 draw(rect:)方法,使用系統(tǒng)的View屬性或者添加子視圖的方式,將繪制工作交給系統(tǒng)來(lái)處理。
背景色直接通過(guò)UIView.backgroundColor設(shè)置,而非使用draw(rect:)
我們?cè)陂_(kāi)發(fā)中,一般會(huì)對(duì)圖片進(jìn)行子線程異步加載,在后臺(tái)進(jìn)行 解碼和下采樣。在列表中,有時(shí)會(huì)加載很多圖片,此時(shí)應(yīng)該注意線程爆炸問(wèn)題。
當(dāng)我們要求系統(tǒng)去做比CPU能夠做的工作更多的工作時(shí)就會(huì)發(fā)生這種情況,比如我們要顯示8張圖片,但我們只有兩個(gè)CPU,就不能一次完成所有這些工作,無(wú)法在不存在的CPU上進(jìn)行并行處理,為了避免向一個(gè)全局隊(duì)列中異步的分配任務(wù)時(shí)發(fā)生死鎖,GCD將創(chuàng)建新線程來(lái)捕捉我們要求它所做的工作,然后CPU將花費(fèi)大量時(shí)間,在這些線程之間進(jìn)行切換,嘗試在所有工作上取得我們要求操作系統(tǒng)為我們做的漸進(jìn)式進(jìn)展,在這些線程之間不停切換,實(shí)際上是相當(dāng)大的開(kāi)銷(xiāo),現(xiàn)在不是簡(jiǎn)單地將工作分派到全局異步隊(duì)列之一,而是創(chuàng)建一個(gè)串行隊(duì)列,在預(yù)取的方法中,異步的將工作分派到該隊(duì)列,它的確意味著單個(gè)圖像的加載,可能要比以前晚才能開(kāi)始取得進(jìn)展,但CPU將花費(fèi)更少的時(shí)間,在它可以做的小任務(wù)之間來(lái)回切換。
在SDWebImage中,解碼的隊(duì)列 _coderQueue.maxConcurrentOperationCount = 1就是一個(gè)串行隊(duì)列。這樣就很好的解決了多圖片異步解碼時(shí),線程爆炸問(wèn)題。
以上是“怎么在iOS中高效的加載圖片”這篇文章的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對(duì)大家有幫助,更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。