Android年薪30萬面試寶典

1、Activity的生命週期

生命週期：物件什麼時候生，什麼時候死，怎麼寫程式碼，程式碼往那裡寫。

注意：

當開啟新的Activity，採用透明主題的時候，當前Activity不會回撥onStop
onCreate和onDestroy配對，onStart和onStop配對（是否可見），onResume和onPause配對（是否在前臺，可以與使用者互動）

開啟新的Activity的時候，相關的Log為：

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

異常狀態下的生命週期：

資源相關的系統配置發生改變或者資源不足：例如螢幕旋轉，當前Activity會銷燬，並且在onStop之前回撥onSaveInstanceState儲存資料，在重新建立Activity的時候在onStart之後回撥onRestoreInstanceState。其中Bundle資料會傳到onCreate（不一定有資料）和onRestoreInstanceState（一定有資料）。

    防止螢幕旋轉的時候重建，在清單檔案中新增配置：
    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的啟動模式

standard：每次啟用Activity時(startActivity)，都建立Activity例項，並放入任務棧；
singleTop：如果某個Activity自己啟用自己，即任務棧棧頂就是該Activity，則不需要建立，其餘情況都要建立Activity例項；
singleTask：如果要啟用的那個Activity在任務棧中存在該例項，則不需要建立，只需要把此Activity放入棧頂，即把該Activity以上的Activity例項都pop，並呼叫其onNewIntent；
singleInstance：應用1的任務棧中建立了MainActivity例項，如果應用2也要啟用MainActivity，則不需要建立，兩應用共享該Activity例項。

4、Activity與Fragment之間的傳值

透過findFragmentByTag或者getActivity獲得對方的引用（強轉）之後，再相互呼叫對方的public方法，但是這樣做一是引入了“強轉”的醜陋程式碼，另外兩個類之間各自持有對方的強引用，耦合較大，容易造成記憶體洩漏。

透過Bundle的方法進行傳值，例如以下程式碼：

 //Activity中對fragment設定一些引數
 fragment.setArguments(bundle);

 //fragment中透過getArguments獲得Activity中的方法
 Bundle arguments = getArguments();

利用eventbus進行通訊，這種方法實時性高，而且Activity與Fragment之間可以完全解耦。

 //Activity中的程式碼
 EventBus.getDefault().post("訊息");

 //Fragment中的程式碼
 EventBus.getDefault().register(this);

 @Subscribe
 public void test(String text) {
     tv_test.setText(text);
 }

5、Service

Service分為兩種：

本地服務，屬於同一個應用程式，透過startService來啟動或者透過bindService來繫結並且獲取代理物件。如果只是想開個服務在後臺執行的話，直接startService即可，如果需要相互之間進行傳值或者操作的話，就應該透過bindService。
遠端服務（不同應用程式之間），透過bindService來繫結並且獲取代理物件。

對應的生命週期如下：

    context.startService() ->onCreate()- >onStartCommand()->Service running--呼叫context.stopService() ->onDestroy() 

    context.bindService()->onCreate()->onBind()->Service running--呼叫>onUnbind() -> onDestroy()

注意

Service預設是執行在main執行緒的，因此Service中如果需要執行耗時操作（大檔案的操作，資料庫的複製，網路請求，檔案下載等）的話應該在子執行緒中完成。

！特殊情況是：Service在清單檔案中指定了在其他程式中執行。

6、Android中的訊息傳遞機制

為什麼要使用Handler？

因為螢幕的重新整理頻率是60Hz，大概16毫秒會重新整理一次，所以為了保證UI的流暢性，耗時操作需要在子執行緒中處理，子執行緒不能直接對UI進行更新操作。因此需要Handler在子執行緒發訊息給主執行緒來更新UI。

這裡再深入一點，Android中的UI控制元件不是執行緒安全的，因此在多執行緒併發訪問UI的時候會導致UI控制元件處於不可預期的狀態。Google不透過鎖的機制來處理這個問題是因為：

引入鎖會導致UI的操作變得複雜
引入鎖會導致UI的執行效率降低

因此，Google的工程師最後是透過單執行緒的模型來操作UI，開發者只需要透過Handler在不同執行緒之間切花就可以了。

