1. service生命周期（http://blog.csdn.net/todo_/article/details/51097453）

被啟動(dòng)的服務(wù)的生命周期：如果一個(gè)Service被某個(gè)Activity 調(diào)用

Context.startService 方法啟動(dòng)，那么不管是否有Activity使用bindService綁定或unbindService解除綁定到該Service，該Service都在后臺(tái)運(yùn)行。如果一個(gè)Service被startService 方法多次啟動(dòng)，那么onCreate方法只會(huì)調(diào)用一次，onStart將會(huì)被調(diào)用多次（對(duì)應(yīng)調(diào)用startService的次數(shù)），并且系統(tǒng)只會(huì)創(chuàng)建Service的一個(gè)實(shí)例（因此你應(yīng)該知道只需要一次stopService調(diào)用）。該Service將會(huì)一直在后臺(tái)運(yùn)行，而不管對(duì)應(yīng)程序的Activity是否在運(yùn)行，直到被調(diào)用stopService，或自身的stopSelf方法。當(dāng)然如果系統(tǒng)資源不足，android系統(tǒng)也可能結(jié)束服務(wù)

被綁定的服務(wù)的生命周期：如果一個(gè)Service被某個(gè)Activity 調(diào)用

Context.bindService 方法綁定啟動(dòng)，不管調(diào)用

bindService 調(diào)用幾次，onCreate方法都只會(huì)調(diào)用一次，同時(shí)onStart方法始終不會(huì)被調(diào)用。當(dāng)連接建立之后，Service將會(huì)一直運(yùn)行，除非調(diào)用Context.unbindService

斷開(kāi)連接或者之前調(diào)用bindService

的

Context 不存在了（如Activity被finish的時(shí)候），系統(tǒng)將會(huì)自動(dòng)停止Service，對(duì)應(yīng)onDestroy將被調(diào)用。

被啟動(dòng)又被綁定的服務(wù)的生命周期：如果一個(gè)Service又被啟動(dòng)又被綁定，則該Service將會(huì)一直在后臺(tái)運(yùn)行。并且不管如何調(diào)用，onCreate始終只會(huì)調(diào)用一次，對(duì)應(yīng)startService調(diào)用多少次，Service的onStart便會(huì)調(diào)用多少次。調(diào)用unbindService將不會(huì)停止Service，而必須調(diào)用

stopService 或

Service的

stopSelf 來(lái)停止服務(wù)。

當(dāng)服務(wù)被停止時(shí)清除服務(wù)：當(dāng)一個(gè)Service被終止（1、調(diào)用stopService；2、調(diào)用stopSelf；3、不再有綁定的連接（沒(méi)有被啟動(dòng)））時(shí)，onDestroy方法將會(huì)被調(diào)用，在這里你應(yīng)當(dāng)做一些清除工作，如停止在Service中創(chuàng)建并運(yùn)行的線程。

特別注意：

你應(yīng)當(dāng)知道在調(diào)用

bindService 綁定到Service的時(shí)候，你就應(yīng)當(dāng)保證在某處調(diào)用 unbindService 解除綁定（盡管 Activity 被 finish 的時(shí)候綁定會(huì)自動(dòng)解除，并且Service會(huì)自動(dòng)停止）；

你應(yīng)當(dāng)注意 使用

startService 啟動(dòng)服務(wù)之后，一定要使用 stopService停止服務(wù)，不管你是否使用bindService；

同時(shí)使用 startService 與 bindService 要注意到，Service 的終止，需要unbindService與stopService同時(shí)調(diào)用，才能終止 Service，不管 startService 與 bindService 的調(diào)用順序，如果先調(diào)用 unbindService 此時(shí)服務(wù)不會(huì)自動(dòng)終止，再調(diào)用 stopService 之后服務(wù)才會(huì)停止，如果先調(diào)用 stopService 此時(shí)服務(wù)也不會(huì)終止，而再調(diào)用 unbindService 或者 之前調(diào)用 bindService 的 Context 不存在了（如Activity 被 finish 的時(shí)候）之后服務(wù)才會(huì)自動(dòng)停止；

當(dāng)在旋轉(zhuǎn)手機(jī)屏幕的時(shí)候，當(dāng)手機(jī)屏幕在“橫”“豎”變換時(shí)，此時(shí)如果你的

Activity 如果會(huì)自動(dòng)旋轉(zhuǎn)的話，旋轉(zhuǎn)其實(shí)是 Activity 的重新創(chuàng)建，因此旋轉(zhuǎn)之前的使用 bindService 建立的連接便會(huì)斷開(kāi)（Context 不存在了），對(duì)應(yīng)服務(wù)的生命周期與上述相同。

