2. 程式人生 > >Android應用優化之流暢度

Android應用優化之流暢度

阿新 • • 發佈：2018-12-03

前言

對於現今市面上針對於使用者互動的應用，都有使用列表去展示資訊。列表對於使用者來說是十分好的瀏覽、接收資訊的一個控制元件。對於產品來說，列表流暢度的重要性就不言而喻了。而流暢度的好壞，對一個產品的基本體驗和口碑有著極大的影響。然而Android手機與iPhone手機對比，第一點往往就是流暢度的問題，對於技術來說，我們的Google親爹，不斷對這個詬病進行優化，包括GPU硬體加速、將Dalvik虛擬機器換成ART等等，我們的程式碼也不斷從ListView換成RecyclerView。當我們沾沾自喜地說我們的產品也能像飄柔那樣順滑，我們的產品經理說出一個詞“競品對比”，來了一個JSON資料結構是三層陣列巢狀，直觀來說就是巢狀三層RecyclerView，懵逼臉?當然我們編碼肯定不會這樣做。好了回到我們的流暢度問題。

流暢度

對於流暢度，我們首先會重點說到FPS問題，導致流暢度不足。FPS是Frames Per Second，Frame(畫面、幀)，p就是Per(每)，s就是Second(秒)。人類大腦與眼睛對一個畫面的連貫性感知有一個邊界值，譬如我們看電影會覺得畫面很自然連貫，其幀率通常為 24fps。

但經過國內BAT專業測試團隊研究，我們常說的FPS與流暢度的關係並不準確。此刻我們要先理解60FPS、16ms這倆名詞。我們在其他的文章裡總會看到的名詞。那它究竟是什麼意思呢？它們出於官方出的效能優化視訊Android Performance Patterns: Why 60fps? 對其解釋說：

While 60 frames per second is actually the sweet pot. Great, smooth motion without all the tricks. And most humans can’t perceive the benefits of going higher than this number.
60fps是最恰當的幀率，是使用者能感知到的最流暢的幀率，而且人眼和大腦之間的協作無法感知到超過 60fps的畫面更新。

Now, it’s worth noting that the human eye is very discerning when it comes to inconsistencies in these frame rates
但值得注意的是人眼卻能夠感受到重新整理頻率不一致帶來的卡頓現象，比如一會60fps，一會30fps，這是能夠被感受到的，即卡頓。

As an app developer, your goal is clear. Keep your app at 60 frames per second. that’s means you have got 16 milliseconds per frame to do all of your work.That is input, computing, network and rendering every frame to stay fluid for your users.
所以作為開發者，你必須要保證你的所有操作在16ms**（1000毫秒/60幀）**內完成包括輸入、計算、網路、渲染等這些操作，才能保證應用使用過程的流暢性。

基礎概念

Android應用程式顯示原理是：手機螢幕顯示的內容是通過Android系統的SurfaceFLinger類，把當前系統裡所有程序需要顯示的資訊經過測量、佈局和繪製後的Surface渲染合成一幀，然後交到螢幕進行顯示。

FPS就是1s內SurfaceFLinger提交到螢幕的幀數。

  • SurfaceFLinger：Android系統服務，負責管理Android系統的幀緩衝區，即顯示螢幕。
  • Surface：Android應用的每個視窗對應一個畫布（Canvas），即Surface，可以理解為Android應用程式的一個視窗。

Android應用程式的顯示重點有繪製、渲染。

上面所說的繪製指的是Android的繪製機制。我們要從View的建立、View的測量、View的佈局、View的繪製對整一個繪製流程有一個基本的理解，下面我們更好地探究如何流暢，為什麼卡頓。

大多數使用者感覺卡頓等效能的問題根源就是渲染效能（Render Performance）。此時要從VSync機制開始。VSync機制是Android4.1引入的是Vertical Synchronization（垂直同步）的縮寫。我們可以把它看作是一種定時中斷，其目的是為了改善android的流暢程度。

清晰理解上面我們所述的概念後，接著去理解VSync機制。下圖是VSync機制下的繪製顯示過程，從下圖中看到CPU、GPU處理時間都很快，都是少於一個VSync間隔，也就是16ms，都能在16ms的VSync內display顯示對應的內容。

這裡寫圖片描述

上圖是一個相當理想狀態下的情況，但是當我們要完成一些酷炫、複雜的介面時，CPU、GPU處理時間會出現較慢的情況。就如下圖所示的情況。

