前言

回想一下我們每天使用手機的場景，無論是清晨瀏覽新聞資訊，午休時刷短視頻，還是睡前查看電商平台的購物訂單，這些海量信息的呈現方式無一例外都是列表。對於用户而言，手指在屏幕上滑動的流暢度直接決定了對一款應用的第一印象，哪怕出現幾毫秒的掉幀或者瞬間的白屏，都可能讓用户心生退意。而對於我們開發者來説，構建一個能跑通的列表界面似乎是入門必修課，甚至在很多初級教程中，只需要幾行簡單的代碼就能把數組裏的數據渲染到屏幕上。

但是，當我們把數據量從幾十條增加到一千條、一萬條時，那個曾經絲般順滑的界面可能會突然變得卡頓、手機發燙，甚至因為內存溢出而直接閃退。這就是初級工程師與資深開發者的分水嶺所在。

在鴻蒙 HarmonyOS 6 的開發裏，掌握 List 列表容器僅僅是起點，而真正能讓我們駕馭海量數據、實現極致性能體驗的核心鑰匙，在於理解並精通 LazyForEach 懶加載機制。

一、 走出全量渲染的舒適區與性能陷阱

在 ArkUI 的組件體系中，創建一個列表是極其符合直覺的。我們通常會使用 List 容器組件，它就像是一個能夠滾動的長條盒子，而在盒子內部，我們通過 ListItem 來承載具體的每一行內容。對於剛接觸鴻蒙開發的同學來説，最順手的工具肯定是 ForEach 循環渲染。它的邏輯非常簡單直接，我們給它一個數組，它就老老實實地遍歷數組中的每一個元素，然後為每一個元素創建一個對應的組件。這種全量渲染的模式在數據量較少時，比如只有二三十條設置項，是完全沒有問題的，代碼寫起來也清晰易懂。

// 1. 數據源
@State dataList: string[] = ['核心概念', '組件通信', '路由管理', '狀態管理'];

build() {
  // 2. List 容器：類似滾動的長條盒子
  List({ space: 12 }) { 
    // 3. ForEach：循環渲染
    // 參數1：數據源
    // 參數2：組件生成函數
    // 參數3：鍵值生成函數 (性能關鍵，用於唯一標識)
    ForEach(this.dataList, (item: string) => {
      
      // 4. ListItem：承載具體的每一行
      ListItem() {
        Text(item)
          .fontSize(16)
          .width('100%')
          .padding(15)
          .backgroundColor(Color.White)
          .borderRadius(10)
      }
      
    }, (item: string) => item) // 唯一 Key，避免不必要的重新渲染
  }
  .width('100%')
  .height('100%')
  .padding(16)
}

我們必須警惕這種舒適區往往也是性能的陷阱。ForEach 的工作機制決定了它會一次性加載所有的數據。

如果服務器給我們返回了一萬條歷史訂單數據，如果我們直接使用 ForEach 進行渲染，ArkUI 就會嘗試在瞬間創建一萬個 ListItem 組件以及它們內部的所有子組件。這不僅會瞬間佔滿應用的內存，大量的佈局計算和節點創建任務還會死死地堵塞主線程，導致用户看到頁面長時間的白屏或者嚴重的掉幀。這就是為什麼很多新手的應用在測試階段數據少時跑得飛快，一上線遇到真實數據就崩潰的原因。

我們必須意識到，屏幕的顯示區域是有限的，用户同一時間能看到的可能只有五六條數據，為那些還未出現在屏幕上的九千多條數據提前創建組件，是一種極大的資源浪費。

二、 LazyForEach 的按需渲染哲學與數據契約

為了解決全量渲染帶來的性能災難，HarmonyOS 引入了 LazyForEach 組件。

它的名字非常直觀，Lazy 代表懶惰，但在計算機科學中，這裏的懶惰意味着極致的高效。LazyForEach 的核心哲學是 按需渲染。它只會為當前屏幕可見區域以及可視區域附近少量的預加載區域創建組件。當用户向上滑動屏幕時，下方的列表項即將進入屏幕，LazyForEach 才會向數據源請求數據並創建新的組件；而當上方的列表項滑出屏幕並遠離可視區域時，它們所佔用的組件資源會被銷燬或者回收進入複用池。這種機制就像是一個滑動的窗口，無論我們的底層數據有多少萬條，內存中實際存在的組件數量始終維持在一個很小的、穩定的範圍內。

這種高性能是有門檻的。與 ForEach 直接接收一個簡單的數組不同，LazyForEach 要求我們提供一個實現了 IDataSource 接口的數據源對象。這對於很多習慣了直接操作數組的前輩來説，可能是一個思維上的轉變。在懶加載的模式下，ArkUI 框架不再直接持有數據的所有權，它變成了一個單純的索取者。它會不斷地問我們：總共有多少條數據？第 5 條數據是什麼？作為開發者，我們需要構建一個能夠回答這些問題的數據管理代理。

