每日更新每日學(xué)習(xí)面試筆記，來(lái)自https://github.com/Moosphan/Android-Daily-Interview/

• 1、自定義 Handler 時(shí)如何有效地避免內(nèi)存泄漏問(wèn)題？
  問(wèn)題原因：一般非靜態(tài)內(nèi)部類持有外部類的引用的情況下，造成外部類在使用完成后不能被系統(tǒng)回收內(nèi)存，從而造成內(nèi)存泄漏。這里 Handler 持有外部類 Activity 的引用，一旦 Activity 被銷毀，而此時(shí) Handler 依然持有 Activity 引用，就會(huì)造成內(nèi)存泄漏。

解決方案：將 Handler 以靜態(tài)內(nèi)部類的形式聲明，然后通過(guò)弱引用的方式讓 Handler 持有外部類 Activity 的引用，這樣就可以避免內(nèi)存泄漏問(wèn)題了：
1.自定義的靜態(tài)handler
2.可以加一個(gè)弱引用
3.還有一個(gè)主意的就是當(dāng)你activity被銷毀的時(shí)候如果還有消息沒(méi)有發(fā)出去 就remove掉吧
4.removecallbacksandmessages去清除Message和Runnable 加null 寫(xiě)在生命周的ondestroy()就行

private WeakHandler weakHandler;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);ButterKnife.bind(this);weakHandler = new WeakHandler(this);}static class WeakHandler extends Handler {private final WeakReference<MainActivity> mActivity;WeakHandler(MainActivity activity) {mActivity = new WeakReference<>(activity); // 弱引用}@Overridepublic void handleMessage(Message msg) {super.handleMessage(msg);MainActivity activity = mActivity.get();switch (msg.what) {case 1:if (activity != null) {activity.btnDemoOne.setText("ceshi");}break;default:break;}}}@Overrideprotected void onDestroy() {super.onDestroy();weakHandler.removeCallbacksAndMessages(null);}

• 2、Activity 與 Fragment 之間常見(jiàn)的幾種通信方式？

通常，Fragment 與 Activity 通信存在三種情形：

• Activity 操作內(nèi)嵌的 Fragment
• Fragment 操作宿主 Activity
• Fragment 操作同屬 Activity中的其他 Fragment

在Android中我們可以通過(guò)以下幾種方式優(yōu)雅地實(shí)現(xiàn)Activity和fragment之間的通信：

• Handler
• 廣播
• EventBus
• 接口回調(diào)
  見(jiàn)Activity 與 Fragment 之間的通信
  - 3、一般什么情況下會(huì)導(dǎo)致內(nèi)存泄漏問(wèn)題？
• 內(nèi)部類&匿名內(nèi)部類實(shí)例無(wú)法釋放（有延遲時(shí)間等等），而內(nèi)部類又持有外部類的強(qiáng)引用，導(dǎo)致外部類無(wú)法釋放，這種匿名內(nèi)部類常見(jiàn)于監(jiān)聽(tīng)器、Handler、Thread、TimerTask
• 持有靜態(tài)的Context（Avtivity）和View
• 資源使用完成后沒(méi)有關(guān)閉File，Cursor，Stream，Bitmap（調(diào)用recycle（））等相關(guān)流的操作
• 接收器、監(jiān)聽(tīng)器注冊(cè)沒(méi)取消，BraodcastReceiver，ContentObserver
• 集合類內(nèi)存泄漏，如果一個(gè)集合類是靜態(tài)的（緩存HashMap），只有添加方法，沒(méi)有對(duì)應(yīng)的刪除方法，會(huì)導(dǎo)致引用無(wú)法被釋放，引發(fā)內(nèi)存泄漏。

順便說(shuō)一下內(nèi)存泄漏和內(nèi)存溢出的區(qū)別

• 內(nèi)存溢出（Out of memory）:系統(tǒng)會(huì)給每個(gè)APP分配內(nèi)存也就是Heap size值，當(dāng)APP所需要的內(nèi)存大于了系統(tǒng)分配的內(nèi)存，就會(huì)造成內(nèi)存溢出；通俗點(diǎn)就是10L桶只能裝10L水，但是你卻用來(lái)裝11L的水，那就有1L的水就會(huì)溢出
• 內(nèi)存泄漏（Memory leak）:當(dāng)一個(gè)對(duì)象不在使用了，本應(yīng)該被垃圾回收器（JVM）回收，但是這個(gè)對(duì)象由于被其他正在使用的對(duì)象所持有，造成無(wú)法被回收的結(jié)果，通俗點(diǎn)就是系統(tǒng)把一定的內(nèi)存值A(chǔ)借給程序，但是系統(tǒng)卻收不回完整的A值，那就是內(nèi)存泄漏
  - 4、LaunchMode 的應(yīng)用場(chǎng)景？
  LaunchMode 有四種，分別為 Standard，SingleTop，SingleTask 和 SingleInstance，每種模式的實(shí)現(xiàn)原理
• android:launchMode="standard"可以存在多個(gè)實(shí)例，這是默認(rèn)的啟動(dòng)模式，系統(tǒng)總是會(huì)在目標(biāo)棧中創(chuàng)建新的activity實(shí)例。Standard 模式是系統(tǒng)默認(rèn)的啟動(dòng)模式，一般我們 app 中大部分頁(yè)面都是由該模式的頁(yè)面構(gòu)成的，比較常見(jiàn)的場(chǎng)景是：社交應(yīng)用中，點(diǎn)擊查看用戶A信息->查看用戶A粉絲->在粉絲中挑選查看用戶B信息->查看用戶A粉絲… 這種情況下一般我們需要保留用戶操作 Activity 棧的頁(yè)面所有執(zhí)行順序。
• android:launchMode=“singleTop” 如果這個(gè) activity 實(shí)例已經(jīng)存在目標(biāo)棧的棧頂，系統(tǒng)會(huì)調(diào)用這個(gè) activity 中的 onNewIntent() 方法，并傳遞 intent，而不會(huì)創(chuàng)建新的 activity 實(shí)例；如果不存在這個(gè) activity 實(shí)例或者 activity 實(shí)例不在棧頂，則 SingleTop 和Standard 作用是一樣的。SingleTop 模式一般常見(jiàn)于社交應(yīng)用中的通知欄行為功能，例如：App 用戶收到幾條好友請(qǐng)求的推送消息，需要用戶點(diǎn)擊推送通知進(jìn)入到請(qǐng)求者個(gè)人信息頁(yè)，將信息頁(yè)設(shè)置為 SingleTop 模式就可以增強(qiáng)復(fù)用性。
• android:launchMode=“singleTask” 不會(huì)存在多個(gè)實(shí)例，如果棧中不存在 activity 實(shí)例，系統(tǒng)會(huì)在新棧的根部創(chuàng)建一個(gè)新的 activity；如果這個(gè) activity 實(shí)例已經(jīng)存在，系統(tǒng)會(huì)調(diào)用這個(gè) activity的 onNewIntent() 方法而不會(huì)創(chuàng)建新的 activity 實(shí)例。SingleTask 模式一般用作應(yīng)用的首頁(yè)，例如瀏覽器主頁(yè)，用戶可能從多個(gè)應(yīng)用啟動(dòng)瀏覽器，但主界面僅僅啟動(dòng)一次，其余情況都會(huì)走onNewIntent，并且會(huì)清空主界面上面的其他頁(yè)面。
• android:launchMode=“singleInstance” 這種啟動(dòng)模式比較特殊，因?yàn)樗鼤?huì)啟用一個(gè)新的棧結(jié)構(gòu)，將 Acitvity 放置于這個(gè)新的棧結(jié)構(gòu)中，并保證不再有其他 Activity 實(shí)例進(jìn)入，除此之外，SingleInstance模式和 SingleTask 模式是一樣的。SingleInstance 模式常應(yīng)用于獨(dú)立棧操作的應(yīng)用，如鬧鐘的提醒頁(yè)面，當(dāng)你在A應(yīng)用中看視頻時(shí)，鬧鐘響了，你點(diǎn)擊鬧鐘提醒通知后進(jìn)入提醒詳情頁(yè)面，然后點(diǎn)擊返回就再次回到A的視頻頁(yè)面，這樣就不會(huì)過(guò)多干擾到用戶先前的操作了。
• 5、如何實(shí)現(xiàn)多線程中的同步？
  線程間的同步問(wèn)題一般借助于同步鎖 Synchronized 和 volatile 關(guān)鍵字實(shí)現(xiàn):

public class Singleton{private volatile static Singleton mSingleton;private Singleton(){}public static Singleton getInstance(){if(mSingleton == null){synchronized(Singleton.class){if(mSingleton == null)mSingleton = new Singleton();}}return mSingleton;} }

• 6、Android 補(bǔ)間動(dòng)畫(huà)和屬性動(dòng)畫(huà)的區(qū)別？

• 補(bǔ)間動(dòng)畫(huà)
  補(bǔ)間動(dòng)畫(huà)，主要是向View對(duì)象設(shè)置動(dòng)畫(huà)效果，包括AlphaAnimation 、RotateAnimation 、ScaleAnimation 、TranslateAnimation 這4種效果，對(duì)應(yīng)的xml標(biāo)簽分別是alpha、rotate、scale、translate。通過(guò)為動(dòng)畫(huà)設(shè)置初始和終止對(duì)應(yīng)的值，根據(jù)插值器和duration計(jì)算動(dòng)畫(huà)過(guò)程中間相應(yīng)的值實(shí)現(xiàn)平滑運(yùn)動(dòng)，即設(shè)置初始和終止?fàn)顟B(tài)，插值器來(lái)計(jì)算填補(bǔ)初始狀態(tài)到終止?fàn)顟B(tài)間的動(dòng)畫(huà)

• 屬性動(dòng)畫(huà)
  屬性動(dòng)畫(huà)可以對(duì)任何對(duì)象的屬性做動(dòng)畫(huà)而不僅僅是View，甚至可以沒(méi)有對(duì)象。除了作用對(duì)象進(jìn)行擴(kuò)展外，屬性動(dòng)畫(huà)的效果也加強(qiáng)了，不僅能實(shí)現(xiàn)View動(dòng)畫(huà)的4中效果，還能實(shí)現(xiàn)其它多種效果，這些效果都是通過(guò)ValuAnimator或ObjectAnimator、AnimatorSet等來(lái)實(shí)現(xiàn)的。

• 7、ANR出現(xiàn)的場(chǎng)景及解決方案？
  在Android中，應(yīng)用的響應(yīng)性被活動(dòng)管理器（Activity Manager）和窗口管理器（Window Manager）這兩個(gè)系統(tǒng)服務(wù)所監(jiān)視。當(dāng)用戶觸發(fā)了輸入事件（如鍵盤(pán)輸入，點(diǎn)擊按鈕等）,如果應(yīng)用5秒內(nèi)沒(méi)有響應(yīng)用戶的輸入事件，那么，Android會(huì)認(rèn)為該應(yīng)用無(wú)響應(yīng)，便彈出ANR對(duì)話框。而彈出ANR異常，也主要是為了提升用戶體驗(yàn)。
  解決方案是對(duì)于耗時(shí)的操作，比如訪問(wèn)網(wǎng)絡(luò)、訪問(wèn)數(shù)據(jù)庫(kù)等操作，需要開(kāi)辟子線程，在子線程處理耗時(shí)的操作，主線程主要實(shí)現(xiàn)UI的操作

• 8、談?wù)?Handler 機(jī)制和原理？
  首先在UI線程我們創(chuàng)建了一個(gè)Handler實(shí)例對(duì)象，無(wú)論是匿名內(nèi)部類還是自定義類生成的Handler實(shí)例對(duì)象，我們都需要對(duì)handleMessage方法進(jìn)行重寫(xiě)，在handleMessage方法中我們可以通過(guò)參數(shù)msg來(lái)寫(xiě)接受消息過(guò)后UIi線程的邏輯處理，接著我們創(chuàng)建子線程，在子線程中需要更新UI的時(shí)候，新建一個(gè)Message對(duì)象，并且將消息的數(shù)據(jù)記錄在這個(gè)消息對(duì)象Message的內(nèi)部，比如arg1,arg2,obj等，然后通過(guò)前面的Handler實(shí)例對(duì)象調(diào)用sendMessge方法把這個(gè)Message實(shí)例對(duì)象發(fā)送出去，之后這個(gè)消息會(huì)被存放于MessageQueue中等待被處理，此時(shí)MessageQueue的管家Looper正在不停的把MessageQueue存在的消息取出來(lái)，通過(guò)回調(diào)dispatchMessage方法將消息傳遞給Handler的handleMessage方法，最終前面提到的消息會(huì)被Looper從MessageQueue中取出來(lái)傳遞給handleMessage方法。
  問(wèn)題擴(kuò)展
  A. messageQueue.next 是阻塞式的取消息, 如果有 delay 會(huì)調(diào)用 nativeWake;
  那么問(wèn)題來(lái)了, 線程掛起了, 是掛起的 UI線程嗎? 答案是 YES, 為什么我沒(méi)有察覺(jué)呢?
  還有就是 nativeWake 和 nativePollOnce 的實(shí)現(xiàn)原理;

B. looper.loop 既然是 while-true 為什么不會(huì)卡死?

C. MessageQueue 是隊(duì)列嗎? 他是什么數(shù)據(jù)結(jié)構(gòu)呢?

D. handler 的postDelay, 時(shí)間準(zhǔn)嗎? 答案是不準(zhǔn), 為什么呢?

E. handler 的 postDelay 的時(shí)間是 system.currentTime 嗎? 答案是 NO, 你知道是什么嗎?

F. 子線程run方法使用 handler 要先 looper.prepare(); 再 handler.post; 再 looper.loop();
那么問(wèn)題來(lái)了, looper.loop(); 之后 在 handler.post 消息, 還能收到嗎? 答案是 NO, 為什么?

G. handler 這么做到的 一個(gè)線程對(duì)應(yīng)一個(gè) looper, 答案是threadLocal, 你對(duì)ThreadLocal 有什么了解嗎?

H. 假設(shè)先 postDelay 10ms, 再postDelay 1ms, 你簡(jiǎn)單描述一下, 怎么處理這2條消息?

I. 你知道主線程的Looper, 第一次被調(diào)用loop方法, 在什么時(shí)候嗎? 哪一個(gè)類

J. 你對(duì) IdleHandler 有多少了解?

K. 你了解 HandlerThread 嗎?

L. 你對(duì) Message.obtain() 了解嗎, 或者你知道 怎么維護(hù)消息池嗎；

• 9、什么是Sticky事件？
  在Android開(kāi)發(fā)中，Sticky事件只指事件消費(fèi)者在事件發(fā)布之后才注冊(cè)的也能接收到該事件的特殊類型。Android中就有這樣的實(shí)例，也就是Sticky Broadcast，即粘性廣播。正常情況下如果發(fā)送者發(fā)送了某個(gè)廣播，而接收者在這個(gè)廣播發(fā)送后才注冊(cè)自己的Receiver，這時(shí)接收者便無(wú)法接收到剛才的廣播，為此Android引入了StickyBroadcast，在廣播發(fā)送結(jié)束后會(huì)保存剛剛發(fā)送的廣播（Intent），這樣當(dāng)接收者注冊(cè)完Receiver后就可以接收到剛才已經(jīng)發(fā)布的廣播。這就使得我們可以預(yù)先處理一些事件，讓有消費(fèi)者時(shí)再把這些事件投遞給消費(fèi)者。
