前言

本篇所涉及的性能問(wèn)題我都將根據(jù)滑動(dòng)的流暢性來(lái)評(píng)判, 包括掉幀情況和一些實(shí)際體驗(yàn)

• 編譯環(huán)境: MacOS 10.13.3, Xcode 9.2
• 參與測(cè)試機(jī)型: iPhone 6 10.3.3, iPhone 7 11.2.1, iPhone X 11.2.5, 默認(rèn) iPhone 6

TableView / TableNode 包含的 TableViewCell / CellNode: 默認(rèn)復(fù)雜程度一般, 包含 1~2 張圖片和 2~4 條文本展示, 圖片有圓角

列表滑動(dòng)卡頓的原因及優(yōu)化

大牛們把原因都說(shuō)的很清楚了, 導(dǎo)致的結(jié)果就是 16ms 不足以渲染一幀, 產(chǎn)生掉幀卡頓

下面是嘗試過(guò)的一些優(yōu)化:

圓角

使用一張圓角圖片覆蓋, 經(jīng)典文章 Corner Rounding(http://texturegroup.org/docs/corner-rounding.html), HYBImageCliped(http://texturegroup.org/docs/corner-rounding.html )也是這么做的

異步裁剪圖片: 通過(guò) UIGraphics 對(duì)圖片進(jìn)行裁剪, 可能造成內(nèi)存暴漲

數(shù)據(jù)預(yù)加工

具體是在 JSON 轉(zhuǎn) Model 后把文本轉(zhuǎn)為富文本, 處理一些弱邏輯等, 之后賦值就可以直接展示了

咳咳, 這個(gè)感覺(jué)不到什么效果

圖形預(yù)加工

例如處理圖片遮罩或固定的圖標(biāo), 一般是直接使用多層視圖實(shí)現(xiàn)

我曾嘗試把三張小圖繪制到一張大圖上再進(jìn)行展示, 于是乎, 異步復(fù)用問(wèn)題除外, 內(nèi)存炸了, 最終還是老老實(shí)實(shí)用多個(gè)視圖實(shí)現(xiàn)

為什么要使用 ASDK

圖形異步渲染

通常我們認(rèn)為 UIKit 是不能渲染于非主線程的, 一旦你這么做, 就可能會(huì)導(dǎo)致崩潰, 無(wú)法正常顯示等問(wèn)題, 而 ASDK 為什么可以呢, 因?yàn)? ASDisplayNode 是線程安全的, Node 創(chuàng)建時(shí), 不會(huì)立即在其內(nèi)部新建 UIView 和 CALayer, 直到主線程***次訪問(wèn)時(shí)才會(huì)生成對(duì)應(yīng)的對(duì)象, 除此之外, 還通過(guò)圖層預(yù)合成和基于 Runloop 的異步并發(fā), 使其擁有更好的性能 ASAsyncTransactionGroup(https://github.com/TextureGroup/Texture/blob/b7cd0b16567a9eb10e58f4cc0886a145dc5273b8/Source/Details/Transactions/_ASAsyncTransactionGroup.m)

這個(gè)特點(diǎn)帶來(lái)的相關(guān)實(shí)際體驗(yàn)就是: 安心的進(jìn)行異步繪圖, 如圓角裁剪, 增加遮罩等, 這在 UIKit 中是足以毀滅人生的, 內(nèi)存暴漲, 異步復(fù)用, 性能極差

不過(guò)低性能設(shè)備下還是會(huì)出現(xiàn)明顯空白

預(yù)加載數(shù)據(jù)和對(duì)象

首先來(lái)一張 Gif 體驗(yàn)一下, 實(shí)際上使用 ASDK 開(kāi)發(fā)完成后對(duì)比也是如此, 有種網(wǎng)速變快了的錯(cuò)覺(jué)

ASDK 中的 ASRangeController, ASTableView, ASCollectionView 相對(duì)于 UIKit 原生控件的特點(diǎn)是可用于監(jiān)控視圖的可見(jiàn)區(qū)域, 維護(hù)工作區(qū)域, 在合適的時(shí)機(jī)觸發(fā)網(wǎng)絡(luò)請(qǐng)求以及繪制, 單元格的異步布局

異于原生控件的復(fù)用機(jī)制

單一的 Cell

意思是某個(gè) List 展示的樣式只有一種, TableView 只需要注冊(cè)一個(gè) Cell

這種情況下, 如果常規(guī)的一些優(yōu)化得當(dāng), 滾動(dòng)的流暢性還是可以接受的(與 ASDK 差距微小, 但仍然肉眼可分辨)

此時(shí)的差距主要體現(xiàn)在列表某項(xiàng)數(shù)據(jù)***次展示, 以及 TableView 在分頁(yè)加載時(shí)產(chǎn)生的等待較長(zhǎng), 當(dāng)然, 這兩點(diǎn)也是可以繼續(xù)優(yōu)化和解決的

相反的, 也就是來(lái)回滑動(dòng)已經(jīng)展示過(guò)的數(shù)據(jù), 兩者的差距就非常小了, 大概是 59.7 - 59.9 和 59.9 的區(qū)別 (我瞎扯的)

綜上, 優(yōu)化得當(dāng)?shù)那闆r下, 單一的 Cell 情況下 UIKit 與 ASDK 的差距不明顯

