Android的生命周期是什么

這篇“Android的生命周期是什么”文章的知識(shí)點(diǎn)大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來(lái)看看這篇“Android的生命周期是什么”文章吧。

0、Android整體架構(gòu)

談?wù)勀銓?duì)android系統(tǒng)(體系)架構(gòu)的理解

Linux操作系統(tǒng)為核心，從下往上，依賴關(guān)系。

1. 應(yīng)用程序?qū)樱?/strong>包括系統(tǒng)應(yīng)用以及第三方應(yīng)用。

2. 應(yīng)用程序框架：提供應(yīng)用開(kāi)發(fā)所必須的一些API框架，是軟件復(fù)用的重要手段

3. 庫(kù)：android運(yùn)行時(shí)(核心包(相當(dāng)于JDK提供的包)，虛擬機(jī)(優(yōu)化過(guò)的JVM));C/C++的一些庫(kù)

4. Linux核心：提供了電源管理、進(jìn)程調(diào)度、內(nèi)存管理、網(wǎng)絡(luò)協(xié)議棧、驅(qū)動(dòng)模型等核心系統(tǒng)服務(wù)

android中的四大組件以及應(yīng)用場(chǎng)景

1. Activity：在Android應(yīng)用中負(fù)責(zé)與用戶交互的組件。

2. Service：常用于為其他組件提供后臺(tái)服務(wù)或者監(jiān)控其他組件的運(yùn)行狀態(tài)。經(jīng)常用來(lái)執(zhí)行一些耗時(shí)操作。

3. BroadcastReceiver：用于監(jiān)聽(tīng)?wèi)?yīng)用程序中的其他組件。

4. ContentProvider：Android應(yīng)用程序之間實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)交換。

1、Activity的生命周期

生命周期：對(duì)象什么時(shí)候生，什么時(shí)候死，怎么寫代碼，代碼往那里寫。

注意：

1. 當(dāng)打開(kāi)新的Activity，采用透明主題的時(shí)候，當(dāng)前Activity不會(huì)回調(diào)onStop

2. onCreate和onDestroy配對(duì)，onStart和onStop配對(duì)(是否可見(jiàn))，onResume和onPause配對(duì)(是否在前臺(tái)，可以與用戶交互)

3. 打開(kāi)新的Activity的時(shí)候，相關(guān)的Log為：

Main1Activity: onPause Main2Activity: onCreate Main2Activity: onStart Main2Activity: onResume MainA1ctivity: onStop

異常狀態(tài)下的生命周期：

資源相關(guān)的系統(tǒng)配置發(fā)生改變或者資源不足：例如屏幕旋轉(zhuǎn)，當(dāng)前Activity會(huì)銷毀，并且在onStop之前回調(diào)onSaveInstanceState保存數(shù)據(jù)，在重新創(chuàng)建Activity的時(shí)候在onStart之后回調(diào)onRestoreInstanceState。其中Bundle數(shù)據(jù)會(huì)傳到onCreate(不一定有數(shù)據(jù))和onRestoreInstanceState(一定有數(shù)據(jù))。

防止屏幕旋轉(zhuǎn)的時(shí)候重建，在清單文件中添加配置：

android:configChanges="orientation"

2、Fragment的生命周期

正常啟動(dòng)

Activity: onCreate Fragment: onAttach Fragment: onCreate Fragment: onCreateView Fragment: onActivityCreated Activity: onStart Activity: onResume

正常退出

Activity: onPause   Activity: onStop   Fragment: onDestroyView   Fragment: onDestroy   Fragment: onDetach   Activity: onDestroy

3、Activity的啟動(dòng)模式

1. standard：每次激活A(yù)ctivity時(shí)(startActivity)，都創(chuàng)建Activity實(shí)例，并放入任務(wù)棧;

2. singleTop：如果某個(gè)Activity自己激活自己，即任務(wù)棧棧頂就是該Activity，則不需要?jiǎng)?chuàng)建，其余情況都要?jiǎng)?chuàng)建Activity實(shí)例;

3. singleTask：如果要激活的那個(gè)Activity在任務(wù)棧中存在該實(shí)例，則不需要?jiǎng)?chuàng)建，只需要把此Activity放入棧頂，即把該Activity以上的Activity實(shí)例都pop，并調(diào)用其onNewIntent;

4. singleInstance：應(yīng)用1的任務(wù)棧中創(chuàng)建了MainActivity實(shí)例，如果應(yīng)用2也要激活MainActivity，則不需要?jiǎng)?chuàng)建，兩應(yīng)用共享該Activity實(shí)例。

4、Activity與Fragment之間的傳值

通過(guò)findFragmentByTag或者getActivity獲得對(duì)方的引用(強(qiáng)轉(zhuǎn))之后，再相互調(diào)用對(duì)方的public方法，但是這樣做一是引入了“強(qiáng)轉(zhuǎn)”的丑陋代碼，另外兩個(gè)類之間各自持有對(duì)方的強(qiáng)引用，耦合較大，容易造成內(nèi)存泄漏。

通過(guò)Bundle的方法進(jìn)行傳值，例如以下代碼：

