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

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

1、Activity的生命周期

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

注意：

1. 當打開新的Activity，采用透明主題的時候，當前Activity不會回調onStop
2. onCreate和onDestroy配對，onStart和onStop配對（是否可見），onResume和onPause配對（是否在前臺，可以與用戶交互）
3. 打開新的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的啟動模式

1. standard：每次激活Activity時(startActivity)，都創建Activity實例，并放入任務棧；
2. singleTop：如果某個Activity自己激活自己，即任務棧棧頂就是該Activity，則不需要創建，其余情況都要創建Activity實例；
3. singleTask：如果要激活的那個Activity在任務棧中存在該實例，則不需要創建，只需要把此Activity放入棧頂，即把該Activity以上的Activity實例都pop，并調用其onNewIntent；
4. singleInstance：應用1的任務棧中創建了MainActivity實例，如果應用2也要激活MainActivity，則不需要創建，兩應用共享該Activity實例。

4、Activity與Fragment之間的傳值

1. 通過findFragmentByTag或者getActivity獲得對方的引用（強轉）之后，再相互調用對方的public方法，但是這樣做一是引入了“強轉”的丑陋代碼，另外兩個類之間各自持有對方的強引用，耦合較大，容易造成內存泄漏。
2. 通過Bundle的方法進行傳值，例如以下代碼：

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

      3. 利用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分為兩種：

1. 本地服務，屬于同一個應用程序，通過startService來啟動或者通過bindService來綁定并且獲取代理對象。如果只是想開個服務在后臺運行的話，直接startService即可，如果需要相互之間進行傳值或者操作的話，就應該通過bindService。
2. 遠程服務（不同應用程序之間），通過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不通過鎖的機制來處理這個問題是因為：

1. 引入鎖會導致UI的操作變得復雜
2. 引入鎖會導致UI的運行效率降低

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

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

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

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

1. MessageQueue是傳送帶，負責Message隊列的傳送與管理
2. Looper是流水線的發動機，不斷地把消息從消息隊列里面取出來，交給Handler來處理
3. Message是每一件產品
4. 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，如果沒有任何視圖消耗事件的話，事件會順著路徑往回傳遞。其中：

1. dispatchTouchEvent是事件的分發方法，如果事件能夠到達該視圖的話，就首先一定會調用，一般我們不會去修改這個方法。
2. onInterceptTouchEvent是事件分發的核心方法，表示ViewGroup是否攔截事件，如果返回true表示攔截，在這之后ViewGroup的onTouchEvent會被調用，事件就不會往下傳遞。
3. onTouchEvent是***級的，在事件分發中***被調用。
4. 子View可以通過requestDisallowInterceptTouchEvent方法去請求父元素不要攔截。

注意

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

自定義View的分類

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

View的測量-onMeasure

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

MeasureSpec的三種模式：

1. EXACTLY模式：精確模式，對應于用戶指定為match_parent或者具體大小的時候（實際上指定為match_parent實質上是指定大小為父容器的大小）
2. AT_MOST模式：對應于用戶指定為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); 
     
            //根據模式去返回大小 
            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、性能優化

布局優化

    1. 使用include標簽，通過layout屬性復用相同的布局。 

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

 

    2. 使用merge標簽，去除同類的視圖

    3. 使用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); 

 

   4. 盡量多使用RelativeLayout，因為這樣可以大大減少視圖的層級。

內存優化

APP設計以及代碼編寫階段都應該考慮內存優化：

    1. 珍惜Service，盡量使得Service在使用的時候才處于運行狀態。盡量使用IntentService

        IntentService在內部其實是通過線程以及Handler實現的，當有新的Intent到來的時候，會創建線程并且處理這個Intent，處理完畢以后就自動銷毀自身。因此使用IntentService能夠節省系統資源。

    2. 內存緊張的時候釋放資源（例如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 其他: 
 
     } 
 
 } 

 

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

