Willy's Fish教學筆記』

年關過後是大家的換工作潮

在這波浪潮裡沉浮的我

經歷過快一個月的面試後，決定把這些遇到的問題記下來

加強印象的同時，也可以幫到找工作的朋友們

希望各位看倌們都能順順利利找到心儀的工作囉!

===========================================

1、Context 是什麼？
Activity 和 Service 都是繼承 Context 來的，Context 可以說是一個 Application 的靈魂，可以代表這個 App 與別的 App 溝通，很多的功能都可以透過 Context 來取得，宣告在 App Context 的變數也可以說是 App 的全域變數。

2、Android 四大組件與用途 資料：Activity, Service Broadcast, ContentProvider
a、Activity
可說是 Android 的核心元件，是 App 與使用者互動的基礎介面

b、Service
一般來說都是在講 Background 的 Service 是一個無介面、生命週期長，適合用來連續處理事情的一個元件。

但因為 Android 對資安的要求，權限的取得越來越嚴格，之後可能會偏向於使用 Foreground ( 使用者知情-icon、不會被回收 )來進行開發。

若要偷偷運行在背景的話，就需要一個「保活」的技巧 ( 提高權重、復活 ) 來達成，Android 7 以上只能盡力一段時間。

2018 Google 推了 WorkManager 可以更簡單的來進行後台工作，點我看介紹

c、Broadcast
Android 裡預設的溝通模式，就像以前的收音機一樣，利用 intent 去發送訊號，並且訂義相應的 Action 頻道讓 Receiver 去接收，Adnroid 很多開放的功能都是這種模式 ( 打電話、聯絡人…等 )，要注意的是 Broadcast 生命只有 10 秒，若做超過的事會發生 ANR。

d、ContentProvider
這是一個統一的資料接口元件，將自己可供人讀取的資料包住，讓別的 App 能存取。例如：通訊錄要給不同 App 讀取時就會包在此類