//Activity中對(duì)fragment設(shè)置一些參數(shù) fragment.setArguments(bundle);  //fragment中通過(guò)getArguments獲得Activity中的方法 Bundle arguments = getArguments()

利用eventbus進(jìn)行通信，這種方法實(shí)時(shí)性高，而且Activity與Fragment之間可以完全解耦。

//Activity中的代碼 EventBus.getDefault().post("消息");  //Fragment中的代碼 EventBus.getDefault().register(this); @Subscribe public void test(String text) {     tv_test.setText(text); }

5、Service

Service分為兩種：

1. 本地服務(wù)，屬于同一個(gè)應(yīng)用程序，通過(guò)startService來(lái)啟動(dòng)或者通過(guò)bindService來(lái)綁定并且獲取代理對(duì)象。如果只是想開(kāi)個(gè)服務(wù)在后臺(tái)運(yùn)行的話，直接startService即可，如果需要相互之間進(jìn)行傳值或者操作的話，就應(yīng)該通過(guò)bindService。

2. 遠(yuǎn)程服務(wù)(不同應(yīng)用程序之間)，通過(guò)bindService來(lái)綁定并且獲取代理對(duì)象。

對(duì)應(yīng)的生命周期如下：

context.startService() ->onCreate()- >onStartCommand()->Service running--調(diào)用context.stopService() ->onDestroy()        context.bindService()->onCreate()->onBind()->Service running--調(diào)用>onUnbind() -> onDestroy()

注意

1. Service默認(rèn)是運(yùn)行在main線程的，因此Service中如果需要執(zhí)行耗時(shí)操作(大文件的操作，數(shù)據(jù)庫(kù)的拷貝，網(wǎng)絡(luò)請(qǐng)求，文件下載等)的話應(yīng)該在子線程中完成。

2. !特殊情況是：Service在清單文件中指定了在其他進(jìn)程中運(yùn)行。

6、Android中的消息傳遞機(jī)制

為什么要使用Handler?

因?yàn)槠聊坏乃⑿骂l率是60Hz，大概16毫秒會(huì)刷新一次，所以為了保證UI的流暢性，耗時(shí)操作需要在子線程中處理，子線程不能直接對(duì)UI進(jìn)行更新操作。因此需要Handler在子線程發(fā)消息給主線程來(lái)更新UI。

這里再深入一點(diǎn)，Android中的UI控件不是線程安全的，因此在多線程并發(fā)訪問(wèn)UI的時(shí)候會(huì)導(dǎo)致UI控件處于不可預(yù)期的狀態(tài)。Google不通過(guò)鎖的機(jī)制來(lái)處理這個(gè)問(wèn)題是因?yàn)椋?/p>

• 引入鎖會(huì)導(dǎo)致UI的操作變得復(fù)雜

• 引入鎖會(huì)導(dǎo)致UI的運(yùn)行效率降低

因此，Google的工程師***是通過(guò)單線程的模型來(lái)操作UI，開(kāi)發(fā)者只需要通過(guò)Handler在不同線程之間切花就可以了。

概述一下Android中的消息機(jī)制?

Android中的消息機(jī)制主要是指Handler的運(yùn)行機(jī)制。Handler是進(jìn)行線程切換的關(guān)鍵，在主線程和子線程之間切換只是一種比較特殊的使用情景而已。其中消息傳遞機(jī)制需要了解的東西有Message、Handler、Looper、Looper里面的MessageQueue對(duì)象。

如上圖所示，我們可以把整個(gè)消息機(jī)制看作是一條流水線。其中：

1. MessageQueue是傳送帶，負(fù)責(zé)Message隊(duì)列的傳送與管理

2. Looper是流水線的發(fā)動(dòng)機(jī)，不斷地把消息從消息隊(duì)列里面取出來(lái)，交給Handler來(lái)處理

3. Message是每一件產(chǎn)品

4. Handler就是工人。但是這么比喻不太恰當(dāng)，因?yàn)榘l(fā)送以及最終處理Message的都是Handler

為什么在子線程中創(chuàng)建Handler會(huì)拋異常?

Handler的工作是依賴于Looper的，而Looper(與消息隊(duì)列)又是屬于某一個(gè)線程(ThreadLocal是線程內(nèi)部的數(shù)據(jù)存儲(chǔ)類，通過(guò)它可以在指定線程中存儲(chǔ)數(shù)據(jù)，其他線程則無(wú)法獲取到)，其他線程不能訪問(wèn)。因此Handler就是間接跟線程是綁定在一起了。因此要使用Handler必須要保證Handler所創(chuàng)建的線程中有Looper對(duì)象并且啟動(dòng)循環(huán)。因?yàn)樽泳€程中默認(rèn)是沒(méi)有Looper的，所以會(huì)報(bào)錯(cuò)。

正確的使用方法是：

