#Android:
---
**五種布局: FrameLayout 、 LinearLayout 、 AbsoluteLayout 、 RelativeLayout 、 TableLayout 全都繼承自ViewGroup,各自特點及繪制效率對比。**
* FrameLayout(框架布局)
此布局是五中布局中最簡單的布局,Android中并沒有對child view的擺布進行控制,這個布局中所有的控件都會默認出現在視圖的左上角,我們可以使用``android:layout_margin``,``android:layout_gravity``等屬性去控制子控件相對布局的位置。
* LinearLayout(線性布局)
一行只控制一個控件的線性布局,所以當有很多控件需要在一個界面中列出時,可以用LinearLayout布局。
此布局有一個需要格外注意的屬性:``android:orientation=“horizontal|vertical``。
* 當`android:orientation="horizontal`時,*說明你希望將水平方向的布局交給**LinearLayout** *,其子元素的`android:layout_gravity="right|left"` 等控制水平方向的gravity值都是被忽略的,*此時**LinearLayout**中的子元素都是默認的按照水平從左向右來排*,我們可以用`android:layout_gravity="top|bottom"`等gravity值來控制垂直展示。
* 反之,可以知道 當`android:orientation="vertical`時,**LinearLayout**對其子元素展示上的的處理方式。
* AbsoluteLayout(絕對布局)
可以放置多個控件,并且可以自己定義控件的x,y位置
* RelativeLayout(相對布局)
這個布局也是相對自由的布局,Android 對該布局的child view的 水平layout& 垂直layout做了解析,由此我們可以FrameLayout的基礎上使用標簽或者Java代碼對垂直方向 以及 水平方向 布局中的views任意的控制.
* 相關屬性:
```
android:layout_centerInParent="true|false"
android:layout_centerHorizontal="true|false"
android:layout_alignParentRight="true|false"
```
* TableLayout(表格布局)
將子元素的位置分配到行或列中,一個TableLayout由許多的TableRow組成
---
**Activity生命周期。**
* 啟動Activity:
onCreate()—>onStart()—>onResume(),Activity進入運行狀態。
* Activity退居后臺:
當前Activity轉到新的Activity界面或按Home鍵回到主屏:
onPause()—>onStop(),進入停滯狀態。
* Activity返回前臺:
onRestart()—>**onStart()**—>onResume(),再次回到運行狀態。
* Activity退居后臺,且系統內存不足,
系統會殺死這個后臺狀態的Activity(此時這個Activity引用仍然處在任務棧中,只是這個時候引用指向的對象已經為null),若再次回到這個Activity,則會走onCreate()–>onStart()—>onResume()(將重新走一次Activity的初始化生命周期)
* 鎖定屏與解鎖屏幕
**只會調用onPause(),而不會調用onStop()方法,開屏后則調用onResume()**
* 更多流程分支,請參照以下生命周期流程圖

