來源：映維網(wǎng)

多線程（Multithreading）是指從軟件或者硬件實(shí)現(xiàn)多個線程并發(fā)執(zhí)行的技術(shù)。具有多線程能力的計算機(jī)因有硬件支持而能夠在同一時間執(zhí)行多于一個線程，進(jìn)而提升整體處理性能。

微軟混合現(xiàn)實(shí)技術(shù)專家賈里德·拜恩茲（Jared Bienz）是一位著名的軟件架構(gòu)師，有著20多年的從業(yè)經(jīng)驗。日前，拜恩茲撰文分享了自己在AR/VR/MR多線程處理方面的八年經(jīng)驗和技巧。下面是映維網(wǎng)的具體整理：

要正確實(shí)現(xiàn)多線程并不容易，但它對于資源受限的移動設(shè)備流暢運(yùn)行模擬至關(guān)重要。在供職于微軟的生涯中，我有機(jī)會在四年多的時間里幫助合作伙伴為HoloLens編寫高性能的應(yīng)用程序。我另外有4年多的時間幫助合作伙伴為智能手機(jī)和平板電腦編寫高性能應(yīng)用程序。

我早已有意撰寫這篇文章。這基本上是我對AR/VR/MR模擬的多線程處理的8年經(jīng)驗分享。盡管本文主要關(guān)注Unity和C#，但我希望其中介紹的概念依然能夠為所有語言和運(yùn)行時的模擬開發(fā)者帶來價值。

1. 什么是線程？

我知道這是一個基礎(chǔ)性的問題，但我從它開始寫起是有一個重要原因。這個理由會在本章后面變得清晰起來。

維基百科將線程描述為：可以與其它指令并發(fā)執(zhí)行的一系列指令。

我強(qiáng)調(diào)并發(fā)執(zhí)行是因為它對這次討論至關(guān)重要。并發(fā)運(yùn)行多個任務(wù)的能力使得線程對于模擬至關(guān)重要。

2. 關(guān)于內(nèi)核與線程的簡要說明

一個CPU可以有多個內(nèi)核，而有些內(nèi)核可以運(yùn)行多個線程。例如，Ryzen Threadripper最多有64個內(nèi)核，每個內(nèi)核可以運(yùn)行2個線程。這意味著，如果你編寫的模擬屬于高度多線程，你可能會有多達(dá)128個不同的任務(wù)同時發(fā)生。你可以用這些線程來運(yùn)行NPC的人工智能大腦，或者在物理模擬中制造碰撞。

但請記住，大多數(shù)實(shí)際場景不會接近128個線程。即使是英特爾的旗艦i9 10900k都只是提供20個并發(fā)線程。不過，編寫多線程代碼意味著提供多個內(nèi)核的設(shè)備可以同時發(fā)生多個任務(wù)。

3. 線程如何影響應(yīng)用程序

即使你不依賴先進(jìn)的人工智能，但幾乎所有的MR應(yīng)用都在某種程度上使用物理。例如，Hand Menu菜單中的按鈕會使用物理來檢測指尖何時接觸按鈕的表面。

但遠(yuǎn)比物理更重要的是渲染。

幾乎所有的游戲引擎（包括Unity）都依然依賴于單線程進(jìn)行渲染。沒錯，只有一個線程可以在屏幕上繪制。即使是超底層的Directx API都只支持在輔助線程上排隊命令。相關(guān)命令依然需要發(fā)送到渲染線程進(jìn)行繪制。這是一個特別的線程。

正如你可以想象的那樣，從渲染線程獲取代碼可以釋放引擎以繪制內(nèi)容。你將獲得更高的幀速率，看到更少的卡頓和頻閃。你的應(yīng)用程序會感覺更加高響（高響應(yīng)速度）和穩(wěn)定。

4. 好吧，所以不要在Render Thread運(yùn)行代碼嗎？

這聽起來顯然像是在逃避，不是嗎？但事實(shí)證明，Render Thread是所有代碼運(yùn)行的默認(rèn)位置。不僅如此，在Render Thread運(yùn)行代碼是不可避免的事情。為了說明原因，我們下面來看看一個基本的Unity立方體。