這裡寫圖片描述

在上圖我們看到Display有兩個A、B，這裡涉及到另外一個概念，在我們在繪製UI的時候，會採用一種稱為“雙緩衝”的技術。雙緩衝意思是使用兩個緩衝區（SharedBufferStack中），其中一個稱為Front Buffer，另外一個稱為Back Buffer。UI總是先在Back Buffer中繪製，然後再和Front Buffer交換，渲染到顯示裝置中。理想情況下，這樣一個重新整理會在16ms內完成（60FPS），上圖就是描述的這樣一個重新整理過程（Display處理前Front Buffer，CPU、GPU處理Back Buffer。

從上圖我們看到CPU、GPU的處理情況，已經大於一個VSync的間隔（16ms）,我們看到在Display本應顯示B幀，但卻因為GPU還在處理B幀，導致A幀被重複顯示，這就會讓視覺產生不協調，達不到60FPS,於是出現了丟幀（Skipped Frame，SF）現象。

另外在上圖第二個16ms時間段內，CPU無所事事，因為A Buffer被Display在使用。B Buffer被GPU在使用。注意，一旦過了VSYNC時間點，CPU就不能被觸發以處理繪製工作了。

此時就有一種想法，如果有第三個Buffer存在，那CPU此時也可以利用起來了。那在Android4.1引入了Triple Buffer,所以當雙Buffer不夠用時Triple Buffer的丟幀情況如下圖。

這裡寫圖片描述

所以從上圖可以看到，在第二個VSync,CPU是用了C Buffer繪圖。雖然還是會多顯示A幀一次，但後續顯示就比較順暢了。

可能有同學對上面的理解有點吃力，我們用通俗點的例子去描述一下。Vsync機制就像一臺轉速固定的發動機（60轉/s），每一轉都是處理一些UI的操作，但是不是每一轉都有事情幹，例如我們掛空擋的時候。而有時候因為一些阻力的原因，導致某一圈工作量過大，超過了16ms，那麼這發動機這秒內就不是60轉了，我們將這個轉速稱為流暢度。

獲取流暢度的值

上面描述到對於VSync機制，我們是理解為一種定時中斷，這個概念我們可以試著與Loop產生一種聯絡。在VSync機制中1s內Loop執行的次數。在這樣的機制下，我們在每一次的Loop執行前，我們記錄一下，就能獲取的流暢度的相對情況。

而Android中有一個叫畫圖的打雜工————Choreographer物件。Google的官方API描述是，它用於協調animations、input以及drawing的時序，並且每個Looper公用一個Choreographer物件。Choreographer中文翻譯過來是”舞蹈指揮”，字面上的意思就是優雅地指揮以上三個UI操作一起跳一支舞。

Choreographer的構造方法:

private Choreographer(Looper looper) {    
  mLooper = looper;    
  mHandler = new FrameHandler(looper);    
  mDisplayEventReceiver = USE_VSYNC ? new FrameDisplayEventReceiver(looper) : null;    
  mLastFrameTimeNanos = Long.MIN_VALUE;    
  mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());    
  mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];   
  for (int i = 0; i <= CALLBACK_LAST; i++) {        
   mCallbackQueues[i] = new CallbackQueue();    
  }
}

通過深入分析UI 上層事件處理核心機制 Choreographer和Android Choreographer 原始碼分析等文章參考理解，從上面Choreographer的構造方法我們理解到：

  1. Choreographer根據一個Looper來生成，Looper和執行緒是一對一的關係，因此對於每一條執行緒都有對應的一個Choreographer。
  2. 初始化FrameHandler。接收處理訊息。
  3. 初始化FrameDisplayEventReceiver。FrameDisplayEventReceiver用來接收垂直同步脈衝，就是VSync訊號，VSync訊號是一個時間脈衝，一般為60HZ，用來控制系統同步操作。
  4. 初始化mLastFrameTimeNanos(標記上一個frame的渲染時間)以及mFrameIntervalNanos(幀率,fps，一般手機上為1s/60)。
  5. 初始化CallbackQueue，callback佇列，將在下一幀開始渲染時回撥。

然而Choreographer的主要工作在doFrame中，我們針對來看doFrame函式：