在 sdk 2.0 及其以后的版本中，對(duì)應(yīng)的 onStart 已經(jīng)被否決變?yōu)榱?onStartCommand，不過(guò)之前的 onStart 任然有效。這意味著，如果你開(kāi)發(fā)的應(yīng)用程序用的 sdk 為 2.0 及其以后的版本，那么你應(yīng)當(dāng)使用 onStartCommand 而不是 onStart。

生命周期方法說(shuō)明

onStartCommand()當(dāng)另一個(gè)組件（如 Activity）通過(guò)調(diào)用 startService() 請(qǐng)求啟動(dòng)服務(wù)時(shí)，系統(tǒng)將調(diào)用此方法。一旦執(zhí)行此方法，服務(wù)即會(huì)啟動(dòng)并可在后臺(tái)無(wú)限期運(yùn)行。

如果您實(shí)現(xiàn)此方法，則在服務(wù)工作完成后，需要由您通過(guò)調(diào)用 stopSelf() 或 stopService() 來(lái)停止服務(wù)。（如果您只想提供綁定，則無(wú)需實(shí)現(xiàn)此方法。）

onBind()

當(dāng)另一個(gè)組件想通過(guò)調(diào)用 bindService() 與服務(wù)綁定（例如執(zhí)行 RPC）時(shí)，系統(tǒng)將調(diào)用此方法。在此方法的實(shí)現(xiàn)中，您必須通過(guò)返回 IBinder 提供一個(gè)接口，供客戶端用來(lái)與服務(wù)進(jìn)行通信。請(qǐng)務(wù)必實(shí)現(xiàn)此方法，但如果您并不希望允許綁定，則應(yīng)返回 null。

onCreate()

首次創(chuàng)建服務(wù)時(shí)，系統(tǒng)將調(diào)用此方法來(lái)執(zhí)行一次性設(shè)置程序（在調(diào)用 onStartCommand() 或 onBind() 之前）。如果服務(wù)已在運(yùn)行，則不會(huì)調(diào)用此方法。

onDestroy()

當(dāng)服務(wù)不再使用且將被銷毀時(shí)，系統(tǒng)將調(diào)用此方法。服務(wù)應(yīng)該實(shí)現(xiàn)此方法來(lái)清理所有資源，如線程、注冊(cè)的偵聽(tīng)器、接收器等。

這是服務(wù)接收的最后一個(gè)調(diào)用。

2. Android子線程更新UI的方法( http://blog.csdn.net/silleyj/article/details/55006573 ）

專業(yè)術(shù)語(yǔ)：

Message：消息，其中包含了消息ID，消息處理對(duì)象以及處理的數(shù)據(jù)等，由MessageQueue統(tǒng)一列隊(duì)，終由Handler處理。?

Handler：處理者，負(fù)責(zé)Message的發(fā)送及處理。使用Handler時(shí)，需要實(shí)現(xiàn)handleMessage(Message msg)方法來(lái)對(duì)特定的Message進(jìn)行處理，例如更新UI等。?

MessageQueue：消息隊(duì)列，用來(lái)存放Handler發(fā)送過(guò)來(lái)的消息，并按照FIFO規(guī)則執(zhí)行。當(dāng)然，存放Message并非實(shí)際意義的保存，而是將Message以鏈表的方式串聯(lián)起來(lái)的，等待Looper的抽取。?

Looper：消息泵，不斷地從MessageQueue中抽取Message執(zhí)行。因此，一個(gè)MessageQueue需要一個(gè)Looper。?

Thread：線程，負(fù)責(zé)調(diào)度整個(gè)消息循環(huán)，即消息循環(huán)的執(zhí)行場(chǎng)所。

用Handler

主線程中定義Handler (handleMessage(Message msg))

子線程發(fā)消息，通知Handler完成UI更新 （Thread(new Runnable()))

用Activity對(duì)象的runOnUiThread方法更新 ，在子線程中通過(guò)runOnUiThread（）方法更新UI

View.post(Runnabler)

3. Android Service和Thread的區(qū)別（https://www.cnblogs.com/carlo/p/4947342.html ）

Thread：Thread 是程序執(zhí)行的最小單元，可以用Thread 來(lái)執(zhí)行一些異步的操作。Thread 的運(yùn)行是獨(dú)立的，也就是說(shuō)當(dāng)一個(gè) Activity 被 finish 之后，如果沒(méi)有主動(dòng)停止 Thread 或者 Thread 里的 run 方法沒(méi)有執(zhí)行完畢的話，Thread 也會(huì)一直執(zhí)行。因此這里會(huì)出現(xiàn)一個(gè)問(wèn)題：當(dāng) Activity 被 finish 之后，不再持有該 Thread 的引用，也就是不能再控制該Thread。另一方面，沒(méi)有辦法在不同的 Activity 中對(duì)同一 Thread 進(jìn)行控制。

