Activity：

• 生命周期：
• 啟動模式： 
  
  • standard、singleTop、singleTask、singleInstance
  • 任務棧：前臺任務棧、后臺任務棧
  • TaskAffinity + singleTask
  • 使用adb查看任務棧信息
• 啟動方式： 
  
  • 顯式：intent.setClass()
  • 隱式：設置過濾信息：action、category、data類別，且同時匹配上述三類
• 四種狀態： 
  
  • Active/Runing： 它處于可見并可和用戶交互的激活狀態。
  • Paused： 仍然可見，但它已經失去了焦點故不可與用戶交互。比如當 Activity 被另一個透明或者 Dialog 樣式的 Activity 覆蓋時的狀態。
  • Stoped： 當 Activity 被另外一個 Activity 覆蓋、失去焦點并不可見時處于 Stoped 狀態。
  • Killed： Activity被系統殺死回收或者沒有被啟動時處于 Killed 狀態。

Service：

• 生命周期：

• 如何提高service的生存率？

1. 在onStartCommand()中使用startforegound，將service變成前臺進程（詳見android的集中進程等級）
2. 在onStartCommand中return sart_sticky
3. 注冊靜態BroadcastReceiver，監聽系統廣播，然后判斷Service狀態
4. 守護進程

BroadcastReceiver：

• 普通廣播、
• 系統廣播：系統內置的一些廣播，比如監聽網絡變化、打開相機等等
• 有序廣播： 
  
  • 接收者按照預先聲明的優先級依次接收Broadcast；
  • 可以把數據存入結果對象中，傳遞給下一個接收者；
  • 可以被一種某一個接收者終止。
• 本地廣播（APP內）

ContentProvider：

---

Android進程（等級）

1. foreground process 前端進程

前端進程就是目前顯示在屏幕上和用戶交互的進程

比如說：

1. 頂層可交互的activity（已執行onResume）；
2. 有個Service，并綁定到跟用戶正在交互的activity；
3. 在Service里調用了startForground函數；
4. 正在執行onReceive函數的BroadCastReceiver

visible process 可見進程

沒有任何前臺組件,但是仍然能影響用戶在屏幕上看到東西。 
比如：

• 如果一個activity在一個對話框運行之后仍然是可視的；
• 輸入法的彈出時。

Service process 服務進程 
服務進程不會直接為用戶所見 
比如在后臺播放mp3或者從網上下載東西

background process 后臺進程 
比如：Activity執行了onStop

empty process 空進程

---

數據持久化

SQLight：

- SQLite是一個輕量級的數據庫，支持基本的SQL語法
- SQLiteDatabase的類，封裝了一些操作數據庫的api
    1. context.openOrCreateDatabase()方法創建SQLiteDatabase實例
    2. SQLiteDatabase實例調用insert()方法插入數據
    3. 調用query()方法查詢數據
    4. 調用execSQL()方法執行SQL語句 

	
	

		1
	

	

		2
	

	

		3
	

	

		4
	

	

		5
	

	

		6
	




	
	

		1
	

	

		2
	

	

		3
	

	

		4
	

	

		5
	

	

		6
	

SharedPreference：

- 是一種輕量級的數據存儲方式，采用簡直對的方式來存儲數據。
- 其本質就是一個xml文件，一般位于/data/data/包名/shared_prefs/目錄下。
- 由于內存中存在sharedPreference文件的緩存，所以在多進程的環境下，系統對它的讀寫不可靠。因此不建議用在IPC中 

	
	

		1
	

	

		2
	

	

		3
	




	
	

		1
	

	

		2
	

	

		3
	

ContentProvider：

- Android系統中能實現不同應用間共享的一種數據存儲方式。例如音頻，視頻，圖片和通訊錄，一般都可以采用此種方式進行存儲
- 每個Content Provider都會對外提供一個公共的URI，應用程序通過這個URI來對數據進行操作。
- Content Provider天生支持跨進程訪問，因此可以用于IPC 

	
	

		1
	

	

		2
	

	

		3
	




	
	

		1
	

	

		2
	

	

		3
	