概述一下Android中的訊息機制？

Android中的訊息機制主要是指Handler的執行機制。Handler是進行執行緒切換的關鍵，在主執行緒和子執行緒之間切換隻是一種比較特殊的使用情景而已。其中訊息傳遞機制需要了解的東西有Message、Handler、Looper、Looper裡面的MessageQueue物件。

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

MessageQueue是傳送帶，負責Message佇列的傳送與管理
Looper是流水線的發動機，不斷地把訊息從訊息佇列裡面取出來，交給Handler來處理
Message是每一件產品
Handler就是工人。但是這麼比喻不太恰當，因為傳送以及最終處理Message的都是Handler

為什麼在子執行緒中建立Handler會拋異常？

Handler的工作是依賴於Looper的，而Looper（與訊息佇列）又是屬於某一個執行緒（ThreadLocal是執行緒內部的資料儲存類，透過它可以在指定執行緒中儲存資料，其他執行緒則無法獲取到），其他執行緒不能訪問。因此Handler就是間接跟執行緒是繫結在一起了。因此要使用Handler必須要保證Handler所建立的執行緒中有Looper物件並且啟動迴圈。因為子執行緒中預設是沒有Looper的，所以會報錯。

正確的使用方法是：

    handler = null;
    new Thread(new Runnable() {

        private Looper mLooper;

        @Override
        public void run() {
            //必須呼叫Looper的prepare方法為當前執行緒建立一個Looper物件，然後啟動迴圈
            //prepare方法中實質是給ThreadLocal物件建立了一個Looper物件
            //如果當前執行緒已經建立過Looper物件了，那麼會報錯
            Looper.prepare();
            handler = new Handler();
            //獲取Looper物件
            mLooper = Looper.myLooper();
            //啟動訊息迴圈
            Looper.loop();

            //在適當的時候退出Looper的訊息迴圈，防止記憶體洩漏
            mLooper.quit();
        }
    }).start();

主執行緒中預設是建立了Looper並且啟動了訊息的迴圈的，因此不會報錯：
應用程式的入口是ActivityThread的main方法，在這個方法裡面會建立Looper，並且執行Looper的loop方法來啟動訊息的迴圈，使得應用程式一直執行。

子執行緒中可以透過Handler傳送訊息給主執行緒嗎？

可以。有時候出於業務需要，主執行緒可以向子執行緒傳送訊息。子執行緒的Handler必須按照上述方法建立，並且關聯Looper。

7、事件傳遞機制以及自定義View相關

Android的檢視樹

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

事件傳分發機制

ViewGroup有以下三個與事件分發的方法，而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);
    }

事件總是從上往下進行分發，即先到達Activity，再到達ViewGroup，再到達子View，如果沒有任何檢視消耗事件的話，事件會順著路徑往回傳遞。其中：

dispatchTouchEvent是事件的分發方法，如果事件能夠到達該檢視的話，就首先一定會呼叫，一般我們不會去修改這個方法。
onInterceptTouchEvent是事件分發的核心方法，表示ViewGroup是否攔截事件，如果返回true表示攔截，在這之後ViewGroup的onTouchEvent會被呼叫，事件就不會往下傳遞。
onTouchEvent是最低階的，在事件分發中最後被呼叫。
子View可以透過requestDisallowInterceptTouchEvent方法去請求父元素不要攔截。

注意

事件從Activity.dispatchTouchEvent()開始傳遞，只要沒有被停止或攔截，從最上層的View(ViewGroup)開始一直往下(子View)傳遞。子View 可以透過onTouchEvent()對事件進行處理。
事件由父View(ViewGroup)傳遞給子View，ViewGroup 可以透過onInterceptTouchEvent()對事件做攔截，停止其往下傳遞。
如果事件從上往下傳遞過程中一直沒有被停止，且最底層子View 沒有消費事件，事件會反向往上傳遞，這時父View(ViewGroup)可以進行消費，如果還是沒有被消費的話，最後會到Activity 的onTouchEvent()函式。
如果View 沒有對ACTION_DOWN 進行消費，之後的其他事件不會傳遞過來。
OnTouchListener 優先於onTouchEvent()對事件進行消費。

自定義View的分類

