26 lines
2.9 KiB
Markdown
26 lines
2.9 KiB
Markdown
# TPSchedule Android 0.5.1+9：启动闪烁修复
|
||
|
||
日期：2026-10-13。
|
||
|
||
0.5.0先显示Android原生启动屏，再通过FutureBuilder构建Flutter品牌页，最后AnimatedSwitcher淡出220ms。Future即使已完成，首次构建仍会进入等待分支；重复快速启动时，第二层品牌页容易表现为短暂闪屏。原实现的回归测试已复现这两个分支。
|
||
|
||
0.5.1恢复此前0.4.0的正常启动方式：先完成controller.initialize，再一次性runApp。原生启动屏保持到首个真正的应用帧，不再额外构建Flutter品牌页或淡出。后台返回同一实例不重新初始化；初始化失败仍可进入原有恢复界面。
|
||
|
||
连续三次冷启动后，录屏还复现后台返回时的无标志亮蓝色预览。已将NormalTheme窗口、状态栏和导航栏的底色改为与课表canvas一致的#F3F7FF，并使用深色系统图标；浅深资源均同步。仅改窗口底色仍不足以控制系统预览；日志确认还有Android SplashScreenView的退场动画。因此API31及以上使用官方setOnExitAnimationListener，在实际应用首帧完成后立即remove系统启动视图，去掉多余退场动画。LaunchTheme及Android12+系统启动屏保持原蓝色和标志，较旧安卓不调用新API。
|
||
|
||
验证期间曾尝试首帧延后/释放方案，但软件渲染模拟器实测需要额外触碰才进入应用；普通widget测试会主动pump且替换帧调度，不能代表原生表现。最终放弃此方案，沿用正常runApp引导所安排的真实引擎帧，不依赖warm-up帧呈现或额外用户操作。
|
||
|
||
自动测试覆盖等待真实初始化完成后启动、缓存数据首次绘制、后台返回、失败后的恢复界面。最终完整Flutter测试141项通过，使用--enable-impeller；静态分析无问题。
|
||
|
||
参考：[Android启动屏衔接](https://docs.flutter.dev/platform-integration/android/splash-screen)、[Flutter首帧延后API](https://api.flutter.dev/flutter/widgets/WidgetsBinding/deferFirstFrame.html)。已核对Flutter本地renderer、scheduler及Android embedding源代码。
|
||
|
||
应用ID仍为com.tpschedule.app，签名配置不变；图标、原生启动配色和通透Dock不改。0.5.0记录保留为历史验证。
|
||
|
||
## 原生检查
|
||
|
||
API36模拟器覆盖安装并进入保存的课表，无需触碰屏幕。最终发布包的冷启动和后台返回录屏位于dist/screenshots/tpschedule-startup-fixed.mp4。普通启动不再叠加Flutter品牌页；后台返回的系统预览由约0.3–0.4秒退场缩短为录屏中的约0.1秒，系统进入动画本身仍由Android控制，不能宣称每台手机完全没有任何系统预览帧。该检查使用软件渲染，具体手机效果还需实机确认。
|
||
|
||
发布包和调试包均构建成功并通过原证书指纹检查；新旧证书及公钥完全一致。源码审查确认初始化失败后的恢复界面与较旧安卓API兼容性保留。
|
||
|
||
发布APK SHA256：D8F4C15E9D3EF02AEF98DDB2BD032E2DF4B7A8166F79C34D524CCC7C08330D29。
|