轉(zhuǎn)載請(qǐng)注明出處

synchronized函數(shù)和synchronized代碼塊的區(qū)別

• 1. 首先synchronized函數(shù)和synchronized代碼快的作用范圍有區(qū)別，synchronized函數(shù)一般鎖定的是當(dāng)前類(lèi)對(duì)象，synchronized代碼塊鎖定作用域可以選擇是本對(duì)象，也可以是字符串等等.
• 2. 當(dāng)前類(lèi)對(duì)象鎖沒(méi)有釋放的時(shí)候，本類(lèi)的所有synchronized(this)同步代碼塊都阻塞。如果有并發(fā)請(qǐng)求synchronized函數(shù)，同一時(shí)間只能有一個(gè)請(qǐng)求執(zhí)行 .
• 3. 但是當(dāng)前類(lèi)對(duì)象鎖沒(méi)有釋放的時(shí)候，其他請(qǐng)求可以訪(fǎng)問(wèn)本類(lèi)中不帶synchronized(this)的代碼塊，也可以訪(fǎng)問(wèn)非同一把鎖的代碼塊例如synchronized(Str)等.
• 4. 由于作用范圍有區(qū)別，一般作用范圍越小執(zhí)行效率越高，平時(shí)開(kāi)發(fā)中一般選擇作用范圍較小的synchronized.

如何判斷一個(gè)對(duì)象是可以被回收的

• 1. 之前java虛擬機(jī)使用引用計(jì)數(shù)器的算法，當(dāng)引用計(jì)數(shù)器為0時(shí)代表該對(duì)象沒(méi)有引用了然后被清理。但是這個(gè)方式很難解決循環(huán)引用問(wèn)題，所以目前停止使用了。
• 2. 目前用到的是可達(dá)性分析算法來(lái)確定一個(gè)對(duì)象是不是可以被回收。
• 3. 原理是：通過(guò)一個(gè)叫GC Roots的對(duì)象當(dāng)作根對(duì)象，然后開(kāi)始向下搜索，搜索的路徑叫做引用鏈，當(dāng)對(duì)象到GC Roots沒(méi)有任何引用鏈相連的時(shí)候，則證明此對(duì)象是不可用的.
• 4. 不可用對(duì)象并不是馬上就執(zhí)行回收方法，執(zhí)行清理方法之前至少要經(jīng)歷兩次標(biāo)記過(guò)程.
• ①如果對(duì)象在進(jìn)行可達(dá)性分析后發(fā)現(xiàn)沒(méi)有與GC Roots相連接的引用鏈,那它將會(huì)被第一次標(biāo)記并且進(jìn)行一次篩選,篩選的條件是此對(duì)象是否有必要執(zhí)行finalize()方法。當(dāng)對(duì)象沒(méi)有覆蓋finalize()方法,或者finalize()方法已經(jīng)被虛擬機(jī)調(diào)用過(guò),虛擬機(jī)將這兩種情況都視為“沒(méi)有必要執(zhí)行”。(即意味著直接回收).
• ②如果這個(gè)對(duì)象被判定為有必要執(zhí)行finalize()方法,那么這個(gè)對(duì)象將會(huì)放置在一個(gè)叫做F-Queue的隊(duì)列之中,并在稍后由一個(gè)由虛擬機(jī)自動(dòng)建立的、低優(yōu)先級(jí)的Finalizer線(xiàn)程去執(zhí)行它。這里所謂的“執(zhí)行”是指虛擬機(jī)會(huì)觸發(fā)這個(gè)方法,但并不承諾會(huì)等待它運(yùn)行結(jié)束,這樣做的原因是,如果一個(gè)對(duì)象在finalize()方法中執(zhí)行緩慢,或者發(fā)生了死循環(huán)(更極端的情況),將很可能會(huì)導(dǎo)致F-Queue隊(duì)列中其他對(duì)象永久處于等待,甚至導(dǎo)致整個(gè)內(nèi)存回收系統(tǒng)崩潰.
• 5. finalize()方法是對(duì)象回收前的最后一次機(jī)會(huì),稍后GC將對(duì)F-Queue中的對(duì)象進(jìn)行第二次小規(guī)模的標(biāo)記,如果對(duì)象要在finalize()中不被回收，只要重新與引用鏈上的任何一個(gè)對(duì)象建立關(guān)聯(lián)即可,譬如把自己(this關(guān)鍵字)賦值給某個(gè)類(lèi)變量或者對(duì)象的成員變量,那在第二次標(biāo)記時(shí)它將被移除出“即將回收”的集合;如果對(duì)象這時(shí)候還沒(méi)有逃脫,那基本上它就真的被回收了。
• 6. 任何一個(gè)對(duì)象的finalize()方法都只會(huì)被系統(tǒng)自動(dòng)調(diào)用一次,如果對(duì)象面臨下一次回收,它的finalize()方法不會(huì)被再次執(zhí)行,因此第二段代碼的自救行動(dòng)失敗了。因?yàn)閒inalize()方法已經(jīng)被虛擬機(jī)調(diào)用過(guò),虛擬機(jī)都視為“沒(méi)有必要執(zhí)行”。(即意味著直接回收).