對現有的View的子類進行擴充套件，例如複寫onDraw方法、擴充套件新功能等。
自定義組合控制元件，把常用一些控制元件組合起來以方便使用。
直接繼承View實現View的完全定製，需要完成View的測量以及繪製。
自定義ViewGroup，需要複寫onLayout完成子View位置的確定等工作。

View的測量-onMeasure

View的測量最終是在onMeasure方法中透過setMeasuredDimension把代表寬高兩個MeasureSpec設定給View，因此需要掌握MeasureSpec。MeasureSpec包括大小資訊以及模式資訊。

MeasureSpec的三種模式：

EXACTLY模式：精確模式，對應於使用者指定為match_parent或者具體大小的時候（實際上指定為match_parent實質上是指定大小為父容器的大小）
AT_MOST模式：對應於使用者指定為wrap_content，此時控制元件尺寸只要不超過父控制元件允許的最大尺寸即可。
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);

            //根據模式去返回大小
            if (mode == View.MeasureSpec.EXACTLY) {
                //精確模式（指定大小以及match_parent）直接返回指定的大小
                measureSize = size;
            } else {
                //UNSPECIFIED模式、AT_MOST模式（wrap_content）的話需要提供預設的大小
                measureSize = defaultSize;
                if (mode == View.MeasureSpec.AT_MOST) {
                    //AT_MOST（wrap_content）模式下，需要取測量值與預設值的最小值
                    measureSize = Math.min(measureSize, defaultSize);
                }
            }
            return measureSize;
        }
    }

最後，複寫onMeasure方法，把super方法去掉：

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

View的繪製-onDraw

View繪製，需要掌握Android中View的座標體系：

View的座標體系是以左上角為座標原點，向右為X軸正方向，向下為Y軸正方向。

View繪製，主要是透過Android的2D繪圖機制來完成，時機是onDraw方法中，其中包括畫布Canvas，畫筆Paint。下面給出示例程式碼。相關API不是介紹的重點，重點是Canvas的save和restore方法，透過save以後可以對畫布進行一些放大縮小旋轉傾斜等操作，這兩個方法一般配套使用，其中save的呼叫次數可以多於restore。

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);

        Bitmap bitmap = ImageUtils.drawable2Bitmap(mDrawable);
        canvas.drawBitmap(bitmap, getLeft(), getTop(), mPaint);

        canvas.save();
        //注意，這裡的旋轉是指畫布的旋轉
        canvas.rotate(90);
        mPaint.setColor(Color.parseColor("#FF4081"));
        mPaint.setTextSize(30);
        canvas.drawText("測試", 100, -100, mPaint);

        canvas.restore();
    }

View的位置-onLayout

與佈局位置相關的是onLayout方法的複寫，一般我們自定義View的時候，只需要完成測量，繪製即可。如果是自定義ViewGroup的話，需要做的就是在onLayout中測量自身以及控制子控制元件的佈局位置，onLayout是自定義ViewGroup必須實現的方法。

8、效能最佳化

佈局最佳化

使用include標籤，透過layout屬性複用相同的佈局。
```
  
```
使用merge標籤，去除同類的檢視

使用ViewStub來進行佈局的延遲載入一些不是馬上就用到的佈局。例如列表頁中，列表在沒有拿到資料之前不載入，這樣做可以使UI變得流暢。

 

 //需要手動呼叫inflate方法，佈局才會顯示出來。
 stub.inflate();
 //其中setVisibility在底層也是會呼叫inflate方法
 //stub.setVisibility(View.VISIBLE);
 //之後，如果要使用ViewStub標籤裡面的View，只需要按照平常來即可。
 TextView tv_1 = (TextView) findViewById(R.id.tv_1);

儘量多使用RelativeLayout，因為這樣可以大大減少檢視的層級。

記憶體最佳化

APP設計以及程式碼編寫階段都應該考慮記憶體最佳化：

珍惜Service，儘量使得Service在使用的時候才處於執行狀態。儘量使用IntentService

