5.請介紹下 AsyncTask的內(nèi)部實現(xiàn)，適用的場景是

• AsyncTask 內(nèi)部也是 Handler 機(jī)制來完成的，只不過 Android 提供了執(zhí)行框架來提供線程池來

• 執(zhí)行相應(yīng)地任務(wù)，因為線程池的大小問題，所以 AsyncTask 只應(yīng)該用來執(zhí)行耗時時間較短的任務(wù)，

• 比如 HTTP 請求，大規(guī)模的下載和數(shù)據(jù)庫的更改不適用于 AsyncTask，因為會導(dǎo)致線程池堵塞，沒有

• 線程來執(zhí)行其他的任務(wù)，導(dǎo)致的情形是會發(fā)生 AsyncTask 根本執(zhí)行不了的問題。

網(wǎng)絡(luò)相關(guān)

1.TCP三次握手

2.為什么TCP是可靠的，UDP早不可靠的?為什么UDP比TCP快?

• TCP/IP協(xié)議高，因為其擁有三次握手雙向機(jī)制，這一機(jī)制保證校驗了數(shù)據(jù)，保證了他的可靠性。

• UDP就沒有了，udp信息發(fā)出后,不驗證是否到達(dá)對方,所以不可靠。

• 但是就速度來說，還是UDP協(xié)議更高，畢竟其無需重復(fù)返回驗證，只是一次性的

3.http協(xié)議了解多少，說說里面的協(xié)議頭部有哪些字段?

• http(超文本傳輸協(xié)議)是一個基于請求與響應(yīng)模式的、無狀態(tài)的、應(yīng)用層的協(xié)議;http請求由三部分組成，分別是：請求行、消息報頭、請求正文。

• HTTP消息報頭包括普通報頭、請求報頭、響應(yīng)報頭、實體報頭

4.https了解多少

HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

5.談?wù)?HTTP 中Get 和 Post 方法的區(qū)別

• GET - 從指定的服務(wù)器中獲取數(shù)據(jù)，明文發(fā)送內(nèi)容

• POST - 提交數(shù)據(jù)給指定的服務(wù)器處理

• POST請求不能被緩存下來

• POST請求不會保存在瀏覽器瀏覽記錄中

• 以POST請求的URL無法保存為瀏覽器書簽

• POST請求沒有長度限制

6.推送心跳包是TCP包還是UDP包或者HTTP包

心跳包的實現(xiàn)是調(diào)用了socket.sendUrgentData(0xFF)這句代碼實現(xiàn)的，所以，當(dāng)然是TCP包。

7.如何實現(xiàn)文件斷點上傳

在 Android 中上傳文件可以采用 HTTP 方式，也可以采用 Socket 方式，但是 HTTP 方式不能上傳

大文件，這里介紹一種通過 Socket 方式來進(jìn)行斷點續(xù)傳的方式，服務(wù)端會記錄下文件的上傳進(jìn)度，

當(dāng)某一次上傳過程意外終止后，下一次可以繼續(xù)上傳，這里用到的其實還是 J2SE 里的知識。

這個上傳程序的原理是：客戶端第一次上傳時向服務(wù)端發(fā)送

“Content-Length=35;filename=WinRAR_3.90_SC.exe;sourceid=“這種格式的字符串，服務(wù)端 收到后會查找該文件是否有上傳記錄，如果有就返回已經(jīng)上傳的位置，否則返回新生成的 sourceid 以及 position 為 0，類似 sourceid=2324838389;position=0“這樣的字符串，客戶端收到返回后 的字符串后再從指定的位置開始上傳文件。

Fragment相關(guān)

1.Fragment 如何實現(xiàn)類似 Activity 棧的壓棧和出棧效果的?

Fragment 的事物管理器內(nèi)部維持了一個雙向鏈表結(jié)構(gòu)，該結(jié)構(gòu)可以記錄我們每次 add 的

Fragment 和 replace 的 Fragment，然后當(dāng)我們點擊 back 按鈕的時候會自動幫我們實現(xiàn)退棧操作。

2.Fragment 在你們項目中的使用

• Fragment 是 android3.0 以后引入的的概念，做局部內(nèi)容更新更方便，原來為了到達(dá)這一點要

• 把多個布局放到一個 activity 里面，現(xiàn)在可以用多 Fragment 來代替，只有在需要的時候才加載

• Fragment，提高性能。

Fragment 的好處：

• Fragment 可以使你能夠?qū)?activity 分離成多個可重用的組件，每個都有它自己的生命周期和UI。

