四大組件：

Activity：

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

Service：

• 生命周期：

• 如何提高service的生存率？

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

BroadcastReceiver：

• 普通廣播、
• 系統(tǒng)廣播：系統(tǒng)內(nèi)置的一些廣播，比如監(jiān)聽網(wǎng)絡(luò)變化、打開相機等等
• 有序廣播：
  
  • 接收者按照預(yù)先聲明的優(yōu)先級依次接收Broadcast；
  • 可以把數(shù)據(jù)存入結(jié)果對象中，傳遞給下一個接收者；
  • 可以被一種某一個接收者終止。
• 本地廣播（APP內(nèi)）

ContentProvider：

---

Android進程（等級）

1. foreground process 前端進程

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

   比如說：

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

2. visible process 可見進程

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

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

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

4. background process 后臺進程
   比如：Activity執(zhí)行了onStop

5. empty process 空進程

---

數(shù)據(jù)持久化

SQLight：

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

SharedPreference：

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

ContentProvider：

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

Android應(yīng)用程序之間是通過哪些方式共享數(shù)據(jù)的？

File，Sqlite，Content Provider，BroadCast Receiver，Intent，同個Application內(nèi)部的話還可以通過靜態(tài)變量共享數(shù)據(jù)。

---

webView

加載

1. 提高渲染的優(yōu)先級

   webSettings.setRenderPriority(RenderPriority.HIGH);

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

   webSettings.setBlockNetworkImage(true);

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

4. 開啟緩存
   設(shè)置websetting

js和java對象交互

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

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

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

防止OOM

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

---

線程相關(guān)

Linux線程基礎(chǔ)

• 線程與進程的區(qū)別
• 線程同步
• Linux線程通訊方式

ANR

- what
    - Activity 5s內(nèi)無響應(yīng)，BroadcastReceiver 10s內(nèi)無響應(yīng)
    - /data/anr/traces.txt 文件記錄了ANR的信息
- why
- how
 

耗時任務(wù)或者線程間通訊

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

Handler

• Handler + MessageQueue + Looper

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

• HandlerThread

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

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

IntentService

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

• override onHandleIntent() 方法

• 優(yōu)點：一方面不需要自己去創(chuàng)建線程，另一方面不需要考慮在什么時候關(guān)閉該Service

OOM

• what
  OOM 和 內(nèi)存泄漏 的區(qū)別

• how

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

• Handler造成OOM

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

• WebView造成OOM

---

View相關(guān)

三部曲

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

Touch分發(fā)機制

重要

滑動沖突

簡述Activity、Window、WindowManager、View、ViewRootImpl的作用和相互之間的關(guān)系

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

• Window中有decorview，decorview是當(dāng)前視圖的底層View，是setContentView所設(shè)置View的父View
  View是所有控件的基類。

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

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

RecyclerView

• 優(yōu)點：

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

• 缺點：

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

• RecyclerView.Adapter

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

---

IPC

Linux中IPC的方式：命名管道、信號量、共享內(nèi)存

基礎(chǔ)

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

序列化

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

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

• 對象是不能直接跨進程傳輸?shù)摹ο蟮目邕M程傳輸，其本質(zhì)是序列化和反序列化的過程

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

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

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

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

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

Binder

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

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

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

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

• Binder連接池

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

AIDL

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

Messager

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

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

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

  1. 在Service中new一個Messenger（這個Messenger需要指定Handler）
  2. 然后在onBind函數(shù)中，返回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函數(shù))-向AMS注冊-通知ActivityThread創(chuàng)建Activity并執(zhí)行生命周期

App內(nèi)Activity啟動流程

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

ActivityManagerService 和 Instrument 的區(qū)別

---

性能及優(yōu)化

apk包大小

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

方法數(shù)越界 multiDex方案

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

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

• 解決方法數(shù)越界：

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

• 基本使用：

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

其他

目標：

- 快：流暢
- 穩(wěn)：穩(wěn)定
- ?。菏‰?、省流量
- 小：安裝包小

優(yōu)化方案：

• 布局優(yōu)化：

  • 減少View樹的層數(shù)
  • 合理使用優(yōu)先使用FrameLayout和LinerLayout，減少使用RelativeLayout
  • 布局復(fù)用，使用標簽

• OOM優(yōu)化

• ANR優(yōu)化

• ListView（GridView）優(yōu)化

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

• Bitmap優(yōu)化

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

---

架構(gòu)：本質(zhì)上都是一種代碼架構(gòu)思想

MVC

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

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