handler = null;   new Thread(new Runnable() {       private Looper mLooper;       @Override       public void run() {           //必須調(diào)用Looper的prepare方法為當(dāng)前線程創(chuàng)建一個(gè)Looper對(duì)象，然后啟動(dòng)循環(huán)           //prepare方法中實(shí)質(zhì)是給ThreadLocal對(duì)象創(chuàng)建了一個(gè)Looper對(duì)象           //如果當(dāng)前線程已經(jīng)創(chuàng)建過(guò)Looper對(duì)象了，那么會(huì)報(bào)錯(cuò)           Looper.prepare();           handler = new Handler();           //獲取Looper對(duì)象           mLooper = Looper.myLooper();           //啟動(dòng)消息循環(huán)           Looper.loop();           //在適當(dāng)?shù)臅r(shí)候退出Looper的消息循環(huán)，防止內(nèi)存泄漏           mLooper.quit();       }   }).start();

主線程中默認(rèn)是創(chuàng)建了Looper并且啟動(dòng)了消息的循環(huán)的，因此不會(huì)報(bào)錯(cuò)：

• 應(yīng)用程序的入口是ActivityThread的main方法，在這個(gè)方法里面會(huì)創(chuàng)建Looper，并且執(zhí)行Looper的loop方法來(lái)啟動(dòng)消息的循環(huán)，使得應(yīng)用程序一直運(yùn)行。

• 子線程中可以通過(guò)Handler發(fā)送消息給主線程嗎?

• 可以。有時(shí)候出于業(yè)務(wù)需要，主線程可以向子線程發(fā)送消息。子線程的Handler必須按照上述方法創(chuàng)建，并且關(guān)聯(lián)Looper。

7、事件傳遞機(jī)制以及自定義View相關(guān)

Android的視圖樹(shù)

Android中View的機(jī)制主要是Activity的顯示，每個(gè)Activity都有一個(gè)Window(具體在手機(jī)中的實(shí)現(xiàn)類是PhoneWindow)，Window以下有DecorView，DecorView下面有TitleVie以及ContentView，而ContentView就是我們?cè)贏ctivity中通過(guò)setContentView指定的。

事件傳分發(fā)機(jī)制

ViewGroup有以下三個(gè)與事件分發(fā)的方法，而View只有dispatchTouchEvent和onTouchEvent。

@Override    public boolean dispatchTouchEvent(MotionEvent ev) {        return super.dispatchTouchEvent(ev);    }    @Override    public boolean onInterceptTouchEvent(MotionEvent ev) {        return super.onInterceptTouchEvent(ev);    }    @Override    public boolean onTouchEvent(MotionEvent event) {        return super.onTouchEvent(event);    }

事件總是從上往下進(jìn)行分發(fā)，即先到達(dá)Activity，再到達(dá)ViewGroup，再到達(dá)子View，如果沒(méi)有任何視圖消耗事件的話，事件會(huì)順著路徑往回傳遞。其中：

1. dispatchTouchEvent是事件的分發(fā)方法，如果事件能夠到達(dá)該視圖的話，就首先一定會(huì)調(diào)用，一般我們不會(huì)去修改這個(gè)方法。

2. onInterceptTouchEvent是事件分發(fā)的核心方法，表示ViewGroup是否攔截事件，如果返回true表示攔截，在這之后ViewGroup的onTouchEvent會(huì)被調(diào)用，事件就不會(huì)往下傳遞。

3. onTouchEvent是***級(jí)的，在事件分發(fā)中***被調(diào)用。

4. 子View可以通過(guò)requestDisallowInterceptTouchEvent方法去請(qǐng)求父元素不要攔截。

注意

1. 事件從Activity.dispatchTouchEvent()開(kāi)始傳遞，只要沒(méi)有被停止或攔截，從最上層的View(ViewGroup)開(kāi)始一直往下(子View)傳遞。子View  可以通過(guò)onTouchEvent()對(duì)事件進(jìn)行處理。

2. 事件由父View(ViewGroup)傳遞給子View，ViewGroup  可以通過(guò)onInterceptTouchEvent()對(duì)事件做攔截，停止其往下傳遞。

3. 如果事件從上往下傳遞過(guò)程中一直沒(méi)有被停止，且***層子View  沒(méi)有消費(fèi)事件，事件會(huì)反向往上傳遞，這時(shí)父View(ViewGroup)可以進(jìn)行消費(fèi)，如果還是沒(méi)有被消費(fèi)的話，***會(huì)到Activity  的onTouchEvent()函數(shù)。

4. 如果View 沒(méi)有對(duì)ACTION_DOWN 進(jìn)行消費(fèi)，之后的其他事件不會(huì)傳遞過(guò)來(lái)。

5. OnTouchListener 優(yōu)先于onTouchEvent()對(duì)事件進(jìn)行消費(fèi)。

自定義View的分類

1. 對(duì)現(xiàn)有的View的子類進(jìn)行擴(kuò)展，例如復(fù)寫onDraw方法、擴(kuò)展新功能等。

2. 自定義組合控件，把常用一些控件組合起來(lái)以方便使用。

3. 直接繼承View實(shí)現(xiàn)View的完全定制，需要完成View的測(cè)量以及繪制。

4. 自定義ViewGroup，需要復(fù)寫onLayout完成子View位置的確定等工作。

View的測(cè)量-onMeasure

View的測(cè)量最終是在onMeasure方法中通過(guò)setMeasuredDimension把代表寬高兩個(gè)MeasureSpec設(shè)置給View，因此需要掌握MeasureSpec。MeasureSpec包括大小信息以及模式信息。

MeasureSpec的三種模式：

1. EXACTLY模式：精確模式，對(duì)應(yīng)于用戶指定為match_parent或者具體大小的時(shí)候(實(shí)際上指定為match_parent實(shí)質(zhì)上是指定大小為父容器的大小)

2. AT_MOST模式：對(duì)應(yīng)于用戶指定為wrap_content，此時(shí)控件尺寸只要不超過(guò)父控件允許的***尺寸即可。

3. UNSPECIFIED模式：不指定大小的測(cè)量模式，這種模式比較少用

下面給出模板代碼：

public class MeasureUtils {        /**         * 用于View的測(cè)量         *         * @param measureSpec         * @param defaultSize         * @return         */        public static int measureView(int measureSpec, int defaultSize) {                int measureSize;                //獲取用戶指定的大小以及模式            int mode = View.MeasureSpec.getMode(measureSpec);            int size = View.MeasureSpec.getSize(measureSpec);                //根據(jù)模式去返回大小            if (mode == View.MeasureSpec.EXACTLY) {                //精確模式（指定大小以及match_parent）直接返回指定的大小                measureSize = size;            } else {                //UNSPECIFIED模式、AT_MOST模式（wrap_content）的話需要提供默認(rèn)的大小                measureSize = defaultSize;                if (mode == View.MeasureSpec.AT_MOST) {                    //AT_MOST（wrap_content）模式下，需要取測(cè)量值與默認(rèn)值的最小值                    measureSize = Math.min(measureSize, defaultSize);                }            }            return measureSize;        }    }

***，復(fù)寫onMeasure方法，把super方法去掉：

@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {     setMeasuredDimension(MeasureUtils.measureView(widthMeasureSpec, 200),             MeasureUtils.measureView(heightMeasureSpec, 200)     ); }

View的繪制-onDraw

View繪制，需要掌握Android中View的坐標(biāo)體系：

View的坐標(biāo)體系是以左上角為坐標(biāo)原點(diǎn)，向右為X軸正方向，向下為Y軸正方向。

View繪制，主要是通過(guò)Android的2D繪圖機(jī)制來(lái)完成，時(shí)機(jī)是onDraw方法中，其中包括畫布Canvas，畫筆Paint。下面給出示例代碼。相關(guān)API不是介紹的重點(diǎn)，重點(diǎn)是Canvas的save和restore方法，通過(guò)save以后可以對(duì)畫布進(jìn)行一些放大縮小旋轉(zhuǎn)傾斜等操作，這兩個(gè)方法一般配套使用，其中save的調(diào)用次數(shù)可以多于restore。

@Override    protected void onDraw(Canvas canvas) {        super.onDraw(canvas);        Bitmap bitmap = ImageUtils.drawable2Bitmap(mDrawable);        canvas.drawBitmap(bitmap, getLeft(), getTop(), mPaint);        canvas.save();        //注意，這里的旋轉(zhuǎn)是指畫布的旋轉(zhuǎn)        canvas.rotate(90);        mPaint.setColor(Color.parseColor("#FF4081"));        mPaint.setTextSize(30);        canvas.drawText("測(cè)試", 100, -100, mPaint);        canvas.restore();    }

與布局位置相關(guān)的是onLayout方法的復(fù)寫，一般我們自定義View的時(shí)候，只需要完成測(cè)量，繪制即可。如果是自定義ViewGroup的話，需要做的就是在onLayout中測(cè)量自身以及控制子控件的布局位置，onLayout是自定義ViewGroup必須實(shí)現(xiàn)的方法。

8、性能優(yōu)化

布局優(yōu)化

使用include標(biāo)簽，通過(guò)layout屬性復(fù)用相同的布局。

<include    android:id="@+id/v_test"    layout="@layout/include_view" /

• 使用merge標(biāo)簽，去除同類的視圖

• 使用ViewStub來(lái)進(jìn)行布局的延遲加載一些不是馬上就用到的布局。例如列表頁(yè)中，列表在沒(méi)有拿到數(shù)據(jù)之前不加載，這樣做可以使UI變得流暢。

<ViewStub     android:id="@+id/v_stub"     android:layout_width="match_parent"     android:layout_height="wrap_content"     android:layout="@layout/view_stub" /> //需要手動(dòng)調(diào)用inflate方法，布局才會(huì)顯示出來(lái)。 stub.inflate(); //其中setVisibility在底層也是會(huì)調(diào)用inflate方法 //stub.setVisibility(View.VISIBLE); //之后，如果要使用ViewStub標(biāo)簽里面的View，只需要按照平常來(lái)即可。 TextView tv_1 = (TextView) findViewById(R.id.tv_1);

• 盡量多使用RelativeLayout，因?yàn)檫@樣可以大大減少視圖的層級(jí)。

內(nèi)存優(yōu)化

APP設(shè)計(jì)以及代碼編寫階段都應(yīng)該考慮內(nèi)存優(yōu)化：

珍惜Service，盡量使得Service在使用的時(shí)候才處于運(yùn)行狀態(tài)。盡量使用IntentService

IntentService在內(nèi)部其實(shí)是通過(guò)線程以及Handler實(shí)現(xiàn)的，當(dāng)有新的Intent到來(lái)的時(shí)候，會(huì)創(chuàng)建線程并且處理這個(gè)Intent，處理完畢以后就自動(dòng)銷毀自身。因此使用IntentService能夠節(jié)省系統(tǒng)資源。

內(nèi)存緊張的時(shí)候釋放資源(例如UI隱藏的時(shí)候釋放資源等)。復(fù)寫Activity的回調(diào)方法。

@Override public void onLowMemory() {     super.onLowMemory(); } @Override public void onTrimMemory(int level) {     super.onTrimMemory(level);     switch (level) {         case TRIM_MEMORY_COMPLETE:             //...             break;         case 其他:     } }

• 通過(guò)Manifest中對(duì)Application配置更大的內(nèi)存，但是一般不推薦

• android:largeHeap="true"

• 避免Bitmap的浪費(fèi)，應(yīng)該盡量去適配屏幕設(shè)備。盡量使用成熟的圖片加載框架，Picasso，F(xiàn)resco，Glide等。

• 使用優(yōu)化的容器，SparseArray等

• 其他建議：盡量少用枚舉變量，盡量少用抽象，盡量少增加類，避免使用依賴注入框架，謹(jǐn)慎使用library，使用代碼混淆，時(shí)當(dāng)場(chǎng)合考慮使用多進(jìn)程等。

• 避免內(nèi)存泄漏(本來(lái)應(yīng)該被回收的對(duì)象沒(méi)有被回收)。一旦APP的內(nèi)存短時(shí)間內(nèi)快速增長(zhǎng)或者GC非常頻繁的時(shí)候，就應(yīng)該考慮是否是內(nèi)存泄漏導(dǎo)致的。

分析方法

1. 使用Android Studio提供的Android Monitors中Memory工具查看內(nèi)存的使用以及沒(méi)使用的情況。

2. 使用DDMS提供的Heap工具查看內(nèi)存使用情況，也可以手動(dòng)觸發(fā)GC。

3. 使用性能分析的依賴庫(kù)，例如Square的LeakCanary，這個(gè)庫(kù)會(huì)在內(nèi)存泄漏的前后通過(guò)Notification通知你。

什么情況會(huì)導(dǎo)致內(nèi)存泄漏

1. 資源釋放問(wèn)題：程序代碼的問(wèn)題，長(zhǎng)期保持某些資源，如Context、Cursor、IO 流的引用，資源得不到釋放造成內(nèi)存泄露。

2. 對(duì)象內(nèi)存過(guò)大問(wèn)題：保存了多個(gè)耗用內(nèi)存過(guò)大的對(duì)象(如Bitmap、XML 文件)，造成內(nèi)存超出限制。

3. static 關(guān)鍵字的使用問(wèn)題：static 是Java  中的一個(gè)關(guān)鍵字，當(dāng)用它來(lái)修飾成員變量時(shí)，那么該變量就屬于該類，而不是該類的實(shí)例。所以用static  修飾的變量，它的生命周期是很長(zhǎng)的，如果用它來(lái)引用一些資源耗費(fèi)過(guò)多的實(shí)例(Context 的情況最多)，這時(shí)就要謹(jǐn)慎對(duì)待了。

解決方案

1. 應(yīng)該盡量避免static 成員變量引用資源耗費(fèi)過(guò)多的實(shí)例，比如Context。

2. Context 盡量使用ApplicationContext，因?yàn)锳pplication 的Context  的生命周期比較長(zhǎng)，引用它不會(huì)出現(xiàn)內(nèi)存泄露的問(wèn)題。

3. 使用WeakReference 代替強(qiáng)引用。比如可以使用WeakReference mContextRef

線程導(dǎo)致內(nèi)存溢出：線程產(chǎn)生內(nèi)存泄露的主要原因在于線程生命周期的不可控。例如Activity中的Thread在run了，但是Activity由于某種原因重新創(chuàng)建了，但是Thread仍然會(huì)運(yùn)行，因?yàn)閞un方法不結(jié)束的話Thread是不會(huì)銷毀的。

解決方案

1. 將線程的內(nèi)部類，改為靜態(tài)內(nèi)部類(因?yàn)榉庆o態(tài)內(nèi)部類擁有外部類對(duì)象的強(qiáng)引用，而靜態(tài)類則不擁有)。

2. 在線程內(nèi)部采用弱引用保存Context 引用。

查看內(nèi)存泄漏的方法、工具

• android官方提供的工具：Memory  Monitor(當(dāng)APP占用的內(nèi)存在短時(shí)間內(nèi)快速增長(zhǎng)或者GC變得頻繁的時(shí)候)、DDMS提供的Heap工具(手動(dòng)觸發(fā)GC)

• Square提供的內(nèi)存泄漏檢測(cè)工具，LeakCanary(能夠自動(dòng)完成內(nèi)存追蹤、檢測(cè)、輸出結(jié)果)，進(jìn)行演示，并且適當(dāng)?shù)慕庹f(shuō)。

性能優(yōu)化

1. 防止過(guò)度繪制，通過(guò)打開(kāi)手機(jī)的“顯示過(guò)度繪制區(qū)域”即可查看過(guò)度繪制的情況。

2. 最小化渲染時(shí)間，使用視圖樹(shù)查看節(jié)點(diǎn)，對(duì)節(jié)點(diǎn)進(jìn)行性能分析。

3. 通過(guò)TraceView進(jìn)行數(shù)據(jù)的采集以及分析。在有大概定位的時(shí)候，使用Android官方提供的Debug類進(jìn)行采集。***通過(guò)DDMS即可打開(kāi)這個(gè).trace文件，分析函數(shù)的調(diào)用情況(包括在指定情況下執(zhí)行時(shí)間，調(diào)用次數(shù))

//開(kāi)啟數(shù)據(jù)采集 Debug.startMethodTracing("test.trace"); //關(guān)閉 Debug.stopMethodTracing();

OOM

避免OOM的一些常見(jiàn)方法：

• App資源中盡量少用大圖。使用Bitmap的時(shí)候要注意等比例縮小圖片，并且注意Bitmap的回收。

BitmapFactory.Options options = new BitmapFactory.Option();  options.inSampleSize = 2;  //Options 只保存圖片尺寸大小，不保存圖片到內(nèi)存  BitmapFactory.Options opts = new BitmapFactory.Options();  opts.inSampleSize = 2;  Bitmap bmp = null;  bmp = BitmapFactory.decodeResource(getResources(),  mImageIds[position],opts);  //回收  bmp.recycle();

結(jié)合組件的生命周期，釋放資源

IO流，數(shù)據(jù)庫(kù)查詢的游標(biāo)等應(yīng)該在使用完之后及時(shí)關(guān)閉。

ListView中應(yīng)該使用ViewHolder模式緩存ConverView

頁(yè)面切換的時(shí)候盡量去傳遞(復(fù)用)一些對(duì)象

ANR

不同的組件發(fā)生ANR 的時(shí)間不一樣，主線程(Activity、Service)是5 秒，BroadCastReceiver 是10 秒。

ANR一般有三種類型：

• KeyDispatchTimeout(5 seconds)

• 主要類型按鍵或觸摸事件在特定時(shí)間內(nèi)無(wú)響應(yīng)

• BroadcastTimeout(10 seconds)

• BroadcastReceiver在特定時(shí)間內(nèi)無(wú)法處理完成

• ServiceTimeout(20 seconds)

• 小概率類型Service在特定的時(shí)間內(nèi)無(wú)法處理完成

解決方案：

1. UI線程只進(jìn)行UI相關(guān)的操作。所有耗時(shí)操作，比如訪問(wèn)網(wǎng)絡(luò)，Socket 通信，查詢大量SQL  語(yǔ)句，復(fù)雜邏輯計(jì)算等都放在子線程中去，然后通過(guò)handler.sendMessage、runonUITread、AsyncTask 等方式更新UI。

2. 無(wú)論如何都要確保用戶界面操作的流暢度。如果耗時(shí)操作需要讓用戶等待，那么可以在界面上顯示進(jìn)度條。

3. BroadCastReceiver要進(jìn)行復(fù)雜操作的的時(shí)候，可以在onReceive()方法中啟動(dòng)一個(gè)Service來(lái)處理。

9、九切圖(.9圖)、SVG圖片

九切圖

點(diǎn)九圖，是Android開(kāi)發(fā)中用到的一種特殊格式的圖片，文件名以”.9.png“結(jié)尾。這種圖片能告訴程序，圖像哪一部分可以被拉升，哪一部分不能被拉升需要保持原有比列。運(yùn)用點(diǎn)九圖可以保證圖片在不模糊變形的前提下做到自適應(yīng)。點(diǎn)九圖常用于對(duì)話框背景圖片中。

1、2部分規(guī)定了圖像的可拉伸部分,當(dāng)實(shí)際程序中設(shè)定了對(duì)話框的寬高時(shí)，1、2部分就會(huì)被拉伸成所需要的高和寬，呈現(xiàn)出于設(shè)計(jì)稿一樣的視覺(jué)效果。

而3、4部分規(guī)定了圖像的內(nèi)容區(qū)域。內(nèi)容區(qū)域規(guī)定了可編輯區(qū)域，例如文字需要被包裹在其內(nèi)。

• android5.0的SCG矢量動(dòng)畫機(jī)制

• 圖像在方法縮小的時(shí)候圖片質(zhì)量不會(huì)有損失

• 使用XML來(lái)定義圖形

• 適配不同分辨率

10、Android中數(shù)據(jù)常見(jiàn)存儲(chǔ)方式

• 文件(包括XML、SharePreference等)

• 數(shù)據(jù)庫(kù)

• Content Provider

• 保存在網(wǎng)絡(luò)

11、進(jìn)程間通信

操作系統(tǒng)進(jìn)程間通信的方法，android中有哪些?

操作系統(tǒng)：

• Windows：剪貼板、管道、郵槽等

• Linux：命名管道、共享內(nèi)存、信號(hào)量

Android中的進(jìn)程通信方式并不是完全繼承于Linux：

1. Bundle

2. 文件共享

3. AIDL

4. Messenger

5. Content Provider

6. Socket

12、常見(jiàn)的網(wǎng)絡(luò)框架

常用的http框架以及他們的特點(diǎn)

1. HttpURLConnection:在Android 2.2版本之前，HttpClient擁有較少的bug，因此使用它是***的選擇。而在Android  2.3版本及以后，HttpURLConnection則是***的選擇。它的API簡(jiǎn)單，體積較小，因而非常適用于Android項(xiàng)目。壓縮和緩存機(jī)制可以有效地減少網(wǎng)絡(luò)訪問(wèn)的流量，在提升速度和省電方面也起到了較大的作用。對(duì)于新的應(yīng)用程序應(yīng)該更加偏向于使用HttpURLConnection，因?yàn)樵谝院蟮墓ぷ鳟?dāng)中我們也會(huì)將更多的時(shí)間放在優(yōu)化HttpURLConnection上面。特點(diǎn)：比較輕便，靈活，易于擴(kuò)展，在3.0后以及4.0中都進(jìn)行了改善，如對(duì)HTTPS的支持，在4.0中，還增加了對(duì)緩存的支持。