• Fragment 可以輕松得創(chuàng)建動態(tài)靈活的 UI 設(shè)計，可以適應(yīng)于不同的屏幕尺寸。從手機(jī)到平板電腦。

• Fragment 是一個獨立的模塊,緊緊地與 activity 綁定在一起。可以運行中動態(tài)地移除、加入、交換等。

• Fragment 提供一個新的方式讓你在不同的安卓設(shè)備上統(tǒng)一你的 UI。

• Fragment 解決 Activity 間的切換不流暢，輕量切換。

• Fragment 替代 TabActivity 做導(dǎo)航，性能更好。

• Fragment 在 4.2.版本中新增嵌套 fragment 使用方法，能夠生成更好的界面效果

3.如何切換 fragement,不重新實例化

正確的切換方式是 add()，切換時 hide()，add()另一個 Fragment;再次切換時，只需 hide()當(dāng)前， show()另一個

四大組件相關(guān)

1.Activity和Fragment生命周期有哪些?

Activity——onCreate->onStart->onResume->onPause->onStop->onDestroy

Fragment——onAttach->onCreate->onCreateView->onActivityCreated->onStart->onResume->onPause->onStop->onDestroyView->onDestroy->onDetach

2.廣播的兩種注冊方式及有什么區(qū)別

3.內(nèi)存不足時，怎么保持Activity的一些狀態(tài)，在哪個方法里面做具體操作?

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ù)的持久化保存。

4.啟動service的兩種方法?有什么區(qū)別?

一種是startService(),另一種是bindService()。這兩者的區(qū)別是第一種方式調(diào)用者開啟了服務(wù)，即會與服務(wù)失去聯(lián)系，兩者沒有關(guān)聯(lián)。即使訪問者退出了，服務(wù)仍在運行。如需解除服務(wù)必須顯式的調(diào)用stopService方法。主要用于調(diào)用者與服務(wù)沒有交互的情況下，也就是調(diào)用者不需要獲取服務(wù)里的業(yè)務(wù)方法。比如電話錄音。而后者調(diào)用者與服務(wù)綁定在一起的。當(dāng)調(diào)用者退出的時候，服務(wù)也隨之退出。用于需要與服務(wù)交互。

5.Android中的Context, Activity，Appliction有什么區(qū)別?

相同：Activity和Application都是Context的子類。

Context從字面上理解就是上下文的意思，在實際應(yīng)用中它也確實是起到了管理上下文環(huán)境中各個參數(shù)和變量的總用，方便我們可以簡單的訪問到各種資源。

不同：維護(hù)的生命周期不同。 Context維護(hù)的是當(dāng)前的Activity的生命周期，Application維護(hù)的是整個項目的生命周期。

使用context的時候，小心內(nèi)存泄露，防止內(nèi)存泄露，注意一下幾個方面：

不要讓生命周期長的對象引用activity context，即保證引用activity的對象要與activity本身生命周期是一樣的。

對于生命周期長的對象，可以使用application，context。

避免非靜態(tài)的內(nèi)部類，盡量使用靜態(tài)類，避免生命周期問題，注意內(nèi)部類對外部對象引用導(dǎo)致的生命周期變化。

6.Context是什么?

它描述的是一個應(yīng)用程序環(huán)境的信息，即上下文。

該類是一個抽象(abstract class)類，Android提供了該抽象類的具體實現(xiàn)類(ContextIml)。

通過它我們可以獲取應(yīng)用程序的資源和類，也包括一些應(yīng)用級別操作，例如：啟動一個Activity，發(fā)送廣播，接受Intent，信息，等。

7.Service 是否在 main thread 中執(zhí)行, service 里面是否能執(zhí)行耗時的操作?

默認(rèn)情況,如果沒有顯示的指 servic 所運行的進(jìn)程, Service 和 activity 是運行在當(dāng)前 app 所在進(jìn)

程的 main thread(UI 主線程)里面。

service 里面不能執(zhí)行耗時的操作(網(wǎng)絡(luò)請求,拷貝數(shù)據(jù)庫,大文件 )

特殊情況 ,可以在清單文件配置 service 執(zhí)行所在的進(jìn)程 ,讓 service 在另外的進(jìn)程中執(zhí)行 ? 1 2 3 4 5

8.Activity 怎么和 Service 綁定，怎么在 Activity 中啟動自己對應(yīng)的Service?