void doFrame(long frameTimeNanos, int frame) {    
  final long startNanos;    
  synchronized (mLock) {        
    if (!mFrameScheduled) { //判斷是否有callback需要執行，mFrameScheduled會在postCallBack的時候置為true,一次frame執行時置為false       
      return; // no work to do        
    }
    \\\\列印跳frame時間        
    if (DEBUG_JANK && mDebugPrintNextFrameTimeDelta) {            
      mDebugPrintNextFrameTimeDelta = false;            
      Log.d(TAG, "Frame time delta: "                    
              + ((frameTimeNanos - mLastFrameTimeNanos) *  0.000001f) + " ms");        
    }
    //設定當前frame的Vsync訊號到來時間        
    long intendedFrameTimeNanos = frameTimeNanos;        
    startNanos = System.nanoTime();//實際開始執行當前frame的時間
    //時間差        
    final long jitterNanos = startNanos - frameTimeNanos;        
    if (jitterNanos >= mFrameIntervalNanos) {
      //時間差大於一個時鐘週期，認為跳frame            
      final long skippedFrames = jitterNanos / mFrameIntervalNanos;
      //跳frame數大於預設值，列印警告資訊，預設值為30            
      if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {                
         Log.i(TAG, "Skipped " + skippedFrames + " frames!  "                        
                    + "The application may be doing too much work on its main thread.");            
      }
      //計算實際開始當前frame與時鐘訊號的偏差值            
      final long lastFrameOffset = jitterNanos % mFrameIntervalNanos; 
      //列印偏差及跳幀資訊           
      if (DEBUG_JANK) {                
        Log.d(TAG, "Missed vsync by " + (jitterNanos * 0.000001f) + " ms "                        
                  + "which is more than the frame interval of "                        
                  + (mFrameIntervalNanos * 0.000001f) + " ms!  "                        
                  + "Skipping " + skippedFrames + " frames and setting frame "                        
                  + "time to " + (lastFrameOffset * 0.000001f) + " ms in the past.");            
       }
       //修正偏差值，忽略偏差，為了後續更好地同步工作            
       frameTimeNanos = startNanos - lastFrameOffset;        
    }
    ···
}

我截取了其中一段關於繪製和丟幀處理和判斷，後面的是回撥CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL；對我們的討論的目的過於深奧就不全部截取了。

我們利用Choreographer中的一個回撥介面，FrameCallback。

    public interface FrameCallback {
        /**
         * Called when a new display frame is being rendered.
         * ···
         */
        public void doFrame(long frameTimeNanos);
    }

doFrame()的註釋翻譯意思是：當新的一幀被繪製的時候被呼叫。因此我們利用這個特性，可以統計兩幀繪製的時間間隔。

主要流程如下：

1.實現Choreographer.FrameCallback介面；
2.在doFrame中統計兩幀繪製的時間;
3.啟動監測和處理資料;

@RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
public class SMFrameCallback implements Choreographer.FrameCallback {
    private String TAG = "#SMFrameCallback";
    public static final float deviceRefreshRateMs = 16.6f;
    public static long lastFrameTimeNanos = 0;//納秒為單位
    public static long currentFrameTimeNanos = 0;
    public static SMFrameCallback sInstance;

    public void start() {
        Choreographer.getInstance().postFrameCallback(SMFrameCallback.getInstance());
    }

    public static SMFrameCallback getInstance() {
        if (sInstance == null) {
            sInstance = new SMFrameCallback();
        }
        return sInstance;
    }

    @Override
    public void doFrame(long frameTimeNanos) {
        if (lastFrameTimeNanos == 0) {
            lastFrameTimeNanos = frameTimeNanos;
            Choreographer.getInstance().postFrameCallback(this);
            return;
        }
        currentFrameTimeNanos = frameTimeNanos;
        // 計算兩次doFrame的時間間隔
        long value = (currentFrameTimeNanos - lastFrameTimeNanos) / 1000000;

        int skipFrameCount = skipFrameCount(lastFrameTimeNanos, currentFrameTimeNanos, deviceRefreshRateMs);

        Log.e(TAG, "兩次繪製時間間隔value=" + value + "  frameTimeNanos=" + frameTimeNanos + "  currentFrameTimeNanos=" + currentFrameTimeNanos + "  skipFrameCount=" + skipFrameCount + "");

        lastFrameTimeNanos = currentFrameTimeNanos;
        Choreographer.getInstance().postFrameCallback(this);
    }

    /**
     * 計算跳過多少幀
     */
    private int skipFrameCount(long start, long end, float devRefreshRate) {
        int count = 0;
        long diffNs = end - start;

        long diffMs = TimeUnit.MILLISECONDS.convert(diffNs, TimeUnit.MILLISECONDS);
        long dev = Math.round(devRefreshRate);
        if (diffMs > dev) {
            long skipCount = diffMs / dev;
            count = (int) skipCount;
        }
        return count;
    }
}

通過上述的工具類，我們在需要檢測的Activity中呼叫啟動程式碼即可。

 SMFrameCallback.getInstance().start();

一般情況下，我們會寫在我們的BaseActivity或者Activitylifecyclecallbacks中去呼叫。

自定義MyActivityLifeCycle實現Application.ActivityLifecycleCallbacks。

public class MyActivityLifeCycle implements Application.ActivityLifecycleCallbacks {
    private Handler mHandler = new Handler(Looper.getMainLooper());
    private boolean mPaused = true;
    private Runnable mCheckForegroundRunnable;
    private boolean mForeground = false;
    private static MyActivityLifeCycle sInstance;
    //當前Activity的弱引用
    private WeakReference<Activity> mActivityReference;

    protected final String TAG = "#MyActivityLifeCycle";

    public static final int ACTIVITY_ON_RESUME = 0;
    public static final int ACTIVITY_ON_PAUSE = 1;

    private MyActivityLifeCycle() {
    }

    public static synchronized MyActivityLifeCycle getInstance() {
        if (sInstance == null) {
            sInstance = new MyActivityLifeCycle();
        }
        return sInstance;
    }

    public Activity getCurrentActivity() {
        if (mActivityReference != null) {
            return mActivityReference.get();
        }
        return null;
    }

    public boolean isForeground() {
        return mForeground;
    }

    @Override
    public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        mActivityReference = new WeakReference<>(activity);
    }

    @Override
    public void onActivityStarted(Activity activity) {

    }

    @Override
    public void onActivityResumed(Activity activity) {
        String activityName = activity.getClass().getName();
        notifyActivityChanged(activityName, ACTIVITY_ON_RESUME);
        mPaused = false;
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.JELLY_BEAN) {
            FrameSkipMonitor.getInstance().setActivityName(activityName);
            FrameSkipMonitor.getInstance().OnActivityResume();
            if (!mForeground) {
                FrameSkipMonitor.getInstance().start();
            }
        }
        mForeground = true;
        if (mCheckForegroundRunnable != null) {
            mHandler.removeCallbacks(mCheckForegroundRunnable);
        }
        mActivityReference = new WeakReference<Activity>(activity);
    }

    @Override
    public void onActivityPaused(Activity activity) {
        notifyActivityChanged(activity.getClass().getName(), ACTIVITY_ON_PAUSE);
        mPaused = true;
        if (mCheckForegroundRunnable != null) {
            mHandler.removeCallbacks(mCheckForegroundRunnable);
        }
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.JELLY_BEAN)
            FrameSkipMonitor.getInstance().OnActivityPause();

        mHandler.postDelayed(mCheckForegroundRunnable = new Runnable() {
            @Override
            public void run() {
                if (mPaused && mForeground) {
                    if (Build.VERSION.SDK_INT > Build.VERSION_CODES.JELLY_BEAN) {
                        FrameSkipMonitor.getInstance().report();
                    }
                    mForeground = false;
                }
            }
        }, 1000);
    }
}