2. HttpClient：高效穩(wěn)定，但是維護(hù)成本高昂，故android 開(kāi)發(fā)團(tuán)隊(duì)不愿意在維護(hù)該庫(kù)而是轉(zhuǎn)投更為輕便的

3. okHttp：okhttp 是一個(gè) Java 的 HTTP+SPDY 客戶端開(kāi)發(fā)包，同時(shí)也支持 Android。需要Android  2.3以上。特點(diǎn)：OKHttp是Android版Http客戶端。非常高效，支持SPDY、連接池、GZIP和 HTTP  緩存。默認(rèn)情況下，OKHttp會(huì)自動(dòng)處理常見(jiàn)的網(wǎng)絡(luò)問(wèn)題，像二次連接、SSL的握手問(wèn)題。如果你的應(yīng)用程序中集成了OKHttp，Retrofit默認(rèn)會(huì)使用OKHttp處理其他網(wǎng)絡(luò)層請(qǐng)求。從Android4.4開(kāi)始HttpURLConnection的底層實(shí)現(xiàn)采用的是okHttp。

4. volley：早期使用HttpClient，后來(lái)使用HttpURLConnection，是谷歌2013年推出的網(wǎng)絡(luò)請(qǐng)求框架，非常適合去進(jìn)行數(shù)據(jù)量不大，但通信頻繁的網(wǎng)絡(luò)操作，而對(duì)于大數(shù)據(jù)量的網(wǎng)絡(luò)操作，比如說(shuō)下載文件等，Volley的表現(xiàn)就會(huì)非常糟糕。