Activity 通過 bindService(Intent service, ServiceConnection conn, int flags)跟 Service 進(jìn)行綁定，當(dāng)綁定成功的時候 Service 會將代理對象通過回調(diào)的形式傳給 conn，這樣我們就拿到了Service 提供的服務(wù)代理對象。

在 Activity 中可以通過 startService 和 bindService 方法啟動 Service。一般情況下如果想獲取Service 的服務(wù)對象那么肯定需要通過 bindService()方法，比如音樂播放器，第三方支付等。如果僅僅只是為了開啟一個后臺任務(wù)那么可以使用 startService()方法。

9.說說 Activity、Intent、Service 是什么關(guān)系

他們都是 Android 開發(fā)中使用頻率最高的類。其中 Activity 和 Service 都是 Android 四大組件之一。他倆都是 Context 類的子類 ContextWrapper 的子類，因此他倆可以算是兄弟關(guān)系吧。不過兄弟倆各有各自的本領(lǐng)，Activity 負(fù)責(zé)用戶界面的顯示和交互，Service 負(fù)責(zé)后臺任務(wù)的處理。Activity和 Service 之間可以通過 Intent 傳遞數(shù)據(jù)，因此可以把 Intent 看作是通信使者。

10.請描述一下 BroadcastReceiver

BroadCastReceiver 是 Android 四大組件之一，主要用于接收系統(tǒng)或者 app 發(fā)送的廣播事件。

廣播分兩種：有序廣播和無序廣播。

內(nèi)部通信實現(xiàn)機(jī)制：通過 Android 系統(tǒng)的 Binder 機(jī)制實現(xiàn)通信。

無序廣播：完全異步，邏輯上可以被任何廣播接收者接收到。優(yōu)點是效率較高。缺點是一個接收者不

能將處理結(jié)果傳遞給下一個接收者，并無法終止廣播 intent 的傳播。

有序廣播：按照被接收者的優(yōu)先級順序，在被接收者中依次傳播。比如有三個廣播接收者 A，B，C，

優(yōu)先級是 A > B > C。那這個消息先傳給 A，再傳給 B，最后傳給 C。每個接收者有權(quán)終止廣播，比如 B 終止廣播，C 就無法接收到。此外 A 接收到廣播后可以對結(jié)果對象進(jìn)行操作，當(dāng)廣播傳給 B 時，B 可以從結(jié)果對象中取得 A 存入的數(shù)據(jù)。

在通過 Context.sendOrderedBroadcast(intent, receiverPermission, resultReceiver, scheduler,initialCode, initialData, initialExtras)時我們可以指定 resultReceiver 廣播接收者，這個接收者我們可以認(rèn)為是最終接收者，通常情況下如果比他優(yōu)先級更高的接收者如果沒有終止廣播，那么他的onReceive 會被執(zhí)行兩次，第一次是正常的按照優(yōu)先級順序執(zhí)行，第二次是作為最終接收者接收。

如果比他優(yōu)先級高的接收者終止了廣播，那么他依然能接收到廣播

11.為什么要用 ContentProvider?它和 sql 的實現(xiàn)上有什么差別?

ContentProvider 屏蔽了數(shù)據(jù)存儲的細(xì)節(jié),內(nèi)部實現(xiàn)對用戶完全透明,用戶只需要關(guān)心操作數(shù)據(jù)的uri 就可以了，ContentProvider 可以實現(xiàn)不同 app 之間共享。

Sql 也有增刪改查的方法，但是 sql 只能查詢本應(yīng)用下的數(shù)據(jù)庫。而 ContentProvider 還可以去增刪改查本地文件. xml 文件的讀取等。

12.說說 ContentProvider、ContentResolver、ContentObserver 之間的關(guān)系

a. ContentProvider 內(nèi)容提供者，用于對外提供數(shù)據(jù)

b. ContentResolver.notifyChange(uri)發(fā)出消息

c. ContentResolver 內(nèi)容解析者，用于獲取內(nèi)容提供者提供的數(shù)據(jù)

d. ContentObserver 內(nèi)容監(jiān)聽器，可以監(jiān)聽數(shù)據(jù)的改變狀態(tài)

e. ContentResolver.registerContentObserver()監(jiān)聽消息。

View 相關(guān)

1.onInterceptTouchEvent()和onTouchEvent()的區(qū)別

onInterceptTouchEvent()用于攔截觸摸事件

onTouchEvent()用于處理觸摸事件

2.RemoteView在哪些功能中使用

APPwidget和Notification中SurfaceView和View的區(qū)別是什么?

SurfaceView中采用了雙緩存技術(shù)，在單獨的線程中更新界面View在UI線程中更新界面

