移动端性能与稳定性

• 功耗量化指标（电流、电压、温度、耗电曲线）
• 功耗测试工具（Battery Historian、Power Monitor、厂商功耗助手）
• 场景化功耗测试（待机、亮屏、播放、导航、后台）

功耗测试需先明确量化指标：电流（mA）、电压、温度、一定时间内的耗电量（mAh）与耗电曲线。工具上，Android 常用 Battery Historian/BatteryStats 统计各进程与系统组件的耗电，配合 nRF 的 Power Monitor 或厂商功耗仪器测真实电流；iOS 用 Instruments 的 Energy 工具与 Xcode 的能耗分析。测试方法为场景化：分别测待机、亮屏、视频播放、网络请求、GPS 导航、后台任务下的电流与温度，记录并对比。定位耗电模块：用 BatteryStats 的 dumpsys batterystats 查看各 uid 的 CPU/网络/WakeLock 耗电，结合系统电量统计（如"耗电排行"）定位到具体功能（如 GPS 常开、网络轮询频繁、WakeLock 未释放）。测试需控制变量（固定亮度、屏幕、网络），并做版本间对比看功耗是否劣化。

功耗定位的关键是"先量化再定位"。回答要给出指标、工具、场景化方法、模块定位四个层面的完整链路，并强调控制变量与版本对比。

• 内存抖动（Memory Churn）的成因与危害
• 低端机内存上限与 OOM 触发
• 内存检测工具（Memory Profiler、LeakCanary、MAT）

内存抖动指频繁创建/回收对象导致 GC 频繁、卡顿甚至 OOM，常见于列表滚动、循环字符串拼接、图片解码等。测试需在低端机（内存小）上重点验证：长列表快速滚动是否内存抖动、onTrimMemory/低内存下是否被系统 kill、加载大图是否 OOM。检测工具：Android Studio Memory Profiler 观察堆分配与 GC 频率、LeakCanary 检测内存泄漏、MAT/hprof 分析大对象；iOS 用 Instruments 的 Allocations/Leaks。稳定性测试方法：长时间运行（数小时/数天）同时操作核心功能，观察内存曲线是否持续上升（疑似泄漏）、是否 OOM；用 adb shell am 注入低内存压力、调低 memory class 模拟低端机、用 Monkey 随机操作。判断标准：内存曲线平稳、无持续增长、无 OOM/ANR。

内存抖动与 OOM 是移动端稳定性核心问题。回答要体现"长跑 + 低端机 + 工具监控"的组合，并强调内存曲线是"缓慢生长"还是"瞬时尖峰"的不同处理。

• 性能基线的建立（指标、口径、环境）
• 版本回归的对比方法
• 性能劣化的自动判定与告警/门禁

性能基线建立需先确定指标集与口径（冷启动耗时、页面加载、帧率/卡顿率、内存占用、CPU、功耗），在同一受控环境（固定机型、网络、配置）下多次测量取众数/中位数（如 P50/P95）作为基线。版本回归测试在每次发版/合入时用相同脚本重测，与基线对比，设定阈值（如启动耗时劣化超 10% 即告警）触发 CI 门禁或人工评审。为避免波动，需多次采样取均值、剔除异常、固定环境变量。工具上可用自研 Benchmark 框架、Appium/PerfDog/Perfetto 采集指标，配合 CI 流水线自动跑并生成对比报告。关键点：基线要随硬件/版本演进定期校准，避免"基线漂移"。

性能回归的本质是"可控度量的对比"。回答要覆盖确定性、口径一致性、阈值门禁、CI 集成四个环节，体现工程化落地。

• Monkey 随机测试的局限
• 定向遍历（基于 UI 层级/深度优先）与业务流建模
• 核心路径覆盖的权重与策略