5. xutils：緩存網(wǎng)絡(luò)請(qǐng)求數(shù)據(jù)

6. Retrofit：和Volley框架的請(qǐng)求方式很相似，底層網(wǎng)絡(luò)請(qǐng)求采用okhttp(效率高，android4.4底層采用okhttp)，采用注解方式來(lái)指定請(qǐng)求方式和url地址，減少了代碼量。

AsyncTask

13、常用的圖片加載框架以及特點(diǎn)、源碼

1. Picasso：PicassoSquare的網(wǎng)絡(luò)庫(kù)一起能發(fā)揮***作用，因?yàn)镻icasso可以選擇將網(wǎng)絡(luò)請(qǐng)求的緩存部分交給了okhttp實(shí)現(xiàn)。

2. Glide：模仿了Picasso的API，而且在他的基礎(chǔ)上加了很多的擴(kuò)展(比如gif等支持)，支持圖片流，因此在做愛(ài)拍之類的視頻應(yīng)用用得比較多一些。

3. Fresco：Fresco中設(shè)計(jì)有一個(gè)叫做image pipeline的模塊。它負(fù)責(zé)從網(wǎng)絡(luò)，從本地文件系統(tǒng)，本地資源加載圖片。  為了***限度節(jié)省空間和CPU時(shí)間，它含有3級(jí)緩存設(shè)計(jì)(2級(jí)內(nèi)存，1級(jí)文件)。Fresco中設(shè)計(jì)有一個(gè)叫做Drawees模塊，  方便地顯示loading圖，當(dāng)圖片不再顯示在屏幕上時(shí)，及時(shí)地釋放內(nèi)存和空間占用。

