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

時間 2019-11-30

標籤 android 年薪面試寶典按期更新欄目 Android 简体版

原文原文鏈接

做者-煥然一璐，支持原創，轉載請註明出處，謝謝合做。原文連接：http://www.jianshu.com/p/4bcd4c50fd6bandroid

Android年薪30萬面試寶典

0、Android總體架構

談談你對android系統（體系）架構的理解

Linux操做系統爲核心，從下往上，依賴關係。面試

應用程序層：包括系統應用以及第三方應用。
應用程序框架：提供應用開發所必須的一些API框架，是軟件複用的重要手段
庫：android運行時（核心包（至關於JDK提供的包），虛擬機（優化過的JVM））；C/C++的一些庫
Linux核心：提供了電源管理、進程調度、內存管理、網絡協議棧、驅動模型等核心系統服務

android中的四大組件以及應用場景

Activity：在Android應用中負責與用戶交互的組件。
Service：經常使用於爲其餘組件提供後臺服務或者監控其餘組件的運行狀態。常常用來執行一些耗時操做。
BroadcastReceiver：用於監聽應用程序中的其餘組件。
ContentProvider：Android應用程序之間實現實時數據交換。

一、Activity的生命週期

生命週期：對象何時生，何時死，怎麼寫代碼，代碼往那裏寫。算法

注意：數據庫

當打開新的Activity，採用透明主題的時候，當前Activity不會回調onStopexpress
onCreate和onDestroy配對，onStart和onStop配對（是否可見），onResume和onPause配對（是否在前臺，能夠與用戶交互）canvas

打開新的Activity的時候，相關的Log爲：緩存

Main1Activity: onPause
 Main2Activity: onCreate
 Main2Activity: onStart
 Main2Activity: onResume
 MainA1ctivity: onStop
複製代碼

異常狀態下的生命週期：安全

資源相關的系統配置發生改變或者資源不足：例如屏幕旋轉，當前Activity會銷燬，而且在onStop以前回調onSaveInstanceState保存數據，在從新建立Activity的時候在onStart以後回調onRestoreInstanceState。其中Bundle數據會傳到onCreate（不必定有數據）和onRestoreInstanceState（必定有數據）。性能優化

防止屏幕旋轉的時候重建，在清單文件中添加配置：
    android:configChanges="orientation"
複製代碼

二、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
複製代碼

三、Activity的啓動模式

standard：每次激活Activity時(startActivity)，都建立Activity實例，並放入任務棧；
singleTop：若是某個Activity本身激活本身，即任務棧棧頂就是該Activity，則不須要建立，其他狀況都要建立Activity實例；
singleTask：若是要激活的那個Activity在任務棧中存在該實例，則不須要建立，只須要把此Activity放入棧頂，即把該Activity以上的Activity實例都pop，並調用其onNewIntent；
singleInstance：應用1的任務棧中建立了MainActivity實例，若是應用2也要激活MainActivity，則不須要建立，兩應用共享該Activity實例。

四、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);
 }
複製代碼

五、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在清單文件中指定了在其餘進程中運行。

六、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。

七、事件傳遞機制以及自定義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必須實現的方法。

八、性能優化

佈局優化

使用include標籤，經過layout屬性複用相同的佈局。

<include
     android:id="@+id/v_test"
     layout="@layout/include_view" />
複製代碼

使用merge標籤，去除同類的視圖

使用ViewStub來進行佈局的延遲加載一些不是立刻就用到的佈局。例如列表頁中，列表在沒有拿到數據以前不加載，這樣作可使UI變得流暢。

<ViewStub
     android:id="@+id/v_stub"
     android:layout_width="match_parent"
     android:layout_height="wrap_content"
     android:layout="@layout/view_stub" />

 //須要手動調用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<Context> mContextRef
複製代碼

線程致使內存溢出：線程產生內存泄露的主要緣由在於線程生命週期的不可控。例如Activity中的Thread在run了，可是Activity因爲某種緣由從新建立了，可是Thread仍然會運行，由於run方法不結束的話Thread是不會銷燬的。
```
解決方案
 1. 將線程的內部類，改成靜態內部類（由於非靜態內部類擁有外部類對象的強引用，而靜態類則不擁有）。
 2. 在線程內部採用弱引用保存Context 引用。
複製代碼
```

查看內存泄漏的方法、工具

android官方提供的工具：Memory Monitor（當APP佔用的內存在短期內快速增加或者GC變得頻繁的時候）、DDMS提供的Heap工具（手動觸發GC）
Square提供的內存泄漏檢測工具，LeakCanary（可以自動完成內存追蹤、檢測、輸出結果），進行演示，而且適當的解說。

性能優化

防止過分繪製，經過打開手機的「顯示過分繪製區域」便可查看過分繪製的狀況。
最小化渲染時間，使用視圖樹查看節點，對節點進行性能分析。
經過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圖）、SVG圖片

####九切圖點九圖，是Android開發中用到的一種特殊格式的圖片，文件名以」.9.png「結尾。這種圖片能告訴程序，圖像哪一部分能夠被拉昇，哪一部分不能被拉昇須要保持原有比列。運用點九圖能夠保證圖片在不模糊變形的前提下作到自適應。點九圖經常使用於對話框背景圖片中。

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

android5.0的SCG矢量動畫機制

圖像在方法縮小的時候圖片質量不會有損失
使用XML來定義圖形
適配不一樣分辨率

十、Android中數據常見存儲方式

文件（包括XML、SharePreference等）
數據庫
Content Provider
保存在網絡

十一、進程間通訊

操做系統進程間通訊的方法，android中有哪些？

操做系統：

Windows：剪貼板、管道、郵槽等
Linux：命名管道、共享內存、信號量

Android中的進程通訊方式並非徹底繼承於Linux：

Bundle
文件共享
AIDL
Messenger
Content Provider
Socket

十二、常見的網絡框架

經常使用的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

1三、經常使用的圖片加載框架以及特色、源碼

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 又會被放回到原來的位置。若是一個被抽取的圖片須要再繪製一次，系統僅僅須要把它再解碼一次，這個操做很是迅速。

1四、在Android開發裏用什麼作線程間的通信工具？

傳統點的方法就是往同步代碼塊裏些數據，而後使用回調讓另一條線程去讀。在Android裏我通常會建立Looper線程，而後Hanlder傳遞消息。

###1五、Android新特性相關

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

1六、網絡請求優化

####網絡請求優化

可以緩存起來的儘可能去緩存起來，減輕服務器的壓力。例如APP中首頁的一些數據，又例如首頁的圖標、文案都是緩存起來的，並且這些數據經過網絡來指定可使app具備更大的靈活性。
不用域名，用 IP 直連，省去了DNS域名解析。
鏈接複用、請求合併、請求數據Body能夠利用壓縮算法Gzip來進行壓縮，使用JSON 代替 XML