使得立方體成為立方體的主要原因之一是稱為網(wǎng)格渲染器（Mesh Renderer）的行為。網(wǎng)格渲染器做什么？當(dāng)然，它繪制立方體。換句話說，為了使一個Unity立方體成為一個立方體，它必須存在于Render Thread之上。

Unity通常將Render Thread稱為主線程、應(yīng)用線程、以及UI線程。請注意，它們都是同一個意思。

5. coroutine（協(xié)程）與線程

當(dāng)Unity開發(fā)者發(fā)現(xiàn)coroutine時，大多數(shù)人認(rèn)為他們已經(jīng)發(fā)現(xiàn)了多線程。遺憾的是，事實(shí)遠(yuǎn)非如此。

Unity負(fù)責(zé)一位coroutine的博士指出：coroutine就像一個函數(shù)，它可以暫停執(zhí)行并將控制權(quán)返回給Unity，但然后會在下一個幀中繼續(xù)執(zhí)行。

重要的是要意識到coroutine依然是在Render Thread上運(yùn)行。

想象一下一個簡單的Unity應(yīng)用程序在這樣的循環(huán)中運(yùn)行：

如果行為A啟動兩個coroutine，則循環(huán)將簡單地更改為：

coroutine和正則函數(shù)的唯一區(qū)別在于，coroutine的一部分可以在幀之間掛起。掛起時會包含存在關(guān)鍵字yield的任何行。盡管這可能會騰出時間讓其他任務(wù)運(yùn)行，但編寫糟糕的coroutine依然非常容易給Render Thread造成巨大的負(fù)載。

coroutine異常：你知道在coroutine出現(xiàn)異常會發(fā)生什么嗎？可能不是你想象的那樣。異常不會停止應(yīng)用程序，甚至不會禁用Behavior。唯一發(fā)生的事情是，coroutine從更新循環(huán)中unscheduled。Behavior不會注意到錯誤，甚至不知道coroutine已經(jīng)被unscheduled。

由于coroutine不是并發(fā)運(yùn)行，所以最好把它看作是一個時間切片機(jī)制。它們不是真正的多線程。

6. Thread.Start又如何？

我們終于聊到多線程的第一個實(shí)際選擇。System.Threading.Thread實(shí)際上代表一個線程，而調(diào)用Thread.Start將導(dǎo)致任務(wù)在所述線程并發(fā)運(yùn)行。

但對于Thread類，你需要理解Thread類的實(shí)例表示一個能夠執(zhí)行工作的對象，而不是請求完成工作。許多函數(shù)可以安排在Thread上運(yùn)行，而等待Thread完成并不一定意味著函數(shù)成功完成。例如，異常可能會發(fā)生。

正是由于這些原因，通用Windows Platform（HoloLens運(yùn)行的平臺）甚至不包括System.Threading.Thread。相反，UWP提供了一種名為ThreadPool的元素，其中各個工作項可以進(jìn)行scheduled。

在本文中，我不打算討論Thread或ThreadPool，因為我希望重點(diǎn)討論另一種方法。不過，我還是想簡單地講講這些問題，因為過去使用Thread的Unity開發(fā)者會由于代碼無法為HoloLens編譯感到困惑或沮喪。Thread類可能會被添加到UWP的未來版本中，但我希望證明即使它可用，我們?nèi)匀挥懈玫哪Ｊ娇梢宰裱?/p>

7. 回調(diào)中的“貓膩”

什么是回調(diào)？維基百科將回調(diào)定義為：作為參數(shù)傳遞給其他代碼的任何可執(zhí)行代碼…這個執(zhí)行…可能會在稍后的異步回調(diào)中發(fā)生。

編寫“經(jīng)典”多線程代碼的開發(fā)者非常熟悉回調(diào)，因為一旦你開始并發(fā)運(yùn)行代碼，不知何故你需要知道它是于何時完成。