---
**通過Acitivty的xml標簽來改變任務棧的默認行為**
* 使用``android:launchMode="standard|singleInstance|singleTask|singleTop"``來控制Acivity任務棧。
**任務棧**是一種后進先出的結構。位于棧頂的Activity處于焦點狀態,當按下back按鈕的時候,棧內的Activity會一個一個的出棧,并且調用其``onDestory()``方法。如果棧內沒有Activity,那么系統就會回收這個棧,每個APP默認只有一個棧,以APP的包名來命名.
* standard : 標準模式,每次啟動Activity都會創建一個新的Activity實例,并且將其壓入任務棧棧頂,而不管這個Activity是否已經存在。Activity的啟動三回調(*onCreate()->onStart()->onResume()*)都會執行。
- singleTop : 棧頂復用模式.這種模式下,如果新Activity已經位于任務棧的棧頂,那么此Activity不會被重新創建,所以它的啟動三回調就不會執行,同時Activity的``onNewIntent()``方法會被回調.如果Activity已經存在但是不在棧頂,那么作用于*standard模式*一樣.
- singleTask: 棧內復用模式.創建這樣的Activity的時候,系統會先確認它所需任務棧已經創建,否則先創建任務棧.然后放入Activity,如果棧中已經有一個Activity實例,那么這個Activity就會被調到棧頂,``onNewIntent()``,并且singleTask會清理在當前Activity上面的所有Activity.(clear top)
- singleInstance : 加強版的singleTask模式,這種模式的Activity只能單獨位于一個任務棧內,由于棧內復用的特性,后續請求均不會創建新的Activity,除非這個獨特的任務棧被系統銷毀了
Activity的堆棧管理以ActivityRecord為單位,所有的ActivityRecord都放在一個List里面.可以認為一個ActivityRecord就是一個Activity棧
---
**Activity緩存方法。**
有a、b兩個Activity,當從a進入b之后一段時間,可能系統會把a回收,這時候按back,執行的不是a的onRestart而是onCreate方法,a被重新創建一次,這是a中的臨時數據和狀態可能就丟失了。
可以用Activity中的onSaveInstanceState()回調方法保存臨時數據和狀態,這個方法一定會在活動被回收之前調用。方法中有一個Bundle參數,putString()、putInt()等方法需要傳入兩個參數,一個鍵一個值。數據保存之后會在onCreate中恢復,onCreate也有一個Bundle類型的參數。
示例代碼:
```
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//這里,當Acivity第一次被創建的時候為空
//所以我們需要判斷一下
if( savedInstanceState != null ){
savedInstanceState.getString("anAnt");
}
}
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
outState.putString("anAnt","Android");
}
```
一、onSaveInstanceState (Bundle outState)
當某個activity變得“容易”被系統銷毀時,該activity的onSaveInstanceState就會被執行,除非該activity是被用戶主動銷毀的,例如當用戶按BACK鍵的時候。
注意上面的雙引號,何為“容易”?言下之意就是該activity還沒有被銷毀,而僅僅是一種可能性。這種可能性有哪些?通過重寫一個activity的所有生命周期的onXXX方法,包括onSaveInstanceState和onRestoreInstanceState方法,我們可以清楚地知道當某個activity(假定為activity A)顯示在當前task的最上層時,其onSaveInstanceState方法會在什么時候被執行,有這么幾種情況:
1、當用戶按下HOME鍵時。
這是顯而易見的,系統不知道你按下HOME后要運行多少其他的程序,自然也不知道activity A是否會被銷毀,故系統會調用onSaveInstanceState,讓用戶有機會保存某些非永久性的數據。以下幾種情況的分析都遵循該原則
2、長按HOME鍵,選擇運行其他的程序時。
3、按下電源按鍵(關閉屏幕顯示)時。
4、從activity A中啟動一個新的activity時。
5、屏幕方向切換時,例如從豎屏切換到橫屏時。(如果不指定configchange屬性)
在屏幕切換之前,系統會銷毀activity A,在屏幕切換之后系統又會自動地創建activity A,所以onSaveInstanceState一定會被執行
總而言之,onSaveInstanceState的調用遵循一個重要原則,即當系統“未經你許可”時銷毀了你的activity,則onSaveInstanceState會被系統調用,這是系統的責任,因為它必須要提供一個機會讓你保存你的數據(當然你不保存那就隨便你了)。另外,需要注意的幾點:
1.布局中的每一個View默認實現了onSaveInstanceState()方法,這樣的話,這個UI的任何改變都會自動的存儲和在activity重新創建的時候自動的恢復。但是這種情況只有在你為這個UI提供了唯一的ID之后才起作用,如果沒有提供ID,將不會存儲它的狀態。
2.由于默認的onSaveInstanceState()方法的實現幫助UI存儲它的狀態,所以如果你需要覆蓋這個方法去存儲額外的狀態信息時,你應該在執行任何代碼之前都調用父類的onSaveInstanceState()方法(super.onSaveInstanceState())。
既然有現成的可用,那么我們到底還要不要自己實現onSaveInstanceState()?這得看情況了,如果你自己的派生類中有變量影響到UI,或你程序的行為,當然就要把這個變量也保存了,那么就需要自己實現,否則就不需要。
3.由于onSaveInstanceState()方法調用的不確定性,你應該只使用這個方法去記錄activity的瞬間狀態(UI的狀態)。不應該用這個方法去存儲持久化數據。當用戶離開這個activity的時候應該在onPause()方法中存儲持久化數據(例如應該被存儲到數據庫中的數據)。
4.onSaveInstanceState()如果被調用,這個方法會在onStop()前被觸發,但系統并不保證是否在onPause()之前或者之后觸發。
二、onRestoreInstanceState (Bundle outState)
至于onRestoreInstanceState方法,需要注意的是,onSaveInstanceState方法和onRestoreInstanceState方法“不一定”是成對的被調用的,(本人注:我昨晚調試時就發現原來不一定成對被調用的!)
onRestoreInstanceState被調用的前提是,activity A“確實”被系統銷毀了,而如果僅僅是停留在有這種可能性的情況下,則該方法不會被調用,例如,當正在顯示activity A的時候,用戶按下HOME鍵回到主界面,然后用戶緊接著又返回到activity A,這種情況下activity A一般不會因為內存的原因被系統銷毀,故activity A的onRestoreInstanceState方法不會被執行
另外,onRestoreInstanceState的bundle參數也會傳遞到onCreate方法中,你也可以選擇在onCreate方法中做數據還原。
還有onRestoreInstanceState在onstart之后執行。
至于這兩個函數的使用,給出示范代碼(留意自定義代碼在調用super的前或后):
```
@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
savedInstanceState.putBoolean("MyBoolean", true);
savedInstanceState.putDouble("myDouble", 1.9);
savedInstanceState.putInt("MyInt", 1);
savedInstanceState.putString("MyString", "Welcome back to Android");
// etc.
super.onSaveInstanceState(savedInstanceState);
}
@Override
public void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
boolean myBoolean = savedInstanceState.getBoolean("MyBoolean");
double myDouble = savedInstanceState.getDouble("myDouble");
int myInt = savedInstanceState.getInt("MyInt");
String myString = savedInstanceState.getString("MyString");
}
```
---
**Fragment的生命周期和activity如何的一個關系**
這我們引用本知識庫里的一張圖片:

**為什么在Service中創建子線程而不是Activity中**
這是因為Activity很難對Thread進行控制,當Activity被銷毀之后,就沒有任何其它的辦法可以再重新獲取到之前創建的子線程的實例。而且在一個Activity中創建的子線程,另一個Activity無法對其進行操作。但是Service就不同了,所有的Activity都可以與Service進行關聯,然后可以很方便地操作其中的方法,即使Activity被銷毀了,之后只要重新與Service建立關聯,就又能夠獲取到原有的Service中Binder的實例。因此,使用Service來處理后臺任務,Activity就可以放心地finish,完全不需要擔心無法對后臺任務進行控制的情況。
**Intent的使用方法,可以傳遞哪些數據類型。**
通過查詢Intent/Bundle的API文檔,我們可以獲知,Intent/Bundle支持傳遞基本類型的數據和基本類型的數組數據,以及String/CharSequence類型的數據和String/CharSequence類型的數組數據。而對于其它類型的數據貌似無能為力,其實不然,我們可以在Intent/Bundle的API中看到Intent/Bundle還可以傳遞Parcelable(包裹化,郵包)和Serializable(序列化)類型的數據,以及它們的數組/列表數據。
所以要讓非基本類型和非String/CharSequence類型的數據通過Intent/Bundle來進行傳輸,我們就需要在數據類型中實現Parcelable接口或是Serializable接口。
[http://blog.csdn.net/kkk0526/article/details/7214247](http://blog.csdn.net/kkk0526/article/details/7214247)
**Fragment生命周期**

注意和Activity的相比的區別,按照執行順序
* onAttach(),onDetach()
* onCreateView(),onDestroyView()
---
**Service的兩種啟動方法,有什么區別**
1.在Context中通過``public boolean bindService(Intent service,ServiceConnection conn,int flags)`` 方法來進行Service與Context的關聯并啟動,并且Service的生命周期依附于Context(**不求同時同分同秒生!但求同時同分同秒屎!!**)。
2.通過`` public ComponentName startService(Intent service)``方法去啟動一個Service,此時Service的生命周期與啟動它的Context無關。
3.要注意的是,whatever,**都需要在xml里注冊你的Service**,就像這樣:
```
<service
android:name=".packnameName.youServiceName"
android:enabled="true" />
```
**廣播(Boardcast Receiver)的兩種動態注冊和靜態注冊有什么區別。**
* 靜態注冊:在AndroidManifest.xml文件中進行注冊,當App退出后,Receiver仍然可以接收到廣播并且進行相應的處理
* 動態注冊:在代碼中動態注冊,當App退出后,也就沒辦法再接受廣播了
---
**ContentProvider使用方法**
[http://blog.csdn.net/juetion/article/details/17481039](http://blog.csdn.net/juetion/article/details/17481039)
---
**目前能否保證service不被殺死**
**Service設置成START_STICKY**
* kill 后會被重啟(等待5秒左右),重傳Intent,保持與重啟前一樣
**提升service優先級**
* 在AndroidManifest.xml文件中對于intent-filter可以通過``android:priority = "1000"``這個屬性設置最高優先級,1000是最高值,如果數字越小則優先級越低,**同時適用于廣播**。
* 【結論】目前看來,priority這個屬性貌似只適用于broadcast,對于Service來說可能無效
**提升service進程優先級**
* Android中的進程是托管的,當系統進程空間緊張的時候,會依照優先級自動進行進程的回收
* 當service運行在低內存的環境時,將會kill掉一些存在的進程。因此進程的優先級將會很重要,可以在startForeground()使用startForeground()將service放到前臺狀態。這樣在低內存時被kill的幾率會低一些。
* 【結論】如果在極度極度低內存的壓力下,該service還是會被kill掉,并且不一定會restart()
**onDestroy方法里重啟service**
* service +broadcast 方式,就是當service走ondestory()的時候,發送一個自定義的廣播,當收到廣播的時候,重新啟動service
* 也可以直接在onDestroy()里startService
* 【結論】當使用類似口口管家等第三方應用或是在setting里-應用-強制停止時,APP進程可能就直接被干掉了,onDestroy方法都進不來,所以還是無法保證
**監聽系統廣播判斷Service狀態**
* 通過系統的一些廣播,比如:手機重啟、界面喚醒、應用狀態改變等等監聽并捕獲到,然后判斷我們的Service是否還存活,別忘記加權限
* 【結論】這也能算是一種措施,不過感覺監聽多了會導致Service很混亂,帶來諸多不便
**在JNI層,用C代碼fork一個進程出來**
* 這樣產生的進程,會被系統認為是兩個不同的進程.但是Android5.0之后可能不行
**root之后放到system/app變成系統級應用**
**大招: 放一個像素在前臺(手機QQ)**
---
**動畫有哪兩類,各有什么特點?三種動畫的區別**
* tween 補間動畫。通過指定View的初末狀態和變化時間、方式,對View的內容完成一系列的圖形變換來實現動畫效果。
Alpha
Scale
Translate
Rotate。
* frame 幀動畫
AnimationDrawable 控制
animation-list xml布局
* PropertyAnimation 屬性動畫
---
**Android的數據存儲形式。**
* SQLite:SQLite是一個輕量級的數據庫,支持基本的SQL語法,是常被采用的一種數據存儲方式。
Android為此數據庫提供了一個名為SQLiteDatabase的類,封裝了一些操作數據庫的api
* SharedPreference: 除SQLite數據庫外,另一種常用的數據存儲方式,其本質就是一個xml文件,常用于存儲較簡單的參數設置。
* File: 即常說的文件(I/O)存儲方法,常用語存儲大數量的數據,但是缺點是更新數據將是一件困難的事情。
* ContentProvider: Android系統中能實現所有應用程序共享的一種數據存儲方式,由于數據通常在各應用間的是互相私密的,所以此存儲方式較少使用,但是其又是必不可少的一種存儲方式。例如音頻,視頻,圖片和通訊錄,一般都可以采用此種方式進行存儲。每個Content Provider都會對外提供一個公共的URI(包裝成Uri對象),如果應用程序有數據需要共享時,就需要使用Content Provider為這些數據定義一個URI,然后其他的應用程序就通過Content Provider傳入這個URI來對數據進行操作。
---
**Sqlite的基本操作。**
[http://blog.csdn.net/zgljl2012/article/details/44769043](http://blog.csdn.net/zgljl2012/article/details/44769043)
---
**如何判斷應用被強殺**
在Applicatio中定義一個static常量,賦值為-1,在歡迎界面改為0,如果被強殺,application重新初始化,在父類Activity判斷該常量的值。
**應用被強殺如何解決**
如果在每一個Activity的onCreate里判斷是否被強殺,冗余了,封裝到Activity的父類中,如果被強殺,跳轉回主界面,如果沒有被強殺,執行Activity的初始化操作,給主界面傳遞intent參數,主界面會調用onNewIntent方法,在onNewIntent跳轉到歡迎頁面,重新來一遍流程。
**Json有什么優劣勢。**
**怎樣退出終止App**
**Asset目錄與res目錄的區別。**
**Android怎么加速啟動Activity。**
**Android內存優化方法:ListView優化,及時關閉資源,圖片緩存等等。**
**Android中弱引用與軟引用的應用場景。**
**Bitmap的四種屬性,與每種屬性隊形的大小。**
**View與View Group分類。自定義View過程:onMeasure()、onLayout()、onDraw()。**
如何自定義控件:
1. 自定義屬性的聲明和獲取
* 分析需要的自定義屬性
* 在res/values/attrs.xml定義聲明
* 在layout文件中進行使用
* 在View的構造方法中進行獲取
2. 測量onMeasure
3. 布局onLayout(ViewGroup)
4. 繪制onDraw
5. onTouchEvent
6. onInterceptTouchEvent(ViewGroup)
7. 狀態的恢復與保存
**Android長連接,怎么處理心跳機制。**
---
**View樹繪制流程**
---
**下拉刷新實現原理**
---
**你用過什么框架,是否看過源碼,是否知道底層原理。**
Retrofit
EventBus
glide
---
**Android5.0、6.0新特性。**
Android5.0新特性:
* MaterialDesign設計風格
* 支持多種設備
* 支持64位ART虛擬機
Android6.0新特性
* 大量漂亮流暢的動畫
* 支持快速充電的切換
* 支持文件夾拖拽應用
* 相機新增專業模式
Android7.0新特性
* 分屏多任務
* 增強的Java8語言模式
* 夜間模式
---
**Context區別**
* Activity和Service以及Application的Context是不一樣的,Activity繼承自ContextThemeWraper.其他的繼承自ContextWrapper
* 每一個Activity和Service以及Application的Context都是一個新的ContextImpl對象
* getApplication()用來獲取Application實例的,但是這個方法只有在Activity和Service中才能調用的到。那么也許在絕大多數情況下我們都是在Activity或者Service中使用Application的,但是如果在一些其它的場景,比如BroadcastReceiver中也想獲得Application的實例,這時就可以借助getApplicationContext()方法,getApplicationContext()比getApplication()方法的作用域會更廣一些,任何一個Context的實例,只要調用getApplicationContext()方法都可以拿到我們的Application對象。
* Activity在創建的時候會new一個ContextImpl對象并在attach方法中關聯它,Application和Service也差不多。ContextWrapper的方法內部都是轉調ContextImpl的方法
* 創建對話框傳入Application的Context是不可以的
* 盡管Application、Activity、Service都有自己的ContextImpl,并且每個ContextImpl都有自己的mResources成員,但是由于它們的mResources成員都來自于唯一的ResourcesManager實例,所以它們看似不同的mResources其實都指向的是同一塊內存
* Context的數量等于Activity的個數 + Service的個數 + 1,這個1為Application
---
**IntentService的使用場景與特點。**
>IntentService是Service的子類,是一個異步的,會自動停止的服務,很好解決了傳統的Service中處理完耗時操作忘記停止并銷毀Service的問題
優點:
* 一方面不需要自己去new Thread
* 另一方面不需要考慮在什么時候關閉該Service
onStartCommand中回調了onStart,onStart中通過mServiceHandler發送消息到該handler的handleMessage中去。最后handleMessage中回調onHandleIntent(intent)。
---
**圖片緩存**
查看每個應用程序最高可用內存:
```
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
Log.d("TAG", "Max memory is " + maxMemory + "KB");
```
---
**Gradle**
構建工具、Groovy語法、Java
Jar包里面只有代碼,aar里面不光有代碼還包括
---
**你是如何自學Android**
首先是看書和看視頻敲代碼,然后看大牛的博客,做一些項目,向github提交代碼,覺得自己API掌握的不錯之后,開始看進階的書,以及看源碼,看完源碼學習到一些思想,開始自己造輪子,開始想代碼的提升,比如設計模式,架構,重構等。
---
- JavaSE(Java基礎)
- Java基礎知識
- Java中的內存泄漏
- String源碼分析
- Java集合結構
- ArrayList源碼剖析
- HashMap源碼剖析
- Hashtable簡介
- Vector源碼剖析
- LinkedHashMap簡介
- LinkedList簡介
- JVM(Java虛擬機)
- JVM基礎知識
- JVM類加載機制
- Java內存區域與內存溢出
- 垃圾回收算法
- Java并發(JavaConcurrent)
- Java并發基礎知識
- 生產者和消費者問題
- Thread和Runnable實現多線程的區別
- 線程中斷
- 守護線程與阻塞線程的情況
- Synchronized
- 多線程環境中安全使用集合API
- 實現內存可見的兩種方法比較:加鎖和volatile變量
- 死鎖
- 可重入內置鎖
- 使用wait/notify/notifyAll實現線程間通信
- NIO
- 數據結構(DataStructure)
- 數組
- 棧和隊列
- Algorithm(算法)
- 排序
- 選擇排序
- 冒泡排序
- 快速排序
- 歸并排序
- 查找
- 順序查找
- 折半查找
- Network(網絡)
- TCP/UDP
- HTTP
- Socket
- OperatingSystem(操作系統)
- Linux系統的IPC
- android中常用設計模式
- 面向對象六大原則
- 單例模式
- Builder模式
- 原型模式
- 簡單工廠
- 策略模式
- 責任鏈模式
- 觀察者模式
- 代理模式
- 適配器模式
- 外觀模式
- Android(安卓面試點)
- Android基礎知識
- Android內存泄漏總結
- Handler內存泄漏分析及解決
- Android性能優化
- ListView詳解
- RecyclerView和ListView的異同
- AsyncTask源碼分析
- 插件化技術
- 自定義控件
- ANR問題
- Art和Dalvik的區別
- Android關于OOM的解決方案
- Fragment
- SurfaceView
- Android幾種進程
- APP啟動過程
- 圖片三級緩存
- Bitmap的分析與使用
- 熱修復的原理
- AIDL
- Binder機制
- Zygote和System進程的啟動過程
- Android中的MVC,MVP和MVVM
- MVP
- Android開機過程
- EventBus用法詳解
- 查漏補缺
- Git操作