前兩次的分享分別介紹了 ASDK 對(duì)于渲染的優(yōu)化以及 ASDK 中使用的另一種布局模型；這兩個(gè)新機(jī)制的引入分別解決了 iOS 在主線程渲染視圖以及 Auto Layout 的性能問題，而這一次討論的主要內(nèi)容是 ASDK 如何預(yù)先請(qǐng)求服務(wù)器數(shù)據(jù)，達(dá)到看似無限滾動(dòng)列表的效果的。

這篇文章是 ASDK 系列中的最后一篇，文章會(huì)介紹 iOS 中幾種預(yù)加載的方案，以及 ASDK 中是如何處理預(yù)加載的。

不過，在介紹 ASDK 中實(shí)現(xiàn)智能預(yù)加載的方式之前，文章中會(huì)介紹幾種簡(jiǎn)單的預(yù)加載方式，方便各位開發(fā)者進(jìn)行對(duì)比，選擇合適的機(jī)制實(shí)現(xiàn)預(yù)加載這一功能。

網(wǎng)絡(luò)與性能

ASDK 通過在渲染視圖和布局方面的優(yōu)化已經(jīng)可以使應(yīng)用在任何用戶的瘋狂操作下都能保持 60 FPS 的流暢程度，也就是說，我們已經(jīng)充分的利用了當(dāng)前設(shè)備的性能，調(diào)動(dòng)各種資源加快視圖的渲染。

但是，僅僅在 CPU 以及 GPU 方面的優(yōu)化往往是遠(yuǎn)遠(yuǎn)不夠的。在目前的軟件開發(fā)中，很難找到一個(gè)沒有任何網(wǎng)絡(luò)請(qǐng)求的應(yīng)用，哪怕是一個(gè)記賬軟件也需要服務(wù)器來同步保存用戶的信息，防止資料的丟失；所以，只在渲染這一層面進(jìn)行優(yōu)化還不能讓用戶的體驗(yàn)達(dá)到好，因?yàn)榫W(wǎng)絡(luò)請(qǐng)求往往是一個(gè)應(yīng)用最為耗時(shí)以及昂貴的操作。

每一個(gè)應(yīng)用程序在運(yùn)行時(shí)都可以看做是 CPU 在底層利用各種資源瘋狂做加減法運(yùn)算，其中最耗時(shí)的操作并不是進(jìn)行加減法的過程，而是資源轉(zhuǎn)移的過程。

舉一個(gè)不是很恰當(dāng)?shù)睦?，主廚（CPU）在炒一道菜（計(jì)算）時(shí)往往需要的時(shí)間并不多，但是菜的采購(gòu)以及準(zhǔn)備（資源的轉(zhuǎn)移）會(huì)占用大量的時(shí)間，如果在每次炒菜之前，都由幫廚提前準(zhǔn)備好所有的食材（緩存），那么做一道菜的時(shí)間就大大減少了。

而提高資源轉(zhuǎn)移的效率的好辦法就是使用多級(jí)緩存：

從上到下，雖然容量越來越大，直到 Network 層包含了整個(gè)互聯(lián)網(wǎng)的內(nèi)容，但是訪問時(shí)間也是直線上升；在 Core 或者三級(jí)緩存中的資源可能訪問只需要幾個(gè)或者幾十個(gè)時(shí)鐘周期，但是網(wǎng)絡(luò)中的資源就遠(yuǎn)遠(yuǎn)大于這個(gè)數(shù)字，幾分鐘、幾小時(shí)都是有可能的。

更糟糕的是，因?yàn)樘斐木W(wǎng)絡(luò)情況及其復(fù)雜，運(yùn)營(yíng)商劫持 DNS、404 無法訪問等問題導(dǎo)致網(wǎng)絡(luò)問題極其嚴(yán)重；而如何加速網(wǎng)絡(luò)請(qǐng)求成為了很多移動(dòng)端以及 Web 應(yīng)用的重要問題。

預(yù)加載

本文就會(huì)提供一種緩解網(wǎng)絡(luò)請(qǐng)求緩慢導(dǎo)致用戶體驗(yàn)較差的解決方案，也就是預(yù)加載；在本地真正需要渲染界面之前就通過網(wǎng)絡(luò)請(qǐng)求獲取資源存入內(nèi)存或磁盤。

預(yù)加載并不能徹底解決網(wǎng)絡(luò)請(qǐng)求緩慢的問題，而是通過提前發(fā)起網(wǎng)絡(luò)請(qǐng)求緩解這一問題。

那么，預(yù)加載到底要關(guān)注哪些方面的問題呢？總結(jié)下來，有以下兩個(gè)關(guān)注點(diǎn)：

