opview：建立駕駛信心，而不是在螢幕上種米（Rice）
從 dashy 到 opview：關於效率、效能與視覺透明度的實驗報告
在開發 dragonpilot 的這些年，我學到最重要的一件事就是：複雜度會殺死穩定性。
許多用戶追求螢幕上的視覺效果（Rice），比如五顏六色的彩虹路徑線（Rainbow Path）或是密密麻麻的實時數據。在靜止時看這些畫面確實很酷，但當你在國道上以 110 公里的時速行駛時，這些裝飾不僅是多餘的，更是有害的。
這就是 opview 誕生的原因：我們需要的是視野的延伸，而不是更多的電子垃圾。
https://github.com/eFiniLan/opview/blob/main/README_zh-TW.md
螢幕是用來「校準信任」的
很多人問過我，為什麼 openpilot 的 UI 不能做得更像導航 App，或是整合更多調整選單？
我的觀點很簡單：openpilot 的螢幕是拿來建立人對輔助駕駛的信心度，僅此而已。
在自動駕駛的領域中，這叫 「信任校準」（Trust Calibration）。螢幕上的那條路徑線（Path）不是畫給你看漂亮的，它是為了告訴你「AI 現在看到了什麼」。當你看到線跟車道精準重合，你的大腦會自動放鬆；當線偏了，你會立刻接管。
這是一扇通往 AI 大腦的窗戶。如果這扇窗戶被過多的「Rice」遮蔽，信任校準就會失效。
華麗 UI 的代價：一般用戶看不見的隱形成本
為什麼我們反對過度裝飾？因為畫面越多（Rice），並不代表系統更厲害，但能確定的是它會消耗更多 CPU 運算資源。在車載設備這種高負荷環境下，每一分算力都是珍貴的：
更多的 CPU/GPU 負擔：每一條彩虹線都需要算力去繪製。
更多的發熱量：運算越多，發熱越多。主機溫度一高就會觸發保護機制（降頻），這會直接威脅系統的穩定。
更多的延遲（Latency）：渲染這些垃圾佔用了系統資源，導致你看到的影像產生微小延遲。在高速下，幾百毫秒的延遲就足以讓「人機協作」的直覺斷線。
為什麼我們將 dashy 精簡化？
當初為了搭配無螢幕機器，我們開發了 dashy。但後來發現 Dashy 愈做愈肥，更致命的是，Video Streaming 極度消耗 Video Encoding（影片編碼） 資源。如果你只是想看一眼路況，卻得讓主機在後台持續進行編碼，這對效能是無謂的浪費。
所以我們決定將 dashy 精簡化，並將視覺呈現功能獨立出來，成為現在的 opview。
opview 的效率優化：算力卸載
opview 的開發邏輯非常純粹：主機只負責給數據，複雜的計算交給顯示端。
純 Dart 3x3 矩陣運算：我們不使用沉重的 3D 函式庫，所有的路徑投影與視覺變換，全是靠純 Dart 的矩陣運算完成。這不僅極致輕量，還能確保跨平台（iOS/Android）的一致性。
算力卸載 (Offloading)：openpilot 主機端現在只需要輸出兩樣東西：1. 行車畫面 與 2. cereal 數據。剩下的所有 UI 渲染、路徑線計算與座標變換，全部由 opview 在你的手機或平板上處理。
這意味著，你可以擁有大螢幕的信心回饋，也不會增加太多的運算量在顯示端上（老舊的手機或是車機也能使用）。
針對不同硬體與用戶的方案
opview 的設計考慮到了現實中硬體的局限與開發者的權衡：
對 oepnpilot 新用戶 (c4)：C4 的 2 吋螢幕實在太小。透過 opview 將 AI 的判斷投射到大平板上，在新手期好好「觀察」AI，建立信心。
對 openpilot 老司機： 你已經熟悉系統行為，不想要螢幕光線干擾駕駛。你可以關閉主機螢幕，確保主機能以最低負載、最低溫度運行。只有在需要確認路況時，再打開手機上的 opview 即可。
獨立、開源、純粹
我們將 opview 獨立出來並開源，讓無論是原生的 openpilot 或是各種 fork 都能快速套用。
我們不是在做導航，我們是在強化人類與 AI 協作的感知力。最好的系統應該像空氣一樣，在需要的時候提供透明度，在不需要的時候悄然退場。
[筆記：什麼是 Rice？]
在改裝車文化中，Rice (或是 Rice Burner/Racer) 在中文通常稱為「台客改裝」、「花俏改裝」或「有樣沒料」的改裝。這源自 “Race-Inspired Cosmetic Enhancements” (RICE)，意指僅在外觀做誇張、廉價的賽車化裝飾，但實際性能並未提升，常被認為是浮誇且不實用的風格。在軟體開發中，我們借用這個詞來形容那些「除了佔用算力外毫無用處」的視覺特效。
✍️ 本文在 gemini 協力下完成，一起調校的不只是 openpilot，還有這篇文章。
我們盡量以最簡單易懂的方式說明，若有任何錯誤也麻煩各位指正。未經授權請勿任意轉發，轉發請註明出處，謝謝。