SentryExecutorS Thread Continuously Running, Causing High Power Consumption

[sunxu3074]

Description

While using Perfetto for performance analysis, we observed that the SentryExecutorS thread stays in a "Running" state consistently. Specifically, the thread shows continuous green blocks over certain time periods, indicating sustained CPU usage (see attached screenshot). This raises concerns about power consumption, especially during prolonged activity.

We would like to understand the following:

What is the purpose of the SentryExecutorS thread? Is this continuous "Running" state expected behavior, and is there any way to optimize or reduce its CPU usage? Are there any recommendations from the team regarding power optimization? Looking forward to your guidance!

[markushi]

@sunxu3074 thanks for reaching out! Our SentryExecutorService is a single background thread responsible for performing tasks off the main thread. There could be many reasons for it run, e.g. any navigation events, user clicks or system callbacks (e.g. changes to network speed) are processed using SentryExecutorService.

Do you want to optimize the power consumption? You can definitely disable a few features to reduce it. If you can provide some more details about your app / environment we're happy to give you some more guidance!

[sunxu3074]

@sunxu3074 thanks for reaching out! Our SentryExecutorService is a single background thread responsible for performing tasks off the main thread. There could be many reasons for it run, e.g. any navigation events, user clicks or system callbacks (e.g. changes to network speed) are processed using SentryExecutorService.感谢您伸出援手！我们的SentryExecutorService是一个后台线程，负责执行主线程之外的任务。它运行的原因可能有很多，例如任何导航事件、用户点击或系统回调（例如网络速度的更改）都是使用SentryExecutorService处理的。

Do you want to optimize the power consumption? You can definitely disable a few features to reduce it. If you can provide some more details about your app / environment we're happy to give you some more guidance!您想优化功耗吗？您绝对可以禁用一些功能来减少它。如果您可以提供有关您的应用程序/环境的更多详细信息，我们很乐意为您提供更多指导！

@markushi Thank you for your prompt reply. I have tried the following change, set every configuration option to false, but this thread keeps running. Below is a screenshot from the official OPPO app market, where they indicate that my app is continuously consuming battery power.

[romtsn]

@sunxu3074 could you try to disable isEnableScopePersistence = false? This should make the SentryExecutor way less busy. This disables collecting breadcrumbs for ANR events, but it should improve the power consumption significantly.

[sunxu3074]

@markushi I tried the method you provided, and the runtime of the SentryExecutorService thread has indeed decreased. However, it seems that other RxCache threads have increased by about ten and are frequently consuming CPU intermittently. Could you please suggest the most effective and minimal configuration to reduce power consumption? I really don’t want to remove Sentry, as I’ve been integrating and using it for a long time. Alternatively, could you let me know if there’s an optimization timeline so we can re-enable it after the improvements are made?

[romtsn]

RxCache threads should have nothing to do with the Sentry SDK, we don't use RxJava (or any dependency fwiw) in the Android SDK. In general, you could look out for the amount of breadcrumbs that your app generates:

• If it has many Fragments, they will generate a lot of breadcrumbs, you can filter out some Fragment states that you're not interested in to reduce the number of breadcrumbs logged and persisted
• If you use the Logcat integration, you can also specify a minLevel for breadcrumbst o reduce the number of breadcrumbs logged and persisted, or you could also disable it altogether if it's not critical for your case

As for this specific issue with breadcrumbs (with scope persistence), we're working on resolving it as we speak, so expect an update in the next couple of weeks.

[markushi]

@sunxu3074 any chance you had time to look into the RxCache thread utilization?

[sunxu3074]

Thank you for your response. I tried using this configuration isEnableScopePersistence = false while keeping all previous settings unchanged, and I noticed that the SentryExecutorService indeed showed fewer running states. Correspondingly, the running time of the associated daemon threads has also decreased. We’ll roll this out in the next phase and observe.

I’d also like to clarify that our app primarily operates in two processes. The main process is for the keyboard configuration interface, while the :keyboard process is a subprocess running the InputMethodService. The issues we observed occurred in the subprocess. When using TikTok, the SentryExecutorService walltime for our keyboard exceeded TikTok's significantly. Could this be related to both processes initializing Sentry? As far as I know, it’s expected to initialize Sentry in both processes, right?

Regarding the Breadcrumb issue, we’ve been logging some events to make it easier to observe specific logs directly on the Sentry platform. However, I don’t think this is the primary issue, as we’re not logging constantly—only at critical points do we record logs.