IntentService在內部其實是透過執行緒以及Handler實現的，當有新的Intent到來的時候，會建立執行緒並且處理這個Intent，處理完畢以後就自動銷燬自身。因此使用IntentService能夠節省系統資源。
記憶體緊張的時候釋放資源（例如UI隱藏的時候釋放資源等）。複寫Activity的回撥方法。
```
 @Override
 public void onLowMemory() {
     super.onLowMemory();

 }
```

    @Override
    public void onTrimMemory(int level) {
        super.onTrimMemory(level);

        switch (level) {
            case TRIM_MEMORY_COMPLETE:
                //...
                break;
            case 其他:
        }
    }

透過Manifest中對Application配置更大的記憶體，但是一般不推薦
```
 android:largeHeap="true"
```
避免Bitmap的浪費，應該儘量去適配螢幕裝置。儘量使用成熟的圖片載入框架，Picasso，Fresco，Glide等。
使用最佳化的容器，SparseArray等
其他建議：儘量少用列舉變數，儘量少用抽象，儘量少增加類，避免使用依賴注入框架，謹慎使用library，使用程式碼混淆，時當場合考慮使用多程式等。

避免記憶體洩漏（本來應該被回收的物件沒有被回收）。一旦APP的記憶體短時間內快速增長或者GC非常頻繁的時候，就應該考慮是否是記憶體洩漏導致的。

 分析方法
 1. 使用Android Studio提供的Android Monitors中Memory工具檢視記憶體的使用以及沒使用的情況。
 2. 使用DDMS提供的Heap工具檢視記憶體使用情況，也可以手動觸發GC。
 3. 使用效能分析的依賴庫，例如Square的LeakCanary，這個庫會在記憶體洩漏的前後透過Notification通知你。

什麼情況會導致記憶體洩漏

資源釋放問題：程式程式碼的問題，長期保持某些資源，如Context、Cursor、IO 流的引用，資源得不到釋放造成記憶體洩露。
物件記憶體過大問題：儲存了多個耗用記憶體過大的物件（如Bitmap、XML 檔案），造成記憶體超出限制。

static 關鍵字的使用問題：static 是Java 中的一個關鍵字，當用它來修飾成員變數時，那麼該變數就屬於該類，而不是該類的例項。所以用static 修飾的變數，它的生命週期是很長的，如果用它來引用一些資源耗費過多的例項（Context 的情況最多），這時就要謹慎對待了。

 解決方案
 1. 應該儘量避免static 成員變數引用資源耗費過多的例項，比如Context。
 2. Context 儘量使用ApplicationContext，因為Application 的Context 的生命週期比較長，引用它不會出現記憶體洩露的問題。
 3. 使用WeakReference 代替強引用。比如可以使用WeakReference mContextRef

執行緒導致記憶體溢位：執行緒產生記憶體洩露的主要原因在於執行緒生命週期的不可控。例如Activity中的Thread在run了，但是Activity由於某種原因重新建立了，但是Thread仍然會執行，因為run方法不結束的話Thread是不會銷燬的。
```
 解決方案
 1. 將執行緒的內部類，改為靜態內部類（因為非靜態內部類擁有外部類物件的強引用，而靜態類則不擁有）。
 2. 線上程內部採用弱引用儲存Context 引用。
```

效能最佳化

防止過度繪製，透過開啟手機的“顯示過度繪製區域”即可檢視過度繪製的情況。
最小化渲染時間，使用檢視樹檢視節點，對節點進行效能分析。
透過TraceView進行資料的採集以及分析。在有大概定位的時候，使用Android官方提供的Debug類進行採集。最後透過DDMS即可開啟這個.trace檔案，分析函式的呼叫情況（包括在指定情況下執行時間，呼叫次數）
```
 //開啟資料採集
 Debug.startMethodTracing("test.trace");
 //關閉
 Debug.stopMethodTracing();
```

OOM

避免OOM的一些常見方法：

App資源中儘量少用大圖。使用Bitmap的時候要注意等比例縮小圖片，並且注意Bitmap的回收。

 BitmapFactory.Options options = new BitmapFactory.Option();
 options.inSampleSize = 2;
 //Options 只儲存圖片尺寸大小，不儲存圖片到記憶體
 BitmapFactory.Options opts = new BitmapFactory.Options();
 opts.inSampleSize = 2;
 Bitmap bmp = null;
 bmp = BitmapFactory.decodeResource(getResources(),
 mImageIds[position],opts);

 //回收
 bmp.recycle();

