上篇介紹了一些Realm數(shù)據(jù)庫(kù)的基礎(chǔ)知識(shí)，本篇將介紹數(shù)據(jù)分頁(yè)與列表復(fù)用原理，希望對(duì)大家有所幫助，如有錯(cuò)誤請(qǐng)指正。
iOS Realm數(shù)據(jù)持久化--Realm基礎(chǔ)知識(shí) （一）
iOS Realm數(shù)據(jù)持久化--數(shù)據(jù)分頁(yè)與復(fù)用原理 （二）
iOS Realm數(shù)據(jù)持久化--List容器分頁(yè)（三）
iOS Realm數(shù)據(jù)持久化--Realm集合分頁(yè)（四）
1、數(shù)據(jù)分頁(yè)
1.1 為何要分頁(yè)加載
隨著智能設(shè)備的普及，信息以指數(shù)級(jí)增長(zhǎng)，移動(dòng)設(shè)備與后臺(tái)交互復(fù)雜度也不斷上升：
（1）移動(dòng)設(shè)備容納海量服務(wù)器數(shù)據(jù)。
（2）帶寬優(yōu)先、流量資源寶貴，不適宜一次拉取過(guò)多的數(shù)據(jù)。
（3）設(shè)備性能不足，一次載入過(guò)多數(shù)據(jù)會(huì)導(dǎo)致處理時(shí)間過(guò)長(zhǎng)，影響交互體驗(yàn)。
（4）設(shè)備內(nèi)存占用過(guò)多將會(huì)導(dǎo)致APP被系統(tǒng)Kill。
要解決上述問(wèn)題，提高App交互體驗(yàn)，我們需要做多方面的功課：
（1）客戶(hù)端限量依次拉取數(shù)據(jù)
（2）對(duì)數(shù)據(jù)壓縮編碼，減少冗余
（3）服務(wù)器節(jié)點(diǎn)和帶寬優(yōu)化
就客戶(hù)端而言主要還是解決數(shù)據(jù)冗余和拉取問(wèn)題，JSON是目前通用數(shù)據(jù)格式，解決冗余問(wèn)題只需減少無(wú)用字段即可（如果要求非常高可以使用非Http協(xié)議并采用二級(jí)制數(shù)據(jù)編碼，如protocolBuffer方案），數(shù)據(jù)拉取則需要采用分頁(yè)方案解決：
（1）首次進(jìn)入App從服務(wù)器或者磁盤(pán)讀取最新的M條數(shù)據(jù)，M不益過(guò)大
（2）瀏覽到第一條，觸發(fā)分頁(yè)交互，加載最新的M條數(shù)據(jù)到內(nèi)存
（3）瀏覽到最后一條數(shù)據(jù)，觸發(fā)分頁(yè)交互，加載之后的M條歷史數(shù)據(jù)到內(nèi)存
（4）響應(yīng)數(shù)據(jù)只提供基本概要，避免將無(wú)用的內(nèi)容加載到內(nèi)存
（5）根據(jù)所在地區(qū)尋找最新的服務(wù)器節(jié)點(diǎn)提高訪問(wèn)速度
1.2 常見(jiàn)的分頁(yè)交互方案
分頁(yè)設(shè)計(jì)幾乎是聯(lián)網(wǎng)App的標(biāo)配，常見(jiàn)的有Feed流、IM消息等，交互流程大致如下：
IM分頁(yè)（IM消息列表通常只有下拉刷新）
（1）進(jìn)入會(huì)話(huà)加載最新M條數(shù)據(jù)，M通常為10-20條
（2）滾動(dòng)到列表頂部觸發(fā)下拉刷新或者自動(dòng)加載M條歷史數(shù)據(jù)（通常使用timeStamp作為查詢(xún)標(biāo)志）
（3）發(fā)送文本、圖片、位置等插入一條或多條新消息數(shù)據(jù)
Feed流分頁(yè)（Feed流通常包含上、下拉刷新或者只有上拉刷新等操作）
（1）進(jìn)入頁(yè)面加載最新M條數(shù)據(jù)，M通常為10-20條
（2）滾動(dòng)到頁(yè)面底部觸發(fā)上拉刷新或者自動(dòng)加載M條歷史數(shù)據(jù)到內(nèi)存
（3）滾動(dòng)到頁(yè)面頂部觸發(fā)下拉刷新或者自動(dòng)加載最新M條數(shù)據(jù)到內(nèi)存
實(shí)際上很多App受復(fù)雜的數(shù)據(jù)緩存、數(shù)據(jù)提取算法等影響，實(shí)際分頁(yè)策略不盡相同，但基礎(chǔ)交互并無(wú)差異，這里不做詳細(xì)討論。有興趣的可以去了解微信朋友圈、微信聊天、新浪微博等分頁(yè)邏輯。
2、表視圖
設(shè)計(jì)數(shù)據(jù)分頁(yè)不得不提到表視圖，表視圖是移動(dòng)開(kāi)發(fā)最重要的一章，使用極為頻繁，CocoaTouch框架提供了UITableView和UICollectionView兩種類(lèi)型的表視圖，使用簡(jiǎn)潔方便，熟練掌握好表視圖的相關(guān)特性和原理有助于我們更好的自定義表視圖。
2.1 為何要進(jìn)行數(shù)據(jù)復(fù)用
移動(dòng)設(shè)備的CPU和GPU硬件配置和運(yùn)算性能遠(yuǎn)不如桌面電腦，早期的iOS設(shè)備只有256M內(nèi)存，可供App使用的不到30M，超出這個(gè)限制App就會(huì)被系統(tǒng)殺掉，目前最新的iOS設(shè)備如果內(nèi)存占用400M以上依然可能因?yàn)閮?nèi)存警告被系統(tǒng)Kill。為了減少內(nèi)存占用，我們需要盡可能的利用已分配的資源來(lái)展示信息，UITableView和UICollectionView正是基于此考慮采用了復(fù)用模式。
2.2 復(fù)用的原理
UITableView和UICollectionView并非將每一個(gè)Item都綁定一個(gè)對(duì)應(yīng)的單元格Cell，如果你非要這么干（棄用復(fù)用模式），雖然數(shù)據(jù)可以正常顯示，但已背離了設(shè)計(jì)初衷，更糟糕的是過(guò)多的數(shù)據(jù)會(huì)導(dǎo)致同等量的Cell載入內(nèi)存，并且列表滾動(dòng)時(shí)新的Cell不斷生成，內(nèi)存消耗也不斷增加，App很快會(huì)變得卡頓然后被系統(tǒng)終結(jié)，這一定是你不愿意遇見(jiàn)的。
下圖展示了UITableViewCell的復(fù)用的基本原理（實(shí)際要復(fù)雜很多）：
如上圖，UITableView只在屏幕可見(jiàn)區(qū)域申請(qǐng)若干個(gè)UITableViewCell（具體申請(qǐng)數(shù)量跟Cell 的identifier也相關(guān)）,滾動(dòng)的時(shí)候?qū)?code>Cell綁定新的數(shù)據(jù)源，這種設(shè)計(jì)可以保持內(nèi)存占用在一個(gè)較低的水平。
2.2 如何提高列表滾動(dòng)的流暢性
列表滾動(dòng)卡頓是一個(gè)很糟糕的體驗(yàn)，應(yīng)該盡量避免以下操作：
（1）列表數(shù)據(jù)占用太多內(nèi)存資源，觸發(fā)內(nèi)存警告或App閃退
（2）消耗大量CPU和GPU資源進(jìn)行界面渲染與繪制
（3）計(jì)算結(jié)果不做預(yù)緩存，每次復(fù)用都反復(fù)計(jì)算
（4）在主線(xiàn)程執(zhí)行耗時(shí)的任務(wù)
避免卡頓有助于提高列表滾動(dòng)流暢性，可以從以下幾個(gè)方面著手：
（1）減少界面渲染與繪制的資源消耗，如優(yōu)化圓角與陰影，減少透明圖層，避免子視圖的反復(fù)申請(qǐng)，子線(xiàn)程異步處理。
（2）緩存計(jì)算結(jié)果 ，避免對(duì)非動(dòng)態(tài)變化數(shù)據(jù)反復(fù)計(jì)算，如將高度、格式化時(shí)間、富文本、轉(zhuǎn)換后的數(shù)據(jù)模型等做內(nèi)存緩存。
（3）減少內(nèi)存占用，如采用分頁(yè)加載、懶加載，緩存失效、單元格復(fù)用等。