• 10、抽象類與接口的區(qū)別？
  1.抽象類是用來(lái)捕捉子類的通用特性的 。它不能被實(shí)例化，只能被用作子類的超類。抽象類是被用來(lái)創(chuàng)建繼承層級(jí)里子類的模板。
  2.接口是抽象方法的集合。如果一個(gè)類實(shí)現(xiàn)了某個(gè)接口，那么它就繼承了這個(gè)接口的抽象方法。這就像契約模式，如果實(shí)現(xiàn)了這個(gè)接口，那么就必須確保使用這些方法。接口只是一種形式，接口自身不能做任何事情。
  大體區(qū)別如下：
• 抽象類可以提供成員方法的實(shí)現(xiàn)細(xì)節(jié)，而接口中只能存在 public 抽象方法；
• 抽象類中的成員變量可以是各種類型的，而接口中的成員變量只能是 public static final 類型的；
• 接口中不能含有構(gòu)造器、靜態(tài)代碼塊以及靜態(tài)方法，而抽象類可以有構(gòu)造器、靜態(tài)代碼塊和靜態(tài)方法；
• 一個(gè)類只能繼承一個(gè)抽象類，而一個(gè)類卻可以實(shí)現(xiàn)多個(gè)接口；
• 抽象類訪問(wèn)速度比接口速度要快，因?yàn)榻涌谛枰獣r(shí)間去尋找在類中具體實(shí)現(xiàn)的方法；
• 如果你往抽象類中添加新的方法，你可以給它提供默認(rèn)的實(shí)現(xiàn)。因此你不需要改變你現(xiàn)在的代碼。如果你往接口中添加方法，那么你必須改變實(shí)現(xiàn)該接口的類。
  補(bǔ)充詳細(xì)見(jiàn)抽象類與接口的區(qū)別
• 11、BroadcastReceiver 與 LocalBroadcastReceiver 有什么區(qū)別？
• BroadcastReceiver 是跨應(yīng)用廣播，利用Binder機(jī)制實(shí)現(xiàn)，支持動(dòng)態(tài)和靜態(tài)兩種方式注冊(cè)方式。
• LocalBroadcastReceiver是應(yīng)用內(nèi)廣播，利用Handler實(shí)現(xiàn)，利用了IntentFilter的match功能，提供消息的發(fā)布與接收功能，實(shí)現(xiàn)應(yīng)用內(nèi)通信，效率和安全性比較高，僅支持動(dòng)態(tài)注冊(cè)。

/*** 自定義廣播*/ public static final String LOGIN_ACTION = "com.archie.action.LOGIN_ACTION"; //廣播接收器private LoginBroadcastReceiver mReceiver = new LoginBroadcastReceiver();//注冊(cè)廣播方法private void registerLoginBroadcast(){IntentFilter intentFilter = new IntentFilter(LoginActivity.LOGIN_ACTION);LocalBroadcastManager.getInstance(mContext).registerReceiver(mReceiver,intentFilter);}//取消注冊(cè)private void unRegisterLoginBroadcast(){LocalBroadcastManager.getInstance(mContext).unregisterReceiver(mReceiver);} /*** 自定義廣播接受器,用來(lái)處理登錄廣播*/private class LoginBroadcastReceiver extends BroadcastReceiver{@Overridepublic void onReceive(Context context, Intent intent) {//處理我們具體的邏輯,更新UI}}/*** 發(fā)送我們的局部廣播*/private void sendBroadcast(){LocalBroadcastManager.getInstance(this).sendBroadcast(new Intent(LOGIN_ACTION));}

小結(jié)：
1、LocalBroadcastManager在創(chuàng)建單例傳參時(shí)，不用糾結(jié)context是取activity的還是Application的，它自己會(huì)取到tApplicationContext。
2、LocalBroadcastManager只適用于代碼間的，因?yàn)樗褪潜４娼涌贐roadcastReceiver的對(duì)象，然后直接調(diào)用其onReceive方法。
3、LocalBroadcastManager注冊(cè)廣播后，當(dāng)該其Activity或者Fragment不需要監(jiān)聽(tīng)時(shí)，記得要取消注冊(cè)，注意一點(diǎn)：注冊(cè)與取消注冊(cè)在activity或者fragment的生命周期中要保持一致，例如onResume，onPause。
4、LocalBroadcastManager雖然 支持對(duì)同一個(gè)BroadcastReceiver可以注冊(cè)多個(gè)IntentFilter，但還是應(yīng)該將所需要的action都放進(jìn)一個(gè) IntentFilter，即只注冊(cè)一個(gè)IntentFilter，這只是我個(gè)人的建議。
5、LocalBroadcastManager所發(fā) 送的廣播action，只能與注冊(cè)到LocalBroadcastManager中BroadcastReceiver產(chǎn)生互動(dòng)。如果你遇到了通過(guò) LocalBroadcastManager發(fā)送的廣播，對(duì)面的BroadcastReceiver沒(méi)響應(yīng)，很可能就是這個(gè)原因造成的。

• 12、請(qǐng)簡(jiǎn)要談一談單例模式？
  單例分為懶漢模式和惡漢模式，主要是雙檢查、靜態(tài)內(nèi)部類、枚舉等
  懶漢模式有線程安全和非線程安全的區(qū)別
  實(shí)現(xiàn)線程安全的懶漢模式有多重 其中一種是加double check，一種是靜態(tài)內(nèi)部類

/*** 雙重檢查*/ public class SingletonDoubleCheck {private SingletonDoubleCheck() { }private static volatile SingletonDoubleCheck instance;//代碼1public static SingletonDoubleCheck getInc() {if (null == instance) {//代碼2synchronized (SingletonDoubleCheck.class) {if (null == instance) {//代碼3instance = new SingletonDoubleCheck();//代碼4}}}return instance;} }/*** 靜態(tài)內(nèi)部類實(shí)現(xiàn)單例* */ public class SingleDemo4 {private static SingleDemo4 instance;private static class SingleDemo4Holder {private static final SingleDemo4 instance = new SingleDemo4();}private SingleDemo4() {if (instance != null) {throw new RuntimeException();}}/*** 調(diào)用這個(gè)方法的時(shí)候，JVM才加載靜態(tài)內(nèi)部類，才初始化靜態(tài)內(nèi)部類的類變量。由于由JVM初始化，保證了線程安全性，* 同時(shí)又實(shí)現(xiàn)了懶加載* @return*/public static SingleDemo4 getInstance() {return SingleDemo4Holder.instance;} }

更多詳細(xì)單例見(jiàn)單例的五種實(shí)現(xiàn)方式，及其性能分析
在代碼 在多線程中 兩個(gè)線程可能同時(shí)進(jìn)入代碼2, synchronize保證只有一個(gè)線程能進(jìn)入下面的代碼,
此時(shí)一個(gè)線程A進(jìn)入一個(gè)線程B在外等待, 當(dāng)線程A完成代碼3 和代碼4之后,
線程B進(jìn)入synchronized下面的方法, 線程B在代碼3的時(shí)候判斷不過(guò),從而保證了多線程下 單例模式的線程安全,
另外要慎用單例模式,因?yàn)閱卫Ｊ揭坏┏跏蓟?只有進(jìn)程退出才有可能被回收,如果一個(gè)對(duì)象不經(jīng)常被使用,盡量不要使用單例,否則為了幾次使用,一直讓單例存在占用內(nèi)存。
接著上一篇Android 面試題筆記（一）

13、Window和DecorView是什么?DecorView又是如何和Window建立聯(lián)系的?
DecorView的作用
DecorView是頂級(jí)View，本質(zhì)就是一個(gè)FrameLayout
包含了兩個(gè)部分，標(biāo)題欄和內(nèi)容欄
內(nèi)容欄id是content，也就是activity中setContentView所設(shè)置的部分，最終將布局添加到id為content的FrameLayout中
獲取content：ViewGroup content = findViewById(R.android.id.content)
獲取設(shè)置的View：content.getChidlAt(0)
Window是什么？

表示一個(gè)窗口的概念，是所有View的直接管理者，任何視圖都通過(guò)Window呈現(xiàn)(單擊事件由Window->DecorView->View; Activity的setContentView底層通過(guò)Window完成)
Window是一個(gè)抽象類，具體實(shí)現(xiàn)是PhoneWindow
創(chuàng)建Window需要通過(guò)WindowManager創(chuàng)建
WindowManager是外界訪問(wèn)Window的入口
Window具體實(shí)現(xiàn)位于WindowManagerService中
WindowManager和WindowManagerService的交互是通過(guò)IPC完成
DecorView又是如何和Window建立聯(lián)系的?

在Activity的啟動(dòng)流程中，處理onResume()的相關(guān)方法中，將DecorView作為Window的成員變量保存到Window內(nèi)部
DecorView與Window建立聯(lián)系又有什么用呢?例如Activity的onSaveInstanceState()進(jìn)行數(shù)據(jù)保存時(shí)，就通過(guò)window內(nèi)部的DecorView觸發(fā)整個(gè)View樹(shù)進(jìn)行狀態(tài)保存
//ActivityThread.java
final void handleResumeActivity(IBinder token, …) {
//1. 創(chuàng)建DecorView，設(shè)置為不可見(jiàn)INVISIBLE
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
//2. 獲取到WindowManager, addView方法將DecorView添加到Window中
ViewManager wm = a.getWindowManager();
wm.addView(decor, l);
//3. 將DecorView設(shè)置為visible
r.activity.makeVisible();
}

• 14、對(duì)于 Context，你了解多少?
  Context 宏觀來(lái)說(shuō)是一個(gè)描述應(yīng)用程序全局信息的場(chǎng)景，當(dāng)然，本質(zhì)上來(lái)說(shuō)，這個(gè)“場(chǎng)景”其實(shí)是一個(gè)抽象類詳細(xì)見(jiàn)Android Context 上下文 你必須知道的一切
• 15、SharedPreferences 是線程安全的嗎？它的 commit 和 apply 方法有什么區(qū)別?
  SharedPreferences 是線程安全的 進(jìn)程不安全的， commit 是同步寫(xiě)入有返回值，apply是異步寫(xiě)入。
  apply沒(méi)有返回值而commit返回boolean表明修改是否提交成功
  apply是將修改數(shù)據(jù)原子提交到內(nèi)存, 而后異步真正提交到硬件磁盤(pán), 而commit是同步的提交到硬件磁盤(pán)，因此，在多個(gè)并發(fā)的提交commit的時(shí)候，他們會(huì)等待正在處理的commit保存到磁盤(pán)后在操作，從而降低了效率。而apply只是原子的提交到內(nèi)容，后面有調(diào)用apply的函數(shù)的將會(huì)直接覆蓋前面的內(nèi)存數(shù)據(jù)，這樣從一定程度上提高了很多效率。
  由于在一個(gè)進(jìn)程中，sharedPreference是單實(shí)例，一般不會(huì)出現(xiàn)并發(fā)沖突，如果對(duì)提交的結(jié)果不關(guān)心的話，建議使用apply，當(dāng)然需要確保提交成功且有后續(xù)操作的話，還是需要用commit的。
  - 16、HashMap 的實(shí)現(xiàn)原理？
• 數(shù)組：存儲(chǔ)區(qū)間連續(xù)，占用內(nèi)存嚴(yán)重，尋址容易，插入刪除困難；
• 鏈表：存儲(chǔ)區(qū)間離散，占用內(nèi)存比較寬松，尋址困難，插入刪除容易；
• Hashmap： 綜合應(yīng)用了這兩種數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)了尋址容易，插入刪除也容易。
  更多可參考以下文章：
  HashMap 原理以及源碼解析
  HashMap 碰撞問(wèn)題
  HashMap 中的負(fù)載因子
• 17、簡(jiǎn)述一下 Android 中 UI 的刷新機(jī)制？
  應(yīng)用層的：
• 界面刷新的本質(zhì)流程
  通過(guò)ViewRootImpl的scheduleTraversals()進(jìn)行界面的三大流程。
  調(diào)用到scheduleTraversals()時(shí)不會(huì)立即執(zhí)行，而是將該操作保存到待執(zhí)行隊(duì)列中。并給底層的刷新信號(hào)注冊(cè)監(jiān)聽(tīng)。
  當(dāng)VSYNC信號(hào)到來(lái)時(shí)，會(huì)從待執(zhí)行隊(duì)列中取出對(duì)應(yīng)的scheduleTraversals()操作，并將其加入到主線程的消息隊(duì)列中。
  主線程從消息隊(duì)列中取出并執(zhí)行三大流程: onMeasure()-onLayout()-onDraw()
• 同步屏障的作用
  同步屏障用于阻塞住所有的同步消息(底層VSYNC的回調(diào)onVsync方法提交的消息是異步消息)
  用于保證界面刷新功能的performTraversals()的優(yōu)先執(zhí)行。
• 同步屏障的原理？
  主線程的Looper會(huì)一直循環(huán)調(diào)用MessageQueue的next方法并且取出隊(duì)列頭部的Message執(zhí)行，遇到同步屏障(一種特殊消息)后會(huì)去尋找異步消息執(zhí)行。如果沒(méi)有找到異步消息就會(huì)一直阻塞下去，除非將同步屏障取出，否則永遠(yuǎn)不會(huì)執(zhí)行同步消息。
  界面刷新操作是異步消息，具有最高優(yōu)先級(jí)
  我們發(fā)送的消息是同步消息，再多耗時(shí)操作也不會(huì)影響UI的刷新操作

系統(tǒng)層的：
首先屏幕是 大約16.6ms刷新一次（固定的），當(dāng)界面需要改變時(shí)， CPU開(kāi)始計(jì)算，將計(jì)算結(jié)果 賦予 GPU 的buffer緩存起來(lái)，等待刷新時(shí)間的到來(lái)，然后根據(jù)buffer的數(shù)據(jù)刷新界面。如果當(dāng)前界面沒(méi)有變化，CPU不用計(jì)算，也不會(huì)給GPU的buffer賦值啥的，這個(gè)buffer也就沒(méi)變化，等到刷新時(shí)間的到來(lái)，會(huì)依舊根據(jù)buffer刷新屏幕
結(jié)論是：界面改不改變都會(huì)刷新界面，只是在于CPU是否計(jì)算這點(diǎn)區(qū)別
UI刷新卡頓，基本都在于卡在CPU計(jì)算這一環(huán)節(jié)，對(duì)于根據(jù)GPU 的buffer刷新這一環(huán)節(jié)，在系統(tǒng)里有很高的優(yōu)先級(jí)

• 18、Serializable和Parcelable的區(qū)別?
  Serializable是屬于Java自帶的，本質(zhì)是使用了反射。序列化的過(guò)程比較慢，這種機(jī)制在序列化的時(shí)候會(huì)創(chuàng)建很多臨時(shí)的對(duì)象，比引起頻繁的GC。Parcelable 是屬于 Android 專用。不過(guò)不同于Serializable，Parcelable實(shí)現(xiàn)的原理是將一個(gè)完整的對(duì)象進(jìn)行分解。而分解后的每一部分都是Intent所支持的數(shù)據(jù)類型。 如果在內(nèi)存中使用建議Parcelable。持久化操作建議Serializable；目前AS安裝android parcelable code generator插件可直接生成Parcelable
