Android最新面試實戰總結

熱文導讀 | 點選標題閱讀

金九銀十跳槽季如何進階找到合適滿意的工作？

Spring中的9種設計模式彙總

凜冬將至？對網際網路行業人員流動性的一些看法(深度好文)

作者：騎小豬看流星 

來源：http://www.apkbus.com/blog-973383-79263.html

所謂,君子性非異也,善假於物也！~
那麼，本文意在給大家提供快速、全面、高效的面試解決方案；
為大家節約尋找面試、筆試答案的時間；
讓閱讀本文或收藏本文的開發者成為Android面試場上的最強王者；
更是為開發者量身定製立志成為面試官的夢魘而奮鬥！
現筆者將自己親身實戰的面試題及收到的面試題總結並分享答案出來。歡迎各位Developer斧正和指點，也希望看到本文的小夥伴積極提供面試題以供分享，內容分為Java和Android兩大篇。

JAVA:

volatitle關鍵字及其原理?

Volatile是輕量級的synchronized，它在多執行緒開發中保證了共享變數的“可見性”。可見性的意思是當一個執行緒修改一個共享變數時，另外一個執行緒能讀到這個修改的值。它在某些情況下比synchronized的開銷更小，如果一個欄位被宣告成volatile，java執行緒記憶體模型確保所有執行緒看到這個變數的值是一致的(比較常用的就是單例模式中,對欄位的宣告,加上這個關鍵字)。

Volatile原理:

處理器為了提高處理速度，不直接和記憶體進行通訊，而是先將系統記憶體的資料讀到內部快取（L1,L2或其他）後再進行操作，但操作完之後不知道何時會寫到記憶體，如果對宣告瞭Volatile變數進行寫操作，JVM就會向處理器傳送一條Lock字首的指令，將這個變數所在快取行的資料寫回到系統記憶體。但是就算寫回到記憶體，如果其他處理器快取的值還是舊的，再執行計算操作就會有問題，所以在多處理器下，為了保證各個處理器的快取是一致的，就會實現快取一致性協議，每個處理器通過嗅探在匯流排上傳播的資料來檢查自己快取的值是不是過期了，當處理器發現自己快取行對應的記憶體地址被修改，就會將當前處理器的快取行設定成無效狀態，當處理器要對這個資料進行修改操作的時候，會強制重新從系統記憶體裡把資料讀到處理器快取裡。

原理總結 (重點):先將當前處理器快取行的資料會寫回到系統記憶體\,其次,這個寫回記憶體的操作會引起在其他CPU裡快取了該記憶體地址的資料無效。最後,當處理器要對這個資料進行修改操作的時候，會強制重新從系統記憶體裡把資料讀到處理器快取裡。如此迴圈反覆保證共享變數的值是一致的

synchronize的理解及原理
A: 每個物件有一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，執行緒執行monitorenter指令時嘗試獲取monitor的所有權，過程如下：
1、如果monitor的進入數為0，則該執行緒進入monitor，然後將進入數設定為1，該執行緒即為monitor的所有者。
2、如果執行緒已經佔有該monitor，只是重新進入，則進入monitor的進入數加1.
3.如果其他執行緒已經佔用了monitor，則該執行緒進入阻塞狀態，直到monitor的進入數為0，再重新嘗試獲取monitor的所有權。

B:執行monitorexit的執行緒必須是objectref所對應的monitor的所有者。
指令執行時，monitor的進入數減1，如果減1後進入數為0，那執行緒退出monitor，不再是這個monitor的所有者。其他被這個monitor阻塞的執行緒可以嘗試去獲取這個 monitor 的所有權。
可能你看暈了,沒事,附上鍊接:synchronize原理探索

簡述多型?
多型就是指程式中定義的引用變數所指向的具體型別和通過該引用變數發出的方法呼叫在程式設計時並不確定，而是在程式執行期間才確定，即一個引用變數倒底會指向哪個類的例項物件，該引用變數發出的方法呼叫到底是哪個類中實現的方法，必須在由程式執行期間才能決定。簡稱:父類引用指向子類物件
由多型引申的概念:向上轉型

它只能訪問父類中擁有的方法和屬性，而對於子類中存在而父類中不存在的方法，該引用是不能使用的，儘管是過載該方法。若子類重寫了父類中的某些方法，在呼叫該些方法的時候，必定是使用子類中定義的這些方法（動態連線、動態呼叫）。
Java實現多型有三個必要條件：繼承、重寫、向上轉型。
更詳細的說明和補充可以點選這裡瞭解多型

對Java的理解?
可以從物件導向、分散式、健壯性、安全性、平臺獨立與可移植性、多執行緒、動態性等特點。桌面應用程式、Web應用程式、分散式系統和嵌入式系統應用程式,Android開發等等回答.

抽象類與介面的聯絡與區別?
相同點:
都不能直接例項化,
介面的實現類或抽象類的子類都只有實現了介面或抽象類中的方法後才能被例項化

區別:
1、抽象類變數必須指向實現所有抽象方法的子類物件，介面變數必須指向實現所有介面方法的類物件。
2、抽象類要被子類繼承，介面要被類實現。
3、介面只能做方法申明，抽象類中可以做方法申明，也可以做方法實現
4、介面裡定義的變數只能是公共的靜態的常量，抽象類中的變數是普通變數。
5、抽象類裡的抽象方法必須全部被子類所實現，如果子類不能全部實現父類抽象方法，那麼該子類只能是抽象類。同樣，一個實現介面的時候，如不能全部實現介面方法，那麼該類也只能為抽象類。
6、抽象方法只能申明，不能實現。abstract void abc();不能寫成abstract void abc(){}。
7、抽象類裡可以沒有抽象方法
8、如果一個類裡有抽象方法，那麼這個類只能是抽象類
9、抽象方法要被實現，所以不能是靜態的，也不能是私有的。
10、介面可繼承介面，並可多繼承介面，但類只能單根繼承。

綜述 : 特別是對於公用的實現程式碼，抽象類有它的優點。抽象類能夠保證實現的層次關係，避免程式碼重複。然而，即使在使用抽 象類的場合，也不要忽視通過介面定義行為模型的原則。從實踐的角度來看，如果依賴於抽象類來定義行為，往往導致過於複雜的繼承關係，而通過介面定義行為能 夠更有效地分離行為與實現，為程式碼的維護和修改帶來方便。

float f=2.3;是否正確?
不正確。2.3是雙精度數，將雙精度型(double)賦值給浮點型(float)屬於下轉型(down-casting，也稱為窄化)會造成精度損失，因此需要強制型別轉換float f =(float)2.3; 或者寫成float f =2.3F;。