Android應用程序之間是通過哪些方式共享數據的？

File，Sqlite，Content Provider，BroadCast Receiver，Intent，同個Application內部的話還可以通過靜態變量共享數據。

---

webView

加載

1. 提高渲染的優先級

webSettings.setRenderPriority(RenderPriority.HIGH);

把圖片加載放在最后來加載渲染

webSettings.setBlockNetworkImage(true);

使用硬件加速，該功能在Android 3.0 (API level 11)才加入。 
硬件加速可以在一下四個級別開啟或關閉：Application、Activity、Window、View 
比如，在AndroidManifest.xml中添加android:hardwareAccelerated屬性；關閉view的硬件加速myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

開啟緩存 
設置websetting

js和java對象交互

1. 獲取webview控件的websetting
2. 設置websetting.setJavascriptEnabled( true )

3. 將一個對象暴露給JavaScript：webview.addJavascriptInterface。這個對象包含了JS調用的方法，這些方法用@JavascriptInterface修飾

4. JS通過這些方法與Android交互

防止OOM

1. 在代碼中動態地將webview設置到布局中，而不是直接寫到xml文件中；
2. 在Activity的onDestory中銷毀webview

---

線程相關

Linux線程基礎

• 線程與進程的區別
• 線程同步
• Linux線程通訊方式

ANR

- what
    - Activity 5s內無響應，BroadcastReceiver 10s內無響應
    - /data/anr/traces.txt 文件記錄了ANR的信息
- why
- how 

	
	

		1
	

	

		2
	

	

		3
	

	

		4
	

	

		5
	




	
	

		1
	

	

		2
	

	

		3
	

	

		4
	

	

		5
	

耗時任務或者線程間通訊

• AsyncTask 
  
  • 本質上是對 ThreadPool 和 Handler 的一個封裝
  • 默認是串行的執行任務，可以調用executeOnExecutors()方法并行執行任務
• Handler
• IntentService

Handler

• Handler + MessageQueue + Looper

MessageQueue本質上是一個單鏈表，不是Queue。采用FIFO方式管理，enqueueMessage()方法是將消息插入一條隊列，next()方法是一個無限循環的方法。如果有消息，則取出，如果沒有，就阻塞。

• HandlerThread

本質上是一個繼承了Thread的線程類。 
通過創建HandlerThread**獲取looper對象，傳遞給Handler對象，執行異步任務。在HandlerThread中通過**Looper.prepare()來創建消息隊列，并通過Looper.loop()來開啟消息循環。創建HandlerThread后必須先調用start()方法，才能調用getLooper()獲取Looper對象。

HandlerThread封裝了Looper對象，使我們不用關心Looper的開啟和釋放的細節問題。如果不用HandlerThread的話，需要手動去調用Looper.prepare()和Looper.loop()這些方法。

IntentService

• 原理：IntentService是一個抽象類，封裝了HandlerThread和Handler，負責處理耗時的任務。任務執行完畢后會自行停止。在onCreate()方法中開啟了一個HandlerThread線程，之后通過HandlerThread的Looper初始化了一個Handler，負責處理耗時操作。通過startService()方法啟動，在handler中調用抽象方法onHandleIntent()，該方法執行完成后自動調用stopself()方法停止

• override onHandleIntent() 方法

• 優點：一方面不需要自己去創建線程，另一方面不需要考慮在什么時候關閉該Service

OOM

• what 
  OOM 和 內存泄漏 的區別

• how

• 靜態變量持有Activity或Context對象
• 非靜態內部類的實例（默認持有外部類的引用）
• 資源未關閉：file、stream、bitmap等

Handler造成OOM

• 原因：使用（匿名）內部類實例化handler，默認持有context引用
• 避免：靜態內部類、Activity在onDestroy的時候，清空handler未處理的消息

WebView造成OOM

---

View相關

三部曲

三個核心步驟：Measure、Layout、Draw

Touch分發機制

重要

滑動沖突

簡述Activity、Window、WindowManager、View、ViewRootImpl的作用和相互之間的關系