android:largeHeap="true" 

    4. 避免Bitmap的浪費，應該盡量去適配屏幕設備。盡量使用成熟的圖片加載框架，Picasso，Fresco，Glide等。

    5. 使用優化的容器，SparseArray等

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

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

 分析方法

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

 2. 使用DDMS提供的Heap工具查看內存使用情況，也可以手動觸發GC。

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

什么情況會導致內存泄漏

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

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

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

 解決方案

 1. 應該盡量避免static 成員變量引用資源耗費過多的實例，比如Context。

 2. Context 盡量使用ApplicationContext，因為Application 的Context 的生命周期比較長，引用它不會出現內存泄露的問題。

 3. 使用WeakReference 代替強引用。比如可以使用WeakReference<Context> mContextRef

    4. 線程導致內存溢出：線程產生內存泄露的主要原因在于線程生命周期的不可控。例如Activity中的Thread在run了，但是Activity由于某種原因重新創建了，但是Thread仍然會運行，因為run方法不結束的話Thread是不會銷毀的。

 解決方案

 1. 將線程的內部類，改為靜態內部類（因為非靜態內部類擁有外部類對象的強引用，而靜態類則不擁有）。

 2. 在線程內部采用弱引用保存Context 引用。

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

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

性能優化

1. 防止過度繪制，通過打開手機的“顯示過度繪制區域”即可查看過度繪制的情況。
2. 最小化渲染時間，使用視圖樹查看節點，對節點進行性能分析。
3. 通過TraceView進行數據的采集以及分析。在有大概定位的時候，使用Android官方提供的Debug類進行采集。***通過DDMS即可打開這個.trace文件，分析函數的調用情況（包括在指定情況下執行時間，調用次數） 

//開啟數據采集 
 
 Debug.startMethodTracing("test.trace"); 
 
 //關閉 
 
 Debug.stopMethodTracing(); 

OOM

避免OOM的一些常見方法：

    1. 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(); 

 

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

    3. IO流，數據庫查詢的游標等應該在使用完之后及時關閉。

    4. ListView中應該使用ViewHolder模式緩存ConverView

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

ANR

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

ANR一般有三種類型：

    1. KeyDispatchTimeout(5 seconds)

主要類型按鍵或觸摸事件在特定時間內無響應

    2. BroadcastTimeout(10 seconds)

BroadcastReceiver在特定時間內無法處理完成

    3. ServiceTimeout(20 seconds)

小概率類型Service在特定的時間內無法處理完成

解決方案：

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

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

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

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

九切圖

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

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

android5.0的SCG矢量動畫機制

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

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

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

11、進程間通信

1. 操作系統進程間通信的方法，android中有哪些？
2. 操作系統：
3. Windows：剪貼板、管道、郵槽等
4. Linux：命名管道、共享內存、信號量

Android中的進程通信方式并不是完全繼承于Linux：

1. Bundle
2. 文件共享
3. AIDL
4. Messenger
5. Content Provider
6. Socket

12、常見的網絡框架

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

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

13、常用的圖片加載框架以及特點、源碼

1. Picasso：PicassoSquare的網絡庫一起能發揮***作用，因為Picasso可以選擇將網絡請求的緩存部分交給了okhttp實現。
2. Glide：模仿了Picasso的API，而且在他的基礎上加了很多的擴展(比如gif等支持)，支持圖片流，因此在做愛拍之類的視頻應用用得比較多一些。
3. Fresco：Fresco中設計有一個叫做image pipeline的模塊。它負責從網絡，從本地文件系統，本地資源加載圖片。 為了***限度節省空間和CPU時間，它含有3級緩存設計（2級內存，1級文件）。Fresco中設計有一個叫做Drawees模塊， 方便地顯示loading圖，當圖片不再顯示在屏幕上時，及時地釋放內存和空間占用。

Fresco是把圖片緩存放在了Ashmem（系統匿名內存共享區）

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

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

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

傳統點的方法就是往同步代碼塊里些數據，然后使用回調讓另外一條線程去讀。在Android里我一般會創建Looper線程，然后Hanlder傳遞消息。

1***ndroid新特性相關

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

16、網絡請求優化

網絡請求優化

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

網絡請求的安全性

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

17、新技術相關

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

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