利用iPhone捕捉360度汽車環景影像的問題
作者 : Jai Chaudry & Greg Surma
為了打造一款軟體開發套件(SDK)，我們利用iPhone的強大功能來執行汽車的360度影像。即便擁有強大的iPhone處理器，在日常的開發工作上仍舊面對一些特定問題...
當今的iPhone智慧型手機功能已經變得相當強大了。為了打造一款軟體開發套件(SDK)，我們可以利用iPhone的強大功能來執行汽車的360度影像，順利推出一款能夠擷取、分析、檢視並上傳這些影像資料的SDK。然而，即便擁有強大的iPhone處理器，在日常的開發工作上仍舊面對一些特定問題。
圖1：利用iPhone檢查車輛的損壞情形。(圖片來源：Fyusion)
這是一款具備豐富相機功能的SDK，因此我們能在內部建立自己的相機傳輸管道，並且擷取高解析度且完整互動的360度汽車影像，從而能夠藉由各種機器學習(machine learning；ML)功能加以增強。當然，使用相機仍然面對一連串既有的問題。
相機的開銷和過熱問題
我們所開發的SDK最近遇到了這樣的使用案例：為了讓相機能夠保持長時間的開啟狀態，使得手機變得過熱。特別是在炎熱的夏天，這個問題更加值得注意。
我們也利用蘋果(Apple)的MetalKit和AVFoundation API，但這些API通常讓GPU和CPU的負荷變得沉重。在擷取一段360度的環景視訊之後，接著利用電腦視覺和Core ML等工具，在所擷取的視訊媒體上執行內部處理。如果未能妥善地均衡處理，所有的這些舉動都會導致手機過熱。所以，我們想出了許多解決方案，以便將這個問題進行最佳化處理。
在iOS裝置上進行機器學習時，最重要的是利用神經引擎，這顯然是專為加速機器學習推論而設計的。其處理速度平均比GPU快十倍，且隨著效能的提升，你也能夠感受到較低的能耗。然而，為了能夠使用這項功能，我們只能使用其所支援的分層。
裝置上機器學習最具價值的應用之一是即時視覺化。為了達到流暢且即時的視覺化而不至於讓裝置過熱，下列是一些需要考慮的事項：
- 跳格(Skipping frames)—無需在每一格影像上都執行機器學習模式。通常在精確度和流暢度之間的最佳權衡是每秒25格(25fps)。
- 在讀取機器學習輸出時，利用直接的資料指標以取代下標陣列(subscripting array)。這兩種方法的時間差一開始似乎可被忽略，而當執行每格數千次之後，所耗費的時間累加起來就很可觀。例如，我們有一款App即利用指標補償法來解壓縮，需要耗時000000012秒；相形之下，利用陣列下標法耗時約0.00000076秒。這兩個數字看起來都非常小，甚至可以忽略，但是在累積一整天的差異後，它們對整個效能的影響至關重要。
- 儘可能利用足以完成任務的最小化網路。由於推論時間通常與網路的規模成比例，最好小心謹慎以避免利用大規模網路，以免為了流暢地進行即時運算而花費太多時間。
- 利用Metal套件進行可視化以取代UIKit。由於我們致力於每秒至少產出25格影像，程式碼就必須盡可能地快速。採用Metal套件著色器(shader)的運算可視化比UIKit快了好幾十倍。因為UIKit是高階架構，主要用於多半處於靜態的介面和使用者介面(UI)元素。另一方面，Metal顧名思義，它相當接近硬體，能夠為高效能繪圖渲染提供所需的低階且低營運成本API。除此之外，為了呈現與UIKit的覆蓋層，我們首先需要運算UIImage；在多數情況下這是由一個相對慢速的CPU完成。另一方面，利用Metal套件，我們能夠在提供Metal著色器的同時計算許多畫素值，所有的這些運算都可在GPU上完成，因而能夠更快地渲染覆蓋層。
- 利用低階的C++和Objective-C++，以取代像Swift等高階程式語言。即使Swift在效能上已經追趕上來了，它仍然無法達到C++的水準。一般的經驗法則是越關注效能，就越需要接近硬體。
- 量化權重。儘管這並不會直接增加推論速度，但將會減少機器學習模式的記憶體佔用及其運算資源，而這將有利於一般App的效能。
上傳任務
上傳作業一開始看起來似乎微不足道，但它也存在固有的問題。以我們的案例來看，由於使用者通常會在停車場使用這一款App，這讓網路情況變得更嚴苛。我們還必須確定，即使這個App在背景執行或被OS暫停時，上傳作業還能夠持續進行。儘管Apple確實提供了特定API來執行這一任務，但它並不如你所想像的那麼簡單。
圖2：使用者可以透過手機來擷取車輛的3D影像，添加聲音或視覺標記，然後透過email、文字簡訊或傳訊App進行傳送。(圖片來源：Fyusion)
為了上傳資料(利用公司專用檔案格式‘.fyuse’)，我們以往曾經使用一連串的多次呼叫(call)。這一開始可能是個還不錯的解決方案，直到開始出現一連串.fyuse的等候作業時，那可能就不再是個好辦法了。值得注意的是，我們必須支援系統後台的上傳作業，同時還要考慮到App的速率限制。你可以把一個限速器視為每次想要喚醒App時所增加的啟動時間。喚醒作業可能採用深層連結的URL、網路呼叫和推送通知等等任何方式。但是，一連串的多次呼叫可能累積並增加啟動所需的時間，以至於完全無法啟動。試想在一個等候作業中，有一百多秒的上傳動作佇列會是什麼狀況。
因此，我們決定將檔案內容壓縮成一個單一的大型檔案，以降低喚醒App所需的呼叫次數。同時，我們也決定利用預先指定的S3 URL進行上傳。這個作法唯一的缺點是如果上傳到98%的完成度時突然故障，就必須從0%重新上傳。為了解決此一問題，我們建議將足夠大的檔案分塊處理。
上述的傳檔途徑也伴隨著一些限制：
- 在開始上傳之前，我們必須先確定所有的檔案已被寫入磁碟。換句話說，那會增加輸入/輸出(I/O)作業並因而增加CPU的使用率。
- 利用Apple的背景URLSession API，很難針對這類傳檔途徑進行除錯。唯一的方法是檢查macOS控制台，看看是否有上傳作業在後台執行。
除錯問題
當我們在開發SDK時，重點在於其躼具備的能力，包括追蹤使用者如何使用該App、追查使用SDK時所產生的任何錯誤和警告記錄，以便能夠檢查系統崩潰等。
在此情況下，找到一個經驗證可行的第三方架構極具吸引力。很遺憾地，第三方架構傾向於被設計用來進行應用級的追蹤，如果將它嵌入在SDK中，利用單例模式(singleton pattern)，很可能導致意外的衝突。所以，我們採用許多機制來協助追蹤系統崩潰；例如當有人利用我們的SDK擷取360度影像時，相應地列印其工作日誌(logs)。如果我們能在SDK的二位元檔案中找到崩潰所在位址，也就能夠利用Atos工具將崩潰事件加以符號化。
如前所述，當有人利用這款360影像SDK時，通常會印出重要的工作日誌。這些工作日誌記錄讓我們瞭解關鍵錯誤、警告，以及在除錯或處理系統崩潰時可能會用到的其他事件。我們也利用Apple所提供的OSLog架構，用於監看執行除錯的工作日誌和OSLog登入記錄，以便監測SDK中所存在的耗時程序。OSLog可以在Mac控制台上印出工作日誌，讓除錯工作變得容易。
本文作者：
Jai Chaudry，Fyusion iOS工程主管 Greg Surma，Fyusion資深軟體工程師
(參考原文：Problems faced when using iPhone to capture 360° car images，by Jai Chaudry& Greg Surma)
加入LINE@，最新消息一手掌握！