在實際的工程實踐中，我們絕不會在每一個頁面裏都去手寫一遍 IDataSource 的實現邏輯。那樣不僅代碼冗餘，而且極易出錯。成熟的做法是封裝一個 BasicDataSource 基類。這樣做的好處是，我們可以把那些枯燥的監聽器管理代碼、數據的增刪改查通知邏輯全部封裝起來，在具體的業務代碼中，我們只需要關注數據的獲取本身。這不僅讓代碼更加整潔，也符合面向對象編程的複用原則。

我們可以看看下面這個通用的基類封裝，它是我們構建高性能列表的基石。

// BasicDataSource.ets - 通用數據源基類
class BasicDataSource<T> implements IDataSource {
  private listeners: DataChangeListener[] = [];
  private originDataArray: T[] = [];

  // 告訴框架總共有多少條數據
  totalCount(): number {
    return this.originDataArray.length;
  }

  // 告訴框架指定索引的數據是什麼
  getData(index: number): T {
    return this.originDataArray[index];
  }

  // 註冊監聽器，框架通過它來感知數據變化
  registerDataChangeListener(listener: DataChangeListener): void {
    if (this.listeners.indexOf(listener) < 0) {
      this.listeners.push(listener);
    }
  }

  // 註銷監聽器
  unregisterDataChangeListener(listener: DataChangeListener): void {
    const pos = this.listeners.indexOf(listener);
    if (pos >= 0) {
      this.listeners.splice(pos, 1);
    }
  }

  // 初始化或重置數據
  public setData(data: T[]) {
    this.originDataArray = data;
    this.notifyDataReload();
  }

  // 通知所有監聽器：數據重載了
  notifyDataReload(): void {
    this.listeners.forEach(listener => {
      listener.onDataReloaded();
    });
  }
}

三、 鍵值生成與緩存策略的博弈

當我們封裝好了數據源基類後，使用 LazyForEach 時還有兩個技術細節決定了最終的成敗：一個是鍵值生成規則，一個是緩存數量。LazyForEach 的第三個參數是 keyGenerator，它的作用是為每一個數據項生成一個唯一的身份證。很多開發者容易忽視這一點，甚至為了省事直接使用數組的 index 索引作為 Key。這在列表內容靜態不變時或許能僥倖過關，可一旦涉及到數據的插入或刪除，就會出問題。

因為當我們刪除列表頭部的元素時，後面所有元素的索引都會發生變化，這會導致框架誤判所有組件都需要更新，從而觸發全量的銷燬和重建，讓懶加載的複用機制徹底失效。正確的做法是永遠使用數據對象中本身具備的唯一標識，比如用户 ID 或者訂單號。這樣無論數據如何在數組中移動，框架都能通過這個唯一的 Key 識別出它，從而複用已經存在的 UI 組件。

除了 Key，cachedCount 屬性則是調節性能與體驗的槓桿。它控制着列表的預加載數量。默認情況下，LazyForEach 只加載屏幕內的項目。但這會帶來一個問題，如果用户滑動得非常快，新的列表項還沒來得及渲染，屏幕邊緣就會出現短暫的白塊。我們可以設置 cachedCount，比如將其設置為 5，意味着框架會在屏幕可視區域的上下方額外預先渲染 5 個列表項。這樣當用户滑動時，內容已經準備好了，體驗就會非常絲滑。但這個數值也不是越大越好，過大的緩存數量又會重新帶來內存壓力，我們需要在流暢度和內存佔用之間找到一個平衡點。

四、 實戰

為了讓大家更直觀地理解這些概念如何協同工作，我們來構建一個完整的新聞列表場景。這個示例代碼不僅包含了一個繼承自泛型基類的具體業務數據源，還演示瞭如何在 List 組件中正確配置 LazyForEach 和 cachedCount。你可以直接將這段代碼複製到你的項目中，它能夠毫無壓力地處理上千條數據的渲染。

import { promptAction } from '@kit.ArkUI';

// 1. 定義數據模型
// 在實際項目中，這裏通常對應後端 API 返回的 JSON 結構
class NewsData {
  id: string;
  title: string;
  summary: string;
  timestamp: string;

  constructor(id: string, title: string, summary: string) {
    this.id = id;
    this.title = title;
    this.summary = summary;
    this.timestamp = new Date().toLocaleTimeString();
  }
}

