我們介紹了優化 Layout、記憶體使用等等，但會影響效能的不只是這些，也不見得都可以從 App 進行改善。效能的問題可能發生在後端 API、UI 的設計或需求過於複雜。我們經常需要跟不同的團隊包含 PM、設計師、API 開發人員一起協助與溝通如何讓 App 的效能更好。
與產品單位的溝通
使用者要可以感受到流暢的操作體驗，其中一個關鍵就是UI的繪制。例如在 60 fps時，每 16 毫秒對 UI 的渲染都要成功。而會影響 UI 操作的流暢除了 Layout 的編排、重複繪製等問題，也有可能是在 UI 的設計本身太過複雜。所以如果 UI 設計真的太複雜，應該與產品單位、設計師來一起討論是否有更好的作法。一個好的 UI 設計應該將複雜度同時考慮進來。工程師的責任也包含告訴設計師”限制”在哪裡。在 App 開發前討論 Prototype 時，就應該考慮畫面是否過於複雜及是否有適合的 Component。
與後端 API 的溝通
當我們感覺 API 很慢，首先以下方式先確認 API 實際花費時間：
- 確認是否為網路問題
- 從 Network Inspector 觀察網路請求時間
- 從 Firebase Performance 觀察使用者網路效能狀況
以上數據如果有問題，就接著來看可能的解決方案。
API 是否可使用Cache
如果是慢在資料庫的查詢，可能查詢資料過多。而這個查詢如果沒有非常即時的必要性，就可以讓 API 使用 Cahce 來提升查詢速度。
是否 1 個 API 查詢過多資料，將其拆為多個 API。
如果畫面需要呈現的資訊過多，可以從重新設計 UI 使其載入畫面分為多個階段，可以先載入足夠呈現畫面的資料，再接著載入剩餘資訊。就可以依此將 API 也拆為多段來減少在同一個 API 大量查詢。
是否多個API 增加查詢次數，合併為1個 API。
如果資料量不多，且在同一個畫面呼叫了多個API，如果可以將API合併為1個，也能增加畫面完整呈現的速度。
分頁功能
為了效能和節省流量的考量，我們通常都會將列表分割成好幾頁、限制一頁在一定的小數量回傳顯示出來。而這需要 API 也能依所需每次只請求需要的資料筆數。而 Android 在 Jetpack 的 Paging 可以很方便的實作分頁，包含以下幾種方式：
- PageKeyedDataSource：在前後一頁的取得方式會從當前分頁而得知，通常是一個網址。
- PositionalDataSource：在資料來源的任意位置載入分頁列表。
- ItemKeyedDataSource：由第 N 筆資料去載入第 N + 1 筆資料。
圖片資源的最佳化
在請求一張網路圖片時，即便使用了 Glide 來載入圖片，當圖片檔案很大時還是會有效能問題。我們可以請後端幫你在上傳圖片時，壓縮不同大小的版本，以便在不同的手機或不同的使用情境使用不同大小的圖片。
溝通與協調
效能不是只有 App 開發人員就可以完全處理好。當有不是 App 工程師可以解決的，請找其他相關人員一起處理。有些效能問題其實多一些溝通與討論就可以解決了。
