目录
此内容是否有帮助?

# 客户端 SDK 常见问题

# 客户端 SDK 上报策略是什么？

原生客户端 SDK (包括 Unity、Unreal、Flutter 等) 数据会首先缓存在本地数据库，并在以下情况触发数据上报：

  • App进入后台
  • 30S上报一次（可以在 TA 后台设置）
  • 缓存数据超过 30 条触发上报（可以在 TA 后台设置）
  • 主动调用 flush 接口

小程序、小游戏 SDK，以及 JavaScript SDK 会实时上报，没有本地缓存。

# 设备 ID 的取值逻辑是什么？

原生客户端 SDK (包括 Unity、Unreal、Flutter 等) 的设备 ID 取值逻辑如下：

  • Android: 取 Android ID

对于 Android 8.0 以下的系统，Android ID 是设备唯一标识。重新刷机或者恢复出厂设置才会变更。所有应用共享。Android 8.0 及之后的系统，应用签署密钥、用户和设备的每个组合都具有唯一的 ANDROID_ID 值。因此，在相同设备上运行但具有不同签署密钥的应用将不会再看到相同的 Android ID（即使对于同一用户来说，也是如此）。一个特殊情况：如果用户安装 APP 设备是 8.0 以下，后来卸载了，升级到 8.0 之后又重装了应用，Android ID 会跟之前不一样；如果没有重装，那么 Android ID 不会变更。

  • iOS：先取 IDFV，如果取不到就用随机 UUID。首次取的 设备 ID 值将存入钥匙串中，不再改变，即使 后续 IDFV 发生变化。

小程序、小游戏和 JavaScript 接口无法取得类似的设备号，使用一个随机生成的 ID 作为设备 ID。如果用户删除了缓存，该设备 ID 将会发生变化。

# 客户端 SDK 支持的最低系统版本是多少？

客户端 SDK 支持的最低版本是 Android 4.0 和 iOS 8.0

# 如何排查上报问题？

一般问题可以通过客户端日志很快定位，我们在各个接入指南中都介绍了如何开启客户端日志。

在 Android 中，您可以通过调用 enableTrackLog 接口来开启客户端日志。您可以通过 ThinkingAnalytics 来过滤 Android SDK 的日志。

ThinkingAnalyticsSDK.enableTrackLog(true);

在 iOS 中，您可以通过调用 setLogLevel 接口来开启日志打印，并通过 THINKING 来过滤 iOS SDK 的日志。

[ThinkingAnalyticsSDK setLogLevel:TDLoggingLevelDebug]

在打开日志后，您可以将日志发给我们的技术支持工程师，协助定位问题 。

如果您不确定上报地址是否正确，可以通过检查检查接口来检测上报地址的可达性。 访问 https://YOUR_RECEIVER_URL/health-check，页面返回 ok 表示接收端地址配置正确。

除此之外，通过埋点管理模块的功能，也可以方便的定位到数据上报过程中的问题。

# 通过 Unity SDK 上报数据有哪些注意事项？

  1. 我们的 SDK 的初始化是在 Awake() 中完成的，因此调用不可以在 Awake 中触发
  2. 默认情况下所有接口只能在主线程中调用。
  3. 我们是通过 Android 系统的组件生命周期来判断 APP 是否进入前台或者退到后台的。但是 Unity 中无法保证在程序最开始就初始化 SDK，所以可能会在退到后台的时候才能判断初次启动事件。目前我们会在第一次退到后台的时候补一个 ta_app_start（上报略晚，但是事件时间 #event_time 是正确的，不影响后续分析）

# 崩溃事件包括哪些内容？如何采集崩溃事件

客户端 SDK 支持部分崩溃日志的采集。需要在初始化 SDK 之后，开启 APP Crash 的自动采集。崩溃事件对应的事件名为：ta_app_crash。

触发崩溃事件采集的情况：

  • Android 平台：虚拟机中出现未捕获异常
  • iOS 平台：
    • Unix 信号异常 包括：SIGABRT, SIGILL, SIGSEGV, SIGFPE, SIGBUS
    • NSException 异常
  • Unity引擎中C#异常的采集

← 实时调试 →