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

開發技術 2019/5/18

前言

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

編譯環境: MacOS 10.13.3, Xcode 9.2

參與測試機型: iPhone 6 10.3.3, iPhone 7 11.2.1, iPhone X 11.2.5, 默認 iPhone 6

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

列表滑動卡頓的原因及優化

大牛們把原因都說的很清楚了, 導致的結果就是 16ms 不足以渲染一幀, 產生掉幀卡頓

下面是嘗試過的一些優化:

圓角

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

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

異步裁剪圖片: 通過 UIGraphics 對圖片進行裁剪, 可能造成內存暴漲

數據預加工

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

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

圖形預加工

例如處理圖片遮罩或固定的圖標, 一般是直接使用多層視圖實現

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

為什么要使用 ASDK

圖形異步渲染

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

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

不過低性能設備下還是會出現明顯空白

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

預加載數據和對象

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

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

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

異于原生控件的復用機制

單一的 Cell

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

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

此時的差距主要體現在列表某項數據第一次展示, 以及 TableView 在分頁加載時產生的等待較長, 當然, 這兩點也是可以繼續優化和解決的

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

綜上, 優化得當的情況下, 單一的 Cell 情況下 UIKit 與 ASDK 的差距不明顯

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

多種 Cell

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

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

ASDK 不用說了, 依舊 59.9

復用的差別

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

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

CellNode 與數據源沒有綁定關系: 創建后就算把數據源刪除, TableNode 依然可以正常展示

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

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

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

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

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

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

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

Flex 布局

ASDK 使用的是 Flex 布局, 且面向對象

偷一張圖

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

簡單來說, 缺點只有一個, 就是學習曲線相對 Frame AutoLayout 更陡峭, 而優點是 性能與 Frame 相當, 上手后比 AutoLayout 還簡單。