1赞厕，java
接口的意義：
規(guī)范艳狐，擴展，回調(diào)
規(guī)范：比如皿桑，有兩個及上的的類擁有相同的方法毫目，但是實現(xiàn)功能不一樣喷斋，就可以定義一個接口，將這個方法提煉出來蒜茴，在需要使用該方法的類中去實現(xiàn)，就免除了多個類定義系統(tǒng)方法的麻煩浆西。
擴展：可以實現(xiàn)多個接口
回調(diào)：可以把使用某一接口的類創(chuàng)建的對象的引用賦給該接口聲明的接口變量粉私，那么該接口變量就可以調(diào)用被類實現(xiàn)的接口的方法。實際上近零，當(dāng)接口變量調(diào)用被類實現(xiàn)的接口中的方法時诺核，就是通知相應(yīng)的對象調(diào)用接口的方法，這一過程稱為對象功能的接口回調(diào)
抽象類的意義-樂視
為其子類提供一個公共的類型 封裝子類中得重復(fù)內(nèi)容 定義抽象方法久信，子類雖然有不同的實現(xiàn) 但是定義是一致的
內(nèi)部類的作用-樂視
內(nèi)部類可以用多個實例窖杀，每個實例都有自己的狀態(tài)信息，并且與其他外圍對象的信息相互獨立裙士。
在單個外圍類中入客，可以讓多個內(nèi)部類以不同的方式實現(xiàn)同一個接口，或者繼承同一個類腿椎。
創(chuàng)建內(nèi)部類對象的時刻并不依賴于外圍類對象的創(chuàng)建桌硫。
內(nèi)部類并沒有令人迷惑的“is-a”關(guān)系，他就是一個獨立的實體啃炸。
內(nèi)部類提供了更好的封裝铆隘，除了該外圍類，其他類都不能訪問
不能
子類繼承父類后南用，用相同的靜態(tài)方法和非靜態(tài)方法膀钠，這時非靜態(tài)方法覆蓋父類中的方法（即方法重寫），父類的該靜態(tài)方法被隱藏（如果對象是父類則調(diào)用該隱藏的方法）裹虫，另外子類可繼承父類的靜態(tài)與非靜態(tài)方法肿嘲，至于方法重載我覺得它其中一要素就是在同一類中，不能說父類中的什么方法與子類里的什么方法是方法重載的體現(xiàn)
http://blog.csdn.net/qy1387/article/details/7752973
Java語言的一個非常重要的特點就是與平臺的無關(guān)性恒界。而使用Java虛擬機是實現(xiàn)這一特點的關(guān)鍵睦刃。一般的高級語言如果要在不同的平臺上運行，至少需要編譯成不同的目標代碼十酣。而引入Java語言虛擬機后涩拙，Java語言在不同平臺上運行時不需要重新編譯。Java語言使用模式Java虛擬機屏蔽了與具體平臺相關(guān)的信息耸采，使得Java語言編譯程序只需生成在Java虛擬機上運行的目標代碼（字節(jié)碼）兴泥，就可以在多種平臺上不加修改地運行。Java虛擬機在執(zhí)行字節(jié)碼時虾宇，把字節(jié)碼解釋成具體平臺上的機器指令執(zhí)行搓彻。
Java 垃圾回收機制最基本的做法是分代回收。內(nèi)存中的區(qū)域被劃分成不同的世代，對象根據(jù)其存活的時間被保存在對應(yīng)世代的區(qū)域中旭贬。一般的實現(xiàn)是劃分成3個世代：年輕怔接、年老和永久。內(nèi)存的分配是發(fā)生在年輕世代中的稀轨。當(dāng)一個對象存活時間足夠長的時候扼脐，它就會被復(fù)制到年老世代中。對于不同的世代可以使用不同的垃圾回收算法奋刽。進行世代劃分的出發(fā)點是對應(yīng)用中對象存活時間進行研究之后得出的統(tǒng)計規(guī)律瓦侮。一般來說，一個應(yīng)用中的大部分對象的存活時間都很短佣谐。比如局部變量的存活時間就只在方法的執(zhí)行過程中肚吏。基于這一點狭魂，對于年輕世代的垃圾回收算法就可以很有針對性罚攀。
簡而言之,一個程序至少有一個進程,一個進程至少有一個線程。
線程的劃分尺度小于進程趁蕊，使得多線程程序的并發(fā)性高坞生。
另外，進程在執(zhí)行過程中擁有獨立的內(nèi)存單元掷伙，而多個線程共享內(nèi)存是己，從而極大地提高了程序的運行效率。
線程在執(zhí)行過程中與進程還是有區(qū)別的任柜。每個獨立的線程有一個程序運行的入口卒废、順序執(zhí)行序列和程序的出口。但是線程不能夠獨立執(zhí)行宙地，必須依存在應(yīng)用程序中摔认，由應(yīng)用程序提供多個線程執(zhí)行控制回论。
從邏輯角度來看派哲，多線程的意義在于一個應(yīng)用程序中，有多個執(zhí)行部分可以同時執(zhí)行浑彰。但操作系統(tǒng)并沒有將多個線程看做多個獨立的應(yīng)用秽梅，來實現(xiàn)進程的調(diào)度和管理以及資源分配抹蚀。這就是進程和線程的重要區(qū)別。
進程是具有一定獨立功能的程序關(guān)于某個數(shù)據(jù)集合上的一次運行活動,進程是系統(tǒng)進行資源分配和調(diào)度的一個獨立單位.
線程是進程的一個實體,是CPU調(diào)度和分派的基本單位,它是比進程更小的能獨立運行的基本單位.線程自己基本上不擁有系統(tǒng)資源,只擁有一點在運行中必不可少的資源(如程序計數(shù)器,一組寄存器和棧),但是它可與同屬一個進程的其他的線程共享進程所擁有的全部資源.
一個線程可以創(chuàng)建和撤銷另一個線程;同一個進程中的多個線程之間可以并發(fā)執(zhí)行.
進程和線程的主要差別在于它們是不同的操作系統(tǒng)資源管理方式企垦。進程有獨立的地址空間环壤，一個進程崩潰后，在保護模式下不會對其它進程產(chǎn)生影響钞诡，而線程只是一個進程中的不同執(zhí)行路徑郑现。線程有自己的堆棧和局部變量湃崩，但線程之間沒有單獨的地址空間，一個線程死掉就等于整個進程死掉接箫，所以多進程的程序要比多線程的程序健壯攒读，但在進程切換時，耗費資源較大辛友，效率要差一些整陌。但對于一些要求同時進行并且又要共享某些變量的并發(fā)操作，只能用線程瞎领，不能用進程。如果有興趣深入的話随夸，我建議你們看看《現(xiàn)代操作系統(tǒng)》或者《操作系統(tǒng)的設(shè)計與實現(xiàn)》九默。對就個問題說得比較清楚。
java中==和equals和hashCode的區(qū)別-樂視
http://blog.csdn.net/tiantiandjava/article/details/46988461
HashMap概述： ???HashMap是基于哈希表的Map接口的非同步實現(xiàn)宾毒。此實現(xiàn)提供所有可選的映射操作驼修，并允許使用null值和null鍵。此類不保證映射的順序诈铛，特別是它不保證該順序恒久不變乙各。
HashMap的數(shù)據(jù)結(jié)構(gòu)： 在java編程語言中，最基本的結(jié)構(gòu)就是兩種幢竹，一個是數(shù)組耳峦，另外一個是模擬指針（引用），所有的數(shù)據(jù)結(jié)構(gòu)都可以用這兩個基本結(jié)構(gòu)來構(gòu)造的焕毫，HashMap也不例外蹲坷。HashMap實際上是一個“鏈表散列”的數(shù)據(jù)結(jié)構(gòu)，即數(shù)組和鏈表的結(jié)合體邑飒。
從上圖中可以看出循签，HashMap底層就是一個數(shù)組結(jié)構(gòu)，數(shù)組中的每一項又是一個鏈表疙咸。當(dāng)新建一個HashMap的時候县匠，就會初始化一個數(shù)組。
http://www.jdon.com/designpatterns/designpattern_State.htm
int-char-long各占多少字節(jié)數(shù)
byte 位數(shù) 8 字節(jié)數(shù) 1
short 16 2
int 32 4
long 64 8
float 32 4
double 64 8
char 16 2
http://www.cnblogs.com/shenliang123/archive/2011/10/27/2226903.html
string-stringbuffer-stringbuilder區(qū)別-小米-樂視-百度
String 字符串常量
StringBuffer 字符串變量（線程安全）
StringBuilder 字符串變量（非線程安全）
簡要的說撒轮， String 類型和 StringBuffer 類型的主要性能區(qū)別其實在于 String 是不可變的對象, 因此在每次對 String 類型進行改變的時候其實都等同于生成了一個新的 String 對象乞旦，然后將指針指向新的 String 對象，所以經(jīng)常改變內(nèi)容的字符串最好不要用String 腔召，因為每次生成對象都會對系統(tǒng)性能產(chǎn)生影響杆查，特別當(dāng)內(nèi)存中無引用對象多了以后,JVM 的 GC 就會開始工作，那速度是一定會相當(dāng)慢的臀蛛。
而如果是使用 StringBuffer 類則結(jié)果就不一樣了亲桦，每次結(jié)果都會對 StringBuffer 對象本身進行操作崖蜜，而不是生成新的對象，再改變對象引用客峭。所以在一般情況下我們推薦使用 StringBuffer 豫领，特別是字符串對象經(jīng)常改變的情況下。而在某些特別情況下舔琅， String 對象的字符串拼接其實是被 JVM 解釋成了 StringBuffer 對象的拼接等恐，所以這些時候 String 對象的速度并不會比 StringBuffer 對象慢，而特別是以下的字符串對象生成中备蚓， String 效率是遠要比 StringBuffer 快的：
String S1 = “This is only a” + “ simple” + “ test”;
StringBuffer Sb = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”); 你會很驚訝的發(fā)現(xiàn)课蔬，生成 String S1 對象的速度簡直太快了，而這個時候 StringBuffer 居然速度上根本一點都不占優(yōu)勢郊尝。其實這是 JVM 的一個把戲二跋，在 JVM 眼里，這個 ?String S1 = “This is only a” + “ simple” + “test”; 其實就是： ?String S1 = “This is only a simple test”; 所以當(dāng)然不需要太多的時間了流昏。但大家這里要注意的是扎即，如果你的字符串是來自另外的 String 對象的話，速度就沒那么快了况凉，譬如： ?String S2 = “This is only a”; String S3 = “ simple”; String S4 = “ test”; String S1 = S2 +S3 + S4; 這時候 JVM 會規(guī)規(guī)矩矩的按照原來的方式去做
在大部分情況下 StringBuffer > String
StringBuffer
Java.lang.StringBuffer線程安全的可變字符序列谚鄙。一個類似于 String 的字符串緩沖區(qū)，但不能修改刁绒。雖然在任意時間點上它都包含某種特定的字符序列闷营，但通過某些方法調(diào)用可以改變該序列的長度和內(nèi)容。
可將字符串緩沖區(qū)安全地用于多個線程知市×肝耄可以在必要時對這些方法進行同步，因此任意特定實例上的所有操作就好像是以串行順序發(fā)生的初狰，該順序與所涉及的每個線程進行的方法調(diào)用順序一致莫杈。
StringBuffer 上的主要操作是 append 和 insert 方法，可重載這些方法奢入，以接受任意類型的數(shù)據(jù)筝闹。每個方法都能有效地將給定的數(shù)據(jù)轉(zhuǎn)換成字符串，然后將該字符串的字符追加或插入到字符串緩沖區(qū)中腥光。append 方法始終將這些字符添加到緩沖區(qū)的末端关顷；而 insert 方法則在指定的點添加字符。
例如武福，如果 z 引用一個當(dāng)前內(nèi)容是“start”的字符串緩沖區(qū)對象议双，則此方法調(diào)用 z.append("le") 會使字符串緩沖區(qū)包含“startle”，而 z.insert(4, "le") 將更改字符串緩沖區(qū)捉片，使之包含“starlet”平痰。
在大部分情況下 StringBuilder > StringBuffer
java.lang.StringBuilder
java.lang.StringBuilder一個可變的字符序列是5.0新增的汞舱。此類提供一個與 StringBuffer 兼容的 API，但不保證同步宗雇。該類被設(shè)計用作 StringBuffer 的一個簡易替換昂芜，用在字符串緩沖區(qū)被單個線程使用的時候（這種情況很普遍）。如果可能赔蒲，建議優(yōu)先采用該類泌神，因為在大多數(shù)實現(xiàn)中，它比 StringBuffer 要快舞虱。兩者的方法基本相同
Java多態(tài)性理解
Java中多態(tài)性的實現(xiàn)
什么是多態(tài)
面向?qū)ο蟮娜筇匦裕悍庋b欢际、繼承、多態(tài)矾兜。從一定角度來看幼苛，封裝和繼承幾乎都是為多態(tài)而準備的。這是我們最后一個概念焕刮，也是最重要的知識點。
多態(tài)的定義：指允許不同類的對象對同一消息做出響應(yīng)墙杯。即同一消息可以根據(jù)發(fā)送對象的不同而采用多種不同的行為方式配并。（發(fā)送消息就是函數(shù)調(diào)用）
實現(xiàn)多態(tài)的技術(shù)稱為：動態(tài)綁定（dynamic binding），是指在執(zhí)行期間判斷所引用對象的實 際類型高镐，根據(jù)其實際的類型調(diào)用其相應(yīng)的方法溉旋。
多態(tài)的作用：消除類型之間的耦合關(guān)系。
現(xiàn)實中嫉髓，關(guān)于多態(tài)的例子不勝枚舉观腊。比方說按下 F1 鍵這個動作，如果當(dāng)前在 Flash 界面下彈出的就是 AS 3 的幫助文檔算行；如果當(dāng)前在 Word 下彈出的就是 Word 幫助梧油；在 Windows 下彈出的就是 Windows 幫助和支持。同一個事件發(fā)生在不同的對象上會產(chǎn)生不同的結(jié)果州邢。 下面是多態(tài)存在的三個必要條件儡陨，要求大家做夢時都能背出來！
多態(tài)存在的三個必要條件 一量淌、要有繼承骗村； 二、要有重寫呀枢； 三胚股、父類引用指向子類對象。
多態(tài)的好處：
1.可替換性（substitutability）裙秋。多態(tài)對已存在代碼具有可替換性琅拌。例如缨伊，多態(tài)對圓Circle類工作，對其他任何圓形幾何體财忽，如圓環(huán)倘核，也同樣工作。
2.可擴充性（extensibility）即彪。多態(tài)對代碼具有可擴充性紧唱。增加新的子類不影響已存在類的多態(tài)性、繼承性隶校，以及其他特性的運行和操作漏益。實際上新加子類更容易獲得多態(tài)功能。例如深胳，在實現(xiàn)了圓錐绰疤、半圓錐以及半球體的多態(tài)基礎(chǔ)上，很容易增添球體類的多態(tài)性舞终。
3.接口性（interface-ability）轻庆。多態(tài)是超類通過方法簽名，向子類提供了一個共同接口敛劝，由子類來完善或者覆蓋它而實現(xiàn)的余爆。如圖8.3 所示。圖中超類Shape規(guī)定了兩個實現(xiàn)多態(tài)的接口方法夸盟，computeArea()以及computeVolume()蛾方。子類，如Circle和Sphere為了實現(xiàn)多態(tài)上陕，完善或者覆蓋這兩個接口方法桩砰。
4.靈活性（flexibility）。它在應(yīng)用中體現(xiàn)了靈活多樣的操作释簿，提高了使用效率亚隅。
5.簡化性（simplicity）。多態(tài)簡化對應(yīng)用軟件的代碼編寫和修改過程庶溶，尤其在處理大量對象的運算和操作時枢步，這個特點尤為突出和重要。
Java中多態(tài)的實現(xiàn)方式：接口實現(xiàn)渐尿，繼承父類進行方法重寫醉途，同一個類中進行方法重載。
線程的阻塞
為了解決對共享存儲區(qū)的訪問沖突砖茸，Java 引入了同步機制隘擎，現(xiàn)在讓我們來考察多個線程對共享資源的訪問，顯然同步機制已經(jīng)不夠了凉夯，因為在任意時刻所要求的資源不一定已經(jīng)準備好了被訪問货葬，反過來采幌，同一時刻準備好了的資源也可能不止一個。為了解決這種情況下的訪問控制問題震桶，Java 引入了對阻塞機制的支持.
阻塞指的是暫停一個線程的執(zhí)行以等待某個條件發(fā)生（如某資源就緒）休傍，學(xué)過操作系統(tǒng)的同學(xué)對它一定已經(jīng)很熟悉了。Java 提供了大量方法來支持阻塞蹲姐，下面讓我們逐一分析磨取。
sleep() 方法：sleep() 允許 指定以毫秒為單位的一段時間作為參數(shù)，它使得線程在指定的時間內(nèi)進入阻塞狀態(tài)柴墩，不能得到CPU 時間忙厌，指定的時間一過，線程重新進入可執(zhí)行狀態(tài)江咳。 典型地逢净，sleep() 被用在等待某個資源就緒的情形：測試發(fā)現(xiàn)條件不滿足后，讓線程阻塞一段時間后重新測試歼指，直到條件滿足為止爹土。
suspend() 和 resume() 方法：兩個方法配套使用，suspend()使得線程進入阻塞狀態(tài)踩身，并且不會自動恢復(fù)胀茵，必須其對應(yīng)的resume() 被調(diào)用，才能使得線程重新進入可執(zhí)行狀態(tài)惰赋。典型地，suspend() 和 resume() 被用在等待另一個線程產(chǎn)生的結(jié)果的情形：測試發(fā)現(xiàn)結(jié)果還沒有產(chǎn)生后呵哨，讓線程阻塞赁濒，另一個線程產(chǎn)生了結(jié)果后，調(diào)用 resume() 使其恢復(fù)孟害。
yield() 方法：yield() 使得線程放棄當(dāng)前分得的 CPU 時間拒炎，但是不使線程阻塞，即線程仍處于可執(zhí)行狀態(tài)挨务，隨時可能再次分得 CPU 時間击你。調(diào)用 yield() 的效果等價于調(diào)度程序認為該線程已執(zhí)行了足夠的時間從而轉(zhuǎn)到另一個線程.
wait() 和 notify() 方法：兩個方法配套使用，wait() 使得線程進入阻塞狀態(tài)谎柄，它有兩種形式丁侄，一種允許 指定以毫秒為單位的一段時間作為參數(shù)，另一種沒有參數(shù)朝巫，前者當(dāng)對應(yīng)的 notify() 被調(diào)用或者超出指定時間時線程重新進入可執(zhí)行狀態(tài)鸿摇，后者則必須對應(yīng)的 notify() 被調(diào)用.
初看起來它們與 suspend() 和 resume() 方法對沒有什么分別，但是事實上它們是截然不同的劈猿。區(qū)別的核心在于拙吉，前面敘述的所有方法潮孽，阻塞時都不會釋放占用的鎖（如果占用了的話），而這一對方法則相反筷黔。
上述的核心區(qū)別導(dǎo)致了一系列的細節(jié)上的區(qū)別往史。
首先，前面敘述的所有方法都隸屬于 Thread 類佛舱，但是這一對卻直接隸屬于 Object 類椎例，也就是說，所有對象都擁有這一對方法名眉。初看起來這十分不可思議粟矿，但是實際上卻是很自然的，因為這一對方法阻塞時要釋放占用的鎖损拢，而鎖是任何對象都具有的陌粹，調(diào)用任意對象的 wait() 方法導(dǎo)致線程阻塞，并且該對象上的鎖被釋放福压。而調(diào)用 任意對象的notify()方法則導(dǎo)致因調(diào)用該對象的 wait() 方法而阻塞的線程中隨機選擇的一個解除阻塞（但要等到獲得鎖后才真正可執(zhí)行）掏秩。
其次，前面敘述的所有方法都可在任何位置調(diào)用荆姆，但是這一對方法卻必須在 synchronized 方法或塊中調(diào)用蒙幻，理由也很簡單，只有在synchronized 方法或塊中當(dāng)前線程才占有鎖胆筒，才有鎖可以釋放邮破。同樣的道理，調(diào)用這一對方法的對象上的鎖必須為當(dāng)前線程所擁有仆救，這樣才有鎖可以釋放抒和。因此，這一對方法調(diào)用必須放置在這樣的 synchronized 方法或塊中彤蔽，該方法或塊的上鎖對象就是調(diào)用這一對方法的對象摧莽。若不滿足這一條件，則程序雖然仍能編譯顿痪，但在運行時會出現(xiàn)IllegalMonitorStateException 異常镊辕。
wait() 和 notify() 方法的上述特性決定了它們經(jīng)常和synchronized 方法或塊一起使用，將它們和操作系統(tǒng)的進程間通信機制作一個比較就會發(fā)現(xiàn)它們的相似性：synchronized方法或塊提供了類似于操作系統(tǒng)原語的功能蚁袭，它們的執(zhí)行不會受到多線程機制的干擾征懈，而這一對方法則相當(dāng)于 block 和wakeup 原語（這一對方法均聲明為 synchronized）。它們的結(jié)合使得我們可以實現(xiàn)操作系統(tǒng)上一系列精妙的進程間通信的算法（如信號量算法）揩悄，并用于解決各種復(fù)雜的線程間通信問題受裹。
關(guān)于 wait() 和 notify() 方法最后再說明兩點：
第一：調(diào)用 notify() 方法導(dǎo)致解除阻塞的線程是從因調(diào)用該對象的 wait() 方法而阻塞的線程中隨機選取的，我們無法預(yù)料哪一個線程將會被選擇，所以編程時要特別小心棉饶，避免因這種不確定性而產(chǎn)生問題厦章。
第二：除了 notify()，還有一個方法 notifyAll() 也可起到類似作用照藻，唯一的區(qū)別在于袜啃，調(diào)用 notifyAll() 方法將把因調(diào)用該對象的 wait() 方法而阻塞的所有線程一次性全部解除阻塞。當(dāng)然幸缕，只有獲得鎖的那一個線程才能進入可執(zhí)行狀態(tài)群发。
談到阻塞，就不能不談一談死鎖发乔，略一分析就能發(fā)現(xiàn)熟妓，suspend() 方法和不指定超時期限的 wait() 方法的調(diào)用都可能產(chǎn)生死鎖。遺憾的是栏尚，Java 并不在語言級別上支持死鎖的避免起愈，我們在編程中必須小心地避免死鎖。
以上我們對 Java 中實現(xiàn)線程阻塞的各種方法作了一番分析译仗，我們重點分析了 wait() 和 notify() 方法抬虽，因為它們的功能最強大，使用也最靈活纵菌，但是這也導(dǎo)致了它們的效率較低阐污，較容易出錯。實際使用中我們應(yīng)該靈活使用各種方法咱圆，以便更好地達到我們的目的笛辟。
默認的方法實現(xiàn) 抽象類可以有默認的方法實現(xiàn)完全是抽象的。接口根本不存在方法的實現(xiàn)
實現(xiàn) 子類使用extends關(guān)鍵字來繼承抽象類序苏。如果子類不是抽象類的話手幢，它需要提供抽象類中所有聲明的方法的實現(xiàn)。
子類使用關(guān)鍵字implements來實現(xiàn)接口杠览。它需要提供接口中所有聲明的方法的實現(xiàn)
構(gòu)造器
抽象類可以有構(gòu)造器 接口不能有構(gòu)造器
與正常Java類的區(qū)別
除了你不能實例化抽象類之外弯菊，它和普通Java類沒有任何區(qū) 接口是完全不同的類型
訪問修飾符
抽象方法可以有public纵势、protected和default這些修飾符 接口方法默認修飾符是public踱阿。你不可以使用其它修飾符。
main方法
抽象方法可以有main方法并且我們可以運行它
接口沒有main方法钦铁，因此我們不能運行它软舌。
多繼承
抽象類在java語言中所表示的是一種繼承關(guān)系，一個子類只能存在一個父類牛曹，但是可以存在多個接口佛点。
速度
它比接口速度要快
接口是稍微有點慢的，因為它需要時間去尋找在類中實現(xiàn)的方法。
添加新方法
如果你往抽象類中添加新的方法超营，你可以給它提供默認的實現(xiàn)鸳玩。因此你不需要改變你現(xiàn)在的代碼。
如果你往接口中添加方法演闭，那么你必須改變實現(xiàn)該接口的類不跟。
http://www.cnblogs.com/yuanermen/archive/2009/08/05/1539917.htmlhttp://alexyyek.github.io/2015/04/06/Collection/http://tianmaying.com/tutorial/java_collection
http://www.cnblogs.com/chenssy/p/3388487.html
hashmap和hashtable的區(qū)別-樂視-小米
http://www.233.com/ncre2/JAVA/jichu/20100717/084230917.html
2.Android
把原數(shù)據(jù)庫包括在項目源碼的 res/raw
android系統(tǒng)下數(shù)據(jù)庫應(yīng)該存放在 /data/data/com..（package name）/ 目錄下，所以我們需要做的是把已有的數(shù)據(jù)庫傳入那個目錄下.操作方法是用FileInputStream讀取原數(shù)據(jù)庫米碰，再用FileOutputStream把讀取到的東西寫入到那個目錄.
因廣播數(shù)據(jù)在本應(yīng)用范圍內(nèi)傳播窝革，不用擔(dān)心隱私數(shù)據(jù)泄露的問題。 不用擔(dān)心別的應(yīng)用偽造廣播吕座，造成安全隱患虐译。 相比在系統(tǒng)內(nèi)發(fā)送全局廣播，它更高效吴趴。
intentService作用是什么,AIDL解決了什么問題-小米
生成一個默認的且與主線程互相獨立的工作者線程來執(zhí)行所有傳送至onStartCommand() 方法的Intetnt漆诽。
生成一個工作隊列來傳送Intent對象給你的onHandleIntent()方法，同一時刻只傳送一個Intent對象史侣，這樣一來拴泌，你就不必擔(dān)心多線程的問題。在所有的請求(Intent)都被執(zhí)行完以后會自動停止服務(wù)惊橱，所以蚪腐，你不需要自己去調(diào)用stopSelf()方法來停止。
該服務(wù)提供了一個onBind()方法的默認實現(xiàn)税朴，它返回null
提供了一個onStartCommand()方法的默認實現(xiàn)回季，它將Intent先傳送至工作隊列，然后從工作隊列中每次取出一個傳送至onHandleIntent()方法正林，在該方法中對Intent對相應(yīng)的處理泡一。
AIDL (Android Interface Definition Language) 是一種IDL 語言，用于生成可以在Android設(shè)備上兩個進程之間進行進程間通信(interprocess communication, IPC)的代碼觅廓。如果在一個進程中（例如Activity）要調(diào)用另一個進程中（例如Service）對象的操作鼻忠，就可以使用AIDL生成可序列化的參數(shù)。 AIDL IPC機制是面向接口的杈绸，像COM或Corba一樣帖蔓，但是更加輕量級。它是使用代理類在客戶端和實現(xiàn)端傳遞數(shù)據(jù)瞳脓。
Activity/Window/View三者的差別,fragment的特點-360
Activity像一個工匠（控制單元）塑娇，Window像窗戶（承載模型），View像窗花（顯示視圖） LayoutInflater像剪刀劫侧，Xml配置像窗花圖紙埋酬。
在Activity中調(diào)用attach哨啃，創(chuàng)建了一個Window
創(chuàng)建的window是其子類PhoneWindow，在attach中創(chuàng)建PhoneWindow
在Activity中調(diào)用setContentView(R.layout.xxx)
其中實際上是調(diào)用的getWindow().setContentView()
調(diào)用PhoneWindow中的setContentView方法
創(chuàng)建ParentView：作為ViewGroup的子類写妥，實際是創(chuàng)建的DecorView(作為FramLayout的子類）
將指定的R.layout.xxx進行填充通過布局填充器進行填充【其中的parent指的就是DecorView】
調(diào)用到ViewGroup
調(diào)用ViewGroup的removeAllView()拳球，先將所有的view移除掉
添加新的view：addView()
fragment 特點
Fragment可以作為Activity界面的一部分組成出現(xiàn)；
可以在一個Activity中同時出現(xiàn)多個Fragment珍特，并且一個Fragment也可以在多個Activity中使用醇坝；
在Activity運行過程中，可以添加次坡、移除或者替換Fragment呼猪；
Fragment可以響應(yīng)自己的輸入事件，并且有自己的生命周期砸琅，它們的生命周期會受宿主Activity的生命周期影響宋距。
Handler,Thread和HandlerThread的差別-小米
http://blog.csdn.net/guolin_blog/article/details/9991569
http://droidyue.com/blog/2015/11/08/make-use-of-handlerthread/
從Android中Thread（java.lang.Thread -> java.lang.Object）描述可以看出，Android的Thread沒有對Java的Thread做任何封裝症脂，但是Android提供了一個繼承自Thread的類HandlerThread（android.os.HandlerThread -> java.lang.Thread）谚赎，這個類對Java的Thread做了很多便利Android系統(tǒng)的封裝。
android.os.Handler可以通過Looper對象實例化诱篷，并運行于另外的線程中壶唤，Android提供了讓Handler運行于其它線程的線程實現(xiàn)，也是就HandlerThread棕所。HandlerThread對象start后可以獲得其Looper對象闸盔，并且使用這個Looper對象實例Handler。
自己實現(xiàn)或@TargetApi?annotation
進入源碼根目錄
. build/envsetup.sh
lunch
full(編譯全部)
userdebug(選擇編譯版本)
make -j8(開啟8個線程編譯)
standard琳省，創(chuàng)建一個新的Activity迎吵。
singleTop，棧頂不是該類型的Activity针贬，創(chuàng)建一個新的Activity击费。否則，onNewIntent桦他。
singleTask蔫巩，回退棧中沒有該類型的Activity，創(chuàng)建Activity快压，否則圆仔，onNewIntent+ClearTop。
注意:
設(shè)置了"singleTask"啟動模式的Activity嗓节，它在啟動的時候荧缘，會先在系統(tǒng)中查找屬性值affinity等于它的屬性值taskAffinity的Task存在皆警； 如果存在這樣的Task拦宣，它就會在這個Task中啟動，否則就會在新的任務(wù)棧中啟動。因此鸵隧， 如果我們想要設(shè)置了"singleTask"啟動模式的Activity在新的任務(wù)中啟動绸罗，就要為它設(shè)置一個獨立的taskAffinity屬性值。
如果設(shè)置了"singleTask"啟動模式的Activity不是在新的任務(wù)中啟動時豆瘫，它會在已有的任務(wù)中查看是否已經(jīng)存在相應(yīng)的Activity實例珊蟀， 如果存在，就會把位于這個Activity實例上面的Activity全部結(jié)束掉外驱，即最終這個Activity 實例會位于任務(wù)的Stack頂端中育灸。
在一個任務(wù)棧中只有一個”singleTask”啟動模式的Activity存在。他的上面可以有其他的Activity昵宇。這點與singleInstance是有區(qū)別的华蜒。
singleInstance苇本，回退棧中，只有這一個Activity，沒有其他Activity涡匀。
singleTop適合接收通知啟動的內(nèi)容顯示頁面。
例如属愤，某個新聞客戶端的新聞內(nèi)容頁面揍诽，如果收到10個新聞推送，每次都打開一個新聞內(nèi)容頁面是很煩人的犯助。
singleTask適合作為程序入口點癣漆。
例如瀏覽器的主界面。不管從多少個應(yīng)用啟動瀏覽器剂买，只會啟動主界面一次扑媚，其余情況都會走onNewIntent，并且會清空主界面上面的其他頁面雷恃。
singleInstance應(yīng)用場景：
鬧鈴的響鈴界面疆股。 你以前設(shè)置了一個鬧鈴：上午6點。在上午5點58分倒槐，你啟動了鬧鈴設(shè)置界面旬痹，并按 Home 鍵回桌面；在上午5點59分時讨越，你在微信和朋友聊天两残；在6點時，鬧鈴響了把跨，并且彈出了一個對話框形式的 Activity(名為 AlarmAlertActivity) 提示你到6點了(這個 Activity 就是以 SingleInstance 加載模式打開的)人弓，你按返回鍵，回到的是微信的聊天界面着逐，這是因為 AlarmAlertActivity 所在的 Task 的棧只有他一個元素崔赌， 因此退出之后這個 Task 的椧庵空了。如果是以 SingleTask 打開 AlarmAlertActivity健芭，那么當(dāng)鬧鈴響了的時候县钥，按返回鍵應(yīng)該進入鬧鈴設(shè)置界面。
http://www.codekk.com/blogs/detail/54cfab086c4761e5001b253f
Activity.runOnUiThread(Runnable)
View.post(Runnable),View.postDelay(Runnable,long)
Handler
AsyncTask
http://www.juwends.com/tech/android/android-inter-thread-comm.html
單例
publicclassSingleton{privatevolatilestaticSingletonmSingleton;privateSingleton(){}publicstaticSingletongetInstance(){if(mSingleton==null){\\Asynchronized(Singleton.class){\\Cif(mSingleton==null)? ? ? mSingleton=newSingleton();\\B}? ? }returnmSingleton;? }}
1.資源對象沒關(guān)閉造成的內(nèi)存泄漏
描述： 資源性對象比如(Cursor慈迈，F(xiàn)ile文件等)往往都用了一些緩沖若贮，我們在不使用的時候，應(yīng)該及時關(guān)閉它們痒留，以便它們的緩沖及時回收內(nèi)存谴麦。它們的緩沖不僅存在于 java虛擬機內(nèi)，還存在于java虛擬機外伸头。如果我們僅僅是把它的引用設(shè)置為null,而不關(guān)閉它們细移，往往會造成內(nèi)存泄漏。因為有些資源性對象熊锭，比如 SQLiteCursor(在析構(gòu)函數(shù)finalize(),如果我們沒有關(guān)閉它弧轧，它自己會調(diào)close()關(guān)閉)，如果我們沒有關(guān)閉它碗殷，系統(tǒng)在回收它時也會關(guān)閉它精绎，但是這樣的效率太低了。因此對于資源性對象在不使用的時候锌妻，應(yīng)該調(diào)用它的close()函數(shù)代乃，將其關(guān)閉掉，然后才置為null.在我們的程序退出時一定要確保我們的資源性對象已經(jīng)關(guān)閉仿粹。 程序中經(jīng)常會進行查詢數(shù)據(jù)庫的操作搁吓，但是經(jīng)常會有使用完畢Cursor后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小吭历，對內(nèi)存的消耗不容易被發(fā)現(xiàn)堕仔，只有在常時間大量操作的情況下才會復(fù)現(xiàn)內(nèi)存問題，這樣就會給以后的測試和問題排查帶來困難和風(fēng)險晌区。
2.構(gòu)造Adapter時摩骨，沒有使用緩存的convertView
描述： 以構(gòu)造ListView的BaseAdapter為例，在BaseAdapter中提供了方法： public View getView(int position, ViewconvertView, ViewGroup parent) 來向ListView提供每一個item所需要的view對象朗若。初始時ListView會從BaseAdapter中根據(jù)當(dāng)前的屏幕布局實例化一定數(shù)量的 view對象恼五，同時ListView會將這些view對象緩存起來。當(dāng)向上滾動ListView時哭懈，原先位于最上面的list item的view對象會被回收灾馒，然后被用來構(gòu)造新出現(xiàn)的最下面的list item。這個構(gòu)造過程就是由getView()方法完成的遣总，getView()的第二個形參View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)睬罗。由此可以看出轨功，如果我們不去使用 convertView，而是每次都在getView()中重新實例化一個View對象的話傅物，即浪費資源也浪費時間，也會使得內(nèi)存占用越來越大琉预。 ListView回收list item的view對象的過程可以查看: android.widget.AbsListView.java --> voidaddScrapView(View scrap) 方法董饰。 示例代碼：
public?View?getView(int?position,?ViewconvertView,?ViewGroup?parent)?{
View?view?=?new?Xxx(...);
...?...
return?view;
}
修正示例代碼：
public?View?getView(int?position,?ViewconvertView,?ViewGroup?parent)?{
View?view?=?null;
if?(convertView?!=?null)?{
view?=?convertView;
populate(view,?getItem(position));
...
}?else?{
view?=?new?Xxx(...);
...
}
return?view;
}
3.Bitmap對象不在使用時調(diào)用recycle()釋放內(nèi)存
描述： 有時我們會手工的操作Bitmap對象，如果一個Bitmap對象比較占內(nèi)存圆米，當(dāng)它不在被使用的時候卒暂，可以調(diào)用Bitmap.recycle()方法回收此對象的像素所占用的內(nèi)存，但這不是必須的娄帖，視情況而定也祠。可以看一下代碼中的注釋：
/**? ?Free?up?the?memory?associated?with?thisbitmap's?pixels,?and?mark?the? ?bitmap?as?"dead",?meaning?itwill?throw?an?exception?if?getPixels()?or? ?setPixels()?is?called,?and?will?drawnothing.?This?operation?cannot?be? ?reversed,?so?it?should?only?be?called?ifyou?are?sure?there?are?no? ?further?uses?for?the?bitmap.?This?is?anadvanced?call,?and?normally?need? ?not?be?called,?since?the?normal?GCprocess?will?free?up?this?memory?when? ?there?are?no?more?references?to?thisbitmap.? */
4.試著使用關(guān)于application的context來替代和activity相關(guān)的context
這是一個很隱晦的內(nèi)存泄漏的情況近速。有一種簡單的方法來避免context相關(guān)的內(nèi)存泄漏诈嘿。最顯著地一個是避免context逃出他自己的范圍之外。使用Application context削葱。這個context的生存周期和你的應(yīng)用的生存周期一樣長奖亚，而不是取決于activity的生存周期。如果你想保持一個長期生存的對象析砸，并且這個對象需要一個context,記得使用application對象昔字。你可以通過調(diào)用 Context.getApplicationContext() or Activity.getApplication()來獲得。更多的請看這篇文章如何避免 Android內(nèi)存泄漏首繁。
5.注冊沒取消造成的內(nèi)存泄漏
一些Android程序可能引用我們的Anroid程序的對象(比如注冊機制)作郭。即使我們的Android程序已經(jīng)結(jié)束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用弦疮，泄漏的內(nèi)存依然不能被垃圾回收夹攒。調(diào)用registerReceiver后未調(diào)用unregisterReceiver。 比如:假設(shè)我們希望在鎖屏界面(LockScreen)中胁塞，監(jiān)聽系統(tǒng)中的電話服務(wù)以獲取一些信息(如信號強度等)芹助，則可以在LockScreen中定義一個 PhoneStateListener的對象，同時將它注冊到TelephonyManager服務(wù)中闲先。對于LockScreen對象状土，當(dāng)需要顯示鎖屏界面的時候就會創(chuàng)建一個LockScreen對象，而當(dāng)鎖屏界面消失的時候LockScreen對象就會被釋放掉伺糠。 但是如果在釋放 LockScreen對象的時候忘記取消我們之前注冊的PhoneStateListener對象蒙谓，則會導(dǎo)致LockScreen無法被垃圾回收。如果不斷的使鎖屏界面顯示和消失训桶，則最終會由于大量的LockScreen對象沒有辦法被回收而引起OutOfMemory,使得system_process 進程掛掉累驮。 雖然有些系統(tǒng)程序酣倾，它本身好像是可以自動取消注冊的(當(dāng)然不及時)，但是我們還是應(yīng)該在我們的程序中明確的取消注冊谤专，程序結(jié)束時應(yīng)該把所有的注冊都取消掉躁锡。
6.集合中對象沒清理造成的內(nèi)存泄漏
我們通常把一些對象的引用加入到了集合中，當(dāng)我們不需要該對象時置侍，并沒有把它的引用從集合中清理掉映之，這樣這個集合就會越來越大。如果這個集合是static的話蜡坊，那情況就更嚴重了杠输。
如果開發(fā)機器上出現(xiàn)問題，我們可以通過查看/data/anr/traces.txt即可秕衙，最新的ANR信息在最開始部分蠢甲。
主線程被IO操作（從4.0之后網(wǎng)絡(luò)IO不允許在主線程中）阻塞。
主線程中存在耗時的計算
主線程中錯誤的操作据忘，比如Thread.wait或者Thread.sleep等 Android系統(tǒng)會監(jiān)控程序的響應(yīng)狀況鹦牛，一旦出現(xiàn)下面兩種情況，則彈出ANR對話框
應(yīng)用在5秒內(nèi)未響應(yīng)用戶的輸入事件（如按鍵或者觸摸）
BroadcastReceiver未在10秒內(nèi)完成相關(guān)的處理
Service在特定的時間內(nèi)無法處理完成 20秒
使用AsyncTask處理耗時IO操作勇吊。
使用Thread或者HandlerThread時能岩，調(diào)用Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)設(shè)置優(yōu)先級，否則仍然會降低程序響應(yīng)萧福，因為默認Thread的優(yōu)先級和主線程相同拉鹃。
使用Handler處理工作線程結(jié)果，而不是使用Thread.wait()或者Thread.sleep()來阻塞主線程鲫忍。
Activity的onCreate和onResume回調(diào)中盡量避免耗時的代碼
BroadcastReceiver中onReceive代碼也要盡量減少耗時膏燕，建議使用IntentService處理。
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0920/3478.html
1）使用更加輕量的數(shù)據(jù)結(jié)構(gòu) 2）Android里面使用Enum 3）Bitmap對象的內(nèi)存占用 4）更大的圖片 5）onDraw方法里面執(zhí)行對象的創(chuàng)建 6）StringBuilder
通過Binder對象
通過broadcast(廣播)的形式
http://blog.csdn.net/lijun952048910/article/details/7980562
Android代碼中實現(xiàn)WAP方式聯(lián)網(wǎng)-360
http://blog.csdn.net/asce1885/article/details/7844159
一悟民、onStartCommand方法坝辫，返回START_STICKY
START_STICKY 在運行onStartCommand后service進程被kill后，那將保留在開始狀態(tài)射亏，但是不保留那些傳入的intent近忙。不久后service就會再次嘗試重新創(chuàng)建，因為保留在開始狀態(tài)智润，在創(chuàng)建 ? ? service后將保證調(diào)用onstartCommand及舍。如果沒有傳遞任何開始命令給service，那將獲取到null的intent窟绷。
START_NOT_STICKY 在運行onStartCommand后service進程被kill后锯玛，并且沒有新的intent傳遞給它。Service將移出開始狀態(tài)，并且直到新的明顯的方法（startService）調(diào)用才重新創(chuàng)建攘残。因為如果沒有傳遞任何未決定的intent那么service是不會啟動拙友，也就是期間onstartCommand不會接收到任何null的intent。
START_REDELIVER_INTENT 在運行onStartCommand后service進程被kill后歼郭，系統(tǒng)將會再次啟動service遗契，并傳入最后一個intent給onstartCommand。直到調(diào)用stopSelf(int)才停止傳遞intent病曾。如果在被kill后還有未處理好的intent牍蜂，那被kill后服務(wù)還是會自動啟動。因此onstartCommand不會接收到任何null的intent知态。
二捷兰、提升service優(yōu)先級
在AndroidManifest.xml文件中對于intent-filter可以通過android:priority = "1000"這個屬性設(shè)置最高優(yōu)先級立叛，1000是最高值负敏，如果數(shù)字越小則優(yōu)先級越低，同時適用于廣播秘蛇。
三其做、提升service進程優(yōu)先級
Android中的進程是托管的，當(dāng)系統(tǒng)進程空間緊張的時候赁还，會依照優(yōu)先級自動進行進程的回收妖泄。Android將進程分為6個等級,它們按優(yōu)先級順序由高到低依次是:
前臺進程( FOREGROUND_APP)
可視進程(VISIBLE_APP )
次要服務(wù)進程(SECONDARY_SERVER )
后臺進程 (HIDDEN_APP)
內(nèi)容供應(yīng)節(jié)點(CONTENT_PROVIDER)
空進程(EMPTY_APP)
當(dāng)service運行在低內(nèi)存的環(huán)境時，將會kill掉一些存在的進程艘策。因此進程的優(yōu)先級將會很重要蹈胡，可以使用startForeground 將service放到前臺狀態(tài)。這樣在低內(nèi)存時被kill的幾率會低一些朋蔫。
四罚渐、onDestroy方法里重啟service
service +broadcast ?方式，就是當(dāng)service走ondestory的時候驯妄，發(fā)送一個自定義的廣播荷并，當(dāng)收到廣播的時候，重新啟動service青扔；
五源织、Application加上Persistent屬性
六、監(jiān)聽系統(tǒng)廣播判斷Service狀態(tài)
通過系統(tǒng)的一些廣播微猖，比如：手機重啟谈息、界面喚醒、應(yīng)用狀態(tài)改變等等監(jiān)聽并捕獲到凛剥，然后判斷我們的Service是否還存活黎茎，別忘記加權(quán)限啊。
Requestlayout,onlayout,onDraw,DrawChild區(qū)別與聯(lián)系-獵豹
requestLayout()方法 ：會導(dǎo)致調(diào)用measure()過程 和 layout()過程 当悔。 將會根據(jù)標志位判斷是否需要ondraw
onLayout()方法(如果該View是ViewGroup對象傅瞻，需要實現(xiàn)該方法踢代，對每個子視圖進行布局)
調(diào)用onDraw()方法繪制視圖本身?? (每個View都需要重載該方法，ViewGroup不需要實現(xiàn)該方法)
drawChild()去重新回調(diào)每個子視圖的draw()方法
invalidate()和postInvalidate()的區(qū)別及使用-百度
http://blog.csdn.net/mars2639/article/details/6650876
Animation框架定義了透明度嗅骄，旋轉(zhuǎn)胳挎，縮放和位移幾種常見的動畫，而且控制的是整個View溺森，實現(xiàn)原理是每次繪制視圖時View所在的ViewGroup中的drawChild函數(shù)獲取該View的Animation的Transformation值慕爬，然后調(diào)用canvas.concat(transformToApply.getMatrix())，通過矩陣運算完成動畫幀屏积，如果動畫沒有完成医窿，繼續(xù)調(diào)用invalidate()函數(shù)，啟動下次繪制來驅(qū)動動畫炊林，動畫過程中的幀之間間隙時間是繪制函數(shù)所消耗的時間姥卢，可能會導(dǎo)致動畫消耗比較多的CPU資源，最重要的是渣聚，動畫改變的只是顯示独榴，并不能相應(yīng)事件。
Android為每個應(yīng)用程序分配的內(nèi)存大小是多少-美團
android程序內(nèi)存一般限制在16M奕枝，也有的是24M
由ViewRoot對象的performTraversals()方法調(diào)用draw()方法發(fā)起繪制該View樹棺榔，值得注意的是每次發(fā)起繪圖時，并不會重新繪制每個View樹的視圖隘道，而只會重新繪制那些“需要重繪”的視圖症歇，View類內(nèi)部變量包含了一個標志位DRAWN，當(dāng)該視圖需要重繪時谭梗，就會為該View添加該標志位忘晤。
調(diào)用流程 ：
mView.draw()開始繪制，draw()方法實現(xiàn)的功能如下：
繪制該View的背景
為顯示漸變框做一些準備操作(見5默辨，大多數(shù)情況下德频，不需要改漸變框)
調(diào)用onDraw()方法繪制視圖本身?? (每個View都需要重載該方法，ViewGroup不需要實現(xiàn)該方法)
調(diào)用dispatchDraw ()方法繪制子視圖(如果該View類型不為ViewGroup缩幸，即不包含子視圖壹置，不需要重載該方法)值得說明的是，ViewGroup類已經(jīng)為我們重寫了dispatchDraw ()的功能實現(xiàn)表谊，應(yīng)用程序一般不需要重寫該方法钞护，但可以重載父類函數(shù)實現(xiàn)具體的功能。
LinearLayout和RelativeLayout性能對比-百度
RelativeLayout會讓子View調(diào)用2次onMeasure爆办，LinearLayout 在有weight時难咕，也會調(diào)用子View2次onMeasure
RelativeLayout的子View如果高度和RelativeLayout不同，則會引發(fā)效率問題，當(dāng)子View很復(fù)雜時余佃，這個問題會更加嚴重暮刃。如果可以，盡量使用padding代替margin爆土。
在不影響層級深度的情況下,使用LinearLayout和FrameLayout而不是RelativeLayout椭懊。
最后再思考一下文章開頭那個矛盾的問題，為什么Google給開發(fā)者默認新建了個RelativeLayout步势，而自己卻在DecorView中用了個LinearLayout氧猬。因為DecorView的層級深度是已知而且固定的，上面一個標題欄坏瘩，下面一個內(nèi)容欄盅抚。采用RelativeLayout并不會降低層級深度，所以此時在根節(jié)點上用LinearLayout是效率最高的倔矾。而之所以給開發(fā)者默認新建了個RelativeLayout是希望開發(fā)者能采用盡量少的View層級來表達布局以實現(xiàn)性能最優(yōu)妄均，因為復(fù)雜的View嵌套對性能的影響會更大一些。
為了加速你的view破讨，對于頻繁調(diào)用的方法丛晦，需要盡量減少不必要的代碼奕纫。先從onDraw開始提陶，需要特別注意不應(yīng)該在這里做內(nèi)存分配的事情，因為它會導(dǎo)致GC匹层，從而導(dǎo)致卡頓隙笆。在初始化或者動畫間隙期間做分配內(nèi)存的動作。不要在動畫正在執(zhí)行的時候做內(nèi)存分配的事情升筏。
你還需要盡可能的減少onDraw被調(diào)用的次數(shù)撑柔，大多數(shù)時候?qū)е耾nDraw都是因為調(diào)用了invalidate().因此請盡量減少調(diào)用invaildate()的次數(shù)。如果可能的話您访，盡量調(diào)用含有4個參數(shù)的invalidate()方法而不是沒有參數(shù)的invalidate()铅忿。沒有參數(shù)的invalidate會強制重繪整個view。
另外一個非常耗時的操作是請求layout灵汪。任何時候執(zhí)行requestLayout()檀训，會使得Android UI系統(tǒng)去遍歷整個View的層級來計算出每一個view的大小。如果找到有沖突的值享言，它會需要重新計算好幾次峻凫。另外需要盡量保持View的層級是扁平化的，這樣對提高效率很有幫助览露。
如果你有一個復(fù)雜的UI荧琼，你應(yīng)該考慮寫一個自定義的ViewGroup來執(zhí)行他的layout操作。與內(nèi)置的view不同，自定義的view可以使得程序僅僅測量這一部分命锄，這避免了遍歷整個view的層級結(jié)構(gòu)來計算大小堰乔。這個PieChart 例子展示了如何繼承ViewGroup作為自定義view的一部分。PieChart 有子views脐恩，但是它從來不測量它們浩考。而是根據(jù)他自身的layout法則，直接設(shè)置它們的大小被盈。
http://blog.csdn.net/coder_pig/article/details/47858489
http://a.codekk.com/detail/Android/grumoon/Volley%20%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90
http://www.lightskystreet.com/2015/10/12/glide_source_analysis/http://frodoking.github.io/2015/10/10/android-glide/
http://blog.csdn.net/bboyfeiyu/article/details/44563871
http://www.tianmaying.com/tutorial/AndroidMVC
如果你的需求中只需要對View進行移動析孽、縮放、旋轉(zhuǎn)和淡入淡出操作只怎，那么補間動畫確實已經(jīng)足夠健全了袜瞬。但是很顯然，這些功能是不足以覆蓋所有的場景的身堡，一旦我們的需求超出了移動邓尤、縮放、旋轉(zhuǎn)和淡入淡出這四種對View的操作贴谎，那么補間動畫就不能再幫我們忙了汞扎，也就是說它在功能和可擴展方面都有相當(dāng)大的局限性，那么下面我們就來看看補間動畫所不能勝任的場景擅这。
注意上面我在介紹補間動畫的時候都有使用“對View進行操作”這樣的描述澈魄，沒錯，補間動畫是只能夠作用在View上的仲翎。也就是說痹扇，我們可以對一個Button、TextView溯香、甚至是LinearLayout鲫构、或者其它任何繼承自View的組件進行動畫操作，但是如果我們想要對一個非View的對象進行動畫操作玫坛，抱歉结笨，補間動畫就幫不上忙了∈疲可能有的朋友會感到不能理解炕吸，我怎么會需要對一個非View的對象進行動畫操作呢？這里我舉一個簡單的例子肠骆，比如說我們有一個自定義的View算途，在這個View當(dāng)中有一個Point對象用于管理坐標，然后在onDraw()方法當(dāng)中就是根據(jù)這個Point對象的坐標值來進行繪制的蚀腿。也就是說嘴瓤，如果我們可以對Point對象進行動畫操作扫外，那么整個自定義View的動畫效果就有了。顯然廓脆，補間動畫是不具備這個功能的筛谚，這是它的第一個缺陷。
然后補間動畫還有一個缺陷停忿，就是它只能夠?qū)崿F(xiàn)移動驾讲、縮放、旋轉(zhuǎn)和淡入淡出這四種動畫操作席赂，那如果我們希望可以對View的背景色進行動態(tài)地改變呢吮铭？很遺憾，我們只能靠自己去實現(xiàn)了颅停。說白了谓晌，之前的補間動畫機制就是使用硬編碼的方式來完成的，功能限定死就是這些癞揉，基本上沒有任何擴展性可言纸肉。
最后，補間動畫還有一個致命的缺陷喊熟，就是它只是改變了View的顯示效果而已柏肪，而不會真正去改變View的屬性。什么意思呢芥牌？比如說烦味，現(xiàn)在屏幕的左上角有一個按鈕，然后我們通過補間動畫將它移動到了屏幕的右下角胳泉，現(xiàn)在你可以去嘗試點擊一下這個按鈕拐叉，點擊事件是絕對不會觸發(fā)的岩遗，因為實際上這個按鈕還是停留在屏幕的左上角扇商，只不過補間動畫將這個按鈕繪制到了屏幕的右下角而已。