下面是一些關(guān)于回調(diào)如何工作的偽代碼：

但如果代碼永遠(yuǎn)都沒有完成呢？如果因為文件被鎖定或數(shù)據(jù)損壞而在第9行引發(fā)異常怎么辦呢？

回調(diào)永遠(yuǎn)不會被調(diào)用。

如果沒有額外的編碼，應(yīng)用程序?qū)⒂肋h(yuǎn)不會知道發(fā)生了錯誤。就應(yīng)用程序所知，LoadData已成功運(yùn)行。這是因為異常沒有發(fā)生在LoadData中，而是發(fā)生在LoadData創(chuàng)建的線程中。

對于嘗試編寫和調(diào)試多線程代碼的開發(fā)者來說，不停止（orphan）的回調(diào)一直是痛苦的根源。簡而言之，這是因為請求、工作和結(jié)果是完全分離的。

回調(diào)與事件:請注意，回調(diào)模式有時可以作為事件實(shí)現(xiàn)。Azure Spatial Anchors在搜索錨點(diǎn)時會執(zhí)行這一操作。應(yīng)用程序調(diào)用CreateWatcher開始搜索，當(dāng)找到錨定時，結(jié)果將通過AnchorLocated事件傳回。這有時會導(dǎo)致意想不到的情況。例如，如果在服務(wù)器上撤銷了錨定，則AnchorLocated事件將以NotLocateDanchordesNotExist的狀態(tài)觸發(fā)。另外，如果發(fā)生網(wǎng)絡(luò)錯誤，應(yīng)用程序不會知道，除非它同時訂閱了Error事件。我并不是說這是一個糟糕的設(shè)計（見下文），但顯然，成功地使用基于事件的回調(diào)系統(tǒng)需要了解哪些情況會導(dǎo)致哪些事件。

8. 什么是跨線程調(diào)度（scheduling）？

讓我們再看看之前的偽代碼：

你注意到第12行對loadCompleted的調(diào)用實(shí)際上是在worker線程中執(zhí)行的嗎？如果我們想在數(shù)據(jù)加載后可視化，這會成為一個問題。請記住，loadCompleted是在worker線程上運(yùn)行的，但我們只能在Render Thread創(chuàng)建GameObject。這就需要跨線程scheduling。

在Azure Spatial Anchors for Unity示例中，你可以找到一個名為UnityDispatcher的腳本。UnityDispatcher允許在任何線程上運(yùn)行的代碼請求該代碼在Render Thread上運(yùn)行。你甚至可能在沒有意識到的情況下看到了這一點(diǎn)。

以下是OnCloudAnchorLocated handler的代碼片段：

每當(dāng)ASA定位到一個錨時，AnchorLocated事件將在worker線程上觸發(fā)。如果應(yīng)用程序只需將消息寫入日志，則可以接受這個worker線程。事實(shí)上這是更好的選擇。但這個應(yīng)用程序需要生成一個GameObject或移動一個現(xiàn)有的GameObject，這兩個操作只能在Render Thread上進(jìn)行。InvokeOnAppThread表示“我知道我已經(jīng)在一個worker線程，但我需要調(diào)用在Render Thread運(yùn)行的代碼”。

9. Unity的跨線程調(diào)度

盡管所有多線程系統(tǒng)都有自己的scheduling方式，但Unity的方法有點(diǎn)不尋常。據(jù)我所知，Unity沒有提供直接的API來調(diào)度渲染線程上的工作。他們提供的是一種間接的方式。

UnityDispatcher保留了需要在Render Thread上運(yùn)行的命令的列表。當(dāng)一個worker線程調(diào)用InvokeOnAppThread時，這只會將代碼添加到列表中。當(dāng)應(yīng)用程序啟動時，UnityDispatcher將自己注冊為coroutine。然后在每個幀上，UnityDispatcher檢查列表中是否有任何內(nèi)容。如果是這樣，所述代碼將作為UnityDispatcher的Update例程的一部分執(zhí)行。

