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

談?wù)勀銓ndroid系統(tǒng)（體系）架構(gòu)的理解

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

1. 應(yīng)用程序?qū)樱喊ㄏ到y(tǒng)應(yīng)用以及第三方應(yīng)用。

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

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

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

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

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

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

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

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

1、Activity的生命周期

生命周期：對象什么時候生，什么時候死，怎么寫代碼，代碼往那里寫。

注意：

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

2. onCreate和onDestroy配對，onStart和onStop配對（是否可見），onResume和onPause配對（是否在前臺，可以與用戶交互）

3. 打開新的Activity的時候，相關(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會銷毀，并且在onStop之前回調(diào)onSaveInstanceState保存數(shù)據(jù)，在重新創(chuàng)建Activity的時候在onStart之后回調(diào)onRestoreInstanceState。其中Bundle數(shù)據(jù)會傳到onCreate（不一定有數(shù)據(jù)）和onRestoreInstanceState（一定有數(shù)據(jù)）。

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

?android:configChanges="orientation"

2、Fragment的生命周期

正常啟動

? ?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的啟動模式

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

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

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

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

4、Activity與Fragment之間的傳值

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

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

   //Activity中對fragment設(shè)置一些參數(shù)

   fragment.setArguments(bundle);

   //fragment中通過getArguments獲得Activity中的方法

   Bundle arguments = getArguments()

   
   

   
   

3. 利用eventbus進(jìn)行通信，這種方法實(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ù)，屬于同一個應(yīng)用程序，通過startService來啟動或者通過bindService來綁定并且獲取代理對象。如果只是想開個服務(wù)在后臺運(yùn)行的話，直接startService即可，如果需要相互之間進(jìn)行傳值或者操作的話，就應(yīng)該通過bindService。

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

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

? ?

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

? ?

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

注意

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

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

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

為什么要使用Handler？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正確的使用方法是：

?handler = null;

? ?new Thread(new Runnable() {

? ? ? ?private Looper mLooper;

? ? ? ?@Override

? ? ? ?public void run() {

? ? ? ? ? ?//必須調(diào)用Looper的prepare方法為當(dāng)前線程創(chuàng)建一個Looper對象，然后啟動循環(huán)

? ? ? ? ? ?//prepare方法中實(shí)質(zhì)是給ThreadLocal對象創(chuàng)建了一個Looper對象

? ? ? ? ? ?//如果當(dāng)前線程已經(jīng)創(chuàng)建過Looper對象了，那么會報錯

? ? ? ? ? ?Looper.prepare();

? ? ? ? ? ?handler = new Handler();

? ? ? ? ? ?//獲取Looper對象

? ? ? ? ? ?mLooper = Looper.myLooper();

? ? ? ? ? ?//啟動消息循環(huán)

? ? ? ? ? ?Looper.loop();

? ? ? ? ? ?//在適當(dāng)?shù)臅r候退出Looper的消息循環(huán)，防止內(nèi)存泄漏

? ? ? ? ? ?mLooper.quit();

? ? ? ?}

? ?}).start();

主線程中默認(rèn)是創(chuàng)建了Looper并且啟動了消息的循環(huán)的，因此不會報錯：
應(yīng)用程序的入口是ActivityThread的main方法，在這個方法里面會創(chuàng)建Looper，并且執(zhí)行Looper的loop方法來啟動消息的循環(huán)，使得應(yīng)用程序一直運(yùn)行。

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

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

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

Android的視圖樹

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

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

ViewGroup有以下三個與事件分發(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，如果沒有任何視圖消耗事件的話，事件會順著路徑往回傳遞。其中：

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

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

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

4. 子View可以通過requestDisallowInterceptTouchEvent方法去請求父元素不要攔截。

注意

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

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

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

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

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

自定義View的分類

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

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

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

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

View的測量-onMeasure

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

MeasureSpec的三種模式：

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

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

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

下面給出模板代碼：

? ?public class MeasureUtils {

? ? ? ?/**

? ? ? ? * 用于View的測量

? ? ? ? *

? ? ? ? * @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）模式下，需要取測量值與默認(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繪制，主要是通過Android的2D繪圖機(jī)制來完成，時機(jī)是onDraw方法中，其中包括畫布Canvas，畫筆Paint。下面給出示例代碼。相關(guān)API不是介紹的重點(diǎn)，重點(diǎn)是Canvas的save和restore方法，通過save以后可以對畫布進(jìn)行一些放大縮小旋轉(zhuǎn)傾斜等操作，這兩個方法一般配套使用，其中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("測試", 100, -100, mPaint);

? ? ? ?canvas.restore();

? ?}

View的位置-onLayout

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

8、性能優(yōu)化

布局優(yōu)化

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

   ?<include

   ? ? android:id="@+id/v_test"

   ? ? layout="@layout/include_view" /

   
   

   
   

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

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

   <ViewStub

   ? ? android:id="@+id/v_stub"

   ? ? android:layout_width="match_parent"

   ? ? android:layout_height="wrap_content"

   ? ? android:layout="@layout/view_stub" />

   //需要手動調(diào)用inflate方法，布局才會顯示出來。

   stub.inflate();

   //其中setVisibility在底層也是會調(diào)用inflate方法

   //stub.setVisibility(View.VISIBLE);

   //之后，如果要使用ViewStub標(biāo)簽里面的View，只需要按照平常來即可。

   TextView tv_1 = (TextView) findViewById(R.id.tv_1);

   
   

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

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

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

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

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

2. 內(nèi)存緊張的時候釋放資源（例如UI隱藏的時候釋放資源等）。復(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 其他:

   ? ? }

   }

   
   

3. 通過Manifest中對Application配置更大的內(nèi)存，但是一般不推薦

   android:largeHeap="true"
   

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

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

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

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

   分析方法

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

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

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

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

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

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

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

   解決方案
   1. 應(yīng)該盡量避免static 成員變量引用資源耗費(fèi)過多的實(shí)例，比如Context。
   2. Context 盡量使用ApplicationContext，因?yàn)锳pplication 的Context 的生命周期比較長，引用它不會出現(xiàn)內(nèi)存泄露的問題。
   3. 使用WeakReference 代替強(qiáng)引用。比如可以使用WeakReference<Context> mContextRef
   

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

   解決方案

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

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

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

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

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

性能優(yōu)化

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

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

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

   
   

   //開啟數(shù)據(jù)采集

   Debug.startMethodTracing("test.trace");

   //關(guān)閉

   Debug.stopMethodTracing();

   
   

OOM

避免OOM的一些常見方法：

1. App資源中盡量少用大圖。使用Bitmap的時候要注意等比例縮小圖片，并且注意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();

   
   

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

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

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

5. 頁面切換的時候盡量去傳遞（復(fù)用）一些對象

ANR

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

ANR一般有三種類型：

1. KeyDispatchTimeout(5 seconds)
   主要類型按鍵或觸摸事件在特定時間內(nèi)無響應(yīng)

2. BroadcastTimeout(10 seconds)
   BroadcastReceiver在特定時間內(nèi)無法處理完成

3. ServiceTimeout(20 seconds)
   小概率類型Service在特定的時間內(nèi)無法處理完成

   解決方案：

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

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

3. BroadCastReceiver要進(jìn)行復(fù)雜操作的的時候，可以在onReceive()方法中啟動一個Service來處理。

9、九切圖（.9圖）、SVG圖片

九切圖

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

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

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

android5.0的SCG矢量動畫機(jī)制

1. 圖像在方法縮小的時候圖片質(zhì)量不會有損失

2. 使用XML來定義圖形

3. 適配不同分辨率

10、Android中數(shù)據(jù)常見存儲方式

1. 文件（包括XML、SharePreference等）

2. 數(shù)據(jù)庫

3. Content Provider

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

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

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

操作系統(tǒng)：

1. Windows：剪貼板、管道、郵槽等

2. Linux：命名管道、共享內(nèi)存、信號量

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

1. Bundle

2. 文件共享

3. AIDL

4. Messenger

5. Content Provider

6. Socket

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

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

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

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

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

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

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

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

7. AsyncTask

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

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

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

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

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

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

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

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

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

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

15、Android新特性相關(guān)

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

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

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

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

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

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

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

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

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

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

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

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

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