iOS開發(fā)之加載、滑動翻閱大量圖片優(yōu)化解決方案
今天分享一下私人相冊中,讀取加載、滑動翻閱大量圖片解決方案,我想強調(diào)的是,編程思想無關(guān)乎平臺限制。
我要詳細說一下,在縮略圖界面點擊任意小縮略圖后,進入高清大圖全屏瀏覽界面的這短暫的1秒內(nèi)(和后續(xù)的幾秒),都發(fā)生了什么。
常規(guī)思路流程
點擊任意小圖后,
1.首先制作scrollview框架:大小2個scrollview,小的用于手勢縮放單一圖片,大的橫向依次加載全部照片
2.制作好scrollview框架后,加載照片
3.一切準(zhǔn)備就緒跳轉(zhuǎn)頁面呈現(xiàn)給用戶選擇的大圖
加載圖片這一步,若相冊內(nèi)就10幾張照片,那么毫無技術(shù)挑戰(zhàn),但是如果是300張照片呢?直接崩潰?還是讓用戶等待加載? 時間緊任務(wù)重,這一步需要拆分和優(yōu)化.
scrollview框架需要了解下API,然后動動腦子了,這里有個小竅門,很多人都問我照片與照片間的黑邊間距怎么實現(xiàn),呵呵,貼下代碼:
- #define PADDING 20
- - (NSInteger)loadPhotos
- {
- //清理之前照片
- for (UIView *v in [_scrollView subviews]) {
- [v removeFromSuperview];
- }
- workingFrame = [[UIScreen mainScreen]bounds];
- workingFrame.origin.x = PADDING;
- for (int i = 0; i < int_total; i++) {
- CGRect frame = workingFrame;
- WQPhoto *photoView = [[WQPhoto alloc] initWithFrame:frame];
- [photoView setScroller:self];
- [photoView setIndex:i];
- WQAlbumPhoto *photo = [albumObject._photos objectAtIndex:i];
- [photo cleanThumbnail];
- if (i == int_current) {
- //加載原圖
- [photoView setImage:photo.oriImage];
- [photoView setIsLoad:YES];
- }else if (int_current - 10 < i && i < int_current + 10){
- //加載左右臨近的縮略圖
- [photoView setImage:photo.thumbnail4view];
- }
- [_scrollView addSubview:photoView];
- workingFrame.origin.x = workingFrame.origin.x + 2 * PADDING
- + workingFrame.size.width;
- }
- //實現(xiàn)可滾動
- [_scrollView setContentSize:CGSizeMake(workingFrame.origin.x, workingFrame.size.height / 2)];
- [_scrollView setContentOffset:CGPointMake(360 * int_current, 0)];
- //加載其余縮略圖
- loadThread = [[NSThread alloc]initWithTarget:self selector:@selector(loadImages) object:nil];
- return 0;
- }
使用低分辨率圖
仔細想想,其實沒有必要***時間加載全部圖片的高清原圖,事先存好每張圖配套的低分辨率圖,用空間換時間。
先加載所有的圖片的低分辨率圖, 當(dāng)用戶翻閱到某一張圖片時, 即時的加載原始尺寸的高清無碼大圖. 過程優(yōu)化為:
多線程任務(wù)
即使是這樣,當(dāng)照片數(shù)量達到一定量時,需要消耗的時間也并非毫秒級,體驗無法領(lǐng)人滿意, 頁面跳轉(zhuǎn)時仍然會出現(xiàn)卡頓現(xiàn)象。
于是考慮使用多線程來進一步拆分任務(wù), 執(zhí)行跳轉(zhuǎn)的同時再后臺執(zhí)行加載低分辨率圖的步驟.
優(yōu)化快速翻閱體驗
通過這樣的拆分,可以實現(xiàn)立即跳轉(zhuǎn),體驗滿意。但是翻閱瀏覽時,當(dāng)用戶很快左右滑動時, 出現(xiàn)黑屏的幾率很高, 因為加載低分辨率圖任務(wù)的線程可能還在進行大量IO操作,不能及時跟上。 為了完善它,要把加載低分辨率圖的步驟再次分解,精益求精。
在頁面跳轉(zhuǎn)時間允許的范圍內(nèi),加載用戶選定的那張圖片的高清原圖的同時,盡可能多的加載幾張左右臨近的圖片的低分辨率圖。
如何加載其余的低分辨率圖?
以用戶點擊選定的那張圖為中心向兩邊加載, 直接想應(yīng)該是兩個線程一左一右的加載,再想想左右一起加載其實可以是一個循環(huán), 免了再開線程的那些耗費了。
- -(BOOL)loadImages
- {
- for (int i = int_current - 10, j = int_current + 10 ; !( i < 0 && int_total - 1 < j); --i, ++j) {
- if (!(i < 0)) {
- WQPhoto *photo_pre = [_scrollView.subviews objectAtIndex:i];
- WQAlbumPhoto *photoPre = [albumObject._photos objectAtIndex:i];
- [photo_pre setImage:photoPre.thumbnail4view];
- }
- if (!(int_total - 1 < j)) {
- WQPhoto *photo_next = [_scrollView.subviews objectAtIndex:j];
- WQAlbumPhoto *photoNext = [albumObject._photos objectAtIndex:j];
- [photo_next setImage:photoNext.thumbnail4view];
- }
- }
- return YES;
- }
***還一個砍兒
盡量減少內(nèi)存占用. 因為原始圖片要比低分辨率圖大很多, 所以當(dāng)用戶從一張圖片翻閱到另一張圖片時, 當(dāng)前圖片加載為原始尺寸的高清大圖, 而原來那張就被替換為低分辨率圖了。 雖然讀寫次數(shù)增多了, 但內(nèi)存確實省了不少。
實話說,市場上不少相冊類的app, 翻閱時都會有卡頓的跳躍感,呵呵……