2. 程式人生 > >android冷啟動

android冷啟動

阿新 • • 發佈：2019-02-15

系列文:

1, 程式碼分析

因為這個App集成了Bugly, Push, Feedback等服務, 所以Application的onCreate有很多第三方平臺的初始化工作...

public class GithubApplication extends MultiDexApplication {

    @Override
    public void onCreate() {
        super.onCreate();

        // init logger.
        AppLog.init();

        // init crash helper
        CrashHelper.init(this
 
);

        // init Push
        PushPlatform.init(this);

        // init Feedback
        FeedbackPlatform.init(this);

        // init Share
        SharePlatform.init(this);

        // init Drawer image loader
        DrawerImageLoader.init(new AbstractDrawerImageLoader() {
            @Override
            public
 
 void set(ImageView imageView, Uri uri, Drawable placeholder) {
                ImageLoader.loadWithCircle(GithubApplication.this, uri, imageView);
            }
        });
    }
}

當前冷啟動效果:


code_start_before_optimize

可以看到啟動時白屏了很長時間.

2, Traceview上場

接下來我們結合我們上文的理論知識, 和介紹的Traceview工具, 來分析下Application的onCreate耗時.

在onCreate開始和結尾打上trace.

Debug.startMethodTracing("GithubApp");
...
Debug.stopMethodTracing();

執行程式, 會在sdcard上生成一個"GithubApp.trace"的檔案.

注意: 需要給程式加上寫儲存的許可權:

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

通過adb pull將其匯出到本地

adb pull /sdcard/GithubApp.trace ~/temp

廣告: adb的眾多用法, 可以參考我的另一篇文

開啟DDMS分析trace檔案


ddms_open_trace

分析trace檔案


traceview_ui
  1. 在下方的方法區點選"Real Time/Call", 按照方法每次呼叫耗時降序排.
  2. 耗時超過500ms都是值得注意的.
  3. 看左邊的方法名, 可以看到耗時大戶就是我們用的幾大平臺的初始化方法, 特別是Bugly, 還載入native的lib, 用ZipFile操作等.
  4. 點選每個方法, 可以看到其父方法(呼叫它的)和它的所有子方法(它呼叫的).
  5. 點選方法時, 上方的該方法執行時間軸會閃動, 可以看該方法的執行執行緒及相對時長.

3, 調整Application onCreate再試

既然已經知道了哪些地方耗時長, 我們不妨調整下Application的onCreate實現, 一般來說我們可以將這些初始化放在一個單獨的執行緒中處理, 為了方便今後管理, 這裡我用了一個InitializeService的IntentService來做初始化工作.

明確一點, IntentService不同於Service, 它是工作在後臺執行緒的.

InitializeService.java程式碼如下:

package com.anly.githubapp.compz.service;

import android.app.IntentService;
import android.content.Context;
import android.content.Intent;
import android.graphics.drawable.Drawable;
import android.net.Uri;
import android.widget.ImageView;

import com.anly.githubapp.common.wrapper.AppLog;
import com.anly.githubapp.common.wrapper.CrashHelper;
import com.anly.githubapp.common.wrapper.FeedbackPlatform;
import com.anly.githubapp.common.wrapper.ImageLoader;
import com.anly.githubapp.common.wrapper.PushPlatform;
import com.anly.githubapp.common.wrapper.SharePlatform;
import com.mikepenz.materialdrawer.util.AbstractDrawerImageLoader;
import com.mikepenz.materialdrawer.util.DrawerImageLoader;

/**
 * Created by mingjun on 16/8/25.
 */
public class InitializeService extends IntentService {

    private static final String ACTION_INIT_WHEN_APP_CREATE = "com.anly.githubapp.service.action.INIT";

    public InitializeService() {
        super("InitializeService");
    }

    public static void start(Context context) {
        Intent intent = new Intent(context, InitializeService.class);
        intent.setAction(ACTION_INIT_WHEN_APP_CREATE);
        context.startService(intent);
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        if (intent != null) {
            final String action = intent.getAction();
            if (ACTION_INIT_WHEN_APP_CREATE.equals(action)) {
                performInit();
            }
        }
    }

    private void performInit() {
        AppLog.d("performInit begin:" + System.currentTimeMillis());

        // init Drawer image loader
        DrawerImageLoader.init(new AbstractDrawerImageLoader() {
            @Override
            public void set(ImageView imageView, Uri uri, Drawable placeholder) {
                ImageLoader.loadWithCircle(getApplicationContext(), uri, imageView);
            }
        });

        // init crash helper
        CrashHelper.init(this.getApplicationContext());

        // init Push
        PushPlatform.init(this.getApplicationContext());

        // init Feedback
        FeedbackPlatform.init(this.getApplication());

        // init Share
        SharePlatform.init(this.getApplicationContext());

        AppLog.d("performInit end:" + System.currentTimeMillis());
    }
}

GithubApplication的onCreate改成:

public class GithubApplication extends MultiDexApplication {