纯随机 Monkey 的问题在于覆盖分散、常卡在登录/弹窗、难以到达深层核心路径。改进方向：1) 定向遍历——基于 UI hierarchy 深度优先遍历所有可点击元素，或按页面结构做状态机遍历，保证覆盖程度；2) 业务流建模——把核心业务（登录→搜索→下单→支付）固化为脚本路径，用 wtf/深度优先策略优先执行；3) 加权随机——对核心功能元素提高触发权重，如使用风险等级（Risk Monkey）或基于历史崩溃热点；4) 智能兜底——用 context 处理弹窗、权限、登录态，避免卡死。工具有 Appium、UIAutomator2、Maestro、自研遍历引擎。最终目标是"用较少随机补盲，用定向保证核心路径深度覆盖"，并配合崩溃/ANR 监控。

该题考察对 Monkey 本质的理解与改进。回答要围绕"从随机到定向"的转变，给出遍历建模、加权、智能兜底等工程手段，并点明核心路径优先。

• 登出后的数据清理（缓存、token、本地存储）
• 多账号切换的登录态隔离
• 登出/切换时的进行中请求与数据一致性

登出/多账号切换的状态一致性核心是"账号间数据隔离与登出后彻底清理"。需验证：登出后本地缓存（token、用户信息、购物车、草稿）是否清除，内存中的用户数据是否释放，未完成请求是否被取消或返回后不污染；多账号切换时 A 账号的数据不会残留到 B 账号（如购物车、消息、好友列表），且能正确重新拉取。测试要点包括：登出时机（进行中支付/上传/websocket 时登出）、登出后按返回键是否会回到已登出页面、切换账号后首页/推荐/推送是否刷新为当前账号、离线缓存是否按账号隔离。同时验证"登出后 token 失效"的服务端配合，以及切换账号导致的推送/消息归属。方法上可通过多账号真机 + 自动化，结合 Charles 检查请求是否携带旧 token。

账号一致性是数据安全与体验的关键。回答要抓住"隔离 + 清理 + 进行中操作"三个维度，并强调跨账号残留数据是高风险点。

• 崩溃堆栈的收集（Crash Reporter）
• 符号化（Symbolication）原理与工具（Android NDK 栈、iOS dSYM）
• 发布包混淆/裁剪后的可定位性

发布包通常经过混淆（Android R8/ProGuard）与裁剪，崩溃堆栈是符号地址而非可读方法名，需符号化。Android：用 retrace 结合 ProGuard mapping 文件还原混淆堆栈，Native 崩溃用 addr2line/ndk-stack 结合 so 符号文件还原；iOS：用 atos/symbolicatecrash 结合 dSYM 文件还原。测试需验证：1) mapping 文件/dSYM 与构建一一对应且版本匹配（否则符号化失败）；2) 崩溃上报链路完整（字段、发生时间、堆栈、机型、版本）；3) 上报去重与聚合能力；4) 混淆后关键类/方法是否保底（keep 规则）而不影响可定位性。测试方法：构造人为崩溃（如空指针、divide by zero），验证上报的堆栈在后台能正确符号化还原到原始代码行，并关联到版本与源码。需建立 mapping/dSYM 的版本管理与符号化服务的 CI 校验。

崩溃可定位性是线上问题闭环的前提。回答要体现"混淆后符号化"这一关键难点，并强调 mapping/dSYM 的版本匹配与 CI 校验。

• 稳定性测试的三大指标（Crash、ANR、内存泄漏）
• 长期运行的测试设计（时长、场景、随机性）
• 监控与采集手段（日志、堆栈、内存）

