---

1 -> 概述

移动应用业务面临的作弊手段日益复杂，其中自动化点击（Automated Clicking）和设备墙（Device Farm）是两类典型的高频攻击方式。黑产团伙通过脚本批量执行点击操作、使用大规模设备集群模拟真实用户行为，在电商秒杀、营销活动、签到打卡、应用刷榜等场景下攫取不正当利益，直接侵蚀开发者的营销预算和正常用户的权益。长期以来，这类攻击因为不易被传统的设备指纹或登录验证机制捕获，成为业务风控体系中的一块短板。

HarmonyOS 6.0（API版本要求6.0.0(20)及以上）对Device Security Kit中的BusinessRiskIntelligentDetection模块进行了重要扩展，新增了模拟点击检测能力。该能力能够从系统层面识别当前设备的操作是否来自自动化脚本注入或设备集群中的模拟器/真实设备群控行为，帮助开发者在业务决策层及时发现作弊风险，采取降级、拦截或加强验证等措施。与传统的基于行为统计的风控方案不同，鸿蒙的这一检测能力直接读取设备底层的信号数据（例如传感器状态、点击事件注入痕迹等），并由华为安全服务器进行后端综合分析，具备较高的检测准确率和抗绕过能力。

Device Security Kit本身已在设备完整性检测（DeviceVerify）、安全环境检测（SafetyDetect）、可信应用服务（TrustedAppService）等方面积累了成熟的能力体系，模拟点击检测的加入进一步补齐了业务风控维度中“操作真实性”这一关键环节。对于需要精准识别真实用户行为的场景——尤其是涉及营销权益发放、高价值交易操作、敏感信息访问的应用——该接口提供了一个轻量化但有力的系统级安全屏障。

2 -> 核心概念与应用场景

在深入技术细节之前，有必要厘清检测对象的核心概念。

自动化点击指的是通过脚本、自动化测试框架或注入事件的方式，在没有人工参与的情况下向应用界面发送点击指令。这类操作在合法场景下确实存在用途，例如UI自动化测试；但在黑产场景中，被大量用于批量刷单、自动签到、脚本抢购等行为。黑产通常绕过应用原有的点击检测逻辑，直接通过系统底层的输入事件注入接口模拟点击，导致传统的界面层校验（如按钮点击时的坐标判断）难以区分真实用户和自动化操作。

设备墙（Device Farm）则更进一步：攻击者购置大量真实设备（通常是二手手机或专门的云手机集群），通过集中控制平台批量运行自动化脚本，模拟多用户并行操作的假象。设备墙往往同时结合了自动化点击、设备参数篡改等多种技术手段，对活动防刷、新用户注册奖励等场景构成严重威胁。

模拟点击检测接口的运行逻辑可以简单概括为：每次关键操作之前“问一次”系统——当前这次点击，到底是真人点的，还是机器点的？ 系统综合设备底层的多个线索信号给出判断结果，开发者根据结果决定后续业务逻辑。这种方式不侵入应用的已有UI交互流程，但对操作的真实性提供了独立于业务逻辑的第三方验证。

3 -> 接口详细讲解

3.1 -> 请求参数：SimulatedClickDetectionRequest

模拟点击检测的核心接口为detectSimulatedClickRisk，位于businessRiskIntelligentDetection模块中。请求参数的结构定义如下：

名称	类型	必填	说明
version	number	否	检测结果消息格式的版本，默认值为1，当前只支持1

该参数结构在当前版本中较为简洁——version字段用于标识结果格式的版本。需要特别说明的是，在Device Security Kit的涉诈剧本检测（FraudDetectionRequest） 中，请求参数还包括nonce和algorithm字段用于防重放攻击和签名校验；而在基础版的模拟点击检测中，目前尚未要求传入nonce。但从业务安全实践的角度出发，如果开发者的业务场景对重放攻击防御有较高要求，建议结合实际业务层的时间戳和一次性令牌机制进行防重放保障。

