iOS開發(fā)一定要嘗試的 Texture(ASDK)

作者：程序君 2019-05-17 14:55:08

本篇所涉及的性能問題我都將根據(jù)滑動(dòng)的流暢性來評判, 包括掉幀情況和一些實(shí)際體驗(yàn)。參與測試機(jī)型: iPhone 6 10.3.3, iPhone 7 11.2.1, iPhone X 11.2.5, 默認(rèn) iPhone 6。

前言

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

編譯環(huán)境: MacOS 10.13.3, Xcode 9.2
參與測試機(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)化

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

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

圓角

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

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

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

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

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

圖形預(yù)加工

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

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

為什么要使用 ASDK

圖形異步渲染

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

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

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

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

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

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

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

單一的 Cell

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

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

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

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

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

多種 Cell

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

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

ASDK 不用說了, 依舊 59.9

復(fù)用的差別

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

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

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

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

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