效能很重要

效能是觀眾在不測量任何東西的情況下就能察覺的品質面向 [1] [3]。觀眾按下遙控器，啟動畫面停留的時間比預期稍長，他們就已經在判斷這款應用程式是否緩慢且無法使用。緩慢的啟動、卡頓的選單，或是停滯的捲動，都會促使觀眾解除安裝且不再回來。

強大的團隊會將效能與效率視為持續性的工作，而非定期衝刺，並將其融入每次變更在發佈前審核的方式中。

效能驅動應用程式的所有產品功能，再強大的內容、深思熟慮的設計，以及個人化推薦，都無法在空白的啟動畫面或導覽時掉幀的使用者介面中存續。觀眾若要等上四秒才能看到首頁，就會在還沒看到任何內容前，就對目錄做出判斷。當啟動快速且導覽順暢時，內容與個人化團隊所做的工作才能真正傳達給觀眾。若非如此，這些工作就成了付費卻未被接收的成果。

資源效率很重要

在 Fire TV 串流裝置上有效管理資源比行動裝置更困難，因為硬體限制更多。一款典型的低階手機擁有 8 到 12GB 的 RAM，以及運作速度超過 3GHz 的 CPU，而低階的 Fire TV Stick 約有 1GB RAM，CPU 運作速度約 1.7GHz。與手機不同的是，Fire TV Stick 裝置被密封在電視面板後方的 HDMI 外殼中，沒有主動散熱系統。您的應用程式必須在 Fire TV Stick 上運作時，能承受所有這些資源限制。作業系統會在資源壓力下回收記憶體，並終止應用程式以釋放資源。可接受與有問題之間的差距很小，而您的應用程式必須在所有支援的裝置系列上維持穩定，包括仍在使用中的舊款機型。Fire TV 裝置的使用時段也比行動裝置長，因為串流應用程式可能會執行數小時而非數分鐘。在單一晚間觀看中，觀眾就會感受到緩慢累積的問題，而非經過數週的使用才發現。

辨識效能問題

功能問題或當機會產生清晰的調查線索與責任歸屬。而效能門檻的回歸則不會產生任何警示／當機／調查線索，直到多個回歸的累積效應在觀眾訊號中顯現。

→ 當機與 ANR 訊號涵蓋於「穩定性與韌性」支柱中。

商業理由很簡單：啟動快速的時段會帶來更長的互動。緩慢陷入資源壓力的應用程式會逐漸失去觀眾，而不會出現能促使團隊動員的明顯失敗訊號。一個團隊可能連續發佈三個版本，每個版本在各自的儀表板上看起來都沒問題。累積的留存率下滑在季度檢討時才浮現，卻找不到單一變更可以歸咎。堅持讓團隊達到明確效能標準的品質負責人，正在保護產品其他所有投資的回報。

開發流程中的效能習慣

明確的效能門檻與目標

團隊會為冷啟動至第一影格時間 (TTFF)、暖啟動與恢復、導覽期間的持續影格率、1080p 與 4K 播放期間的記憶體使用量，以及閒置 CPU 使用量，定義明確的目標。目標設定於 Fire TV 裝置認證門檻 [3] [7] 之內，而非正好達到門檻，讓應用程式能吸收新功能與 CX 更新而不致超出合規範圍。作為工作基準：60fps 的使用者介面提供每影格 16.67ms 的預算。在 Fire TV Stick Lite 上，健康的 foreground 使用量應遠低於裝置的 RAM 上限，而非正好達到上限。這些目標應被記錄、擁有，並讓品質負責人看得到，而非僅由少數工程師非正式地記在腦中。

良好表現：應用程式效能 KPI [7] 在每次應用程式提交前，都低於平台設定的目標門檻。

將應用程式啟動門檻視為 go/no go 條件

從使用者體驗的角度來看，應用程式啟動可分為 TTFF（從啟動應用程式到螢幕上渲染出第一影格的時間）與 TTFD（當應用程式渲染完成且可供使用者輸入時，完全繪製的時間）。這兩項指標能突顯使用者在決定開啟應用程式後，看到黑屏的時間，以及啟動後需要等待多久才能開始使用。

從速度的角度，將啟動服務分類為必要與可延後。檢視並限制應用程式啟動時的網路呼叫，只保留必要的，因為網路流量會直接影響啟動效能。對剩餘的網路請求，使用快取或平行化機制。在從背景恢復應用程式時，盡可能恢復狀態而非重新初始化堆疊。積極追蹤每個啟動服務影響的團隊，更有可能在不延長冷啟動（應用程式程式碼在未於背景執行時的全新啟動）的情況下發佈 CX 改善。

良好表現：遵守所有應用程式啟動條件下文件化的啟動門檻，適用於每個應用程式版本發佈。 [7]. 在符合所有 KPI 門檻前，暫停應用程式發佈。

在真實世界環境中量測效能指標

