引言

在移動應用中，雙狀態(tài)動畫切換是最常見的交互模式之一：

• TabBar圖標的聚焦/失焦狀態(tài)
• 按鈕的選中/未選中狀態(tài)
• 開關(guān)的開啟/關(guān)閉狀態(tài)

當使用Lottie實現(xiàn)這類需求時，傳統(tǒng)方案面臨兩大痛點：

• 啟動阻塞：同步加載動畫資源導致主線程卡頓
• 切換卡頓：狀態(tài)變化時重復解析JSON文件

本文將揭示如何通過三次漸進式優(yōu)化，構(gòu)建高性能的雙狀態(tài)動畫解決方案。

1.第一階段：基礎方案（同步阻塞模式）

原始實現(xiàn)方案

在初始實現(xiàn)中，我們直接在主線程同步加載動畫資源。以下是代碼實現(xiàn)：

class DualStateLottieView: UIView {
    privatevar animationView: LottieAnimationView!
    
    init(activePath: String, inactivePath: String) {
        // 同步加載失焦狀態(tài)動畫（阻塞主線程）
        animationView = LottieAnimationView(filePath: inactivePath)
        super.init(frame: .zero)
        addSubview(animationView)
    }
    
    func setActive(_ isActive: Bool) {
        let path = isActive ? activePath : inactivePath
        
        // 每次切換都重新加載（性能黑洞?。?        animationView.removeFromSuperview()
        animationView = LottieAnimationView(filePath: path)
        addSubview(animationView)
        animationView.play()
    }
}

• 初始化動畫視圖：在 init 方法中，我們直接通過 LottieAnimationView(filePath:) 同步加載失焦狀態(tài)的動畫資源；這種方式會阻塞主線程，直到動畫資源加載完成。如果資源較大或網(wǎng)絡延遲，會導致明顯的卡頓。
• 狀態(tài)切換邏輯：在 setActive(_:) 方法中，根據(jù)傳入的布爾值 isActive，選擇對應的動畫路徑；每次狀態(tài)切換時，都會移除當前的 animationView，重新創(chuàng)建一個新的 LottieAnimationView 實例，并加載對應的動畫資源；

這種方式不僅會導致主線程卡頓，還會頻繁地創(chuàng)建和銷毀視圖對象，進一步增加性能開銷。

執(zhí)行流程分析

以下是狀態(tài)切換的執(zhí)行流程圖：

圖片

性能瓶頸分析

圖片

通過分析可以得出以下幾點性能瓶頸：

1. 主線程阻塞：在初始化和狀態(tài)切換時，LottieAnimationView(filePath:) 的調(diào)用會同步加載動畫資源，這會阻塞主線程；如果動畫資源較大或加載路徑較慢（如從網(wǎng)絡加載），會導致明顯的卡頓。
2. 重復解析 JSON 文件：每次狀態(tài)切換時，都會重新加載和解析 JSON 文件。這不僅增加了 I/O 開銷，還導致了不必要的重復計算。
3. 資源加載與視圖渲染強耦合：動畫資源的加載和視圖的渲染緊密耦合，導致每次狀態(tài)切換都需要重新加載資源并重新渲染視圖；這種方式在高頻操作時會導致性能急劇下降，用戶體驗極差。

核心缺陷：資源加載與視圖渲染強耦合，導致高頻操作時性能急劇下降

2.第二階段：異步加載與緩存（性能優(yōu)化）

架構(gòu)改造方案

為了優(yōu)化性能，我們對代碼進行了架構(gòu)改造，引入了異步加載和緩存機制。以下是改造后的代碼實現(xiàn)：

class DualStateLottieView: UIView {
    // 動畫數(shù)據(jù)緩存
    privatevar activeAnimation: LottieAnimation?
    privatevar inactiveAnimation: LottieAnimation?
    
    // 視圖實例
    privatelet animationView = LottieAnimationView()
    
    func loadResources() {
        // 異步加載主動畫
        DispatchQueue.global().async {
            let anim = LottieAnimation.filepath(activePath)
            DispatchQueue.main.async {
                self.activeAnimation = anim
            }
        }
        
        // 異步加載被動畫...
    }
    
    func setActive(_ isActive: Bool) {
        animationView.animation = isActive ? activeAnimation : inactiveAnimation
        animationView.play()
    }
}

• 動畫數(shù)據(jù)緩存：引入了兩個變量 activeAnimation 和 inactiveAnimation，分別用于緩存主動畫和被動畫的數(shù)據(jù)；這樣可以避免每次狀態(tài)切換時重新加載和解析動畫資源。
• 異步加載資源：在 init 方法中，使用 DispatchQueue.global().async 在后臺線程中加載動畫資源；加載完成后，通過 DispatchQueue.main.async 將動畫數(shù)據(jù)更新到主線程的緩存變量中；這種方式將文件 I/O 和 JSON 解析操作移出主線程，避免了主線程的阻塞。
• 狀態(tài)切換邏輯：在 setActive(_:) 方法中，直接從緩存中獲取對應的動畫數(shù)據(jù)，并設置給 animationView；這樣可以快速切換動畫狀態(tài)，而無需重新加載資源。