Service：Service 是android的一種機(jī)制（既不是線程也不是進(jìn)程），當(dāng)它運(yùn)行的時(shí)候如果是Local Service，那么對(duì)應(yīng)的 Service 是運(yùn)行在主進(jìn)程的 main 線程上的。如果是Remote Service，那么對(duì)應(yīng)的

Service 則是運(yùn)行在獨(dú)立進(jìn)程的 main 線程上。使用Service來(lái)處理后臺(tái)任務(wù)，Activity就可以放心地finish，完全不需要擔(dān)心無(wú)法對(duì)后臺(tái)任務(wù)進(jìn)行控制的情況。

4. ConcurrentHashMap

（http://www.importnew.com/22007.html ）

5. Volatitle 與 synchronized（https://www.cnblogs.com/hapjin/p/5492880.html ）

從圖中可以看出：

每個(gè)線程都有一個(gè)自己的本地內(nèi)存空間--線程?？臻g???線程執(zhí)行時(shí)，先把變量從主內(nèi)存讀取到線程自己的本地內(nèi)存空間，然后再對(duì)該變量進(jìn)行操作

對(duì)該變量操作完后，在某個(gè)時(shí)間再把變量刷新回主內(nèi)存

當(dāng)多個(gè)線程之間需要根據(jù)某個(gè)條件確定哪個(gè)線程可以執(zhí)行時(shí)，要確保這個(gè)條件在 線程 之間是可見(jiàn)的。因此，可以用volatile修飾。

volatile關(guān)鍵字的非原子性(所謂原子性，就是某系列的操作步驟要么全部執(zhí)行，要么都不執(zhí)行。)

volatile關(guān)鍵字修飾的變量不會(huì)被指令重排序優(yōu)化

volatile輕量級(jí)，只能修飾變量。synchronized重量級(jí)，還可修飾方法

volatile只能保證數(shù)據(jù)的可見(jiàn)性，不能用來(lái)同步，因?yàn)槎鄠€(gè)線程并發(fā)訪問(wèn)volatile修飾的變量不會(huì)阻塞。

synchronized不僅保證可見(jiàn)性，而且還保證原子性，因?yàn)?，只有獲得了鎖的線程才能進(jìn)入臨界區(qū)，從而保證臨界區(qū)中的所有語(yǔ)句都全部執(zhí)行。多個(gè)線程爭(zhēng)搶synchronized鎖對(duì)象時(shí)，會(huì)出現(xiàn)阻塞。

6. 重載與重寫（http://blog.csdn.net/linzhaojie525/article/details/55213010 ）

重寫方法的規(guī)則：

參數(shù)列表必須完全與被重寫的方法相同，否則不能稱其為重寫而是重載。

返回的類型必須一直與被重寫的方法的返回類型相同，否則不能稱其為重寫而是重載。

訪問(wèn)修飾符的限制一定要大于被重寫方法的訪問(wèn)修飾符（public>protected>default>private）

重寫方法一定不能拋出新的檢查異?；蛘弑缺恢貙懛椒ㄉ昝鞲訉挿旱臋z查型異常。例如：父類的一個(gè)方法申明了一個(gè)檢查異常IOException，在重寫這個(gè)方法是就不能拋出Exception,只能拋出IOException的子類異常，可以拋出非檢查異常。

而重載的規(guī)則：

必須具有不同的參數(shù)列表；

可以有不同的返回類型，只要參數(shù)列表不同就可以了；

可以有不同的訪問(wèn)修飾符；

可以拋出不同的異常；