MVP

• MVP框架由3部分組成：

  • Model：提供數(shù)據(jù)，從進行數(shù)據(jù)庫或者網(wǎng)絡(luò)的操作
  • View：對應(yīng)于Activity/Fragment等View，主要負責(zé)UI顯示
  • Presenter：是Model和View之間的橋梁，進行邏輯處理。View并不能直接對Model進行操作

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

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

• 實現(xiàn)方法：

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

MVVM

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

AAC(Android Architecture Components,架構(gòu)組件)

• LiveData：

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

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

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

  • 與SQLite相比：對于復(fù)雜的數(shù)據(jù)庫結(jié)構(gòu)，SQL使用復(fù)雜，代碼冗長、管理困難；Room，使用簡單、易于管理

MVVM和AAC

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

View：

ViewModel：

Model：

• 橘黃色框的Repository及其下都是Model層。一個Repository數(shù)據(jù)倉庫負責(zé)通過不同方式獲取同類型的數(shù)據(jù)。
• 數(shù)據(jù)來源有：
  
  • 本地存儲數(shù)據(jù)，如數(shù)據(jù)庫，文件，SharedPreferences（本質(zhì)也是文件）
  • 內(nèi)存的緩存或臨時數(shù)據(jù)
  • 通過各種網(wǎng)絡(luò)協(xié)議獲取的遠程數(shù)據(jù)
• ViewModel在從Repository獲取數(shù)據(jù)時，不需關(guān)注數(shù)據(jù)具體是怎么來的。

---

響應(yīng)式編程

RxJava/RxAndroid

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

1. 創(chuàng)建：
   Observable.create/just/from

2. Schedulers線程調(diào)度

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

   • subscribeOn():

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

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

   • observeOn():

     • Subscriber 所運行在的線程，或者叫做事件消費的線程。
     • 指定的是它之后的操作所在的線程，以此實現(xiàn)線程的多次調(diào)用
   • 舉例：
     AndroidSchedulers.mainThread();
     Schedulers.single();
     Schedulers.newThread();
     Schedulers.computation();
     Schedulers.io();

3. 變換 操作符

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

4. 背壓

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

• Observable不支持背壓

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

Retrofit

是一個網(wǎng)絡(luò)請求框架，底層依賴OkHttp

• 首先，Retrofit將Http請求封裝為Java接口；
• 然后，網(wǎng)絡(luò)請求交給OkHttp處理；
• 最后，OkHttp將返回的結(jié)果交給Retrofit解析

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

---

其他

JIN

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

JNI開發(fā)流程：

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

設(shè)計一個圖片加載類

• 圖片同步、異步加載方式
• 圖片壓縮（使用BitmapFactory） —— 降低OOM的風(fēng)險
• 緩存 —— 內(nèi)存緩存LruCache、磁盤緩存DiskLruCache。兩級緩存降低了網(wǎng)絡(luò)訪問次數(shù)，減少了流量消耗
• 網(wǎng)絡(luò)拉取 —— 從網(wǎng)絡(luò)加載圖片。
• View復(fù)用
• 調(diào)用過程：從內(nèi)存緩存中讀取 —— 從磁盤緩存中讀取 —— 從網(wǎng)絡(luò)中拉取

畫出一個項目中網(wǎng)絡(luò)請求的流程圖

第三方庫源碼解析：

OkHttp

說說XML、JSON、GSON有什么樣的聯(lián)系

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

Android訪問權(quán)限

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

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

---

APM

Android性能信息

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

異常捕獲：

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

監(jiān)控Activity生命周期

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

對于Fragment的信息采集

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

對HTTP接口的監(jiān)測

采用插裝的辦法：SDK提供兩個接口，用戶在發(fā)起HTTP請求時，調(diào)用第一個接口，可以記錄下url和時間。在結(jié)束HTTP時，調(diào)用第二個接口，記錄下url、時間和返回碼。這兩組記錄就完成了對HTTP接口的數(shù)據(jù)采集？
會不會麻煩？會的，但是這種方法很通用，其他商用的SDK中也是這種方法?；蛘呤褂肎radle插件，在編譯的時候，將上述代碼自動插入項目中。

錯誤信息上報機制：

方案一：發(fā)現(xiàn)錯誤后立即上報。優(yōu)點：實時性好；缺點：不能保證每一條信息都能上報成功。
方案二：發(fā)生錯誤后，記錄在本地，當(dāng)?shù)诙螁覣pp的時候，上報上一次的信息。

接口加密、token原理