4.View的繪制過程

一個View要顯示在界面上，需要經(jīng)歷一個View樹的遍歷過程，這個過程又可以分為三個過程，也就是自定義View中的三要素：大小，位置，畫什么，即onMesure()，onLayout(),onDraw()。

1.onMesure()確定一個View的大小;

2.onLayout()確定View在父節(jié)點上的位置;

3.onDraw()繪制View 的內(nèi)容;

5.如何自定義ViewGroup

1.指定的LayoutParams

2.onMeasure中計算所有childView的寬和高，然后根據(jù)childView的寬和高，計算自己的寬和高。(當(dāng)然，如果不是wrap_content，直接使用父ViewGroup傳入的計算值即可)

3.onLayout中對所有的childView進(jìn)行布局。

6.View中onTouch，onTouchEvent，onClick的執(zhí)行順序

dispatchTouchEvent—->onTouch—->onTouchEvent—–>onClick。在所有ACTION_UP事件之后才觸發(fā)onClick點擊事件。

性能優(yōu)化相關(guān)

1.ListView卡頓的原因與性能優(yōu)化，越多越好

重用converView： 通過復(fù)用converview來減少不必要的view的創(chuàng)建，另外Infalte操作會把xml文件實例化成相應(yīng)的View實例，屬于IO操作，是耗時操作。

減少findViewById()操作： 將xml文件中的元素封裝成viewholder靜態(tài)類，通過converview的setTag和getTag方法將view與相應(yīng)的holder對象綁定在一起，避免不必要的findviewbyid操作

避免在 getView 方法中做耗時的操作: 例如加載本地 Image 需要載入內(nèi)存以及解析 Bitmap ，都是比較耗時的操作，如果用戶快速滑動listview，會因為getview邏輯過于復(fù)雜耗時而造成滑動卡頓現(xiàn)象。用戶滑動時候不要加載圖片，待滑動完成再加載，可以使用這個第三方庫glideItem的布局層次結(jié)構(gòu)盡量簡單，避免布局太深或者不必要的重繪

盡量能保證 Adapter 的 hasStableIds() 返回 true 這樣在 notifyDataSetChanged() 的時候，如果item內(nèi)容并沒有變化，ListView 將不會重新繪制這個 View，達(dá)到優(yōu)化的目的

在一些場景中，ScollView內(nèi)會包含多個ListView，可以把listview的高度寫死固定下來。 由于ScollView在快速滑動過程中需要大量計算每一個listview的高度，阻塞了UI線程導(dǎo)致卡頓現(xiàn)象出現(xiàn)，如果我們每一個item的高度都是均勻的，可以通過計算把listview的高度確定下來，避免卡頓現(xiàn)象出現(xiàn)

使用 RecycleView 代替listview： 每個item內(nèi)容的變動，listview都需要去調(diào)用notifyDataSetChanged來更新全部的item，太浪費性能了。RecycleView可以實現(xiàn)當(dāng)個item的局部刷新，并且引入了增加和刪除的動態(tài)效果，在性能上和定制上都有很大的改善

ListView 中元素避免半透明： 半透明繪制需要大量乘法計算，在滑動時不停重繪會造成大量的計算，在比較差的機(jī)子上會比較卡。 在設(shè)計上能不半透明就不不半透明。實在要弄就把在滑動的時候把半透明設(shè)置成不透明，滑動完再重新設(shè)置成半透明。

盡量開啟硬件加速： 硬件加速提升巨大，避免使用一些不支持的函數(shù)導(dǎo)致含淚關(guān)閉某個地方的硬件加速。當(dāng)然這一條不只是對 ListView。

2.如何避免 OOM 問題的出現(xiàn)

使用更加輕量的數(shù)據(jù)結(jié)構(gòu) 例如，我們可以考慮使用ArrayMap/SparseArray而不是HashMap等傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)。通常的HashMap的實現(xiàn)方式更加消耗內(nèi)存，因為它需要一個額外的實例對象來記錄Mapping操作。另外，SparseArray更加高效，在于他們避免了對key與value的自動裝箱(autoboxing)，并且避免了裝箱后的解箱。

避免在Android里面使用Enum Android官方培訓(xùn)課程提到過“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具體原理請參考《Android性能優(yōu)化典范(三)》，所以請避免在Android里面使用到枚舉。