short s1 = 1; s1 = s1 + 1;有錯嗎?short s1 = 1; s1 += 1;有錯嗎?
對於short s1 = 1; s1 = s1 + 1;由於1是int型別，因此s1+1運算結果也是int 型，需要強制轉換型別才能賦值給short型。而short s1 = 1; s1 += 1;可以正確編譯，因為s1+= 1;相當於s1 = (short)(s1 + 1);其中有隱含的強制型別轉換。

當一個物件被當作引數傳遞到一個方法後，此方法可改變這個物件的屬性，並可返回變化後的結果，那麼這裡到底是值傳遞還是引用傳遞?
值傳遞。Java語言的方法呼叫只支援引數的值傳遞。當一個物件例項作為一個引數被傳遞到方法中時，引數的值就是對該物件的引用。物件的屬性可以在被呼叫過程中被改變，但對物件引用的改變是不會影響到呼叫者的。

如何保證執行緒安全?
簡單來說，執行緒安全就是：在多執行緒環境中，能永遠保證程式的正確性。因此,只有存在共享資料時才需要考慮執行緒安全問題。

解決方案1:Java多執行緒支援引入同步監視器來解決這個問題,使用同步監視器的通用方法就是同步程式碼塊,使用synchronize(obj)程式碼塊,(目的:任何時刻只能有一個執行緒可以獲得對同步監視器的鎖定,當同步程式碼塊執行完成後,該執行緒會釋放對該同步監視器的鎖定) 推薦使用可能被併發訪問的共享資源充當同步監視器,邏輯大概就是   加鎖-->修改-->釋放鎖 
解決方案2:通過顯示定義同步鎖物件實現同步,在這種機制下,同步鎖用Lock物件充當,Lock允許實現更靈活的結構,有差別很大的屬性,使用Lock物件來進行同步,加鎖和釋放鎖出現在不同的作用範圍內,通常建議使用finally塊來確保在必要時候釋放鎖

簡述Java中為什麼會出現死鎖?
當兩個執行緒相互等待對方釋放同步監視器時就會發生死鎖,Java虛擬機器沒有監測也沒有采取措施來處理死鎖情況,所以多執行緒程式設計時應該採取措施避免死鎖出現.一旦出現死鎖,整個程式既不會發生任何異常,也不會給出任何提示,只是所有執行緒處於阻塞狀態,無法繼續.

簡述Java中的四種引用?
1) 強引用（StrongReference）
強引用是使用最普遍的引用。比如new 物件等等,如果一個物件具有強引用，那垃圾回收器絕不會回收它。當記憶體空間不足，Java虛擬機器寧願丟擲OutOfMemoryError錯誤，使程式異常終止，也不會靠隨意回收具有強引用的物件來解決記憶體不足的問題。
2) 軟引用（SoftReference）
如果一個物件只具有軟引用，則記憶體空間足夠，垃圾回收器就不會回收它；如果記憶體空間不足了，就會回收這些物件的記憶體。軟引用可用來實現記憶體敏感的快取記憶體。
3) 弱引用（WeakReference）
在java中，用java.lang.ref.WeakReference類來表示弱引用.  與軟引用的區別在於：弱引用的物件擁有更短暫的生命週期。在垃圾回收器執行緒掃描它所管轄的記憶體區域的過程中，一旦發現了只具有弱引用的物件，不管當前記憶體空間足夠與否，都會回收它的記憶體。不過，由於垃圾回收器是一個優先順序很低的執行緒，因此不一定會很快發現那些只具有弱引用的物件。
4)虛引用（PhantomReference）
“虛引用”顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定物件的生命週期。在java中用java.lang.ref.PhantomReference類表示。

強引用置為null,會不會被回收?
只要是強引用就證明這個記憶體是在的，但是置為null,因此回收器在適當的時候回收,什麼是適當時候，大體是使用記憶體佔申請記憶體75%的時候，就啟動回收執行緒。（關於申請記憶體75% 這個結論，筆者是查了一些資料）

如何保證多執行緒讀寫檔案的安全?
加鎖,可以參考上面的執行緒安全

單例模式的常見寫法和優缺點分析?
懶漢式：
第一次獲取單例類的例項時建立。(優點:寫法簡單，且不存在多執行緒同步問題，避免了synchronized所造成的效能問題；缺點是：初始化類的時候就需要構造例項，（即便你還沒有用到這個例項），因此在某些特定條件下會耗費記憶體。)
餓漢式：
在類被載入的時候建立單例類的物件，類載入器負責載入類，並會保證只有一個執行緒在例項化單例類， (優點：這種寫法比較簡單，就是在類裝載的時候就完成例項化。避免了執行緒同步問題。缺點：在類裝載的時候就完成例項化，沒有達到Lazy Loading的效果。如果從始至終從未使用過這個例項，則會造成記憶體的浪費。)
單例模式個人覺得最經典在專案裡經常使用的寫法（也稱雙重鎖機制）：更多細節可以參考單例模式的8種寫法

單例模式的擴充？
1：使用靜態內部類 實現單例模式

實現單例模式

用SingletonManager 將多種的單例類統一管理，在使用時根據key獲取物件對應型別的物件，程式碼可讀性強。這種方式使得我們可以管理多種型別的單例，並且在使用時可以通過統一的介面進行獲取操作，降低了使用者的使用成本，也對使用者隱藏了具體實現，降低了耦合度。

StringBuffer和StringBuilder的區別?
StringBuilder：執行緒非安全的,但是效率高
StringBuffer：執行緒安全的,效率相對較低
單執行緒操作字串緩衝區下操作大量資料推薦使用:StringBuilder
多執行緒操作字串緩衝區下操作大量資料推薦使用:StringBuffer

陣列和連結串列的區別？
答：二者都屬於一種資料結構
從邏輯結構來看

1. 陣列必須事先定義固定的長度（元素個數），不能適應資料動態地增減的情況。當資料增加時，可能超出原先定義的元素個數；當資料減少時，造成記憶體浪費；陣列可以根據下標直接存取。

2. 連結串列動態地進行儲存分配，可以適應資料動態地增減的情況，且可以方便地插入、刪除資料項。（陣列中插入、刪除資料項時，需要移動其它資料項，非常繁瑣）連結串列必須根據next指標找到下一個元素

從記憶體儲存來看

1. (靜態)陣列從棧中分配空間, 對於程式設計師方便快速,但是自由度小

2. 連結串列從堆中分配空間, 自由度大但是申請管理比較麻煩
   從上面的比較可以看出，如果需要快速訪問資料，很少或不插入和刪除元素，就應該用陣列；相反， 如果需要經常插入和刪除元素就需要用連結串列資料結構了。