• 19、Android進(jìn)程間的通信方式
  1、Bundle的使用
  可以看到Bundle實(shí)現(xiàn)了Parcelable 接口。
  優(yōu)點(diǎn)：簡(jiǎn)單易用
  缺點(diǎn)：只能傳遞Bundle支持的數(shù)據(jù)類型
  使用場(chǎng)景：四大組件間的進(jìn)程通訊

2.文件共享
優(yōu)點(diǎn)：簡(jiǎn)單易用
缺點(diǎn)：不適合高并發(fā)的場(chǎng)景，不能做到即時(shí)通訊。
使用場(chǎng)景：無(wú)并發(fā)訪問(wèn)的情景，簡(jiǎn)單的交換數(shù)據(jù)，實(shí)時(shí)性要求不高。

3.AIDI
優(yōu)點(diǎn)：功能強(qiáng)大，支持一對(duì)多并發(fā)通信，支持實(shí)時(shí)通信。
缺點(diǎn)：一定要處理好線程同步的問(wèn)題
使用場(chǎng)景：一對(duì)多進(jìn)行通訊，有RPC（遠(yuǎn)程過(guò)程調(diào)用協(xié)議）的需求

4.Messenger(信使)
優(yōu)點(diǎn)：功能一般，支持一對(duì)多串行通信，支持實(shí)時(shí)通信。
缺點(diǎn)：不能很好的處理高并發(fā)場(chǎng)景，不支持RPC，數(shù)據(jù)通過(guò)Message進(jìn)行傳輸，因此只能支持Bundle支持的數(shù)據(jù)類型。
使用場(chǎng)景：低并發(fā)的一對(duì)多的實(shí)時(shí)通訊，沒(méi)有RPC的需求或者說(shuō)沒(méi)有返回結(jié)果的RPC（不調(diào)用服務(wù)端的相關(guān)方法）

5.ContentProvider
優(yōu)點(diǎn)：主要用于數(shù)據(jù)訪問(wèn)，支持一對(duì)多的并發(fā)數(shù)據(jù)共享。
缺點(diǎn)：受約束，主要針對(duì)數(shù)據(jù)源的增刪改查。
使用場(chǎng)景：一對(duì)多的數(shù)據(jù)共享。

6.Socket(套接字)
優(yōu)點(diǎn)：功能強(qiáng)大，通過(guò)讀寫(xiě)網(wǎng)絡(luò)傳輸字節(jié)流，支持一對(duì)多的并發(fā)的實(shí)時(shí)通訊。
缺點(diǎn)：不支持直接的RPC（這里我也不是很明白，間接的怎么實(shí)現(xiàn)？）
使用場(chǎng)景：網(wǎng)絡(luò)的數(shù)據(jù)交換
20、請(qǐng)簡(jiǎn)述一下String、StringBuffer和StringBuilder的區(qū)別？

• String 為字符串常量，一旦創(chuàng)建不可以被修改，是線程安全的；String 類使用 final
  修飾符，不可以被繼承；String 的長(zhǎng)度是不變的。適用于少量操作的字符串。
• StringBuffer 為字符串變量，長(zhǎng)度是可變的，線程安全。適用于多線程下在字符緩沖區(qū)進(jìn)行大量字符串操作
• StringBuilder 為字符串變量，長(zhǎng)度是可變的，線程不安全。適用于單線程下在字符緩沖區(qū)進(jìn)行大量字符串操作。
• 字符串操作在執(zhí)行速度：StringBuilder > StringBuffer > String
  21、請(qǐng)簡(jiǎn)述從點(diǎn)擊圖標(biāo)開(kāi)始app的啟動(dòng)流程？
  ①點(diǎn)擊桌面App圖標(biāo)，Launcher進(jìn)程采用Binder IPC向system_server進(jìn)程發(fā)起startActivity請(qǐng)求；
  ②system_server進(jìn)程接收到請(qǐng)求后，向zygote進(jìn)程發(fā)送創(chuàng)建進(jìn)程的請(qǐng)求；
  ③Zygote進(jìn)程fork出新的子進(jìn)程，即App進(jìn)程；
  ④App進(jìn)程，通過(guò)Binder IPC向sytem_server進(jìn)程發(fā)起attachApplication請(qǐng)求；
  ⑤system_server進(jìn)程在收到請(qǐng)求后，進(jìn)行一系列準(zhǔn)備工作后，再通過(guò)binder IPC向App進(jìn)程發(fā)送scheduleLaunchActivity請(qǐng)求；
  ⑥App進(jìn)程的binder線程（ApplicationThread）在收到請(qǐng)求后，通過(guò)handler向主線程發(fā)送LAUNCH_ACTIVITY消息；
  ⑦主線程在收到Message后，通過(guò)發(fā)射機(jī)制創(chuàng)建目標(biāo)Activity，并回調(diào)Activity.onCreate()等方法。
  ⑧到此，App便正式啟動(dòng)，開(kāi)始進(jìn)入Activity生命周期，執(zhí)行完onCreate/onStart/onResume方法，UI渲染結(jié)束后便可以看到App的主界面。
• 22、IntentService 的應(yīng)用場(chǎng)景和使用姿勢(shì)？
  IntentService是Service的子類，比普通的Service增加了額外的功能。先看Service本身存在兩個(gè)問(wèn)題:Service不會(huì)專門(mén)啟動(dòng)一條單獨(dú)的進(jìn)程，Service與他所在應(yīng)用位于同一個(gè)進(jìn)程中。
  Service也不是專門(mén)一條新進(jìn)程，因此不應(yīng)該在Service中直接處理耗時(shí)的任務(wù)。
  特點(diǎn):
  IntentService會(huì)創(chuàng)建獨(dú)立的worker線程來(lái)處理所有的Intent請(qǐng)求；
  會(huì)創(chuàng)建獨(dú)立的worker線程來(lái)處理onHandleIntent()方法實(shí)現(xiàn)的代碼，無(wú)需處理多線程的問(wèn)題；
  所有請(qǐng)求處理完成后，IntentService會(huì)自動(dòng)停止，無(wú)需調(diào)用stopSelf()方法停止Service；
  為Service的onBind()提供默認(rèn)實(shí)現(xiàn)，返回null；
  為Service的onStartCommand提供默認(rèn)實(shí)現(xiàn)，將請(qǐng)求Intent添加到隊(duì)列中；
  接著上一篇面試題Android 面試題筆記（二）
  23、IntentFilter是什么？有哪些使用場(chǎng)景？

（1）IntentFilter是和intent相匹配的，其中action,category,組成了匹配規(guī)則。同時(shí)intentFilter還可以設(shè)置優(yōu)先級(jí)，其中默認(rèn)是0，范圍是【-1000,1000】，值越大優(yōu)先級(jí)越高。并且IntentFilter多被通過(guò)AndroidManifest.xml的形式使用。
(2) 使用場(chǎng)景
activity的隱式啟動(dòng)和廣播的匹配
(3)IntentFilter的匹配規(guī)則
IntentFilter的過(guò)濾信息有action,category,data.一個(gè)組件可以包含多個(gè)intent-filter,一個(gè)intent只要能完全匹配一組intent-filter即可成功的啟動(dòng)對(duì)應(yīng)的組件。
24、回答一下什么是強(qiáng)、軟、弱、虛引用以及它們之間的區(qū)別？

• 強(qiáng)引用（StrongReference）

強(qiáng)引用是使用最普遍的引用。如果一個(gè)對(duì)象具有強(qiáng)引用，那垃圾回收器絕不會(huì)回收它。當(dāng)內(nèi)存空間不足，Java虛擬機(jī)寧愿拋出 OutOfMemoryError 錯(cuò)誤，使程序異常終止，也不會(huì)靠隨意回收具有強(qiáng)引用的對(duì)象來(lái)解決內(nèi)存不足的問(wèn)題。

• 軟引用（SoftReference）

如果一個(gè)對(duì)象只具有軟引用，則內(nèi)存空間足夠，垃圾回收器就不會(huì)回收它；如果內(nèi)存空間不足了，就會(huì)回收這些對(duì)象的內(nèi)存。只要垃圾回收器沒(méi)有回收它，該對(duì)象就可以被程序使用。軟引用可用來(lái)實(shí)現(xiàn)內(nèi)存敏感的高速緩存（下文給出示例）。
軟引用可以和一個(gè)引用隊(duì)列 ReferenceQueue 聯(lián)合使用，如果軟引用所引用的對(duì)象被垃圾回收器回收，Java虛擬機(jī)就會(huì)把這個(gè)軟引用加入到與之關(guān)聯(lián)的引用隊(duì)列中。

• 弱引用（WeakReference）

弱引用與軟引用的區(qū)別在于：只具有弱引用的對(duì)象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的內(nèi)存區(qū)域的過(guò)程中，一旦發(fā)現(xiàn)了只具有弱引用的對(duì)象，不管當(dāng)前內(nèi)存空間足夠與否，都會(huì)回收它的內(nèi)存。不過(guò)，由于垃圾回收器是一個(gè)優(yōu)先級(jí)很低的線程，因此不一定會(huì)很快發(fā)現(xiàn)那些只具有弱引用的對(duì)象。
弱引用可以和一個(gè)引用隊(duì)列 ReferenceQueue 聯(lián)合使用，如果弱引用所引用的對(duì)象被垃圾回收，Java虛擬機(jī)就會(huì)把這個(gè)弱引用加入到與之關(guān)聯(lián)的引用隊(duì)列中。

• 虛引用（PhantomReference）

“虛引用”顧名思義，就是形同虛設(shè)，與其他幾種引用都不同，虛引用并不會(huì)決定對(duì)象的生命周期。如果一個(gè)對(duì)象僅持有虛引用，那么它就和沒(méi)有任何引用一樣，在任何時(shí)候都可能被垃圾回收器回收。
虛引用主要用來(lái)跟蹤對(duì)象被垃圾回收器回收的活動(dòng)。虛引用與軟引用和弱引用的一個(gè)區(qū)別在于：虛引用必須和引用隊(duì)列 ReferenceQueue 聯(lián)合使用。當(dāng)垃圾回收器準(zhǔn)備回收一個(gè)對(duì)象時(shí)，如果發(fā)現(xiàn)它還有虛引用，就會(huì)在回收對(duì)象的內(nèi)存之前，把這個(gè)虛引用加入到與之 關(guān)聯(lián)的引用隊(duì)列中。

- 25、AsyncTask的優(yōu)點(diǎn)和缺點(diǎn)？
優(yōu)點(diǎn)：使用方便，既可以執(zhí)行串行任務(wù)，也可以執(zhí)行并行任務(wù)
缺點(diǎn)：默認(rèn)使用串行任務(wù)執(zhí)行效率低，不能充分利用多線程加快執(zhí)行速度；如果使用并行任務(wù)執(zhí)行，在任務(wù)特別多的時(shí)候會(huì)阻塞UI線程獲得CPU時(shí)間片，后續(xù)做線程收斂需要自定義AsynTask，將其設(shè)置為全局統(tǒng)一的線程池，改動(dòng)量比較大

• 26、對(duì)于面向?qū)ο蟮牧蠡驹瓌t了解多少？
• 單一職責(zé)(Single Responsibility Principle)：一個(gè)類只做一件事，可讀性提高
• 里式替換原則( Liskov Substitution Principle):依賴?yán)^承和多態(tài)，就是能用父類的地方就可以用子類替換，用子類的但不能用父類。
• 依賴倒置原則(Dependence Inversion Principle)：依賴抽象，就是模塊之間的依賴通過(guò)抽象發(fā)生。
• 開(kāi)閉原則(Open-Close Principle):不管是實(shí)體類,模塊還是函數(shù)都應(yīng)該遵循對(duì)擴(kuò)展開(kāi)放對(duì)修改關(guān)閉。還是要依賴封裝和繼承
• 接口隔離原則(Interface Segregation Principle):一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上，如果接口太大，我們需要把它分割成一些更細(xì)小的接口，也是為了降低耦合性
• 迪米特原則(Law of Demeter ):也稱最少知識(shí)原則，也就是說(shuō)一個(gè)類應(yīng)該對(duì)自己需要耦合或者調(diào)用的類知道的最少，只需知道該方法即可，實(shí)現(xiàn)細(xì)節(jié)不必知道。
• 27、LinearLayout, FrameLayout, RelativeLayout 哪個(gè)效率高, 為什么？
  對(duì)于比較三者的效率那肯定是要在相同布局條件下比較繪制的流暢度及繪制過(guò)程，在這里流暢度不好表達(dá)，并且受其他外部因素干擾比較多，比如CPU、GPU等等，我說(shuō)下在繪制過(guò)程中的比較，1、Fragment是從上到下的一個(gè)堆疊的方式布局的，那當(dāng)然是繪制速度最快，只需要將本身繪制出來(lái)即可，但是由于它的繪制方式導(dǎo)致在復(fù)雜場(chǎng)景中直接是不能使用的，所以工作效率來(lái)說(shuō)Fragment僅使用于單一場(chǎng)景，2、LinearLayout 在兩個(gè)方向上繪制的布局，在工作中使用頁(yè)比較多，繪制的時(shí)候只需要按照指定的方向繪制，繪制效率比Fragment要慢，但使用場(chǎng)景比較多，3、RelativeLayout 它的沒(méi)個(gè)子控件都是需要相對(duì)的其他控件來(lái)計(jì)算，按照View樹(shù)的繪制流程、在不同的分支上要進(jìn)行計(jì)算相對(duì)應(yīng)的位置，繪制效率最低，但是一般工作中的布局使用較多，所以說(shuō)這三者之間效率分開(kāi)來(lái)講個(gè)有優(yōu)勢(shì)、不足，那一起來(lái)講也是有優(yōu)勢(shì)、不足，所以不能絕對(duì)的區(qū)分三者的效率
• 28、請(qǐng)簡(jiǎn)述一下 Android 7.0 的新特性？
  1.低電耗功能改進(jìn)
  2.引入畫(huà)中畫(huà)功能
  3.引入“長(zhǎng)按快捷方式”，即App Shortcuts
  4.引入混合模式，同時(shí)存在解釋執(zhí)行/AOT/JIT，安裝應(yīng)用時(shí)默認(rèn)不全量編譯，使得安裝應(yīng)用時(shí)間大大縮短
  5.引入了對(duì)私有平臺(tái)庫(kù)限制，然而用一個(gè)叫做Nougat_dlfunctions的庫(kù)就行
  6.不推薦使用file:// URI傳遞數(shù)據(jù)，轉(zhuǎn)而推薦使用FileProvider
  7.快速回復(fù)通知
• 29、 Android 8.0 的新特性

