4. Performance & Optimization

Performance Metrics

4.1 App Size & Bundle Analysis

Status: ⚠️Warning

Findings:

• Code obfuscation disabled: minifyEnabled = false and shrinkResources = false in release builds significantly increases app size
• Unoptimized assets: Images stored as PNG/JPEG without compression optimization
• No asset optimization: No evidence of image compression, WebP conversion, or asset optimization

Evidence:

• android/app/build.gradle lines 100-106: minifyEnabled false and shrinkResources false in release builds
• pubspec.yaml assets section (lines 145-150): Images listed without optimization
• Assets directory contains PNG/JPEG files: background.png, logo.png, madam.png, camerascope.png, raceflag.png, icon.jpeg
• No ProGuard/R8 shrinking enabled (see security section 1.6)

Risk Level: Medium Risk

Recommendation:

• Immediate actions:
  • Enable code minification and resource shrinking (after fixing crashes that prevented it)
  • Analyze bundle size using flutter build appbundle --analyze-size or flutter build apk --analyze-size
  • Optimize images (compress PNGs, convert to WebP where appropriate)
  • Remove unused assets and resources
• Short-term:
  • Use image optimization tools (e.g., flutter_image_compress)
  • Review and remove unused dependencies

---

4.2 Memory Management

Status: ⚠️Warning

Findings:

• Stream subscription not cancelled: connectivitySubscription in BaseSingleton is never cancelled, potential memory leak
• Image memory usage: Image.memory() used for loading images from bytes without size limits or caching strategy
• Some dispose methods implemented: Some routes properly implement dispose() (e.g., dashboard_route.dart)
• Timer usage: Timer usage found but may not be properly cancelled in all cases
• No memory leak detection: No evidence of memory profiling or leak detection tools
• Large image loading: Images loaded into memory as Uint8List without size validation
• Database connections: Moor database connections may not be properly managed
• State persistence: State saved to database on every change, potential performance impact

Evidence:

• lib/base_singleton.dart line 47: var connectivitySubscription; - subscription never cancelled
• lib/base_singleton.dart lines 61-82: Connectivity stream subscription created but no cancellation in dispose
• lib/routes/race_buddies_route.dart: Multiple Image.memory() calls (lines 124, 183, 187, 202, 239, 243)
• lib/route_models/launch_route_model.dart: Images loaded as Uint8List and written to files (lines 18-47)
• lib/widgets/count_down_timer.dart: Timer properly cancelled in dispose (line 25) - good example
• lib/routes/dashboard_route.dart: Proper dispose implementation (lines 81-84)
• lib/state_models/session_state.dart: State saved to database on every setter call (potential performance issue)

Risk Level: Medium Risk

Recommendation:

• Immediate actions:
  • Cancel connectivitySubscription in BaseSingleton dispose/cleanup
  • Review and cancel all StreamSubscriptions and Timers in dispose methods
  • Add memory limits for image loading (validate image size before loading)
  • Implement proper image caching strategy
• Short-term:
  • Add memory profiling to identify leaks
  • Review all dispose methods for completeness
  • Implement image size validation before loading
  • Use image caching library (e.g., cached_network_image for network images)
  • Optimize database write operations (batch updates instead of per-change writes)

---

4.3 Network Performance

Status: ⚠️Warning

Findings:

• Firebase Performance monitoring implemented: Performance traces added to routes and Dio interceptor for network monitoring
• Timeout configuration: Network timeouts set to 20 seconds (reasonable but may be too long for some operations)
• No request caching: No evidence of HTTP response caching or request deduplication
• No request batching: Multiple individual API calls instead of batched requests where possible
• Token refresh creates new Dio instance: Token refresh creates separate Dio client, potential overhead
• No request retry logic: No automatic retry mechanism for failed network requests

Evidence:

• lib/base_singleton.dart lines 92-94: Timeout configuration (20 seconds for connect, send, receive)
• lib/base_singleton.dart lines 96-98: Firebase Performance interceptor added to Dio
• lib/base_singleton.dart lines 123-124: New Dio instance created for token refresh (overhead)
• No HTTP cache implementation found
• No request batching or queuing mechanism
• No retry logic in error handlers

Risk Level: Medium Risk

Recommendation:

• Immediate actions:
  • Implement HTTP response caching for static/rarely-changing data
  • Add request retry logic for transient failures
  • Optimize token refresh to reuse existing Dio instance where possible
• Short-term:
  • Implement request deduplication for identical concurrent requests
  • Add request prioritization for critical operations
  • Batch related API calls where possible

---

4.4 Battery & Resource Usage

Status: ⚠️Warning

Findings:

• Location services: OneSignal location sharing disabled (OneSignal.Location.setShared(false)) - good for battery
• Connectivity monitoring: Continuous connectivity stream subscription may drain battery
• Camera usage: Camera functionality may not properly release resources

Evidence:

• lib/main.dart line 25: OneSignal.Location.setShared(false) - location sharing disabled (good)
• lib/base_singleton.dart lines 61-82: Continuous connectivity stream subscription
• lib/main.dart lines 18-40: Multiple Firebase services initialized
• lib/routes/camera_route.dart: Camera usage but no clear resource release verification

Risk Level: Medium Risk

Recommendation:

• Immediate actions:
  • Review connectivity monitoring frequency and optimize if possible
  • Ensure camera resources are properly released after use
  • Review Firebase service usage and disable unused services if any
• Short-term:
  • Review and optimize location services usage
  • Implement efficient push notification handling