Page 33 - EV Hypercar突破重量與動力極限

效 能，就 越 需 要 接 近 硬 體。
6. 量化權重。儘管這並不會直接 增加推論速度，但將會減少機 器學習模式的記憶體佔用及 其運算資源，而這將有利於一
上傳任務
還要考慮到App的速率限制。你可 以把一個限速器視為每次想要喚 醒App時所增加的啟動時間。喚 醒作業可能採用深層連結的URL、 網路呼叫和推送通知等等任何方 式。但是，一連串的多次呼叫可能 累積並增加啟動所需的時間，以 至於完全無法啟動。試想在一個 等候作業中，有一百多秒的上傳動 作佇列會是什麼狀況。
在此情況下，找到一個經驗 證可行的第三方架構極具吸引力。 很遺憾地，第三方架構傾向於被設 計用來進行應用級的追蹤，如果 將它嵌入在SDK中，利用單例模 式(singleton pattern)，很可能 導致意外的衝突。所以，我們採用 許多機制來協助追蹤系統崩潰;例 如當有人利用我們的SDK擷取360 度影像時，相應地列印其工作日誌 (logs)。如果我們能在SDK的二位 元檔案中找到崩潰所在位址，也就 能夠利用Atos工具將崩潰事件加 以符號化。
DESIGN FEATURES
URLSession API，很難針對 這類傳檔途徑進行除錯。唯 一的方法是檢查macOS控制 台，看看是否有上傳作業在後 台執行。
當我們在開發SDK時，重點在 於其所具備的能力，包括追蹤使用 者如何使用該App、追查使用SDK 時所產生的任何錯誤和警告記錄， 以便能夠檢查系統崩潰等。
圖2:使用者可以透過手機來擷取車輛的3D影像，添加聲音或視覺標記，然後透過email、文字簡訊
(圖片來源:Fyusion)
或傳訊App進行傳送。
除錯問題
般App的效能。
上傳作業一開始看起來似乎 微不足道，但它也存在固有的問 題。以我們的案例來看，由於使 用者通常會在停車場使用這一款 App，這讓網路情況變得更嚴苛。 我們還必須確定，即使這個App在 背景執行或被OS暫停時，上傳作 業還能夠持續進行。儘管Apple 確實提供了特定API來執行這一 任務，但它並不如你所想像的那 麼簡單。
因此，我們決定將檔案內容 壓縮成一個單一的大型檔案，以 降低喚醒App所需的呼叫次數。 同時，我們也決定利用預先指定 的S3 URL進行上傳。這個作法唯 一的缺點是如果上傳到98%的完 成度時突然故障，就必須從0%重 新上傳。為了解決此一問題，我們 建議將足夠大的檔案分塊處理。
如前所述，當有人利用這款 360影像SDK時，通常會印出重要 的工作日誌。這些工作日誌記錄讓 我們瞭解關鍵錯誤、警告，以及在 除錯或處理系統崩潰時可能會用 到的其他事件。我們也利用Apple 所提供的OSLog架構，用於監看執 行除錯的工作日誌和OSLog登入 記錄，以便監測SDK中所存在的 耗時程序。OSLog可以在Mac控制 台上印出工作日誌，讓除錯工作變 得容易。
為了上傳資料(利用公司專用 檔案格式‘.fyuse’)，我們以往曾 經使用一連串的多次呼叫(call)。 這一開始可能是個還不錯的解決 方案，直到開始出現一連串.fyuse 的等候作業時，那可能就不再是個 好辦法了。值得注意的是，我們必 須支援系統後台的上傳作業，同時
上述的傳檔途徑也伴隨著一 些限制:
• 在開始上傳之前，我們必須先 確定所有的檔案已被寫入磁 碟。換 句 話 說，那 會 增 加 輸 入 / 輸出(I/O)作業並因而增加CPU 的 使 用 率。
• 此外，利用Apple的背景
www.edntaiwan.com 29