DevEco Profiler 是集成在 DevEco Studio 中的核心性能分析工具，能够帮助开发者深入了解鸿蒙应用在运行时的性能表现，精准定位性能瓶颈。以下是针对 CPU、内存、网络三大核心维度的全链路深度分析：

一、 快速启动与数据收集

1. 启动 Profiler：在 DevEco Studio 中连接设备或启动模拟器，运行应用后，在工具栏选择“Run” -> “Profile 'YourApp'”启动 Profiler。
2. 选择分析模板：根据需求勾选要收集的性能数据类型（如 CPU、内存、Network 等）。
3. 执行操作并录制：在应用中触发目标业务场景（如进入新闻列表页、滑动页面等），等待操作完成后停止数据收集。

二、 CPU 深度分析：定位高耗时与卡顿

CPU 分析旨在实时显示 CPU 使用率和线程运行状态，了解资源消耗情况。

1. 查看核心使用率：在“CPU Core”泳道中，可以通过下拉列表选择“Slice and Frequency”查看占用该 CPU 核心的具体进程和线程，或选择“Usage and Frequency”查看核心使用率与频率曲线。
2. 框选时间段统计：鼠标框选主泳道中的特定时间段，可对选区内的 CPU 使用情况进行汇总统计，查询进程维度和线程维度的状态统计信息。
3. 追踪调度链：点击某个运行状态的时间片，可查询该时间片的基本运行信息及调度时延；开启“View Integrated Scheduling Chain”后，还能查看某一 CPU 运行线程的完整唤醒调度链，精准定位卡顿根因。

三、 内存深度分析：排查泄漏与抖动

内存分析主要用于检查是否存在内存泄漏，防止应用因内存不足而崩溃。

1. 启动内存捕捉：默认情况下内存分配信息捕捉未启动，需手动点击图标启用，并可调整捕捉信息的频率。
2. 分析数据详情：停止收集后，在内存数据展示图上拖动选取时间区段，可查看该时段的分析概览、调用信息以及申请链表。
3. 多维度内存排查：在数据详情中，支持选择“All（所有内存）”、“existing（未释放内存）”或“release（已释放内存）”进行过滤。同时，可分别查看 NativeSize、NativeLibrary、虚拟机 VM 或 APP 级别的内存状况，精准定位内存泄漏点。

四、 网络深度分析：拆解请求耗时瀑布

Network 模板用于查看 HTTP 协议栈的网络信息，方便对网络时延问题进行调优。

1. 查看分段耗时：网络请求耗时被精确划分为五个阶段：DNS 解析、TCP 链接、TLS 链接、请求等待、接受响应。通过 Summary 区域，可按域名（Domain）维度查看各阶段的平均耗时与最大耗时。
2. 请求详情排查：在 Details 区域选择具体的请求，可查看该请求的 Request ID、URL、IP 地址、状态码，以及详细的 Request Headers、Response Headers 和 Response Body，方便排查具体的网络通信问题。

五、 CPU 分析：通过 ArkTS Callstack 与火焰图定位主线程卡顿

当应用出现滑动卡顿或 ANR 时，核心思路是找出主线程上耗时最长的函数。

• 实战步骤：在 DevEco Studio 中选择 Time 类型，录制卡顿场景后，展开 ArkTS Callstack 泳道。通过 Ctrl + 鼠标滚轮 放大卡顿发生的时间段。
• 深度分析：点击卡顿时间条，在下方的 Details 图中查看完整调用链。重点关注右侧 Heaviest Stack（耗时最长的调用栈）。若发现如 JSON.parse 大字符串或复杂计算等耗时操作直接在主线程执行，这就是导致 UI 线程被占满、VSync 信号无法响应的根因。
• 优化方案：将此类耗时操作迁移至 TaskPool 或 Worker 中异步执行。对于轻量级工具应用，优先使用 TaskPool（注意任务函数需使用 @Concurrent 装饰器）；对于视频解码等重型多媒体任务，则使用 Worker 常驻线程处理。

import { taskpool } from '@kit.ArkTS';

// 1. 定义耗时任务：必须使用 @Concurrent 装饰器，且必须是模块顶层函数
@Concurrent
function heavyDataProcessing(dataSize: number): string {
  let result = '';
  // 模拟耗时的复杂计算或大字符串处理
  for (let i = 0; i < dataSize; i++) {
    result += `item_${i}_`;
  }
  return result;
}

@Entry
@Component
struct CPUCardPage {
  @State resultText: string = '点击下方按钮开始处理';
  @State isLoading: boolean = false;

