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

開發(fā)技術(shù) 2019/5/18

前言

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

編譯環(huán)境: MacOS 10.13.3, Xcode 9.2

參與測試機型: 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 條文本展示, 圖片有圓角

列表滑動卡頓的原因及優(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 )也是這么做的

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

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

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

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

咳咳, 這個感覺不到什么效果

圖形預(yù)加工

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

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

為什么要使用 ASDK

圖形異步渲染

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

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

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

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

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

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

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

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

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

單一的 Cell

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

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

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

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

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

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

多種 Cell

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

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

ASDK 不用說了, 依舊 59.9

復(fù)用的差別

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

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

CellNode 與數(shù)據(jù)源沒有綁定關(guān)系: 創(chuàng)建后就算把數(shù)據(jù)源刪除, TableNode 依然可以正常展示

數(shù)據(jù)直接決定要創(chuàng)建一個怎樣的 CellNode: 這一點很重要, TableViewCell 的展示大致為: 添加空假數(shù)據(jù)子視圖 -> 數(shù)據(jù)填充 -> 刷新, 涉及布局或圖文時會更復(fù)雜

CellNode 只有一步: 添加真數(shù)據(jù)的子視圖; 因此可以直接根據(jù)業(yè)務(wù)邏輯對控件和布局做出處理, 而不用一次或多次刷新

Demo: 此處需求為每組一個大圖 + N個小圖, 每組 3 或 5 個

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

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

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

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

Flex 布局

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

偷一張圖

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

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