长期稳定性测试（Monkey/自适应遍历 + 长时间运行）的目标是发现崩溃、ANR、内存泄漏三类问题。设计要点：1) 时长——建议数小时到数天（如 12h/24h/48h），覆盖日切与各种状态；2) 场景——用 Monkey 随机 + 定向遍历核心业务，穿插后台/前台切换、网络切换、弱网、中断、低电量；3) 监控——采集 Crash（含堆栈、符号化）、ANR（/data/anr trace、SIGQUIT）、内存（dumpsys meminfo、Profile 曲线、PSS 趋势），配合 LeakCanary 检测泄漏；4) 判定——以"指定时长内 Crash/ANR 次数为 0、内存曲线无持续增长、无泄漏"为通过标准；5) 闭环——抓到的崩溃/ANR 需还原复现、定位根因、修复并入回归。工具上 Android 用 adb shell monkey + 自研监控，iOS 用 XCUITest + Instruments。需注意区分"首次发生"与"累积劣化"。

稳定性测试是系统工程。回答要覆盖时长、场景、监控、判定、闭环五要素，并强调"三类问题用不同手段定位"。

• WakeLock/AlarmManager 与后台唤醒机制
• Doze/App Standby 下的行为
• 异常耗电的定位（WakeLock 未释放、频繁唤醒）

后台唤醒异常耗电通常源于 WakeLock 未释放、Alarm 频繁触发、后台网络轮询、GPS 常开等。测试需验证：App 进后台后是否仍持有 WakeLock 导致 CPU 不休眠、是否频繁触发 Alarm 唤醒、后台是否持续做网络请求或定位。验证方法：用 adb shell dumpsys power 查看 WakeLock 持有者与时长、用 dumpsys alarm 查看 Alarm 触发频率、用 Battery Historian 观察唤醒区间与后台耗电曲线、对比"前台/后台"耗电差值。测试需覆盖 Doze 模式（手机静止/深睡）下 App 是否被正确限制、退出 App 后是否仍在后台干活。验收标准：后台无持续 WakeLock、唤醒频率符合预期、后台耗电占比低。定位到异常后需推动修复（释放 WakeLock、改 Alarm 为 interval、合并广播）。

后台耗电的关键是"唤醒控制"。回答要体现对 WakeLock/Alarm/Doze 的理解，以及用系统统计定位"谁在唤醒"的方法。

• 冷启动 vs 热启动的定义与度量
• 启动耗时测量方法（logcat、adb、automation）
• 卡顿（jank/掉帧）的度量（帧率、卡顿率）

冷启动指进程从零创建到首页完全可交互，热启动指进程已存在仅从后台恢复。度量方法：Android 用 adb shell am start -W 读取 TotalTime/WaitTime，或用 logcat 的 Displayed 标志、dumpsys activity 获取；iOS 用 Xcode Instruments 的 App Launch 模板。为保证准确，需固定机型、清缓存、多次采样取均值。卡顿度量：统计帧渲染时长，超过 16.6ms（60Hz）为掉帧，用 dumpsys gfxinfo 的 janky frames、FrameStats、Perfetto/Systrace 采集，或 PerfDog 统计卡顿率与帧率曲线。分析需区分"启动"阶段（Application 初始化、首页布局、异步任务）与"运行"阶段（滚动、动画）的卡顿，并定位是主线程阻塞、布局过重、IO 还是 GC 导致。建设持续度量：启动耗时与卡顿率纳入性能基线回归。

启动与卡顿度量是性能回归的基础。回答要区分冷/热启动、给出具体测量命令与指标、并延伸到卡顿定位的根因分析。

• 掉帧检测原理（帧间距、Choreographer）
• Android/iOS 的掉帧采集方法
• 自动化触发滚动/动画并采集数据

掉帧检测基于帧渲染时间：Choreographer 每帧回调，若两帧间隔超过 16.6ms 即为掉帧。Android 自动化采集：dumpsys gfxinfo <pkg> framestats 输出每帧耗时，可计算 jank 帧数与 janky 比例；用 adb shell screenrecord 结合帧分析，或用 Perfetto（Systrace）采集渲染线程。iOS 用 Instruments 的 Core Animation 或 CADisplayLink 统计。自动化流程：用 Appium/Maestro 脚本触发滚动（swipe）、动画、进入页面，同步采集帧数据，计算掉帧率与卡顿时间，与阈值（如卡顿率 < 5%）对比判定。需控制屏幕亮度、同一机型、避免干扰。还可结合"首帧/黄油帧"指标，对长列表滚动、动画、页面切换重点检测。数据要求可重复，需多次采样。