執行緒和程式的區別?
程式有獨立的地址空間，一個程式崩潰後，在保護模式下不會對其它程式產生影響，
而執行緒只是一個程式中的不同執行路徑。執行緒有自己的堆疊和區域性變數，但執行緒之間沒有單獨的地址空間，一個執行緒死掉就等於整個程式死掉，所以多程式的程式要比多執行緒的程式健壯，但在程式切換時，耗費資源較大，效率要差一些。但對於一些要求同時進行並且又要共享某些變數的併發操作，只能用執行緒，不能用程式。
1) 簡而言之,一個程式至少有一個程式,一個程式至少有一個執行緒.
2) 執行緒的劃分尺度小於程式，使得多執行緒程式的併發性高。
3) 另外，程式在執行過程中擁有獨立的記憶體單元，而多個執行緒共享記憶體，從而極大地提高了程式的執行效率。
4) 執行緒在執行過程中與程式還是有區別的。每個獨立的執行緒有一個程式執行的入口、順序執行序列和程式的出口。但是執行緒不能夠獨立執行，必須依存在應用程式中，由應用程式提供多個執行緒執行控制。
5) 從邏輯角度來看，多執行緒的意義在於一個應用程式中，有多個執行部分可以同時執行。但作業系統並沒有將多個執行緒看做多個獨立的應用，來實現程式的排程和管理以及資源分配。這就是程式和執行緒的重要區別。

執行緒池的概念以及應用場景?
多執行緒程式設計下如果併發的執行緒數量很多，並且每個執行緒都是執行一個時間很短的任務就結束了，這樣頻繁建立執行緒就會大大降低系統的效率，因為頻繁建立執行緒和銷燬執行緒需要時間。那麼有沒有一種辦法使得執行緒可以複用，就是執行完一個任務，並不被銷燬，而是可以繼續執行其他的任務,執行緒池技術的出現就很好的解決了上面問題,可以更好的提供效能,並有效控制系統中併發執行緒的數量(執行緒池的最大執行緒數引數可以控制系統中併發執行緒數不超過此數)
關鍵字:ThreadPoolExecutor

Session 、Cookie 、Token相關?
Cookie:  它是儲存在本地終端的資料。cookie由伺服器生成，傳送給瀏覽器，瀏覽器把cookie以key - Value 形式儲存到某個目錄下的文字檔案內，下一次請求同一網站時會把該cookie傳送給伺服器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁碟空間，所以每個域的cookie數量是有限的.(Cookie的作用是為了解決HTTP協議無狀態的缺陷所作的努力)

cookie的內容主要包括：名字、值、過期時間、路徑和域。
路徑與域一起構成cookie的作用範圍。
若不設定過期時間，則表示這個cookie的生命期為瀏覽器會話期間，關閉瀏覽器視窗，cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie.會話cookie一般不儲存在硬碟上而是儲存在記憶體裡，當然這種行為 並不是規範規定的。
若設定了過期時間，瀏覽器就會把cookie儲存在硬碟上，關閉後再次開啟瀏覽器，這些cookie仍然有效直到超過設定的過期時間。儲存在硬碟上的cookie可以在不同的瀏覽器程式間共享，比如兩個IE視窗。而對於儲存在記憶體裡cookie，不同的瀏覽器有不同的處理方式。

Session :  session的中文翻譯是“會話”，當使用者開啟某個web應用時，便與web伺服器產生一次session。
簡單的理解就是 : 伺服器要知道當前發請求給自己的是誰。為了做這種區分，伺服器就要給每個客戶端分配不同的“身份標識”，然後客戶端每次向伺服器發請求的時候，都帶上這個“身份標識”，伺服器就知道這個請求來自於誰了。
伺服器使用session把使用者的資訊臨時儲存在了伺服器上，使用者離開網站後session會被銷燬。這種使用者資訊儲存方式相對Cookie來說更安全 . 但是session有一個缺陷：如果web伺服器做了負載均衡，那麼下一個操作請求到了另一臺伺服器的時候session會丟失。

Token: (英譯漢 : 象徵; 記號; 代幣;)
token是使用者身份的驗證方式，最簡單的token組成:uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進位制字串，可以防止惡意第三方拼接token請求伺服器)。還可以把不變的引數也放進token，避免多次查庫

Cookie和Session的區別
1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。
2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙,考慮到安全應當使用session。
3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能,考慮到減輕伺服器效能方面，應當使用cookie。
4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。
5、所以個人建議：
將登陸資訊等重要資訊存放為session
其他資訊如果需要保留，可以放在cookie中

Token 和 Session 的區別
session和 token並不矛盾，作為身份認證token安全性比session好，因為每個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現有狀態的會話，仍然可以增加session來在伺服器端儲存一些狀態
App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來儲存session,因此用session token來標示自己就夠了，session/state由api server的邏輯處理。如果你的後端不是stateless的rest api,那麼你可能需要在app裡儲存session.可以在app裡嵌入webkit,用一個隱藏的browser來管理cookie session.

Session是一種HTTP儲存機制，目的是為無狀態的HTTP提供的持久機制。所謂Session認證只是簡單的把User資訊儲存到Session裡，因為SID的不可預測性，暫且認為是安全的。這是一種認證手段。而Token，如果指的是OAuth Token或類似的機制的話，提供的是 認證 和 授權 ，認證是針對使用者，授權是針對App。其目的是讓 某App有權利訪問 某使用者 的資訊。這裡的Token是唯一的。不可以轉移到其它App上，也不可以轉到其它 使用者 上。轉過來說Session。Session只提供一種簡單的認證，即有此SID，即認為有此User的全部權利。是需要嚴格保密的，這個資料應該只儲存在站方，不應該共享給其它網站或者第三方App。所以簡單來說，如果你的使用者資料可能需要和第三方共享，或者允許第三方呼叫API介面，用Token。如果永遠只是自己的網站，自己的App，用什麼就無所謂了。

token就是令牌，比如你授權（登入）一個程式時，他就是個依據，判斷你是否已經授權該軟體；cookie就是寫在客戶端的一個txt檔案，裡面包括你登入資訊之類的，這樣你下次在登入某個網站，就會自動呼叫cookie自動登入使用者名稱；session和cookie差不多，只是session是寫在伺服器端的檔案，也需要在客戶端寫入cookie檔案，但是檔案裡是你的瀏覽器編號.Session的狀態是儲存在伺服器端，客戶端只有session id；而Token的狀態是儲存在客戶端。

