DevTools app should connect to new app deployments

[matthew-carroll]

DevTools includes critical performance monitoring tools. These monitoring tools require building in Profile mode, to avoid accumulating lots of Debug mode jank. Profile mode doesn't support hot restart, which means every code change when debugging performance requires a complete app rebuild and restart.

When running DevTools, when the monitored app closes, the DevTools session disappears. Connecting to the next build of the app requires one of the following:

• Typing an IP address in the DevTools experience
• Closing the DevTools experience and re-opening from Android Studio

Both of these options are very tedious. Working through performance investigations and fixes requires dozens, if not hundreds of rebuilds in rapid succession. Needing to close and re-open DevTools for every rebuild is a huge pain point and a persistent frustration.

[matthew-carroll]

CC @slightfoot

CC @kenzieschmoll

[Garima0812S]

I understand that using DevTools for performance monitoring in Flutter can be cumbersome due to the limitations of Profile mode and the need to reconnect to the app after each rebuild. While it's true that DevTools sessions currently close when the monitored app closes, there are a few alternative approaches you can consider to streamline your performance investigations and avoid the need for repeated manual reconnection:

Using the Observatory: The Observatory is a low-level tool provided by the Dart SDK that offers similar functionality to DevTools, including profiling and debugging capabilities. It can be accessed by visiting http://localhost:8181 in your browser. One advantage of using the Observatory is that it remains connected even if the app is restarted. You can keep the Observatory open in a browser tab and refresh it after each rebuild to continue monitoring performance.

Leveraging Hot Reload: While Profile mode doesn't support hot restart, you can still take advantage of hot reload during your performance investigations. Hot reload allows you to quickly apply code changes without restarting the entire app. Although you won't be able to profile in real-time, you can make changes to optimize your code and then trigger a rebuild to observe the effects. This approach can help reduce the number of complete app rebuilds necessary during performance investigations.

Automating the DevTools reconnection: If you frequently switch between your app and DevTools during performance investigations, you can automate the process of reconnecting to DevTools by writing a script or creating a custom Flutter command. This script can automate the steps required to close and reopen DevTools, saving you time and effort. You can explore Flutter's command-line options and Dart's process management capabilities to implement this solution.

Using a combination of print statements and log analysis: In some cases, you may be able to gain insights into performance issues by strategically placing print statements in your code to log relevant data. After each rebuild, you can examine the logs to analyze the performance characteristics of your app. While this approach may not provide the same level of detailed profiling as DevTools, it can still help identify performance bottlenecks and guide your optimizations.

Remember that Flutter is a rapidly evolving framework, and improvements to the development experience are continuously being made. It's worth keeping an eye on updates and releases from the Flutter team to see if they address the pain points you're facing with DevTools and performance monitoring.

Overall, combining alternative tools and techniques with your performance investigations can help mitigate the inconvenience caused by the limitations of Profile mode and the need to reconnect to DevTools after each rebuild.

[darshankawar]

Should this be reported in dedicated repo https://github.com/flutter/devtools/issues ?

[kenzieschmoll]

This could be something that the Dart Tooling Daemon (CC @CoderDake) may be able to help with. If we listen for new vm service events from the IDE (CC @DanTup), then we may be able to establish a new connection automatically in DevTools.

[DanTup]

For DevTools embedded in VS Code, this should already happen. When a new debug session starts, if there are existing DevTools windows in a disconnected state, we'll reload them with the new VM Service URI. I think it may also work for external windows (coordinated via the DevTools server), but don't quote me on that.