• Activity不負責視圖的控制，而是交給Window。這個Window本質上是一個PhoneWindow，被windowmanager管理。

• Window中有decorview，decorview是當前視圖的底層View，是setContentView所設置View的父View 
  View是所有控件的基類。

• ViewRoot對應ViewRootImpl，它是連接WindowManager和DecorView的紐帶。繪制的三大流程都是在ViewRootImpl中完成的：從ViewRootImpl中的performTraversals開始，有三個方法performMeasure, performLayout, prformDraw分別對應measure，layout，draw三個流程，完成對頂級View的繪制。

• 在父View的Measure過程中，會調用子View的Measure過程，如此反復，完成對整個View樹的遍歷。同理，在Layout和Draw中也是如此。

RecyclerView

• 優點：

• 封裝了ViewHolder
• 與ListView相比，耦合性更低、更加靈活：根據viewType設置不同的布局
• 設置LayoutManager，實現ListView的功能和GridView的功能（支持 LinearLayoutManager 和 GridLayoutManager）
• 支持局部刷新：notifyItemChanged()方法 （Listview用的BaseAdapter只有notifyDataSetChanged()方法）

缺點：

• 使用更加復雜
• 沒有onItemClickListener()、setOnItemLongClickListener()方法，只有OnItemTouchListener()方法

RecyclerView.Adapter

• onCreateViewHolder()方法：產生一個ViewHolder對象，該對象中封裝了view
• onBindViewHolder()方法：根據傳入的ViewHolder對象，顯示數據
• getItemViewType()方法：根據情況，返回不同的viewType，方便后續顯示不同的布局和業務處理

---

IPC

Linux中IPC的方式：命名管道、信號量、共享內存

基礎

• 開啟多進程的方式：給四大組件在Menifest文件中，添加process屬性，指定進程名稱
• Android為每個進程分配一個獨立的虛擬機，有不同的Application和地址空間。
• 不同進程訪問同一個類的對象會有不同的副本。因此靜態成員和單例模式失效、線程同步失效、sharedPreference可靠性降低。

序列化

• Serializable接口：Java的序列化接口，使用簡單，但開銷大，序列化和反序列化需要大量IO操作

• Parcelable接口：是Android的序列化方式，使用復雜，但效率高。

• 對象是不能直接跨進程傳輸的。對象的跨進程傳輸，其本質是序列化和反序列化的過程

機制：Bundle、文件共享、ContentProvider、Socket、AIDL、Messager

• 四大組件間，把數據封裝到Bundle。在一個進程中開啟另一個進程的Activity或者Service，就可以通過Intent把Bundle傳遞過去。其中，封裝在Bundle中的數據需要能夠被序列化

• 使用文件共享方式，多進程讀寫一個相同的文件，獲取文件內容進行交互。

• 使用ContentProvider，常用于多進程共享數據，比如系統的相冊，音樂等，我們也可以通過ContentProvider訪問到

• 使用Socket傳輸數據。服務端（比如一個進程中運行了一個Service）創建一個ServerSocket對象，監聽本地的端口；客戶端（比如另一個進程中運行的Activity）通過Socket連接本地的那個接口。經過TCP的三次握手后，建立連接。接著可以發送數據。使用socket不僅可以實現進程間通信，也可以實現設備間通信。

Binder

• 基本原理： 
  Android特有的IPC、客戶端-服務器C/S的模式、

四個角色：Client、Server、ServiceManager、BinderDriver

調用過程： 
1. Server向ServiceManager注冊 
2. Client通過ServiceManager獲取Server的代理對象 
3. Client向代理對象發起請求，該請求通過BinderDriver發送給Server處理 
4. Server通過BinderDriver返回處理結果

• 注意：客戶端調用服務端的方法，被調用的方法運行在服務端的Binder線程池中，此時客戶端被掛起。因此此時需要避免ANR。（AIDL和Messager同理）

• Binder連接池