寫(xiě)一個(gè)函數(shù)，輸入一個(gè)數(shù)如38，拆分 3 + 8 = 11，1 + 1 = 2，最后2無(wú)法拆分就返回

    public  int  getNum(int num) {
        while (num >= 10) {
            num = num / 10 + num % 10;
        }
        return num;
    }

多個(gè)進(jìn)程同時(shí)調(diào)用一個(gè)ContentProvider的query獲取數(shù)據(jù)，ContentPrvoider是如何反應(yīng)的呢？

• 分析：
  我們知道Activity這樣的組件，它生命周期的回調(diào)函數(shù)是在UI線(xiàn)程中執(zhí)行的，ContentProvider的onCreate()方法也是在UI線(xiàn)程中運(yùn)行的，回答這個(gè)問(wèn)題前，我們首先要搞清楚ContentProvider的Query()，insert()，delete()，updata()這幾個(gè)方法是否也是在UI線(xiàn)程中運(yùn)行。
• 發(fā)現(xiàn)問(wèn)題：
  如果以上幾個(gè)方法是在UI線(xiàn)程中運(yùn)行的，那么多個(gè)線(xiàn)程并發(fā)去調(diào)用就很有可能出現(xiàn)ANR；如果不是在UI線(xiàn)程運(yùn)行的，那它是在一個(gè)工作線(xiàn)程中運(yùn)行的還是在多個(gè)線(xiàn)程中運(yùn)行的呢？即ContentProvider是否支持并發(fā)操作呢？
• 分析問(wèn)題：
  ContentResolver與ContentProvider類(lèi)隱藏了實(shí)現(xiàn)細(xì)節(jié)，但是ContentProvider所提供的Query()，insert()，delete()，updata()這幾個(gè)方法都是在ContentProvider進(jìn)行的線(xiàn)程池中運(yùn)行的，而不是在進(jìn)程的主線(xiàn)程中運(yùn)行，以為這些方法有可能被多個(gè)地方調(diào)用，所以它們是線(xiàn)程安全的。
  ContentProvider實(shí)現(xiàn)進(jìn)程通信是依賴(lài)于Binder機(jī)制的，所以以上問(wèn)題會(huì)回歸到Binder線(xiàn)程處理問(wèn)題，并不是每一個(gè)ContentProvider都會(huì)有一個(gè)線(xiàn)程池，而是一個(gè)進(jìn)程共用一個(gè)線(xiàn)程池，共用的線(xiàn)程池就是Binder線(xiàn)程池。
• 標(biāo)準(zhǔn)答案：
  一個(gè)content provider可以接受來(lái)自另外一個(gè)進(jìn)程的數(shù)據(jù)請(qǐng)求。盡管ContentResolver與ContentProvider類(lèi)隱藏了實(shí)現(xiàn)細(xì)節(jié)，但是ContentProvider所提供的query()，insert()，delete()，update()都是在ContentProvider進(jìn)程的線(xiàn)程池中被調(diào)用執(zhí)行的，而不是進(jìn)程的主線(xiàn)程中。這個(gè)線(xiàn)程池是有Binder創(chuàng)建和維護(hù)的，其實(shí)使用的就是每個(gè)應(yīng)用進(jìn)程中的Binder線(xiàn)程池。

Android設(shè)計(jì)ContentProvider的目的是什么？