需要預(yù)加載的資源 預(yù)加載發(fā)出的時(shí)間

文章會(huì)根據(jù)上面的兩個(gè)關(guān)注點(diǎn)，分別分析四種預(yù)加載方式的實(shí)現(xiàn)原理以及優(yōu)缺點(diǎn)：

無限滾動(dòng)列表 threshold 惰性加載 智能預(yù)加載 無限滾動(dòng)列表

其實(shí)，無限滾動(dòng)列表并不能算是一種預(yù)加載的實(shí)現(xiàn)原理，它只是提供一種分頁(yè)顯示的方法，在每次滾動(dòng)到UITableView底部時(shí)，才會(huì)開始發(fā)起網(wǎng)絡(luò)請(qǐng)求向服務(wù)器獲取對(duì)應(yīng)的資源。

雖然這種方法并不是預(yù)加載方式的一種，放在這里的主要作用是作為對(duì)比方案，看看如果不使用預(yù)加載的機(jī)制，用戶體驗(yàn)是什么樣的。

很多客戶端都使用了分頁(yè)的加載方式，并沒有添加額外的預(yù)加載的機(jī)制來提升用戶體驗(yàn)，雖然這種方式并不是不能接受，不過每次滑動(dòng)到視圖底部之后，總要等待網(wǎng)絡(luò)請(qǐng)求的完成確實(shí)對(duì)視圖的流暢性有一定影響。

雖然僅僅使用無限滾動(dòng)列表而不提供預(yù)加載機(jī)制會(huì)在一定程度上影響用戶體驗(yàn)，不過，這種需要用戶等待幾秒鐘的方式，在某些時(shí)候確實(shí)非常好用，比如：投放廣告。

QQ 空間就是這么做的，它們投放的廣告基本都是在整個(gè)列表的最底端，這樣，當(dāng)你滾動(dòng)到列表最下面的時(shí)候，就能看到你急需的租房、租車、同城交友、信用卡辦理、只有 iPhone 能玩的游戲以及各種奇奇怪怪的辣雞廣告了，很好的解決了我們的日常生活中的各種需求。

Threshold

使用 Threshold 進(jìn)行預(yù)加載是一種最為常見的預(yù)加載方式，知乎客戶端就使用了這種方式預(yù)加載條目，而其原理也非常簡(jiǎn)單，根據(jù)當(dāng)前UITableView的所在位置，除以目前整個(gè)UITableView.contentView的高度，來判斷當(dāng)前是否需要發(fā)起網(wǎng)絡(luò)請(qǐng)求：

let threshold: CGFloat = 0.7 var currentPage = 0 override func scrollViewDidScroll(_ scrollView: UIScrollView) { let current = scrollView.contentOffset.y + scrollView.frame.size.height let total = scrollView.contentSize.height let ratio = current / total if ratio >= threshold { currentPage += 1 print("Request page \(currentPage) from server.") }}

上面的代碼在當(dāng)前頁(yè)面已經(jīng)劃過了 70% 的時(shí)候，就請(qǐng)求新的資源，加載數(shù)據(jù)；但是，僅僅使用這種方法會(huì)有另一個(gè)問題，尤其是當(dāng)列表變得很長(zhǎng)時(shí)，十分明顯，比如說：用戶從上向下滑動(dòng)，總共加載了 5 頁(yè)數(shù)據(jù)：

| Page | Total | Threshold | Diff | | :-: | :-: | :-: | :-: | | 1 | 10 | 7 | 7 | | 2 | 20 | 14 | 4 | | 3 | 30 | 21 | 1 | | 4 | 40 | 28 | -2 | | 5 | 50 | 35 | -5 |

Page 當(dāng)前總頁(yè)數(shù)； Total 當(dāng)前UITableView總元素個(gè)數(shù)； Threshold 網(wǎng)絡(luò)請(qǐng)求觸發(fā)時(shí)間； Diff 表示最新加載的頁(yè)面被瀏覽了多少；

當(dāng) Threshold 設(shè)置為 70% 的時(shí)候，其實(shí)并不是單頁(yè) 70%，這就會(huì)導(dǎo)致新加載的頁(yè)面都沒有看，應(yīng)用就會(huì)發(fā)出另一次請(qǐng)求，獲取新的資源。

動(dòng)態(tài)的 Threshold

解決這個(gè)問題的辦法，還是比較簡(jiǎn)單的，通過修改上面的代碼，將 Threshold 變成一個(gè)動(dòng)態(tài)的值，隨著頁(yè)數(shù)的增長(zhǎng)而增長(zhǎng)：