在一個應用有多個使用AIDL的場景，無需為每一個AIDL創建自己的Service。而是使用一個Service,創建并返回一個Binder連接池的Binder對象。Activity在使用AIDL的時候，可以通過該Binder連接池對象，獲取不同的Binder對象（類似于工廠模式）

AIDL

• 使用流程：以Activity（進程1）和Service（進程2）通信為例 
  
  • 創建AIDL接口，Build一下，產生相關代碼
  • 創建IBinder實例，即實例化xxx.Stub()抽象內部類，override抽象方法
  • 創建Service，在onBind()中，把上述IBinder實例返回
  • 在Activity中調用bindService啟動Service，然后在ServiceConnection中的onServiceConnected方法回調中獲得該IBinder實例。
  • Activity調用該實例的方法，實現通信

Messager

• 一種輕量級的跨進程通訊方案，底層使用AIDL實現。

• 是一種串行的通信，即服務端需要一個一個處理消息。因此，在大量并發請求的情況下，用Messager就不太合適。

• 使用流程：以Activity（進程1）和Service（進程2）通信為例

1. 在Service中new一個Messenger（這個Messenger需要指定Handler）
2. 然后在onBind函數中，返回messenger的Binder對象（messenger.getBinder()）
3. 在Activity中，通過bindService啟動service，通過ServiceConnection獲取到Binder對象。
4. 通過這個Binder對象實例化一個Messenger，然后messenger.send(message)進行通信

啟動流程

Android開機流程

init進程-zygote進程-SystemServer進程-各種ManagerService（AMS，PMS，WMS）- launcher程序

App啟動流程

launcher-AMS-(pause)-zygote-新進程ActivityThread-(main函數)-向AMS注冊-通知ActivityThread創建Activity并執行生命周期

App內Activity啟動流程

Activity1-AMS-(pause)-在同一個ActivityThread-加載Activity2類，執行生命周期

ActivityManagerService 和 Instrument 的區別

---

性能及優化

apk包大小

1、減少不必要的jar包依賴 
2、優先使用代碼來設置UI效果 
3、去除沒用到的資源文件，壓縮其他資源文件的大小，不用適配所有尺寸的設備 
4、盡量重用代碼，避免代碼的冗余 
5、限制app支持的cpu架構的數目：在當前的Android 生態系統中，讓你的app支持 armabi 和 x86 架構就夠了；

方法數越界 multiDex方案

• what：dex是Android平臺上(Dalvik虛擬機)的可執行文件, 相當于Windows平臺中的exe文件, 每個Apk安裝包中都有dex文件。

• 單個dex文件所包含的最大方法數是65536，包含Android Framwork、依賴的jar包，以及應用本身的所有方法。

• 解決方法數越界：

1. 刪除無用的代碼和第三方庫
2. 采用插件化機制，動態加載dex。這是一個重量級的方案
3. multiDex方案——可以從apk中加載多個dex文件

基本使用：

1. 配置Gradle，添加 multiDexEnabled true
2. 添加multiDex依賴
3. 在Application中添加 MultiDex.install(this) 代碼

其他

目標：

- 快：流暢
- 穩：穩定
- 省：省電、省流量
- 小：安裝包小 

	
	

		1
	

	

		2
	

	

		3
	

	

		4
	




	
	

		1
	

	

		2
	

	

		3
	

	

		4
	

優化方案：

• 布局優化：

• 減少View樹的層數
• 合理使用優先使用FrameLayout和LinerLayout，減少使用RelativeLayout
• 布局復用，使用標簽

OOM優化

ANR優化

ListView（GridView）優化

• 使用viewholder，進行view復用
• 不要在getview()中進行耗時操作

Bitmap優化

• 圖片壓縮
• 緩存（核心）：內存緩存和磁盤緩存、LRU算法

---

架構：本質上都是一種代碼架構思想

MVC

其中M層處理數據，業務邏輯等；V層處理界面的顯示結果；C層起到橋梁的作用，來控制V層和M層通信 
視圖層(View)：一般采用XML文件進行界面的描述，這些XML可以理解為AndroidApp的View。 
控制層(Controller)：Android中由Activit、Fragment承擔，負責邏輯處理 
模型層(Model)：提供數據，從進行數據庫或者網絡的操作。

