應屆畢業(yè)生可以去刷算法來拿到不錯的offer宪躯，但社招不行乔宿。

技術要求面試前的準備

• 良好的開發(fā)習慣
• 獨立思考的能力
• 主動并且善于溝通

高級安卓所要掌握的知識點。

• 一访雪，基本知識點
• 二详瑞，深入知識點
• 三，基本知識點的細節(jié)
• 四臣缀，系統(tǒng)核心機制

如果遇到自己不懂的問題坝橡，絕對不能說不知道。就算不知道精置，也要把面試官的問題计寇。復述一遍，拆解成123小點來脂倦。闡述自己知道的東西番宁，顯示自己的能力。

感悟
1.選一個自己比較擅長的領域(比如網(wǎng)絡框架OKhttp)去了解它的內部實現(xiàn)赖阻，用流程圖畫出調用邏輯
2.基礎要背蝶押，安卓四大組件，常用API火欧，要把它背的滾瓜亂熟棋电。
3.試著去了解這個領域市面上的技術(熱更新，rxjava 等)
4.如果有時間研究布隔，其中一個眾所周知的庫的源碼离陶。

Activity面試詳解

1.Activity生命周期

Activity的四種狀態(tài)：running/paused/stoped/killed

onCreate : 該方法是在Activity被創(chuàng)建時回調，它是生命周期第一個調用的方法衅檀，我們在創(chuàng)建Activity時一般都需要重寫該方法招刨，然后在該方法中做一些初始化的操作，如通過setContentView設置界面布局的資源哀军，初始化所需要的組件信息等沉眶。
onStart : 此方法被回調時表示Activity正在啟動，此時Activity已處于可見狀態(tài)杉适，只是還沒有在前臺顯示谎倔，因此無法與用戶進行交互。可以簡單理解為Activity已顯示而我們無法看見擺了。
onResume : 當此方法回調時榄鉴，則說明Activity已在前臺可見土砂，可與用戶交互了（處于前面所說的Active/Running形態(tài)），onResume方法與onStart的相同點是兩者都表示Activity可見匆光，只不過onStart回調時Activity還是后臺無法與用戶交互采转，而onResume則已顯示在前臺堡纬，可與用戶交互孽查。當然從流程圖饥悴，我們也可以看出當Activity停止后（onPause方法和onStop方法被調用），重新回到前臺時也會調用onResume方法盲再，因此我們也可以在onResume方法中初始化一些資源西设，比如重新初始化在onPause或者onStop方法中釋放的資源。
onPause : 此方法被回調時則表示Activity正在停止（Paused形態(tài)）答朋，一般情況下onStop方法會緊接著被回調贷揽。但通過流程圖我們還可以看到一種情況是onPause方法執(zhí)行后直接執(zhí)行了onResume方法，這屬于比較極端的現(xiàn)象了绿映，這可能是用戶操作使當前Activity退居后臺后又迅速地再回到到當前的Activity擒滑，此時onResume方法就會被回調腐晾。當然叉弦，在onPause方法中我們可以做一些數(shù)據(jù)存儲或者動畫停止或者資源回收的操作，但是不能太耗時藻糖，因為這可能會影響到新的Activity的顯示——onPause方法執(zhí)行完成后淹冰，新Activity的onResume方法才會被執(zhí)行。
onStop : 一般在onPause方法執(zhí)行完成直接執(zhí)行巨柒，表示Activity即將停止或者完全被覆蓋（Stopped形態(tài)）樱拴，此時Activity不可見，僅在后臺運行洋满。同樣地晶乔，在onStop方法可以做一些資源釋放的操作（不能太耗時）。
onRestart :表示Activity正在重新啟動牺勾，當Activity由不可見變?yōu)榭梢姞顟B(tài)時正罢，該方法被回調。這種情況一般是用戶打開了一個新的Activity時驻民，當前的Activity就會被暫停（onPause和onStop被執(zhí)行了）翻具，接著又回到當前Activity頁面時，onRestart方法就會被回調回还。
onDestroy :此時Activity正在被銷毀裆泳，也是生命周期最后一個執(zhí)行的方法，一般我們可以在此方法中做一些回收工作和最終的資源釋放柠硕。

android進程優(yōu)先級：前臺/可見/服務/后臺/空

2.Android任務棧

一個應用程序當中通常都會包含很多個Activity工禾，每個Activity都應該設計成為一個具有特定的功能，并且可以讓用戶進行操作的組件。另外闻葵，Activity之間還應該是可以相互啟動的糙捺。