3、Activity & Fragment 生命週期 ( 各階段作用 ）圖片來源

a、onCreate ( onAttach, onCreateView, onActivityCreate )
建立 Activity：可執行一次性的基本啟用邏輯，且有saveInstanceState可以取得舊資料

b、onStart
顯示給用戶可見：建立 onStop 所釋放的資源

c、onResume
可與用戶互動：恢復 onPause 釋放的資源，或需要每次進來就初始化的動作

d、onPause
部份可見：做一些系統資源的釋放 ( GPS、相機…等 ) ，以達省電效果。

e、onStop => onRestart => 接到 onStart
隱藏：檢查並釋放資源，以避免 memory leak，onPause 中 heavy-load 的工作應該移到 onStop 來做。

f、onDestroy ( onDestroyView, onDestroy, onDetach )
銷毀：這裡可以做最後確認 memory leak 的可能性，注意有些極端情況 onDestroy 可能不會執行

===額外的===
g、onStart => onRestoreInstanceSave
雖然 onCreate 也能取到 saveBundle ,但此方法只會在需要恢復狀態的時候 invoke 所以不用判斷 bundle == null

h、onStop => onSaveInstanceSave
保存狀態值進一個 bundle 中

4、生命週期的進階 ( A轉B、反轉螢幕...)
a、A轉B
A onPause, B onCreate, B onStart, B onResume, A onStop

b、反轉螢幕
若在沒設 configChanges 的情況下，先銷毀再重建
onPause, onStop, onDestroy, onCreate, onStart, onResume

c、反轉螢幕2  (官方configChanges資料)
configChanges = orientation | keyboardHidden | screenSize
只執行 onConfigurationChanged 方法，可在此做相關調整。

5、反轉螢幕的保存：
若不設定 configChanges 在銷毀後重建的情況下如何保存資料
    利用 onSaveInstanceState() 來保存
    並以 onRestoreInstanceState() 來讀取

6、Manifest.xml 的作用
定義了很多要向系統告知的訊息
例如： App name, 入口 Activity, 申請權限…等。

7、Activity 啟動模式 & 應用場景 ( 4種 )  資料

a、Standard
無論如何新加一個實例

b、SingleTop
若任務棧頂端已有實例，調用onNewIntent復用，可應用在推播啟動上，例如：Line 點開訊息推播後，再點另一則，就直接復用聊天室 UI。

c、SingleTask
若任務棧中已有實例，調用onNewIntent復用，且會刪除壓在目標實例上面的其它實例，可應用在首頁性質的 UI，跳到首頁時清除之前壓在首頁上的 UI。

d、SingleInstance ( 沒用過 )
每次新加一個實例時，都會新加一個任務棧存放，他會獨佔這個任務棧且是全局一起複用的，可應用在打電話的畫面，不管從哪呼叫打電話，整個手機系統中就只有一個打電話的實例。

* 關於 View 的流程管理，2018 google 推 navigation 可以有效的管理，點擊看資料

8、Handler 的用途與使用注意事項

Handler 效果有點類似 RxJava，是一個異步操作的類，我們可以用 Handler 來避免 Main Thread 堵塞，Handler 會把資料塞進 MessageQueue 裡面，然後 Looper 會把 Queue 的值不斷的取出來做處理。

Handler 有做 synchronized 以防多執行緒存取
Looper 裡面是一個無窮迴圈來取 queue 的值

要注意 Handler 若宣告為 inner class 時有可能會 memory leak，想解決可以加上 static 關鍵字，因為 static 可以打破『鏈式引用』( 持有外部類的引用 )。

在 Kotlin 裡，可以使用 coroutines 來做到防 Main Thread 堵塞

9、Handler VS AnycTask 的差異
可以說我們若只想簡單的執行 background 作業，用 AnycTask 就可以，它內部也是以 Handler + Thread 回傳 msg 的方式達到目的，但由於它會抓著外面的 Activity 所以不適合做長時間的作業，怕 Activity 若消毀，作業尚未結束就會造成 memory leak，反之作業結束則會找不到 UI 產生 View not attached to window manager 的 exception。

10、內存溢出 ( OOM )、洩漏 ( Memory Leak ) 的差異，資料
Memory Leak：資源未釋放 ( Connection, Cursor… 等 )
Out of Memory：太多 Memory Leak 導致不夠用，或是像大圖那種需要大量 Memory 的情況

11、Android 常見的 Memory Leak 資料

a、Static Activity：static 變數是貫串整個 APP 的生命周期的，所以若抓著的 Activity 結束前沒有清掉，就會造成 memory leak。
 

b、Static View：和 Activity 類似情況。
 

c、Inner Classes：內部類的優點是可以存取外部類，但它會強引用外部類，所以容易造成 Memory leak。
 

d、Anonymous Classes：匿名內部類也一樣會引用外部類，假設有個 AnycTask 還沒執行完，它抓著的 Activity 就不會被釋放。
 

e、Handler：同匿名類別，當 MessageQueue 還沒處理完，Activity 不會釋放。
 

f、Thread、TimerTask：只要是匿名類，不論在哪個 Thread 都會持有Activity 的引用。

12、Memory leak 和 Out of memory 的解決方法為何？
需釋放的資源可在 onStop 進行檢查並釋放，注意物件的生命週期與使用情況，而像大圖這種大量使用 Memory 的情況，可以用 LruCache 來控制使用量。

13、Service vs IntentService
Service 不能做長時間的事情，需要在另一個 Thread 去操作，而 IntentService 則可以省去 Thread 的動作，並且可以重覆呼叫 IntentService ( 單例 )，他會排進一個 queue 裡，用 onHandleIntent 去處理，最後會自動 onDestroy，Service 要手動。

14、JobScheduler & JobIntentService
Android 8 之後，後台權限的管制變嚴格，JobService 會透過 JobScheduler 去發送分配任務，而 JobIntentService 與 JobService 的關係就像 Service 與 IntentService，JobIntentService 會處理掉 JobScheduler 的部份，讓我們專心覆寫 onHandleWork 即可。

15、Service 生命週期  詳請參考此資料
IntentService 塞 2 個任務時的週期，在 onHandleIntent 處理 Queue 的任務
onCreate -> onStartCommand -> onStart -> onStartCommand -> onStart -> onHandleIntent ( 1 ) -> onHandleIntent ( 2 ) -> onDestroy

16、Android ANR exception 資料
Application Not Responding 發生因原通常是在 main thread 做耗時操作。這裡可以用 Trace File 來追蹤 ( /data/anr/traces.txt )，裡頭會記錄發生問題的 Thread 做了什麼事而導致 Exception

17、i18n 是什麼
國際化，internationalization and localization 的簡寫，i18n 代表字母長度

18、Dependency Injection 是什麼
從物件外部注入資源，像是 setter、construct 都算是，目的是為了降低耦合度

19、物件導向 ( OO ) 的概念

a、設計基礎：封裝、繼承、多型、抽象

b、設計目的：可擴充 ( 繼承、增加功能 )、可修改 ( 物件間不影響 )、可替換 ( 使用不同物件、低耦合)

c、實際工作上，擁有好的物件概念，可以讓工作伙伴只要看我們提供的方法就可以知道物件怎麼使用。

20、Git 經驗分享，flow
a、Git Flow：分為 Master、Hotfix、Develop、Feature。

b、GitHub Flow：只有 Master & Freture 的用法

c、GitLab Flow：2014才出現，補足上一個的不足，多了 Production 或是測試環境的分支

21、Java 使用 String pool 的原因
a、節省資源：若 pool 中已有 “abc”，String str2 = “abc”，會重用 pool “abc”

b、比對效率：一般比對會一個個字元去比，pool 的存在只要比對是否同實例

22、View 重疊的 Touch 處理方法 資料
onDispatchTouchEvent 負責分發事件
若 return
『True => onTouchEvent』
『False => onInterceptTouchEvent』

onInterceptTouchEvent 負責攔截事件 ( ViewGroup 特有的method )
若 return
『True => ViewGroup.onTouchEvent』
『False => 子類.onDispatchTouchEvent』

最後到子類的 onTouchEvent 還是沒有被消費則會傳到 父類.onTouchEvent

23、為何要了解 Design patterns
除了教科書寫的各 patterns 的優缺點之外，也為了讓伙伴之間更容易讀懂程式

24、常見 Design patterns ( 共 23 種 ) 資料

a、觀察者模式：適合在一對多的情況，目標異動的話，call 訂閱者的 method 進行通知，像 RecyclerView.notifyDataSetChanged。
 

b、Singleton：一些較耗資源的物件，可以 new 一個實例供大家使用。就像 getSystemService 就是返回單例物件
 

c、Factory：定義一個創建接口 ( 工廠 )，讓外面來決定要 new 哪個類 ( 產品 ) getSystemService 就是依參數來決定 retrun 的 class
 

d、Builder：若創建實例需要很多參數，且依據順序or設置不同時會有不同結果時使用。就像 Dialog 在 set title msg…後才調用 Builder.create
 

e、Adapter：為了使兩個類可以合作，所以定義自己的接口讓兩方能互動。最常用的就是 RecyclerView
 

f、Prototype：屬性多且常要拷貝的物件適合此模式，有些物件有 clone method 就是此模式。 像 Intent.clone()

25、Singleton 優缺：
Singleton 的定義是「保證只有一實例，並提供一個全局訪問點」

優點：頻繁創建時、需大量建立資源時，可以省效能。

缺點：頻繁變化的對象不適用，若被 GC 後可能造成狀態丟失。

26、private, public, protect 放在 class 上的功用
基本上和放在 method, field 是一樣的，但 private 通常出現在 inner class 上，無宣告的話預設 protect

27、ListView vs RecyclerView
官方有加強 RecyclerView 重用 View 的效能，和記憶體管理優化，讓使用者專注於 UI 的開發，而且可自訂性較高。

28、使用什麼類做 UI Auto Test ，與其測試目的
Espresso，檢查流程是否正確

29、Android 佈局種類與使用時機

a、Coordinatorlayout：Behavior 是與 RelativeLayout 的差異點，可以監聽其它行為來改變自己的狀態，例如：滾動事件、配合其它 View 做變動…等。

b、RelativeLayout、ConstraintLayout：是用元件之間的關係來組成 UI

c、LinearLayout：以橫豎的方式堆疊排列元件

d、FrameLayout：堆疊方式的 Layout，最後一個加入的 View 在最上層

e、GridLayout ( 少用 )：格狀的 Layout

f、TableLayout ( 少用 )：表格狀的 Layout

g、AbsoluteLayout ( 已棄用 )：透過 x,y 來指定位置。

30、Jar跟Aar的差別是什麼？

Jar 只包 Class文件 與 清單文件，Aar 更包含了 res 的全部文件，所以如果我們要包的是一個 UI 庫，有一些自己寫的控件布局文件、字體文件…等，就只能用 Aar。

31、Map set list 差異 satay hash 衝突解方

ListArray：取值快，塞值有預設10個格子，沒了若加在中間，要用一個新 Array 搬過去。

LikedList：取值從頭找，塞值直接判斷位置。

TreeMap、TreeSet：Tree 有排序，Map 一組 Key,Value 的格式，Set 有不可重復性。

HashMap、HashSet：以 Hash 為判斷，當 Hash 重復時，我們可以改變 hasHash、equals 這兩個 method 來做為不重復的標準

32、對稱、非對稱，Aes 加密
對稱：加解密都是同把 key ( AES ：後面的數字是位元數 )
非對稱：分為公鑰加密、私鑰解密，安全性較高 ( RSA )

33、中間人攻擊 ( Man-in-the-middle attack，縮寫：MITM )：

攻擊者將自己偽裝成終端，攔截通訊雙方的通話並插入新的內容。中間人攻擊是一個『缺乏』相互認證的攻擊，SSL、Auth 可以防止攻擊。

34、RestfulAPI CRUD 動詞+賓語 資料
RestfulAPI 是一種定義好的設計風格，遵守這些原則能讓 API 更簡潔易懂，賓詞需為名詞，GET：讀取（Read） 、POST：新增（Create）、PUT：更新（Update）、PATCH：更新（Update 通常是部分更新)　、DELETE：刪除（Delete）