// 2. 引入我們之前定義的通用數據源基類
// (為了代碼的完整性，這裏再次展示簡化版，實際開發中請抽離為單獨文件)
class BasicDataSource<T> implements IDataSource {
  private listeners: DataChangeListener[] = [];
  private originDataArray: T[] = [];

  totalCount(): number {
    return this.originDataArray.length;
  }
  getData(index: number): T {
    return this.originDataArray[index];
  }
  registerDataChangeListener(listener: DataChangeListener): void {
    if (this.listeners.indexOf(listener) < 0) {
      this.listeners.push(listener);
    }
  }
  unregisterDataChangeListener(listener: DataChangeListener): void {
    const pos = this.listeners.indexOf(listener);
    if (pos >= 0) {
      this.listeners.splice(pos, 1);
    }
  }
  public setData(data: T[]) {
    this.originDataArray = data;
    this.notifyDataReload();
  }
  notifyDataReload(): void {
    this.listeners.forEach(listener => {
      listener.onDataReloaded();
    });
  }
}

// 3. 具體的業務數據源
class NewsDataSource extends BasicDataSource<NewsData> {
}

@Entry
@Component
struct LazyListPerformancePage {
  // 實例化我們的數據源對象
  private newsDataSource: NewsDataSource = new NewsDataSource();
  
  // 模擬生成數據的輔助函數
  private generateMockData(count: number): NewsData[] {
    let dataList: NewsData[] = [];
    for (let i = 0; i < count; i++) {
      const id = i.toString();
      dataList.push(new NewsData(
        id, 
        `鴻蒙 HarmonyOS 6 高性能新聞標題 #${id}`, 
        `這是第 ${i} 條新聞的詳細摘要。我們正在使用 LazyForEach 技術來確保列表滑動的極致流暢。`
      ));
    }
    return dataList;
  }

  // 頁面即將顯示時加載數據
  aboutToAppear(): void {
    // 模擬加載 1000 條數據
    const mockData = this.generateMockData(1000);
    this.newsDataSource.setData(mockData);
  }

  build() {
    Column() {
      // 頂部標題欄
      Text('高性能資訊流')
        .fontSize(24)
        .fontWeight(FontWeight.Bold)
        .width('100%')
        .padding(20)
        .backgroundColor('#F1F3F5')

      // List 容器開始
      List({ space: 12 }) {
        // 核心：使用 LazyForEach 替代 ForEach
        LazyForEach(this.newsDataSource, (item: NewsData) => {
          ListItem() {
            // 列表項的具體佈局
            Column({ space: 8 }) {
              Row() {
                Text(item.title)
                  .fontSize(16)
                  .fontWeight(FontWeight.Medium)
                  .maxLines(1)
                  .layoutWeight(1)
                  .textOverflow({ overflow: TextOverflow.Ellipsis })
                
                Text(item.timestamp)
                  .fontSize(12)
                  .fontColor('#999999')
              }
              .width('100%')
              .justifyContent(FlexAlign.SpaceBetween)

              Text(item.summary)
                .fontSize(14)
                .fontColor('#666666')
                .maxLines(2)
                .textOverflow({ overflow: TextOverflow.Ellipsis })
                .lineHeight(20)
            }
            .width('100%')
            .padding(16)
            .backgroundColor(Color.White)
            .borderRadius(12)
            .shadow({ radius: 4, color: '#1A000000', offsetY: 2 })
          }
          .onClick(() => {
            promptAction.showToast({ message: `點擊了新聞 ID: ${item.id}` });
          })
        }, (item: NewsData) => item.id) // 關鍵點：使用唯一的 id 作為 Key
      }
      .width('100%')
      .layoutWeight(1) // 讓列表佔據剩餘的所有高度
      .cachedCount(4)  // 關鍵點：預加載屏幕外的 4 項，防止快速滑動白塊
      .padding({ left: 16, right: 16, bottom: 16 })
      .divider({ strokeWidth: 0 }) // 隱藏默認分割線
      .scrollBar(BarState.Off)     // 隱藏滾動條讓視覺更清爽
    }
    .width('100%')
    .height('100%')
    .backgroundColor('#F1F3F5')
  }
}

五、 總結

回顧我們探討的內容，從簡單的 ForEach 到高性能的 LazyForEach，這不僅僅是 API 的更換，更是一種開發思維的進階。

我們學會了如何通過 IDataSource 建立數據與視圖的契約，如何通過 cachedCount 平衡內存與流暢度，以及如何利用穩定的 Key 來榨乾框架的複用能力。

在鴻蒙 HarmonyOS 6 的全棧開發中，列表性能優化是衡量一個應用質量的基石。一個能夠流暢加載萬級數據的列表，往往比花哨的動畫更能贏得用户的信任。