FirebasePerformance 开发测试 AppTestApp搭建与运行指南Prod/Autopush 双环境配置实战【免费下载链接】firebase-ios-sdkFirebase SDK for Apple App Development项目地址: https://gitcode.com/GitHub_Trending/fi/firebase-ios-sdk本文以 firebase-ios-sdk 仓库中 FirebasePerformance/Tests/TestApp/README.md 为骨架系统讲解 Firebase Performance 官方开发测试 AppPerfTestRigApp的完整搭建流程如何为 Prod生产与 Autopush预发两种上报环境创建 Firebase 工程、放置GoogleService-Info.plist、用generate_project.sh一键生成 Xcode 工程并运行。读完本文你将掌握 Firebase Performance SDK 开发调试环境的完整搭建方法并理解FPR_AUTOPUSH_ENV环境变量在 SDK 内部的真实作用链路。一、TestApp 是什么Firebase Performance 的性能实验台FirebasePerformance/Tests/TestApp 是 firebase-ios-sdk 仓库中 Firebase Performance 模块自带的开发测试 App工程名 PerfTestRigApptarget 名为FirebasePerformance-TestApp。它不是普通的示例工程而是专门用于在开发阶段验证、调试、压测 Firebase Performance SDK 各项采集能力的实验台其主要用途包括Trace自定义追踪测试手动创建、启动、停止自定义 Trace验证指标与计数器上报网络请求测试覆盖 8 种不同的网络请求实现方式验证 SDK 的网络自动采集与过滤逻辑屏幕追踪Screen Trace测试通过快速/慢速大表格、卡帧页面等场景验证UIViewController生命周期追踪、滑动卡顿与帧丢失检测开发期诊断开启FPRDiagnosticsLocal等调试开关在本地观察 SDK 的诊断日志。整个 TestApp 围绕 SDK 的三大采集能力组织其 UI 由三个 Tab 构成见 AppDelegate.mTraces自定义追踪、Requests网络请求、Screen Traces屏幕追踪。二、环境概念Prod 与 Autopush 的区别Firebase Performance 的指标数据会上报到 Google 的后端服务而 SDK 根据运行环境将数据发往不同 log source环境Bundle ID上报去向log source 值Prod生产com.google.FIRPerfTestApp正式生产服务数据可在 Firebase 控制台查看462LogRequest_LogSource_FireperfAutopush预发com.google.FIRPerfTestAppAutopushGoogle 内部 staging 服务器外部无法在控制台查看461LogRequest_LogSource_FireperfAutopush两个环境的核心差异体现在 SDK 的 log source 选择逻辑中。在 FPRConfigurations.m 的logSource实现中优先级为若进程环境变量FPR_AUTOPUSH_ENV 1始终返回 461Autopush否则优先使用 Remote Config 拉取到的 log source 值否则使用GULUserDefaults缓存的旧值兜底返回默认值 462Prod。因此对于外部开发者而言README 明确指出Autopush 环境产生的事件经由 Google 的 staging 服务器处理不会出现在 Firebase 控制台中仅适用于 Google 内部验证。绝大多数第三方场景使用 Prod 环境即可This should be sufficient for most scenarios。三、Setup创建 Firebase 工程与放置配置文件3.1 Prod 环境在 Firebase 控制台创建一个新工程添加一个iOS AppBundle ID 必须填写com.google.FIRPerfTestAppApp 的 Bundle ID 与 Firebase 工程中的 iOS App 标识必须严格一致SDK 初始化时才能匹配到正确的配置下载该 iOS App 的GoogleService-Info.plist将其放入仓库的FirebasePerformance/Tests/TestApp/Plists/Prod/FIRPerfTestApp/目录下。3.2 Autopush 环境创建另一个 Firebase 工程或使用同一个工程新建 App添加 iOS AppBundle ID 填写com.google.FIRPerfTestAppAutopush下载GoogleService-Info.plist放入FirebasePerformance/Tests/TestApp/Plists/Autopush/FIRPerfTestAppAutopush/目录下。注意Plists目录本身不包含在仓库中仓库只读且未跟踪该目录需要开发者自行创建目录并放入文件。但 Xcode 工程 project.pbxproj 中已预先建立了Plists/Prod/FIRPerfTestApp与Plists/Autopush/FIRPerfTestAppAutopush两个文件组引用并各包含一个GoogleService-Info.plist资源引用因此只要按上述路径放置文件重新生成工程后即可被自动打包进 App。3.3 双环境配置文件如何在工程中共存同一份 Xcode 工程里同时引用了两份GoogleService-Info.plist见 pbxproj 中的两个GoogleService-Info.plist in Resources构建阶段。实际生效哪一份取决于生成工程时选择的-e参数generate_project.sh会根据环境设置FPR_AUTOPUSH_ENV而 Podfile 依赖与资源配置由pod gen依据环境变量生成最终编译进 App 的是对应环境目录下的配置文件。四、Build用 generate_project.sh 生成 Xcode 工程4.1 命令与参数在FirebasePerformance目录下执行 generate_project.sh# 生成 Prod 环境工程 sh generate_project.sh -e prod # 生成 Autopush 环境工程默认值两种写法等价 sh generate_project.sh sh generate_project.sh -e autopush脚本支持三个参数见 generate_project.sh 的 help 输出参数含义默认值-e事件上报环境prod或autopushautopush任何非prod值都会回退到 autopush-p目标平台ios-c从零重建 Xcode 工程clean 模式复用已有工程4.2 脚本背后的关键逻辑脚本的核心工作是通过CocoaPods 的pod gen命令从FirebasePerformance.podspec生成独立 Xcode 工程pod gen $DIR/FirebasePerformance.podspec --local-sources$DIR/ \ --auto-open --gen-directory$DIR/gen --platforms$platform--local-sources$DIR/以仓库根目录为本地 spec 源保证生成的工程引用的是当前 checkout 的 FirebasePerformance 源码而非线上发布的 pod 版本这正是开发调试的前提--auto-open生成后自动用 Xcode 打开工程--gen-directory$DIR/gen生成的工程位于仓库根目录的gen/下。在调用pod gen之前脚本还设置两个关键环境变量它们会通过pod gen注入到生成的工程环境中export FPR_UNSWIZZLE_AVAILABLE1 # 开发期允许反 swizzle供单元测试使用 if [ autopush $env ]; then export FPR_AUTOPUSH_ENV1 # Autopush 环境标识 else export FPR_AUTOPUSH_ENV0 fiFPR_UNSWIZZLE_AVAILABLE开发期开关使 SDK 的 swizzle 可以被撤销便于单元测试隔离FPR_AUTOPUSH_ENV决定数据上报目标的核心开关。SDK 在初始化时读取该变量在 FPRClient.m 中若FPR_AUTOPUSH_ENV 1则useAutoPush YES构建的FPRConfiguration会携带 autopush 标识随后FPRConfigurations.m的logSource据此返回 461Autopush而非 462Prod。注意脚本中的rm -f $DIR/FirebasePerformance/ProtoSupport/*.[hm]与protoc调用只在-cclean模式下执行clean 模式会删除 Protogen 生成文件并调用protoc重新生成perf_metric.pbobjc适用于需要强制重新生成 proto 代码的场景。4.3 依赖要求TestApp 的 Podfile 声明platform :ios, 15.0 target PerfTestRigApp do pod FirebasePerformance target PerfTestRigAppTests do inherit! :search_paths pod EarlGrey end end最低系统版本 iOS 15.0依赖FirebasePerformancepod本地源码单元测试 target 额外引入EarlGreyGoogle 的 iOS UI 自动化测试框架用于PerfControllerTests.m等 UI 级测试。五、Run运行测试 App工程生成并打开后在 Xcode 中选择FirebasePerformance-TestApp这个 target即 Podfile 中的PerfTestRigApp选择目标设备/模拟器点击 Run。App 启动时会先执行 AppDelegate.m 的初始化逻辑[[NSUserDefaults standardUserDefaults] setBool:YES forKey:FPRDelegateSwizzling]; [[NSUserDefaults standardUserDefaults] setBool:YES forKey:FPRNSURLConnection]; [[NSUserDefaults standardUserDefaults] setBool:YES forKey:FPRDiagnosticsLocal]; [FIRApp configure];这里通过NSUserDefaults显式开启了三个 SDK 调试开关开关作用FPRDelegateSwizzling允许 SDK swizzle AppDelegate/UIViewController 相关方法启用自动追踪FPRNSURLConnection开启对 NSURLConnection 网络请求的自动采集旧 API 兼容FPRDiagnosticsLocal在本地输出 SDK 诊断日志便于开发期排错随后[FIRApp configure]完成 Firebase 初始化并注册三个功能 TabTraces手动创建自定义 Trace 的试验入口对应 TracesViewController.mRequests网络请求压测入口可选 8 种请求实现Screen Traces屏幕追踪压测入口含快速/慢速大表格、卡帧页面等场景见 ScreenTraceTestViewControllers 下的FastLargeTableViewController、SlowLargeTableViewController、FrozenFramesViewController。六、测试 App 的核心实验能力6.1 网络请求测试覆盖 8 种实现方式网络请求列表来自 network_connections.plist其中定义了 8 种网络连接类型全部指向同一个 HTTPS PDF 下载地址用于验证 SDK 对不同网络 API 的自动采集PerfURLConnectionWithDelegateClassInitNSURLConnection Delegateclass 初始化PerfURLConnectionWithDelegateNSURLConnection DelegatePerfURLConnectionWithDelegateStartImmediatelyNSURLConnection Delegate立即启动PerfURLConnectionAsyncRequestNSURLConnection 异步请求PerfURLSessionDataTask/PerfURLSessionDataTaskWithDelegateNSURLSession DataTask普通 / 带 DelegatePerfURLSessionDownloadTask/PerfURLSessionDownloadTaskWithDelegateNSURLSession DownloadTask普通 / 带 Delegate对应的实现类全部位于 Networking 目录可用于逐个验证 SDK 对NSURLConnection与NSURLSession各 API 形态的采集覆盖情况。这与仓库中 SDK 侧 Instruments 单元测试如FPRNSURLConnectionInstrumentTest.m、FPRNSURLSessionInstrumentTest.m的测试范围一一对应。6.2 屏幕追踪与卡顿测试Screen Traces Tab 提供三类典型性能场景FastLargeTableViewController快速滚动的数据大表格检验快速滑动下的采集性能SlowLargeTableViewController慢速加载的大表格制造主线程耗时FrozenFramesViewController刻意制造卡帧页面验证 SDK 的卡顿/冻结帧检测。结合 SDK 侧的 FPRScreenTraceTrackerTest.m 与 FPRAppActivityTrackerTest.m可以完整理解屏幕追踪从UIViewControllerswizzle 到帧数据采集的底层链路。6.3 自动化与无障碍支持TestApp 对主要交互控件都暴露了accessibilityIdentifier如TracesTab、RequestsTab、ScreenTracesTab见 AppDelegate.m并提供了 PerfTraceViewAccessibility.m 等辅助扩展。这意味着可以使用 EarlGrey 或 XCUITest 对 App 进行 UI 自动化操作例如仓库中 Tests 目录 的PerfControllerTests.m所示这对 CI 中自动生成性能数据非常关键。七、常见问题排查App 启动崩溃或提示 GoogleService-Info 缺失确认GoogleService-Info.plist已放在正确环境目录Plists/Prod/FIRPerfTestApp/或Plists/Autopush/FIRPerfTestAppAutopush/后重新执行generate_project.sh生成工程旧工程不会自动拾取新放入的 plist。Bundle ID 不匹配Firebase 控制台中的 iOS App Bundle ID 必须与目标环境完全一致Prod 用com.google.FIRPerfTestAppAutopush 用com.google.FIRPerfTestAppAutopush。数据在控制台看不到先确认你使用的是 Prod 环境-e prod。Autopush 环境的数据走 Google 内部 staging 服务器外部无法查看README 明确说明。想切换环境但工程没变generate_project.sh默认复用已有工程不带-c。切换 Prod/Autopush 时建议用-c从零重建或确保环境变量变更被重新注入。proto 代码异常可在生成工程时追加-c脚本会调用protoc重新生成perf_metric.pbobjc避免 Protogen 文件与本地 proto 不一致。八、小结FirebasePerformance 的开发测试 App 是一套围绕 SDK 三大采集能力自定义 Trace、网络请求、屏幕追踪设计的完整实验环境。其搭建要点可概括为选环境Prod/Autopush→ 配 plist对应 Bundle ID 的GoogleService-Info.plist放入对应目录→ 跑脚本generate_project.sh -e env→ 选 target 运行。理解FPR_AUTOPUSH_ENV环境变量在 generate_project.sh、FPRClient.m 与 FPRConfigurations.m 之间的传递链路是掌握这套环境机制的关键而 TestApp 提供的 8 种网络请求实现与三类屏幕追踪场景则为验证和调试 Firebase Performance SDK 提供了可直接复用的实验工具。【免费下载链接】firebase-ios-sdkFirebase SDK for Apple App Development项目地址: https://gitcode.com/GitHub_Trending/fi/firebase-ios-sdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考