減小Bitmap對象的內(nèi)存占用 Bitmap是一個極容易消耗內(nèi)存的大胖子，減小創(chuàng)建出來的Bitmap的內(nèi)存占用可謂是重中之重，，通常來說有以下2個措施： inSampleSize：縮放比例，在把圖片載入內(nèi)存之前，我們需要先計算出一個合適的縮放比例，避免不必要的大圖載入。 decode format：解碼格式，選擇ARGB_6666/RBG_545/ARGB_4444/ALPHA_6，存在很大差異

Bitmap對象的復(fù)用 縮小Bitmap的同時，也需要提高BitMap對象的復(fù)用率，避免頻繁創(chuàng)建BitMap對象，復(fù)用的方法有以下2個措施 LRUCache : “最近最少使用算法”在Android中有極其普遍的應(yīng)用。ListView與GridView等顯示大量圖片的控件里，就是使用LRU的機(jī)制來緩存處理好的Bitmap，把近期最少使用的數(shù)據(jù)從緩存中移除，保留使用最頻繁的數(shù)據(jù)， inBitMap高級特性:利用inBitmap的高級特性提高Android系統(tǒng)在Bitmap分配與釋放執(zhí)行效率。使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經(jīng)存在的內(nèi)存區(qū)域，新解碼的Bitmap會嘗試去使用之前那張Bitmap在Heap中所占據(jù)的pixel data內(nèi)存區(qū)域，而不是去問內(nèi)存重新申請一塊區(qū)域來存放Bitmap。利用這種特性，即使是上千張的圖片，也只會僅僅只需要占用屏幕所能夠顯示的圖片數(shù)量的內(nèi)存大小

使用更小的圖片 在涉及給到資源圖片時，我們需要特別留意這張圖片是否存在可以壓縮的空間，是否可以使用更小的圖片。盡量使用更小的圖片不僅可以減少內(nèi)存的使用，還能避免出現(xiàn)大量的InflationException。假設(shè)有一張很大的圖片被XML文件直接引用，很有可能在初始化視圖時會因為內(nèi)存不足而發(fā)生InflationException，這個問題的根本原因其實是發(fā)生了OOM。

StringBuilder 在有些時候，代碼中會需要使用到大量的字符串拼接的操作，這種時候有必要考慮使用StringBuilder來替代頻繁的“+”。

避免在onDraw方法里面執(zhí)行對象的創(chuàng)建 類似onDraw等頻繁調(diào)用的方法，一定需要注意避免在這里做創(chuàng)建對象的操作，因為他會迅速增加內(nèi)存的使用，而且很容易引起頻繁的gc，甚至是內(nèi)存抖動。

避免對象的內(nèi)存泄露

3.三級緩存的原理

從緩存中加載。

從本地文件中加載(數(shù)據(jù)庫，SD)

從網(wǎng)絡(luò)加載。

a.加載 bitmap 的時候無需考慮 bitmap 加載過程中出現(xiàn)的 oom(內(nèi)存溢出)和 android 容器快速

滑動的時候出現(xiàn)的圖片錯位等現(xiàn)象。(16M)

b. 支持加載網(wǎng)絡(luò)圖片和本地圖片。

c. 內(nèi)存管理使用的 lru 算法(移除里面是有頻率最少的對象)，更好的管理 bitmap 的內(nèi)存

Android其他

1.講一下android中進(jìn)程的優(yōu)先級?

• 前臺進(jìn)程

• 可見進(jìn)程

• 服務(wù)進(jìn)程

• 后臺進(jìn)程

• 空進(jìn)程

2.介紹Handle的機(jī)制

Handler通過調(diào)用sendmessage方法把消息放在消息隊列MessageQueue中，Looper負(fù)責(zé)把消息從消息隊列中取出來，重新再交給Handler進(jìn)行處理，三者形成一個循環(huán)

通過構(gòu)建一個消息隊列，把所有的Message進(jìn)行統(tǒng)一的管理，當(dāng)Message不用了，并不作為垃圾回收，而是放入消息隊列中，供下次handler創(chuàng)建消息時候使用，提高了消息對象的復(fù)用，減少系統(tǒng)垃圾回收的次數(shù)

每一個線程，都會單獨對應(yīng)的一個looper，這個looper通過ThreadLocal來創(chuàng)建，保證每個線程只創(chuàng)建一個looper，looper初始化后就會調(diào)用looper.loop創(chuàng)建一個MessageQueue，這個方法在UI線程初始化的時候就會完成，我們不需要手動創(chuàng)建

3.Dalvik虛擬機(jī)與JVM有什么區(qū)別