掉帧自动化检测的关键是"稳定触发 + 精确采集 + 阈值判定"。回答要给出采集命令、触发方式与判定逻辑，体现可落地的自动化能力。

• 弱网导致的重复请求与重传
• 流量统计与冗余请求分析
• 优化手段（缓存、合并、压缩、断点续传）

弱网下流量浪费常见于：请求超时被反复重试、无缓存导致重复下载、图片未压缩、缺少断点续传导致重传整包。验证方法：用抓包工具（Charles/Fiddler）统计弱网下的请求次数、URL、体积与重传情况，或用系统流量统计（dumpsys netstats、TrafficStats API）对比"强网 vs 弱网"流量差值。优化手段：HTTP 缓存（Cache-Control/ETag）、图片尺寸与压缩（WebP）、请求去重与合并、失败重试加退避与次数上限、下载断点续传（Range）、离线缓存。验证重点：弱网下请求重试次数是否受控、命中缓存的比例、重复下载是否避免、流量是否显著下降。可结合弱网 profile 自动化对比优化前后流量，作为优化效果的验收。

流量优化要"先量化再优化"。回答要给出流量统计方法、识别冗余请求的手段、以及具体优化手段与验证闭环。

• Doze 模式的分级与限制（深度 Doze、App Standby）
• Doze 下闹钟、网络、同步、推送的行为
• Doze 测试方法与白名单

Doze 是 Android 在设备静止/亮屏后进入的省电模式，会限制网络、延迟 Alarm、禁止 WakeLock、限制 GPS。测试需验证：App 进入 Doze 后，定时任务（Alarm）、后台同步、轮询、推送是否被延迟或中断；Doze 维持窗口（maintenance window）期间任务是否批量执行；被系统判定为"非活跃"（idle）的 App 是否被限制。测试方法：用 adb shell dumpsys deviceidle 强制进入 Doze 各阶段（force-idle、人工触发 maintenance window），观察任务行为；对于需要及时性的任务（如推送、闹钟），验证是否申请了 setExactAndAllowWhileIdle 或使用高优先级 FCM，并确认是否需加入白名单。同时要区分"深度 Doze"与"App Standby"。验收标准：业务关键任务在 Doze 下仍能按预期（及时或延迟）执行，且不因 Doze 导致数据丢失或功能失效。

Doze 是后台节电的核心机制，测试要理解其分级与限制。回答要体现 deviceidle 的强制测试方法与关键任务的白名单/高优先级处理。

• 崩溃率指标定义（crash-free sessions/users）
• 崩溃监控体系（上报、聚合、归因）
• 崩溃率的版本/渠道分级

crash-free 指标通常指"无崩溃会话占比"或"无崩溃用户占比"，即 1 - 崩溃会话数/总会话数。监控需建立：崩溃上报（自动采集堆栈、环境、版本、机型）、符号化还原、聚合去重（按堆栈指纹归类）、按版本/渠道/机型/系统分级统计。关键指标：整体 crash-free 率、每版本崩溃率、Top 崩溃堆栈、崩溃率随版本的趋势。闭环流程：监控告警（崩溃率超过阈值或新版本突增）→ 定位根因（符号化堆栈 + 复现）→ 修复 → 灰度验证 → 全量 → 回归监控，确认崩溃率下降。同时要区分"新引入崩溃"与"存量崩溃"，通过版本对比识别。线上数据要与测试指标（如 Stability index）对齐，形成持续质量门禁。

崩溃率是移动端线上质量的核心 KPI。回答要覆盖指标定义、监控要素、分级统计与闭环修复，体现端到端运营意识。