1、通知渠道 — Notification Channels
2、畫(huà)中畫(huà)模式 — PIP
3、自適應(yīng)圖標(biāo) — Adaptive Icons
4、定時(shí)作業(yè)調(diào)度
5、后臺(tái)限制
6、廣播限制
7、后臺(tái)位置限制
8、WebView API
9、多顯示器支持
10、 統(tǒng)一的布局外邊距和內(nèi)邊距
11、指針捕獲
12、輸入和導(dǎo)航
13、新的 StrictMode 檢測(cè)程序
14、指紋手勢(shì)
15、更新的 ICU4J Android Framework API

• 30、Android9.0新特性？
  1、室內(nèi)WIFI定位
  2、“劉海”屏幕支持
  3、通知
  4、增強(qiáng)體驗(yàn)
  5、通道設(shè)置、廣播以及免打擾
  6、多相機(jī)支持和相機(jī)更新
  7、新的圖片解碼
  8、動(dòng)畫(huà)
  9、HDR VP9視頻，HEIF圖像壓縮和媒體API
  10、JobScheduler中的數(shù)據(jù)成本敏感度
  11、神經(jīng)網(wǎng)絡(luò)API 1.1
  12、改進(jìn)表單自動(dòng)填充
  13、安全增強(qiáng)
  14、Android 備份加密

• 31、請(qǐng)談?wù)勀銓?duì) MVC 和 MVP 的理解？

1.MVC
用戶首先通過(guò)View發(fā)起交互，View調(diào)用Controller執(zhí)行業(yè)務(wù)邏輯，Controller修改Model，然后View通過(guò)觀察者模式檢測(cè)到Model的變化（具體表現(xiàn)形式可以是Pub/Sub或者是觸發(fā)Events），刷新界面顯示。
從這里可以看出，主要業(yè)務(wù)邏輯都在Controller中，Controller會(huì)變得很重。MVC比較明顯的缺點(diǎn)：
View依賴特定的Model，無(wú)法組件化
View和Controller緊耦合，如果脫離Controller，View難以獨(dú)立應(yīng)用（功能太少）
2.MVP
為了克服MVC的上述缺點(diǎn)，MVP應(yīng)運(yùn)而生。在MVP中，View和Model是沒(méi)有直接聯(lián)系的，所有操作都必須通過(guò)Presenter進(jìn)行中轉(zhuǎn)。View向Presenter發(fā)起調(diào)用請(qǐng)求，Presenter修改Model，Model修改完成后通知Presenter，Presenter再調(diào)用View的相關(guān)接口刷新界面。這樣，View就不需要監(jiān)聽(tīng)具體Model的變化了，只需要提供接口給Presenter調(diào)用就可以了。MVP具有以下優(yōu)點(diǎn)：

View可以組件化，不需要了解業(yè)務(wù)邏輯，只需提供接口給Presenter
便于測(cè)試：只需要給Presenter mock一個(gè)View，實(shí)現(xiàn)View的接口即可

- 32、談?wù)凙ndroid的事件分發(fā)機(jī)制？

• 會(huì)經(jīng)過(guò)Activity->ViewGroup->view,一次往下傳遞事件，如果一直不攔截再回調(diào)回來(lái)。

• 主要經(jīng)過(guò)三個(gè)方法，dispatchTouchEvent（分發(fā)事件），oninterceptTouchEvent（是否攔截View中不存在），onTouchEvent(處理）。

• 三個(gè)方法的用法是，先用dispatchTouchEvent來(lái)分發(fā)事件，然后用oninterceptTouchEvent來(lái)判斷是否攔截該任務(wù)（此方法在dispatchTouchEvent內(nèi)部),如果不攔截直接dispatch向下回調(diào)，如果攔截就調(diào)用自己的onTouchEvent來(lái)處理事件。

• 如果由setOnClickListener方法會(huì)先執(zhí)行onClick.
  更多事件分發(fā)機(jī)制見(jiàn)講講 Android 的事件分發(fā)機(jī)制

• 33、談?wù)凙rrayList和LinkedList的區(qū)別？
  ArrayList和LinkedList的大致區(qū)別：
  1.ArrayList是實(shí)現(xiàn)了基于動(dòng)態(tài)數(shù)組的數(shù)據(jù)結(jié)構(gòu)，LinkedList是基于鏈表結(jié)構(gòu)。
  2.對(duì)于隨機(jī)訪問(wèn)的get和set方法，ArrayList要優(yōu)于LinkedList，因?yàn)長(zhǎng)inkedList要移動(dòng)指針。
  3.對(duì)于新增和刪除操作add和remove，LinkedList比較占優(yōu)勢(shì)，因?yàn)锳rrayList要移動(dòng)數(shù)據(jù)。
  性能上的缺點(diǎn)：
  1.對(duì)ArrayList和LinkedList而言，在列表末尾增加一個(gè)元素所花的開(kāi)銷都是固定的。對(duì) ArrayList而言，主要是在內(nèi)部數(shù)組中增加一項(xiàng)，指向所添加的元素，偶爾可能會(huì)導(dǎo)致對(duì)數(shù)組重新進(jìn)行分配；而對(duì)LinkedList而言，這個(gè)開(kāi)銷是 統(tǒng)一的，分配一個(gè)內(nèi)部Entry對(duì)象。
  2.在ArrayList集合中添加或者刪除一個(gè)元素時(shí)，當(dāng)前的列表所所有的元素都會(huì)被移動(dòng)。而LinkedList集合中添加或者刪除一個(gè)元素的開(kāi)銷是固定的。
  3.LinkedList集合不支持 高效的隨機(jī)隨機(jī)訪問(wèn)（RandomAccess），因?yàn)榭赡墚a(chǎn)生二次項(xiàng)的行為。
  4.ArrayList的空間浪費(fèi)主要體現(xiàn)在在list列表的結(jié)尾預(yù)留一定的容量空間，而LinkedList的空間花費(fèi)則體現(xiàn)在它的每一個(gè)元素都需要消耗相當(dāng)?shù)目臻g

• 34、handlerThread使用場(chǎng)景分析及原理？

當(dāng)我們需要向子線程發(fā)送消息處理耗時(shí)操作時(shí)可使用handlerThread,詳細(xì)使用介紹見(jiàn)
handlerThread使用場(chǎng)景分析及源碼解析

• 35、針對(duì)RecyclerView你做了哪些優(yōu)化？
  1，減少view type的種類，如果樣式差別不大，可以公用一個(gè)布局。因?yàn)閕nflate調(diào)用比公用布局的繪制占用更多的性能。
  2，可以使用DiffUtil去刷新數(shù)據(jù)，notifyDataSetChanged性能太低而且不會(huì)出發(fā)增刪動(dòng)畫(huà)。（子線程計(jì)算新舊數(shù)據(jù)，主線程刷新recylerView）
  3，分頁(yè)加載
  4，有大量圖片時(shí)，滾動(dòng)停止加載圖片，停止才通知adapter去加載
  5，設(shè)置合理的RecycledViewPool
  6，item的高度固定時(shí)setHasFixedSize(true)
  7，在ViewHolder中設(shè)置點(diǎn)擊事件而不是在onBindViewHolder
• 36，請(qǐng)說(shuō)一下HashMap與HashTable的區(qū)別？
  HashMap和Hashtable的比較是Java面試中的常見(jiàn)問(wèn)題，用來(lái)考驗(yàn)程序員是否能夠正確使用集合類以及是否可以隨機(jī)應(yīng)變使用多種思路解決問(wèn)題。HashMap的工作原理、ArrayList與Vector的比較以及這個(gè)問(wèn)題是有關(guān)Java 集合框架的最經(jīng)典的問(wèn)題。Hashtable是個(gè)過(guò)時(shí)的集合類，存在于Java API中很久了。在Java 4中被重寫(xiě)了，實(shí)現(xiàn)了Map接口，所以自此以后也成了Java集合框架中的一部分。Hashtable和HashMap在Java面試中相當(dāng)容易被問(wèn)到，甚至成為了集合框架面試題中最常被考的問(wèn)題，所以在參加任何Java面試之前，都不要忘了準(zhǔn)備這一題。
• 1父類不同

第一個(gè)不同主要是歷史原因。Hashtable是基于陳舊的Dictionary類的，HashMap是Java 1.2引進(jìn)的Map接口的一個(gè)實(shí)現(xiàn)。
public class HashMap<K, V> extends AbstractMap<K, V> implements Cloneable, Serializable {…}
public class Hashtable<K, V> extends Dictionary<K, V> implements Map<K, V>, Cloneable, Serializable {…}
而HashMap繼承的抽象類AbstractMap實(shí)現(xiàn)了Map接口：
public abstract class AbstractMap<K, V> implements Map<K, V> {…}

• 2 線程安全不一樣

Hashtable 中的方法是同步的，而HashMap中的方法在默認(rèn)情況下是非同步的。在多線程并發(fā)的環(huán)境下，可以直接使用Hashtable，但是要使用HashMap的話就要自己增加同步處理了。

• 3允不允許null值

Hashtable中，key和value都不允許出現(xiàn)null值，否則會(huì)拋出NullPointerException異常。
而在HashMap中，null可以作為鍵，這樣的鍵只有一個(gè)；可以有一個(gè)或多個(gè)鍵所對(duì)應(yīng)的值為null。當(dāng)get()方法返回null值時(shí)，即可以表示 HashMap中沒(méi)有該鍵，也可以表示該鍵所對(duì)應(yīng)的值為null。因此，在HashMap中不能由get()方法來(lái)判斷HashMap中是否存在某個(gè)鍵， 而應(yīng)該用containsKey()方法來(lái)判斷。

• 4遍歷方式的內(nèi)部實(shí)現(xiàn)上不同

Hashtable、HashMap都使用了 Iterator。而由于歷史原因，Hashtable還使用了Enumeration的方式 。

• 5哈希值的使用不同

HashTable直接使用對(duì)象的hashCode。而HashMap重新計(jì)算hash值。

• 6 內(nèi)部實(shí)現(xiàn)方式的數(shù)組的初始大小和擴(kuò)容的方式不一樣

HashTable中的hash數(shù)組初始大小是11，增加的方式是 old*2+1。HashMap中hash數(shù)組的默認(rèn)大小是16，而且一定是2的指數(shù)。

• 37，簡(jiǎn)述一下自定義View的流程？
  自定義屬性；
  選擇和設(shè)置構(gòu)造方法；
  重寫(xiě)onMeasure()方法；
  重寫(xiě)onDraw()方法；
  重寫(xiě)onLayout()方法；
  重寫(xiě)其他事件的方法(滑動(dòng)監(jiān)聽(tīng)等)；
  更多見(jiàn)自定義view的三種實(shí)現(xiàn)方式Android自定義View的三種實(shí)現(xiàn)方式
  38、談?wù)劸€程死鎖，如何有效的避免線程死鎖？
  死鎖產(chǎn)生的條件
  一般來(lái)說(shuō)，出現(xiàn)死鎖問(wèn)題需要滿足以下條件
• 互斥條件：一個(gè)資源每次只能被一個(gè)線程使用
• 請(qǐng)求與保證條件：一個(gè)線程因請(qǐng)求資源而阻塞時(shí)，對(duì)已獲得的資源保持不放
• 不剝奪條件：線程已獲得的資源，在未使用完成之前，不能強(qiáng)行剝奪
• 循環(huán)等待條件：若干線程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系

在JAVA編程中，有3中典型的死鎖類型：

• 靜態(tài)的鎖順序死鎖

• 動(dòng)態(tài)的鎖順序死鎖

• 協(xié)作對(duì)象之間發(fā)生的死鎖

• 典型死鎖例子

• 注意以下代碼都是錯(cuò)誤代碼

1.靜態(tài)的鎖順序死鎖

class Test{final Object objA = new Object();final Object objB = new Object();public void a(){//注意這里 先A后Bsynchronized(objA){synchronized(objB){//sth....}}}public void b(){//注意這里 先B后Asynchronized(objB){synchronized(objA){//sth....}}} }

2.動(dòng)態(tài)的鎖順序死鎖
動(dòng)態(tài)的鎖順序死鎖是指兩個(gè)線程調(diào)用同一個(gè)方法時(shí)，傳入的參數(shù)顛倒造成的死鎖。如下情景，一個(gè)線程調(diào)用了transferMoney（轉(zhuǎn)賬）方法并傳入?yún)?shù)accountA,accountB；另一個(gè)線程調(diào)用了transferMoney方法并傳入?yún)?shù)accountB,accountA。此時(shí)就可能發(fā)生在靜態(tài)的鎖順序死鎖中存在的問(wèn)題，即：第一個(gè)線程獲得了accountA鎖并等待accountB鎖，第二個(gè)線程獲得了accountB鎖并等待accountA鎖。

3.協(xié)作對(duì)象之間發(fā)生的死鎖
有時(shí)，死鎖并不會(huì)那么明顯，比如兩個(gè)相互協(xié)作的類之間的死鎖，比如：一個(gè)線程調(diào)用了A對(duì)象的a方法，另一個(gè)線程調(diào)用了B對(duì)象的b方法。此時(shí)可能會(huì)發(fā)生，第一個(gè)線程持有A對(duì)象鎖并等待B對(duì)象鎖，另一個(gè)線程持有B對(duì)象鎖并等待A對(duì)象鎖。

• 39、“equals”與“==”、“hashCode”的區(qū)別和使用場(chǎng)景？
  我們一般這么理解
  equal比較的是內(nèi)容
  == 比較的存儲(chǔ)地址或基本數(shù)據(jù)類型的數(shù)值比較（數(shù)學(xué)意義）
  hashCode 對(duì)內(nèi)存分配的位置確定

使用場(chǎng)景

equal一般比較內(nèi)容相等 比如字符串相等
==一般比較數(shù)值 或者null判斷
hashcode我們一般用來(lái)判斷來(lái)兩個(gè)對(duì)象是否相等，但這里需要注意的是 兩個(gè)對(duì)象的hashcode相等，兩個(gè)對(duì)象不一定相等，兩個(gè)相等的對(duì)象hashcode一定相等。

我們?yōu)槭裁匆@樣判斷呢？

因?yàn)榕袛鄡蓚€(gè)對(duì)象相等重寫(xiě)equal的重載方法比較多，需要判斷 傳遞性、非空性、自反性、一致性、對(duì)稱性

• 40、談一談startService和bindService的區(qū)別，生命周期以及使用場(chǎng)景？
  1、生命周期上的區(qū)別

執(zhí)行startService時(shí)，Service會(huì)經(jīng)歷onCreate->onStartCommand。當(dāng)執(zhí)行stopService時(shí)，直接調(diào)用onDestroy方法。調(diào)用者如果沒(méi)有stopService，Service會(huì)一直在后臺(tái)運(yùn)行，下次調(diào)用者再起來(lái)仍然可以stopService。

執(zhí)行bindService時(shí)，Service會(huì)經(jīng)歷onCreate->onBind。這個(gè)時(shí)候調(diào)用者和Service綁定在一起。調(diào)用者調(diào)用unbindService方法或者調(diào)用者Context不存在了（如Activity被finish了），Service就會(huì)調(diào)用onUnbind->onDestroy。這里所謂的綁定在一起就是說(shuō)兩者共存亡了。

多次調(diào)用startService，該Service只能被創(chuàng)建一次，即該Service的onCreate方法只會(huì)被調(diào)用一次。但是每次調(diào)用startService，onStartCommand方法都會(huì)被調(diào)用。Service的onStart方法在API 5時(shí)被廢棄，替代它的是onStartCommand方法。