除此之外，一個Activity甚至還可以去啟動其它應用程序當中的Activity笙隙。打個比方洪灯，如果你的應用希望去發(fā)送一封郵件，你就可以定義一個具有"send"動作的Intent竟痰，并且傳入一些數(shù)據(jù)签钩，如對方郵箱地址、郵件內容等坏快。這樣铅檩，如果另外一個應用程序中的某個Activity聲明自己是可以響應這種Intent的，那么這個Activity就會被打開莽鸿。在當前場景下昧旨，這個Intent是為了要發(fā)送郵件的，所以說郵件應用程序當中的編寫郵件Activity就應該被打開祥得。當郵件發(fā)送出去之后兔沃，仍然還是會回到你的應用程序當中，這讓用戶看起來好像剛才那個編寫郵件的Activity就是你的應用程序當中的一部分级及。所以說乒疏，即使有很多個Activity分別都是來自于不同應用程序的，Android系統(tǒng)仍然可以將它們無縫地結合到一起饮焦，之所以能實現(xiàn)這一點怕吴，就是因為這些Activity都是存在于一個相同的任務(Task)當中的。

3.Activity啟動模式

• standard：默認
• singletop：棧頂復用,onNewIntent()會被調用
• singletask:棧內復用,onNewIntent()會被調用
• singleinstance:只有一個實例,獨享任務棧
  4.scheme跳轉協(xié)議

android中的scheme是一種頁面內跳轉協(xié)議县踢，應用場景：
服務端下發(fā)一個url路徑转绷，客戶端根據(jù)此路徑，跳轉到相應的頁面
從H5頁面跳轉到相應app的activity
app根據(jù)url跳轉到另一個app

Fragment

1.Fragment為什么被成為第五大組件

使用頻率高硼啤，并且有聲明周期议经，相比activity更節(jié)省內存,UI切換效果也更加舒適。

2.Fragment加載到Activity的兩種方式

靜態(tài)加載丙曙。添加到Fragment到Activity的布局文件當中,Fragment作為xml的標簽
動態(tài)加載爸业。動態(tài)在activity中添加fragment,用fragmentManager,利用容器資源id表示位來確定位置

3.FragmentPagerAdapter與FragmentStatePagerAdapter的區(qū)別

FragmentPagerAdapter適用于頁面較少的情況，F(xiàn)ragmentStatePagerAdapter適用于頁面較多的情況亏镰。
FragmentStatePagerAdapter源碼中的destoryItem()方法是調用了Fragment事務管理器的remove()扯旷，釋放了Fragment所占的內存；FragmentPagerAdapter的destoryItem()內則調用了Fragment事務管理器的detach(),只是將Fragment與Activity分離索抓，并不回收內存

4.Fragment的生命周期

image.png

onAttach()
onCreate():用于創(chuàng)建Fragment
onCreateView():繪制Fragment UI
onViewCreated():Fragment UI已繪制好钧忽，可以初始化Fragment里的控件資源

5.Fragment通信

1.在Fragment中調用Activity中的方法getActivity()
2.在Activity中調用Fragment中的方法 使用接口回調
3.在Fragment中調用Fragment中的方法 首先通過getActivity()毯炮，然后調用findFragmentById()

Service

Service是什么？

是一個一種可以在后臺執(zhí)行長時間運行操作而沒有用戶界面的應用組件耸黑。不能做耗時操作Ｌ壹濉！

service和Thread的區(qū)別

• Thread程序執(zhí)行的最小單元大刊，相對獨立为迈，Service是Android的四大組件之一，被用來執(zhí)行長時間的后臺任務缺菌。默認情況下Service是運行在主線程中的葫辐。

• 他們之間沒有任何關聯(lián)，android中后臺與子線程是不同的概念伴郁，android的后臺指完全不依賴于UI線程耿战，即使activity被銷毀了，服務進程仍然存在運行焊傅；service不能做耗時操作

• 應用場景上剂陡，當需要去訪問網(wǎng)絡、文件查詢狐胎，都應開啟子線程去操作鸭栖，避免UI阻塞；而service主要是用來長時間在后臺運行顽爹，而不需要交互的情況下纤泵，如后臺播放音樂、天氣預報的統(tǒng)計

• 如果需要執(zhí)行復雜耗時的操作镜粤，必須在Service中再創(chuàng)建一個Thread來執(zhí)行任務。Service的優(yōu)先級高于后臺掛起的Activity玻褪，當然也高于Activity所創(chuàng)建的Thread肉渴，因此，系統(tǒng)可能在內存不足的時候優(yōu)先殺死后臺的Activity或者Thread带射，而不會輕易殺死Service組件同规，即使被迫殺死Service，也會在資源可用時重啟被殺死的Service窟社。

