Android:
五種布局: FrameLayout 、 LinearLayout 、 AbsoluteLayout 、 RelativeLayout 、 TableLayout 全都繼承自ViewGroup,各自特點及繪制效率對比。
-
FrameLayout(架構布局)
此布局是五種布局中最簡單的布局,Android中并沒有對child view的擺布進行控制,這個布局中所有的控件都會預設出現在視圖的左上角,我們可以使用
,android:layout_margin
等屬性去控制子控件相對布局的位置。android:layout_gravity
-
LinearLayout(線性布局)
一行(或一列)隻控制一個控件的線性布局,是以當有很多控件需要在一個界面中列出時,可以用LinearLayout布局。
此布局有一個需要格外注意的屬性:
。android:orientation=“horizontal|vertical
- 當
時,說明你希望将水準方向的布局交給LinearLayout* ,其子元素的android:orientation="horizontal
等控制水準方向的gravity值都是被忽略的,此時LinearLayout中的子元素都是預設的按照水準從左向右來排*,我們可以用android:layout_gravity="right|left"
等gravity值來控制垂直展示。android:layout_gravity="top|bottom"
- 反之,可以知道 當
時,LinearLayout對其子元素展示上的的處理方式。android:orientation="vertical
- 當
-
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()
- 解鎖:
onStart()->onResume()
-
更多流程分支,請參照以下生命周期流程圖
[圖檔上傳失敗...(image-b8ce9c-1534251148738)]
通過Acitivty的xml标簽來改變任務棧的預設行為
- 使用
android:launchMode="standard|singleInstance|singleTask|singleTop"
來控制Acivity任務棧。
任務棧是一種後進先出的結構。位于棧頂的Activity處于焦點狀态,當按下back按鈕的時候,棧内的Activity會一個一個的出棧,并且調用其
方法。如果棧内沒有Activity,那麼系統就會回收這個棧,每個APP預設隻有一個棧,以APP的包名來命名.onDestory()
- standard : 标準模式,每次啟動Activity都會建立一個新的Activity執行個體,并且将其壓入任務棧棧頂,而不管這個Activity是否已經存在。Activity的啟動三回調(onCreate()->onStart()->onResume())都會執行。
- singleTop : 棧頂複用模式.這種模式下,如果新Activity已經位于任務棧的棧頂,那麼此Activity不會被重新建立,是以它的啟動三回調就不會執行,同時Activity的
方法會被回調.如果Activity已經存在但是不在棧頂,那麼作用與standard模式一樣.onNewIntent()
- singleTask: 棧内複用模式.建立這樣的Activity的時候,系統會先确認它所需任務棧已經建立,否則先建立任務棧.然後放入Activity,如果棧中已經有一個Activity執行個體,那麼這個Activity就會被調到棧頂,
,并且singleTask會清理在目前Activity上面的所有Activity.(clear top)onNewIntent()
- 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,app将不會存儲它的狀态。
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如何的一個關系
這我們引用本知識庫裡的一張圖檔:
[圖檔上傳失敗...(image-8b8061-1534251148739)]
為什麼在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/7214247Fragment生命周期
image
注意和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" />
廣播(Broadcast Receiver)的兩種動态注冊和靜态注冊有什麼差別。
- 靜态注冊:在AndroidManifest.xml檔案中進行注冊,當App退出後,Receiver仍然可以接收到廣播并且進行相應的處理
- 動态注冊:在代碼中動态注冊,當App退出後,也就沒辦法再接受廣播了
ContentProvider使用方法
http://blog.csdn.net/juetion/article/details/17481039目前能否保證service不被殺死
Service設定成START_STICKY
- kill 後會被重新開機(等待5秒左右),重傳Intent,保持與重新開機前一樣
提升service優先級
- 在AndroidManifest.xml檔案中對于intent-filter可以通過
這個屬性設定最高優先級,1000是最高值,如果數字越小則優先級越低,同時适用于廣播。android:priority = "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如何判斷應用被強殺
在Application中定義一個static常量,指派為-1,在歡迎界面改為0,如果被強殺,application重新初始化,在父類Activity判斷該常量的值。
應用被強殺如何解決
如果在每一個Activity的onCreate裡判斷是否被強殺,備援了,封裝到Activity的父類中,如果被強殺,跳轉回主界面,如果沒有被強殺,執行Activity的初始化操作,給主界面傳遞intent參數,主界面會調用onNewIntent方法,在onNewIntent跳轉到歡迎頁面,重新來一遍流程。
Json有什麼優劣勢。
怎樣退出終止App
Asset目錄與res目錄的差別。
res 目錄下面有很多檔案,例如 drawable,mipmap,raw 等。res 下面除了 raw 檔案不會被壓縮外,其餘檔案都會被壓縮。同時 res目錄下的檔案可以通過R 檔案通路。Asset 也是用來存儲資源,但是 asset 檔案内容隻能通過路徑或者 AssetManager 讀取。
官方文檔Android怎麼加速啟動Activity。
分兩種情況,啟動應用 和 普通Activity
啟動應用 :Application 的構造方法,onCreate 方法中不要進行耗時操作,資料預讀取(例如 init 資料) 放在異步中操作
啟動普通的Activity:A 啟動B 時不要在 A 的 onPause 中執行耗時操作。因為 B 的 onResume 方法必須等待 A 的 onPause 執行完成後才能運作
Android記憶體優化方法:ListView優化,及時關閉資源,圖檔緩存等等。
Android中弱引用與軟引用的應用場景。
Bitmap的四種屬性,與每種屬性隊形的大小。
View與View Group分類。自定義View過程:onMeasure()、onLayout()、onDraw()。
如何自定義控件:
- 自定義屬性的聲明和擷取
- 分析需要的自定義屬性
- 在res/values/attrs.xml定義聲明
- 在layout檔案中進行使用
- 在View的構造方法中進行擷取
- 測量onMeasure
- 布局onLayout(ViewGroup)
- 繪制onDraw
- onTouchEvent
- onInterceptTouchEvent(ViewGroup)
- 狀态的恢複與儲存
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裡面不光有代碼還包括代碼還包括資源檔案,比如 drawable 檔案,xml 資源檔案。對于一些不常變動的 Android Library,我們可以直接引用 aar,加快編譯速度
你是如何自學Android
首先是看書和看視訊敲代碼,然後看大牛的部落格,做一些項目,向github送出代碼,覺得自己API掌握的不錯之後,開始看進階的書,以及看源碼,看完源碼學習到一些思想,開始自己造輪子,開始想代碼的提升,比如設計模式,架構,重構等。