我的移動開發春季曆程，文末領取面試資料

尴尬的35歲

不知道是哪個人提出的職場35歲就要面臨被淘汰的定律，因為35歲定律本來就是個僞命題，尤其是在IT行業!

現在年八九百萬的大學生畢業，他們雖然年輕活力，但是很多企業也将之“拒之門外”。

35歲的不要，二十幾歲又拒絕，覺得現在很多中小型企業真的很“矯情”，出不起工資找經驗豐富的人才，也不想給剛畢業大學生一份适合的崗位。

這也是造成很多中小企業壽命隻有3-5年的重要因素之一，因為他們在用人方面真的是一言難盡。

一、Android基礎

Android基礎知識點比較多，看圖。

建議閱讀：

《Android開發藝術探索》

1. Activity

# Activity的四大啟動模式，以及應用場景？

Activity

的四大啟動模式：

• standard

  ：标準模式，每次都會在活動棧中生成一個新的

  Activity

  執行個體。通常我們使用的活動都是标準模式。

• singleTop

  ：棧頂複用，如果

  Activity

  執行個體已經存在棧頂，那麼就不會在活動棧中建立新的執行個體。比較常見的場景就是給通知跳轉的

  Activity

  設定，因為你肯定不想前台

  Activity

  已經是該

  Activity

  的情況下，點選通知，又給你再建立一個同樣的

  Activity

  。

• singleTask

  ：棧内複用，如果

  Activity

  執行個體在目前棧中已經存在，就會将目前

  Activity

  執行個體上面的其他

  Activity

  執行個體都移除棧。常見于跳轉到主界面。

• singleInstance

  ：單執行個體模式，建立一個新的任務棧，這個活動執行個體獨自處在這個活動棧中。

# Activity中onStart和onResume的差別？onPause和onStop的差別？

首先，

Activity

有三類：

• 前台

  Activity

  ：活躍的

  Activity

  ，正在和使用者互動的

  Activity

  。
• 可見但非前台的

  Activity

  ：常見于棧頂的

  Activity

  背景透明，處在其下面的

  Activity

  就是可見但是不可和使用者互動。
• 背景

  Activity

  ：已經被暫停的

  Activity

  ，比如已經執行了

  onStop

  方法。

是以，

onStart

和

onStop

通常指的是目前活動是否位于前台這個角度，而

onResume

和

onPause

從是否可見這個角度來講的。

2. 螢幕适配

# 平時如何有使用螢幕适配嗎？原理是什麼呢？

平時的螢幕适配一般采用的頭條的螢幕适配方案。簡單來說，以螢幕的一邊作為适配，通常是寬。

原理：裝置像素

px

和裝置獨立像素

dp

之間的關系是

px = dp * density
           

假設UI給的設計圖螢幕寬度基于360dp，那麼裝置寬的像素點已知，即px，dp也已知，360dp，是以

density = px / dp

，之後根據這個修改系統中跟

density

相關的知識點即可。

3. Android消息機制

# Android消息機制介紹？

Android消息機制中的四大概念：

• ThreadLocal

  ：目前線程存儲的資料僅能從目前線程取出。

• MessageQueue

  ：具有時間優先級的消息隊列。

• Looper

  ：輪詢消息隊列，看是否有新的消息到來。

• Handler

  ：具體處理邏輯的地方。

過程：

1. 準備工作：建立

   Handler

   ，如果是在子線程中建立，還需要調用

   Looper#prepare()

   ，在

   Handler

   的構造函數中，會綁定其中的

   Looper

   和

   MessageQueue

   。
2. 發送消息：建立消息，使用

   Handler

   發送。
3. 進入

   MessageQueue

   ：因為

   Handler

   中綁定着消息隊列，是以

   Message

   很自然的被放進消息隊列。

4. Looper

   輪詢消息隊列：

   Looper

   是一個死循環，一直覺察有沒有新的消息到來，之後從

   Message

   取出綁定的

   Handler

   ，最後調用

   Handler

   中的處理邏輯，這一切都發生在

   Looper

   循環的線程，這也是

   Handler

   能夠在指定線程處理任務的原因。

# Looper在主線程中死循環為什麼沒有導緻界面的卡死？

1. 導緻卡死的是在Ui線程中執行耗時操作導緻界面出現掉幀，甚至

   ANR

   ，

   Looper.loop()

   這個操作本身不會導緻這個情況。
2. 有人可能會說，我在點選事件中設定死循環會導緻界面卡死，同樣都是死循環，不都一樣的嗎？Looper會在沒有消息的時候阻塞目前線程，釋放CPU資源，等到有消息到來的時候，再喚醒主線程。
3. App程序中是需要死循環的，如果循環結束的話，App程序就結束了。

# IdleHandler介紹？

介紹： IdleHandler是在Hanlder空閑時處理空閑任務的一種機制。

