显示第一个视图模型后，secs交叉订阅消息触发20+ secs停顿

Question

在我的一些视图模型和一些后台运行的服务中，我需要为所有类型的操作提供第二个标记，例如Statemachine progression等。为了避免每次都创建计时器，我有一个TimerService，它每秒发布一条Messenger插件消息。那些需要它的视图模型或服务只需订阅此消息。这在一年多的时间里一直运行良好。最近，我注意到我的应用程序启动时间相当长。经过一些调试后，我发现在启动第一个Viewmodel (它被正确显示)之后，大约需要25秒的时间，订阅才会开始接收到这条消息。似乎有什么东西阻碍了这些消息的发布。在这些20+秒期间，MvvmCross根本没有任何活动。Mvvmcross根本不会记录任何内容。

是什么导致了这样的行为？在启动序列中，messenger插件何时开始分发其消息？

我很抱歉没有在这里发布代码，因为这是一个刚刚在整个应用程序中发生的现象。在后台运行的单例服务直到20秒后才会接收到这些消息，一切都开始正常工作。

编辑: MvvmCross V3.5与Xamarin的最新稳定更新一起使用。在测试的每个Android版本上都会出现问题。

Answer 1

经过一些试验(并再次阅读所有的MvxMessenger文档)，我尝试使用SubscribeOnThreadPoolThread方法，而不是简单地订阅某个发布的消息，后者通常会在视图模型的处理程序中触发定期更新视图模型的属性。这使得问题消失了。通常情况下，如果这个视图刷新消息很快，并且不需要更多，那么处理方法就是将存储库值(由后台服务更新)复制到可见的视图模型属性中。我猜在某个刷新处理程序中有一个同步调用使得信使系统阻塞。还没有找到。会导致Messenger插件阻塞的典型情况是什么？如果能更好地理解这一点，我会非常感兴趣。