    @Override
    public void onCreate() {
        super.onCreate();

        // init logger.
        AppLog.init();

        InitializeService.start(this);
    }
}

看看現在的效果:


improved-1.gif

可以看到提升了很多, 然後還有一點瑕疵, 就是起來的時候會有一個白屏, 如果手機較慢的話, 這個白屏就會持續一段時間, 不太友好.

那麼還有沒有什麼辦法優化呢?

4, 給我們的應用視窗弄一個PlaceHolder

Android最新的Material Design有這麼個建議的. 建議我們使用一個placeholder UI來展示給使用者直至App載入完畢.

怎麼做呢?

給Window加上背景

如第3節所言, 當App沒有完全起來時, 螢幕會一直顯示一塊空白的視窗(一般來說是黑屏或者白屏, 根據App主題).

前文理論基礎有說到, 這個空白的視窗展示跟主題相關, 那麼我們是不是可以從首屏的主題入手呢? 恰好有一個windowBackground的主題屬性, 我們來給Splash介面加上一個主題, 帶上我們想要展示的背景.

做一個logo_splash的背景:

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- 底層白色 -->
    <item android:drawable="@color/white" />

    <!-- 頂層Logo居中 -->
    <item>
        <bitmap
            android:gravity="center"
            android:src="@drawable/ic_github" />
    </item>
</layer-list>

弄一個主題:

<style name="SplashTheme" parent="AppTheme">
    <item name="android:windowBackground">@drawable/logo_splash</item>
</style>

將一個什麼不渲染布局的Activity作為啟動屏

寫一個什麼都不做的LogoSplashActivity.

public class LogoSplashActivity extends BaseActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // 注意, 這裡並沒有setContentView, 單純只是用來跳轉到相應的Activity.
        // 目的是減少首屏渲染

        if (AppPref.isFirstRunning(this)) {
            IntroduceActivity.launch(this);
        }
        else {
            MainActivity.launch(this);
        }
        finish();
    }
}

在AndroidManifest.xml中設定其為啟動屏, 並加上主題:

<activity
  android:name=".ui.module.main.LogoSplashActivity"
  android:screenOrientation="portrait"
  android:theme="@style/SplashTheme">
  <intent-filter>
      <action android:name="android.intent.action.MAIN"/>
      <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
</activity>

5, 最終的效果

讓我們來看下最終的效果:


improved-2.gif

相比之前, 呈現給使用者的不再是一個白屏了, 帶上了logo, 當然這個背景要顯示什麼, 我們可以根據實際情況來自定義.

這種優化, 對於有些Application內的初始化工作不能移到子執行緒做的情況, 是非常友好的. 可以避免我們的App長時間的呈現給使用者一個空白的視窗.

6, 結語

照例, 總結下.
這次關於App啟動時間的優化, 寫了兩篇. 寫這麼多, 還是想傳達下個人做技術的思想, 也算是個人的經驗回顧, 拋磚引玉.

實際場景可能遠比這個複雜，在此更多的提供一種分析思路～歡迎擴充套件

矯情了, 還是總結下本文相關的吧:

  1. Application的onCreate中不要做太多事情.
  2. 首屏Activity儘量簡化.
  3. 善用工具分析.
  4. 多閱讀官方文件, 很多地方貌似無關, 實際有關聯, 例如這次就用了Material Design文件中的解決方案.

相關推薦

Android冷啟動白屏解析，帶你一步步分析和解決問題

本文同步發表於我的微信公眾號，掃一掃文章底部的二維碼或在微信搜尋 郭霖 即可關注，每天都有文章更新。 寫在前面 記得在本月初，我發表了一篇文章叫《 Android Studio新功能解析，你真的瞭解Instant Run嗎？》，裡面詳細講解了

Android 冷啟動白屏問題

點選上面藍色字型關注“IT大飛說” 置頂公眾號（ID：ITBigFly）第一時間收到推送 今天把玩公司App發現了一個有趣的現象。啟動app白屏。之前沒太留意過；在參照大廠App解決白屏的方案後。簡單彙總一下。 前言 冷啟動：App第

Android冷啟動實現APP秒開

在閱讀這篇文章之前，首先要知道，App 啟動分為冷啟動和熱啟動。 點選一個App 圖示的時候會發現有時進入App首頁很快，有時很慢，有時中間還有個白屏。有時中間還有個黑屏。 冷啟動 冷啟動：當啟動應用時，後臺沒有該應用的程序，這時系統會重新建立一個新的

android冷啟動

