轉(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)求可以訪問(wèn)本類(lèi)中不帶synchronized(this)的代碼塊浦箱，也可以訪問(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線程去執(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線程中執(zhí)行的氮采，ContentProvider的onCreate()方法也是在UI線程中運(yùn)行的殷绍，回答這個(gè)問(wèn)題前，我們首先要搞清楚ContentProvider的Query()鹊漠，insert()主到，delete()，updata()這幾個(gè)方法是否也是在UI線程中運(yùn)行躯概。
• 發(fā)現(xiàn)問(wèn)題：
  如果以上幾個(gè)方法是在UI線程中運(yùn)行的登钥，那么多個(gè)線程并發(fā)去調(diào)用就很有可能出現(xiàn)ANR；如果不是在UI線程運(yùn)行的娶靡，那它是在一個(gè)工作線程中運(yùn)行的還是在多個(gè)線程中運(yùn)行的呢牧牢？即ContentProvider是否支持并發(fā)操作呢？
• 分析問(wèn)題：
  ContentResolver與ContentProvider類(lèi)隱藏了實(shí)現(xiàn)細(xì)節(jié)姿锭，但是ContentProvider所提供的Query()塔鳍，insert()，delete()呻此，updata()這幾個(gè)方法都是在ContentProvider進(jìn)行的線程池中運(yùn)行的轮纫，而不是在進(jìn)程的主線程中運(yùn)行，以為這些方法有可能被多個(gè)地方調(diào)用焚鲜，所以它們是線程安全的蜡感。
  ContentProvider實(shí)現(xiàn)進(jìn)程通信是依賴(lài)于Binder機(jī)制的，所以以上問(wèn)題會(huì)回歸到Binder線程處理問(wèn)題恃泪，并不是每一個(gè)ContentProvider都會(huì)有一個(gè)線程池，而是一個(gè)進(jìn)程共用一個(gè)線程池犀斋，共用的線程池就是Binder線程池贝乎。
• 標(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)程的線程池中被調(diào)用執(zhí)行的锤灿，而不是進(jìn)程的主線程中。這個(gè)線程池是有Binder創(chuàng)建和維護(hù)的辆脸，其實(shí)使用的就是每個(gè)應(yīng)用進(jìn)程中的Binder線程池但校。

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

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

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

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

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

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

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

主線傳遞只有三步：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ì)算視圖大刑耐鳌（measure）

這里寫(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為物理屏幕大小）碍讯。

• 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ì)于Actiity來(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)題歡迎指正录煤。