Android中的四大組件以及應用場景
Activity：在Android應用中負責與用戶交互的組件。Service：常用於為其他組件提供後臺服務或者監控其他組件的運行狀態。經常用來執行一些耗時操作。BroadcastReceiver：用於監聽應用程序中的其他組件。ContentProvider：Android應用程序之間實現實時數據交換。1、Activity的生命週期
生命週期：對象什麼時候生，什麼時候死，怎麼寫代碼，代碼往那裡寫。
注意：
當打開新的Activity，採用透明主題的時候，當前Activity不會回調onStoponCreate和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方法去請求父元素不要攔截。注意
自定義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設計以及代碼編寫階段都應該考慮內存優化：
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通知你。
什麼情況會導致內存洩漏
解決方案 1\. 應該儘量避免static 成員變量引用資源耗費過多的實例，比如Context。 2\. Context 儘量使用ApplicationContext，因為Application 的Context 的生命週期比較長，引用它不會出現內存洩露的問題。 3\. 使用WeakReference 代替強引用。比如可以使用WeakReference 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一般有三種類型：
解決方案： 1\. UI線程只進行UI相關的操作。所有耗時操作，比如訪問網絡，Socket 通信，查詢大量SQL 語句，複雜邏輯計算等都放在子線程中去，然後通過handler.sendMessage、runonUITread、AsyncTask 等方式更新UI。 2\. 無論如何都要確保用戶界面操作的流暢度。如果耗時操作需要讓用戶等待，那麼可以在界面上顯示進度條。 3\. BroadCastReceiver要進行復雜操作的的時候，可以在onReceive()方法中啟動一個Service來處理。
9、九切圖（.9圖）、SVG圖片
九切圖
點九圖，是Android開發中用到的一種特殊格式的圖片，文件名以”.9.png“結尾。這種圖片能告訴程序，圖像哪一部分可以被拉昇，哪一部分不能被拉昇需要保持原有比列。運用點九圖可以保證圖片在不模糊變形的前提下做到自適應。點九圖常用於對話框背景圖片中。
android5.0的SCG矢量動畫機制
圖像在方法縮小的時候圖片質量不會有損失使用XML來定義圖形適配不同分辨率10、Android中數據常見存儲方式
文件（包括XML、SharePreference等）數據庫Content Provider保存在網絡11、進程間通信
操作系統進程間通信的方法，android中有哪些？
操作系統：
Windows：剪貼板、管道、郵槽等Linux：命名管道、共享內存、信號量Android中的進程通信方式並不是完全繼承於Linux：
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地址，減少了代碼量。AsyncTask13、常用的圖片加載框架以及特點、源碼
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來實現的。
文末
好了，今天的分享就到這裡，如果你對在面試中遇到的問題，或者剛畢業及工作幾年迷茫不知道該如何準備面試並突破現狀提升自己，對於自己的未來還不夠了解不知道給如何規劃，來看看同行們都是如何突破現狀，怎麼學習的，來吸收他們的面試以及工作經驗完善自己的之後的面試計劃及職業規劃。
這裡放上一部分我工作以來以及參與過的大大小小的面試收集總結出來的一套進階學習的視頻及面試專題資料包，在這裡[免費分享]給大家，主要還是希望大家在如今大環境不好的情況下面試能夠順利一點，希望可以幫助到大家~
image.png
資料免費領取方式：轉發後關注我後臺私信關鍵詞【資料】獲取！
轉發+點贊+關注，第一時間獲取最新知識點
Android架構師之路很漫長，一起共勉吧！