• 长时间运行的内存泄漏累积
• 状态腐化（陈旧状态、计数器漂移、资源耗尽）
• 长跑测试的监控与判定

长时间运行测试（hours→days）用于发现短时测试难以暴露的累积问题。内存泄漏：持续反复进出页面、切换账号、加载/释放资源，观察内存曲线是否持续增长（PSS 上升、GC 后回落不彻底），用 LeakCanary/Instruments 定位泄漏源。状态腐化：长时间操作后状态对象（计数器、缓存、连接池、定时器）是否漂移——如轮询计数不归零、连接池耗尽、定时器越积越多、偶发字段残留。测试方法：长跑脚本（Monkey/UI 自动化）反复执行核心操作，穿插后台/前台、回收、重启网络，定期采集内存、CPU、线程数、socket 数、注册回调数，与基线对比判定"是否随运行时间劣化"。判定标准：内存平稳、线程/连接数不增长、功能状态在长时间后仍正确。发现腐化后需模块化定位并及时修复。

长跑测试与短时测试的区别在于"累积效应"。回答要体现内存曲线与资源计数（线程/连接/回调）的长期监控，以及状态腐化的判定逻辑。

• 覆盖安装（升级）的数据兼容（数据库、SharedPreferences、缓存）
• 升级后的崩溃与 ANR
• 升-降-升的版本兼容

覆盖安装（升级）测试需验证：升级后本地数据（数据库 schema、SharedPreferences、缓存、文件）是否兼容，sqlite 迁移（onUpgrade）是否正确执行、不丢数据、不崩溃；新版本读取旧数据是否正常；升级后启动是否崩溃（常见于字段变更未迁移、资源缺失）。测试要点：明确支持的升级路径（如 1.0→2.0、2.0→3.0、跨多个版本），在旧版本产生数据后安装新版本验证；验证升级后功能（如订单、收藏、草稿）仍可见可用；验证"降级"（新→旧）是否兜底（通常不支持，需提示）。方法：真机/模拟器先安装旧版产生数据 → 覆盖安装新版 → 启动全功能冒烟 + 数据校验；构造边界数据（空库、大库、损坏数据）验证迁移健壮性。需建立升级专项矩阵，覆盖主流升级路径。

升级是数据兼容的高风险点，尤其数据库迁移。回答要覆盖迁移正确性、跨版本路径、数据完整性校验与边界数据，体现严谨性。

• 通知在前台/后台/被杀状态下的到达
• 通知点击后的跳转与回调
• 本地通知与推送通知的区别

通知测试需覆盖 App 的不同状态：前台（通知是否以横幅/不打扰展示，是否触发回调而非弹通知打扰）、后台（通知栏展示、点击进入的页面）、被杀（冷启动后到达并点击跳转）。测试要点：推送到达后点击是否跳转到正确页面并携带参数（如消息 ID、深链）、前台收到推送是否走回调而非弹通知（避免打扰）、推送被清零/清除后进入 App 的行为、本地通知（定时/提醒）与推送通知的差异。还需验证：锁屏/息屏下的展示、通知栏折叠/分组、通知被误删后是否恢复、以及点击通知回到 App 的登录态处理。测试方法：用厂商推送/APNs/FCM 真实推送、模拟器发本地通知、Charles 模拟推送 payload，配合自动化验证点击跳转。注意不同厂商 ROM 与系统版本的通知权限与展示差异。

通知测试的本质是"状态矩阵 × 行为"。回答要覆盖前台/后台/被杀三态、点击跳转与参数传递、以及展示与权限差异，体现综合设计。

• 深链（URL Scheme）与 Universal Link/App Links 的区别
• 路由参数与登录态处理
• 跨 App 唤起与未安装时的兜底

