# 客户端 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 上报数据有哪些注意事项？
- 我们的 SDK 的初始化是在 Awake() 中完成的，因此调用不可以在 Awake 中触发
- 默认情况下所有接口只能在主线程中调用。
- 我们是通过 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#异常的采集