另外，API文档中还定义了SimulatedClickDetectionEnhancedRequest（起始版本6.0.2(22)），该增强版请求包含nonce和algorithm字段，能提供更强的安全性。在具体使用时，开发者可根据目标设备的API版本选择对应的请求参数类型。

3.2 -> 返回值结构与风险决策

检测结果以Promise<string>形式返回，结果内容为JSON格式的字符串，这是模拟点击检测能力中最需要理解的部分。一个典型的返回结果示例如下：

{
  "timestampMs": 9860437986543,
  "version": 1,
  "riskDecision": "fake",
  "tags": ["AbnormalTap"]
}

3.2.1 -> timestampMs

发起检测请求时生成的时间戳，单位为毫秒。开发者可以使用该字段与本地请求时间进行比对，辅助判断响应数据的新鲜度。

3.2.2 -> version

检测结果消息格式的版本，默认值为1。当前版本下，开发者基本无需特别关注该字段的细节。

3.2.3 -> riskDecision（核心决策字段）

这是检测结果中最直观的结论值，共包含三种可能的状态：

riskDecision值	含义
fake	当前设备存在作弊风险行为。具体而言，系统检测到了自动化操控行为或设备墙作弊行为。此时应结合tags字段了解具体的特征信息，并采取相应的业务降级、拦截或进一步验证措施。
likelyReal	当前操作设备的是真人用户的可能性较高。该结果意味着系统暂未发现明显的异常信号，应用可以正常放行业务操作。
unknown	未知。未检测到明显特征，设备状态特征不足以做出明确判断。遇到该结果时，建议开发者根据业务风险容忍度进行适当处理，例如要求额外的人机验证或采取相对保守的策略。

3.2.4 -> tags（关键特征标签）

tags字段以数组形式呈现，列出检测过程中发现的异常行为线索。tags为空数组时，表示未发现任何关键特征；非空则表示存在一项或多项异常特征。各标签值的含义如下：

tags值	含义
AbnormalDeviceIntegrity	设备完整性遭到破坏，例如设备已被Root、Bootloader解锁或系统分区被篡改。完整性的缺失将直接削弱点击事件的安全性。
AbnormalDeviceBehavior	设备行为异常。例如，设备连接状态异常、传感器数据与预期不符等。设备墙或云手机环境下常常存在这类行为特征。
AbnormalTap	存在异常点击行为。例如，点击事件被通过脚本或外部工具注入，或监测到存在自动化、批量化点击的特征。

理解riskDecision与tags的组合关系非常重要：riskDecision: "fake"本身已经指示了存在作弊风险，而tags字段则进一步说明了风险的具体来源——是设备完整性被破坏导致的（AbnormalDeviceIntegrity），还是单纯的点击事件注入导致的（AbnormalTap），抑或两者兼而有之。开发者可以根据具体的tags组合设计差异化的应对逻辑。例如：

• 仅检测到AbnormalTap而设备完整性正常，可能存在自动点击脚本但不一定是对设备进行了高权限操作，应用可以先要求用户通过人机验证而非直接封禁。
• 同时检测到AbnormalDeviceIntegrity与AbnormalTap，说明设备的底层安全底座已经不可信，点击操作极有可能完全被伪造，建议直接拒绝本次请求并要求用户使用未Root设备重新操作。

3.3 -> 约束与调用限制

模拟点击检测接口在实际调用时存在明确的频率限制和总量限制：

• 每30秒内最多调用10次；
• 每个应用在每个设备上每天最多调用20次。

开发者在设计业务策略时，需要将这些限制纳入考量。例如，对于一些高频操作场景（如用户快速滑动列表时触发的多次点击检测），应在业务代码中增加限频控制或节流逻辑，避免频繁调用超出配额。此外，建议仅在确实需要判断操作真实性的临界点调用该接口——例如用户点击“领取奖励”按钮时、提交高价值订单时、执行余额提现操作等——而不是在每一次普通的界面交互中调用。