35、Android 3.0 Google 推出 Fragment 的原因，為什麼要用 Fragment 圖源

a、模組化：可以把邏輯寫在各 Fragment 中，不用全寫在 Activity。

b、可重用：多個 Activity 可以重用同個 Fragment。

c、螢幕適配性：Android 3.0 後引入了平板使畫面變大，Fragment 可以方便用區塊性的組合來設計出適合的 UI，以加強用戶體驗，下方的圖就是經典例子

36、View 的繪制原理  資料
繪制有三個步驟 onMeasure、onLayout、onDraw，皆由從 ViewGroup 往 View 執行。

Measure：測量 View 的大小

Layout：將 View 依上下左右的四個點確認在 Layout 的位置

Draw：先繪制背景 Canvas 再繪制自己，然後才是子 View 和 DecorView ( Decor 例如: ScollBar )

37、Android Jetpack
這是一個 2018 Google 為了提高開發效率而誕生的組件，包含很多，有後台管理的 WorkManager、生命週期的 Lifecycles、SQLite訪問的 Room …等。

38、v4、v7 的差別
這是 Android 在做版本兼容性所提出的包
2011 年推出 v4 能夠向下兼容至 Android 1.6
2014 年推出的 v7 依賴於 v4 做改動，可向下兼容至 Android 2.1
2018 年的 AndroidX 主要是解決整個 support 庫的亂象，統一命名處理，之後的新功能只會在 AndoridX 釋出