缺點：在Android開發中，Activity并不是一個標準的MVC模式中的Controller，它的首要職責是加載應用的布局和初始化用戶界面，接受并處理來自用戶的操作請求，進而作出響應，既是view層，又是controller層。隨著界面及其邏輯的復雜度不斷提升，Activity類的職責不斷增加，以致變得龐大臃腫。

MVP

• MVP框架由3部分組成：

• Model：提供數據，從進行數據庫或者網絡的操作
• View：對應于Activity/Fragment等View，主要負責UI顯示
• Presenter：是Model和View之間的橋梁，進行邏輯處理。View并不能直接對Model進行操作

優點：將在Activty中的大量邏輯操作放到Presenter控制層中，避免Activity的臃腫。

缺點：MVP模式需要多寫許多新的接口；過于復雜的邏輯會使得Presenter臃腫

實現方法：

• 定義IView接口，Activity實現IView接口，然后在方法中更新UI；
• 在Presenter中維持IView的一個引用；
• 在Activity中實例化Presenter，然后將IView的實例（即this）賦值給Presenter。
• 在Model中做具體的操作，Presenter獲取具體的結果，通過調用所因為的View的方法，更新UI。

MVVM

• Model，View和ViewModel 
  
  • Model：提供數據，從進行數據庫或者網絡的操作
  • View：應于Activity/Fragment等View，主要負責UI顯示；
  • ViewModel是負責邏輯處理；Model提供數據。ViewModel和View之間通過綁定，使得耦合度進一步降低

AAC(Android Architecture Components,架構組件)

• LiveData：

• 使用觀察者模式，可以與控件綁定，監聽數據的改變刷新UI。
• 可以感知控件的生命周期，在控件銷毀時自動取消注冊，因此也不會產生內存泄漏

ViewModel：將視圖的數據和邏輯從具有生命周期特性的實體（如 Activity 和 Fragment）中剝離開來。比如 AndroidViewModel（ViewModle的子類）

Room：官方數據庫框架，對原生的SQLite API進行了一層封裝。

• 與SQLite相比：對于復雜的數據庫結構，SQL使用復雜，代碼冗長、管理困難；Room，使用簡單、易于管理

MVVM和AAC

個人理解：MVVM是一種思想，AAC提供多種工具。利用AAC中的工具實現MVVM的思想

View：

ViewModel：

Model：

• 橘黃色框的Repository及其下都是Model層。一個Repository數據倉庫負責通過不同方式獲取同類型的數據。
• 數據來源有： 
  
  • 本地存儲數據，如數據庫，文件，SharedPreferences（本質也是文件）
  • 內存的緩存或臨時數據
  • 通過各種網絡協議獲取的遠程數據
• ViewModel在從Repository獲取數據時，不需關注數據具體是怎么來的。

---

響應式編程

RxJava/RxAndroid

基于觀察者模式，可以方便地以流的方式處理異步事件

1. 創建： 
   Observable.create/just/from

2. Schedulers線程調度

• 在不指定線程的情況下， RxJava 遵循的是線程不變的原則

• subscribeOn():

• 指定 subscribe() 所發生的線程，即 Observable.OnSubscribe 被激活時所處的線程。或者叫做事件產生的線程。

• subscribeOn() 的位置放在哪里都可以，但它是只能調用一次的。

observeOn():

• Subscriber 所運行在的線程，或者叫做事件消費的線程。
• 指定的是它之后的操作所在的線程，以此實現線程的多次調用

舉例： 
AndroidSchedulers.mainThread(); 
Schedulers.single(); 
Schedulers.newThread(); 
Schedulers.computation(); 
Schedulers.io();

變換 操作符

1. map()：將發射的每一項數據都用一個函數進行變換
2. flapMap()：

背壓

在異步場景下，被觀察者的發送速度遠遠大于觀察者的處理速度。

• Observable不支持背壓