Fresco是把圖片緩存放在了Ashmem(系統(tǒng)匿名內(nèi)存共享區(qū))

1. Heap-堆內(nèi)存：Android中每個(gè)App的  Java堆內(nèi)存大小都是被嚴(yán)格的限制的。每個(gè)對(duì)象都是使用Java的new在堆內(nèi)存實(shí)例化，這是內(nèi)存中相對(duì)安全的一塊區(qū)域。內(nèi)存有垃圾回收機(jī)制，所以當(dāng)  App不在使用內(nèi)存的時(shí)候，系統(tǒng)就會(huì)自動(dòng)把這塊內(nèi)存回收。不幸的是，內(nèi)存進(jìn)行垃圾回收的過(guò)程正是問(wèn)題所在。當(dāng)內(nèi)存進(jìn)行垃圾回收時(shí)，內(nèi)存不僅僅進(jìn)行了垃圾回收，還把  Android 應(yīng)用完全終止了。這也是用戶在使用 App 時(shí)最常見(jiàn)的卡頓或短暫假死的原因之一。

2. Ashmem：Android 在操作 Ashmem 堆時(shí)，會(huì)把該堆中存有數(shù)據(jù)的內(nèi)存區(qū)域從 Ashmem  堆中抽取出來(lái)，而不是把它釋放掉，這是一種弱內(nèi)存釋放模式;被抽取出來(lái)的這部分內(nèi)存只有當(dāng)系統(tǒng)真正需要更多的內(nèi)存時(shí)(系統(tǒng)內(nèi)存不夠用)才會(huì)被釋放。當(dāng) Android  把被抽取出來(lái)的這部分內(nèi)存放回 Ashmem 堆，只要被抽取的內(nèi)存空間沒(méi)有被釋放，之前的數(shù)據(jù)就會(huì)恢復(fù)到相應(yīng)的位置。

