在Android開發中，我們避免不了要做一些，有關APP的性能優化的操作，我們在工作中對其的理解也是各有不同，這也和我們的工作經驗和工作方法等因素有關。下來我先我就針對性能優化這塊做一些詳細的說明，我對性能優化的理解與分析。
性能優化：大概從一下幾方面來說：
一、APK：1、APK瘦身 2、離線資源處理
1、APK瘦身：
1）將圖片格式設置爲webp格式
2）去除多餘的語言
3）去除不必要的so庫
4）去除無用資源 Link 檢查（謹慎刪除）
5）開啓混淆
6）移除無用資源shinkResoure
7） 開啓刪除無用資源模式（普通模式、嚴格模式）
8）AndResCuadr微信壓縮模式
離線資源：1. 離線資源建議從服務器下載，不必打入 APK 包中。
二、日誌：
問題：
Android 平臺使用 java 實現日誌模塊，每有一句日誌就加密寫進文件。這樣在使用過程中不僅存在大量的 GC，更致命的是因爲有大量的 IO 需要寫入，影響程序性能很容易導致程序卡頓。選擇這種方案，在 release 版本只能選擇把日誌關掉。當有用戶反饋時，就需要給用戶重新編一個打開日誌的安裝包，用戶重新安裝重現後再通過日誌來定位問題。不僅定位問題的效率低下，而且並不能保證每個需要定位的問題都能重現。
解決方案：mars:xlog
1）先把日誌緩存到內存中 mmap
2）進行壓縮
3）當到一定大小時再加密
4）避免 Android 平臺下存在頻繁 GC 的問題，可以使用 C++ 來實現寫入文件。
三、自定義View：
1、加載長圖優化：
1）壓縮圖片
2）沿着對角線縮放
3）加載屏幕能夠看到的地方
4）複用上一個BitMap區域的內存
5）處理滑動
2、對覆蓋區域的 View ，一定要避免不要重複繪製。比如競技棋牌類型的 APP 。打鬥地主的時候，很多撲克都是覆蓋的，那麼就不能每張圖片進行繪製，一定要先計算顯示的區域，把不需要的截取，然後在繪製。
四、存儲：
1、sharedPreferences：
使用sharedPreferences時，我們經常會遇到一下兩個問題
1）當 SharePreferences 文件還沒有被加載內存時，調用 getSharedPreferences 方法會初始化文件並讀入內存，這容易導致耗時更長
2）Editor 的 commit 或者 apply 方法每次執行時，同步寫入磁盤耗時較長。
針對以上兩個問題，進行解決的方案如下：
1） 使用 apply 異步寫入
2） SharedPreferences 類中的 commitToMember() 方法會鎖定 SharedPreferences 對象，Put 和 getEditor 方法會鎖定 Editor 對象，在寫入磁盤時更會鎖定一個寫入鎖，因此要避免頻繁的讀寫 SharedPreferences ，減少無畏的調用。
3）對於 SharedPreferences 的批量操作，最好先獲取一個 editor ，進行批量操作，然後調用 apply 方法。這樣會比 commit 方法性能高
2、SQLite：
1）使用事務：beginTransaction、setTransactionSuccessful、endTransaction
2）使用索引
3）異步加載
四、網絡
1、連接服務器優化策略
1）不用域名，用 IP 直連(說下 DNS )
2）服務器合理部署
2、獲取數據優化策略
1）連接複用
2）請求合併
3）減小請求數據大小：對於 POST 請求，Body 可以做 Gzip 壓縮，如日誌。
4）減小返回數據大小：
a：使用 Gzip 壓縮
b：精簡數據格式
c：對於不同的設備不同網絡返回不同的內容 如不同分辨率圖片大小
d：需要數據更新時，可考慮增量更新。如常見的服務端進行 bsdiff，客戶端進行 bspatch。
e：支持斷點續傳，並緩存 Http Resonse 的 ETag 標識，下次請求時帶上，從而確定是否數據改變過，未改變則直接返回 304
f：緩存獲取到的數據，在一定的有效時間內再次請求可以直接從緩存讀取數據。