性能優(yōu)化點

• 主線程零阻塞：初始化時僅創(chuàng)建輕量級的 animationView 容器視圖，耗時小于 1ms，不會阻塞主線程；動畫資源的加載和解析都在后臺線程完成，不會影響主線程的響應速度。
• 資源異步加載：通過后臺線程加載動畫資源，避免了主線程的 I/O 操作和 JSON 解析，顯著提升了性能。
• 動畫數(shù)據(jù)復用：使用 LottieAnimation 對象緩存動畫數(shù)據(jù)，避免了重復解析 JSON 文件，減少了不必要的計算開銷。

但是這種方案并不完善，產(chǎn)生了新的問題。

新問題浮現(xiàn)

盡管引入了異步加載和緩存機制，但在測試中發(fā)現(xiàn)了一個新問題：

測試發(fā)現(xiàn)：快速切換時出現(xiàn)狀態(tài)丟失，動畫不響應，這是為什么呢？——狀態(tài)切換失?。?/p>

• 當用戶快速切換狀態(tài)時，可能會出現(xiàn)動畫數(shù)據(jù)尚未加載完成的情況；
• 例如，用戶調(diào)用 setActive(true) 時，activeAnimation 可能還沒有加載完成，導致 animationView.animation 被設置為 nil，動畫無法正常播放。

通過引入異步加載和緩存機制，我們顯著提升了動畫切換的性能，消除了主線程的阻塞問題。然而，快速切換時的狀態(tài)丟失問題仍然需要進一步優(yōu)化。下一階段將通過狀態(tài)機和 Pending 機制來解決這一問題。

3.第三階段：狀態(tài)機與Pending機制（健壯性增強）

狀態(tài)機設計

為了處理動畫加載和狀態(tài)切換的時序問題，我們引入了狀態(tài)機和Pending機制。以下是狀態(tài)機的設計：

enum AnimationState {
    case active
    case inactive
    case pendingActive  // 新增中間狀態(tài)
    case pendingInactive
}

private var currentState: AnimationState = .inactive

1. 狀態(tài)定義：active：當前顯示主動畫；inactive：當前顯示被動畫；pendingActive：正在加載主動畫，但尚未完成；pendingInactive：正在加載被動畫，但尚未完成。
2. 狀態(tài)管理：通過 currentState 變量記錄當前的狀態(tài)，確保狀態(tài)切換的邏輯清晰且可控。

Pending機制實現(xiàn)

func setActive(_ isActive: Bool) {
    let targetState: AnimationState = isActive ? .active : .inactive
    
    switch (targetState, activeAnimation, inactiveAnimation) {
    case (.active, let anim?, _):
        play(animation: anim) // 立即執(zhí)行
    case (.active, nil, _):
        currentState = .pendingActive // 掛起請求
    // 其他狀態(tài)處理...
    }
}

// 動畫加載完成回調(diào)
privatefunc handleActiveLoaded() {
    ifcase .pendingActive = currentState {
        play(animation: activeAnimation!)
        currentState = .active
    }
}

• 狀態(tài)切換邏輯：在 setActive(_:) 方法中，根據(jù)目標狀態(tài)和當前緩存的動畫數(shù)據(jù)，決定是否立即播放動畫或進入掛起狀態(tài)；如果目標動畫已經(jīng)加載完成（activeAnimation 或 inactiveAnimation 不為 nil），則直接播放動畫；如果目標動畫尚未加載完成，則將當前狀態(tài)設置為 pendingActive 或 pendingInactive，并等待加載完成。
• 加載完成回調(diào)：在動畫加載完成的回調(diào)方法中（handleActiveLoaded() 和 handleInactiveLoaded()），檢查當前狀態(tài)是否為掛起狀態(tài)；如果是掛起狀態(tài)，則立即播放對應的動畫，并將狀態(tài)更新為目標狀態(tài)。

生命周期兜底

為了確保視圖在掛載時能夠正確處理掛起狀態(tài)，我們在 didMoveToWindow 方法中添加了生命周期兜底邏輯：

override func didMoveToWindow() {
    super.didMoveToWindow()
    guard window != nil else { return }
    
    // 檢查并執(zhí)行掛起操作
    switch currentState {
    case .pendingActive where activeAnimation != nil:
        play(animation: activeAnimation!)
        currentState = .active
    // 其他狀態(tài)處理...
    }
}

• 在 didMoveToWindow 方法中，檢查視圖是否已經(jīng)掛載到窗口（window != nil）；
• 如果視圖已經(jīng)掛載，且當前狀態(tài)為掛起狀態(tài)（pendingActive 或 pendingInactive），則檢查對應的動畫是否已經(jīng)加載完成；
• 如果動畫已經(jīng)加載完成，則立即播放動畫，并將狀態(tài)更新為目標狀態(tài)。

資源加載流程優(yōu)化

圖片

通過引入狀態(tài)機和Pending機制，我們解決了以下問題：