然後在自定義的Application中呼叫。

public class MyApplication extends Application {

    ···

    @Override
    public void onCreate() {
        super.onCreate();
        registerActivityLifecycleCallbacks(MyActivityLifeCycle.getInstance());
    }
    ···
}

除了上述的Choreographer幀率檢測外，還有loop()列印日誌等方法來對幀率進行統計監測。這裡就不一一舉例了。

總結：

根據瞭解Google文件，我們理解到Android4.1引入了VSync機制，通過其Loop來了解當前App最高繪製能力。

  • 固定每隔16.6ms執行一次；
  • 如果沒有事件的時候，同樣會執行一個Loop；
  • 這個Loop在1s之內運行了多少次，可以表示為當前App繪製最高能力，即Android App卡頓程度；
  • 如果一次Loop執行時間超過16.6ms,即出現了丟幀情況。

所以通過VSync機制來描述流暢度是一個連續的過程，而在APP靜止某個介面時，流暢度很高，但FPS很低，流暢度更加客觀地描述APP的卡頓情況。

通過一個漫長的理論分析，我們即將在下一篇對引起卡頓原因的程式碼實操。我們先預先認知一下以下幾點引起卡頓的原因：

  1. 佈局Layout過於複雜，無法在16ms內完成渲染；
  2. View過度繪製，導致某些畫素在同一幀時間內被繪製多次，從而使CPU或GPU負載過重；
  3. View頻繁的觸發measure、layout，導致measure、layout累計耗時過多及整個View頻繁的重新渲染；
  4. 人為在UI執行緒中做輕微耗時操作，導致UI執行緒卡頓；
  5. 同一時間動畫執行的次數過多，導致CPU或GPU負載過重；
  6. 記憶體頻繁觸發GC過多（同一幀中頻繁建立記憶體），導致暫時阻塞渲染操作；
  7. 冗餘資源及邏輯等導致載入和執行緩慢；
  8. 工作執行緒優先順序未設定為Process.THREAD_PRIORITY_BACKGROUND導致後臺執行緒搶佔UI執行緒cpu時間片，阻塞渲染操作；
  9. 引起記憶體抖動、記憶體洩漏

