🧪 Performance Profiling:

First:

📉 Before Optimization

In the initial profiling analysis using Flutter DevTools, we noticed a Jank frame occurring during the budget submission process. This means that the frame took longer than expected to render, particularly due to heavy processing on the main thread, which caused UI blocking.

As shown in the image above, the raster thread peaked at 13.0 ms, exceeding the 16ms threshold and causing a dropped frame.

---

🧩 Applied Micro-Optimization: Isolate for API Calls

To resolve the performance issue and improve responsiveness, we applied the following micro-optimization strategy:

• The budget saving process, including network communication and JSON serialization, was extracted from the main UI thread.
• We used Isolate.spawn() to run this operation asynchronously in a separate isolate, preventing any delay in the UI rendering pipeline.

This ensured that the user interface remained responsive even during the heaviest part of the operation: API submission and validation.

---

📈 After Optimization

After implementing the isolate optimization, we re-ran the Flutter performance profiler. The raster thread stayed consistently below the 16ms threshold. No Jank frames were detected.

This demonstrates that the isolate successfully offloaded the work from the UI thread, reducing lag and improving app responsiveness.

---

Second:

📉 Before Optimization

In the initial performance profiling using Flutter DevTools, we observed multiple Jank frames during the execution of the feature. The UI thread was overutilized, especially during asynchronous data handling and widget rebuilding, causing noticeable frame drops and sluggish user experience.

As shown in the image above, maybe because of the entire widget is rebuilt each time a marker is selected and if the number of ATMs is high, or if the setState function is wrapping more logic than necessary, it can slow down the interface, creating a bad performanced. Also having a lot of high values close to 8ms.

---

🧩 Applied Micro-Optimization: centralized selectedAtm as an object and reduce the scope of setState

To resolve the performance issue and improve responsiveness, we applied the following micro-optimization strategy:

• We use a single selectedAtm object.
• We only rebuild the widget that displays the selected ATM, not the entire screen.
• We only rebuild if the ATM actually changed.
• We reduce unnecessary calls to setState.

We increase performance, especially when the map has many markers or they are selected repeatedly.

---

📈 After Optimization

After implementing the isolate optimization, we re-ran the Flutter performance profiler. The execution was significantly smoother, with stable frame times across both UI and raster threads.

This demonstrates that the isolate successfully offloaded the work from the UI thread, reducing the values ​​almost by half.

---

Third:

📉 Before Optimization

In the initial profiling analysis using Flutter DevTools, we observed occasional Jank frames occurring every time the app fetched the authentication token. Each call to SharedPreferences.getInstance() during AuthService.getIdToken() incurred disk I/O, which showed up as spikes on the raster thread (exceeding the 16 ms frame budget).

As shown above, the raster thread peaked around 13 ms when the token was read from disk, causing a dropped frame and momentary UI stutter.

---

🧩 Applied Micro-Optimization: Singleton Token Caching

To eliminate this source of jank, we:

1. Converted AuthService into a singleton and added a private String? _token field.
2. Initialized that singleton once at app startup (await AuthService.instance.init()), loading the token from SharedPreferences a single time.
3. Stored the token in the singleton’s _token field whenever we performed login.
4. Modified getIdToken([forceRefresh]) to return the in-memory _token immediately (unless a refresh is explicitly requested), avoiding repeated disk reads.

This ensures that subsequent calls to retrieve the token are served directly from RAM in under 1 ms, rather than triggering SharedPreferences I/O.

---

📈 After Optimization

After implementing the singleton-caching strategy, we re-ran the performance profiler. The raster thread now stays well below the 16 ms threshold, with no Jank frames when reading the token—showing virtually no delay in the authentication flow.

This demonstrates that caching the token in memory successfully removed the disk I/O bottleneck, resulting in a noticeably smoother and more responsive login experience.