Http,Https相關?
Http: (HTTP-Hypertext transfer protocol)又稱:超文字傳輸協議 , 是一種詳細規定了瀏覽器和全球資訊網伺服器之間互相通訊的規則，通過因特網傳送全球資訊網文件的資料傳送協議。
Https:（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。Https情況下,電腦與伺服器之間收發的資訊傳輸將更加安全。

HTTP協議的主要特點可概括如下：
1.支援客戶/伺服器模式。
2.簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
3.靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
4.無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

加密相關:

採用單鑰密碼系統的加密方法，同一個金鑰可以同時用作資訊的加密和解密(注意:是同一個金鑰)，這種加密方法稱為對稱加密，也稱為單金鑰加密。所謂對稱，就是採用這種加密方法的雙方使用方式用同樣的金鑰進行加密和解密。金鑰是控制加密及解密過程的指令。演算法是一組規則，規定如何進行加密和解密。因此,(" target="_blank">加密的安全性不僅取決於加密演算法本身，金鑰管理的安全性更是重要。因為加密和解密都使用同一個金鑰，如何把金鑰安全地傳遞到解密者手上就成了必須要解決的問題。在對稱加密中，資料傳送方將明文（原始資料）和加密金鑰一起經過特殊加密演算法處理後，使其變成複雜的加密密文傳送出去。接收方收到密文後，若想解讀原文，則需要使用加密金鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的金鑰只有一個，發收信雙方都使用這個金鑰對資料進行加密和解密。

對稱加密演算法的優點    :    演算法公開、計算量小、加密速度快、加密效率高。
對稱加密演算法的缺點    :    在資料傳送前，傳送方和接收方必須商定好祕鑰，然後使雙方都能儲存好祕鑰。其次如果一方的祕鑰被洩露，那麼加密資訊也就不安全了。另外，每對使用者每次使用對稱加密演算法時，都需要使用其他人不知道的唯一祕鑰，這會使得收、發雙方所擁有的鑰匙數量巨大，金鑰管理成為雙方的負擔。
對稱加密演算法中常用的演算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等

非對稱加密:
對稱加密演算法在加密和解密時使用的是同一個祕鑰；
而非對稱加密演算法需要兩個金鑰來進行加密和解密。
這兩個祕鑰是公開金鑰（public key，簡稱公鑰）和私有金鑰（private key，簡稱私鑰）。
公開金鑰與私有金鑰是一對，如果用公開金鑰對資料進行加密，只有用對應的私有金鑰才能解密；如果用私有金鑰對資料進行加密，那麼只有用對應的公開金鑰才能解密。因為加密和解密使用的是兩個不同的金鑰，所以這種演算法叫作非對稱加密演算法。
非對稱加密與對稱加密相比，其安全性更好：對稱加密的通訊雙方使用相同的祕鑰，如果一方的祕鑰遭洩露，那麼整個通訊就會被破解。而非對稱加密使用一對祕鑰，一個用來加密，一個用來解密，而且公鑰是公開的，祕鑰是自己儲存的，不需要像對稱加密那樣在通訊之前要先同步祕鑰。
非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量資料進行加密。
在非對稱加密中使用的主要演算法有：RSA、Elgamal、揹包演算法、Rabin、D-H、ECC（橢圓曲線加密演算法）等。

MD5: 
MD5是一種資訊摘要演算法, 訊息摘要是一種與訊息認證碼結合使用以確保訊息完整性的技術。主要使用單向雜湊函式演算法，可用於檢驗訊息的完整性，和通過雜湊密碼直接以文字形式儲存等，目前廣泛使用的演算法有MD4、MD5、SHA-1。

ANR相關?
ANR全名Application Not Responding, 也就是"應用無響應". 當操作在一段時間內系統無法處理時, 系統層面會彈出上圖那樣的ANR對話方塊.
在Android裡, App的響應能力是由Activity Manager和Window Manager系統服務來監控的. 通常在如下兩種情況下會彈出ANR對話方塊:
A) 5s內無法響應使用者輸入事件(例如鍵盤輸入, 觸控螢幕等).
B) BroadcastReceiver在10s內無法結束.
造成以上兩種情況的首要原因就是在主執行緒(UI執行緒)裡面做了太多的阻塞耗時操作, 例如檔案讀寫, 資料庫讀寫, 網路查詢等等.

Android:

今日頭條螢幕適配的原理？
1：首先計算出 density，計算公式：當前裝置螢幕總寬度（單位為畫素）/ 設計圖總寬度（單位為 dp) = densitydensity 的意思就是 1 dp 佔當前裝置多少畫素計算density 的原因：在佈局檔案中填寫的是什麼單位，最後都會被轉化為 px，系統就是通過上面的方法，將你在專案中任何地方填寫的單位都轉換為 px
但是，今日頭條適配方案預設專案中只能以高或寬中的一個作為基準，來進行適配

簡述Android中的加固和使用平臺?
加固:防止程式碼反編譯,提高程式碼安全性
加固三方平臺,梆梆安全,360加固,愛加密等
區別:梆梆安全,360加固看不到專案中的類,愛加密看的到Java類,單看不到裡面的方法實現體,效果比前面差一點點
加固的底層原理:第三方加固的應用會生成一個Apk,然後把你的APK讀取出來,在封裝到這個第三方應用的APK裡面.

如何對APK瘦身?
1)使用混淆,
2)開啟shrinkResourse(shrink-收縮),會將沒有用到的圖片變成一個畫素點
3)刪除無用的語言資源(刪除國際化檔案)
4)對於非透明的大圖,使用JPG(沒有透明度資訊),代替PNG格式
5)使用tinypng進行圖片壓縮
6)使用webp圖片格式,進一步壓縮圖片資源
7)使用第三方包時把用到的程式碼加到專案中來,避免引用整一個第三方庫

簡述多渠道打包及原理和常用操作?
針對每一個渠道(應用市場)都生成一個帶有渠道標識的apk檔案
原理:使用者下載啟動應用,獲取渠道標識,和裝置的唯一標識,並上傳到伺服器裡面,伺服器這裡就        會根據獲取的記錄,根據渠道號然後判斷是否存在該伺服器的表裡面.(打標記,取標記,上傳標記)
1)友盟多渠道打包:在清單檔案中定義一個佔位符,在gradle指令碼中替換佔位符(會使用到Python)
2)美團打包,在meta-data中建立一個空的檔案,以檔名標識渠道,做一個解壓與壓縮的操作,速度會比較快
3)新一代多渠道打包,將渠道標識新增到.apk檔案的末尾,並不會對原始檔損壞