詳解參考：https://blog.csdn.net/mynameishuangshuai/article/details/51821662

service的啟動方式

1.startService()：

①券勺，定義一個類繼承Service;
②，在清單文件中配置改service灿里；
③关炼，使用Context的startService(intent)方法啟動該服務；
④匣吊，不再使用時儒拂，調用stopService(intent)方法停止該服務寸潦。

注意onStartCommand()的返回值，START_STICKY:系統(tǒng)因內存不足殺死service社痛，一段時間內存充足后见转，會重新啟動該service

2.bindService()

綁定服務的時候，服務和Activity處于綁定狀態(tài)蒜哀。允許Activity和Service進行數(shù)據(jù)交互（客戶端和服務端）斩箫。發(fā)送請求獲取結果等。甚至服務在不同進程間的時候撵儿⌒＝梗可以進行進程間通信傳輸數(shù)據(jù)。多個界面可以綁定同一個服務统倒。當綁定全部取消寨典，服務會自動被銷毀。不必像startService(）房匆，要stopService（）耸成。

步驟：
1.創(chuàng)建BindService服務端，繼承自Service并在類中浴鸿，創(chuàng)建一個實現(xiàn)IBinder接口的實例對象井氢，并提供公共方法給客戶端調用
2.從onBind()回調方法返回此Binder實例；
3.在客戶端中岳链，從onServiceConnected()回調方法接收Binder,并使用提供的方法調用綁定服務花竞。

BroadcaseReceiver

在android中，broadcast是一種廣泛運用的在應用程序之間傳輸信息的機制掸哑，android中我們要發(fā)送的廣播內容是一個Intent约急，這個Intent中可以攜帶我們要傳送的數(shù)據(jù)。

廣播的場景

同一app具有多個進程的不同組件之間的消息通信
不同app之間的組件之間消息通信

廣播的種類
Normal Broadcast:Context.sendBroadcast
System Broadcast:Context.sendOrderedBroadcast
Local Broadcast:只在自身App內傳播

實現(xiàn)廣播-receiver

靜態(tài)注冊：注冊完成就一直運行,在清單文件中
動態(tài)注冊：跟隨activity的生命周期

內部實現(xiàn)機制

1.自定義廣播接收者BroadcastReceiver苗分，并復寫onReceive()方法厌蔽；
2.通過Binder機制（android進程間通信的核心，整體架構是C/S結構摔癣，）向AMS（Activity Manager Service奴饮，負責四大機制的啟動、切換择浊、調度）進行注冊戴卜；
3.廣播發(fā)送者通過Binder機制向AMS發(fā)送廣播；
4.AMS查找符合相應條件(IntentFilter/Permission等)的BroadcastReceiver琢岩，將廣播發(fā)送到BraodcastReceiver（一般情況 下是Activity）相應的消息循環(huán)隊列中投剥；
5.消息循環(huán)執(zhí)行拿到此廣播，回調BroadcastReceiver中的onReceive()方法

LocalBroadcastManager詳解

1.使用它發(fā)送的廣播將只有在自身App內傳播粘捎，因此不必擔心泄漏隱私數(shù)據(jù)
2.其他App無法對你的App發(fā)送該廣播薇缅，因為你的App根本就不可能接收到非自身應用發(fā)送的廣播危彩，因此你不必擔心有安全漏洞可以利用
3.比系統(tǒng)的全局廣播更加高效

LocalBroadcastManager源碼分析:

1.LocalBroadcastManager高效的原因主要是因為它內部是通過Handler實現(xiàn)的，它的sendBroadcast()方法含義并非和我們平時所用的一樣泳桦，他的sendBroadcast()方法其實是通過handler發(fā)送一個Message實現(xiàn)的汤徽。
2.既然它內部是通過Handler來實現(xiàn)廣播發(fā)送，那么相比與系統(tǒng)廣播通過Binder實現(xiàn)灸撰，那肯定是更高效了谒府，同時使用Handler來實現(xiàn)，別的應用無法向我們的應用發(fā)送該廣播浮毯，而我們應用內發(fā)送的廣播也不會離開我們的應用
3.LocalBroadcastManager內部協(xié)作主要是靠這兩個Map集合：mReceivers和mActions完疫，當然還有一個List集合mPendingBroadcasts，這個主要就是存儲待接收的廣播對象

Binder

Binder是Android跨進程通信方式债蓝，它實現(xiàn)了IBinder接口壳鹤，是ServiceManager連接各種Manager(如WindowManager、ActivityManager等)的橋梁
參考：https://blog.csdn.net/huachao1001/article/details/51504469