深链测试需覆盖：URL Scheme（自定义 scheme，如 myapp://）与 Universal Link/App Links（https 域名）两种机制——前者需在清单/Info.plist 注册 scheme，后者需配置关联域名与资格文件。测试要点：1) 深链能否正确解析并路由到对应页面，参数（如 ID、token）是否正确传递；2) 未登录时点击深链是否先跳登录再回跳目标页；3) App 未安装时：URL Scheme 是否报错、Universal Link 是否有 App Store/兜底页；4) 已安装时冷启动/热启动的深链处理；5) 深链安全：参数校验、防注入、防伪造 token 盗取账号。测试方法：用 adb shell am start -a android.intent.action.VIEW -d "scheme://path" 触发深链、iOS 用 Safari 打开，结合自动化验证路由与登录态。需覆盖跨 App（如从微信/浏览器打开）唤起与回跳。

深链测试关键在于"解析-路由-登录态-兜底"四层。回答要区分 scheme 与 Universal Link，并涵盖未安装兜底与安全校验。

• 旋转导致的 Activity 重建与状态保存
• 分屏/多窗口的布局适应与状态保持
• 旋转时的输入/滚动/播放状态

旋转测试的核心是"旋转触发 Activity 重建后状态是否保持"。需验证：旋转横竖屏后，输入框内容、滚动位置、表单、视频播放进度、弹窗、选中状态是否保持；是否因 onConfigurationChanged 处理不当导致布局错乱或数据丢失。Android 上通常用 onSaveInstanceState 保存状态，或通过 configChanges 声明避免重建。分屏/多窗口测试：验证 App 在分屏（多窗口）模式下布局是否自适应、是否可缩放、状态是否保持、是否支持 resizeableActivity；分屏时操作（拖动分隔条调整尺寸）是否正常。测试方法：真机旋转（adb shell settings put system user_rotation）、开发者选项"旋转屏幕"、分屏拖拽，配合自动化验证各状态保持。注意视频、播放器、相机等对旋转的响应。

旋转/多窗口的核心是"配置变化后状态保全"。回答要区分"重建保留"与"configChanges 处理"，并覆盖分屏自适应与状态保持。

• 离线时的功能降级（可读缓存、不可用功能提示）
• 离线数据缓存与队列
• 恢复网络后的数据同步（冲突、顺序、幂等）

离线模式测试需验证：无网时，App 是否能展示已缓存内容（如列表、详情、图片）、仍可用的功能（本地编辑、播放已缓存）、不可用功能（搜索、支付、评论）是否有明确降级提示而非崩溃；离线操作（如写草稿、下单或评论）是否进入本地队列、恢复网络后是否自动同步。关键点：恢复网络后的同步一致性——多笔离线操作按何种顺序同步、是否会重复提交（需幂等）、服务端冲突如何处理（时间戳/版本号）、同步失败的重试与提示。测试方法：飞行模式/关闭网络模拟离线，操作后恢复网络触发同步，验证服务端数据与本地一致、无重复、无丢失。需覆盖"离线时长"（短时/长时）、"离线时 token 过期"（恢复后需重新登录）等边界。

离线测试的核心是"降级可用 + 同步一致"。回答要体现缓存降级、离线队列、恢复同步与冲突处理四个层面，并强调幂等。

• 非确定性输出（模型、环境、随机性）的测试挑战
• 测试数据集与基准（golden set）
• 效果指标（准确率、召回率、相似度）与规则校验

AI/ML 功能输出非确定，传统"断言等于预期"不适用。测试策略：1) 用固定测试集（golden set）与基准标注对比，校验准确率/召回率/相似度阈值，而非逐条精确匹配；2) 对 OCR 用置信度阈值与文本相似度（编辑距离）判定，对推荐用排序指标（NDCG、命中）与白名单规则校验；3) 覆盖边界与异常——低质量输入（模糊图片、手写、低分辨率）、识别失败时是否有兜底提示、低置信度是否回退；4) 分离"算法效果"与"功能正确性"——功能链路（调用、回调、结果展示）用确定性用例，算法效果用数据评测；5) 版本间模型对比，防止模型迭代导致回归。工具上可用模型评测脚本、标注数据集、A/B 对比。需建立"可复现"的评测环境（固定模型版本、固定输入）。