第一次執(zhí)行bindService時(shí)，onCreate和onBind方法會(huì)被調(diào)用，但是多次執(zhí)行bindService時(shí)，onCreate和onBind方法并不會(huì)被多次調(diào)用，即并不會(huì)多次創(chuàng)建服務(wù)和綁定服務(wù)。
2、調(diào)用者如何獲取綁定后的Service的方法

onBind回調(diào)方法將返回給客戶端一個(gè)IBinder接口實(shí)例，IBinder允許客戶端回調(diào)服務(wù)的方法，比如得到Service運(yùn)行的狀態(tài)或其他操作。我們需要IBinder對(duì)象返回具體的Service對(duì)象才能操作，所以說(shuō)具體的Service對(duì)象必須首先實(shí)現(xiàn)Binder對(duì)象。
3、既使用startService又使用bindService的情況

如果一個(gè)Service又被啟動(dòng)又被綁定，則該Service會(huì)一直在后臺(tái)運(yùn)行。首先不管如何調(diào)用，onCreate始終只會(huì)調(diào)用一次。對(duì)應(yīng)startService調(diào)用多少次，Service的onStart方法便會(huì)調(diào)用多少次。Service的終止，需要unbindService和stopService同時(shí)調(diào)用才行。不管startService與bindService的調(diào)用順序，如果先調(diào)用unbindService，此時(shí)服務(wù)不會(huì)自動(dòng)終止，再調(diào)用stopService之后，服務(wù)才會(huì)終止；如果先調(diào)用stopService，此時(shí)服務(wù)也不會(huì)終止，而再調(diào)用unbindService或者之前調(diào)用bindService的Context不存在了（如Activity被finish的時(shí)候）之后，服務(wù)才會(huì)自動(dòng)停止。

那么，什么情況下既使用startService，又使用bindService呢？

如果你只是想要啟動(dòng)一個(gè)后臺(tái)服務(wù)長(zhǎng)期進(jìn)行某項(xiàng)任務(wù)，那么使用startService便可以了。如果你還想要與正在運(yùn)行的Service取得聯(lián)系，那么有兩種方法：一種是使用broadcast，另一種是使用bindService。前者的缺點(diǎn)是如果交流較為頻繁，容易造成性能上的問(wèn)題，而后者則沒(méi)有這些問(wèn)題。因此，這種情況就需要startService和bindService一起使用了。

另外，如果你的服務(wù)只是公開(kāi)一個(gè)遠(yuǎn)程接口，供連接上的客戶端（Android的Service是C/S架構(gòu)）遠(yuǎn)程調(diào)用執(zhí)行方法，這個(gè)時(shí)候你可以不讓服務(wù)一開(kāi)始就運(yùn)行，而只是bindService，這樣在第一次bindService的時(shí)候才會(huì)創(chuàng)建服務(wù)的實(shí)例運(yùn)行它，這會(huì)節(jié)約很多系統(tǒng)資源，特別是如果你的服務(wù)是遠(yuǎn)程服務(wù)，那么效果會(huì)越明顯（當(dāng)然在Servcie創(chuàng)建的是偶會(huì)花去一定時(shí)間，這點(diǎn)需要注意）。
4、本地服務(wù)與遠(yuǎn)程服務(wù)

本地服務(wù)依附在主進(jìn)程上，在一定程度上節(jié)約了資源。本地服務(wù)因?yàn)槭窃谕贿M(jìn)程，因此不需要IPC，也不需要AIDL。相應(yīng)bindService會(huì)方便很多。缺點(diǎn)是主進(jìn)程被kill后，服務(wù)變會(huì)終止。

遠(yuǎn)程服務(wù)是獨(dú)立的進(jìn)程，對(duì)應(yīng)進(jìn)程名格式為所在包名加上你指定的android:process字符串。由于是獨(dú)立的進(jìn)程，因此在Activity所在進(jìn)程被kill的是偶，該服務(wù)依然在運(yùn)行。缺點(diǎn)是該服務(wù)是獨(dú)立的進(jìn)程，會(huì)占用一定資源，并且使用AIDL進(jìn)行IPC稍微麻煩一點(diǎn)。

對(duì)于startService來(lái)說(shuō)，不管是本地服務(wù)還是遠(yuǎn)程服務(wù)，我們需要做的工作都一樣簡(jiǎn)單。

• 41、synchronized和volatile關(guān)鍵字的區(qū)別？
  1.volatile本質(zhì)是在告訴jvm當(dāng)前變量在寄存器（工作內(nèi)存）中的值是不確定的，需要從主存中讀取； synchronized則是鎖定當(dāng)前變量，只有當(dāng)前線程可以訪問(wèn)該變量，其他線程被阻塞住。
  2.volatile僅能使用在變量級(jí)別；synchronized則可以使用在變量、方法、和類級(jí)別的
  volatile僅能實(shí)現(xiàn)變量的修改可見(jiàn)性，不能保證原子性；而synchronized則可以保證變量的修改可見(jiàn)性和原子性
  3.volatile不會(huì)造成線程的阻塞；synchronized可能會(huì)造成線程的阻塞。
  4.volatile標(biāo)記的變量不會(huì)被編譯器優(yōu)化；synchronized標(biāo)記的變量可以被編譯器優(yōu)化

synchronized 可以保證原子性。他可以保證 在同一時(shí)刻，只有一個(gè)線程可以訪問(wèn)被 synchronized 修飾的方法，或者代碼塊。
volatile 不能保證原子性。當(dāng)時(shí)在使用這個(gè)關(guān)鍵字后。當(dāng)被Volatitle 修飾字段的值發(fā)生改變后，其他線程會(huì)立刻知道這個(gè)值已經(jīng)發(fā)生變化了。volatitle 可以保證可見(jiàn)性和有序性。

• 42、什么是冒泡排序？如何優(yōu)化？
  冒泡排序算法原理：（從小到大排序）
  1.比較相鄰的元素。如果第一個(gè)比第二個(gè)大，就交換他們兩個(gè)
  2.對(duì)每一對(duì)相鄰元素作同樣的工作，從開(kāi)始第一對(duì)到結(jié)尾的最后一對(duì)，交換一趟后，最后的元素會(huì)是最大的數(shù)
  3.針對(duì)所有的元素重復(fù)以上的步驟，除了最后一個(gè)
  4.持續(xù)每次對(duì)越來(lái)越少的元素重復(fù)上面的步驟，直到?jīng)]有任何一對(duì)數(shù)字需要比較

優(yōu)化方案1（定義一個(gè)變量l來(lái)保存一趟交換中兩兩交換的次數(shù)，如果l==0,則說(shuō)明排序已經(jīng)完成，退出for循環(huán)）
優(yōu)化方案2（假如有一個(gè)長(zhǎng)度為50的數(shù)組，在一趟交換后，最后發(fā)生交換的位置是10，那么這個(gè)位置之后的40個(gè)數(shù)必定已經(jīng)有序了，記錄下這位置，下一趟交換只要從數(shù)組頭部到這個(gè)位置就可以了）
定義一個(gè)變量n來(lái)保存一趟交換中最后一次發(fā)生交換的位置，并把它傳遞給下一趟交換