Android下的資料儲存方式有那些?
1)內部儲存,直接儲存在內部檔案中
2)外部儲存,首先要判斷外部儲存條件是否可用,然後進行儲存
3)SP儲存,底層是Xml實現的,以鍵值對形式儲存內部的資料,適宜於輕量級的儲存,儲存的資料型別有,boolean,String,int
4)資料庫儲存,SQlite儲存,輕量級的資料庫,強大的增刪改查功能
5)內容提供者,ContentProvider,將自己願意暴露的一部分資料供外部使用操作
6)網路儲存,等等

Sharepreference 執行緒安全問題？
官方文件明確指出，SharedPreferences不支援多執行緒，程式也是不安全的
如果想要實現執行緒安全需重新實現其介面，如下

假設在多程式訪問SharePreferences的情況下，該如何保證程式安全和共享資料?

解決辦法就是：將需要共享資料的欄位提出來統一儲存到一個檔案中。

Android開發下如何有效進行螢幕適配?
1:機型適配，去一些統計網站諸如友盟,現在叫友盟+去看一下市場上最流行的Android機型,有針對性的切圖
2:螢幕適配，適配主流xhdpi螢幕尺寸，使用relativelayout，linerlayout等佈局，多使用matchparent，wrapcontent，及配合weight,權重處理，
3:還有就是在程式碼中，設計到具體尺寸的要使用dp2px的轉換，
4:圖片使用可拉伸.9圖片，imageview使用scaletype縮放；
5:使用權重,等比例,百分比佈局等等

物件序列化：
為什麼要序列化？
1）永久性儲存物件，儲存物件的位元組序列到本地檔案中；
2）通過序列化物件在網路中傳遞物件；
3）通過序列化在程式間傳遞物件。
在Android中實現序列化有兩個選擇：一是實現Serializable介面（是JavaSE本身就支援的），一是實現Parcelable介面（是Android特有功能，效率比實現Serializable介面高效，可用於Intent資料傳遞，也可以用於程式間通訊（IPC））。實現Serializable介面非常簡單，宣告一下就可以了，而實現Parcelable介面稍微複雜一些，但效率更高，推薦用這種方法提高效能。兩種實現方式依舊是貼url，方便大家快速查詢
兩種序列化相關
既然Google推薦Parcelable這種序列化，在這裡，推薦一鍵生成序列化的外掛，
在Android Studio裡面搜尋外掛，如下圖，寫起序列化（根本不用你寫）那就是一個美滋滋吶~

OkHttp相關?
OkHttp支援同步和非同步資料請求，但非同步請求是在子執行緒 (因為原生OkHttp的使用時回撥方法是在子執行緒進行的，要重新整理介面還需要用Handler作處理，可以使用第三方的okhttp-utils,Okgo等等)；
OkHttp裡面封裝了執行緒池、資料轉換、GZIP壓縮（減少流量的傳輸）、HTTP協議快取等,
OKHttp優點---使用GZip壓縮減少傳輸的資料量,快取(減少重複請求);
失敗重試(如果你的服務有多個IP地址,如果第一次連線失敗,OKHttp將使用備用地址)
OKhttp是對http協議的封裝,比較底層,因此擴充性強,便於封裝;
OKhttp基於NIO(JDK1.5,非阻塞式IO)效率更高

ButterKnife相關?
簡介：
一款快速高效的注入框架，節約開發時間減少程式碼量（依靠外掛動態生成View,點選事件等等）
優點：
1.強大的View繫結和Click事件處理功能，簡化程式碼，提升開發效率
2.方便的處理Adapter裡的ViewHolder繫結問題
3.執行時不會影響APP效率，使用配置方便
4.程式碼清晰，可讀性強

使用經驗：
1.Activity ButterKnife.bind(this);必須在setContentView();之後，且父類bind繫結後，子類不需要再bind
2.Fragment ButterKnife.bind(this, mRootView);
3.屬性佈局不能用private or static 修飾，否則會報錯，（注意許可權）
4.setContentView()不能通過註解實現。（其他的有些註解框架可以）
原理：利用註解和反射去獲取繫結ViewID,
關於原理詳情可參考筆者的這一篇:Android-定製專屬ButterKnife框架,該文詳細介紹了ButterKnife框架並模仿了一個註解繫結View的框架

Rxjava概念,常用操作符及擴充?
簡介：
一款優雅的非同步框架,代替之前的AsyncTask / Handler / XXX / … 
其強大的操作符和鏈式寫法,執行緒切換等有助於提高開發效率和快速定位Bug
與Retrofit搭配使用更是有意想不到的效果，
底層原理：觀察者模式
等一些相應的部落格
缺點：
1：操作符太多會增加學習成本時間
2：使用不好，容易導致記憶體洩露(解決方式，推薦Rxlifecycle結合Rxjava，規避記憶體洩漏風險)

ANR相關

ANR全名Application Not Responding, 也就是"應用無響應". 當操作在一段時間內系統無法處理時, 系統層面會彈出上圖那樣的ANR對話方塊.
在Android裡, App的響應能力是由Activity Manager和Window Manager系統服務來監控的. 通常在如下兩種情況下會彈出ANR對話方塊:
A) 5s內無法響應使用者輸入事件(例如鍵盤輸入, 觸控螢幕等).
B) BroadcastReceiver在10s內無法結束.
造成以上兩種情況的首要原因就是在主執行緒(UI執行緒)裡面做了太多的阻塞耗時操作,, 例如檔案讀寫, 資料庫讀寫, 網路查詢等等.

如何分析ANR?
ANR產生時, 系統會生成一個traces.txt的檔案放在/data/anr/下. 開發人員可通過adb命令將其匯出到本地 ($adb pull data/anr/traces.txt .)通過分析,我們可以根據具體的日誌檢視Anr原因( 如: 普通阻塞,CPU滿負荷,記憶體洩露 )
更多Anr細節可參考Anr詳解 ,這位筆者非常詳細的介紹了Anr相關內容

Android中那些場景是執行在主執行緒的?
1)Activity生命週期回撥都是執行在主執行緒的.
2)Service預設是執行在主執行緒的.
3)BroadcastReceiver的onReceive回撥是執行在主執行緒的.
4)沒有使用子執行緒的looper的Handler的handleMessage, post(Runnable)是執行在主執行緒的.
5)AsyncTask的回撥中除了doInBackground, 其他都是執行在主執行緒的.
6)View的post(Runnable)是執行在主執行緒的.等等