Dalvik 基于寄存器，而 JVM 基于棧?；诩拇嫫鞯奶摂M機(jī)對于更大的程序來說，在它們編譯的時候，花費的時間更短。

Dalvik執(zhí)行.dex格式的字節(jié)碼，而JVM執(zhí)行.class格式的字節(jié)碼。

4.每個應(yīng)用程序?qū)?yīng)多少個Dalvik虛擬機(jī)

每一個Android應(yīng)用在底層都會對應(yīng)一個獨立的Dalvik虛擬機(jī)實例，其代碼在虛擬機(jī)的解釋下得以執(zhí)行 ，而所有的Android應(yīng)用的線程都對應(yīng)一個Linux線程

5.應(yīng)用常駐后臺，避免被第三方殺掉的方法

Service設(shè)置成START_STICKY kill 后會被重啟(等待5秒左右)，重傳Intent，保持與重啟前一樣

通過 startForeground將進(jìn)程設(shè)置為前臺進(jìn)程， 做前臺服務(wù)，優(yōu)先級和前臺應(yīng)用一個級別，除非在系統(tǒng)內(nèi)存非常缺，否則此進(jìn)程不會被 kill

雙進(jìn)程Service： 讓2個進(jìn)程互相保護(hù)對方，其中一個Service被清理后，另外沒被清理的進(jìn)程可以立即重啟進(jìn)程

用C編寫守護(hù)進(jìn)程(即子進(jìn)程) : Android系統(tǒng)中當(dāng)前進(jìn)程(Process)fork出來的子進(jìn)程，被系統(tǒng)認(rèn)為是兩個不同的進(jìn)程。當(dāng)父進(jìn)程被殺死的時候，子進(jìn)程仍然可以存活，并不受影響(Android5.0以上的版本不可行

聯(lián)系廠商，加入白名單

6.根據(jù)自己的理解描述下Android數(shù)字簽名。

所有的應(yīng)用程序都必須有數(shù)字證書，Android系統(tǒng)不會安裝一個沒有數(shù)字證書的應(yīng)用程序

Android程序包使用的數(shù)字證書可以是自簽名的，不需要一個權(quán)威的數(shù)字證書機(jī)構(gòu)簽名認(rèn)證

如果要正式發(fā)布一個Android程序，必須使用一個合適的私鑰生成的數(shù)字證書來給程序簽名，而不能使用adt插件或者ant工具生成的調(diào)試證書來發(fā)布。

數(shù)字證書都是有有效期的，Android只是在應(yīng)用程序安裝的時候才會檢查證書的有效期。如果程序已經(jīng)安裝在系統(tǒng)中，即使證書過期也不會影響程序的正常功能。

7.Dalvik基于JVM的改進(jìn)

幾個class變?yōu)橐粋€dex，constant pool，省內(nèi)存

Zygote，copy-on-write shared,省內(nèi)存，省cpu，省電

基于寄存器的bytecode，省指令，省cpu，省電

Trace-based JIT,省cpu，省電,省內(nèi)存

8.ARGB_8888占用內(nèi)存大小

本題的答案，是4byte，即ARGB各占用8個比特來描述。

9.apk安裝卸載的原理

安裝過程：復(fù)制apk安裝包到data/app目錄下，解壓并掃描安裝包，把dex文件(dalvik字節(jié)碼)保存到dalvik-cache目錄，并data/data目錄下創(chuàng)建對應(yīng)的應(yīng)用數(shù)據(jù)目錄。

卸載過程：刪除安裝過程中在上述三個目錄下創(chuàng)建的文件及目錄。

10.通過Intent傳遞一些二進(jìn)制數(shù)據(jù)的方法有哪些?

使用Serializable接口實現(xiàn)序列化，這是Java常用的方法。

實現(xiàn)Parcelable接口，這里Android的部分類比如Bitmap類就已經(jīng)實現(xiàn)了，同時Parcelable在Android AIDL中交換數(shù)據(jù)也很常見的。

11.橫豎屏切換時Activity的生命周期

此時的生命周期跟清單文件里的配置有關(guān)系。

