二、組件
1葱她、Activity----------1?
分析篇：全面了解Activity
問題：Activity生命周期及流程圖吨些；
問題：介紹Activity的幾種啟動模式，并簡單說說自己的理解或者使用場景黔寇；
1.standard:默認(rèn)標(biāo)準(zhǔn)模式屏轰，每啟動一個都會創(chuàng)建一個實(shí)例霎苗，
2.singleTop：棧頂復(fù)用唁盏，如果在棧頂就調(diào)用onNewIntent復(fù)用厘擂，從onResume()開始
3.singleTask：棧內(nèi)復(fù)用驴党，本棧內(nèi)只要用該類型Activity就會調(diào)到棧頂復(fù)用港庄，從onResume()開始
4.singleInstance：單例模式鹏氧，除了3中特性把还，系統(tǒng)會單獨(dú)給該Activity創(chuàng)建一個棧吊履，
問題：Activity傳遞參數(shù)
問題：Activity中如何動態(tài)的添加Fragment
FragmentManager mFragmentManager = getSupportFragmentManager(); //獲取支持包中的FragmentManager();
ExampleFragment mExampleFragment =newmExampleFragment(); //動態(tài)添加的Fragment
FragmentTransaction fragmentTransaction = mFragmentManager.beginTransaction(); //通過beginTransaction()獲取fragmentTransaction
fragmentTransaction.add(R.id.new_panel, mExampleFragment); //向view中添加指定的Fragment
fragmentTransaction.commit(); //更新完成后不要忘記了commit()哦;
知識點(diǎn)：鎖定屏與解鎖屏幕只會調(diào)用onPause()艇炎，而不會調(diào)用onStop方法缀踪，開屏后則調(diào)用onResume()（經(jīng)自己實(shí)際測試小米上會調(diào)用onStop）驴娃；
問題：內(nèi)存不足時系統(tǒng)會殺掉后臺的Activity唇敞，若需要進(jìn)行一些臨時狀態(tài)的保存厚棵，在哪個方法進(jìn)行
Activity的 onSaveInstanceState() 和 onRestoreInstanceState()并不是生命周期方法向楼，它們不同于 onCreate()灭返、onPause()等生命周期方法黔衡，它們并不一定會被觸發(fā)硝岗。當(dāng)應(yīng)用遇到意外情況（如：內(nèi)存不足仓坞、用戶直接按Home鍵）由系統(tǒng)銷毀一個Activity，onSaveInstanceState() 會被調(diào)用伍派。但是當(dāng)用戶主動去銷毀一個Activity時，例如在應(yīng)用中按返回鍵，onSaveInstanceState()就不會被調(diào)用碉纺。除非該activity是被用戶主動銷毀的骨田，通常onSaveInstanceState()只適合用于保存一些臨時性的狀態(tài)态贤，而onPause()適合用于數(shù)據(jù)的持久化保存抵卫。
問題：onSaveInstanceState()被執(zhí)行的場景有哪些介粘；
系統(tǒng)不知道你按下HOME后要運(yùn)行多少其他的程序姻采，自然也不知道activity A是否會被銷毀婚瓜，因此系統(tǒng)都會調(diào)用onSaveInstanceState()巴刻，讓用戶有機(jī)會保存某些非永久性的數(shù)據(jù)胡陪。以下幾種情況的分析都遵循該原則
1.當(dāng)用戶按下HOME鍵時柠座；2.長按HOME鍵妈经，選擇運(yùn)行其他的程序時吹泡；3.鎖屏?xí)r荞胡；4.從activity A中啟動一個新的activity時泪漂；5.屏幕方向切換時萝勤。
問題：Activity場景記錄及恢復(fù)的原理
問題：Activity緩存方法：
1.配置改變導(dǎo)致Activity被殺死，橫屏變豎屏：在onStop之前會調(diào)用onSaveInstanceState()保存數(shù)據(jù)在重建Activity之后趟径，會在onStart()之后調(diào)用onRestoreInstanceState(),并把保存下來的Bundle傳給onCreate()和它會默認(rèn)重建Activity當(dāng)前的視圖蜗巧，我們可以在onCreate()中幕屹，回復(fù)自己的數(shù)據(jù)望拖。
2.內(nèi)存不足殺掉Activity鸥跟，優(yōu)先級分別是：前臺可見医咨，可見非前臺，后臺侈贷。
問題：同一個應(yīng)用程序的不同Activity可以運(yùn)行在不同的進(jìn)程中么俏蛮？如果可以，舉例說明辣恋；
問題：Activity怎樣加速啟動
1伟骨、要顯示的activity的onCreate（）方法中不要進(jìn)行耗時操作携狭，減小主線程的阻塞時間逛腿。初始化的一次性操作可以放到onresume中碘举。
2殴俱、前一個activity的onpause不要做耗時操作
3线欲、優(yōu)化布局文件李丰， 如果我們的布局層次嵌套過多,那么view繪制的時間和findViewById的時間必然會變多。
4嗜憔、使用多線程異步逐漸顯示view
問題：怎樣退出終止APP
問題：Activity切換動畫
1吉捶、在android:theme 主題里設(shè)置android:windowAnimationStyle
2、使用overridePendingTransition函數(shù)
2珊拼、Service----------1
分析篇：Service全面總結(jié)
問題：Service的生命周期揭斧，兩種啟動方法讹开，有什么區(qū)別：
1.context.startService() ->onCreate()- >onStart()->Service running-->(如果調(diào)用context.stopService() )->onDestroy() ->Service shut down
1.如果Service還沒有運(yùn)行闹击，則調(diào)用onCreate()然后調(diào)用onStart()赏半；
2.如果Service已經(jīng)運(yùn)行断箫，則只調(diào)用onStart()，所以一個Service的onStart方法可能會重復(fù)調(diào)用多次埃撵。
3.調(diào)用stopService的時候直接onDestroy暂刘，
4.如果是調(diào)用者自己直接退出而沒有調(diào)用stopService的話，Service會一直在后臺運(yùn)行捂刺。該Service的調(diào)用者再啟動起來后可以通過stopService關(guān)閉Service谣拣。
2.context.bindService()->onCreate()->onBind()->Service running-->onUnbind() -> onDestroy() ->Service stop
1.onBind將返回給客戶端一個IBind接口實(shí)例，IBind允許客戶端回調(diào)服務(wù)的方法叠萍，比如得到Service運(yùn)行的狀態(tài)或其他操作芝发。
2.這個時候會把調(diào)用者和Service綁定在一起苛谷，Context退出了,Service就會調(diào)用onUnbind->onDestroy相應(yīng)退出。
3.所以調(diào)用bindService的生命周期為：onCreate --> onBind(只一次格郁，不可多次綁定) --> onUnbind --> onDestory腹殿。
問題：onStartCommand()的返回值是一個很奇怪的值START_STICKY，這是個什么呢例书？或者說這個方法的返回值是用來干嘛的呢锣尉？
事實(shí)上，它的返回值是用來指定系統(tǒng)對當(dāng)前線程的行為的决采。它的返回值必須是以下常量之一：
START_NOT_STICKY : 如果系統(tǒng)在 onStartCommand() 返回后終止服務(wù)自沧，則除非有掛起 Intent 要傳遞，否則系統(tǒng)不會重建服務(wù)。這是最安全的選項(xiàng)拇厢，可以避免在不必要時以及應(yīng)用能夠輕松重啟所有未完成的作業(yè)時運(yùn)行服務(wù)爱谁。
START_STICKY : 如果系統(tǒng)在 onStartCommand() 返回后終止服務(wù)，則會重建服務(wù)并調(diào)用 onStartCommand()孝偎，但絕對不會重新傳遞最后一個 Intent访敌。相反，除非有掛起 Intent 要啟動服務(wù)（在這種情況下衣盾，將傳遞這些 Intent ）寺旺，否則系統(tǒng)會通過空 Intent 調(diào)用 onStartCommand()。這適用于不執(zhí)行命令势决、但無限期運(yùn)行并等待作業(yè)的媒體播放器（或類似服務(wù)）阻塑。
START_REDELIVER_INTENT : 如果系統(tǒng)在 onStartCommand() 返回后終止服務(wù)，則會重建服務(wù)徽龟，并通過傳遞給服務(wù)的最后一個 Intent 調(diào)用 onStartCommand()叮姑。任何掛起 Intent 均依次傳遞。這適用于主動執(zhí)行應(yīng)該立即恢復(fù)的作業(yè)（例如下載文件）的服務(wù)据悔。
注意點(diǎn)：Android5.0后隱式啟動service會報Service Intent must be explicit
問題：說下IntentService原理
IntentService已經(jīng)做了這些事：
創(chuàng)建默認(rèn)的工作線程传透，用于在應(yīng)用的主線程外執(zhí)行傳遞給 onStartCommand() 的所有 Intent
創(chuàng)建工作隊(duì)列，用于將一個 Intent 逐一傳遞給 onHandleIntent() 實(shí)現(xiàn)极颓，這樣的話就永遠(yuǎn)不必?fù)?dān)心多線程問題了
在處理完所有啟動請求后停止服務(wù)朱盐，從此媽媽再也不用擔(dān)心我忘記調(diào)用 stopSelf() 了
提供 onBind() 的默認(rèn)實(shí)現(xiàn)（返回 null）
提供 onStartCommand() 的默認(rèn)實(shí)現(xiàn)，可將 Intent 依次發(fā)送到工作隊(duì)列和 onHandleIntent() 實(shí)現(xiàn)
問題：IntentService與Service的區(qū)別
IntentService是Service的子類菠隆，是一個異步的兵琳，會自動停止的服務(wù)，很好解決了傳統(tǒng)的Service中處理完耗時操作忘記停止并銷毀Service的問題
會創(chuàng)建獨(dú)立的worker線程來處理所有的Intent請求骇径；
會創(chuàng)建獨(dú)立的worker線程來處理onHandleIntent()方法實(shí)現(xiàn)的代碼躯肌，無需處理多線程問題；
所有請求處理完成后破衔，IntentService會自動停止清女，無需調(diào)用stopSelf()方法停止Service；
為Service的onBind()提供默認(rèn)實(shí)現(xiàn)晰筛，返回null嫡丙；
為Service的onStartCommand提供默認(rèn)實(shí)現(xiàn)，將請求Intent添加到隊(duì)列中读第；
IntentService不會阻塞UI線程曙博，而普通Serveice會導(dǎo)致ANR異常
Intentservice若未執(zhí)行完成上一次的任務(wù)，將不會新開一個線程怜瞒，是等待之前的任務(wù)完成后父泳，再執(zhí)行新的任務(wù)，等任務(wù)完成后再次調(diào)用stopSelf()
問題：如何保證一個后臺服務(wù)不被殺死；比較省電的方式是什么
分析篇：保證service不被殺死
終極解決方案:Android應(yīng)對進(jìn)程被殺死--Service（二）
使用Jni,在 c端 fork進(jìn)程惠窄，檢測Service是否存活逝她，若Service已被殺死，則進(jìn)行重啟Service.
至于檢測方式睬捶，可以輪詢獲取子進(jìn)程Pid,若為1, 則說明子進(jìn)程被Init進(jìn)程所領(lǐng)養(yǎng),已經(jīng)成為了孤兒進(jìn)程.
但是這種方式比較消耗電量黔宛，并且由于不同手機(jī)系統(tǒng)定制的改變，當(dāng)應(yīng)用被強(qiáng)制停止時擒贸，父進(jìn)程并不一定被真正殺死臀晃，因此在一些特定機(jī)型上是無法通過此方式進(jìn)行判斷.這里推薦使用liunx socket的方式進(jìn)行類似心跳包的檢測，并且當(dāng)觸發(fā)檢測Service是否被殺死之前介劫，需要判斷應(yīng)用是否已經(jīng)被卸載徽惋，如果應(yīng)用已經(jīng)被卸載，則不再進(jìn)行檢測Service行為座韵，直接調(diào)用exit(0)退出子進(jìn)程险绘，避免浪費(fèi)系統(tǒng)資源和消耗電量.
注意: 目前在Android5.0系統(tǒng)上會把fork出來的進(jìn)程放到一個進(jìn)程組里， 當(dāng)程序主進(jìn)程掛掉后誉碴，也會把整個進(jìn)程組殺掉,因此用fork的方式也無法在Android5.0及以上系統(tǒng)實(shí)現(xiàn)守護(hù)進(jìn)程. 這個是系統(tǒng)層面的限制宦棺，當(dāng)然也是為了優(yōu)化整個的系統(tǒng)環(huán)境,守護(hù)進(jìn)程給手機(jī)帶來的體驗(yàn)并不好
1、利用service自己的機(jī)制.在onStartCommand中設(shè)置參數(shù)為START_STICKY黔帕，內(nèi)存不足被殺死內(nèi)存有的時候會重新創(chuàng)建代咸，短時間5次限制。
2成黄、設(shè)置Android:persistent="true"呐芥。
3、提升service優(yōu)先級android:priority奋岁。
4思瘟、提升service進(jìn)程優(yōu)先級,可以綁定通知欄成為前臺服務(wù)，在service中創(chuàng)建一個notification闻伶，startForeground滨攻；nDestory方法中需要通過stopForeground(true)來取消前臺運(yùn)行狀態(tài)。
5虾攻、 android:process=”com.xxx.xxxservice”配置到單獨(dú)的進(jìn)程中
6铡买、onDestroy方法里重啟service更鲁。
7霎箍、監(jiān)聽系統(tǒng)廣播判斷Service狀態(tài)，手機(jī)重啟澡为、界面喚醒漂坏、應(yīng)用狀態(tài)改變等等監(jiān)聽并捕獲到，然后判斷我們的Service是否還存活去啟動。
8顶别、雙進(jìn)程Service： 讓2個進(jìn)程互相保護(hù)**谷徙，其中一個Service被清理后，另外沒被清理的進(jìn)程可以立即重啟進(jìn)程
9驯绎、加上兩個類似于守護(hù)進(jìn)程的Service完慧， 分別檢查Service的運(yùn)行狀態(tài)，注冊響應(yīng)的廣播剩失，對其進(jìn)行守護(hù),一旦發(fā)現(xiàn)沒有運(yùn)行就將其啟動.我利用的系統(tǒng)廣播是Intent.ACTION_TIME_TICK屈尼，這個廣播每分鐘發(fā)送一次，我們可以每分鐘檢查一次Service的運(yùn)行狀態(tài)拴孤，如果已經(jīng)被結(jié)束了脾歧，就重新啟動Service。它的優(yōu)點(diǎn)就是間隔時間短而且非常穩(wěn)定, 而其他的廣播并不能保證這一點(diǎn),當(dāng)然演熟，在具體的應(yīng)用中還是要根據(jù)需求使用, 結(jié)合其他廣播來保證自己的service一定會被重啟.
10鞭执、通過jni調(diào)用，在c層啟動多進(jìn)程 fork 機(jī)制創(chuàng)建 Native 進(jìn)程監(jiān)聽主進(jìn)程芒粹，為純Linux進(jìn)程生命周期不受android的控制兄纺，適用于5.0以下。
(要在 Native 進(jìn)程中感知主進(jìn)程是否存活有兩種實(shí)現(xiàn)方式：
10.1化漆、在 Native 進(jìn)程中通過死循環(huán)或定時器囤热，輪訓(xùn)判斷主進(jìn)程是否存活，檔主進(jìn)程不存活時進(jìn)行拉活获三。該方案的很大缺點(diǎn)是不停的輪詢執(zhí)行判斷邏輯旁蔼，非常耗電。
10.2疙教、在主進(jìn)程中創(chuàng)建一個監(jiān)控文件棺聊，并且在主進(jìn)程中持有文件鎖。在拉活進(jìn)程啟動后申請文件鎖將會被堵塞贞谓，一旦可以成功獲取到鎖限佩，說明主進(jìn)程掛掉，即可進(jìn)行拉活裸弦。由于 Android 中的應(yīng)用都運(yùn)行于虛擬機(jī)之上祟同，Java層的文件鎖與 Linux 層的文件鎖是不同的，要實(shí)現(xiàn)該功能需要封裝 Linux 層的文件鎖供上層調(diào)用理疙。)
11晕城、5.0以上利用 JobScheduler 機(jī)制拉活，系統(tǒng)會定時調(diào)用該進(jìn)程以使應(yīng)用進(jìn)行一些邏輯操作窖贤。
12砖顷、利用賬號同步機(jī)制拉活贰锁，Android 系統(tǒng)的賬號同步機(jī)制會定期同步賬號進(jìn)行
13、QQ黑科技: 在應(yīng)用退到后臺后滤蝠，另起一個只有 1 像素的頁面停留在桌面上豌熄，讓自己保持前臺狀態(tài)，保護(hù)自己不被后臺清理工具殺死
14物咳、在已經(jīng)root的設(shè)備下锣险，修改相應(yīng)的權(quán)限文件,將App偽裝成系統(tǒng)級的應(yīng)用Android4.0系列的一個漏洞，已經(jīng)確認(rèn)可行
15览闰、在NDK環(huán)境中將1中編寫的C代碼編譯打包成可執(zhí)行文件(BUILD_EXECUTABLE)囱持。主進(jìn)程啟動時將守護(hù)進(jìn)程放入私有目錄下，賦予可執(zhí)行權(quán)限焕济，啟動它即可纷妆。
16、聯(lián)系廠商晴弃，加入白名單
問題：注冊Service需要注意什么
Service還是運(yùn)行在主線程當(dāng)中的掩幢，所以如果需要執(zhí)行一些復(fù)雜的邏輯操作，最好在服務(wù)的內(nèi)部手動創(chuàng)建子線程進(jìn)行處理上鞠，否則會出現(xiàn)UI線程被阻塞的問題
問題：Service與Activity怎么實(shí)現(xiàn)通信
方法一：
1际邻、添加一個繼承Binder的內(nèi)部類，并添加相應(yīng)的邏輯方法
2芍阎、Messager
3世曾、AIDL
方法二：
通過BroadCast(廣播)的形式 當(dāng)我們的進(jìn)度發(fā)生變化的時候我們發(fā)送一條廣播，然后在Activity的注冊廣播接收器谴咸，接收到廣播之后更新視圖
3轮听、BroadcastReceiver----------1
問題：注冊廣播接收器有哪幾種方式,有什么區(qū)別
靜態(tài)注冊：在AndroidManifest.xml文件中進(jìn)行注冊，當(dāng)App退出后岭佳，Receiver仍然可以接收到廣播并且進(jìn)行相應(yīng)的處理
動態(tài)注冊：在代碼中動態(tài)注冊血巍，當(dāng)App退出后，也就沒辦法再接受廣播了
問題：如何通過廣播攔截和abort一條短信珊随；
要攔截首先設(shè)置權(quán)限：android.permission.SEND_SMS述寡，android.permission.RECEIVE_SMS，設(shè)置receiver的優(yōu)先級為最高1000叶洞，acticion為android.provider.Telephony.SMS_RECEIVED鲫凶。
在4.4前，短信攔截都是通過動態(tài)注冊高優(yōu)先級BroadcastReceiver的方式進(jìn)行攔截的衩辟，主要是用于跟競品進(jìn)行短信搶占螟炫。而現(xiàn)在ContenetObserver是并行通知的情況下，如果過濾邏輯不夠快惭婿，依然有可能會被競品搶先把短信先刪除掉不恭，導(dǎo)致拿到的最后一次短信是舊的短信。建議結(jié)合BroadcastReceiver和ContenetObserver進(jìn)行攔截财饥，BroadcastReceiver做內(nèi)容校正和后備數(shù)據(jù)换吧，以防拿到的最后一條短信是舊的時候，依然可以進(jìn)行正常的攔截流程钥星；
4.4以上引入了default sms機(jī)制沾瓦，我們可以在不成為default sms的前提下實(shí)現(xiàn)短信攔截，利用App Ops權(quán)限管理功能谦炒，
但由于App Ops從4.3出現(xiàn)到4.4一直牌隱藏的狀態(tài)贯莺，猜想google還在不斷調(diào)整中；
Write SMS/MMS的權(quán)限開關(guān)的存在跟defaultsms本身是一個矛盾宁改，之所以出現(xiàn)Write SMS/MMS的權(quán)限開關(guān)缕探，完全是因?yàn)锳pp Ops出現(xiàn)在前，而defaultsms出現(xiàn)在后所致还蹲。
6.0以上引入了新的動態(tài)權(quán)限管理爹耗，類似于iOS中的權(quán)限。6.0以前是在安裝時一次性獲取權(quán)限谜喊，6.0之后是在運(yùn)行的時候選擇潭兽。
問題：廣播是否可以請求網(wǎng)絡(luò)；
網(wǎng)絡(luò)狀態(tài)發(fā)生變化的時候斗遏，系統(tǒng)會發(fā)出 android.NET.conn.CONNECTIVITY_CHANGE山卦，在onreceiver中使用ConnectivityManager監(jiān)聽網(wǎng)絡(luò)狀態(tài)，從4.0 開始所有的網(wǎng)絡(luò)請求都需要在線程中诵次，廣播請求網(wǎng)絡(luò)同理 開啟線程在線程中請求網(wǎng)絡(luò)
問題：廣播引起anr的時間限制
10秒鐘账蓉，所以在Onceive中耗時的操作一般新開線程處理
4、ContentProvider ----------1
問題：權(quán)限管理
讀寫分離(exported=true讀設(shè)置Android:readPermission,寫設(shè)置android:writePermisson
問題：權(quán)限控制-精確到表級(匹配URI)逾一，URL控制
5剔猿、Fragment?----------1
MS思考：Android面試一天一題（Day 24: 悲催的Fragment）
分析篇：Fragment 全解析
問題：Fragment生命周期
onAttach綁定activity,oncreate,onActivitycreated:Activity的onCreate方法已經(jīng)執(zhí)行完成并返回,onstart,onresume,onpause,onstop,onDesdroyview,onDesdroy,ondettach解除綁定券膀；
問題：Fragment狀態(tài)保存
人為返回出棧不調(diào)用onSaveInstanceState淮摔，在ondesdroy中保存（保存在能和Fragment一起共存的Argument：Bundle b = getArguments();），恢復(fù)狀態(tài)在onActivityCreated中
問題：fragement里面可以再嵌套fragment硕勿？
getChildFragmentManager()
Android Fragment使用(二) 嵌套Fragments (Nested Fragments) 的使用及常見錯誤
6鄙早、Intent----------1
問題：顯示Intent與隱式Intent的區(qū)別
對明確指出了目標(biāo)組件名稱的Intent汪茧，我們稱之為“顯式Intent”。 對于沒有明確指出目標(biāo)組件名稱的Intent限番，則稱之為“隱式 Intent”舱污。
對于隱式意圖，在定義Activity時弥虐，指定一個intent-filter扩灯，當(dāng)一個隱式意圖對象被一個意圖過濾器進(jìn)行匹配時媚赖，將有三個方面會被參考到：
動作(Action)
類別(Category ['k?t?g(?)r?] )
數(shù)據(jù)(Data )
問題：Intent可以傳遞哪些數(shù)據(jù)類型
1.Serializable
2.charsequence: 主要用來傳遞String，char等
3.parcelable
4.Bundle
7珠插、動畫----------1
問題：Android中的動畫有哪些惧磺，區(qū)別是什么
逐幀動畫(Drawable Animation)： 加載一系列Drawable資源來創(chuàng)建動畫，簡單來說就是播放一系列的圖片來實(shí)現(xiàn)動畫效果捻撑，可以自定義每張圖片的持續(xù)時間
補(bǔ)間動畫(Tween Animation)： Tween可以對View對象實(shí)現(xiàn)一系列簡單的動畫效果磨隘，比如位移，縮放顾患，旋轉(zhuǎn)番捂，透明度等等。但是它并不會改變View屬性的值江解，只是改變了View的繪制的位置设预，比如，一個按鈕在動畫過后犁河，不在原來的位置絮缅，但是觸發(fā)點(diǎn)擊事件的仍然是原來的坐標(biāo)。
屬性動畫(Property Animation)： 動畫的對象除了傳統(tǒng)的View對象呼股，還可以是Object對象耕魄，動畫結(jié)束后，Object對象的屬性值被實(shí)實(shí)在在的改變了
問題：動畫的原理：
1.動畫的基本原理：其實(shí)就是利用插值器和估值器彭谁，來計(jì)算出各個時刻View的屬性吸奴，然后通過改變View的屬性來，實(shí)現(xiàn)View的動畫效果缠局。
2.View動畫:只是影像變化则奥，view的實(shí)際位置還在原來的地方。
3.幀動畫是在xml中定義好一系列圖片之后狭园，使用AnimationDrawable來播放的動畫读处。
4.View的屬性動畫：
1.插值器：作用是根據(jù)時間的流逝的百分比來計(jì)算屬性改變的百分比
2.估值器：在1的基礎(chǔ)上由這個東西來計(jì)算出屬性到底變化了多少數(shù)值的類
問題：不使用動畫，怎么實(shí)現(xiàn)一個動態(tài)的 View唱矛？
1罚舱、利用線程改變view的位置大小等
2、自定義view重繪
問題：View的補(bǔ)間動畫有哪幾種绎谦？補(bǔ)間動畫效果的實(shí)現(xiàn)原理
8管闷、ListView----------1
問題：怎么實(shí)現(xiàn)一個部分更新的 ListView？
intvisiblePosition = mListView.getFirstVisiblePosition();
//只有當(dāng)要更新的view在可見的位置時才更新窃肠，不可見時包个，跳過不更新
if(itemIndex?-?visiblePosition?>=0)?{
//得到要更新的item的view
View?view?=?mListView.getChildAt(itemIndex?-?visiblePosition);
問題：怎么實(shí)現(xiàn)ListView多種布局？
問題：ListView與數(shù)據(jù)庫綁定的實(shí)現(xiàn)
9冤留、View相關(guān)----------1
問題：Postvalidata與Validata有什么區(qū)別碧囊？
Validata只能在工作線程調(diào)用树灶，Postvalidata內(nèi)部使用了handler實(shí)現(xiàn)，可在工作線程調(diào)用
10糯而、RecyclerView----------1
11天通、Scrollview----------1
問題：Scrollview怎么判斷是否滑倒底部
android:怎么判斷android中ScrollView滑動到了最底部?
12、Context----------1
問題：Context與ApplicationContext的區(qū)別歧蒋，分別用在什么情況下
ApplicationContext的生命周期是與Application的生命周期相關(guān)的土砂，context隨著Application的銷毀而銷毀州既，伴隨application的一生谜洽，與activity的生命周期無關(guān).第二種中的context跟Activity的生命周期是相關(guān)的，但是對一個Application來說吴叶，Activity可以銷毀幾次阐虚，那么屬于Activity的context就會銷毀多次。
Application的Context是一個全局靜態(tài)變量蚌卤，SDK的說明是只有當(dāng)你引用這個context的生命周期超過了當(dāng)前activity的生命周期实束，而和整個應(yīng)用的生命周期掛鉤時，才去使用這個application的context逊彭。
在android中context可以作很多操作咸灿，但是最主要的功能是加載和訪問資源。在android中有兩種context侮叮，一種是 application context避矢，一種是activity context，通常我們在各種類和方法間傳遞的是activity context囊榜。
在使用context的時候审胸，小心內(nèi)存泄露，防止內(nèi)存泄露卸勺，注意一下幾個方面：
1. 不要讓生命周期長的對象引用activity context砂沛，即保證引用activity的對象要與activity本身生命周期是一樣的
2. 對于生命周期長的對象，可以使用application context
3. 避免非靜態(tài)的內(nèi)部類曙求，盡量使用靜態(tài)類碍庵，避免生命周期問題，注意內(nèi)部類對外部對象引用導(dǎo)致的生命周期變化
問題：Application（或者Service）和Activity都可以調(diào)用Context的startActivity方法悟狱，那么在這兩個地方調(diào)用startActivity有區(qū)別嗎怎抛？
Application（或者Service）需要給Intent設(shè)置Intent.FLAG_ACTIVITY_NEW_TASK才能正常啟動Activity，Application（或者Service）需要給Intent設(shè)置Intent.FLAG_ACTIVITY_NEW_TASK才能正常啟動Activity
問題：Context的實(shí)例是什么時候創(chuàng)建的芽淡？一個應(yīng)用里面會有幾個Context的實(shí)例马绝？
Context數(shù)量 = Activity數(shù)量 + Service數(shù)量 + 1（Application）
問題：為什么Dialog不能用Application的Context
13、布局相關(guān)----------1
布局性能優(yōu)化：布局性能優(yōu)化(include, viewstub, merge)
三挣菲、進(jìn)程線程
1富稻、進(jìn)程----------1
問題：多進(jìn)程開發(fā)以及多進(jìn)程應(yīng)用場景
例子：音樂播放服務(wù)掷邦，云平臺客戶端的同步服務(wù)
問題：多進(jìn)程的好處
（1）Android系統(tǒng)對每個應(yīng)用進(jìn)程的內(nèi)存占用是有限制的，占用內(nèi)存越大的進(jìn)程椭赋，通常被系統(tǒng)殺死的可能性越大抚岗。讓一個組件運(yùn)行在單獨(dú)的進(jìn)程中，可以減少主進(jìn)程所占用的內(nèi)存哪怔，降低被系統(tǒng)殺死的概率宣蔚；
（2）如果子進(jìn)程因?yàn)槟撤N原因崩潰了，不會直接導(dǎo)致主程序的崩潰认境，可以降低主程序崩潰的概率胚委；
（3）即使主進(jìn)程退出了，子進(jìn)程仍然可以繼續(xù)工作叉信，比如子進(jìn)程是推送服務(wù)亩冬，在主進(jìn)程退出的情況下，仍然能夠保證用戶可以收到推送消息硼身。
問題：多進(jìn)程使用場景
（1）BroadcastReceiver
一個程序發(fā)送廣播硅急，可以啟動其他程序的BroadcastReceiver。拿到清單文件中BroadcastReceiver的intentFilter中的action屬性值佳遂，可以在另一個應(yīng)用中發(fā)送廣播啟動當(dāng)前應(yīng)用里的BroadcastReceiver营袜。
（2）ContentProvider
一個應(yīng)用通過ContentProvider向其他的應(yīng)用暴露自己的數(shù)據(jù)，供其他應(yīng)用訪問
（3）啟動其他應(yīng)用的activity或者service
2丑罪、線程----------1
問題：什么時候使用CountDownLatch
問題：HandlerThread荚板、Thread、Asynctask原理與區(qū)別
問題：生產(chǎn)者與消費(fèi)者巍糯，手寫代碼 ****（多線程同步的框架的實(shí)現(xiàn)原理啸驯，以及如何用生產(chǎn)者消費(fèi)者模型解決同步問題）
3、Socket編程
問題：socket短線重連怎么實(shí)現(xiàn)祟峦，心跳機(jī)制又是怎樣實(shí)現(xiàn)罚斗，四次握手步驟有哪些（網(wǎng)絡(luò)通訊原理）
4、ThreadLocal
四宅楞、數(shù)據(jù)存儲
問題：數(shù)據(jù)持久化的四種方式有哪些针姿？
文件存儲： 通過java.io.FileInputStream和java.io.FileOutputStream這兩個類來實(shí)現(xiàn)對文件的讀寫，java.io.File類則用來構(gòu)造一個具體指向某個文件或者文件夾的對象厌衙。
SharedPreferences： SharedPreferences是一種輕量級的數(shù)據(jù)存儲機(jī)制距淫，他將一些簡單的數(shù)據(jù)類型的數(shù)據(jù)，包括boolean類型婶希，int類型榕暇，float類型，long類型以及String類型的數(shù)據(jù)，以鍵值對的形式存儲在應(yīng)用程序的私有Preferences目錄（/data/data/<包名>/shared_prefs/）中彤枢，這種Preferences機(jī)制廣泛應(yīng)用于存儲應(yīng)用程序中的配置信息狰晚。
SQLite數(shù)據(jù)庫： 當(dāng)應(yīng)用程序需要處理的數(shù)據(jù)量比較大時，為了更加合理地存儲缴啡、管理壁晒、查詢數(shù)據(jù)，我們往往使用關(guān)系數(shù)據(jù)庫來存儲數(shù)據(jù)业栅。Android系統(tǒng)的很多用戶數(shù)據(jù)秒咐，如聯(lián)系人信息，通話記錄碘裕，短信息等携取，都是存儲在SQLite數(shù)據(jù)庫當(dāng)中的，所以利用操作SQLite數(shù)據(jù)庫的API可以同樣方便的訪問和修改這些數(shù)據(jù)娘汞。
ContentProvider: 主要用于在不同的應(yīng)用程序之間實(shí)現(xiàn)數(shù)據(jù)共享的功能歹茶，不同于sharepreference和文件存儲中的兩種全局可讀寫操作模式夕玩，內(nèi)容提供其可以選擇只對哪一部分?jǐn)?shù)據(jù)進(jìn)行共享你弦，從而保證我們程序中的隱私數(shù)據(jù)不會有泄漏的風(fēng)險
解析xml：
問題：Json有什么優(yōu)劣勢
分析篇：Json優(yōu)劣勢
1.JSON的速度要遠(yuǎn)遠(yuǎn)快于XML
2.JSON相對于XML來講禽作，數(shù)據(jù)的體積小
3.JSON對數(shù)據(jù)的描述性比XML較差
問題：數(shù)據(jù)庫的知識，包括本地數(shù)據(jù)庫優(yōu)化點(diǎn)揩页。