三級快取:
當我們第一次開啟應用獲取圖片或其它資源時，首先到網路去下載，然後依次存入記憶體快取，磁碟快取，
當我們再一次需要用到剛才下載的這張圖片時，就不需要再重複的到網路上去下載，直接可以從記憶體快取和磁碟快取中找，由於記憶體快取速度較快，我們優先到記憶體快取中尋找該圖片，如果找到則運用，
如果沒有找到（記憶體快取大小有限），那麼我們再到磁碟快取中去找。
只要我們合理的去協調這三層快取運用，便可以提升應用效能,給使用者更好的體驗
三級快取指的是：記憶體快取、本地快取、網路快取。其各自的特點是記憶體快取速度快, 優先讀取，本地快取速度其次, 記憶體沒有該資源資訊就去讀取本地記憶體，網路快取速度較慢(比較物件是記憶體快取和本地快取),假設本地記憶體也沒有,才請求網路獲取。

記憶體洩漏:
當應用內部不再需要某個例項後，但是這個物件卻仍然被引用，這個情況就叫做記憶體洩露(Memory Leak)。安卓虛擬機器為每一個應用分配一定的記憶體空間，當記憶體洩露到達一定的程度就會造成記憶體溢位。

導致記憶體洩露常見原因:
1)靜態變數直接或者間接地引用了Activity物件就會造成記憶體洩露
2)Activity使用了靜態的View(View會持有Activity的物件的引用)
3)Activity定義了靜態View變數???
4)ImageSpan引用了Activity Context
5)單例中引用了Activity的Context(需要使用Application的Context)
6)對於使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源，應該在Activity銷燬時及時關閉或者登出，否則這些資源將不會被回收，從而造成記憶體洩漏。
7)靜態集合儲存的物件沒有及時消除(不使用的時候置為null)
8)在Java中,非靜態(匿名)內部類會引用外部類物件,而靜態內部類不會引用外部類物件
9)在Activity中,建立了非靜態內部類(內部類直接或者間接引用了Activity)的靜態成員變數
10)執行緒包括AsyncTask的使用,Activity退出後執行緒還在執行(執行緒在死迴圈),並且線上程中使用了Activity或view物件(解決方法:不要直接寫死迴圈,可以設定一個布林型別的TAG,當activity推出的時候,設定TAG為False)
11)Handler物件的使用,Activity退出後Handler還是有訊息需要處理(解決方法:在退出activity之後,移除訊息)
12)WebView造成的記憶體洩漏(在onDestory中銷燬)

如何進行記憶體洩露分析?
A: 通過Android Studio 視窗進行分析,檢視記憶體分配情況,如果操作應用是記憶體一直往上漲說明存在記憶體洩露
B: 定位記憶體洩露分析的工具---MAT(Memory Analyzer tool)
C: 使用開源庫LeakCanary快速定位記憶體洩露

Android中的四大元件相關?
Activity:
Activity是一個應用程式元件，提供一個螢幕(狹義的理解就是當前APP的介面)，使用者可以用來互動為了完成某項任務。(點選,登入,跳轉頁面)
Activity中所有操作都與使用者密切相關，是一個負責與使用者互動的元件，可以通過setContentView(View)來顯示指定控制元件(設定佈局檔案)。
在一個android應用中，一個Activity通常就是一個單獨的螢幕，它上面可以顯示一些控制元件也可以監聽並處理使用者的事件做出響應。

Activity四種啟動模式?

Activity的啟動模式指,可以根據實際開發需求為Activity設定對應的啟動模式，從而可以避免建立大量重複的Activity等問題。

1)standard
standard為Activity的預設啟動模式，可以不用寫配置。在這個模式下，都會預設建立一個新的例項。因此，在這種模式下，可以有多個相同的例項，也允許多個相同Activity疊加。(點back鍵會依照棧順序依次退出)
2)singleTop
singleTop模式下,Activity可以有多個例項，但是不允許多個相同Activity疊加。即，如果Activity在棧頂的時候，啟動相同的Activity，不會建立新的例項，而會呼叫其onNewIntent方法。
3)singleTask
singleTask表示只有一個例項。在同一個應用程式中啟動他的時候，若Activity不存在，則會在當前task建立一個新的例項，若存在，則會把task中在其之上的其它Activity destory掉並呼叫它的onNewIntent方法。如果是在別的應用程式中啟動它，則會新建一個task，並在該task中啟動這個Activity，singleTask允許別的Activity與其在一個task中共存，也就是說，如果我在這個singleTask的例項中再開啟新的Activity，這個新的Activity還是會在singleTask的例項的task中。
4)singleInstance
只有一個例項，並且這個例項獨立執行在一個task中，這個task只有這個例項，不允許有別的Activity存在。

BraodcastReceiver:（待補充）
使用了設計模式中的觀察者模式：基於訊息的釋出/訂閱事件模型。
註冊的方式分為兩種：靜態註冊、動態註冊

ContentProvider:(待補充)
外界可以通過ContentResolver介面來訪問ContentProvider(內容提供者)中的資料。Uri 通用資源標誌符（Universal Resource Identifier）Uri代表要操作的資料，Android中可用的每種資源 - 影像、視訊片段等都可以用Uri來表示。ContentProvider共享資料是通過定義一個對外開放的統一的介面來實現的。然而，應用程式並不直接呼叫這些方法，而是使用一個 ContentResolver 物件，呼叫它的方法作為替代。ContentResolver可以與任意內容提供者進行會話，與其合作來對所有相關互動通訊進行管理。當外部應用需要對ContentProvider中的資料進行新增、刪除、修改和查詢操作時，可以使用ContentResolver類來完成，要獲取ContentResolver物件，可以使用Context提供的getContentResolver()方法。

IntentService：
IntentService是Service的子類，比普通的Service增加了額外的功能。IntentService會建立獨立的worker執行緒來處理所有的Intent請求；會建立獨立的worker執行緒來處理onHandleIntent()方法實現的程式碼，無需處理多執行緒的問題；所有請求處理完成後，IntentService會自動停止，開發者無需手動呼叫stopSelf()方法停止Service；

簡述System.exit(0) 、onDestory()、Activity.finish()三者的區別
1)System.exit(0) 是你正常結束程式,kill 掉當前程式,針對的是整個Application
2)onDestory()方法是Activity生命週期的最後一步，資源空間等就被回收了。當重新進入此Activity的時候，必須重新建立，執行onCreate()方法.
3)Activity.finish()當你呼叫此方法的時候，系統只是將最上面的Activity移出了棧，並沒有及時的呼叫onDestory（）方法，也就是佔用的資源沒有被及時釋放。