let threshold: CGFloat = 0.7 let itemPerPage: CGFloat = 10 var currentPage: CGFloat = 0 override func scrollViewDidScroll(_ scrollView: UIScrollView) { let current = scrollView.contentOffset.y + scrollView.frame.size.height let total = scrollView.contentSize.height let ratio = current / total let needRead = itemPerPage * threshold + currentPage * itemPerPage let totalItem = itemPerPage * (currentPage + 1) let newThreshold = needRead / totalItem if ratio >= newThreshold { currentPage += 1 print("Request page \(currentPage) from server.") }}

通過這種方法獲取的newThreshold就會(huì)隨著頁(yè)數(shù)的增長(zhǎng)而動(dòng)態(tài)的改變，解決了上面出現(xiàn)的問題：

惰性加載

使用 Threshold 進(jìn)行預(yù)加載其實(shí)已經(jīng)適用于大多數(shù)應(yīng)用場(chǎng)景了；但是，下面介紹的方式，惰性加載能夠有針對(duì)性的加載用戶“會(huì)看到的” Cell。

惰性加載，就是在用戶滾動(dòng)的時(shí)候會(huì)對(duì)用戶滾動(dòng)結(jié)束的區(qū)域進(jìn)行計(jì)算，只加載目標(biāo)區(qū)域中的資源。

用戶在飛速滾動(dòng)中會(huì)看到巨多的空白條目，因?yàn)橛脩舨⒉幌腴喿x這些條目，所以，我們并不需要真正去加載這些內(nèi)容，只需要在ASTableView/ASCollectionView中只根據(jù)用戶滾動(dòng)的目標(biāo)區(qū)域惰性加載資源。

惰性加載的方式不僅僅減少了網(wǎng)絡(luò)請(qǐng)求的冗余資源，同時(shí)也減少了渲染視圖、數(shù)據(jù)綁定的耗時(shí)。

計(jì)算用戶滾動(dòng)的目標(biāo)區(qū)域可以直接使用下面的代理方法獲?。?/p>let markedView = UIView() let rowHeight: CGFloat = 44.0 override func scrollViewWillEndDragging(_ scrollView: UIScrollView, withVelocity velocity: CGPoint, targetContentOffset: UnsafeMutablePointer) { let targetOffset = targetContentOffset.pointee let targetRect = CGRect(origin: targetOffset, size: scrollView.frame.size) markedView.frame = targetRect markedView.backgroundColor = UIColor.black.withAlphaComponent(0.1) tableView.addSubview(markedView) var indexPaths: [IndexPath] = [] let startIndex = Int(targetRect.origin.y / rowHeight) let endIndex = Int((targetRect.origin.y + tableView.frame.height) / rowHeight) for index in startIndex...endIndex { indexPaths.append(IndexPath(row: index, section: 0)) } print("\(targetRect) \(indexPaths)")}

以上代碼只會(huì)大致計(jì)算出目標(biāo)區(qū)域內(nèi)的IndexPath數(shù)組，并不會(huì)展開新的 page，同時(shí)會(huì)使用淺黑色標(biāo)記目標(biāo)區(qū)域。

當(dāng)然，惰性加載的實(shí)現(xiàn)也并不只是這么簡(jiǎn)單，不僅需要客戶端的工作，同時(shí)因?yàn)樾枰?strong>加載特定 offset 資源，也需要服務(wù)端提供相應(yīng) API 的支持。

雖然惰性加載的方式能夠按照用戶的需要請(qǐng)求對(duì)應(yīng)的資源，但是，在用戶滑動(dòng)UITableView的過程中會(huì)看到大量的空白條目，這樣的用戶體驗(yàn)是否可以接受又是值得考慮的問題了。

智能預(yù)加載

終于到了智能預(yù)加載的部分了，當(dāng)我第一次得知 ASDK 可以通過滾動(dòng)的方向預(yù)加載不同數(shù)量的內(nèi)容，感覺是非常神奇的。

如上圖所示 ASDK 把正在滾動(dòng)的ASTableView/ASCollectionView劃分為三種狀態(tài)：

Fetch Data Display Visible

上面的這三種狀態(tài)都是由 ASDK 來管理的，而每一個(gè)ASCellNode的狀態(tài)都是由ASRangeController控制，所有的狀態(tài)都對(duì)應(yīng)一個(gè)ASInterfaceState：

ASInterfaceStatePreload當(dāng)前元素貌似要顯示到屏幕上，需要從磁盤或者網(wǎng)絡(luò)請(qǐng)求數(shù)據(jù)； ASInterfaceStateDisplay當(dāng)前元素非常可能要變成可見的，需要進(jìn)行異步繪制； ASInterfaceStateVisible當(dāng)前元素最少在屏幕上顯示了 1px