相關推薦

Android應用優化之流暢度

前言 對於現今市面上針對於使用者互動的應用，都有使用列表去展示資訊。列表對於使用者來說是十分好的瀏覽、接收資訊的一個控制元件。對於產品來說，列表流暢度的重要性就不言而喻了。而流暢度的好壞，對一個產品的基本體驗和口碑有著極大的影響。然而Android手機與iPhone手機對比，第一點往

Android應用優化之流暢度優化實操

上一篇流暢度概念向大家詳細地描述了VSync機制和Choreographer編舞者的用法。可能所講解的內容偏向理論概念，因此這篇是流暢度優化實操，整篇主要分三層，UI層、程式碼邏輯層、IO層來講述各個優化點，其中還會穿插多個輔助檢測外掛。可謂乾貨滿滿，希望對大家

Android應用優化之冷啟動優化

前言 事件發生在發包上線的前兩天，在某某雲進行移動測試時，提示冷啟動速度低於平均值的問題，之前自己也曾嘗試過優化，但是發現效果並不是很明顯，作為一個有追求的開發者，趁著有點空閒時間，要好好研究一下冷啟動優化問題。 App的啟動流程 我們可以瞭解一下官方文件《App startup time》對App啟動

Android效能優化——介面流暢度優化

Android效能優化——介面流暢度優化   序言 首先流暢度不僅僅是受到程式碼的影響。也會跟機器的硬體配置有關係。所以第一點需要明確的是，流暢度最低保證在哪個硬體配置之上。這樣有了一個基點之後，才能比較好明確優化目標。不然你拿一個兩三年前的機子來做優化。那就真的是吃力不討好的

Android應用優化之程式碼檢測優化

前言 最近換了新的公司，面對新的程式碼大家都有不同的熟悉過程和方法。在我的角度來說，利用程式碼檢測工具，可以更直接地去熟悉程式碼邏輯和業務邏輯，表現得自己去程式碼質量很有追求，最重要當然是在公司的任務管理工時上面顯得自己積極向上啦。不過在修改程式碼之前，你要根據專案的分工、明確在公司

Android應用優化之記憶體概念

導語 現在的Android智慧手機發展資訊萬變，從一開始的HTC到小米價格戰到現在高階市場份額戰，在軟硬體都發生了翻天覆地的變化。在硬體上記憶體從一開始的一兩百M到現在4G。從軟體上我們從一開始為了實現需求而寫程式碼到現在為了程式碼更健壯、更漂亮而進行不斷優化程式碼。這些都是Andr

Android App介面和流暢度優化

Android App介面和流暢度優化   所謂介面和流暢度優化，就是儘可能多地消除使用者可直接感知的、影響使用者操作體驗的bug 1、人為在UI執行緒中做輕微耗時操作，導致UI執行緒卡頓 人為避免一切耗時操作 開啟 StrictMode（嚴苛模式） 在Activi

Android應用開發之PNG、IconFont、SVG圖示資源優化詳解