4 -> 开发步骤与代码实现

下面以ArkTS语言为例，完整演示模拟点击检测的接入过程。

4.1 -> 导入必要的模块

首先需要导入Device Security Kit的业务风险智能检测模块，以及日志和错误处理相关的模块：

import { businessRiskIntelligentDetection } from '@kit.DeviceSecurityKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { hilog } from '@kit.PerformanceAnalysisKit';

• @kit.DeviceSecurityKit提供设备安全相关的整套能力，其中包括模拟点击检测。
• BusinessError模块定义了业务错误的标准结构，用于统一捕获和解析异步操作中抛出的异常。
• hilog用于日志记录，便于开发和调试阶段追踪检测接口的运行状态。

4.2 -> 构造请求并调用接口

完整调用示例：

const TAG = "BusinessRiskIntelligentDetectionDemo";

// 构造模拟点击检测请求参数
let params = {
  version: 1
} as businessRiskIntelligentDetection.SimulatedClickDetectionRequest;

hilog.info(0x0000, TAG, '模拟点击检测开始');

try {
  businessRiskIntelligentDetection.detectSimulatedClickRisk(params)
    .then((result: string) => {
      hilog.info(0x0000, TAG, '模拟点击检测成功，结果：%{public}s', result);
      
      // 解析并处理检测结果
      try {
        const riskResult = JSON.parse(result) as {
          timestampMs: number,
          version: number,
          riskDecision: string,
          tags: string[]
        };
        
        // 处理不同的风险决策结果
        if (riskResult.riskDecision === 'fake') {
          // 检测到作弊风险，根据tags做业务处理
          hilog.warn(0x0000, TAG, '检测到模拟点击风险，tags: %{public}s', 
                     JSON.stringify(riskResult.tags));
          // 业务降级或拒绝请求
          handleSimulatedClickRisk(riskResult.tags);
        } else if (riskResult.riskDecision === 'likelyReal') {
          // 当前操作为真人用户可能性较高，正常放行
          hilog.info(0x0000, TAG, '操作看起来正常，继续执行业务');
        } else {
          // unknown 情况，根据业务风险容忍度使用降级策略
          hilog.info(0x0000, TAG, '检测结果未知，按保守策略处理');
          handleUnknownRisk();
        }
      } catch (parseError) {
        hilog.error(0x0000, TAG, 'JSON解析失败: %{public}s', parseError.message);
      }
    })
    .catch((error: Error) => {
      let e: BusinessError = error as BusinessError;
      hilog.error(0x0000, TAG, '模拟点击检测失败, code: %{public}d, message: %{public}s', 
                  e.code, e.message);
    });
} catch (error) {
  let e: BusinessError = error as BusinessError;
  hilog.error(0x0000, TAG, '调用模拟点击检测时发生同步异常: %{public}d %{public}s', 
              e.code, e.message);
}

在上述代码中，需要注意几个关键点：

1. 异步Promise的正确使用：detectSimulatedClickRisk返回的是Promise对象，推荐使用.then().catch()链式语法处理。接口可能因网络问题、服务器异常或次数超限等原因失败，务必实现catch分支。
2. JSON解析：返回的result是一个JSON字符串，需要JSON.parse()之后才能读取其中的riskDecision和tags字段。同时需要考虑解析失败的情况。
3. 业务分支逻辑：根据riskDecision做分支处理是接入中最核心的部分。结合实际需求给出fake和unknown场景下的处理措施。

4.3 -> 业务对冲策略示例

在fake场景下，不同类型的tags可以采取不同的处理策略：

function handleSimulatedClickRisk(tags: string[]) {
  if (tags.includes('AbnormalTap')) {
    // 仅检测到异常点击，可以弹出验证码弹窗
    showCaptchaVerification();
  } else if (tags.includes('AbnormalDeviceIntegrity')) {
    // 设备完整性已被破坏，风险较高，可直接拒绝请求
    rejectOperation('安全检测未通过，请确保设备未被篡改');
  } else if (tags.includes('AbnormalDeviceBehavior')) {
    // 设备行为异常，建议加强验证
    requireAdditionalAuthentication();
  }
}