/*** 排序思想:* 對(duì)一組數(shù)字進(jìn)行從小到大或者從大到小的進(jìn)行排序。* 它是通過(guò)讓相鄰的兩個(gè)元素進(jìn)行比較，大的元素向下沉，小的元素向上冒* arr[0]與arr[1]進(jìn)行比較，如果前者大于后者，則交換位置* 然后arr[1]與arr[2]進(jìn)行比較，以此類推。當(dāng)進(jìn)行到n-1輪后，排序完成。*/ import java.util.Arrays; public class Sort {public static void main(String[] args){int arr[]= {100,90,101,23,13,75};int temp=0;for(int i=0;i<arr.length-1;i++) {for(int j=0;j<arr.length-1-i;j++) {if(arr[j]>arr[j+1]) {temp=arr[j+1];arr[j+1]=arr[j];arr[j]=temp;}}System.out.println("第["+(i+1)+"]輪，排序結(jié)果:"+ Arrays.toString(arr));}System.out.print("================================");int arr2[]= {100,90,101,23,13,75};sort2(arr2);}/*** 優(yōu)化思路：* 假如在第1輪比較當(dāng)中，發(fā)現(xiàn)所有的元素都沒(méi)有進(jìn)行交換，則說(shuō)明此原數(shù)據(jù)就是有序的，不需要再進(jìn)行排序* @param arr*/public static void sort2(int arr[]){int temp=0;int flag=0;for(int i=0;i<arr.length-1;i++) {flag=0;for(int j=0;j<arr.length-1-i;j++) {if(arr[j]>arr[j+1]) {temp=arr[j+1];arr[j+1]=arr[j];arr[j]=temp;//如果有交換的行為,則flag=1flag=1;}}//說(shuō)明上面 內(nèi)for循環(huán)中，沒(méi)有交換任何元素。if(flag==0) {break;}System.out.println("第["+(i+1)+"]輪，排序結(jié)果:"+Arrays.toString(arr));}} }

• 43、分別講講 final，static，synchronized 關(guān)鍵字可以修飾什么，以及修飾后的作用？
  static
  static 方法
  static 方法一般稱作靜態(tài)方法，由于靜態(tài)方法不依賴于任何對(duì)象就可以進(jìn)行訪問(wèn)，因此對(duì)于靜態(tài)方法來(lái)說(shuō)，是沒(méi)有 this 的，因?yàn)樗灰栏接谌魏螌?duì)象，既然都沒(méi)有對(duì)象，就談不上 this 了。
  public class StaticTest {
  public static void a(){
  }
  public static void main(String[]args){
  StaticTest.a();
  }
  }
  static 變量
  static 變量也稱作靜態(tài)變量，靜態(tài)變量和非靜態(tài)變量的區(qū)別是：靜態(tài)變量被所有的對(duì)象所共享，在內(nèi)存中只有一個(gè)副本，它當(dāng)且僅當(dāng)在類初次加載時(shí)會(huì)被初始化。而非靜態(tài)變量是對(duì)象所擁有的，在創(chuàng)建對(duì)象的時(shí)候被初始化，存在多個(gè)副本，各個(gè)對(duì)象擁有的副本互不影響。
  static 代碼塊
  static 關(guān)鍵字還有一個(gè)比較關(guān)鍵的作用就是 用來(lái)形成靜態(tài)代碼塊以優(yōu)化程序性能。static 塊可以置于類中的任何地方，類中可以有多個(gè) static 塊。在類初次被加載的時(shí)候，會(huì)按照 static 塊的順序來(lái)執(zhí)行每個(gè) static 塊，并且只會(huì)執(zhí)行一次。
  public class StaticTest {
  private static int a ;
  private static int b;
  static {
  a = 1;
  b = 2;
  }
  final
  final 變量
  凡是對(duì)成員變量或者本地變量(在方法中的或者代碼塊中的變量稱為本地變量)聲明為 final 的都叫作 final 變量。final 變量經(jīng)常和 static 關(guān)鍵字一起使用，作為常量。
  private final int aa = 1;
  static {
  a = 1;
  b = 2;
  }
  private void init(){
  aa = 2;//報(bào)錯(cuò)編譯器會(huì)提示 不能賦值。。
  }
  final 方法
  final 也可以聲明方法。方法前面加上 final 關(guān)鍵字，代表這個(gè)方法不可以被子類的方法重寫(xiě)。如果你認(rèn)為一個(gè)方法的功能已經(jīng)足夠完整了，子類中不需要改變的話，你可以聲明此方法為 final。final 方法比非 final 方法要快，因?yàn)樵诰幾g的時(shí)候已經(jīng)靜態(tài)綁定了，不需要在運(yùn)行時(shí)再動(dòng)態(tài)綁定。
  public static void main(String[]args){
  StaticTest.a();
  }
  class StaticTest2 extends StaticTest{
  public final void a(){ //這邊就會(huì)編譯器提示不能重寫(xiě)
  }
  }
  **final 類 **
  其實(shí)更上面同個(gè)道理，使用 final 來(lái)修飾的類叫作 final 類。final 類通常功能是完整的，它們不能被繼承。Java 中有許多類是 final 的，譬如 String，Interger 以及其他包裝類。
  synchronized
  synchronized 是 Java 中解決并發(fā)問(wèn)題的一種最常用的方法，也是最簡(jiǎn)單的一種方法。synchronized 的作用主要有三個(gè)：

確保線程互斥的訪問(wèn)同步代碼
保證共享變量的修改能夠及時(shí)可見(jiàn)
有效解決重排序問(wèn)題。
synchronized 方法
有效避免了類成員變量的訪問(wèn)沖突：
private synchronized void init(){
aa = 2;
}
synchronized 代碼塊
這時(shí)鎖就是對(duì)象，誰(shuí)拿到這個(gè)鎖誰(shuí)就可以運(yùn)行它所控制的那段代碼。當(dāng)有一個(gè)明確的對(duì)象作為鎖時(shí)，就可以這樣寫(xiě)程序，但當(dāng)沒(méi)有明確的對(duì)象作為鎖，只是想讓一段代碼同步時(shí)，可以創(chuàng)建一個(gè)特殊的 instance 變量（它得是一個(gè)對(duì)象）來(lái)充當(dāng)鎖。
public final void a(){
synchronized (lock){
//代碼
}
}
@Override
public void run() {
}

• 44、什么是 RemoteViews？使用場(chǎng)景有哪些？
  RemoteViews
  RemoteViews翻譯過(guò)來(lái)就是遠(yuǎn)程視圖.顧名思義,RemoteViews不是當(dāng)前進(jìn)程的View,是屬于SystemServer進(jìn)程.應(yīng)用程序與RemoteViews之間依賴Binder實(shí)現(xiàn)了進(jìn)程間通信.
  用法
  通常是在通知欄

//1.創(chuàng)建RemoteViews實(shí)例RemoteViews mRemoteViews=new RemoteViews("com.example.remoteviewdemo", R.layout.remoteview_layout);//2.構(gòu)建一個(gè)打開(kāi)Activity的PendingIntentIntent intent=new Intent(MainActivity.this,MainActivity.class);PendingIntent mPendingIntent=PendingIntent.getActivity(MainActivity.this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);//3.創(chuàng)建一個(gè)NotificationmNotification = new Notification.Builder(this).setSmallIcon(R.drawable.ic_launcher).setContentIntent(mPendingIntent).setContent(mRemoteViews).build();//4.獲取NotificationManagermanager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);Button button1 = (Button) findViewById(R.id.button1);button1.setOnClickListener(new OnClickListener() {@Overridepublic void onClick(View v) {//彈出通知manager.notify(1, mNotification);}});

• 45、什么是反射機(jī)制？反射機(jī)制的應(yīng)用場(chǎng)景有哪些？
  Java 反射機(jī)制是在運(yùn)行狀態(tài)中，對(duì)于任意一個(gè)類，都能夠知道這個(gè)類中的所有屬性和方法，對(duì)于任意一個(gè)對(duì)象，都能夠調(diào)用它的任意一個(gè)方法和屬性；這種動(dòng)態(tài)獲取的信息以及動(dòng)態(tài)調(diào)用對(duì)象的方法的功能稱為 Java 語(yǔ)言的反射機(jī)制。
  應(yīng)用場(chǎng)景：

逆向代碼，例如反編譯
與注解相結(jié)合的框架，如 Retrofit
單純的反射機(jī)制應(yīng)用框架，例如 EventBus（事件總線）
動(dòng)態(tài)生成類框架 例如Gson

import java.lang.reflect.Constructor; import java.lang.reflect.Field; import java.lang.reflect.Method;/*** 對(duì)于任何一個(gè)類，我們都能夠知道這個(gè)類有哪些方法和屬性。對(duì)于任何一個(gè)對(duì)象，* 我們都能夠?qū)λ姆椒ê蛯傩赃M(jìn)行調(diào)用。* 我們把這種動(dòng)態(tài)獲取對(duì)象信息和調(diào)用對(duì)象方法的功能稱之為 反射機(jī)制*/ /*** 所謂反射其實(shí)是獲取類的字節(jié)碼文件，* 也就是.class文件，那么我們就可以通過(guò)Class這個(gè)對(duì)象進(jìn)行獲取*/ public class HookTest {public static void main(String[] args) {//第一種方式LoopTest loopTest = new LoopTest();Class aClass = loopTest.getClass();System.out.println(aClass.getName());//第二種方式Class aclass2 = LoopTest.class;System.out.println(aclass2.getName());//第三種方式try {Class aclass3 = Class.forName("LoopTest");System.out.println(aclass3.getName());}catch (ClassNotFoundException ex){ex.printStackTrace();}/*** 那么這3中方式我們一般選用哪種方式呢？第一種已經(jīng)創(chuàng)建了對(duì)象，那么這個(gè)時(shí)候就不需要去進(jìn)行反射了，* 顯得有點(diǎn)多此一舉。第二種需要導(dǎo)入類的包，依賴性太強(qiáng)。所以我們一般選中第三種方式。*//*** 三、通過(guò)反射獲取類的構(gòu)造方法、方法以及屬性*//*** 1、獲取構(gòu)造方法*/Constructor[]constructors = aclass2.getConstructors();System.out.println("獲取構(gòu)造方法:");for (Constructor constructor1 : constructors){System.out.println(constructor1.getName());}System.out.println("獲取類的屬性:");Field[] fields = aclass2.getFields();//88888System.out.println("獲取類的方法:");Method[]methods = aclass2.getMethods();for (Method method : methods){System.out.println(method.getName());}/*** 反射執(zhí)行方法*/try { Class aclass4 = Class.forName("LoopTest");Method method = aclass4.getDeclaredMethod("method",String.class);Constructor ct = aclass4.getConstructor(null);Object obj = ct.newInstance(null);method.invoke(obj,"反射調(diào)用");} catch (Exception e) {e.printStackTrace();}/*** Android中使用場(chǎng)景：其實(shí)很多用過(guò)的EventBus 、Retrofit 都有涉獵 可以去看看源碼*/}}

java反射機(jī)制是在運(yùn)行狀態(tài)中，對(duì)于任意一個(gè)類，都能夠知道這個(gè)類的所有屬性和方法；對(duì)于任意一個(gè)對(duì)象，都能調(diào)用它的任意一個(gè)方法和屬性；這種動(dòng)態(tài)獲取的信息以及動(dòng)態(tài)調(diào)用對(duì)象的方法的功能稱為java語(yǔ)言的反射機(jī)制。
靜態(tài)編譯：在編譯時(shí)確定類型，綁定對(duì)象。
動(dòng)態(tài)編譯：在運(yùn)行時(shí)確定類型，綁定對(duì)象。
反射機(jī)制的優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：運(yùn)行期類型的判斷，動(dòng)態(tài)加載類，提高代碼靈活度。
缺點(diǎn)：性能瓶頸：反射相當(dāng)于一系列解釋操作，通知 JVM 要做的事情，性能比直接的java代碼要慢很多。

• 46、Java 中使用多線程的方式有哪些？
  1、繼承Thread類創(chuàng)建線程
  Thread類本質(zhì)上是實(shí)現(xiàn)了Runnable接口的一個(gè)實(shí)例，代表一個(gè)線程的實(shí)例。啟動(dòng)線程的唯一方法就是通過(guò)Thread類的start()實(shí)例方法。start()方法是一個(gè)native方法，它將啟動(dòng)一個(gè)新線程，并執(zhí)行run()方法。這種方式實(shí)現(xiàn)多線程很簡(jiǎn)單，通過(guò)自己的類直接extend Thread，并復(fù)寫(xiě)run()方法，就可以啟動(dòng)新線程并執(zhí)行自己定義的run()方法。
  2、實(shí)現(xiàn)Runnable接口創(chuàng)建線程
  如果自己的類已經(jīng)extends另一個(gè)類，就無(wú)法直接extends Thread，此時(shí)，可以實(shí)現(xiàn)一個(gè)Runnable接口
  3、實(shí)現(xiàn)Callable接口通過(guò)FutureTask包裝器來(lái)創(chuàng)建Thread線程
  Callable接口（也只有一個(gè)方法
  4、4、使用ExecutorService、Callable、Future實(shí)現(xiàn)有返回結(jié)果的線程

ExecutorService、Callable、Future三個(gè)接口實(shí)際上都是屬于Executor框架。返回結(jié)果的線程是在JDK1.5中引入的新特征，有了這種特征就不需要再為了得到返回值而大費(fèi)周折了。
可返回值的任務(wù)必須實(shí)現(xiàn)Callable接口。類似的，無(wú)返回值的任務(wù)必須實(shí)現(xiàn)Runnable接口

• 47、請(qǐng)簡(jiǎn)述一下什么是 Kotlin？它有哪些特性？
  設(shè)計(jì)理念
  1、創(chuàng)建一種兼容Java的語(yǔ)言
  2、讓它比Java更安全，能夠靜態(tài)檢測(cè)常見(jiàn)的陷阱。如：引用空指針
  3、讓它比Java更簡(jiǎn)潔，通過(guò)支持variable type inference，higher-order functions (closures)，extension functions，mixins and first-class delegation等實(shí)現(xiàn)。
  4、讓它比最成熟的競(jìng)爭(zhēng)對(duì)手Scala語(yǔ)言更加簡(jiǎn)單。
  Kotlin優(yōu)勢(shì)
  1、簡(jiǎn)潔: 大大減少樣板代碼的數(shù)量。
  2、安全: 避免空指針異常等整個(gè)類的錯(cuò)誤。
  3、互操作性: 充分利用 JVM、Android 和瀏覽器的現(xiàn)有庫(kù)。
  4、工具友好: 可用任何 Java IDE 或者使用命令行構(gòu)建。

kotlin和java都是運(yùn)行在java虛擬機(jī)的語(yǔ)言。編譯后都會(huì)生成.class文件。而虛擬機(jī)運(yùn)行的正是.class文件。所以兩者都可以用來(lái)寫(xiě)Android。再說(shuō)說(shuō)個(gè)人的一些看法。java作為一門(mén)相對(duì)時(shí)間長(zhǎng)一點(diǎn)的語(yǔ)言。相對(duì)來(lái)說(shuō)更萬(wàn)能一些。基本上能完成所有的開(kāi)發(fā)場(chǎng)景。而且，因?yàn)闀r(shí)間夠久，相對(duì)來(lái)說(shuō)問(wèn)題也很少,雖然大家都吐槽分號(hào)，類型轉(zhuǎn)換，空指針這些傻瓜操作，但是我并沒(méi)有覺(jué)得不寫(xiě)這些就能對(duì)我的開(kāi)發(fā)有質(zhì)的的提升，唯一讓我想學(xué)kt的動(dòng)力就是google的Android實(shí)例將來(lái)要用kt寫(xiě)。而kotlin作為一門(mén)新語(yǔ)言，有他自己的優(yōu)點(diǎn)，也有一些缺點(diǎn)。具體什么缺點(diǎn)大家看下面的文章吧。

從java到kotlin,再?gòu)膋otlin回歸java

• 48.談?wù)凟rror和Exception的區(qū)別？
  Exception是java程序運(yùn)行中可預(yù)料的異常情況，咱們可以獲取到這種異常，并且對(duì)這種異常進(jìn)行業(yè)務(wù)外的處理。

Error是java程序運(yùn)行中不可預(yù)料的異常情況，這種異常發(fā)生以后，會(huì)直接導(dǎo)致JVM不可處理或者不可恢復(fù)的情況。所以這種異常不可能抓取到，比如OutOfMemoryError、NoClassDefFoundError等。

其中的Exception又分為檢查性異常和非檢查性異常。兩個(gè)根本的區(qū)別在于，檢查性異常 必須在編寫(xiě)代碼時(shí)，使用try catch捕獲（比如：IOException異常）。非檢查性異常 在代碼編寫(xiě)使，可以忽略捕獲操作（比如：ArrayIndexOutOfBoundsException），這種異常是在代碼編寫(xiě)或者使用過(guò)程中通過(guò)規(guī)范可以避免發(fā)生的。 切記，Error是Throw不是Exception 。

• 49.請(qǐng)簡(jiǎn)述 Http 與 Https 的區(qū)別？

HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計(jì)了SSL（Secure Sockets Layer）協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。
1、https協(xié)議需要到ca申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。

2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。

3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

4、http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。
最后一點(diǎn)在Android 9.0 如果用http進(jìn)行傳輸，需要在application節(jié)點(diǎn)下設(shè)置 android:usesCleartextTraffic=“true”

• 50、說(shuō)說(shuō)項(xiàng)目中用到的設(shè)計(jì)模式和使用場(chǎng)景？

單例模式

常見(jiàn)應(yīng)用場(chǎng)景：網(wǎng)絡(luò)請(qǐng)求的工具類、sp存儲(chǔ)的工具類、彈窗的工具類等

工廠模式

常見(jiàn)應(yīng)用場(chǎng)景：activity的基類等

責(zé)任鏈模式

常見(jiàn)應(yīng)用場(chǎng)景：OKhttp的攔截器封裝

觀察者模式

常見(jiàn)應(yīng)用場(chǎng)景：Rxjava的運(yùn)用

代理模式

常見(jiàn)應(yīng)用場(chǎng)景：AIDL的使用

建造者模式

常見(jiàn)應(yīng)用場(chǎng)景：Dialog的創(chuàng)建

• 51、簡(jiǎn)述下熱修復(fù)的原理？

代碼修復(fù)主要有三個(gè)方案，分別是底層替換方案、類加載方案和Instant Run方案。3.1 類加載方案類加載方案基于Dex分包方案，什么是Dex分包方案呢？這個(gè)得先從65536限制和LinearAlloc限制說(shuō)起。
65536限制
隨著應(yīng)用功能越來(lái)越復(fù)雜，代碼量不斷地增大，引入的庫(kù)也越來(lái)越多，可能會(huì)在編譯時(shí)提示如下異常：com.android.dex.DexIndexOverflowException:methodIDnotin[0, 0xffff]: 65536

這說(shuō)明應(yīng)用中引用的方法數(shù)超過(guò)了最大數(shù)65536個(gè)。產(chǎn)生這一問(wèn)題的原因就是系統(tǒng)的65536限制，65536限制的主要原因是DVM Bytecode的限制，DVM指令集的方法調(diào)用指令invoke-kind索引為16bits，最多能引用 65535個(gè)方法。
LinearAlloc限制
在安裝時(shí)可能會(huì)提示INSTALL_FAILED_DEXOPT。產(chǎn)生的原因就是LinearAlloc限制，DVM中的LinearAlloc是一個(gè)固定的緩存區(qū)，當(dāng)方法數(shù)過(guò)多超出了緩存區(qū)的大小時(shí)會(huì)報(bào)錯(cuò)。為了解決65536限制和LinearAlloc限制，從而產(chǎn)生了Dex分包方案。Dex分包方案主要做的是在打包時(shí)將應(yīng)用代碼分成多個(gè)Dex，將應(yīng)用啟動(dòng)時(shí)必須用到的類和這些類的直接引用類放到主Dex中，其他代碼放到次Dex中。當(dāng)應(yīng)用啟動(dòng)時(shí)先加載主Dex，等到應(yīng)用啟動(dòng)后再動(dòng)態(tài)的加載次Dex，從而緩解了主Dex的65536限制和LinearAlloc限制。Dex分包方案主要有兩種，分別是Google官方方案、Dex自動(dòng)拆包和動(dòng)態(tài)加載方案；

熱更新 / 熱修復(fù)
不安裝新版本的軟件直接從網(wǎng)絡(luò)下載新功能模塊對(duì)軟件進(jìn)行局部更新
熱更新和插件化的區(qū)別
區(qū)別有兩點(diǎn):
1.插件化的內(nèi)容在原來(lái)的App中沒(méi)有,而熱更新在原來(lái) App 做了 改動(dòng)
2. 插件化在代碼中有固定的入口,而熱更新則可能改變?nèi)魏我粋€(gè)位置的代碼
熱更新的原理

classsLoder 的 dex 文件替換
直接修改字節(jié)碼文件
了解熱更新就必須了解 loadeClass() 的類加載過(guò)程

宏觀上: loadClass() 是一個(gè)帶緩存,自上而下的加載過(guò)程(即網(wǎng)上說(shuō)的[雙親委托機(jī)制])

對(duì)于一個(gè)具體的 ClassLoader

先從自己緩存中取
自己緩存沒(méi)有,就在 父 ClassLoader 要 (parent.loadClass())
父 View 沒(méi)有,就自加載(findClass)
BaseDexClassLoader 或者 它的子類(DexClassLoader,PathClassLoader) 的 findClass()

通過(guò)它的 pathList.findClass()
它的 pathList .loadClass() 通過(guò) pathClassLoader 等
所以熱更新關(guān)鍵在于,把補(bǔ)丁 dex 文件加載到 Element 對(duì)象插入到 dexElement 前面才行.插入后面會(huì)被忽閱掉
正確的做法是:反射

自己用補(bǔ)丁創(chuàng)建一個(gè)PathClassLoader
2.把補(bǔ)丁 PathClassLoader 里面的 elments 替換到舊的里面去
注意:
1.盡早加載熱更新(通用手段把加載過(guò)程放到Application.attachBaseContext())
把 補(bǔ)丁 PathClassLoader 里面的 elements 替換到舊的里面去
熱更新下載完成后在需要時(shí)先殺死進(jìn)程才能補(bǔ)丁生效
優(yōu)化:熱更新沒(méi)必要把所有的內(nèi)容都打過(guò)來(lái),只要把類拿過(guò)來(lái)就行了
d8 把 指定 的 class 打包 進(jìn) dex
5.完整化: 從網(wǎng)上加載
再優(yōu)化: 把打包過(guò)程寫(xiě)一個(gè)task

• 52、談?wù)剬?duì)于ConcurrentHashMap的理解？
  從JDK1.2起，就有了HashMap，正如前一篇文章所說(shuō)，HashMap不是線程安全的，因此多線程操作時(shí)需要格外小心。
  在JDK1.5中，偉大的Doug Lea給我們帶來(lái)了concurrent包，從此Map也有安全的了。
  ConcurrentHashMap具體是怎么實(shí)現(xiàn)線程安全的呢，肯定不可能是每個(gè)方法加synchronized，那樣就變成了HashTable。