非确定性测试的核心是"把断言从逐条精确改为统计/阈值/规则"。回答要体现 golden set、置信度、相似度与兜底策略，并区分算法评测与功能测试。

• 热降频机制（CPU/GPU 降频保护）
• 长时间高负载触发热降频
• 性能劣化（掉帧、卡顿、启动变慢）的验证

热降频是 CPU/GPU 在温度过高时自动降频以保护硬件，会导致性能骤降。压测需通过长时间高负载运行（如持续渲染、复杂动画、视频编解码、游戏）使设备温度升高到触发降频，观察性能是否劣化：帧率下降、卡顿、启动变慢、持续高负载下性能下降。验证方法：用性能监控工具（PerfDog、Perfetto、dumpsys cpuinfo）记录 CPU/GPU 频率与温度曲线，观察降频拐点与对应的性能衰减；对比"冷机"与"热机"下的性能差异。测试需注意散热条件（真机散热、是否套壳、环境温度）影响结果，需固定环境。验收标准：热降频后性能衰减在可接受范围，关键操作（核心页面、动画）不出现严重卡顿。压测需结合用户真实长时使用场景（如长时间视频、游戏）。

热降频使性能不是稳定值而是随温度变化。回答要体现"高温触发降频 + 监控频率温度 + 对比冷热机性能"的压测逻辑。

• 剪切板读写与权限（Android 12+ 剪贴板提示）
• 分享面板（系统分享）的内容与目标 App
• 跨 App 数据传递与隐私

剪切板测试：验证 App 读取/写入剪切板是否正确、粘贴内容能否正常使用、Android 12+ 系统剪贴板访问提示（隐私提示）是否合理、以及剪切板敏感数据（如验证码）是否及时清除。分享面板测试：验证 App 调用系统分享面板后，分享内容（文本/图片/链接/文件）是否正确传递到目标 App（微信、邮件、备忘录等）、分享目标的图标与文案是否准确、取消分享的回调、分享后是否回跳及结果。隐私要点：分享/剪切板是否超出必要范围、是否泄露敏感信息。测试方法：真机分别在多个目标 App 上测试分享、自动化触发分享面板并验证 payload、用系统剪贴板工具验证剪切板内容。注意不同系统版本与 ROM 对分享面板的差异。

跨 App 交互是移动端特有的系统能力测试。回答要覆盖剪切板读写/隐私、分享面板内容传递与回跳，并关注系统版本差异。

• ATT（App Tracking Transparency）与 GDPR 合规要求
• 隐私弹窗、权限申请、数据收集的合规检测
• 合规检测工具（静态分析、动态抓包、合规扫描）

隐私合规自动化检测需覆盖：ATT（iOS 追踪授权弹窗是否在追踪前展示、未授权是否拒绝追踪）、GDPR（用户同意、数据可删除、最小化收集、撤回同意）。检测方法：1) 静态分析——用脚本扫描 Manifest/Info.plist 中的权限声明、SDK 列表、隐私标签，核对是否与隐私政策一致；2) 动态抓包——用 Charles/mitmproxy 抓取实际请求，检查收集的数据字段（设备 ID、位置、通讯录）是否有必要、是否在授权前就上报；3) 合规扫描工具——如 MobSF（Mobile Security Framework）做静态与动态分析、第三方合规 SDK；4) 自动化 UI 测试——验证隐私弹窗的出现时机、同意/拒绝分支、拒绝后的降级。工具如 MobSF、Google/Apple 的隐私清单、以及自研的权限-数据采集映射脚本。需建立"权限声明-实际采集-隐私政策"三方一致性校验。

隐私合规的核心是"声明与行为一致"。回答要体现静态分析、动态抓包、UI 弹窗自动化三方结合，并给出如 MobSF 等工具。