39、A/B Testing
當我們有新功能或大改版的時候，可以發佈給部份使用者使用，以取得市場回饋，來決定是否發佈或如何改善。 而 Fabric 可以幫助我們去挑選這些部份使用者。

40、Material Design
Google 於 2014 年提出的 UI 設計模式，主要著重於「實體感」、「層次感」與「互動感」的體驗。

41、Monkey Test
這是一套 Android 原生的壓力測試工具，特色就是像隻猴子一樣亂按，我們無法控制他的行為，所以才能測出一些意想不到的 Bug

42、Flutter
這是 Google 在 2017 就提出的開源跨平台開發引擎，目的是利於快速開發雙平台，和 Facebook 的 React Native 競爭，在 2018 推出 1.0 版

43、Kotlin Volatile
這個關鍵字用於多線程，可以當作是「輕量化的 synchronized」。

44、Kotlin inline
內聯函數，利用編譯為基本類來節省資源

45、Kotlin vs Java

a、Null Safety

b、Extension

c、Coroutines

d、Smart Casts

e、Range Expressions

f、Companion Object

g、寫法簡潔

46、為什麼 Kotlin 和 Java 相融
Kotlin 也是一種靜態語言，他會編譯成 byte code 然後在 jvm 上面運行，和 java 一樣，所以才能和 java 配合