結合元件的生命週期，釋放資源
IO流，資料庫查詢的遊標等應該在使用完之後及時關閉。
ListView中應該使用ViewHolder模式快取ConverView
頁面切換的時候儘量去傳遞（複用）一些物件

ANR

不同的元件發生ANR 的時間不一樣，主執行緒（Activity、Service）是5 秒，BroadCastReceiver 是10 秒。

ANR一般有三種型別：

KeyDispatchTimeout(5 seconds)
主要型別按鍵或觸控事件在特定時間內無響應
BroadcastTimeout(10 seconds)
BroadcastReceiver在特定時間內無法處理完成

ServiceTimeout(20 seconds)
小機率型別Service在特定的時間內無法處理完成

 解決方案：
 1. UI執行緒只進行UI相關的操作。所有耗時操作，比如訪問網路，Socket 通訊，查詢大量SQL 語句，複雜邏輯計算等都放在子執行緒中去，然後透過handler.sendMessage、runonUITread、AsyncTask 等方式更新UI。
 2. 無論如何都要確保使用者介面操作的流暢度。如果耗時操作需要讓使用者等待，那麼可以在介面上顯示進度條。
 3. BroadCastReceiver要進行復雜操作的的時候，可以在onReceive()方法中啟動一個Service來處理。

9、九切圖（.9圖）

點九圖，是Android開發中用到的一種特殊格式的圖片，檔名以”.9.png“結尾。這種圖片能告訴程式，影像哪一部分可以被拉昇，哪一部分不能被拉昇需要保持原有比列。運用點九圖可以保證圖片在不模糊變形的前提下做到自適應。點九圖常用於對話方塊背景圖片中。

1、2部分規定了影像的可拉伸部分,當實際程式中設定了對話方塊的寬高時，1、2部分就會被拉伸成所需要的高和寬，呈現出於設計稿一樣的視覺效果。
而3、4部分規定了影像的內容區域。內容區域規定了可編輯區域，例如文字需要被包裹在其內。

10、Android中資料常見儲存方式

檔案（包括XML、SharePreference等）
資料庫
Content Provider
儲存在網路

11、程式間通訊

作業系統程式間通訊的方法，android中有哪些？

作業系統：

Windows：剪貼簿、管道、郵槽等
Linux：命名管道、共享記憶體、訊號量

Android中的程式通訊方式並不是完全繼承於Linux：

Bundle
檔案共享
AIDL
Messenger
Content Provider
Socket

12、常見的網路框架

常用的http框架以及他們的特點

HttpURLConnection:在Android 2.2版本之前，HttpClient擁有較少的bug，因此使用它是最好的選擇。而在Android 2.3版本及以後，HttpURLConnection則是最佳的選擇。它的API簡單，體積較小，因而非常適用於Android專案。壓縮和快取機制可以有效地減少網路訪問的流量，在提升速度和省電方面也起到了較大的作用。對於新的應用程式應該更加偏向於使用HttpURLConnection，因為在以後的工作當中我們也會將更多的時間放在最佳化HttpURLConnection上面。特點：比較輕便，靈活，易於擴充套件，在3.0後以及4.0中都進行了改善，如對HTTPS的支援，在4.0中，還增加了對快取的支援。
HttpClient：高效穩定，但是維護成本高昂，故android 開發團隊不願意在維護該庫而是轉投更為輕便的
okHttp：okhttp 是一個 Java 的 HTTP+SPDY 客戶端開發包，同時也支援 Android。需要Android 2.3以上。特點：OKHttp是Android版Http客戶端。非常高效，支援SPDY、連線池、GZIP和 HTTP 快取。預設情況下，OKHttp會自動處理常見的網路問題，像二次連線、SSL的握手問題。如果你的應用程式中整合了OKHttp，Retrofit預設會使用OKHttp處理其他網路層請求。從Android4.4開始HttpURLConnection的底層實現採用的是okHttp。
volley：早期使用HttpClient，後來使用HttpURLConnection，是谷歌2013年推出的網路請求框架，非常適合去進行資料量不大，但通訊頻繁的網路操作，而對於大資料量的網路操作，比如說下載檔案等，Volley的表現就會非常糟糕。
xutils：快取網路請求資料
Retrofit：和Volley框架的請求方式很相似，底層網路請求採用okhttp（效率高，android4.4底層採用okhttp），採用註解方式來指定請求方式和url地址，減少了程式碼量。
AsyncTask