從ConcurrentHashMap代碼中可以看出，它引入了一個(gè)“分段鎖”的概念，具體可以理解為把一個(gè)大的Map拆分成N個(gè)小的HashTable，根據(jù)key.hashCode()來(lái)決定把key放到哪個(gè)HashTable中。

在ConcurrentHashMap中，就是把Map分成了N個(gè)Segment，put和get的時(shí)候，都是現(xiàn)根據(jù)key.hashCode()算出放到哪個(gè)Segment中：
ConcurrentHashMap中默認(rèn)是把segments初始化為長(zhǎng)度為16的數(shù)組。
總結(jié)：以上就是ConcurrentHashMap的工作機(jī)制，通過(guò)把整個(gè)Map分為N個(gè)Segment（類似HashTable），可以提供相同的線程安全，但是效率提升N倍，默認(rèn)提升16倍。

• 53、Java 中深拷貝與淺拷貝的區(qū)別？
  首先需要明白，淺拷貝和深拷貝都是針對(duì)一個(gè)已有對(duì)象的操作。那先來(lái)看看淺拷貝和深拷貝的概念。在 Java 中，除了基本數(shù)據(jù)類型（元類型）之外，還存在 類的實(shí)例對(duì)象 這個(gè)引用數(shù)據(jù)類型。而一般使用 『 = 』號(hào)做賦值操作的時(shí)候。對(duì)于基本數(shù)據(jù)類型，實(shí)際上是拷貝的它的值，但是對(duì)于對(duì)象而言，其實(shí)賦值的只是這個(gè)對(duì)象的引用，將原對(duì)象的引用傳遞過(guò)去，他們實(shí)際上還是指向的同一個(gè)對(duì)象。而淺拷貝和深拷貝就是在這個(gè)基礎(chǔ)之上做的區(qū)分，如果在拷貝這個(gè)對(duì)象的時(shí)候，只對(duì)基本數(shù)據(jù)類型進(jìn)行了拷貝，而對(duì)引用數(shù)據(jù)類型只是進(jìn)行了引用的傳遞，而沒(méi)有真實(shí)的創(chuàng)建一個(gè)新的對(duì)象，則認(rèn)為是淺拷貝。反之，在對(duì)引用數(shù)據(jù)類型進(jìn)行拷貝的時(shí)候，創(chuàng)建了一個(gè)新的對(duì)象，并且復(fù)制其內(nèi)的成員變量，則認(rèn)為是深拷貝。所以到現(xiàn)在，就應(yīng)該了解了，所謂的淺拷貝和深拷貝，只是在拷貝對(duì)象的時(shí)候，對(duì) 類的實(shí)例對(duì)象 這種引用數(shù)據(jù)類型的不同操作而已。總結(jié)來(lái)說(shuō)：1、淺拷貝：對(duì)基本數(shù)據(jù)類型進(jìn)行值傳遞，對(duì)引用數(shù)據(jù)類型進(jìn)行引用傳遞般的拷貝，此為淺拷貝。2、深拷貝：對(duì)基本數(shù)據(jù)類型進(jìn)行值傳遞，對(duì)引用數(shù)據(jù)類型，創(chuàng)建一個(gè)新的對(duì)象，并復(fù)制其內(nèi)容，此為深拷貝。
• 54.談?wù)勅绾沃貙?xiě)equals()方法？為什么還要重寫(xiě)hashCode()？
  hashcode()
  （1）hashCode 的存在主要用于查找的快捷性，如 Hashtable, HashMap 等，hashCode 是用來(lái)在三列存儲(chǔ)結(jié)構(gòu)中確定對(duì)象的存儲(chǔ)地址的。
  （2）如果兩個(gè)對(duì)象相同，就是適用于 euqals(java.lang.Object) 方法，那么這兩個(gè)對(duì)象的 hashCode一定相同。
  （3）如果對(duì)象的euqals 方法被重寫(xiě)，那么對(duì)象的 hashCode 也盡量重寫(xiě)，并且產(chǎn)生 hashCode 使用的對(duì)象，一定要和 equals 方法中使用的一致，否則就會(huì)違反上面提到的第二點(diǎn)。
  （4）兩個(gè)對(duì)象的 hashCode 相同，并不一定表示這兩個(gè)對(duì)象就相同，也就是不一定適用于equals() 方法，只能夠說(shuō)明這兩個(gè)對(duì)象在三列存儲(chǔ)結(jié)構(gòu)中，如 Hashtable.,他們存在同一個(gè)籃子里。
• 55，說(shuō)一說(shuō)https,udp,socket區(qū)別？
  （1）TCP(Transmission Control Protocol,傳輸控制協(xié)議)與UDP(User Data Protocol,用戶數(shù)據(jù)協(xié)議)是互聯(lián)網(wǎng)傳輸數(shù)據(jù)較為常用的協(xié)議，我們熟知的HTTP就是基于TCP的.而HTTPS就是HTTP 加上SSL的加密方式：
  （2）UDP是非面向連接的協(xié)議，發(fā)送數(shù)據(jù)時(shí)不管對(duì)方狀態(tài)直接發(fā)送，無(wú)需建立連接，如同微信發(fā)送一個(gè)消息或者語(yǔ)音信息，對(duì)面在不在線無(wú)所謂.
  （3）Socket不屬于協(xié)議范疇，別名套接字通過(guò)調(diào)用Socket，才能使用TCP/IP協(xié)議，Socket連接是長(zhǎng)連接，理論上客戶端和服務(wù)器端一旦建立連接將不會(huì)主動(dòng)斷開(kāi)此連接。Socket連接屬于請(qǐng)求-響應(yīng)形式，服務(wù)端可主動(dòng)將消息推送給客戶端。
• 56，簡(jiǎn)要說(shuō)說(shuō) LruCache 的原理？
  LruCache 非常適合用于 緩存圖片，他的主要算法原理是包最近使用的對(duì)象 存儲(chǔ)在 LinckHashMap中，并且把最近使用的最少的對(duì)象在 緩存值達(dá)到預(yù)設(shè)值之前從內(nèi)存中移除

`public class LruCachePhoto { /** * 圖片 緩存技術(shù)的核心類，用于緩存下載好的所有圖片， * 在程序內(nèi)存達(dá)到設(shè)定值后會(huì)將最少最近使用的圖片移除掉 */ private LruCache<String, Bitmap> mMenoryCache;public LruCachePhoto() {//獲取應(yīng)用最大可用內(nèi)存int maxMemory = (int) Runtime.getRuntime().maxMemory();//設(shè)置 緩存文件大小為 程序最大可用內(nèi)存的 1/8int cacheSize = maxMemory / 8;mMenoryCache = new LruCache<String, Bitmap>(cacheSize) {@Overrideprotected int sizeOf(String key, Bitmap value) {return value.getByteCount();}}; }/*** 從 LruCache 中獲取一張圖片，如果不存在 就返回 null** @param key LurCache 的鍵，這里是 圖片的地址* @return 返回對(duì)應(yīng)的 Bitmap對(duì)象，找不到則為 null*/ public Bitmap getBitmapFromMemoryCache(String key) {return mMenoryCache.get(key); }/*** 添加一張圖片* * @param key key* @param bitmap bitmap*/ public void addBitmapToCache(String key, Bitmap bitmap) {if (getBitmapFromMemoryCache(key) == null) {mMenoryCache.put(key, bitmap);} } }`

• 57、談?wù)勗趺唇oapk瘦身？
  （1）res目錄優(yōu)化：將png格式轉(zhuǎn)webp或svg格式，
  保真壓縮圖片:可以使用一些圖片壓縮網(wǎng)站或者工具壓縮你的資源文件吧，例如TinyPng、ImageOptim、Zopfli、智圖等。
  （2）使用lint刪除無(wú)用資源:在多人開(kāi)發(fā)過(guò)程中，通常都會(huì)有漏刪無(wú)用資源的問(wèn)題，圖片資源也不例外，例如需要?jiǎng)h除一個(gè)模塊的代碼時(shí)，很容易就會(huì)漏刪資源文件，所以可以定期使用lint檢測(cè)出無(wú)用的資源文件，原理這里不作介紹，使用方法非常簡(jiǎn)單，可以直接在AS里面使用，如下圖所示。注意：lint檢查出來(lái)的資源都是無(wú)直接引用的，所以如果我們通過(guò)getIdentifier()方法引用文件時(shí)，lint也會(huì)標(biāo)記為無(wú)引用，所以刪除時(shí)注意不要?jiǎng)h除通過(guò)getIdentifier()引用的資源。
  （3）方法：Analyze -> Run Inspection by Name -> 輸入：Unused resources -> 跳出彈框選擇范圍即可
  （4）去掉無(wú)用資源：打開(kāi)shrinkResources
  shrinkResources是在編譯過(guò)程中用來(lái)檢測(cè)并刪除無(wú)用資源文件，也就是沒(méi)有引用的資源，minifyEnabled 這個(gè)是用來(lái)開(kāi)啟刪除無(wú)用代碼，比如沒(méi)有引用到的代碼，所以如果需要知道資源是否被引用就要配合minifyEnabled使用，只有兩者都為true時(shí)才會(huì)起到真正的刪除無(wú)效代碼和無(wú)引用資源的目的。打開(kāi)方式也是非常簡(jiǎn)單，在build.gralde文件里面打開(kāi)即可：
  android {
  buildTypes{
  minifyEnabled true
  shrinkResources true
  }
  }
  （5）Proguard代碼混淆：
  Proguard是一款免費(fèi)的Java類文件壓縮器、優(yōu)化器和混淆器，Android Studio已經(jīng)集成了這個(gè)工具，只要經(jīng)過(guò)簡(jiǎn)單的配置，即可完成，如下代碼所示，在build.gradle里面設(shè)置minifyEnabled為ture，同時(shí)在proguardFiles指向proguard的規(guī)則文件即可。
  android {
  buildTypes{
  minifyEnabled true
  proguardFiles ‘proguard.cfg’
  }
  }
• 58、JVM、Dalvik、ART三者的原理和區(qū)別？
  JVM：是Java Virtual Machine的縮寫(xiě)，其并不是指某個(gè)特定的虛擬機(jī)實(shí)現(xiàn)，而指任何能夠運(yùn)行Java字節(jié)碼（class文件）的虛擬機(jī)實(shí)現(xiàn)，比如oracle的Hotspot VM

Dalvik：是Google寫(xiě)的一個(gè)用于Android的虛擬機(jī)，但其嚴(yán)格來(lái)說(shuō)并不算JVM（沒(méi)有遵守Java虛擬機(jī)規(guī)范，比如其字節(jié)碼格式是dex而非class）
該虛擬機(jī)在5.0時(shí)被ART替代

ART：是Android Runtime的縮寫(xiě)，嚴(yán)格來(lái)說(shuō)并不是一個(gè)虛擬機(jī)，在4.4~6.0時(shí)采用安裝時(shí)全部編譯為機(jī)器碼的方式實(shí)現(xiàn)，7.0時(shí)默認(rèn)不全部編譯，采用解釋執(zhí)行+JIT+空閑時(shí)AOT以改善安裝耗時(shí)
ART在安卓4.4時(shí)加入，5.0取代dalvik作為唯一實(shí)現(xiàn)直到現(xiàn)在。

• 59、談?wù)勀闶侨绾蝺?yōu)化App啟動(dòng)過(guò)程的？
  （1）盡量不要在Application里做耗時(shí)操作，能放子線程的放子線程，能延后初始化的延后
  （2）啟動(dòng)頁(yè)可以做成一個(gè)view在主頁(yè)面加載，同時(shí)主頁(yè)面的一些操作可以在這個(gè)過(guò)程中開(kāi)始初始化
  （3）啟動(dòng)頁(yè)的view層級(jí)盡量簡(jiǎn)單

• 60、談一談單例模式，建造者模式，工廠模式的使用場(chǎng)景？如何合理選擇？
  （1）單例模式，一般是指將消耗內(nèi)存、屬性和對(duì)象支持全局公用的對(duì)象，應(yīng)該設(shè)置為單例模式，如持久化處理（網(wǎng)絡(luò)、文件等）
  （2）建造者模式，一般見(jiàn)于開(kāi)發(fā)的框架或者屬性時(shí)可以直接鏈?zhǔn)皆O(shè)置屬性，比如我們看到的AlertDialog，一般用在某些輔助類（如BRVAH的BaseViewHolder）或者開(kāi)發(fā)的框架的時(shí)候方便連續(xù)設(shè)置多個(gè)屬性和調(diào)用多個(gè)方法。
  （3）工廠模式，一般用于業(yè)務(wù)的實(shí)體創(chuàng)建，在創(chuàng)建的過(guò)程中考慮到后期的擴(kuò)展。在Android源碼中比較常見(jiàn)的有BitmapFactoryLayoutInflater.Factory,在實(shí)體編碼的過(guò)程中，比如BRVAH的多布局，如果數(shù)據(jù)類型比較多或者后期需要擴(kuò)展，則可以通過(guò)工廠布局的方式，將實(shí)現(xiàn)MultiItemEntity接口的實(shí)體通過(guò)工廠模式創(chuàng)建：

• 61、談?wù)劜季謨?yōu)化的技巧？
  1、降低Overdraw（過(guò)度繪制），減少不必要的背景繪制
  2、減少嵌套層次及控件個(gè)數(shù)
  3、使用Canvas的clipRect和clipPath方法限制View的繪制區(qū)域
  4、通過(guò)imageDrawable方法進(jìn)行設(shè)置避免ImageView的background和imageDrawable重疊
  5、借助ViewStub按需延遲加載
  6、選擇合適的布局類型
  7、熟悉API盡量借助系統(tǒng)現(xiàn)有的屬性來(lái)實(shí)現(xiàn)一些UI效果
  8、盡量減少控件個(gè)數(shù)，對(duì) TextView 左邊或者右邊有圖片可是試用 drawableLeft，drawableRight

• 61、說(shuō)一下線程的幾種狀態(tài)？
  1.初始(NEW) ，創(chuàng)建線程對(duì)象
  2.運(yùn)行(RUNNABLE)，此時(shí)就緒且正在運(yùn)行一起稱為運(yùn)行
  3.阻塞(BLOCKED)，線程阻塞
  4.等待(WAITING)，等待中斷等操作
  5.超時(shí)等待(TIMED_WAITING)，可以指定時(shí)間返回，不一定需要操作
  6.終止(TERMINATED)，線程執(zhí)行完畢

• 62、簡(jiǎn)單介紹下ContentProvider是如何實(shí)現(xiàn)數(shù)據(jù)共享的？
  使用 ContentProvider 可以將數(shù)據(jù)共享給其他應(yīng)用，讓除本應(yīng)用之外的應(yīng)用也可以訪問(wèn)本應(yīng)用的數(shù)據(jù)。它的底層是用 SQLite 數(shù)據(jù)庫(kù)實(shí)現(xiàn)的，所以其對(duì)數(shù)據(jù)做的各種操作都是以 Sql 實(shí)現(xiàn)，只是在上層提供的是 Uri，用戶只需要關(guān)心操作數(shù)據(jù)的 uri 就可以了,ContentProvider 可以實(shí)現(xiàn)不同 app 之間共享。詳細(xì)使用見(jiàn)ContentProvider跨程序共享數(shù)據(jù)（一）

