Improve app cold start performance

[lowrt]

這是什麼類型的 PR？

選擇所有符合的項目

• 重構
• 新功能
• 錯誤修復
• 最佳化
• 技術文件更新

描述

DeviceInfo 改 背景跑
安卓部分裝置 冷啟動時間省500ms以上

相關 issue

• 相關問題 #
• closes #

QA 指南、截圖、錄像

請將這行替換成：如何測試您的 PR 的步驟，已測試的裝置註釋，以及任何相關的 UI 更改圖片。

UI 無障礙清單

如果您的 PR 包含 UI 更改，請使用此清單：

• 變數名稱實現語意化命名？
• 測試通過 AA 顏色對比？

[lowrt]

@claude review

[claude]

Claude finished @lowrt's task in 1m 8s —— View job

---

Code Review Progress

• Gather context and read repository guidelines
• Read lib/main.dart to understand the code
• Review the diff to see exact changes
• Analyze the performance optimization approach
• Provide comprehensive code review feedback

---

Code Review Summary

This PR makes strategic performance optimizations to improve cold start time on Android devices. The changes are well-targeted and should provide measurable improvements.

Key Changes

1. Platform-specific StoreKit initialization (lib/main.dart:31-34)
2. DeviceInfo.init moved to background on Android (lib/main.dart:82-93)
3. WeatherStationLocalizations.load commented out (lib/main.dart:72-75)
4. Log message cleanup (lib/main.dart:142, 156, 165, 168)

---

✅ Strengths

1. Smart platform-specific optimization: The iOS vs Android handling for DeviceInfo.init is appropriate. iOS awaits initialization while Android runs it in the background, which is a good approach if DeviceInfo isn't immediately needed on Android.

2. Performance measurement: Excellent logging to track the actual time saved by moving DeviceInfo to background execution.

3. Error handling preserved: The background task includes proper error handling in the FCM/notify initialization block.

---

⚠️ Issues & Recommendations

1. Critical: Missing import for unawaited (lib/main.dart:85)

You're using unawaited() but I don't see import 'dart:async'; being added. Wait, I see it's at line 1, so this is fine. However, there's a function call syntax issue:

// Current code (lines 85-92):
unawaited(() async {
    final start = DateTime.now();
    await DeviceInfo.init();
    talker.log(
      '📱 DeviceInfo.init 完成 ${DateTime.now().difference(start).inMilliseconds}ms',
    );
  }(),
);

Problem: You're calling an anonymous async function immediately with () at the end. The unawaited() function expects a Future, not a function call wrapper.

Recommended fix:

unawaited(
  () async {
    final start = DateTime.now();
    await DeviceInfo.init();
    talker.log(
      '📱 DeviceInfo.init 完成 ${DateTime.now().difference(start).inMilliseconds}ms',
    );
  }(),
);

Or more idiomatically:

unawaited(
  Future(() async {
    final start = DateTime.now();
    await DeviceInfo.init();
    talker.log(
      '📱 DeviceInfo.init 完成 ${DateTime.now().difference(start).inMilliseconds}ms',
    );
  }),
);

2. Potential race condition risk (lib/main.dart:82-93)

On Android, DeviceInfo.init() runs in the background, but there's no guarantee it completes before components that might need device info. Consider:

• Does any code in DpipApp() or its children immediately access DeviceInfo?
• If yes, you may need to add null checks or lazy initialization

Recommendation: Document which parts of the app can safely run without DeviceInfo being ready, or add a completion check/fallback.

3. WeatherStationLocalizations commented out (lib/main.dart:72-75)

This appears unrelated to the DeviceInfo optimization. Was this intentional for performance or a separate change?

Recommendation:

• If this is a deliberate optimization, mention it in the PR description
• If it's temporary for testing, it should be uncommented before merge
• Consider moving to a separate PR if it's unrelated to DeviceInfo changes

4. Platform check duplication (lib/main.dart:31, 82)

You're checking Platform.isIOS twice. While not a bug, consider documenting why iOS needs synchronous DeviceInfo initialization while Android doesn't.

---

🔍 Questions for Consideration

1. Does DeviceInfo need to complete before any user interaction? If a user quickly taps something before DeviceInfo completes, will it cause issues?

2. What about error handling for background DeviceInfo.init? The current implementation logs the completion time but doesn't handle errors. Should it catch and log errors like the FCM/notify block does?

3. Why is iOS treated differently? Is DeviceInfo critical for iOS immediately, or is this just being conservative? If it's not critical, iOS could also benefit from background initialization.

---

📝 Suggested Improvements

// Better error handling for background DeviceInfo init
if (Platform.isIOS) {
  await DeviceInfo.init();
} else {
  unawaited(
    Future(() async {
      try {
        final start = DateTime.now();
        await DeviceInfo.init();
        talker.log(
          '📱 DeviceInfo.init 完成 ${DateTime.now().difference(start).inMilliseconds}ms',
        );
      } catch (e, st) {
        talker.error('📱 DeviceInfo.init 失敗: $e\n$st');
      }
    }),
  );
}

---

✅ Verdict

Overall: Good optimization approach with measurable performance gains. The main concerns are:

1. Verify the unawaited() syntax compiles correctly
2. Add error handling to background DeviceInfo init
3. Clarify the WeatherStationLocalizations change
4. Document any race condition considerations

The claimed 500ms+ improvement seems reasonable if DeviceInfo.init was blocking on the main thread before.

---