buenaflor
commented
10 months ago Thank you for the report. We will investigate this
Closed ltq918 closed 9 months ago
buenaflor
commented
10 months ago Thank you for the report. We will investigate this
buenaflor
commented
10 months ago Hi I've tested your sample and I cannot reproduce the slow startup after closing it through SystemNavigator.pop and reopening.
Which android version and device are you testing it on? More information on steps to reproduce would be helpful!
ltq918
commented
10 months ago Hello, thank you for your attention to this issue. The difference between using real devices and release mode is more obvious, and the difference between low- and medium-performance models is even more obvious. I tested on an Android 13-based Honor device (Qualcomm Snapdragon 6 Gen 1) and an Android 10-based Xiaomi device (Qualcomm Snapdragon 845). They can currently reproduce the issue, but the emulator for Android 13 seems unable to detect the difference. I just performed the following steps and confirmed that the problem still exists, and it should be traced back to at least the flutter version and sentry_flutter version in September last year.
Steps to reproduce:
ltq918
commented
10 months ago The video may be a good demonstration of the previously described problem. We can find that once you use side swipe twice and trigger SystemNavigator.pop to exit, starting it again will be very time-consuming, but if you interrupt it through the task manager during the time-consuming stage , you can quickly open it
https://github.com/getsentry/sentry-dart/assets/16819135/edb4ba02-8c72-48da-977f-b3b6bd434d53
buenaflor
commented
10 months ago Thank you for the comprehensive steps! We will take a look
buenaflor
commented
10 months ago Just for more clarification as I don't have a lower perf phone on hand right now (will test on one soon): this does not happen without the Sentry SDK?
Could you also reproduce it set up with options.debug = true; and send me a snippet of what was logged
ltq918
commented
10 months ago Sorry it will take a while before I can provide the logs after options.debug = true;. But I have some different new information here. I found a mobile phone with the latest high-performance chip for testing, and ruled out performance reasons. I'm sorry that I misled the direction of this incident.
This problem may be related to the network. The availability of some links varies depending on the country and region. The current problem will not occur in airplane mode or when the network is smooth. When starting after SystemNavigator.pop, does the Sentry SDK Will be blocked by network requests until timeout.
Without the Sentry SDK, this issue does not occur. This is also the main reason why I think sentry_flutter instead of flutter
ltq918
commented
10 months ago The following is the log after I added options.debug = true; and the debug mode was run on the real machine. It records all the information from clicking the icon to getting stuck on the startup screen, and then to entering the main page of the application. You can see that one of the messages is: I/Choreographer(9320): Skipped 960 frames! The application may be doing too much work on its main thread.
buenaflor
commented
10 months ago Thank you for sending those! What's also especially noticable is the failed connection to send an envelope
E/Sentry ( 9320): Caused by: java.net.SocketTimeoutException: failed to connect to example.ingest.sentry.io/34.120.195.249 (port 443) from /192.168.1.106 (port 43588) after 5000ms@ltq918 quick confirmation, are you operating around the China region? There have been quite some incidents regarding China where events are not coming through so it might be related to the network issue.
ltq918
commented
10 months ago Yes, it's in China, but earlier I seemed to be able to use the service, it might not be very stable
buenaflor
commented
10 months ago Did you also notice similar "slow cold boot" behaviour on iOS? or only Android?
ltq918
commented
10 months ago Since there is no analogue of SystemNavigator.pop in iOS with only an exit(0) (but it is not recommended and does not comply with Apple Human Interface guidelines，Refer to this iOS documentation archive.), I am not currently using this approach. I'm guessing there may not be a similar problem on iOS. I'll test this later with exit(0), but actually we probably won't exit the app like this in iOS (because it looks like a crash). However, in Android, this method seems to be commonly used to exit the program.
buenaflor
commented
10 months ago Got it 👍 Thanks for all the info
buenaflor
commented
10 months ago What's interesting is if this is also a problem on native android with our sentry-android sdk - is that possible for you to test? @ltq918
ltq918
commented
10 months ago Even though I'm currently not very good at native Android app development, as far as testing goes, I think I should be fine. But it may take some time
ltq918
commented
10 months ago I just tested with native Android and successfully received the verification message "This app uses Sentry! :)" from the sentry installation guide, the problem does not seem to exist in native android, it works regardless of the network and regardless of the exit method Has good startup performance.
Here are my test steps:
Use the latest Android studio (Android Studio Hedgehog | 2023.1.1)
Select [New Project] and select [Empty Activity]
After the project is initialized, follow the Sentry Android installation guide to add id("io.sentry.android.gradle") version "4.1.1" in YourProjects/app/build.gradle.kts
Add the following code to YourProjects/app/src/main/AndroidManifest.xml
<!-- Required: set your sentry.io project identifier (DSN) -->
<meta-data android:name="io.sentry.dsn" android:value="https://example.ingest.sentry.io/example" />
<!-- enable automatic breadcrumbs for user interactions (clicks, swipes, scrolls) -->
<meta-data android:name="io.sentry.traces.user-interaction.enable" android:value="true" />
<!-- enable screenshot for crashes -->
<meta-data android:name="io.sentry.attach-screenshot" android:value="true" />
<!-- enable view hierarchy for crashes -->
<meta-data android:name="io.sentry.attach-view-hierarchy" android:value="true" />
<!-- enable the performance API by setting a sample-rate, adjust in production env -->
<meta-data android:name="io.sentry.traces.sample-rate" android:value="1.0" />
<!-- enable profiling when starting transactions, adjust in production env -->
<meta-data android:name="io.sentry.traces.profiling.sample-rate" android:value="1.0" />Modify your MainActivity.kt
package com.example.myapplication
import android.os.Bundle import android.widget.Toast import androidx.activity.ComponentActivity import androidx.activity.compose.BackHandler import androidx.activity.compose.setContent import androidx.compose.foundation.layout.fillMaxSize import androidx.compose.material3.MaterialTheme import androidx.compose.material3.Surface import androidx.compose.material3.Text import androidx.compose.runtime.Composable import androidx.compose.ui.Modifier import androidx.compose.ui.tooling.preview.Preview import com.example.myapplication.ui.theme.MyApplicationTheme import io.sentry.Sentry
class MainActivity : ComponentActivity() { private var backPressedTime: Long = 0
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
MyApplicationTheme {
// A surface container using the 'background' color from the theme
BackHandler {
if (backPressedTime + 2000 > System.currentTimeMillis()) {
finish()
} else {
Sentry.captureException(RuntimeException("This app uses Sentry! :)"));
Toast.makeText(
this@MainActivity,
"Press back again to exit",
Toast.LENGTH_SHORT
).show()
}
backPressedTime = System.currentTimeMillis()
}
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
Greeting("Android")
}
}
}
}}
@Composable fun Greeting(name: String, modifier: Modifier = Modifier) { Text( text = "Hello $name!", modifier = modifier ) }
@Preview(showBackground = true) @Composable fun GreetingPreview() { MyApplicationTheme { Greeting("Android") } }
6. Run it on a real machine for previous tests.In addition, if you use exit(0) in flutter to exit the application on the iOS platform, the problem of slow cold startup of the application will not occur.
buenaflor
commented
10 months ago Thanks for taking the time!
stefanosiano
commented
9 months ago I had a look into this.
From what I understand, when an app is closed with the back button on Android, it goes in a detached state, when the flutter engine keeps running, even if no view is visible anymore.
The issue is that we don't close the native layers when the app is in detached state, and when the app restarts, we initialize the SDK again. But the native layer is still running, so the SDK stops the previous native SDK instance and starts it again.
Due to how the Android SDK is implemented, when it is closed, it tries to finish sending the data it has to send, blocking the current thread.
I tried to implement a fix, but the MethodChannel don't work when the app goes in detached state, apparently by design.
Swiping the app away from the recents view kills the app process, stopping the native layers, too. That's why the issue doesn't occur in that case.
This leaves us with the following options:
MethodChannel work in detached state, unlikely but not impossiblestefanosiano
commented
9 months ago The Android SDK 7.4.0 should solve this issue. Let's update it and check again
ltq918
commented
9 months ago I added api 'io.sentry:sentry-android:7.4.0' in flutter_project/android/app/build.gradle, verified that the problem has been successfully fixed. And now using SystemNavigator.pop to exit and re-enter is faster than cold-starting an app by crossing it out from the Android task list.
Many thanks to you and all involved for your work.
buenaflor
commented
9 months ago that's great to hear! Thanks a lot @stefanosiano!
We'll bump the android sdk to 7.4.0 for the upcoming release
Platform
Flutter Mobile
Obfuscation
Enabled
Debug Info
Disabled
Doctor
Doctor output
```console Doctor summary (to see all details, run flutter doctor -v): [√] Flutter (Channel stable, 3.16.5, on Microsoft Windows [版本 10.0.22631.2861], locale zh-CN) [√] Windows Version (Installed version of Windows is version 10 or higher) [!] Android toolchain - develop for Android devices (Android SDK version 33.0.2) X Android license status unknown. Run `flutter doctor --android-licenses` to accept the SDK licenses. See https://flutter.dev/docs/get-started/install/windows#android-setup for more details. [√] Chrome - develop for the web [√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.2.6) [√] Android Studio (version 2023.1) [√] VS Code (version 1.85.1) [!] Proxy Configuration ! NO_PROXY is not set [√] Connected device (5 available) [√] Network resources ! Doctor found issues in 2 categories. ```Version
7.14.0
Steps to Reproduce
Some of my Android users have reported that they sometimes spend a lot of time on the splash screen. I did some testing and found that when using sentry_flutter, once I close the app by double-clicking back to exit (using SystemNavigator.pop), it takes a long time to enter the app again. (about 5-30 seconds), which may take longer than a fresh install or using Android Task Manager to cross out the app and restart (which only takes 1-3 seconds)
Expected Result
The expected result is that when closing using SystemNavigator.pop, the startup speed is not affected and is as fast as opening after installation, or as fast as opening after closing using task management.
Actual Result
The actual result is that when using SystemNavigator.pop to close and launch the startup page, it takes a long time, which may depend on device performance. When you are currently facing a similar issue, use the system task card to close the app and reopen it to launch it quickly.
Are you willing to submit a PR?
None