不設(shè)置Activity的android:configChanges時，切屏?xí)匦抡{(diào)用各個生命周期默認(rèn)首先銷毀當(dāng)前activity,然后重新加載。

設(shè)置Activity android:configChanges=”orientation|keyboardHidden|screenSize”時，切屏不會重新調(diào)用各個生命周期，只會執(zhí)行onConfigurationChanged方法

12.Serializable 和 Parcelable 的區(qū)別

在使用內(nèi)存的時候，Parcelable 類比 Serializable 性能高，所以推薦使用 Parcelable 類。

Serializable 在序列化的時候會產(chǎn)生大量的臨時變量，從而引起頻繁的 GC。

Parcelable 不能使用在要將數(shù)據(jù)存儲在磁盤上的情況。盡管 Serializable 效率低點，但在這

種情況下，還是建議你用 Serializable 。

13.Android 中如何捕獲未捕獲的異常

自 定 義 一 個 Application ， 比 如 叫 MyApplication 繼 承 Application 實 現(xiàn)

UncaughtExceptionHandler。

覆寫 UncaughtExceptionHandler 的 onCreate 和 uncaughtException 方法。

14.Android 的權(quán)限規(guī)則

Android 中的 apk 必須簽名

基于 UserID 的進(jìn)程級別的安全機(jī)制

默認(rèn) apk 生成的數(shù)據(jù)對外是不可見的

AndroidManifest.xml 中的顯式權(quán)限聲明

15.多線程間通信和多進(jìn)程之間通信有什么不同，分別怎么實現(xiàn)?

一、進(jìn)程間的通信方式

**管道( pipe )：**管道是一種半雙工的通信方式，數(shù)據(jù)只能單向流動，而且只能在具有親緣關(guān)系的進(jìn)程間使用。進(jìn)程的親緣關(guān)系通常是指父子進(jìn)程關(guān)系。

有名管道 (namedpipe)： 有名管道也是半雙工的通信方式，但是它允許無親緣關(guān)系進(jìn)程間的通信。

信號量(semophore )： 信號量是一個計數(shù)器，可以用來控制多個進(jìn)程對共享資源的訪問。它常作為一種鎖機(jī)制，防止某進(jìn)程正在訪問共享資源時，其他進(jìn)程也訪問該資源。因此，主要作為進(jìn)程間以及同一進(jìn)程內(nèi)不同線程之間的同步手段。

消息隊列( messagequeue )： 消息隊列是由消息的鏈表，存放在內(nèi)核中并由消息隊列標(biāo)識符標(biāo)識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節(jié)流以及緩沖區(qū)大小受限等缺點。

信號 (sinal )： 信號是一種比較復(fù)雜的通信方式，用于通知接收進(jìn)程某個事件已經(jīng)發(fā)生。

共享內(nèi)存(shared memory ) ：共享內(nèi)存就是映射一段能被其他進(jìn)程所訪問的內(nèi)存，這段共享內(nèi)存由一個進(jìn)程創(chuàng)建，但多個進(jìn)程都可以訪問。共享內(nèi)存是最快的 IPC 方式，它是針對其他進(jìn)程間通信方式運行效率低而專門設(shè)計的。它往往與其他通信機(jī)制，如信號兩，配合使用，來實現(xiàn)進(jìn)程間的同步和通信。

自我介紹一下，小編13年上海交大畢業(yè)，曾經(jīng)在小公司待過，也去過華為、OPPO等大廠，18年進(jìn)入阿里一直到現(xiàn)在。

深知大多數(shù)初中級Android工程師，想要提升技能，往往是自己摸索成長或者是報班學(xué)習(xí)，但對于培訓(xùn)機(jī)構(gòu)動則近萬的學(xué)費，著實壓力不小。自己不成體系的自學(xué)效果低效又漫長，而且極易碰到天花板技術(shù)停滯不前！

因此收集整理了一份《2024年Android移動開發(fā)全套學(xué)習(xí)資料》，初衷也很簡單，就是希望能夠幫助到想自學(xué)提升又不知道該從何學(xué)起的朋友，同時減輕大家的負(fù)擔(dān)。

既有適合小白學(xué)習(xí)的零基礎(chǔ)資料，也有適合3年以上經(jīng)驗的小伙伴深入學(xué)習(xí)提升的進(jìn)階課程，基本涵蓋了95%以上Android開發(fā)知識點，真正體系化！

由于文件比較大，這里只是將部分目錄截圖出來，每個節(jié)點里面都包含大廠面經(jīng)、學(xué)習(xí)筆記、源碼講義、實戰(zhàn)項目、講解視頻，并且會持續(xù)更新！

如果你覺得這些內(nèi)容對你有幫助，可以掃碼獲取?。。▊渥ⅲ篈ndroid）

建議

當(dāng)我們出去找工作，或者準(zhǔn)備找工作的時候，我們一定要想，我面試的目標(biāo)是什么，我自己的技術(shù)棧有哪些，近期能掌握的有哪些，我的哪些短板 ，列出來，有計劃的去完成，別看前兩天掘金一些大佬在駁來駁去 ，他們的觀點是他們的，不要因為他們的觀點，膨脹了自己，影響自己的學(xué)習(xí)節(jié)奏?；A(chǔ)很大程度決定你自己技術(shù)層次的厚度，你再熟練框架也好，也會比你便宜的，性價比高的替代，很現(xiàn)實的問題但也要有危機(jī)意識，當(dāng)我們年級大了，有哪些亮點，與比我們經(jīng)歷更旺盛的年輕小工程師，競爭。

• 無論你現(xiàn)在水平怎么樣一定要 持續(xù)學(xué)習(xí) 沒有雞湯，別人看起來的毫不費力，其實費了很大力，這四個字就是我的建議?。。。。。。。?！

• 準(zhǔn)備想說怎么樣寫簡歷，想象算了，我覺得，技術(shù)就是你最好的簡歷

• 我希望每一個努力生活的it工程師，都會得到自己想要的，因為我們很辛苦，我們應(yīng)得的。

• 有什么問題想交流，歡迎給我私信，歡迎評論

【附】相關(guān)架構(gòu)及資料

內(nèi)含往期Android高級架構(gòu)資料、源碼、筆記、視頻。高級UI、性能優(yōu)化、架構(gòu)師課程、NDK、混合式開發(fā)（ReactNative+Weex）微信小程序、Flutter全方面的Android進(jìn)階實踐技術(shù)

《互聯(lián)網(wǎng)大廠面試真題解析、進(jìn)階開發(fā)核心學(xué)習(xí)筆記、全套講解視頻、實戰(zhàn)項目源碼講義》點擊傳送門即可獲?。?/strong>文章來源地址http://www.zghlxwxcb.cn/news/detail-852433.html

每個節(jié)點里面都包含大廠面經(jīng)、學(xué)習(xí)筆記、源碼講義、實戰(zhàn)項目、講解視頻，并且會持續(xù)更新！**

如果你覺得這些內(nèi)容對你有幫助，可以掃碼獲?。。。▊渥ⅲ篈ndroid）

建議

當(dāng)我們出去找工作，或者準(zhǔn)備找工作的時候，我們一定要想，我面試的目標(biāo)是什么，我自己的技術(shù)棧有哪些，近期能掌握的有哪些，我的哪些短板 ，列出來，有計劃的去完成，別看前兩天掘金一些大佬在駁來駁去 ，他們的觀點是他們的，不要因為他們的觀點，膨脹了自己，影響自己的學(xué)習(xí)節(jié)奏。基礎(chǔ)很大程度決定你自己技術(shù)層次的厚度，你再熟練框架也好，也會比你便宜的，性價比高的替代，很現(xiàn)實的問題但也要有危機(jī)意識，當(dāng)我們年級大了，有哪些亮點，與比我們經(jīng)歷更旺盛的年輕小工程師，競爭。

• 無論你現(xiàn)在水平怎么樣一定要 持續(xù)學(xué)習(xí) 沒有雞湯，別人看起來的毫不費力，其實費了很大力，這四個字就是我的建議?。。。。。。。?！

• 準(zhǔn)備想說怎么樣寫簡歷，想象算了，我覺得，技術(shù)就是你最好的簡歷

• 我希望每一個努力生活的it工程師，都會得到自己想要的，因為我們很辛苦，我們應(yīng)得的。

• 有什么問題想交流，歡迎給我私信，歡迎評論

【附】相關(guān)架構(gòu)及資料

[外鏈圖片轉(zhuǎn)存中…(img-XStnBDh9-1712353632276)]

[外鏈圖片轉(zhuǎn)存中…(img-Hli8PnPA-1712353632276)]

內(nèi)含往期Android高級架構(gòu)資料、源碼、筆記、視頻。高級UI、性能優(yōu)化、架構(gòu)師課程、NDK、混合式開發(fā)（ReactNative+Weex）微信小程序、Flutter全方面的Android進(jìn)階實踐技術(shù)

《互聯(lián)網(wǎng)大廠面試真題解析、進(jìn)階開發(fā)核心學(xué)習(xí)筆記、全套講解視頻、實戰(zhàn)項目源碼講義》點擊傳送門即可獲?。?/strong>

到了這里，關(guān)于Android 開發(fā)必備知識點及面試題匯總（Android+Java+算法+性能優(yōu)化+四大組件……），騰訊安卓開發(fā)面試的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！