圖片優化，以及圖片載入框架的使用，如Picasso、 Fresco、Glide等？
1)儘量使用小的圖片,對圖片進行壓縮，bitmapfactory.options圖片配置類，insimplesize進行縮放，設定圖片的編碼方式；對圖片使用軟引用，記憶體不夠時即時釋圖片記憶體；對圖片的複用，三級快取的使用；
即時回收不再使用的bitmap物件；
2)Picasso,不支援gif，快取的是Argb8888的原圖，佔用記憶體較大,圖片的框架使用了OkHttp快取機制,使用Http協議快取,也是非同步載入.
3)Fresco,框架是FaceBook公司推出的,適合批量載入圖片,底層是通過三級快取(2級記憶體,1級磁碟)
載入成功後自動替換成目標圖片
4)glide,Google公司14年推出來的,可以載入GIF圖,也可以根據指定圖片清晰度,底層的原理:為Bitmap維護一個物件池,物件池的目的是通過減少物件的分配,以重用來提高效能.物件池也可以幫助提高滾動的效能。API簡潔易呼叫

Handle相關:
Handler 工作流程基本包括 Handler、Looper、Message、MessageQueue 四個部分。但我們在日常開發中，經常都只會用到 Handler 和 Message 兩個類。Message 負責訊息的搭載，裡面有個target用於標記訊息，obj用於存放內容，Handler 負責訊息的分發和處理。

一般在開發中是怎麼使用 Handler 的？
官方不允許在子執行緒中更新 UI，所以我們經常會把需要更新 UI 的訊息直接發給處理器 Handler，通過重寫 Handler 的handleMessage()方法進行 UI 的相關操作。
Handle使用中就沒什麼需要注意的嗎？
有，Handler 如果設定為私有變數的話，Android Studio 會報警告，提示可能會造成記憶體洩漏，這種情況可以通過設定為靜態內部類 + 弱引用，或者在onDestroy()方法中呼叫Handler.removeCallbacksAndMessages(null)即可避免
Handler 整體工作流程淺析分為以下四個步驟：
非同步通訊準備 => 訊息入隊 => 訊息迴圈 => 訊息處理

A：非同步通訊準備
I：假定是在主執行緒建立 Handler，則會直接在主執行緒中建立處理器物件Looper、訊息佇列物件MessageQueue和 Handler 物件。
需要注意的是，Looper和MessageQueue均是屬於其建立執行緒的。
II：Looper物件的建立一般通過Looper.prepareMainLooper()和Looper.prepare()兩個方法，而建立Looper物件的同時，將會自動建立MessageQueue。
III：建立好MessageQueue後，Looper將自動進入訊息迴圈。此時，Handler自動繫結了主執行緒的Looper和MessageQueue。
B：訊息入隊
工作執行緒通過Handler傳送訊息Message到訊息佇列MessageQueue中，訊息內容一般是 UI 操作。傳送訊息一般都是通過Handler.sendMessage(Message msg)和Handler.post(Runnabe r)兩個方法來進行的。而入隊一般是通過MessageQueue.enqueueeMessage(Message msg,long when)來處理。
C：訊息迴圈
主要分為「訊息出隊」和「訊息分發」兩個步驟，Looper會通過迴圈取出訊息佇列MessageQueue裡面的訊息Message，並分發到建立該訊息的處理者Handler。如果訊息迴圈過程中，訊息佇列MessageQueue為空佇列的話，則執行緒阻塞。
D：訊息處理
Handler接收到Looper發來的訊息，開始進行處理。

擴充

先簡單介紹下你自己？
分析：除了向面試官做簡單的基本自我介紹之外，還需向面試官展現自身對該職業所必須具備的一些自身特質，
比如，面試程式設計師職業需要間接的向面試官表示自己思維嚴謹，對細節的處理，理性思維，假設論證等等；面試產品等職業，需要向面試官通過自己的一些故事間接展現對產品的看法以及獨特的思維個性等等
切入點：自身特質能否符合該職位的預期需求

自己的興趣愛好特長有那些？
在企業和麵試官看來，如果求職者的愛好和應聘的崗位在某些方面恰恰有正向關聯，就會有興趣。面試官也會通過應聘者的興趣愛好來判斷其價值觀是否與企業文化契合，能否很好地融入工作團隊。求職者的回答將有可能為面試加分。
下列興趣愛好所反映出的一些性格和職業方向可供參考：
1．籃球，足球，排球：團隊精神，適用大多數崗位。
2．圍棋，國際象棋：戰略意識，適合市場類或高階職位。
3．閱讀，古典音樂：高雅，適合文職類的職位。
4．旅遊：適應不同環境的能力，快速學習的能力，適合銷售業務類職位。
5．舞蹈：外向，易溝通，適合公關、市場類的職位。

對自己的期望和規劃？
分析：職業發展規劃表面上看是在考察你（求職者）、職位、公司三者之間長期的契合程度，但實際上，這麼大的一個問題完全不是三眼兩語間能夠表達清楚的。面試官（無論HR還是專業部門的）主要是看你回答問題時的思路是否清晰，回答中表現出的工作態度如何，順便看看你是否對公司和職位有足夠的瞭解。所以不管答案如何，最關鍵的就是不能茫然。
切入點：依舊自身特點，對未來期望和規劃需表述清晰，思維敏捷

談談自己的優點和缺點？
先談缺點：
技術行業面試基本是由該崗位未來同事和上司進行。這種面試技術性強，行為問題主要考察就是你是否真心想做這個工作（而不是當跳板或者聽說高薪體面而來）和你性格與文化是否相符。所有答案都應該圍繞這兩點組織（即每個經歷都應迴歸到你通過這個經歷學到什麼，該職位所需關鍵技巧，這些經歷為何讓你想做這個工作，和該經歷體現出你什麼樣的個人風格）。對這個問題因為好的回答而留下好印象很難，
關鍵是避免留下壞印象。

要點以下：
1）避免避重就輕，不要談一個算不得缺點的缺點。比如熬夜會困，或者（待人接物）太客氣等等。
2）避免談非職業缺點，比如有感情潔癖，挑食，不擅長陪女友逛街，做飯經常不懂會煮糊。
3）避免談到無法改善的弱點，比如我算數必須用計算器，我腦子不好用看書不理解。
4）避免談到致命弱點，比如脾氣怪異,不喜歡合作,遲到早退等。

那談什麼最好呢？我認為要點有三：
1）談已經在改正的缺點／有明確計劃來改正的缺點。尤其是你能夠充分論證在近期就可以解決的缺點。
2）談一個利用你的優點改正的缺點，順便帶出一個優點。（這是較高效的溝通技巧）

相對較好的回答：
1）喜歡追求細節導致專案／作業未能按期完成。通過時間管理能力改變工作方式，先完成框架再改善細節得以解決；
2）不知如何拒絕，同事要求幫忙一概攬下，影響自身工作進度。通過多工處理能力設定優先順序，以該優先順序表向求助同事展示自己手上工作，並給其一個自己在何時可以給予幫助的時間估計，讓求助人自行決定是否求助，問題解決
3）對處理同一問題的解決辦法上，由於組員自己的技術偏好和技術構成不一樣容易造成溝通障礙及影響專案計劃，所以,應學會高效和有效溝通方式及工作技巧