13、常用的圖片載入框架以及特點、原始碼

Picasso：PicassoSquare的網路庫一起能發揮最大作用，因為Picasso可以選擇將網路請求的快取部分交給了okhttp實現。
Glide：模仿了Picasso的API，而且在他的基礎上加了很多的擴充套件(比如gif等支援)，支援圖片流，因此在做愛拍之類的影片應用用得比較多一些。
Fresco：Fresco中設計有一個叫做image pipeline的模組。它負責從網路，從本地檔案系統，本地資源載入圖片。為了最大限度節省空間和CPU時間，它含有3級快取設計（2級記憶體，1級檔案）。Fresco中設計有一個叫做Drawees模組，方便地顯示loading圖，當圖片不再顯示在螢幕上時，及時地釋放記憶體和空間佔用。

Fresco是把圖片快取放在了Ashmem（系統匿名記憶體共享區）

Heap-堆記憶體：Android中每個App的 Java堆記憶體大小都是被嚴格的限制的。每個物件都是使用Java的new在堆記憶體例項化，這是記憶體中相對安全的一塊區域。記憶體有垃圾回收機制，所以當 App不在使用記憶體的時候，系統就會自動把這塊記憶體回收。不幸的是，記憶體進行垃圾回收的過程正是問題所在。當記憶體進行垃圾回收時，記憶體不僅僅進行了垃圾回收，還把 Android 應用完全終止了。這也是使用者在使用 App 時最常見的卡頓或短暫假死的原因之一。
Ashmem：Android 在操作 Ashmem 堆時，會把該堆中存有資料的記憶體區域從 Ashmem 堆中抽取出來，而不是把它釋放掉，這是一種弱記憶體釋放模式；被抽取出來的這部分記憶體只有當系統真正需要更多的記憶體時（系統記憶體不夠用）才會被釋放。當 Android 把被抽取出來的這部分記憶體放回 Ashmem 堆，只要被抽取的記憶體空間沒有被釋放，之前的資料就會恢復到相應的位置。

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

14、在Android開發裡用什麼做執行緒間的通訊工具？

傳統點的方法就是往同步程式碼塊裡些資料，然後使用回撥讓另外一條執行緒去讀。在Android裡我一般會建立Looper執行緒，然後Hanlder傳遞訊息。

15、Android新特性相關

5.0：Material Design、多種裝置的支援、支援64位ART虛擬機器、Project Volta電池續航改進計劃等
6.0：動態許可權管理、過度動畫、支付、指紋等
7.0：分屏、通知訊息快捷回覆、夜間模式、流量保護模式等

16、網路請求最佳化

網路請求最佳化

能夠快取起來的儘量去快取起來，減輕伺服器的壓力。例如APP中首頁的一些資料，又例如首頁的圖示、文案都是快取起來的，而且這些資料透過網路來指定可以使app具有更大的靈活性。
不用域名，用 IP 直連，省去了DNS域名解析。
連線複用、請求合併、請求資料Body可以利用壓縮演算法Gzip來進行壓縮，使用JSON 代替 XML

網路請求的安全性

這塊瞭解的不多。我給你說說我的思路吧，利用雜湊演算法，比如MD5，伺服器給我們的資料可以透過時間戳和其他引數做個加密，得到一個key，在客戶端取出資料後根據資料和時間戳再去生成key與服務端給的做個對比。

17、新技術相關

RXJava：一個非同步請求庫，核心就是非同步。利用的是一種擴充套件的觀察模式，被觀察者發生某種變化的時候，可以透過事件（onNext、onError、onComplete）等方式透過觀察者。RXJava同時支援執行緒的排程和切換，使用者可以指定訂閱發生的執行緒以及觀察者觸發的執行緒。

Retrofit：透過註解的方式來指定URL、請求方法，實質上底層是透過OKHttp來實現的。

原文連結：http://www.apkbus.com/blog-904275-65736.html

Android年薪30萬面試寶典-不定期更新