Android 把性能優化落到實處

時間 2019-11-07

原文原文鏈接

App的優化目的是爲了讓應用更快、更穩定、更小。網上也有不少相應的文章，可是不少由於花費時間跟優化程度不成正比，或者許多在開發過程當中本身已經避免了因此僅僅記錄一下本身最近用過的。java

更快

啓動白屏

<!--啓動activity時白屏替換-->
    <style name="SplashStyle" parent="AppTheme">
        <item name="windowActionBar">false</item>
        <item name="windowNoTitle">true</item>
        <!--若是須要效果更圓滑能夠換成啓動頁的背景圖-->
        <item name="android:windowBackground">@color/theme_color</item>
         <!--帶有這個屬性就會去除劉海屏-->
        <item name="android:windowFullscreen">true</item>
    </style>
複製代碼

把啓動頁的主題換成android

<activity
            android:name=".SplashActivity"
            android:launchMode="singleTop"
            android:screenOrientation="portrait"
            android:theme="@style/SplashStyle"
            >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
複製代碼

注意git

可能有些人直接換MainActivity的主題，這樣會有些問題，背景在啓動後處須要換過來。而且不能設置去除劉海屏的屬性，有些手機不適配，劉海屏處是白的。多是我本身沒有找到控制劉海屏的方法。但願大佬指點一下
跳轉到MainActivity不能直接把啓動頁finish掉，不然跳轉時會有一瞬間白屏。須要延時幾秒finish

//延時銷燬，避免白屏
   new Handler().postDelayed(() -> {
       finish();
   }, 3000);
複製代碼

跳轉時最好換一下系統默認的跳轉動畫，效果會比較圓滑

ARouter.getInstance().build(RouterPath.MAIN)
                                .withTransition(R.anim.common_popup_fade_in, R.anim.common_popup_fade_out)
                                .navigation(this);
複製代碼

<alpha
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="300"
    android:fromAlpha="1.0"
    android:interpolator="@android:anim/decelerate_interpolator"
    android:toAlpha="0.0"/>
複製代碼

<alpha
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="300"
    android:fromAlpha="0.0"
    android:interpolator="@android:anim/decelerate_interpolator"
    android:toAlpha="1.0"/>
複製代碼

延時加載

/**
     * 屏幕之外信息延時獲取
     */
    private void initDelay() {
        // 拿到主線程的MessageQueue
        Looper.myQueue().addIdleHandler(() -> {
            // 最後返回false，後續不用再監聽了。
            return faslse;
        });
    }
複製代碼

addIdleHandler 方法是當handle線程空閒再執行，基本上能夠理解爲界面顯示後再執行。具體原理能夠看mp.weixin.qq.com/s/KpeBqIEYe…github

異步加載

對於一些不必在主線程執行的代碼，如sp、數據庫等代碼能夠在子線程初始化。數據庫

佈局優化

看看是否過分繪製以及嵌套層級是否過多。這種通常在寫代碼時注意一下後期能夠避免不少工做。設計模式

同一層級時LinearLayout、FrameLayout比RelativeLayout性能要好。
寫佈局時background可避免的儘可能不設置
靈活使用ViewStub，實例化才加載而且只加載一次。

一些其餘

點擊事件優化

不少app沒有作點擊偏差處理，因此有時候點擊兩次會出現兩個界面，雖然影響不大可是爲了讓用戶體驗更好。最好一開始就作好api

使用RxBind具體看github
使用工具類

public class ViewOnClickUtils {
    private static final int MIN_DELAY_TIME= 1000;  // 兩次點擊間隔不能少於1000ms
    private static long lastClickTime;

    /**
     * 判斷是否快速點擊
     * @return
     */
    public static boolean isFastClick() {
        boolean flag = true;
        long currentClickTime = System.currentTimeMillis();
        if ((currentClickTime - lastClickTime) >= MIN_DELAY_TIME) {
            flag = false;
        }
        lastClickTime = currentClickTime;
        return flag;
    }

    /**
     * 判斷是否快速點擊
     * @param time 設置時間
     * @return
     */
    public static boolean isFastClick(int time) {
        boolean flag = true;
        long currentClickTime = System.currentTimeMillis();
        if ((currentClickTime - lastClickTime) >= time) {
            flag = false;
        }
        lastClickTime = currentClickTime;
        return flag;
    }
}
複製代碼

tv.setOnClickListener(view -> {
        if (ViewOnClickUtils.isFastClick()) {
            return;
        }
        //邏輯操做
        ...
     }
複製代碼

圖片壓縮

更小的圖片意味着加載更快，上傳也更快。性能優化

之前在外包公司作的時候，ui給的圖片很大，沒有作到最大限度的壓縮，一個背景圖幾百k，加載的時候回出現內存抖動，因此最好叫UI或者本身去網上找一下壓縮。
圖片上傳時也應該使用壓縮，一款很是棒的圖片壓縮開源框架github.com/Curzibn/Lub…

更穩定

避免內存泄漏、內存抖動。我我的以爲這跟平時寫代碼比較相關bash

注意

須要傳入Context的地方，須要注意生命週期是否一致。好比單例應該用ApplicationContext
註冊的監聽須要銷燬時反註冊，或者循環播放的動畫銷燬時要記得中止寫自定義view時尤爲注意。
避免在短期內大量建立對象，好比寫列表時若是有這種須要可使用單例代替或者作好判斷。

出現卡頓是咱們須要一些工具的輔助排查

常常用到LeakCanary，用於看是否有內存泄漏。通常一開始就會接入。接入方式能夠看看博客www.jianshu.com/p/70b8c87ea…
其餘一些工具的介紹例如as自帶的monnitors和MAT（memoryAnalyzer：eclipse官方工具） www.jianshu.com/p/d71b51a0e…

崩潰問題

雖然在測試階段已經會把這個過濾掉，可是實際使用時可能數據出錯等等的緣由均可能致使崩潰。這時咱們最好接入Bugly，接入方法能夠看官網，每次崩潰bugly都會記錄。可是bugly天天只會推送一次，若是咱們須要作一些預警，能夠監聽app崩潰作個通知發給釘釘機器人或者咱們本身的後臺方便咱們作熱修復。app

釘釘羣截圖以下，具體實現能夠看對應官方文檔以及博客。相對來講比較簡單沒什麼技術含量，只是提供個方案。