不管發(fā)生什么，垃圾回收器都不會(huì)自動(dòng)回收這些 Bitmap。當(dāng) Android 繪制系統(tǒng)在渲染這些圖片，Android 的系統(tǒng)庫(kù)就會(huì)把這些 Bitmap 從  Ashmem 堆中抽取出來(lái)，而當(dāng)渲染結(jié)束后，這些 Bitmap  又會(huì)被放回到原來(lái)的位置。如果一個(gè)被抽取的圖片需要再繪制一次，系統(tǒng)僅僅需要把它再解碼一次，這個(gè)操作非常迅速。

14、在Android開(kāi)發(fā)里用什么做線程間的通訊工具?

傳統(tǒng)點(diǎn)的方法就是往同步代碼塊里些數(shù)據(jù)，然后使用回調(diào)讓另外一條線程去讀。在Android里我一般會(huì)創(chuàng)建Looper線程，然后Hanlder傳遞消息。

1***ndroid新特性相關(guān)

1. 5.0：Material Design、多種設(shè)備的支持、支持64位ART虛擬機(jī)、Project Volta電池續(xù)航改進(jìn)計(jì)劃等

2. 6.0：動(dòng)態(tài)權(quán)限管理、過(guò)度動(dòng)畫、支付、指紋等

3. 7.0：分屏、通知消息快捷回復(fù)、夜間模式、流量保護(hù)模式等