5 -> 典型场景适用分析

5.1 -> 电商秒杀活动防刷

在秒杀开始的那一刻，大量抢购请求会在极短时间内涌入服务器。黑产团队通过自动化点击脚本甚至可以同时操作上百个设备发起抢购。这种情况下，在用户点击“立即抢购”按钮时调用模拟点击检测接口进行验证，可以高效识别脚本注入和批量设备的点击行为。对于riskDecision返回fake且tags包含AbnormalTap的请求，业务后端可结合频控策略进行拦截或置入排队等待处理。

5.2 -> 营销活动与新人福利

电商、金融、内容社区等App通常会为新注册用户或参与营销活动的用户发放优惠券、红包、积分等权益。黑产往往在短时间内注册大量账号并批量“点击领取”。开发者可以在“领取”按钮的点击事件处理器中增加模拟点击检测；如果检测结果指示异常，可以在后端拒绝该权益的发放，并要求用户完成更高级的实名认证或图形验证码校验后再重试。

5.3 -> 敏感操作二次验证

对于提现、修改交易密码、解绑银行卡等涉及资金的敏感操作，应用的安全性要求远高于普通场景。开发者可以在用户发起操作时调用模拟点击检测，并结合设备完整性检测的结果综合判断风险级别。例如，返回fake并包含AbnormalDeviceIntegrity时，应直接拒绝该操作并要求用户在正常设备上重新登录；返回unknown时，可以进行二次短信验证或人脸识别加强身份核验。

6 -> 总结

鸿蒙6.0 Device Security Kit新增的模拟点击检测能力，与其已有的设备完整性检测、安全环境检测等能力协同构成了一个立体的业务安全检测矩阵。与传统的基于统计和规则的风控方案相比，该系统级检测强调数据采集的地下视角，从设备底层线索中直接捕获作弊信号，具有更高的不可伪造性。

但对任何安全方案而言，技术手段从来都不是万能的。模拟点击检测也存在一些不可忽视的约束：首先，它的调用次数限制（每30秒10次、每天20次）决定了它不可能用于任意高频的调用场景，开发者需要谨慎设计调用策略；其次，返回unknown的情况意味着系统未能做出明确的判断，这在实战中需要结合业务层的风控策略进行兜底；最后，API的进化速度也值得关注——6.0.2版本已开始引入增强版请求参数，后续版本可能会加入更多维度的校验手段。

建议开发者在接入该能力的同时，做好以下几点：

1. 调用频率治理：建立本地的调用计数器或节流机制，避免超出系统配额；同时考虑仅在高价值操作时才触发检测。

2. 结果缓存策略：在一次用户的交互会话中，检测结果的时效性是值得关注的。可以根据业务的风险敏感度决定每次点击都实时调用还是在一定时间窗口内复用上次的检测结果。

3. 多维度安全组合：将模拟点击检测与设备完整性检测、设备状态检测等Device Security Kit内的其他能力结合使用，形成复合安全判断逻辑。

4. 可观测性建设：对模拟点击检测的调用情况、失败率、各riskDecision占比建立监控链路，在后台可以看到整体趋势，当某段时间内fake占比大幅波动时，可能意味着有爬虫或黑产团队正在针对应用进行攻击。提前分析这些数据，有助于动态调整业务逻辑来应对新型攻击手法。

随着黑产技术的日益复杂和自动化程度的持续提升，业务安全的对抗将长期存在。鸿蒙系统通过Device Security Kit提供的一系列底层安全原生能力，为开发者降低了构建业务风控体系的技术门槛。模拟点击检测功能的加入，是这个能力矩阵的重要补全，也是对应用开发者安全需求的正向回应。

---

感谢各位大佬支持！！！
互三啦！！！