• 63、談?wù)凙pp的電量?jī)?yōu)化？
  (1)GPS

——使用要謹(jǐn)慎，如精確度不高可用WiFi定位或者基站定位，可用；非要用的話，注意定位數(shù)據(jù)的復(fù)用和定位頻率的閾值

(2)Process和Service

——按需啟動(dòng)，用完就退出

(3)網(wǎng)絡(luò)數(shù)據(jù)交互

——減少網(wǎng)絡(luò)網(wǎng)絡(luò)請(qǐng)求次數(shù)和數(shù)據(jù)量；WiFi比手機(jī)網(wǎng)絡(luò)省電

(4)CPU

——減少I(mǎi)/O操作（包括數(shù)據(jù)庫(kù)操作），減少大量的計(jì)算

(5)減少手機(jī)硬件交互

——使用頻率優(yōu)化和選擇低功耗模式
（6）避免輪循。可以利用推送。如果非要輪循，合理的設(shè)置頻率。
應(yīng)用處于后臺(tái)時(shí)，避免某些數(shù)據(jù)的傳輸，比如感應(yīng)器，定位，視頻緩存。
頁(yè)面銷毀時(shí)，取消掉網(wǎng)絡(luò)請(qǐng)求。
限制訪問(wèn)頻率，失敗后不要無(wú)限的重連。
合理的選擇定位精度和頻率。
使用緩存。如果數(shù)據(jù)變化周期比較長(zhǎng)，可以出一個(gè)配置接口，用于記錄那些接口有變化。沒(méi)變化的直接用緩存。
減少?gòu)V播的使用頻率。可以用觀察者，startActivityForResult等代替。

• 64、Java 線程中notify 和 notifyAll有什么區(qū)別？
  當(dāng)線程狀態(tài)為等待、超時(shí)等待會(huì)調(diào)用notify 和 notifyAll方法通知線程更改狀態(tài)，此時(shí)
  當(dāng)線程數(shù)量為1時(shí)，notify 和 notifyAll的效果一樣，會(huì)喚醒一個(gè)線程，并獲取鎖
  當(dāng)線程數(shù)量大于1時(shí)，notify會(huì)喚醒一個(gè)線程，并獲取鎖，notifyAll會(huì)喚醒所有線程并根據(jù)算法選取其中一個(gè)線程獲取鎖，區(qū)別在于此時(shí)使用notify可能會(huì)出現(xiàn)死鎖的情況

• 65、談一談你對(duì)binder的機(jī)制的理解？
  Binder機(jī)制：
  1.為了保證進(jìn)程空間不被其他進(jìn)程破壞或干擾，Linux中的進(jìn)程是相互獨(dú)立或相互隔離的。
  2.進(jìn)程空間分為用戶空間和內(nèi)核空間。用戶空間不可以進(jìn)行數(shù)據(jù)交互；內(nèi)核空間可以進(jìn)行數(shù)據(jù)交互，所有進(jìn)程共用一個(gè)內(nèi)核空間。
  3.Binder機(jī)制相對(duì)于Linux內(nèi)傳統(tǒng)的進(jìn)程間通信方式：（1）性能更好；Binder機(jī)制只需要拷貝數(shù)據(jù)一次，管道、消息隊(duì)列、Socket等都需要拷貝數(shù)據(jù)兩次；而共享內(nèi)存雖然不需要拷貝，但實(shí)現(xiàn)復(fù)雜度高。（2）安全性更高；Binder機(jī)制通過(guò)UID/PID在內(nèi)核空間添加了身份標(biāo)識(shí)，安全性更高。
  4.Binder跨進(jìn)程通信機(jī)制：基于C/S架構(gòu)，由Client、Server、Server Manager和Binder驅(qū)動(dòng)組成。
  5.Binder驅(qū)動(dòng)實(shí)現(xiàn)的原理：通過(guò)內(nèi)存映射，即系統(tǒng)調(diào)用了mmap（）函數(shù)。
  6.Server Manager的作用：管理Service的注冊(cè)和查詢。
  7.Binder驅(qū)動(dòng)的作用：（1）傳遞進(jìn)程間的數(shù)據(jù)，通過(guò)系統(tǒng)調(diào)用mmap（）函數(shù)；（2）實(shí)現(xiàn)線程的控制，通過(guò)Binder驅(qū)動(dòng)的線程池，并由Binder驅(qū)動(dòng)自身進(jìn)行管理。
  8.Server進(jìn)程會(huì)創(chuàng)建很多線程處理Binder請(qǐng)求，這些線程采用Binder驅(qū)動(dòng)的線程池，由Binder驅(qū)動(dòng)自身進(jìn)行管理。一個(gè)進(jìn)程的Binder線程池默認(rèn)最大是16個(gè)，超過(guò)的請(qǐng)求會(huì)阻塞等待空閑的線程。
  9.Android中進(jìn)行進(jìn)程間通信主要通過(guò)Binder類（已經(jīng)實(shí)現(xiàn)了IBinder接口），即具備了跨進(jìn)程通信的能力。

• 66、什么是線程池？如何創(chuàng)建一個(gè)線程池？
  線程池：
  1.線程池：創(chuàng)建多個(gè)線程，并管理線程，為線程分配任務(wù)并執(zhí)行。
  2.使用線程池的好處：多個(gè)線程的創(chuàng)建會(huì)占用過(guò)多的系統(tǒng)資源，造成死鎖或OOM
  3.線程池的作用：（1）可以復(fù)用創(chuàng)建好的線程，減少線程的創(chuàng)建或銷毀的開(kāi)銷；（2）提高響應(yīng)速度，當(dāng)任務(wù)到達(dá)時(shí)，不需要等待就可以立即執(zhí)行；（3）可有效控制最大并發(fā)的線程數(shù)，提高系統(tǒng)資源的利用率。防止死鎖或OOM；（4）可以提供定時(shí)和定期的執(zhí)行方式。
  4.線程池參數(shù)：corePoolSize（核心線程數(shù)）、maximumPoolSize（最大線程數(shù)）、workQueue（阻塞隊(duì)列）、keepAliveTime（保活時(shí)間）、threadFactory（線程工廠，用于生成線程）。
  5.線程池提交任務(wù)：有兩個(gè)方法可以向線程池提交任務(wù)，分別是execute（）和submit（）。
  execute（）：用于提交不需要返回值的任務(wù)，無(wú)法判斷任務(wù)是否被線程執(zhí)行成功。
  submit（）：用于提交需要返回值的任務(wù)，會(huì)返回一個(gè)future類型的對(duì)象，來(lái)判斷任務(wù)是否執(zhí)行成功，還可以通過(guò)future的get（）方法獲取返回值，get（）方法會(huì)阻塞當(dāng)前線程直到任務(wù)完成。
  5.線程池的工作流程：
  （1）有新任務(wù)時(shí)，判斷當(dāng)前線程數(shù)是否超過(guò)corePoolSize，如果小于corePoolSize，即使有空閑線程可以執(zhí)行任務(wù)，也會(huì)創(chuàng)建一個(gè)新的線程用來(lái)執(zhí)行該任務(wù)；
  （2）如果超過(guò)corePoolSize，就把任務(wù)放在workQueue(阻塞隊(duì)列)中，等待被執(zhí)行，前提是workQueue是有界隊(duì)列；
  （3）如果workQueue滿了，判斷當(dāng)前線程數(shù)是否小于maximumPoolSize，如果小于maximumPoolSize就創(chuàng)建一個(gè)線程用來(lái)執(zhí)行任務(wù)。
  （4）如果當(dāng)前線程數(shù)大于maximumPoolSize，就會(huì)執(zhí)行線程池的飽和策略。
  6.線程池的飽和策略：（1）默認(rèn)策略：直接拋出異常；（2）用調(diào)用者所在的線程（提交任務(wù)的那個(gè)線程）執(zhí)行任務(wù)；（3）丟棄阻塞隊(duì)列中最靠前的任務(wù)，執(zhí)行當(dāng)前任務(wù)；（4）直接丟棄任務(wù)。
  7.線程池的狀態(tài)：
  （1）RUNNING：接收提交的任務(wù)。
  （2）SHUTDOWN：不再接收新提交的任務(wù)，繼續(xù)處理阻塞隊(duì)列中的任務(wù)。
  （3）STOP：不再接收新的任務(wù)，也不會(huì)處理阻塞隊(duì)列中的任務(wù)，并會(huì)終止正在執(zhí)行的任務(wù)。
  （4）TIDYING：所有的任務(wù)已終止，ctl記錄的任務(wù)數(shù)量為0，會(huì)執(zhí)行鉤子函數(shù)terminated()。
  （5）TERMINATED：線程池徹底終止。
  8.關(guān)閉線程池的方法：ThreadPoolExecutor提供了兩個(gè)方法，用于線程池的關(guān)閉，分別是shutdown（）和shutdownNow（）。
  原理：都是循環(huán)遍歷線程池的工作線程，然后依次調(diào)用線程的intercept（）方法來(lái)中斷線程。
  shutdown（）：將線程池狀態(tài)設(shè)置為SHUTDOWN。
  shutdownNow（）：將線程池狀態(tài)設(shè)置為STOP。

• 67、給View設(shè)置的透明度的三種方法
  1，java代碼實(shí)現(xiàn)

text = (TextView) findViewById(R.id.text); text.getBackground().setAlpha(12);

setAlpha()的括號(hào)中可以填0–255之間的數(shù)字。數(shù)字越大，越不透明。

注意點(diǎn)：在5.0以上系統(tǒng)時(shí)，有些機(jī)型會(huì)出現(xiàn)莫名其妙的顏色值不起作用，變成透明了，也就是用此方法會(huì)導(dǎo)致其他共用一個(gè)資源的布局（例如：@color/white）透明度也跟著改變。
比如text用上述方法設(shè)置成透明后，項(xiàng)目中，其他用到text顏色值的控件，都變成透明了。
原因：在布局中多個(gè)控件同時(shí)使用一個(gè)資源的時(shí)候，這些控件會(huì)共用一個(gè)狀態(tài)，例如ColorState，如果你改變了一個(gè)控件的狀態(tài)，其他的控件都會(huì)接收到相同的通知。這時(shí)我們可以使用mutate()方法使該控件狀態(tài)不定，這樣不定狀態(tài)的控件就不會(huì)共享自己的狀態(tài)了。

text.getBackground().mutate().setAlpha(12);

2，在xml布局中進(jìn)行設(shè)置

<TextViewandroid:id="@ id/text"android:text="Hello World!"android:background="#FFFFFF"android:layout_width="match_parent"android:alpha="0.6"android:layout_height="100dp" />

android:alpha的值為0~1之間的數(shù)。數(shù)字越大，越不透明。1表示完全不透明，0表示完全透明。

3,在xml布局中通過(guò)android:background設(shè)置

<TextViewandroid:id="@ id/text"android:text="Hello World!"android:background="#52FFFFFF"android:layout_width="match_parent"android:layout_height="100dp" />

顏色和不透明度 (alpha) 值以十六進(jìn)制表示法表示。任何一種顏色的值范圍都是 0 到 255(00 到 ff)。對(duì)于 alpha，00 表示完全透明，ff 表示完全不透明。android:background的值的格式為”#AARRGGBB”。AA即透明度，R、G、B是紅綠藍(lán)三色。每一位均為0–F的十六位數(shù)。其中透明度的數(shù)值越大，越不透明
java代碼

//java代碼生成的對(duì)應(yīng)表 for (int i = 100; i>=0; i--) {double j = (i / 100.0d);int alpha = (int) Math.round(255-j * 255);String hex = Integer.toHexString(alpha).toUpperCase();if (hex.length() == 1) hex = "0" + hex;int percent = (int) (j*100);System.out.println(String.format("%d%% — %s", percent, hex)); }

透明度對(duì)照表
透明度 16進(jìn)制表示
100% 00（全透明）
99% 03
98% 05
97% 07
96% 0A
95% 0D
94% 0F
93% 12
92% 14
91% 17
90% 1A
89% 1C
88% 1E
87% 21
86% 24
85% 26
84% 29
83% 2B
82% 2E
81% 30
80% 33
79% 36
78% 38
77% 3B
76% 3D
75% 40
74% 42
73% 45
72% 47
71% 4A
70% 4D
69% 4F
68% 52
67% 54
66% 57
65% 59
64% 5C
63% 5E
62% 61
61% 63
60% 66
59% 69
58% 6B
57% 6E
56% 70
55% 73
54% 75
53% 78
52% 7A
51% 7D
50% 80
49% 82
48% 85
47% 87
46% 8A
45% 8C
44% 8F
43% 91
42% 94
41% 96
40% 99
39% 9C
38% 9E
37% A1
36% A3
35% A6
34% A8
33% AB
32% AD
31% B0
30% B3
29% B5
28% B8
27% BA
26% BD
25% BF
24% C2
23% C4
22% C7
21% C9
20% CC
19% CF
18% D1
17% D4
16% D6
15% D9
14% DB
13% DE
12% E0
11% E3
10% E6
9% E8
8% EB
7% ED
6% F0
5% F2
4% F5
3% F7
2% FA
1% FC
0% FF（完全不透明）

不透明度對(duì)照表
不透明度—十六進(jìn)制值
100% — FF（完全不透明）
99% — FC
98% — FA
97% — F7
96% — F5
95% — F2
94% — F0
93% — ED
92% — EB
91% — E8
90% — E6
89% — E3
88% — E0
87% — DE
86% — DB
85% — D9
84% — D6
83% — D4
82% — D1
81% — CF
80% — CC
79% — C9
78% — C7
77% — C4
76% — C2
75% — BF
74% — BD
73% — BA
72% — B8
71% — B5
70% — B3
69% — B0
68% — AD
67% — AB
66% — A8
65% — A6
64% — A3
63% — A1
62% — 9E
61% — 9C
60% — 99
59% — 96
58% — 94
57% — 91
56% — 8F
55% — 8C
54% — 8A
53% — 87
52% — 85
51% — 82
50% — 80
49% — 7D
48% — 7A
47% — 78
46% — 75
45% — 73
44% — 70
43% — 6E
42% — 6B
41% — 69
40% — 66
39% — 63
38% — 61
37% — 5E
36% — 5C
35% — 59
34% — 57
33% — 54
32% — 52
31% — 4F
30% — 4D
29% — 4A
28% — 47
27% — 45
26% — 42
25% — 40
24% — 3D
23% — 3B
22% — 38
21% — 36
20% — 33
19% — 30
18% — 2E
17% — 2B
16% — 29
15% — 26
14% — 24
13% — 21
12% — 1F
11% — 1C
10% — 1A
9% — 17
8% — 14
7% — 12
6% — 0F
5% — 0D
4% — 0A
3% — 08
2% — 05
1% — 03
0% — 00（全透明）

總結(jié)

以上是生活随笔為你收集整理的Android 面试题笔记（一）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。