  build() {
    Column({ space: 20 }) {
      Text(this.resultText)
        .fontSize(16)
        .padding(20)

      Button(this.isLoading ? '处理中...' : '执行耗时任务')
        .onClick(async () => {
          if (this.isLoading) return;
          this.isLoading = true;
          this.resultText = '正在后台处理，UI 保持响应...';

          try {
            // 2. 将耗时任务提交给 TaskPool 异步执行
            const task = new taskpool.Task(heavyDataProcessing, 100000);
            // 使用 await 等待结果，此过程不会阻塞主线程
            const result = await taskpool.execute(task) as string;
            
            this.resultText = `处理完成，结果长度: ${result.length}`;
          } catch (e) {
            this.resultText = `处理失败: ${JSON.stringify(e)}`;
          } finally {
            this.isLoading = false;
          }
        })
        .width('80%')
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
  }
}

六、 内存分析：通过 Native Allocation 定位 C++ 层内存泄漏

如果 ArkTS 堆内存正常，但进程总内存（PSS）持续上涨，问题通常出在 Native 层（如 PixelMap 像素数据、第三方 C/C++ 库）。

• 实战步骤：在 Profiler 中切换至 Native Allocation 模式，仅开启 Native 内存通道进行录制。复现疑似泄漏的场景后，在详情区选择 "Created & Existing"（已创建且未释放的内存）。
• 深度分析：切换到 Call Trees 选项卡，按内存占用比例降序排序。优先展开亮色（代表开发者自己的代码）且占用比例最高的堆栈。若调用栈仅显示 so+偏移，需导入对应版本的符号表（Symbol Table）进行离线解析，以还原真实的 C++ 函数名。
• 优化方案：结合定位到的调用栈排查代码。例如，若是 NAPI 强引用未删除，需在业务结束时调用 napi_delete_reference 释放；若是 C++ 对象绑定到 JS 时未注册析构回调，需在 napi_wrap 中注册 finalize 回调，确保 JS 垃圾回收时能同步释放 C++ 内存。

// C++ NAPI 代码示例
#include <napi/native_api.h>
#include <iostream>

// 模拟一个占用较大内存的 C++ 类
class MyCppClass {
public:
    MyCppClass() {
        std::cout << "Native Memory Allocated" << std::endl;
    }
    ~MyCppClass() {
        std::cout << "Native Memory Released" << std::endl;
    }
};

// 1. 定义析构回调函数，用于释放 C++ 内存
// 当 ArkTS 侧对象被 GC 回收时，会自动触发此函数
void FinalizeCallback(napi_env env, void* data, void* hint) {
    // 安全地释放通过 new 分配的内存
    if (data != nullptr) {
        delete static_cast<MyCppClass*>(data); 
    }
}

// 2. 在绑定对象时注册回调
napi_value CreateCppObject(napi_env env, napi_callback_info info) {
    napi_value jsObj;
    napi_create_object(env, &jsObj);

    // 分配 C++ 对象
    MyCppClass* nativePtr = new MyCppClass(); 

    // 【关键】将 nativePtr 绑定到 jsObj，并传入 FinalizeCallback
    // 这样 JS 垃圾回收时，就会顺带清理这块 Native 内存
    napi_wrap(
        env, 
        jsObj, 
        nativePtr, 
        FinalizeCallback, 
        nullptr, 
        nullptr
    ); 

    return jsObj;
}

// 模块初始化注册
EXTERN_C_START
static napi_value Init(napi_env env, napi_value exports) {
    napi_property_descriptor desc[] = {
        { "createCppObject", nullptr, CreateCppObject, nullptr, nullptr, nullptr, napi_default, nullptr }
    };
    napi_define_properties(env, exports, sizeof(desc) / sizeof(desc[0]), desc);
    return exports;
}
EXTERN_C_END

static napi_module demoModule = {
    .nm_version = 1,
    .nm_flags = 0,
    .nm_filename = nullptr,
    .nm_register_func = Init,
    .nm_modname = "entry",
    .nm_priv = ((void*)0),
    .reserved = { 0 },
};

extern "C" __attribute__((constructor)) void RegisterEntryModule(void) {
    napi_module_register(&demoModule);
}

七、 网络分析：通过五段耗时拆解优化慢请求

网络请求慢往往不是单一原因，需要精确定位瓶颈发生在哪个阶段。

• 实战步骤：创建 Network 模板任务并录制数据。在 Summary 区域按域名（Domain）维度查看统计，找到平均耗时或最大耗时异常的请求。
• 深度分析：在 Details 区域点选该请求的耗时方块，查看其五个阶段的精确耗时：DNS 解析、TCP 链接、TLS 链接、请求等待、接受响应。同时，可展开右侧 More 区域，检查 Request Headers 和 Response Body，排查是否因请求参数错误导致服务端处理缓慢或返回了重定向。
• 优化方案：
  • 若 DNS 解析 耗时过长：考虑引入 HTTPDNS 或增加本地缓存。
  • 若 TCP/TLS 链接 耗时过长：检查是否需要开启长连接复用，或优化证书链。
  • 若 请求等待/接受响应 耗时过长：通常是服务端处理慢或返回数据量过大。需与服务端协同优化接口逻辑，或在客户端实施分页加载、数据压缩等策略。

import { http } from '@kit.NetworkKit';

/**
 * 封装网络请求，内置超时控制与性能优化策略
 */
export async function fetchOptimizedData(url: string): Promise<string> {
  const httpRequest = http.createHttp();
  
  try {
    // 发起网络请求，针对 Profiler 中的耗时阶段进行优化
    const response = await httpRequest.request(url, {
      method: http.RequestMethod.GET,
      
      // 【优化1】针对 TCP/TLS 链接与请求等待耗时过长
      // 设置合理的连接与读取超时时间，防止长时间阻塞主线程或子线程
      connectTimeout: 5000, 
      readTimeout: 5000,
      
      // 【优化2】针对 接受响应 耗时过长
      // 声明接受 GZIP 压缩，减少网络传输的数据量
      header: {
        'Accept-Encoding': 'gzip'
      }
    });

    // 校验响应状态码
    if (response.responseCode === http.ResponseCode.OK) {
      return response.result as string;
    } else {
      throw new Error(`Request failed with status code: ${response.responseCode}`);
    }
  } catch (err) {
    console.error('Network request error:', err);
    throw err;
  } finally {
    // 【关键】请求结束后务必销毁实例，释放底层 Socket 连接资源
    httpRequest.destroy();
  }
}