當(dāng)用戶滾動(dòng)當(dāng)前視圖時(shí)，ASRangeController就會(huì)修改不同區(qū)域內(nèi)元素的狀態(tài)：

上圖是用戶在向下滑動(dòng)時(shí)，ASCellNode是如何被標(biāo)記的，假設(shè)當(dāng)前視圖可見的范圍高度為 1，那么在默認(rèn)情況下，五個(gè)區(qū)域會(huì)按照上圖的形式進(jìn)行劃分：

| Buffer | Size | | :-: | :-: | | Fetch Data Leading Buffer | 2 | | Display Leading Buffer | 1 | | Visible | 1 | | Display Trailing Buffer | 1 | | Fetch Data Trailing Buffer | 1 |

在滾動(dòng)方向（Leading）上 Fetch Data 區(qū)域會(huì)是非滾動(dòng)方向（Trailing）的兩倍，ASDK 會(huì)根據(jù)滾動(dòng)方向的變化實(shí)時(shí)改變緩沖區(qū)的位置；在向下滾動(dòng)時(shí)，下面的 Fetch Data 區(qū)域就是上面的兩倍，向上滾動(dòng)時(shí)，上面的 Fetch Data 區(qū)域就是下面的兩倍。

這里的兩倍并不是一個(gè)確定的數(shù)值，ASDK 會(huì)根據(jù)當(dāng)前設(shè)備的不同狀態(tài)，改變不同區(qū)域的大小，但是滾動(dòng)方向的區(qū)域總會(huì)比非滾動(dòng)方向大一些。

智能預(yù)加載能夠根據(jù)當(dāng)前的滾動(dòng)方向，自動(dòng)改變當(dāng)前的工作區(qū)域，選擇合適的區(qū)域提前觸發(fā)請(qǐng)求資源、渲染視圖以及異步布局等操作，讓視圖的滾動(dòng)達(dá)到真正的流暢。

原理

在 ASDK 中整個(gè)智能預(yù)加載的概念是由三個(gè)部分來統(tǒng)一協(xié)調(diào)管理的：

ASRangeController ASDataController ASTableView與ASTableNode

對(duì)智能預(yù)加載實(shí)現(xiàn)的分析，也是根據(jù)這三個(gè)部分來介紹的。

工作區(qū)域的管理

ASRangeController是ASTableView以及ASCollectionView內(nèi)部使用的控制器，主要用于監(jiān)控視圖的可見區(qū)域、維護(hù)工作區(qū)域、觸發(fā)網(wǎng)絡(luò)請(qǐng)求以及繪制、單元格的異步布局。

以ASTableView為例，在視圖進(jìn)行滾動(dòng)時(shí)，會(huì)觸發(fā)-[UIScrollView scrollViewDidScroll:]代理方法：

- (void)scrollViewDidScroll:(UIScrollView *)scrollView { ASInterfaceState interfaceState = [self interfaceStateForRangeController:_rangeController]; if (ASInterfaceStateIncludesVisible(interfaceState)) { [_rangeController updateCurrentRangeWithMode:ASLayoutRangeModeFull]; } ...}

每一個(gè)ASTableView的實(shí)例都持有一個(gè)ASRangeController以及ASDataController用于管理工作區(qū)域以及數(shù)據(jù)更新。

ASRangeController 最重要的私有方法-[ASRangeController _updateVisibleNodeIndexPaths]一般都是因?yàn)樯厦娴姆椒ㄩg接調(diào)用的：

-[ASRangeController updateCurrentRangeWithMode:] -[ASRangeController setNeedsUpdate] -[ASRangeController updateIfNeeded] -[ASRangeController _updateVisibleNodeIndexPaths]

調(diào)用棧中間的過程其實(shí)并不重要，最后的私有方法的主要工作就是計(jì)算不同區(qū)域內(nèi) Cell 的NSIndexPath數(shù)組，然后更新對(duì)應(yīng) Cell 的狀態(tài)ASInterfaceState觸發(fā)對(duì)應(yīng)的操作。

我們將這個(gè)私有方法的實(shí)現(xiàn)分開來看：

- (void)_updateVisibleNodeIndexPaths { NSArray *allNodes = [_dataSource completedNodes];

本文題目：【成都網(wǎng)站建設(shè)】預(yù)加載與智能預(yù)加載(iOS)-成都創(chuàng)新互聯(lián)官方網(wǎng)站
URL鏈接：http://jinyejixie.com/news/227320.html

網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網(wǎng)站制作，網(wǎng)絡(luò)營(yíng)銷seo公司；服務(wù)項(xiàng)目有網(wǎng)站建設(shè)等

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)