在支援範圍內的最低規格裝置 (MVD) 系列以及真實裝置上分析應用程式，因為問題會首先在這些裝置上浮現。最低規格裝置是最有可能最先顯示效能問題的最低規格裝置。在長時間使用後以及在受限的網路環境下，觀察效能指標，使用裝置端分析與記憶體工具 [3]，而非僅依賴開發測試或在理想環境中測試。關鍵指標是從真實生產資料中取樣，而非僅來自內部測試執行。作為標準測試計畫的一部分，應包含在觀眾在應用程式內花費的最長時間內，持續長時間使用應用程式的測試。

良好表現：確保所有效能指標資料點都是在 MVD 裝置以及目標裝置平台上收集。這些資料是應用程式發佈的簽核點。

資源消耗門檻

應用程式的資源監控從應用程式套件的大小開始，接著是使用者與應用程式互動時的記憶體／CPU 消耗。在發佈測試中應執行記憶體預算，視回歸為品質缺陷，而非稍後再處理的小問題。若未及早處理，資源使用可能在多次發佈中累積，造成觀眾感受到選單遲緩與啟動時間延長等降級現象。在整合前，應先分析第三方服務（如分析、廣告、當機回報與 A/B 測試）。對它們應與第一方程式碼設定相同的資源標準。

良好表現：應用程式與整合服務的所有資源使用量測，都在裝置定義的品質門檻內。 [7]

裝置上的熱足跡

由於 Fire TV 裝置是市電供電且被封閉在電視後方，相關的考量框架是熱能與電力效率，而非行動裝置框架的電池續航力。應盡量減少持續的 CPU 與 GPU 使用，並在硬體解碼可用時優先使用。應在真實的觀看情境下執行應用程式，以分析並確認長時間使用應用程式不會增加裝置的熱能測量值。節流很少以單一可見事件出現；它會在長時間觀看時段的後半段，以逐漸的影格掉落與影音漂移的形式顯現。

良好表現：確保針對應用程式發佈執行長時間浸泡測試，以檢查熱能影響。

效能是品質負責人指標 [3]

效能資料與當機資料並列於發佈檢討中。每個新功能的上線都應回答一個問題：這在啟動時間與資源上會造成什麼代價？SDK 採用的決策應考量使用量，而非僅考量功能。當發佈決策在未討論效能的情況下做出時，差距會在稍後浮現於觀眾行為中，而非單一工單。這種負責很重要，因為 200ms 的冷啟動回歸不會產生警示或升級；它必須被主動尋找。品質負責人的關注，是讓緩慢移動的訊號變得像大聲的訊號一樣可見。品質負責人應負責在開發流程中，讓應用程式符合品質指標並進行效能測試 [6]

良好表現：每次發佈準備度檢討都附有效能資料與當機資料，且功能發佈決策僅在檢討效能影響後才簽核。 [7]

品質負責人問題

這些問題是設計給品質負責人在品質檢討、發佈 go/no go 討論，以及發佈後回顧時使用的。強而有力的答案應有資料與指定負責人支持。

啟動與恢復

團隊的 TTFF 與互動時間為何？是否依裝置系列分類？該量測值是否是在支援範圍內的 MVD 上，在真實條件下取得的？

開發團隊是否已實作改善啟動效能的效能指引 [5]。

當觀眾在 30 秒、5 分鐘，以及 1 小時後返回應用程式時，他們看到的是保留的狀態還是完整重新載入，這是否是刻意設計的行為？

影格率與流暢度

團隊是否有來自真實觀眾的影格率資料？團隊能否找出在使用者介面導覽中產生最嚴重遲緩的畫面、互動，以及裝置型號？

新的 CX 功能對使用者介面回應性與導覽流暢度的影響為何？

記憶體、CPU 與資源預算

團隊在啟動時、資源密集型操作期間，以及長時間浸泡後的記憶體使用量為何？

該使用量在過去幾次發佈中的變化為何？

團隊如何在發佈測試中分析資源使用，以及團隊如何根據趨勢進行調整？

上次在長時間工作階段中進行堆積分析以偵測緩慢洩漏是什麼時候，以及誰負責結果？

熱能與持續行為

團隊是否已在目標裝置上，以真實設定執行一小時的浸泡測試，並確認沒有熱能節流？生產遙測是否會顯示節流事件？

當應用程式處於前景但沒有內容播放時，應用程式的閒置 CPU 使用量為何，以及該數字在最近的發佈中是否有變化？

效能文化

啟動延遲、使用者介面回應性，以及資源使用量，是否都是每次發佈 go/no go 標準的一部分，並附有資料？團隊能否說出上次在發佈前就捕捉到效能回歸的版本是哪一次？

當觀眾回報緩衝或播放降級時，團隊是否有裝置端遙測，能在升級到串流管線前，判斷原因是用戶端還是網路端？

下一步

效能與效率是 Blueprint 的第二支柱。下一篇文章將涵蓋穩定性與韌性。這是未受管理的效能壓力最常以當機、停滯，以及無法復原的狀態呈現之處，也是相同的量測工作開始回報之處。後續的支柱建立在這個基礎上。串流體驗取決於健康的裝置端執行階段。發佈與營運卓越取決於在此建立的效能門禁是否在後續的每次發佈中都被執行。