47、Intent implicit VS explicit 

a、implicit 利用 action, category, data 去選擇開啟哪一個

b、explicit 明確指定要開啟哪個 Activity

48、Fragment 要如何以 back 回到上一個 Fragment

a、可用 addToBackStack 來記錄 Fragment 的操作行為

b、Navigation 就可以做到 view 很好的流程控制

49、threadpool VS thread 哪個有效益

ThreadPool 會比較有效益，因為 Thread 在開啟和關閉時其實都會消耗一點資源，所以會優先選擇讓 Pool 去管理 Thread

a、pool 有預先 new 好的 therad 有點像正職員工，做完了接下一個任務，所以有一個 queue

b、therad 就是一個個任務結束就

50、Fragment VS Activity 應用場景

a、Activity 可以說是 ui 基本的的元件，也只有他才能接受 intent 的調轉

b、Fragment 離不開 Activity，他可以做到 view 重用，螢幕適配性等功能

51、Serializable VS Parcelable

ａ、都是用來做序列化用於數據傳輸

ｂ、s 比 p 還消資源，在序列化 & 反序列化的過程需要很多 I/O 操作

ｃ、p 適合用於 Android 內部傳輸

ｄ、s 適合用於網路傳輸 & 持久化本地儲存

52、MVC、MCP、MVVM 的差別
http://0rz.tw/MJqbg

53、什麼時候用 MVC 什麼時候用 MVVM
依照專案的規模來決定，太小規模的專案，會產生大量無用的 code，雖然說可擴性高，但因為小規模，擴充機會較小

54、ViewModel 辦演的角色與功能

a、知道資料從何而來，該去哪兒的一個傢伙

b、暫儲存數據，就算 Activity 轉向銷毀重建依然還可以使用

c、Activity、Fragment 之間的資料通訊

55、為什麼要用 AndroidViewModel 圖片來源

參考上圖，由於 VM 的生命周期較長， Activity 轉向銷毀重建後 VM 還會是之前的 instance 只有調用 Activtiy.finish() 才會跟著調用 ViewModel.onCleared，所以 VM 別持有 Activity 才不會產生 memory leak，需要 Context 的時候用 AndroidViewModel 就可以了

56、Kotlin Data Class VS Class
Data Class 會自動的創建這些 eqauls、hashCode、toString、componentN、copy

57、AIDL (Android Interface Definition Language)
主要是用來對不同 app 之間的溝通，透過定義接口之後，可以做到資訊甚至方法的共享。

58、Android 各版本重大差異 

3.0 出現平版，引入 Fragment

6.0 取得權限需要使用者同意

8.0 後台管制，Background Service 生存不易

9.0 Dooz model 省電模式