无法在虚拟设备上重现 Unity AppCrash 错误是否证明了与真实设备有关的任何信息?

Does the inability to reproduce a Unity AppCrash error on a virtual device prove anything about the real device?

我一直在尝试重现同事构建的 android 应用程序的错误。我们的客户每次 运行 时都会让应用程序在 phone 上崩溃。 我怀疑该错误与应用程序(它是一个统一应用程序)所针对的图形 API 有关,但还不能确定。

为了找出问题所在,我正在使用 Android Studio 中的 Android 虚拟设备模拟器来制作客户端看到崩溃的确切设备的虚拟版本(这是我无法访问的旧三星 运行ning Android 4.4.4)。

应用程序从未在虚拟设备上崩溃或产生任何错误这一事实是否证明了我对错误来源的看法?

换句话说,我如何确定 Android 虚拟设备准确地再现了真实设备 - 特别是在其图形和处理器方面(我认为这是错误的根源) ?

奖励: CPU (ABI) 或图形渲染设置会在复制保真度方面改变什么吗?

调试时,不会有什么坏处:

  • 在任何类型的真实 Android 设备上尝试相同的操作,
  • 按照您的描述在 AVD 上尝试相同的操作。

如果您无法使用上述方法重现它,那么您只是验证那些测试用例有效。但无法重现错误并不能证明其原因。充其量只是缩小搜索范围 space。但是搜索有多大space?

为了回答这个问题,一般来说,我认为 AVD 不擅长重现此类设备错误。 AVD 不会准确复制的搜索 space 很大:

  • 渲染或 GPU 错误,
  • 架构或本机库错误,
  • 内存错误,并且
  • 您可能会在 AVD 上发现的几乎任何逻辑错误,但不会因为您的配置不同。

因此,如果您无法重现错误并且似乎无法在类似设备上安装该应用程序,我同意@james-poag 的观点,您可以:

  • 如果是技术性的,请向用户询问设备日志。 You may use adb as a standalone tool these days.
  • 访问用户并将他们的设备插入 Android Studio。
  • 如果他们看到“强制关闭”对话框,请他们使用 Google 播放来报告错误。然后,您可以通过 Google Play 控制台查看详细信息。
  • 要求开发者包括日志上传。
  • 包括崩溃报告工具,例如 Fabric Crashlytics(IMO,这非常好)。

FWIW,我认为你的怀疑很可能是正确的,但在你获得更多细节之前,你无法证明这一点。

注意:我认为您的问题已被否决,因为您的标题太笼统了。也许考虑编辑它以反映在 AVD 上测试 Unity 应用程序的细节。