UnityDispatcher沒有綁定到Azure空間錨，因此你可以復(fù)制該類并在任何項目中使用它。如果沒有ASA，你也可以從GitHub上的ThreadUtils項目中獲取這個類的副本。

10. Task-based Programming

針對C++開發(fā)者的說明:我將要開始討論Task-based Programming。我將介紹一個名為Task的C#，但你不會在C++ / WinRT中找到Task。相反，C++開發(fā)者使用IasyccAct之類的接口，而當(dāng)從C#調(diào)用時，這些接口會自動轉(zhuǎn)換為Task。更多信息請參閱這里。

如上所述，調(diào)試多線程代碼非常困難，因為請求、工作和結(jié)果都是相互分離的。但我向你承諾過一個更好的方法，我想現(xiàn)在是時候討論它了。

許多開發(fā)者都知道Task-based Programming，但很少有人真正了解它在幕后的工作原理。Task-based Programming統(tǒng)一了我們前面討論過的概念，大大減少了多線程代碼中出錯的機(jī)會。下面我們來看看Task-based Programming是如何簡化線程、回調(diào)和跨線程scheduling。

11. Auto Threading

在C#中，每當(dāng)一個函數(shù)被async關(guān)鍵字修飾時，我們告訴編譯器的是“這個代碼可以在另一個線程上運(yùn)行”

讓我們來看看將數(shù)據(jù)保存到文件中的一些偽代碼：

在本例中，打開文件、寫入字節(jié)和關(guān)閉文件都將在worker線程上執(zhí)行。

這個神奇的worker線程是什么時候創(chuàng)造出來的呢？它是在使用await操作符時創(chuàng)建的。

如果我們的示例應(yīng)用程序具有以下代碼行：

這相當(dāng)于：

異步函數(shù)中的代碼確實(shí)在新線程上運(yùn)行。但你的應(yīng)用程序不需要知道這些細(xì)節(jié)，也不需要太多地關(guān)注。

更妙的是，正如斯蒂芬·圖布（Stephen Toub）常常說的：“等待的一個美妙之處就是它能把你帶回原來的地方”。讓我們看看這句話在另一個代碼示例中的含義吧：

我們知道這段代碼是從Render Thread開始的，因為它是對按鈕點(diǎn)擊的響應(yīng)。所以在第4行與GameObject交互是有意義的。但我們同時知道，第7行的await關(guān)鍵字啟動了一個新線程。所以，如何才能與第10行和第11行的GameObjects交互呢？

答案是一個叫做SynchronizationContext的元素。簡而言之，無論何時使用await，編譯器都會記住在worker線程啟動之前有哪個線程正在運(yùn)行。編譯器同時會在worker線程完成后立即處理返回Starting Thread的操作。是的，await自動處理跨線程scheduling。

重要提示：await永不加塞。看起來像是await妨礙了Starting Thread，但這只是編譯器的錯覺。await之前的所有內(nèi)容都是內(nèi)聯(lián)運(yùn)行，而且await之后的所有內(nèi)容都由調(diào)度程序運(yùn)行。當(dāng)Task在另一個線程中運(yùn)行時，Render Thread就是這樣保持繪制的。

12. 跟蹤工作

正如我在Thread.Start一節(jié)指出地那樣：線程表示一個能夠執(zhí)行工作的對象，而不是請求完成工作。這是Task-based Programming的另一個亮點(diǎn)。任何Task實(shí)例實(shí)際上都表示一個要完成的工作的請求。這正是Task類擁有IsCompleted和IsFaulted之類的屬性。

13. 數(shù)據(jù)與異常

我在上面提到回調(diào)和事件可以在worker線程完成時返回數(shù)據(jù)。我同時提到了worker線程上的異常通常意味著回調(diào)不運(yùn)行或事件不觸發(fā)。Task-based Programming通過將數(shù)據(jù)作為請求本身的一部分來解決這個問題。

讓我們來看看相同的LoadData函數(shù)，但我們將其作為Task而不是回調(diào)來實(shí)現(xiàn)：