End:

本文意在分享面試題目,因是筆者自己整理的一些面試答案,如有不足,也希望大家多多指正(碼字不易,且行且珍惜望收藏望點贊),
感謝文章中動態連結的作者,忠於開源,樂於分享,我想，這才是Android開發的本質及靈魂吧
千里之行，始於足下,希望能和大家一起學習成長,加油！
如果這篇文章對您有開發or學習上的些許幫助，希望各位看官留下寶貴的star，謝謝。

想進阿里嗎？快加入我們的知識星球吧，如下：

如有收穫，歡迎「分享 」

「點贊」「評論 」

　媽媽常教導我，讓我養成良好習慣。這樣長大才能成為一個有用的人。良好的習慣是尊敬師長這樣長大才能成為一個有用的人。良好的習慣是尊敬師長，愛護同學，對人有禮貌；是不粗心，做事情不拖拉；還是愛護公物，不浪費糧食。為什麼呢？因為擁有良好習慣，做一個品德高尚的人，懂得尊重別人，才會得到別人的尊重。我要努力地做到這些。我有一些壞習慣，有時候學習很粗心，把一些會做的題做錯。在生活上，也很粗心，有一次早上起床居然穿反了衣服。我吃飯很慢，有的時候還剩飯。我還起床磨蹭，本來應該迅速地穿好衣服，但是，我總是磨磨蹭蹭地，速度很慢。“我打算在這學期裡，改掉這些壞習慣。早上起來，迅速地穿好衣服，不拖拉。學習不粗心，仔細完成每一道題。吃飯的時候，要很快的把飯吃完，不剩飯。我要從一點一滴做起，逐漸養成良好習慣。我相信自己一定能成為一名品學兼優的好學生！我打算在這學期裡，改掉這些壞習慣。早上起來，迅速地穿好衣服，不拖拉。學習不粗心，仔細完成每一道題。吃飯的時候，要很快的把飯吃完，不剩飯。我要從一點一滴做起，逐漸養成良好習慣。我相信自己一定能成為一名品學兼優的好學生！”　　在上幼兒園以前，我什麼也不會幹，就連穿衣服也是媽媽給我穿好，就要上幼兒園了，這樣可不行，媽媽鍛鍊我要學會自己穿衣服。 　　有一天，媽媽把衣服擺在我面前，開始讓我自己穿。一開始。我又哭又叫就是不穿，還把衣服扔的滿地都是，然後坐在地上開始大哭，等了好長時間，媽媽還是不理我，我只好自己乖乖的把衣服穿好， 一出了房間門，媽媽就笑了起來，再看看我的衣服，毛衣和褲子都穿反了，我趕緊回房間又重新穿了一遍，這次穿好了，拿起外套，可是外套的扣子又扣不上了，釦子可調皮了，好像故意和我作對，我把釦子往釦眼——人類邪惡的根源；愛情——幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話：幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話“親愛的！擦乾你的眼淚，至高無上的愛情已經開啟了我們的眼界，使我們成了它的崇拜者。是它，

　媽媽常教導我，讓我養成良好習慣。這樣長大才能成為一個有用的人。良好的習慣是尊敬師長這樣長大才能成為一個有用的人。良好的習慣是尊敬師長，愛護同學，對人有禮貌；是不粗心，做事情不拖拉；還是愛護公物，不浪費糧食。為什麼呢？因為擁有良好習慣，做一個品德高尚的人，懂得尊重別人，才會得到別人的尊重。我要努力地做到這些。我有一些壞習慣，有時候學習很粗心，把一些會做的題做錯。在生活上，也很粗心，有一次早上起床居然穿反了衣服。我吃飯很慢，有的時候還剩飯。我還起床磨蹭，本來應該迅速地穿好衣服，但是，我總是磨磨蹭蹭地，速度很慢。“我打算在這學期裡，改掉這些壞習慣。早上起來，迅速地穿好衣服，不拖拉。學習不粗心，仔細完成每一道題。吃飯的時候，要很快的把飯吃完，不剩飯。我要從一點一滴做起，逐漸養成良好習慣。我相信自己一定能成為一名品學兼優的好學生！我打算在這學期裡，改掉這些壞習慣。早上起來，迅速地穿好衣服，不拖拉。學習不粗心，仔細完成每一道題。吃飯的時候，要很快的把飯吃完，不剩飯。我要從一點一滴做起，逐漸養成良好習慣。我相信自己一定能成為一名品學兼優的好學生！”　　在上幼兒園以前，我什麼也不會幹，就連穿衣服也是媽媽給我穿好，就要上幼兒園了，這樣可不行，媽媽鍛鍊我要學會自己穿衣服。 　　有一天，媽媽把衣服擺在我面前，開始讓我自己穿。一開始。我又哭又叫就是不穿，還把衣服扔的滿地都是，然後坐在地上開始大哭，等了好長時間，媽媽還是不理我，我只好自己乖乖的把衣服穿好， 一出了房間門，媽媽就笑了起來，再看看我的衣服，毛衣和褲子都穿反了，我趕緊回房間又重新穿了一遍，這次穿好了，拿起外套，可是外套的扣子又扣不上了，釦子可調皮了，好像故意和我作對，我把釦子往釦眼——人類邪惡的根源；愛情——幸福和光明的源泉。我一直在這些思想的舞臺上徘徊。突然我發現兩個身影從我面前經過，坐在不遠的草地上。這是一對從農田那邊走過來的青年男女。農田那邊有農民的茅舍。在一陣令人傷心的沉默之後，隨著一聲長嘆，我聽見從一個肺癆病人的嘴裡說出了這樣的話：“親愛的！擦乾你的眼淚，至高無上的愛情已經開啟了我們的眼界，使我們成了它的崇拜者。是它，

如你有好的文章想和大家分享歡迎投稿，直接向我投遞文章連結即可

最後，國慶福利來了，我們的知識星球已達到1000人了，之前說過到達1000人時將大大幅漲價到169元，為了反饋大家對我們的關注和厚愛，特此維持現價99元最後一天，今天后（今晚 00:00）後將漲到169元，歡迎大家加入我們的知識星球，更多星球資訊參見：

如何進階成為Java和Android架構師？

金九銀十跳槽季如何進階找到合適滿意的工作？

說兩件事

微信掃描或者點選上方二維碼領取Android\Python\AI\Java等高階進階資源

更多學習資料點選下面的“閱讀原文”獲取