• 資源未就緒時的狀態(tài)丟失問題：在動畫資源尚未加載完成時，記錄當前狀態(tài)為掛起狀態(tài)，確保在資源加載完成后能夠正確切換狀態(tài)。
• 確保最終一致性：通過生命周期兜底邏輯，確保視圖在掛載時能夠處理掛起狀態(tài)，避免因加載時序問題導致的狀態(tài)不一致。

第四階段：多資源管理（生產(chǎn)級方案）

Lottie動畫與圖片

Lottie 的 json 文件分為兩種情況：

• 純 json 文件，所有資源（包括圖片）都內(nèi)嵌在 json 里（base64），這種情況下，Lottie 只需要加載 json 文件本身即可，動畫和圖片都能正常顯示；
• json 文件 + 外部 images 目錄（圖片分離），這種情況下，Lottie 需要能訪問到 json 文件旁邊的 images 目錄，才能正確加載圖片資源。如果找不到圖片，動畫會顯示不出來或圖片部分缺失。

現(xiàn)在的異步加載方式

let animation = LottieAnimation.filepath(path)

這種方式只傳入了 json 文件路徑，沒有告訴 Lottie 去哪里找 images 目錄。

Lottie 的底層實現(xiàn)會嘗試用 json 路徑的同級目錄下的 images 文件夾，但如果你用的是沙盒緩存路徑、或者 images 目錄和 json 不在同一目錄，或者 images 目錄沒有被正確拷貝，Lottie 就找不到圖片，結(jié)果動畫就不會被正常顯示出來。

那么如何解決呢？

圖片資源隔離方案

Lottie 支持自定義圖片加載方式，可以用 FilepathImageProvider 指定 images 目錄。

當你切換 animation 屬性時，如果新動畫的圖片資源目錄和上一個動畫不同，必須同步切換 imageProvider，否則會出現(xiàn)圖片丟失或顯示異常。

// 初始化時創(chuàng)建獨立ImageProvider
let activeProvider = FilepathImageProvider(
    filepath: URL(fileURLWithPath: activePath)
        .deletingLastPathComponent()
        .appendingPathComponent("images")
        .path
)

// 狀態(tài)切換時同步更新
func play(animation: LottieAnimation, provider: AnimationImageProvider) {
    animationView.imageProvider = provider // 先切換資源
    animationView.animation = animation    // 再切換動畫數(shù)據(jù)
    animationView.play()
}

完整架構(gòu)圖

圖片

• DualStateLottieView：主類，負責管理雙狀態(tài)動畫的加載、切換和渲染；包含動畫數(shù)據(jù)緩存（activeAnimation 和 inactiveAnimation）和圖片資源提供者（activeImageProvider 和 inactiveImageProvider）；使用狀態(tài)機管理動畫狀態(tài)的變化。
• AnimationLoader：負責異步加載動畫資源；提供 loadAnimation(path:) 方法，返回加載完成的 LottieAnimation 對象。
• StateMachine：負責處理狀態(tài)變化的邏輯；提供 handleStateChange() 方法，確保狀態(tài)切換的正確性和一致性。

關(guān)鍵優(yōu)化點總結(jié)

性能對比數(shù)據(jù)

針對同一個Lottie動畫，JOSN大小4KB，含7張1KB-800KB圖片，內(nèi)存占用0.7MB

啟動耗時測試（ms）

狀態(tài)切換性能

結(jié)論：99%的主線程阻塞被消除，切換性能大幅提升

最佳實踐指南

1. 資源規(guī)范

推薦目錄結(jié)構(gòu)：
├── tab_animations
│   ├── home_active
│   │   ├── active.json
│   │   ├── images/  # 獨立圖片目錄
│   ├── home_inactive
│   │   ├── inactive.json
│   │   └── images/

2. 預加載策略

// 在應用空閑時預加載
func preloadAnimations() {
    let preloadQueue = OperationQueue()
    preloadQueue.qualityOfService = .utility
    
    for path in criticalAnimationPaths {
        preloadQueue.addOperation {
            _ = LottieAnimation.filepath(path) // 觸發(fā)緩存
        }
    }
}

3. 降級方案

func safePlay(animation: LottieAnimation?) {
    guardlet anim = animation else {
        showPlaceholder() // 降級為靜態(tài)圖片
        return
    }
    
    animationView.animation = anim
    animationView.play { [weakself] success in
        if !success {
            self?.animationView.currentProgress = 1// 顯示最后一幀
        }
    }
}

結(jié)語

通過三次關(guān)鍵迭代：

1. 異步解耦：解決主線程阻塞
2. 狀態(tài)補全：處理資源未就緒場景
3. 資源隔離：保障復雜資源正確性

我們最終實現(xiàn)了：

• ?? 啟動加速：主線程接近零耗時
• ?? 切換流暢：60fps穩(wěn)定運行
• ?? 通用性強：適配任意雙狀態(tài)場景

優(yōu)化本質(zhì)在于解耦三個關(guān)注點：

1. 資源加載（異步）
2. 狀態(tài)管理（狀態(tài)機）
3. 視圖渲染（輕量）

在本次實踐中，我們通過一系列漸進式優(yōu)化，成功解決了 Lottie 動畫雙狀態(tài)切換中的性能瓶頸，實現(xiàn)了高性能、高可靠性的動畫交互體驗。