1 背景 最近因為一些個人私事導致好久沒寫部落格了，多事之年總算要過去了，突然沒了動力，所以趕緊先拿個最近專案中重構的一個小知識點充下數，老題重談。 在我們App開發中大家可能都會有過如下痛疾（程式設計師和設計妹妹注意嘍）： 好多小的圖示好煩人，又佔體積

Android 效能優化之應用啟動

寫在前面 最近工作轉到Android 效能優化方向，剛轉過來，相關經驗缺乏，紀錄一個目前讓人惱火的問題。非常遺憾，本文到目前為止還未能提供解決問題的優化方案，也沒有明確定位到導致效能問題的瓶頸所在。就像解數學題一樣，花費了大把時間，然並卵。之所以寫它

Android應用開發之所有動畫使用詳解

factory 技術分享 resource bsp phi 顯示 程序 恢復 分享 題外話：有段時間沒有更新博客了，這篇文章也是之前寫了一半一直放在草稿箱，今天抽空把剩余的補上的。消失的這段時間真的好忙，節奏一下子有些適應不過來，早晨七點四十就得醒來，晚上九點四十才準備下班

Android App優化之ANR詳解

nic orm rim manage dal private rom syn UNC 引言 背景:Android App優化, 要怎麽做? Android App優化之性能分析工具 Android App優化之提升你的App啟動速度之理論基礎 Android App優化

Android——效能優化之SparseArray

相信大家都用過HashMap用來存放鍵值對，最近在專案中使用HashMap的時候發現，有時候 IDE 會提示我這裡的HashMap可以用SparseArray或者SparseIntArray等等來代替。 SparseArray(稀疏陣列).它是Android內部特有的api,標準的jdk是沒有這

Android效能優化之較精確的獲取影象顯示到螢幕上的時間

轉載自：http://blog.desmondyao.com/android-show-time/ 這兩天我的包工頭歪龍木·靈魂架構師·王半仙·Yrom給我派了一個活：統計App冷啟動時間。這個任務看上去不難，但是要求統計出來的時間要準，要特別準。 意思就是，我必須要按Activity繪製到

Android開發優化之的強引用、軟引用、弱引用的使用

本文轉載至：http://www.jianshu.com/p/8488079a939b 引言 早在JDK1.2，Java就把物件的引用分為四種級別，從而使程式能更加靈活的控制物件的生命週期。這四種級別由高到低依次為：強引用、軟引用、弱引用和虛引用。 但是平時我們的程式碼中似乎很

android電量優化之Battery Historian工具使用

前幾天寫了關於androidAPP效能優化總結的文章，還沒有看的話可以看一下，這文章提到了電量優化，android耗電分析所用到的工具battery-historian,這裡做一個總結． 在 Android5.0 以前，在應用中測試電量消耗比較麻煩，也不準確，5.0 之後專門引入了一個獲取裝置上

Android學習筆記之百度地圖（駕車路線搜尋及RouteOverlay步行路線搜尋及RouteOverlay）

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

Android佈局優化之merge標籤詳解

我們都知道View的繪製流程需要經歷measure、layout、draw這個三個過程，如果佈局巢狀層次比較深的話，每一步都需要進行遍歷所有子View進行對應的measure、layout、draw過程，由此就會降低繪製效率，巢狀越多，耗時就越多；其實不光光只會影響view的繪製效率，同

Android效能優化之圖片壓縮優化

1 分類Android圖片壓縮結合多種壓縮方式，常用的有尺寸壓縮、質量壓縮、取樣率壓縮以及通過JNI呼叫libjpeg庫來進行壓縮。 參考此方法：Android-BitherCompress 備註：對於資源圖片直接使用：tiny壓縮 2 質量壓縮（1）原理：保持畫素的前提下改變圖片的位深及透明度，（即：通

Android效能優化之apk瘦身技巧

隨著專案迭代,新功能的增加。回導致apk越大。那麼在下載安裝過程中。使用者耗費的流量越多。 安裝等待的時間也會越長。這就意味著下載轉化率會越低。那麼如何apk瘦身呢？ 理解APK結構 在討論怎麼減小Apk體積之前，理解一個應用的APK結構是非常有幫助的。一個ap

Android效能優化之佈局優化

          佈局優化可以通過減少佈局層級來提高，儘量減少使用效能低的佈局，LineaLayout的效率最高，在可以使用LinearLayout或者RelativeLayout時，選擇LinearLayout。因為RelativeLayout測量較為複雜，需要測量水平和