7. 降低Java垃圾回收開(kāi)銷的方法(http://www.importnew.com/20656.html )

預(yù)測(cè)集合的容量

直接處理數(shù)據(jù)流

使用不可變對(duì)象

小心字符串的拼接

使用特定的原生類集合

8. Runnable 與 Callable(https://www.cnblogs.com/frinder6/p/5507082.html )

相同點(diǎn)：

兩者都是接口；（廢話）

兩者都可用來(lái)編寫多線程程序；

兩者都需要調(diào)用Thread.start()啟動(dòng)線程；

不同點(diǎn)：

兩者最大的不同點(diǎn)是：實(shí)現(xiàn)Callable接口的任務(wù)線程能返回執(zhí)行結(jié)果；而實(shí)現(xiàn)Runnable接口的任務(wù)線程不能返回結(jié)果；

Callable接口的call()方法允許拋出異常；而Runnable接口的run()方法的異常只能在內(nèi)部消化，不能繼續(xù)上拋；

9. Java 內(nèi)存溢出（java.lang.OutOfMemoryError）(http://outofmemory.cn/c/java-outOfMemoryError )

導(dǎo)致OutOfMemoryError異常的常見(jiàn)原因有以下幾種：

內(nèi)存中加載的數(shù)據(jù)量過(guò)于龐大，如一次從數(shù)據(jù)庫(kù)取出過(guò)多數(shù)據(jù)；

集合類中有對(duì)對(duì)象的引用，使用完后未清空，使得JVM不能回收；

代碼中存在死循環(huán)或循環(huán)產(chǎn)生過(guò)多重復(fù)的對(duì)象實(shí)體；

使用的第三方軟件中的BUG；

啟動(dòng)參數(shù)內(nèi)存值設(shè)定的過(guò)?。?/p>

此錯(cuò)誤常見(jiàn)的錯(cuò)誤提示：

tomcat:java.lang.OutOfMemoryError:

PermGen space

tomcat:java.lang.OutOfMemoryError:

Java heap space

weblogic:Root

cause of ServletException java.lang.OutOfMemoryError

resin:java.lang.OutOfMemoryError

java:java.lang.OutOfMemoryError

10. find grep組合使用\ (http://blog.csdn.net/cupidove/article/details/8767450)

查找所有".h"文件

find/PATH -name "*.h"

查找所有".h"文件中的含有"helloworld"字符串的文件

find /PATH-name "*.h" -exec grep -in "helloworld" {} \;

find /PATH -name "*.h" | xargs grep -in "helloworld"

查找所有".h"和".c"文件中的含有"helloworld"字符串的文件

find /PATH/( -name "*.h" -or -name "*.c" /) -exec grep -in

"helloworld" {} \;

11. shell 中$0,$1,$2的含義（http://blog.csdn.net/qq_30137611/article/details/77092524）

簡(jiǎn)單來(lái)說(shuō) $0 就是你寫的shell腳本本身的名字，$1 是你給你寫的shell腳本傳的第一個(gè)參數(shù)，$2 是你給你寫的shell腳本傳的第二個(gè)參數(shù)

12. HashMap 與HashTable的區(qū)別（http://www.androidchina.net/1802.html ）

HashMap是非synchronized，可以接受key與value值為空，HashTable不行

HashMap是非synchronized，HashTable是synchronized。HashTable是線程安全的，多個(gè)線程可以共享一個(gè)HashTable。而如果沒(méi)有正確同步的話，多個(gè)線程是不能共享HashMap的。

HashMap的迭代器（Iterator）是fail-fast迭代器，而Hashtable的enumrator迭代器不是fail-fast。當(dāng)線程改變了HashMap的結(jié)構(gòu)時(shí)會(huì)拋出ConcurrentModificationException。但是迭代器本身remove（）函數(shù)移除元素時(shí)不會(huì)拋出 異常。

HashTable是線程安全的也是synchronized，所以在單線程環(huán)境比HashMap要慢。如果，不需要同步，HashMap要好過(guò)HashTable。

HashMap不能保證隨時(shí)間推移map元素次序不變。

13. AVL（平衡二叉樹(shù)）

定義：AVL樹(shù)是二叉樹(shù)，其各個(gè)節(jié)點(diǎn)的左右子樹(shù)的高度相差不超過(guò)1。

定義：數(shù)的高度可以看做是節(jié)點(diǎn)與最低的葉子節(jié)點(diǎn)的距離。跟節(jié)點(diǎn)的高度最大，而葉子節(jié)點(diǎn)的高度為0，一個(gè)不存在的節(jié)點(diǎn)的高度定義為-1。

14. TCP/IP協(xié)議端口

端口號(hào)的范圍從0到65535，比如用于瀏覽網(wǎng)頁(yè)服務(wù)的80端口，用于FTP服務(wù)的21端口等。由于物理端口和邏輯端口數(shù)量較多，為了對(duì)端口進(jìn)行區(qū)分，將每個(gè)端口進(jìn)行了編號(hào)，這就是端口號(hào)。

15. UDP分片

以太網(wǎng)的數(shù)據(jù)幀必須要在46-1500之間，所以1500字節(jié)被稱為最大傳輸單元MTU。當(dāng)UDP的數(shù)據(jù)報(bào)大于1500時(shí)發(fā)送方的IP就要分片，