• Flowable支持背壓： 
  - 背壓策略：MISSING、ERROR、BUFFER、DROP、LATEST

Retrofit

是一個網絡請求框架，底層依賴OkHttp

• 首先，Retrofit將Http請求封裝為Java接口；
• 然后，網絡請求交給OkHttp處理；
• 最后，OkHttp將返回的結果交給Retrofit解析

支持兩種模式：callback、RxJava/RxAndroid

---

其他

JIN

由于Java的跨平臺的特性，導致Java同本地交互的能力不夠強大，一些和操作系統相關的操作無法完成。通過JNI可以調用C和C++的代碼，提高自己的本地交互能力

JNI開發流程：

1. 在Java中編寫native方法
2. 將Java編譯成class文件，然后導出JNI的.h頭文件。
3. 用C或者C++實現java中聲明的JNI方法
4. 編譯.so庫文件，然后在java中調用

設計一個圖片加載類

• 圖片同步、異步加載方式
• 圖片壓縮（使用BitmapFactory） —— 降低OOM的風險
• 緩存 —— 內存緩存LruCache、磁盤緩存DiskLruCache。兩級緩存降低了網絡訪問次數，減少了流量消耗
• 網絡拉取 —— 從網絡加載圖片。
• View復用
• 調用過程：從內存緩存中讀取 —— 從磁盤緩存中讀取 —— 從網絡中拉取

畫出一個項目中網絡請求的流程圖

第三方庫源碼解析：

OkHttp

說說XML、JSON、GSON有什么樣的聯系

XML全稱叫做可擴展標記語言，它的結構相對簡單，數據共享比較方便。但是對于一些比較復雜的數據，XML文件格式復雜，解析的代價大。 
JSON的數據格式比較簡單，易于讀寫。但是目前還沒有XML應用廣泛。 
GSON的Google的一個開源庫。這個開源庫可以很方便地將JSON數組轉換為對象，這在開發中簡化了將JSON的字段轉換為屬性的步驟。

Android訪問權限

apk下載到cache目錄，只有 rw 權限，沒有 x 權限，所以無法安裝

Runtime.getRuntime().exec() 
執行 chmod 命令，修改為rwx

---

APM

Android性能信息

• CPU信息：/proc/cpuinfo
• Memory 信息：/proc/meminfo

異常捕獲：

UncaughtExceptionHandler： 
android全局異常捕獲器——在Application中調用**Thread.setDefaultUncaughtExceptionHandler 
(uncaughtExceptionHandler)**，定制自己的錯誤日志系統。比如在發生Exception時，記錄exception的堆棧信息。

監控Activity生命周期

在application中，調用registerActivityLifecycleCallbacks()，通過實現了ActivityLifecycleCallbacks接口的實例，完成對Activity各個生命周期信息的采集。比如哪個Activity在什么時間處于onCreate、onStop等等，進而統計出Activity的使用時間和使用次數。

對于Fragment的信息采集

SDK提供不同接口，分別對應Fragment的各個生命周期，進而采集信息。使用時，需要用戶在Fragment的生命周期中的各個環節中，調用對應的接口。 
會不會使用麻煩？會的，解決方法就是：在SDK中封裝一個Fragment的子類，在這個子類中按照上述方法采集信息。用戶在使用SDK過程中，可以直接繼承使用這個子類，而不是繼承使用Fragment。

對HTTP接口的監測

采用插裝的辦法：SDK提供兩個接口，用戶在發起HTTP請求時，調用第一個接口，可以記錄下url和時間。在結束HTTP時，調用第二個接口，記錄下url、時間和返回碼。這兩組記錄就完成了對HTTP接口的數據采集？ 
會不會麻煩？會的，但是這種方法很通用，其他商用的SDK中也是這種方法。或者使用Gradle插件，在編譯的時候，將上述代碼自動插入項目中。

錯誤信息上報機制：

方案一：發現錯誤后立即上報。優點：實時性好；缺點：不能保證每一條信息都能上報成功。 
方案二：發生錯誤后，記錄在本地，當第二次啟動App的時候，上報上一次的信息。