@TimDams指向您好的方法来检测什么是主题是现在设置，但我没有注意到任何信息如何检测在应用程序运行时期间的主题的更改。用户可以启动您的应用，然后触摸前进到菜单，更改主题，并获取返回到您的应用。虽然您可能认为您的应用程序将被墓碑化，然后重新启动并重新导航到您的页面，与所有的页面加载完全循环 - 这是不是100％是真的。

@TimDams pointed you to one of the nice ways to detect what-theme-is-now-set, but I didn't notice there any information how to detect a change to the theme during the application runtime. The user could start your app, then bump forward to the menu, change the theme, and get back to your app. While you may think that your app will be tombstoned and then restarted and renavigated to your page with full cycle with all pageloads -- it is not 100% true.

PageLoaded不是执行初始检查和设置样式的好地方，因为如果您调用了该事件，则该页面可能已经呈现一次。如果我记得很清楚，PageLoaded在第一次渲染之后被调用。如果这是真的，那么你将不得不先检测颜色，例如在LayoutUpdated（警告：这个事件是一个伟大的垃圾邮件发送者，我的意思是，它被称为gazillions次。附上一个单独的处理程序，你知道，它将在第一次调用时立即取消挂接）。也许你将能够在页面的.ctor中，只是在InitializeComponent后。或者在OnApplyTemplate或MeasureOverride，或至少ArrangeOverride - 视觉效果应该在那里大部分/完全可用。

Firstly, the PageLoaded is NOT a good place to do the initial check-and-set-styles, because, if you get that event called, then the page, probably, has already rendered once. If I remember well, the PageLoaded is invoked just after the first render. If this is true, then you will have to detect the colors earlier, for example in the LayoutUpdated (warning: this event is a great spammer. I mean, it gets called gazillions times. Attach a single-shot handler, you know, such that will instantly unattach-self on first invocation). Maybe you will be able to do it in the Page's .ctor, just after InitializeComponent. Or in the OnApplyTemplate or MeasureOverride, or at least ArrangeOverride -- the visuals should be mostly/fully available there.

Buuuut。我故意粗暴的初始一词。与Mango，有一些多任务越来越常见，但即使是前Mango 7.0版本不保证您的应用程序将墓碑。从我在7.0的早期的观察，例如，从WebBrowser组件启动MediaPlayer不会破坏你的应用程序:)如果你有一些时间阅读，请检查

Buuuut. I've intentionally 'bolded-out' the word "initial". With Mango, there's some multitasking getting more and more common, but even the pre-Mango 7.0 version does not guarantee that your app will be tombstoned. From my observations in early 7.0, for example, starting the MediaPlayer from WebBrowser component does not tombstone your app:) If you have some time to read, check WP7 recover from Tombstone and return to page for details on the "pause" vs "tombstone".

无论如何，如果您的应用程式已暂停，而且使用者切换主题的同时，我认为（我没有检查）您的网页会的情况）只是暂时隐藏，并返回到屏幕，它可能不会被重新创建，将不会被重新（页面）加载。如果是真的，那么你就没有那么容易解决的问题，因为你的应用程序可能被暂停，操作系统重新化，你的应用程序在任何时候虚拟地被取消，你在同一时间得到的唯一的事件。 ... App.Deactivated和App.Activated的全局事件。可能完全没有每个页面的事件会触发[但我没有检查 - 在您执行我在下面的建议，请检查]。

Anyways, if your app gets "paused" and the user switches themes in the meantime, I think (I've NOT checked) that your page will (in most of the cases) be just temporarily hidden and upon returning to the screen, it will probably not be re-created and will not be re-(Page)Loaded. If it is true, then you will have not so easy problem to solve, because your app may be paused, the OS rethemed, and your app unpased virtually in any moment of time and the only events you will get in the mean time are .... global events of App.Deactivated and App.Activated. It is possible that completely none of per-page events will fire [but I've not checked - before you do anything I suggest below, CHECK IT].

如果这个悲观视图真的是真的，比那些事件，你必须检测当前主题（ - > Tim的帖子），然后以某种方式通知您的当前页面主题已更改 - 或不。如果你有你的ViewModel至少有一点点与应用程序的其余部分（因为它应该是:)），你有一个简单的选择：创建在ViewModel一组属性（dp或inotif）像画笔背景，刷前景，刷Hightlight和其他你需要的，而不是harcoding颜色在你的XAML - 绑定到那些属性。你可能想为所有这些许多画笔和其他样式创建一个单独的类，让我们说pub类MyCurrentAppTheme，并保持道具在那里，并公开这样的对象从ViewModel - 无论如何。只需将你的颜色绑定到任何 - 但任何将是逻辑全局，这将很容易从App.Acticated事件处理程序访问。完成后，在App.Activated，检测当前主题，如果更改，所以通过保存在VM中的所有颜色，并设置它们适当。

If this pessimistic view is really true, than in those events, you will have to detect the current theme (->Tim's post), then somehow inform your current Page that themes changed - or not. If you have your ViewModel at least a bit separated from the rest of the app (as it should be:) ) you have an easy option to do it: create in that ViewModel a set of properties (dp or inotif) like Brush Background, Brush Foreground, Brush Hightlight, and other that you need, and instead of harcoding colours in your XAML - bind to those properties. You may event want to create a separate class for all those many Brushes and other Styles, let's say "pub class MyCurrentAppTheme" and keep that props there, and expose such object from ViewModel - whatever. Just Bind your colors to whatever -- but whatever that will be "logically global" and that will be easily accessible from the App.Acticated event handler. Having that done, in the App.Activated, detect the current theme and if changed, so through all the colors kept in VM and set them appropriatelly. Voil'a, whole your App gets recoloured properly.

但请注意，在渲染缓存旧主题，刷新数据绑定对象之间可能会有一些短暂的闪烁和闪烁，并重新绘制新主题。我希望不会，但我感觉可能会发生，特别是当从快速切换工具（长回按）返回：我认为设备捕获您的应用程序的最后一个屏幕截图在后台缓冲区，并使用，在所有的时间应用程序是'最小化'做转换动画，以显示快速应用程序切换概述等。再次，我没有检查，但我怀疑在这样的动画中的页面内容是活，它可以是非常降低CPU / GPU资源。任何人都知道什么？这可能是一个很好的测试，在页面上有一些循环动画，然后切换和检查快速切换概述，无论动画是否移动或停止！：）

But mind that still - there might be some transient blinks and flashes between the rendering of cached old theme, refreshing databound objects, and redrawing fresh theme. I hope not, but I sense it may occur, especially when returning from fast-switch tool (long back press): I think that the device captures the 'last screenshot' of your app in the backbuffer and uses that throughout all the time the app is 'minimalized' to do transitions animations, to show the fast-app-switch overview and so on.. again, I've not checked, but I doubt that during such animations the pagecontents are 'live', it could be very demaning on CPU/GPU resources. Any one knows anything on that? It could be a nice test to have some looping animation on the page and then to switch out and check in the fast-switch overview, whether the animation moves or is halted!:)