多種 Cell

表示某 List 中有多種不同的樣式, TableView 必須要通過(guò)注冊(cè) N 個(gè) Cell 來(lái)實(shí)現(xiàn)

這種情況下, 假設(shè)有 5 種 Cell, 屏幕可同時(shí)展示 6 條 Cell, 此時(shí)若***屏幕剛好展示的就包含全部 5 種 Cell , 那么后續(xù)的滑動(dòng)情況將與單一的 Cell表現(xiàn)一致, 若***屏幕展示的內(nèi)容只包含一種, 其他 4 種沒(méi)有在屏幕上出現(xiàn)過(guò), 那么當(dāng)某一種***出現(xiàn)在屏幕上時(shí), 便會(huì)出現(xiàn)明顯的卡頓; 我嘗試過(guò)解決這個(gè)問(wèn)題, 提前創(chuàng)建所有的 Cell 實(shí)例對(duì)象, 緩存和復(fù)用相同的子視圖, 異步預(yù)繪制為一張圖片并緩存(坑), 都收效漸微

ASDK 不用說(shuō)了, 依舊 59.9

復(fù)用的差別

TableView 的復(fù)用機(jī)制我是既愛(ài)又恨的, 方便之處在于直接與數(shù)據(jù)綁定后, 可以方便的更新和修改, 只需保證 setModel 簡(jiǎn)潔就 OK, 只是當(dāng)業(yè)務(wù)綁定較多時(shí)就比較麻煩了

下面重點(diǎn)說(shuō)說(shuō) TableNode, TableNode 的復(fù)用機(jī)制就是沒(méi)有復(fù)用, 只有緩存, 每個(gè) CellNode 都是全新的, 因此會(huì)有一些特殊的地方:

• CellNode 與數(shù)據(jù)源沒(méi)有綁定關(guān)系: 創(chuàng)建后就算把數(shù)據(jù)源刪除, TableNode 依然可以正常展示
• 數(shù)據(jù)直接決定要?jiǎng)?chuàng)建一個(gè)怎樣的 CellNode: 這一點(diǎn)很重要, TableViewCell 的展示大致為: 添加空假數(shù)據(jù)子視圖 -> 數(shù)據(jù)填充 -> 刷新, 涉及布局或圖文時(shí)會(huì)更復(fù)雜
• CellNode 只有一步: 添加真數(shù)據(jù)的子視圖; 因此可以直接根據(jù)業(yè)務(wù)邏輯對(duì)控件和布局做出處理, 而不用一次或多次刷新
• Demo: 此處需求為每組一個(gè)大圖 + N個(gè)小圖, 每組 3 或 5 個(gè)

• 解決思路: TableView 的方式是創(chuàng)建 5 個(gè), 根據(jù)數(shù)量顯隱下面兩個(gè), 或者兩種 Cell, 把 3 和 5 的情況分別對(duì)應(yīng), 除此之外, 最重要的是: 祈禱數(shù)據(jù)正常, 每組數(shù)據(jù)個(gè)數(shù)僅為 3 或 5

此時(shí)若使用 TableNode 就靈活多了, 可以根據(jù)需要(數(shù)據(jù)個(gè)數(shù)), 加入需要的子視圖, 我的思路是把頂部的大圖固定, 剩下的兩個(gè)為一行進(jìn)行添加, 就算總數(shù)為偶數(shù)也是沒(méi)有任何額外消耗的, 具體參見(jiàn) ASDKDemo(https://github.com/didez/ASDK-Demo/tree/master/ASDKDemo)

Flex 布局

ASDK 使用的是 Flex 布局, 且面向?qū)ο?/p>

偷一張圖

簡(jiǎn)單來(lái)說(shuō), 缺點(diǎn)只有一個(gè), 就是學(xué)習(xí)曲線相對(duì) Frame AutoLayout 更陡峭, 而優(yōu)點(diǎn)是 性能與 Frame 相當(dāng), 上手后比 AutoLayout 還簡(jiǎn)單。