16、網(wǎng)絡(luò)請(qǐng)求優(yōu)化

網(wǎng)絡(luò)請(qǐng)求優(yōu)化

1. 能夠緩存起來(lái)的盡量去緩存起來(lái)，減輕服務(wù)器的壓力。例如APP中首頁(yè)的一些數(shù)據(jù)，又例如首頁(yè)的圖標(biāo)、文案都是緩存起來(lái)的，而且這些數(shù)據(jù)通過(guò)網(wǎng)絡(luò)來(lái)指定可以使app具有更大的靈活性。

2. 不用域名，用 IP 直連，省去了DNS域名解析。

3. 連接復(fù)用、請(qǐng)求合并、請(qǐng)求數(shù)據(jù)Body可以利用壓縮算法Gzip來(lái)進(jìn)行壓縮，使用JSON 代替 XML

網(wǎng)絡(luò)請(qǐng)求的安全性

這塊了解的不多。我給你說(shuō)說(shuō)我的思路吧，利用哈希算法，比如MD5，服務(wù)器給我們的數(shù)據(jù)可以通過(guò)時(shí)間戳和其他參數(shù)做個(gè)加密，得到一個(gè)key，在客戶端取出數(shù)據(jù)后根據(jù)數(shù)據(jù)和時(shí)間戳再去生成key與服務(wù)端給的做個(gè)對(duì)比。

17、新技術(shù)相關(guān)

RXJava：一個(gè)異步請(qǐng)求庫(kù)，核心就是異步。利用的是一種擴(kuò)展的觀察模式，被觀察者發(fā)生某種變化的時(shí)候，可以通過(guò)事件(onNext、onError、onComplete)等方式通過(guò)觀察者。RXJava同時(shí)支持線程的調(diào)度和切換，用戶可以指定訂閱發(fā)生的線程以及觀察者觸發(fā)的線程。

Retrofit：通過(guò)注解的方式來(lái)指定URL、請(qǐng)求方法，實(shí)質(zhì)上底層是通過(guò)OKHttp來(lái)實(shí)現(xiàn)的。

以上就是關(guān)于“Android的生命周期是什么”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對(duì)大家有幫助，若想了解更多相關(guān)的知識(shí)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。