市面上有很多優化方案，但是都沒有一個完整的鏈路體系，現在它來了，本文將帶你進階新高度，不管是面試、績效KPI，還是彙報宣講，都能讓你遊刃有餘！

前置必讀：

Android包體積優化（常規、進階、極致）涵蓋各階段全面的優化方案。

1、背景

提升下載轉化率
...
提升更新率，這個是鮮有人提到的，二次下載同樣重要，它能推動業務快速落地。

2、現狀

最新版本?MB，突破80大關？100大關？競對？
近6個月平均每個月增速?MB
近6個月平均每個版本更新週期（7天？10天？）

輸出報表

3、目標

減少30MB & 降低30%

4、現狀具體分析

圖片佔比15%
程式碼佔比25%
so檔案50%
其他10%

結合專案分析，輸出每項佔比背後的具體因素（設計花哨？業務複雜？架構合理？）

輸出餅圖

5、優化思路

壓縮參與打包的檔案
減少參與打包的檔案

6、規劃思考

如何保證穩定性？
如何長效治理？

站在更高的角度去思考問題

7、里程碑

資訊公示
確保進度穩中推進
有風險及時尋求資源支援

8、抓手

Android Studio
ApkChecker
ClassShark
...
產出具有專案特色的工具

9、技術大圖

彙報示例

9、圖片優化

手動 -> 指令碼

10、程式碼優化

11、遠端so

需要熟悉打包流程，知道Gradle的各種Task執行在幹什麼事。

打包階段，在合併apk之前，把需要遠端的so檔案上傳至遠端，然後剔除掉。

Flutter的so遠端這方面沒啥資料，提一下，原始碼搜一下FlutterLoader，繼承FlutterLoader重寫startInitialization，原理就是干預原有的so檔案載入路徑。

11.1、下載流程

沉澱通用的下載SDK

網路狀態管理
下載任務優先順序排程
斷點續傳
...

11.1.1、啟動下載（閒時）

閒時下載：使用者是無感知的，即使失敗，也不需要互動形式表現。

11.1.2、按需下載

按需下載：下載流程與閒時下載一樣，但互動表現形式不一樣，需要讓使用者感知你在幹什麼、什麼進度，提供一個loading頁承載。

自檢：不一定是我們程式碼的問題，可能是使用者網路不可用、儲存不夠等

12、測試

相容性：android 5.0-12.0
是否重複下載、是否可用（32/64）
斷網、弱網
覆蓋安裝
前臺退後臺
...

13、監控告警

13.1、埋點

success
error code/message
so name
retry
demotion
storage size
download type
download time
裝置資訊
網路資訊
使用者資訊
...

13.2、監控

下載成功率
load成功率
loading頁開啟成功率
...

13.3、告警

？分鐘？次失敗

告警形式包括但不限於釘釘群、微信群、簡訊、電話等。

13.4、排障

排障指南
資料庫底表查詢sql

14、長效治理

打包後置卡口的設計原理：

打包過程中會對資原始檔、程式碼檔案、jar/aar等檔案進行合併，既然知道有哪些檔案，就可以知道這些檔案的大小，就可以輸出一個file size的檔案作為當前版本的基線。
閾值配置資訊可寫死，可配置。

15、結果

優化前、優化後對比
競對對比
下載時間對比
安裝時間對比
...