Figure

■ My analysis
根据目前的分析，音乐控制器在音乐播放器被杀掉后，会短暂恢复空占位状态，然后又展示音乐信息，在大约 1 分钟后又恢复到空占位状态。原因是，在主动杀掉音乐进程后，系统回到 MediaSession 变更通知，没有音乐信息，展示空占位，然后音乐进程被系统拉起，音乐相关服务重启 MediaSession，将音乐信息通知发出展示在音乐控制器中，大约 1 分钟后，音乐服务进行终止，MediaSession 被释放，音乐控制器恢复空占位状态。

通过第三方音乐 App 的情况分析，基本与系统音乐的现象一致。

■ Next action
根据目前的分析看，音乐播放控制器的行为表现符合逻辑预期，后期找其他机器对比分析。

■ My analysis
音乐从 Recent 清除后，音乐服务可能会再次被系统拉起，服务会发送音乐控制数据给控制中心，且控制中心可操作，这个为系统策略，不做处理。

目前系统表现，音乐被杀掉后服务没有再被重启。这个现象需要进一步分析。

针对音乐播放控制器短暂消失的问题是由于从有音乐数据变为空占位，布局刷新导致，需调整布局的处理逻辑。

■ My analysis
1. 通过分析，移除音乐进程后，音乐停止播放，并且卡片恢复无歌曲模式，但是很快系统会把音乐播放服务拉起来，音乐卡片会刷新，又变为一个有歌曲的模式，并且音乐控制卡片为可操作状态，根据和其他音乐 App 对比，这个系统行为为正常现象，不需要做处理；

2. 经过分析，1分钟后音乐播放器卡片会短暂消失，是因为音乐服务被系统拉起后，没有进行任何操作，即为空闲状态，系统每间隔 1 分钟会检查当前所有的服务状态，若为空闲，会被系统杀掉。音乐播放器卡片从有歌曲状态变为无歌曲状态，是通过移除和重建的方式实现的，所以播放器卡片会先消失，然后再创建一个新的加入到视图容器中。

■ Next action
针对问题 1 无需处理。
针对问题 2，需要将音乐播放器的卡片的更新方式从移除创建变更为刷新，该处理需要先梳理整个音乐播放器卡片的创建移除逻辑，然后修改其创建更新流程。

■ Current conclusion
已处理，代码已入库。

■ My analysis
1. 针对音乐进程被杀掉后，播放控制器又出现，属于系统针对服务的策略，见之前的分析，所以不做处理，保持现状；
2. 针对音乐播放控制器短暂消失的问题，已经处理，麻烦验证。

■ Next action
测试验证。

4.18
验证通过