讓我們假設(shè)第7行執(zhí)行一些數(shù)據(jù)反序列化。大多數(shù)時候，這一切都很好，但偶爾我們的應(yīng)用程序會打開一個損壞的文件，第7行會出現(xiàn)一個異常。請記住，這個異常是在worker線程上引發(fā)的。那么，Starting Thread如何處理這個異常呢？比你想象的要簡單：

當(dāng)我們等待一個Task并且該Task成功時，來自該Task的任何數(shù)據(jù)都將返回到Starting Thread。但是，如果我們等待一個Task，并且在Task內(nèi)部發(fā)生了異常，該異常將傳播回Starting Thread，就像它是內(nèi)聯(lián)發(fā)生一樣。換句話說，在Task中處理異常和在任何普通函數(shù)中處理異常都是一樣的。

希望大家能夠開始明白為什么Task-based Programming會使多線程變得更容易。Task-based Programming提供了一個單一的統(tǒng)一模型。在這個模型中，請求、工作和結(jié)果都真正地相互關(guān)聯(lián)。

14. 當(dāng)撤銷（Cancellation）非常重要的時候

在某些情況下，Task可能會運(yùn)行很長時間。例如，在慢速網(wǎng)絡(luò)上下載大文件時。在這些場景中，使Task變得可撤銷通常會很有幫助?？梢酝ㄟ^將CancellationToken傳遞到異步函數(shù)來實(shí)現(xiàn)。然后，在運(yùn)行一會后，所述函數(shù)可以在執(zhí)行更多操作之前檢查Token是否已撤銷。

下面是所述函數(shù)的可能樣子：

盡可能頻繁地檢查CancellationToken非常重要，這樣可以快速撤銷Task。調(diào)用ThrowIfCancellationRequested時，如果Token已被撤銷，則整個Task以O(shè)perationCanceledException結(jié)束。

既然我們已經(jīng)看到Task可以撤銷，下面我們來想象一下使用Task的Azure Spatial Anchors：

我并不是建議ASA應(yīng)該停止使用事件而開始使用Task。ASA可以同時搜索多個錨，而ASA從不知道何時（甚至是否）定位錨。事件在這種情況下的效果很好，只要你知道什么時候觸發(fā)了哪些事件。但是，除了事件之外，添加對Task的支持可以幫助簡化許多常見的場景。

15. coroutine還是有一席之地的

既然我們已經(jīng)知道Task的作用，有人可能會問為什么我們要用其他方式編寫代碼。但請記住，Task在worker線程上運(yùn)行，而GameObject只存在于Render Thread上。這就是coroutine的意義所在。

coroutine在Render Thread上運(yùn)行，但可以將時間返回到渲染器。訣竅是在yielding之前確定工作量。太少會需要很長時間，而太多則會導(dǎo)致應(yīng)用程序沒有響應(yīng)。

讓我們想象一個能夠接收數(shù)據(jù)并用GameObject可視化的coroutine吧：

為了保持60 FPS，應(yīng)用程序需要在大約16毫秒內(nèi)渲染幀。我們假設(shè)我們的應(yīng)用程序需要4毫秒來渲染。剩下的12毫秒可以用來創(chuàng)建GameObject。

如果第10行需要2毫秒，我們就會剩下6毫秒的容量。不僅如此，我們的應(yīng)用程序每幀只能創(chuàng)建一個GameObject。

在本例中，更好的實(shí)現(xiàn)可能如下所示：

在C#中，%運(yùn)算符計算余數(shù)。所以這里我們說的是“每6個對象之后，把時間還給渲染器。”6個對象x每個對象2毫秒=12毫秒（正好是我們的預(yù)算）。

顯然，這個數(shù)字對于每個應(yīng)用程序而言都是獨(dú)一無二，并且會隨著時間的推移而變化。應(yīng)用程序可能會變得更加復(fù)雜，需要更長的時間來渲染?；蛘呙總€單獨(dú)的GameObject可能會變得更復(fù)雜，需要更長的時間來創(chuàng)建。沒有神奇的數(shù)字。要達(dá)到正確的平衡，你需要花時間分析性能。