執行場景：

• MessageQueue

  沒有消息，隊列為空的時候。

• MessageQueue

  屬于延遲消息，目前沒有消息執行的時候。

會不會發生死循環： 答案是否定的，

MessageQueue

使用計數的方法保證一次調用

MessageQueue#next

方法隻會使用一次的

IdleHandler

集合。

4. View事件分發機制和View繪制原理

剛哥的《Android開發藝術探索》已經很全面了，建議閱讀。

5. Bitmap

# Bitmap的記憶體計算方式？

在已知圖檔的長和寬的像素的情況下，影響記憶體大小的因素會有資源檔案位置和像素點大小。

像素點大小： 常見的像素點有：

• ARGB_8888：4個位元組
• ARGB_4444、ARGB_565：2個位元組

資源檔案位置： 不同dpi對應存放的檔案夾

比如一個一張圖檔的像素為

180*180px

，

dpi

(裝置獨立像素密度)為320，如果它僅僅存放在

drawable-hdpi

，則有：

橫向像素點 = 180 * 320/240 + 0.5f = 240 px
縱向像素點 = 180 * 320/240 + 0.5f = 240 px
           

如果 如果它僅僅存放在

drawable-xxhdpi

，則有：

橫向像素點 = 180 * 320/480 + 0.5f = 120 px
縱向像素點 = 180 * 320/480 + 0.5f = 120 px
           

是以，對于一張

180*180px

的圖檔，裝置dpi為320，資源圖檔僅僅存在

drawable-hdpi

，像素點大小為

ARGB_4444

，最後生成的檔案記憶體大小為：

橫向像素點 = 180 * 320/240 + 0.5f = 240 px
縱向像素點 = 180 * 320/240 + 0.5f = 240 px
記憶體大小 = 240 * 240 * 2 = 115200byte 約等于 112.5kb
           

# Bitmap的高效加載？

Bitmap的高效加載在Glide中也用到了，思路：

1. 擷取需要的長和寬，一般擷取控件的長和寬。
2. 設定

   BitmapFactory.Options

   中的

   inJustDecodeBounds

   為true，可以幫助我們在不加載進記憶體的方式獲得

   Bitmap

   的長和寬。
3. 對需要的長和寬和Bitmap的長和寬進行對比，進而獲得壓縮比例，放入

   BitmapFactory.Options

   中的

   inSampleSize

   屬性。
4. 設定

   BitmapFactory.Options

   中的

   inJustDecodeBounds

   為false，将圖檔加載進記憶體，進而設定到控件中。

二、Android進階

Android進階中重點考察

Android Framework

、性能優化和第三方架構。

1. Binder

# Binder的介紹？與其他IPC方式的優缺點？

Binder是Android中特有的IPC方式，引用《Android開發藝術探索》中的話(略有改動)：

從IPC角度來說，Binder是Android中的一種跨程序通信方式；Binder還可以了解為虛拟的實體裝置，它的裝置驅動是/dev/binder；從

Android Framework

來講，Binder是

Service Manager

連接配接各種

Manager

和對應的

ManagerService

的橋梁。從面向對象和CS模型來講，

Client

通過Binder和遠端的

Server

進行通訊。

基于Binder，Android還實作了其他的IPC方式，比如

AIDL

、

Messenger

和

ContentProvider

。

與其他IPC比較：

• 效率高：除了記憶體共享外，其他IPC都需要進行兩次資料拷貝，而因為Binder使用記憶體映射的關系，僅需要一次資料拷貝。
• 安全性好：接收方可以從資料包中擷取發送發的程序Id和使用者Id，友善驗證發送方的身份，其他IPC想要實驗隻能夠主動存入，但是這有可能在發送的過程中被修改。

學習交流

如果你覺得自己學習效率低，缺乏正确的指導，可以加入資源豐富，學習氛圍濃厚的技術圈一起學習交流吧！

群内有許多來自一線的技術大牛，也有在小廠或外包公司奮鬥的碼農，我們緻力打造一個平等，高品質的Android交流圈子，不一定能短期就讓每個人的技術突飛猛進，但從長遠來說，眼光，格局，長遠發展的方向才是最重要的。

35歲中年危機大多是因為被短期的利益牽着走，過早壓榨掉了價值，如果能一開始就樹立一個正确的長遠的職業規劃。35歲後的你隻會比周圍的人更值錢。

群内有許多來自一線的技術大牛，也有在小廠或外包公司奮鬥的碼農，我們緻力打造一個平等，高品質的Android交流圈子，不一定能短期就讓每個人的技術突飛猛進，但從長遠來說，眼光，格局，長遠發展的方向才是最重要的。

35歲中年危機大多是因為被短期的利益牽着走，過早壓榨掉了價值，如果能一開始就樹立一個正确的長遠的職業規劃。35歲後的你隻會比周圍的人更值錢。