隨著當今的裝置及其各自的使用者介面(UI)變得更加先進，創建和產生這些UI也變得更具挑戰性，特別是為現代複雜裝置建置UI通常更燒腦。無論如何，當你想要為特定的自訂嵌入式裝置製作UI時，它可能是一項完全不同的挑戰性任務。

我們經常看到開發人員受限於各式各樣的問題，跌入常見的錯誤陷阱。本文將深入探討這些問題，並揭示開發人員在開發跨平台UI時最常犯的6個與應用和解決方案架構有關的錯誤。

錯誤#1：誤解記憶體消耗和記憶體利用

當開發人員將影像載入繪圖記憶體時，需要考慮的一些事項包括：需要快取的項目、載入元素的順序，以及如何建構整體用戶體驗(UX)。性能問題(通常發生在較小的裝置中)區分為實際和感知性能，例如，對於花費大量時間(實際性能)的操作，開發人員可以在螢幕上彈出預載的影像，讓使用者認為事情發生得更快(感知性能)。然而，解決這些問題需要到位的技術能力和工具。

以嵌入式Linux堆疊為例。現成可用的底層作業系統(OS)可能得花超過10秒的時間啟動，而其上的普通Qt大約需要1秒鐘(圖1)。考慮到在這兩者之上的應用本身，總啟動時間總計約15秒。透過適當的技巧、工具和最佳化，啟動應該只需要1~2秒鐘。

圖1 啟動序列的持續時間在未最佳化和最佳化的軟體堆疊之間差異很大。

在最佳化時，開發人員必須減少性能遲滯，並瞭解真正的瓶頸和時間花費所在。這需要充份地理解記憶體的使用方式、順序，以及如何最佳化並具備相應能力。如果方案需要花費大量啟動時間，顯示最佳化尚未到位，亦說明企業不重視績效，但我猜最終會如願以償，因為客戶畢竟花了錢，對嗎？

錯誤#2：在部署到目標硬體之前於PC上進行開發

這是嵌入式開發最常見的原罪。設計師和工程團隊光是在PC上就花費太長時間開發嵌入式方案，然後，他們在專案週期中又太晚部署到目標硬體上。由於目標硬體通常是新的，而且在專案的早期階段團隊也還用不到，因此該問題通常會進一步惡化。

在專案實施過程中，設計缺陷、性能瓶頸、錯誤或問題的發現時間越晚，其修復成本就越高。將PC與嵌入式裝置進行比較發現，PC幾乎可以不限量地「揮霍」資源、記憶體和功耗，以及其他基礎要素。如果專案在PC上運作良好，可能無法實現添加提升性能的特性，這會導致重新進行架構設計和重新編寫大量軟體的主要問題。在PC桌面上完美運作的東西到了嵌入式裝置上，並不一定就能正常運作或管理，忽略了這一點會影響產品上市時間、提高擁有成本，以及工程和維護成本。

那麼有靈丹妙藥嗎？是的，從第一天開始就在目標裝置上部署。投資在使這一切成為可能的工具，以確保整個團隊(包括設計師)都可以存取目標硬體，如果沒有可用的目標裝置，請選擇接近該裝置的產品，並從第一天開始部署。當今，有很多的現成參考硬體選擇，可讓你足夠接近目標裝置，如果必須只在PC上進行開發，那就在PC上開發，但要做好重新編寫和延遲的心理準備。

錯誤#3：將完全渲染的設計壓縮到嵌入式裝置中

為了在螢幕上顯示酷炫的三維(3D)元素，需要來自設計師的3D設計。設計師經常會創造完全渲染的影像，相當於無數的多邊形(「嘿！它可是在設計師的PC上運作得很好呢！」)。這必須要由開發人員試圖將巨大的3D物件擠進小型裝置中(圖2)，它要不是使一切都變得非常緩慢，不然就是要求開發人員付出額外時間，或者兩弊兼具。

圖2 設計師提供完全渲染的影像，導致對於開發人員來說是過於複雜的元素。

此外，在2D UI上，開發人員和設計師有時會在UI上使用過於複雜的元素。挑戰是如何最佳化不堪(down)、斑駁(shaving)和單調(slimming)的影像、元素和多邊形以適應小螢幕，同時保持相同的用戶體驗。在此過程中，通常都以性能和/或上市時間為代價。

錯誤#4：使用一種編碼語言，以一蓋全

客戶經常用HTML5、Javascript和/或QML編寫過多的應用邏輯。上述都是聲明性的腳本技術，它們將使用與原生(native)C++不同的CPU資源，這通常會導致性能和維護問題。

從一開始就設計軟體架構十分重要。先放上UI層，然後加上C++和更低分層(二進位執行、原生二進位執行，在這些分層上可能使用的GPU和CPU功率)。在設計軟體架構時，選擇正確的元件非常重要。

性能良好的Qt應用有兩個主要部份：應用邏輯和大量數據以C++編寫；UI和使用者互動則使用更高階語言編寫，如QML。

錯誤#5：將更新和安全性視為特性

假設你正在研發一項專案，而且完成了大約三分之二的工作量，然後，客戶希望添加無線軟體更新和安全特性，這要求是錯誤的。更新和安全性並不是特性，它們是設計思維模式(mindset)和整體軟體架構的核心部份。

客戶往往會將更新和安全性視為某段時間中已在其他特性實現的東西，但其實不然。開發人員必須提前計畫和思考，有什麼樣的安全要求？軟體的哪些部份需要定期更新？怎麼實施這項方案？如何驗證？它需要具有從第一天就開始的思維模式。例如，如果開發人員在對UI至關重要的韌體層上編寫內容，則可能無法使用可用於更新應用層和UI的相同機制更新韌體。

錯誤#6：忽略最佳化作業系統中的「工作空間」

本文已在前面部分討論過啟動性能的最佳化(錯誤#1)，但還有更多值得注意之處。

軟體工程的參考影像通常支援許多工具和功能特性，它們專為開發人員設計，以便輕鬆開始實施專案。這些工具都同時運作，但可決定使用或不使用它們，且應著手剝離不需要的東西，以達最佳化。如果不這樣做，系統會在嵌入式裝置上使用其有限的資源，在後台執行無用的進程，千萬不要受累於此。

許多嵌入式專案都使用Yocto配方創建的Yocto影像。可惜的是，由於檔案層級各不相同，這些配方也很難用(圖3)。目前在市場上有許多供應商，因此還需要密切地瞭解硬體驅動器、核心和系統其他部份的工作原理，這部份花在專業諮詢服務上的投資通常會在上市時間和性能提升方面得到投資報酬。

圖3 許多嵌入式專案使用基於Yocto的影像，它們是由複雜的Yocto配方創建，但並不容易使用。

(參考原文：Top 12 mistakes in creating cross-platform UIs, Part 2: Technology and UX design，by Santtu Ahonen)

活動簡介

未來寬能隙半導體元件會在哪些應用成為主流？元件供應商又會開發出哪些新的應用寬能隙元件的電路架構，以協助電力系統開發商進一步簡化設計複雜度、提升系統整體效率？TechTaipei「寬能隙元件市場與技術發展研討會」將邀請寬能隙半導體的關鍵供應商一一為與會者解惑。

贊助廠商

立即報名