• 1. 隱藏?cái)?shù)據(jù)的實(shí)現(xiàn)方式，對(duì)外提供統(tǒng)一的數(shù)據(jù)訪(fǎng)問(wèn)接口；
• 2. 更好的數(shù)據(jù)訪(fǎng)問(wèn)權(quán)限管理。ContentProvider可以對(duì)開(kāi)發(fā)的數(shù)據(jù)進(jìn)行權(quán)限設(shè)置，不同的URI可以對(duì)應(yīng)不同的權(quán)限，只有符合權(quán)限要求的組件才能訪(fǎng)問(wèn)到ContentProvider的具體操作。
• 3. ContentProvider封裝了跨進(jìn)程共享的邏輯，我們只需要Uri即可訪(fǎng)問(wèn)數(shù)據(jù)。由系統(tǒng)來(lái)管理ContentProvider的創(chuàng)建、生命周期及訪(fǎng)問(wèn)的線(xiàn)程分配，簡(jiǎn)化我們?cè)趹?yīng)用間共享數(shù)據(jù)（進(jìn)程間通信）的方式。我們只管通過(guò)ContentResolver訪(fǎng)問(wèn)ContentProvider所提示的數(shù)據(jù)接口，而不需要擔(dān)心它所在進(jìn)程是啟動(dòng)還是未啟動(dòng)。

運(yùn)行在主線(xiàn)程的ContentProvider為什么不會(huì)影響主線(xiàn)程的UI操作?

• 1. ContentProvider的onCreate()是運(yùn)行在UI線(xiàn)程的，而query()，insert()，delete()，update()是運(yùn)行在線(xiàn)程池中的工作線(xiàn)程的，所以調(diào)用這向個(gè)方法并不會(huì)阻塞ContentProvider所在進(jìn)程的主線(xiàn)程，但可能會(huì)阻塞調(diào)用者所在的進(jìn)程的UI線(xiàn)程！
• 2. 所以，調(diào)用ContentProvider的操作仍然要放在子線(xiàn)程中去做。雖然直接的CRUD的操作是在工作線(xiàn)程的，但系統(tǒng)會(huì)讓你的調(diào)用線(xiàn)程等待這個(gè)異步的操作完成，你才可以繼續(xù)線(xiàn)程之前的工作。

請(qǐng)?jiān)敿?xì)敘述Android事件分發(fā)機(jī)制：

這道題是很多家面試公司會(huì)問(wèn)到的一道經(jīng)典面試題，但又經(jīng)常被面試者忽略。

看了很多博客也看了很多代碼，大部分都是長(zhǎng)篇大論，不利于閱讀固總結(jié)如下：

主線(xiàn)傳遞只有三步：Activity->ViewGroup->View

Activity和View只有兩個(gè)方法控制事件傳遞：dispatchTouchEvent()，onTouchEvent ();
ViewGroup有三個(gè)方法控制傳遞：dispatchTouchEvent()，onInterceptTouchEvent()，onTouchEvent ()；

接下來(lái)用一張圖給大家敘述下具體是怎么一步一步分發(fā)的。

ViewGroup和View 的dispatchTouchEvent 是做事件分發(fā)，那么這個(gè)事件可能分發(fā)出去的四個(gè)目標(biāo)
注：------> 后面代表事件目標(biāo)需要怎么做。
1、 自己消費(fèi)，終結(jié)傳遞。------->return true ；
2、 給自己的onTouchEvent處理-------> 調(diào)用super.dispatchTouchEvent()系統(tǒng)默認(rèn)會(huì)去調(diào)用 onInterceptTouchEvent，在onInterceptTouchEvent return true就會(huì)去把事件分給自己的onTouchEvent處理。
3、 傳給子View------>調(diào)用super.dispatchTouchEvent()默認(rèn)實(shí)現(xiàn)會(huì)去調(diào)用 onInterceptTouchEvent 在onInterceptTouchEvent return false，就會(huì)把事件傳給子類(lèi)。
4、 不傳給子View，事件終止往下傳遞，事件開(kāi)始回溯，從父View的onTouchEvent開(kāi)始事件從下到上回歸執(zhí)行每個(gè)控件的onTouchEvent------->return false；
注： 由于View沒(méi)有子View所以不需要onInterceptTouchEvent 來(lái)控件是否把事件傳遞給子View還是攔截，所以View的事件分發(fā)調(diào)用super.dispatchTouchEvent()的時(shí)候默認(rèn)把事件傳給自己的onTouchEvent處理（相當(dāng)于攔截），對(duì)比ViewGroup的dispatchTouchEvent 事件分發(fā)，View的事件分發(fā)只有dispatchTouchEvent()和onTouchEvent()不需要onInterceptTouchEvent()參與。