系列文: 1, 程式碼分析 因為這個App集成了Bugly, Push, Feedback等服務, 所以Application的onCreate有很多第三方平臺的初始化工作... public class GithubApplication extends MultiDexApplication {

android 性能優化 -- 啟動過程 冷啟動 熱啟動

sdc 視覺 準備 and 接下來 元素 uri word androidm 一、應用的啟動方式 　　通常來說，啟動方式分為兩種：冷啟動和熱啟動。 　　1、冷啟動：當啟動應用時，後臺沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。 　　

Android應用優化之冷啟動優化

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

Android效能測試之冷啟動時間

          冷啟動是Android效能測試中的重要指標，即應用從程序未建立到完全啟動的時間，一般要求時長<1.5s，過長需要考慮優化。 獲取冷啟動時間的方法： 1.用命令列  adb shell am start

Android中APP應用冷啟動黑白屏原因 優化解決方案

冷啟動 前言 應用啟動 冷啟動流程 問題原因 解決方法 優化 前言 做過APP開發，尤其是複雜專案的同學應該會經歷過APP在桌面點選冷啟動的時候，你以為會順利開啟應用首頁，但是出現在你眼前的

Android 啟動白屏，跳轉黑屏以及冷啟動優化

一，白屏 現象：啟動app,白屏一段時間後才出現歡迎頁 解決： 1，新增style <style name="AppTheme.Launcher"> <item name="android:windowDisablePreview">true<

Android知識體系總結之Android部分之冷啟動&熱啟動篇

Android知識體系總結之Android部分之冷啟動&熱啟動篇 1.冷啟動&熱啟動 1.1 什麼是冷啟動？   當啟動應用時，後臺沒有該應用的程序，這時系統會重新建立一個新的程序分配給該應用，這個啟動方式就是冷啟動。它的特點就是冷啟動因為系統

Android應用冷啟動過程分析和優化方案你瞭解多少

你有沒有發現，點選安卓手機桌面上的App圖示時，有時候應用馬上進入主介面，有時候要經歷好幾秒甚至更久的白屏（也可能是黑屏）時間才能進入主介面呢？這其實是安卓應用常見的冷熱啟動問題。本文就和大家一起聊聊冷熱啟動方式和啟動頁的體驗優化方案。 啟動方式 安卓應用的啟動方式分為三種：冷啟動

Android 7.0應用冷啟動流程分析

最近在為自己Moto G定製Rom,順便重新讀了一遍Android 7.0的相關原始碼,特此記錄當做筆記. 在開始正文之前,首先要明白冷啟動和熱啟動.所謂冷啟動就是啟動該應用時,後臺沒有該應用的程序,此時系統會建立一個程序分配給它(AMS通過Socket和Zy

Android啟動時間優化檢視及冷啟動時間優化優化

測量Activity 的啟動時間 如何獲得app的啟動時間？ 我也在想這個問題。 當我在framework 程式碼上做這類測量的時候，我可以精確的得出我需要的東西。但是非framework 開發者如何從普通構建獲得自己需要的資訊呢？ 一 、直接看log 幸運的是，這

Android 你應該知道的的應用冷啟動過程分析和優化方案

你有沒有發現，點選安卓手機桌面上的App圖示時，有時候應用馬上進入主介面，有時候要經歷好幾秒甚至更久的白屏（也可能是黑屏）時間才能進入主介面呢？這其實是安卓應用常見的冷熱啟動問題。本文就和大家一起聊聊冷熱啟動方式和啟動頁的體驗優化方案。 啟動方式

Android 效能優化 冷啟動速度優化

前言 本篇文章對app啟動速度進行優化。先了解 Android 效能優化 基本概念應用是如何啟動的，會對此有幫助。 1. 應用的啟動模式 冷啟動 Cold start 當啟動應用時，後臺沒有該應用的程序，這時系統會重新建立一個新的程序分配給該應用，

Android面試系列冷啟動優化

什麼是冷啟動？ 冷啟動的定義 冷啟動就是在啟動應用前，系統中沒有該應用的任何程序資訊時候的啟動（第一次開啟應用，或者殺死了這個app程序後的啟動） 冷啟動/熱啟動的區別 熱啟動定義:使用者使用app返回鍵退出應用，然後馬上又重新啟動應用。 區別一：ap

Android應用冷啟動解析和優化方案

前言 在我們點選Android手機桌面APP圖示時，有時候我麼會發現，應用並不是直接進入閃屏頁或者應用主頁面，而是會有一個短暫時間的白屏才能進去。但如果我們點選Back鍵退出應用，在點選返回的時候卻沒有白屏或者白屏時間幾乎不可見。為什麼會出現這種情況呢？這就涉及到Andro

解決android應用啟動白屏問題——android 的冷啟動

在專案中啟動應用的時候總是有一段時間是白屏的然後才能啟動歡迎介面，感覺不好，為了視覺效果我找到了問題（程式設計師的潔癖） 一、 什麼叫冷啟動 通常來說，啟動方式分為兩種：冷啟動和熱啟動。

Android程式冷啟動白屏時間較長

Instant Run在我們使用AndroidStudio編譯apk的時候，使用的gradle tool版本較高的話，程式會在啟動的時候去初始化Instant Run,從而導致啟動時間較長，例如： buildscript { repositories {

android應用冷啟動過程分析與優化過程

http://yifeng.studio/2016/11/15/android-optimize-for-cold-start/?utm_source=tuicool&utm_medium=referral 你有沒有發現，點選安卓手機桌面上的App圖示時，有時候應用馬上進入主介面，有時候要經歷好幾秒甚