android同一个手机上不同应用获取的AndroidID不一样-CFANZ编程社区

在今天的移动应用开发中，AndroidID 的获取常常会出现不同应用于同一个手机上取到的值不一致的问题。这不仅影响到用户的体验，还可能引发一系列业务逻辑上的异常。本文旨在记录我们针对“android同一个手机上不同应用获取的AndroidID不一样”这一技术问题的解决过程，涵盖背景定位、演进历程、架构设计、性能攻坚及扩展应用等方面。

背景定位

在某个项目中，我们发现不同的应用在同一设备上获取的 AndroidID 并不一致。业务使用场景主要集中在用户身份验证与行为分析方面，因此这一问题显得尤为重要。

timeline
    title 业务增长里程碑
    2019 : 项目启动
    2020 : 首次用户反馈
    2021 : 功能迭代完成
    2022 : 发现AndroidID问题
    2023 : 启动项目优化

“用户反馈表示不同行为分析应用获取的 AndroidID 结果不一致，导致用户体验差。”

演进历程

经过调研，我们发现 AndroidID 可能因设备重启、应用卸载等原因而改变。关键决策节点在于是否继续使用 AndroidID 作为唯一标识还是转换为其他方式。此时，我们在项目中的配置也进行了一些变更，部分历史配置如下：

# 之前的配置
<android:id="@+id/android_id" />
<!-- 获取AndroidID -->
String androidID = Settings.Secure.getString(getContentResolver(), Settings.Secure.ANDROID_ID);

# 新的配置
<android:id="@+id/custom_id" />
<!-- 使用UUID作为标识 -->
String customID = UUID.randomUUID().toString();

架构设计

经过讨论后我们决定构建一个更为灵活的标识管理结构。核心模块包括标识生成器、存储与获取等功能模块。

modules:
  identifier:
    type: service
    functions:
      - generateID:
          return: String
      - storeID:
          return: boolean
      - retrieveID:
          return: String

性能攻坚

为了验证新方案的有效性，我们进行了压力测试，数据表明，识别速度优化明显。同时，引入了QPS计算模型来展示性能提升。

[ QPS = \frac{Total , Requests}{Total , Time , (seconds)} ]

复盘总结

通过以上迭代，我们总结出了一套可复用的方法论，产品的运营成本和效率得到了显著改善。以下是成本效益分析表：

方案	成本	效益
旧方案	高	低
新方案	中	高

此外，架构评分也较之前有了巨大的提升。

radar
    title 架构评分
    轴名:灵活性,可维护性,性能,可扩展性,用户体验
    评分:4,4,5,4,5

扩展应用

这个问题的解决方案不仅限于当前项目，我们开始在多个业务场景进行适配，包括用户认证、数据分析等。核心模块的源码已发布，供开发者参考，具体路径如下：

journey
    title 方案推广路径
    section 开始
      识别问题: 5: 用户
      评估解决方案: 5: 开发者
      实施方案: 4: 开发者
    section 结尾
      收集反馈: 5: 用户
      优化调整: 4: 开发者

通过这次经验，我们认识到在多应用场景中，统一的标识解决方案对于提升用户体验和业务稳定性至关重要。