我在我的應用程序中的循環,通過以下方式C#+的WinRT + Monogame線程網絡(Azure的移動服務)業務
foreach(var entity in mEntities)
{
entity.Update();
}
一些實體維護一個網絡組件一組實體的循環這將調用Azure移動服務以便將其狀態更新到服務器。下面是一個示例:
public class TestEntity {
public int Index;
public int PropertyValue;
public async void Update()
{
Task.Run(() => {
MyAzureMobileServiceClient.Update(Index, PropertyValue);
});
}
}
UI渲染是由Monogame以更傳統的遊戲循環方式完成的。雖然我不知道它的內部工作原理,但我相當肯定它沒有一個真正獨立的線程來完成這項工作。在實踐中,這表示每次調用此更新時UI凍結。
我希望能夠在後臺「順利」運行它。在舊的Windows模型中,通過啓動一個可以處理它的新線程可以很容易地完成,但是我不明白WinRT中的線程是否足夠了解我的方法有什麼問題。
任何想法?
[更新]我也試過這樣:
Task.Factory.StartNew(async() =>
{
while(true) {
await Task.Delay(1000);
MyAzureMobileServiceClient.Update(Index, PropertyValue);
}
});
每1秒,我得到一個迷你凍結像以前一樣。
[更新2]我試了一下。我用標準的HTTP請求取代了Azure移動服務客戶端調用,並且它出色地工作;沒有迷你冰凍。當然,它不是後端,但至少我有手動完成整個事情的工作。但是,寧願不這樣做。
[更新3]這是越來越奇特。我意識到我簡化了這個問題中的代碼,以便在上下文中保持一致。但是,這似乎消除了問題的真正根源。我嘗試了以下幾件事:
- 我創建了一個HTTP請求和手動創建的請求,把它稱爲Task.Run()內,並與無延遲出色的工作。
- 我直接調用Azure移動服務客戶端更新,並且沒有延遲。
所以這就讓我想到問題出在哪裏。我基本上有一個Azure移動服務的包裝類。就是那張在真實路徑看起來大致是這樣的:
CommunicationClient.UpdateAsync(myObject);
public Task UpdateAsync(MyObjectType obj)
{
var table = mMobileServiceClient.GetTable<MyObjectType>();
return table.UpdateAsync(obj);
}
這使得滯後,但如果我這樣做,而不是它這個,它沒有任何延遲作品:
var client = CommunicationClient.MobileServiceClient;
var table = client.GetTable<MyObjectType>();
table.UpdateAsync(obj);
Soooooo ...我應該可能重構整個問題。它變得乾燥。
這是一個有點難以看到所有運動部件的配合在一起這裏。數據請求是否導致暫停或更新帶有獲取數據的用戶界面?如果是後者,這是一個更大的挑戰。 – WiredPrairie
這是後者,這將成爲挑戰。基本上我現在不更新UI,只是發送一個請求。我原來的帖子是不準確的,因爲我使用的是Azure Mobile Service後端爲我的應用程序。實際上,這意味着發送一個HTTP請求並獲得響應。 也許在我的代碼中有一個愚蠢的用戶錯誤,導致我的更新線程等待響應。我可以深入研究Monogame如何處理渲染。如果有幫助,Update()將從Monogame更新循環中調用。 – Muhwu
我應該補充一點,我等待的迴應僅僅是「200 OK」或「### Error」。沒有實際的數據是必需的,我對反正什麼都不感興趣。此外,發送的數據是一個簡單的小型「jsonized」結構,包含幾個字符串和幾個整數。這就是說,移動的數據量非常小。 – Muhwu