16. 將coroutine視作Task

所以coroutine有自己的用武之地，但現(xiàn)在我們有兩種不同的方法來處理長時間運(yùn)行的代碼。不僅如此，除非我們實(shí)現(xiàn)某種回調(diào)，否則應(yīng)用程序?qū)⒉恢繴isualizeRoutine何時完成（我們已經(jīng)知道回調(diào)中的“貓膩”）。如果我們能把coroutine當(dāng)作Task來對待，那不是很好嗎？

有一個名為TaskCompletionSource的類允許你將任何長時間運(yùn)行的進(jìn)程表示為一個Task。具體如下：

在一個長時間運(yùn)行的流程開始時，創(chuàng)建TaskCompletionSource。使用TaskCompletionSource.Task表示長時間運(yùn)行的過程。完成后，使用TaskCompletionSource.SetResult返回數(shù)據(jù)。如果進(jìn)程遇到錯誤，請使用TaskCompletionSource.SetException來傳播異常。

我們可以很容易地修改VisualizationRoutine以接收TaskCompletionSource，并在完成后返回一些數(shù)據(jù)：

剩下的只是啟動coroutine并返回Task的helper函數(shù)：

17. coroutine中的異常處理

如果你仔細(xì)觀察，你可能已經(jīng)注意到上面的coroutine中有一個非常重要的遺漏。如果在第26行之前產(chǎn)生異常會發(fā)生什么事情呢？

遺憾的是，coroutine不能提供與async相同的編譯器效果。coroutine中沒有自動異常傳播，這意味著如果我們不處理異常，我們將以產(chǎn)生一個不停止的Task。任何等待Task的代碼將永遠(yuǎn)不會恢復(fù)。如果你認(rèn)為這聽起來很像是一個不停止的回調(diào)，你絕對正確。

你說：“沒問題。我把所有一切都打包到一個try/catch block中。”

可能看起來像這樣：

這正是你要做的事情，除了現(xiàn)在第24行生成了一個CS1626編譯器錯誤。

錯誤CS1626無法在帶有catch clause的try block中生成值。

CS1626出現(xiàn)的原因非常復(fù)雜，但你只需知道你不能將try/catch放在任何使用yield的行中。這給我們留下了兩個可能的選擇：

在任何非yield行周圍放置多個try/catch block。在IEnumerator周圍放置try/catch

選項1最簡單，但并非所有情況下都有效。例如，你不能將try/catch放在foreach語句周圍，因為foreach語句包含一個yield。

但我們?nèi)绾螌?shí)現(xiàn)選項2？通常，IEnumerator直接傳遞到startRoutine。

遺憾的是，事情變得麻煩起來。IEnumerator接口有一個屬性和兩個函數(shù)。我們必須確保，若任何part-IEnumerator產(chǎn)生異常，我們就將結(jié)束Task。

為了幫助解決這個問題，我創(chuàng)建了ExceptionSafeRoutine。你可以在GitHub的AsyncUtils.cs中找到它。ExceptionSafeRoutine接受一個IEnumerator和一個TaskCompletionSource。如果在IEnumerator中引發(fā)任何異常，則在TaskCompletionSource設(shè)置該異常。還有一個擴(kuò)展方法可以將任何IEnumerator轉(zhuǎn)換為ExceptionSafeRoutine。

最后，我們更新Visualization Async以確保Task始終完成：

這種方法的酷炫之處在于，任何異常都會被傳播。即使協(xié)程沒有try/catch block。這使得coroutine的工作方式就像async一樣。我們唯一要記住的是，在開始一個coroutine時添加.WithExceptionHandling。

18. 總結(jié)

如果你看到最后，希望你能夠向我分享你的想法。你是否學(xué)到什么呢？有什么我需要補(bǔ)充或者遺漏的嗎？或者你有什么其他更好的方案嗎？

原文鏈接：https://yivian.com/news/80052.html