到此事件分發(fā)總結(jié)完畢。如果想詳細(xì)了解事件分發(fā)機(jī)制的請(qǐng)看這篇博客：
http://blog.csdn.net/w525721508/article/details/78227154

View的渲染過(guò)程，或者叫View的繪制流程

這道題也是比較老的一道題了，但是無(wú)論BAT還是小創(chuàng)業(yè)公司中出現(xiàn)的頻率相當(dāng)高
接下來(lái)就總結(jié)性的敘述一遍View繪制流程，避免長(zhǎng)篇大論，接下來(lái)的描述一切從簡(jiǎn)
希望各位讀者耐心看完，相信你會(huì)有很大的收獲！
View繪圖流程是在ViewRoot.java類(lèi)的performTraversals()函數(shù)中展開(kāi)的
繪制部分一共需要三步:

measure() -> layout() -> draw();

1. 判讀是否重新計(jì)算視圖大?。╩easure）

這里寫(xiě)圖片描述

原理：從頂層父View像子View遞歸調(diào)用view.measure(),measure方法中回調(diào)onMeasure()
MeasureSpec是View的測(cè)量?jī)?nèi)部類(lèi)，測(cè)量規(guī)格為int型，值由高2位規(guī)格模式specMode和低30位的具體尺寸specSize組成。

specMode有三種值：

MeasureSpec.UPSPECIFIED : 父容器對(duì)于子容器沒(méi)有任何限制,子容器想要多大就多大
MeasureSpec.EXACTLY: 父容器已經(jīng)為子容器設(shè)置了尺寸,子容器應(yīng)當(dāng)服從這些邊界,不論子容器想要多大的空間。
MeasureSpec.AT_MOST：子容器可以是聲明大小內(nèi)的任意大小

• View的measure方法是final，不可以重載，只能重載inMeasure完成自己的測(cè)量邏輯

• 頂層的DecorView的MeasureSpec是由ViewRootImpl中的getRootMeasureSpec方法確定（LayoutParams寬高參數(shù)均為MATCH_PARENT，specMode是EXACTLY，specSize為物理屏幕大?。?/p>

• ViewGroup類(lèi)提供了measureChild，measureChild和measureChildWithMargins方法，簡(jiǎn)化了父子View的尺寸計(jì)算。

• 只要是ViewGroup的子類(lèi)就必須要求LayoutParams繼承子MarginLayoutParams，否則無(wú)法使用layout_margin參數(shù)。

• View的布局大小由父View和子View共同決定。

• 使用View的getMeasuredWidth()和getMeasuredHeight()方法來(lái)獲取View測(cè)量的寬高，必須保證這兩個(gè)方法在onMeasure流程之后被調(diào)用才能返回有效值。

2. 是否重新分配視圖的位置（layout）

這里寫(xiě)圖片描述

原理： layout也是從頂層父View向子View的遞歸調(diào)用View.layout方法的過(guò)程,父View根據(jù)上一步measure子View得到的布局大小和布局參數(shù)，將子View放在合適的位置上。

• View.layout方法可以被重載，ViewGroup.layout為final不可以被重載，ViewGroup.onLayout為abstract的子類(lèi)必須重載實(shí)現(xiàn)自己的位置邏輯

• measure結(jié)束后得到的是每個(gè)View經(jīng)測(cè)量后的measuredWidth和measuredHeight，Layout操作完以后得到的是每個(gè)View進(jìn)行位置分配后的mLeft，mTop、mRight、mBottom，這些值都是相對(duì)父View

• 凡是layout_XXX的布局屬性都是針對(duì)父級(jí)View的，如果View沒(méi)有父級(jí)容器則layout_XXX屬性是沒(méi)有任何意義的

• 使用View 的getWidth()和getHright()方法獲取View測(cè)量的寬高必須保證這兩個(gè)方法在在onLayout流程之后。

3. 是否重新繪制（draw）

這里寫(xiě)圖片描述

原理： draw過(guò)程也是在ViewRootImpl的performTraversals()內(nèi)部調(diào)運(yùn)的，其調(diào)用順序在measure()和layout()之后，這里的mView對(duì)于A(yíng)ctiity來(lái)說(shuō)就是PhoneWindow.DecorView，ViewRootImpl中的代碼會(huì)創(chuàng)建一個(gè)Canvas對(duì)象，然后調(diào)用View的draw()方法來(lái)執(zhí)行具體的繪制工。所以又回歸到了ViewGroup與View的樹(shù)狀遞歸draw過(guò)程

• 如果該View是一個(gè)ViewGroup，則需要遞歸繪制其所包含的所有子View。

• View默認(rèn)不繪制任何內(nèi)容，真正的繪制都在自己的子類(lèi)中實(shí)現(xiàn)

• View的繪制是借助onDraw()方法傳入的Canvas類(lèi)來(lái)進(jìn)行的

• 區(qū)分View 動(dòng)畫(huà)和ViewGroup動(dòng)畫(huà)，前者是View自身的動(dòng)畫(huà)可以通過(guò)setAnimation添加，后者可以通過(guò)xml布局的layoutAnimation屬性添加

• 在獲取畫(huà)布剪切區(qū)（每個(gè)View的draw中傳入的Canvas）時(shí)會(huì)自動(dòng)處理掉padding，子View獲取Canvas不用關(guān)注這些邏輯，只關(guān)心如何繪制即可

• 默認(rèn)情況下子View的ViewGroup.drawChild繪制順序和子View被添加的順序一致，但是你也可以重載ViewGroup.getChildDrawingOrder()以提供不同的順序

4. invalidate()

原理： invalidate方法請(qǐng)求重繪View樹(shù)（也就是draw方法），如果View大小沒(méi)有發(fā)生變化就不會(huì)調(diào)用layout過(guò)程，并且只繪制那些“需要重繪的”View，也就是哪個(gè)View(View只繪制該View，ViewGroup繪制整個(gè)ViewGroup)請(qǐng)求invalidate系列方法，就繪制該View。

• 直接調(diào)用invalidate方法.請(qǐng)求重新draw，但只會(huì)繪制調(diào)用者本身。

• 觸發(fā)setSelection方法。請(qǐng)求重新draw，但只會(huì)繪制調(diào)用者本身。

• 觸發(fā)setVisibility方法。 當(dāng)View可視狀態(tài)在INVISIBLE轉(zhuǎn)換VISIBLE時(shí)會(huì)間接調(diào)用invalidate方法，繼而繪制該View。當(dāng)View的可視狀態(tài)在INVISIBLE\VISIBLE 轉(zhuǎn)換為GONE狀態(tài)時(shí)會(huì)間接調(diào)用requestLayout和invalidate方法，同時(shí)由于View樹(shù)大小發(fā)生了變化，所以會(huì)請(qǐng)求measure過(guò)程以及draw過(guò)程，同樣只繪制需要“重新繪制”的視圖。

• 觸發(fā)setEnabled方法。請(qǐng)求重新draw，但不會(huì)重新繪制任何View包括該調(diào)用者本身。

• 觸發(fā)requestFocus方法。請(qǐng)求View樹(shù)的draw過(guò)程，只繪制“需要重繪”的View。

例： 當(dāng)我們寫(xiě)一個(gè)Activity時(shí)，我們一定會(huì)通過(guò)setContentView方法將我們要展示的界面?zhèn)魅朐摲椒?，該方法?huì)講我們界面通過(guò)addView追加到id為content的一個(gè)FrameLayout（ViewGroup）中，然后addView方法中通過(guò)調(diào)運(yùn)invalidate(true)去通知觸發(fā)ViewRootImpl類(lèi)的performTraversals()方法，至此遞歸繪制我們自定義的所有布局。

5.requestLayout()

原理： View的requestLayout時(shí)其實(shí)質(zhì)就是層層向上傳遞，直到ViewRootImpl為止，然后觸發(fā)ViewRootImpl的requestLayout方法
requestLayout()方法會(huì)調(diào)用measure過(guò)程和layout過(guò)程，不會(huì)調(diào)用draw過(guò)程，也不會(huì)重新繪制任何View包括該調(diào)用者本身。

以上為View渲染的整體過(guò)程，如有問(wèn)題歡迎指正。