Android Studio JNI流程

1. 首先在java代碼聲明本地方法 用到native關鍵字 本地方法不用去實現,最好聲明在一個新類中(rebuild project)
2. 項目根目錄下創建jni文件夾(java文件夾同級)
3. 在jni文件夾下創建.c文件
   • 本地函數命名規則: Java包名_類名_本地方法名
   • 也可以cd到當前項目的 build/intermediates/classes/debug/ 目錄下執行javah native方法下的包名類名
   • 得到頭文件拷貝到.c文件下
4. System.loadLibrary("hello")，把so庫加載進來（可以調用native本地方法了）
5. local.properties 設置ndk.dir目錄
6. gradle.properties 添加一行 android.useDeprecatedNdk=true
7. 在當前Module下的build.gradle 文件下的defaultConfig節添加

   ndk {
       moduleName "hello"
       abiFilter "x86"
       abiFilter "armeabi"
   }
   

C調用JAVA

1. 找到字節碼對象
   • jclass (FindClass)(JNIEnv, const char*);
   • 第二個參數 要回調的java方法所在的類的路徑 "com/itheima/callbackjava/JNI"
2. 通過字節碼對象找到方法對象
   • jmethodID (GetMethodID)(JNIEnv, jclass, const char, const char);
   • 第二個參數 字節碼對象 第三個參數 要反射調用的java方法名 第四個參數 要反射調用的java方法簽名
   • javap -s 要獲取方法簽名的類的全類名 項目/bin/classes 運行javap
3. 通過字節碼創建 java對象(可選) 如果本地方法和要回調的java方法在同一個類里可以直接用 jni傳過來的java對象 調用創建的Method
   • jobject obj =(*env)->AllocObject(env,claz);
   • 當回調的方法跟本地方法不在一個類里 需要通過剛創建的字節碼對象手動創建一個java對象
   • 再通過這個對象來回調java的方法
   • 需要注意的是 如果創建的是一個activity對象 回調的方法還包含上下文 這個方法行不通!!!回報空指針異常
4. 反射調用java方法
   • void (CallVoidMethod)(JNIEnv, jobject, jmethodID, ...);
   • 第二個參數 調用java方法的對象 第三個參數 要調用的jmethodID對象 可選的參數 調用方法時接收的參數

NDK的理解

• NDK提供了一系列的工具，幫助開發者快速開發 C （或 C++ ）的動態庫，并能自動將 so 和 java 應用一起打包成 apk 。這些工具對開發者的幫助是巨大的
• NDK 提供了一份穩定、功能有限的 API 頭文件聲明
• Google明確聲明該 API 是穩定的，在后續所有版本中都穩定支持當前發布的 API 。從該版本的 NDK 中看出，這些 API 支持的功能非常有限，包含有： C 標準庫（ libc ）、標準數學庫（ libm ）、壓縮庫（ libz ）、 Log 庫（ liblog ）

四大組件相關

• 四大組件之間通過Intent來傳數據
• Service啟動Activity需要加上 intentv.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
• Service如何彈出dialog

  1. show() 調用之前添加以下代碼： dialog.getWindow().setType((WindowManager.LayoutParams.TYPE_SYSTEM_ALERT));
  2. 清單文件添加權限:android.permission.SYSTEM_ALERT_WINDOW

Handler機制

• 作用：將一個任務切換到某個指定的線程中去執行和分發消息，主要涉及類：Handler、Message、MessageQueue、Looper
• 創建：Handler構造函數通過Looper.myLooper()會獲取當前線程中的Looper對象（Looper通過prepare/prepareMainLooper創建的，通過ThreadLocal存儲，每個線程只有一個），通過Looper的構造函數創建MessageQueue（內部是鏈表結構），從而三者關聯起來
• 發送：Handler通過sendMessage/post將Message（Message.obtain()復用）發送到Looer對應的MessageQueue，MessageQueue通過enqueueMessage()把當前消息加入到鏈表對應位置
• 處理：Looper通過loop()不斷從MessageQueue中取出Message queue.next()（沒有消息則阻塞，異步阻塞IO），然后調用與Message綁定的Handler對象的dispatchMessage()交給發送該消息的Handler進行處理，如果是post的message會調用handleCallback()，直接處理事件，否則會調用我們復寫handleMessage()處理，處理完成后調用Message.recycle()將其放入Message對象池中，最終三者形成一個循環
• 高級：NativeMessageQueue、 Native Looper
  • 獲取消息首先調用nativePollOnce，從底層epoll（異步阻塞IO），發送消息加入消息隊列首先會調用nativeWake，向管道寫入字符，喚醒IO，從而MessageQueue.next()可以返回一個Message

分析AsyncTask

• 主要方法有：onPreExecute()、doInBackground()、 publishProgress()、onProgressUpdate()、onPostExecute()
• 創建：AsyncTask(泛型參數：Params、Progress、Result)時會創建一個WorkerRunnable(實現Callable接口)對象mWorker，一個FutureTask對象mFuture，mWorker會保存到mFuture屬性中
• 運行：調用executeOnExecutor()，設置狀態 -> 回調onPreExecute() -> 設置mWorker參數(doInBackground參數) -> sDefaultExecutor.execute(mFuture)，有兩個線程池（線性入隊線程池、工作線程池）從線性線程池(offer()/poll()輪訓任務)執行FutureTask的run()封裝成Runnable并交到工作線程池中，此時是運行在子線程中）
• FutureTask#run()result = c.call()-> postResult(doInBackground(mParams));，這個過程中doInBackground將會被調用，其中mFuture中result變量保存了doInBackground返回值，通過postResult()傳遞給InternalHandler()（此時是主線程了...）,handler中會調用mTask.finish(結果)，最后正常結束會調用onPostExecute(result)，FutureTask#finishCompletion()->done()，最后傳到FutureTask復寫的Done()->postResultIfNotInvoked(get())通過get()可以獲取子線程傳遞過來的值
• 如果復寫的doInBackground方法中方調用了publishProgress方法，則通過InternalHandler實例sHandler發送一條Message，更新進度，sHandler處理消息onProgressUpdate方法將被調用

ThreadLocal

• ThreadLocal是一個線程內部的數據存儲類（內部數據結構是map），通過它可以在指定的線程中存儲數據，數據存儲后，只有在指定的線程中獲取存儲的數據，其它的線程無法獲取，實現了隔離多個線程的數據共享，主要用在Looper、ActivityThread以及AMS中
• ThreadLocalMap類似HashMap，key為ThreadLocal，value為實際放入的值，采用線性探測法來解決散列沖突

HandlerThread

• HandlerThread繼承了Thread，是可以使用Handler的Thread，內部run方法中通過Looper.prepare()創建消息隊列，并通過Looper.loop()開啟消息循環，具體使用場景有IntentService，它可以通過quit/quitSafely方法終止線程的執行(區別是quitSafely沒有立即終止把當前時間之前的任務執行完才退出)

IntentService

• 當Service中執行耗時操作時，20s會產生ANR，而IntentService是一個特殊的Service，則可用于執行后臺耗時的任務，無需處理多線程問題，IntentService封裝了HandlerThread和Handler，通過復寫onHandleIntent方法操作耗時操作，當任務執行完后會自動停止，無需調用stopSelf()方法停止Service，避免了Service的內存泄漏，Intentservice若未執行完成上一次的任務，將不會新開一個線程，是等待之前的任務完成后，再執行新的任務，等任務完成后再次調用stopSelf，適合執行一些高優先級的后臺任務，因為不容易被殺死

保證后臺進程不被kill

• 提供進程優先級，降低進程被殺死的概率
  • 方法一：監控手機鎖屏解鎖事件，在屏幕鎖屏時啟動1個像素的 Activity，在用戶解鎖時將 Activity 銷毀掉。
  • 方法二：啟動前臺service（setForeground）
  • 方法三：提升service優先級：
    在AndroidManifest.xml文件中對于intent-filter可以通過android:priority = "1000"這個屬性設置最高優先級，1000是最高值，如果數字越小則優先級越低，（適用于廣播）
• 在進程被殺死后，進行拉活
  • 方法一：注冊高頻率廣播接收器，喚起進程。如網絡變化，解鎖屏幕，開機等
  • 方法二：Native雙進程相互喚起（fork+JNI）
  • 方法三：依靠系統喚起（賬號同步機制）
  • 方法四：onDestroy方法里重啟service：service +broadcast 方式，就是當service走ondestory的時候，發送一個自定義的廣播，當收到廣播的時候，重新啟動service；
  • 方法五：手機QQ、微信、支付寶、UC瀏覽器等，以及友盟、信鴿、個推等 SDK，找出它們外發的廣播，在應用中進行監聽，這樣當這些應用發出廣播時，就會將我們的應用拉活

怎么保證 Service 不被殺死

• 雙進程守護(JNI,Fork)只有5.0以下有效
• 在Service的onStartCommand方法里返回 STATR_STICK（kill 后會被重啟（等待5秒左右），重傳Intent，保持與重啟前一樣）（詳情）
• 提升service 優先級 //android:priority="1000"，1000是最高值，同時適用于廣播
• 提升service進程優先級（startForeground 將service放到前臺進程）
• 在 onDestory 中通過廣播再次啟動 Service（Service+Broadcast，發送一個自定義的廣播，當收到廣播的時候，重新啟動service）
• Application加上Persistent屬性（保證應用的持久性，這種應用會頑固地運行于系統之中，從系統一啟動，一直到系統關機）
• root之后放到system/app變成系統級應用

廣播的兩種注冊方法,有什么區別

• 動態注冊：動態注冊的優先級高于靜態注冊，Activity關閉不能接受廣播，無需在清單文件注冊
• 靜態注冊：Activity關閉還能接受廣播，只要設備處于開啟狀態就能接收

服務的類型

• 按照使用范圍分類:本地服務、遠程服務
• 按照運行類別分類:前臺服務、后臺服務

Android啟動Service的兩種方式是什么

• startService：生命周期與調用者不同，啟動后若調用者未調用stopService而直接退出，Service仍會運行
• bindService：生命周期與調用者綁定（Service的生命周期依附于Context），調用者一旦全部退出，Service就會調用unBind->onDestroy

Service兩種啟動方式的區別

• startService只是啟動Service，啟動它的組件（如Activity）和Service并沒有關聯，只有當Service調用stopSelf或者其他組件調用stopService服務才會終止
• bindService方法啟動Service，其他組件可以通過回調獲取Service的代理對象和Service交互，而這兩方也進行了綁定，當啟動方銷毀時，Service也會自動進行unBind操作，當發現所有綁定都進行了unBind時才會銷毀Service

Android組件之間數據傳遞方法

• 基于消息的通信機制 Intent--bundle,extra
• 利用static靜態數據，public static成員變量
• 基于外部存儲的傳輸 ，File/Preference/Sqlite
• 基于ipc的通信機制
• context與service之間的傳輸，如Activity與Service之間的通信
• 基于Application Context

Android怎么加速啟動Activity（優化的細節）

• 減少onCreate的時間，耗時操作
• 移除背景
• 在很多的應用一開始點擊的時候總會出現黑屏或者白屏,甚至前段時間微信也有同樣的問 題。其實白屏或者黑屏還是一些其他的東西,都是因為 Android 主題的問題,只要自己自 定義一個啟動主題,問題完美解決

View繪制流程

• View的繪制是由ViewRootImpl來負責的，每個應用程序窗口的decorView都有一個與之關聯的ViewRootImpl對象（ViewRootImpl是DecorView添加到Window中創建的）
• View繪制的起點：requestLayout()->scheduleTraversals()->performTraversals()
• performTraversals整個繪制流程可以分為以下三個階段
  • performMeasure()->measure()->onMeasure: 判斷是否需要重新計算View的大小，需要的話則計算
    • MeasureSpec:由SpecMode和SpecSize兩部分組成EXACTLY（match_parent、數值）
      AT_MOST（wrap_content）
      UNSPECIFIED（不限制，ScrollView）
    • 具體自定義view復寫onMeasure()，處理AT_MOST，setMeasuredDimension()設置測量的結果
  • performLayout()->layout()->onLayout(): 據上一階段得到的View的測量寬高來確定View的最終顯示位置，判斷是否需要重新計算View的位置，ViewGroup類的onLayout()是abstract
  • performDraw()->draw()->onDraw()判斷是否需要重新繪制View
    • drawBackground()->onDraw()-> dispatchDraw()-> onDrawForeground()
• 重繪
  • requestLayout()：調用performTraversals()但不執行draw() mPrivateFlags
  • invalidate()：調用performTraversals()但不執行measure()、layout()

事件分發機制

Android 長連接,怎么處理心跳機制

• 維護任何一個長連接都需要心跳機制，客戶端發送一個心跳給服務器，服務器給客戶端一個心跳應答，這樣就形成客戶端服務器的一次完整的握手，這個握手是讓雙方都知道他們之間的連接是沒有斷開，客戶端是在線的
• 如果超過一個時間的閾值，客戶端沒有收到服務器的應答，或者服務器沒有收到客戶端的心跳，那么對客戶端來說則斷開與服務器的連接重新建立一個連接，對服務器來說只要斷開這個連接即可
• 推送的實現方式
  • 客戶端不斷的查詢服務器，檢索新內容，也就是所謂的pull 或者輪詢方式
  • 客戶端和服務器之間維持一個TCP/IP長連接，服務器向客戶端push
  • 服務器有新內容時，發送一條類似短信的信令給客戶端，客戶端收到后從服務器中下載新內容，也就是SMS的推送方式
• Android推送技術
• 微信Android客戶端后臺?；罱涷灧窒?/a>

• FragmentPagerAdapter不會銷毀Fragment， 適用于那些相對靜態的頁，數量也比較少的那種
• 如果需要處理有很多頁，并且數據動態性較大、占用內存較多的情況，應該使用FragmentStatePagerAdapter，會銷毀不需要的Fragment，當擁有大量的頁面時，不必在內存中占用大量的內存，更省內存
• FragmentPagerAdapter詳解

提升SQLite數據插入效率低、速度慢的方法

• 慢速——最粗暴的方法(SQLite的API中直接執行SQL)
• 中速——顯式開啟事務(就是指一組SQL命令，這些命令要么一起執行，要么都不被執行)
• 高速——寫同步(synchronous)
• 極速——執行準備(一種是使用前文提到的函數sqlite3_exec()，該函數直接調用包含SQL語句的字符串；另一種方法就是“執行準備”（類似于存儲過程）操作，即先將SQL語句編譯好，然后再一步一步（或一行一行）地執行。)
• SQLite插入數據效率最快的方式就是：事務+關閉寫同步+執行準備（存儲過程），如果對數據庫安全性有要求的話，就開啟寫同步

Activity與Fragment之間的區別

• 區別：
  • fragment顯得更加靈活?？梢灾苯釉赬ML文件中添加<fragment/>,Activity則不能
  • 可以在一個界面上靈活的替換一部分頁面，activity不可以，做不到
• 通信(也就是控件的相互操控)：
  • fragment控制fragment：得到一個Activity，然后通過這個Activity的getFragmentManager()獲得該Fragment的實例。
  • fragment控制Activity：這個很簡單。每個Fragment都有getActivity()得到一個活動。MainActivity activity=getActivity();
  • Activity控制fragment：getFragmentManager().findFragmentById();
  • Activity控制Activity：這個顯然是通過Intent活動之間的通信完成。別忘了在被打開的活動中創建Intent和得到Intent一起進行，寫個靜態的actionStart()。

Activity與Fragment通信方案

• handler：該方案存在的缺點：
  • Fragment對具體的Activity存在耦合，不利于Fragment復用
  • 不利于維護，若想刪除相應的Activity，Fragment也得改動
  • 沒法獲取Activity的返回數據
  • handler的使用個人感覺就很不爽（不知大家是否有同感)
• 廣播方案缺點：
  • 用廣播解決此問題有點大材小用了，個人感覺廣播的意圖是用在一對多，接收廣播者是未知的情況
  • 廣播性能肯定會差
  • 傳播數據有限制（必須得實現序列化接口才可以）
• EventBus方案：
  • EventBus是用反射機制實現的，性能上會有問題
  • EventBus難于維護代碼
  • 沒法獲取Activity的返回數據
• 接口方案
  • 假如項目很大了，Activity與Fragment的數量也會增加

Activity與Service通信方案(區別于是否同個進程)

• Aidl，回調(listener)
• Messager
• 廣播 （推薦LocalBroadcastManager）
• 開源組件(EventBus，otto)

Android常見的內存緩存算法

• LRU即Least RecentlyUsed，近期最少使用算法：當內存緩存達到設定的最大值時將內存緩存中近期最少使用的對象移除，有效的避免了OOM的出現
• Least Frequently Used（LFU）：
  對每個緩存對象計算他們被使用的頻率。把最不常用的緩存對象換走
• First in First out（FIFO）：
  這是一個低負載的算法，并且對緩存對象的管理要不高。通過一個隊列去跟蹤所有的緩存對象，最近最常用的緩存對象放在后面，而更早的緩存對象放在前面，當緩存容量滿時，排在前面的緩存對象會被踢走，然后把新的緩存對象加進去
• LargestLimitedMemoryCache：超過指定緩存的話，每次移除棧最大內存的緩存的對象

Context相關

• Context直系子類有兩個，一個是ContextWrapper，一個是ContextImpl。那么從名字上就可以看出，ContextWrapper是上下文功能的封裝類，而ContextImpl則是上下文功能的實現類。而ContextWrapper又有三個直接的子類，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一個帶主題的封裝類，而它有一個直接子類就是Activity
• Context類型：
  • 分別是Application、Activity和Service
  • 每一個Activity和Service以及Application的Context都是一個新的ContextImpl對象
  • Application/Activity/Service作為Context的區別
• Context獲取：
  • getApplicationContext() 返回應用的上下文，生命周期是整個應用，應用摧毀它才摧毀
  • Activity.this的context 返回當前activity的上下文，屬于activity ，activity 摧毀他就摧毀

  • getBaseContext() 返回由構造函數指定或setBaseContext()設置的上下文

    
    
    類結構圖

Service與Thread區別

• Thread：Thread是程序執行的最小單元，它是分配CPU的基本單位?？梢杂?Thread 來執行一些異步的操作
• Service：Service 是android的一種機制，當它運行的時候如果是Local Service，那么對應的 Service 是運行在主進程的 main 線程上的。如：onCreate，onStart 這些函數在被系統調用的時候都是在主進程的 main 線程上運行的。如果是Remote Service，那么對應的 Service 則是運行在獨立進程的 main 線程上
• Thread 的運行是獨立于 Activity 的，也就是說當一個 Activity 被 finish 之后，如果你沒有主動停止 Thread 或者 Thread 里的 run 方法沒有執行完畢的話，Thread 也會一直執行。因此這里會出現一個問題：當 Activity 被 finish 之后，你不再持有該 Thread 的引用。另一方面，你沒有辦法在不同的 Activity 中對同一 Thread 進行控制
• Android的后臺就是指，它的運行是完全不依賴UI的。即使Activity被銷毀，或者程序被關閉，只要進程還在，Service就可以繼續運行。比如說一些應用程序，始終需要與服務器之間始終保持著心跳連接，就可以使用Service來實現
• 在一個Activity中創建的子線程，另一個Activity無法對其進行操作。但是Service就不同了，所有的Activity都可以與Service進行關聯，然后可以很方便地操作其中的方法，即使Activity被銷毀了，之后只要重新與Service建立關聯，就又能夠獲取到原有的Service中Binder的實例，因此，使用Service來處理后臺任務，Activity就可以放心地finish，完全不需要擔心無法對后臺任務進行控制的情況。

Apk打包過程

• (aapt) 打包資源文件，生成R.java文件
  • 把xml文件編譯成二進制文件，解析速度更快并減少文件大小
• (aidl) 處理AIDL文件，生成相應的Java文件
• (javac) 編譯工程源代碼，生成相應的class文件
• (dex) 轉換所有的class文件(包括3rd庫)，生成classes.dex文件
• (apkbuilder) 將classes.dex、resources.arsc、res文件夾(res/raw不變)、Other Resources(assets文件夾)、AndroidManifest.xml打包成apk文件
• (jarsigner) 對apk包進行簽名
• (zipalign) 對簽名后的apk文件進行對對齊處理

如何退出Activity,如何安全退出已調用多個Activity的Application？

• 拋異常強制退出，android.os.Process.killProcess(android.os.Process.myPid());
• 在Appliction類中記錄打開的Activity，每打開一個Activity，就記錄下來。在需要退出時，關閉每一個Activity即可
• 創建發送特定廣播的Activity，在需要結束應用時，發送一個特定的廣播，每個Activity收到廣播后，關閉即可
• 遞歸退出，在打開新的Activity時使用startActivityForResult，然后自己加標志，在onActivityResult中處理，遞歸關閉
• 用intent.setFlag(FLAG_ACTIVITY_CLEAR_TOP)激活一個新的activity,然后在新的activity的oncreate方法里面 finish掉

自定義控件的生命周期

• onFinishInflate() 當View中所有的子控件均被映射成xml后觸發
• onMeasure( int , int ) 確定所有子元素的大小
• onLayout( boolean , int , int , int , int ) 當View分配所有的子元素的大小和位置時觸發
• onSizeChanged( int , int , int , int ) 當view的大小發生變化時觸發，啟動時間在onDraw之前
• onDraw(Canvas) view渲染內容的細節
• onKeyDown( int , KeyEvent) 有按鍵按下后觸發
• onKeyUp( int , KeyEvent) 有按鍵按下后彈起時觸發
• onTrackballEvent(MotionEvent) 軌跡球事件
• onTouchEvent(MotionEvent) 觸屏事件
• onFocusChanged( boolean , int , Rect) 當View獲取或失去焦點時觸發
• onWindowFocusChanged( boolean ) 當窗口包含的view獲取或失去焦點時觸發
• onAttachedToWindow() 當view被附著到一個窗口時觸發
• onDetachedFromWindow() 當view離開附著的窗口時觸發，Android123提示該方法和 onAttachedToWindow() 是相反的
• onWindowVisibilityChanged( int ) 當窗口中包含的可見的view發生變化時觸發

Force Close相關

• 比如空指針啦，類沒有找到啦，資源沒找到，就連Android API使用的順序錯誤也可能導致比如setContentView()之前進行了findViewById()操作）
• 如何避免彈出Force Close窗口 可以在Application類中實現Thread.UncaughtExceptionHandler接口的uncaughtException方法

縮減APK包大小

• 保持良好的編程習慣，不要重復或者不用的代碼，謹慎添加libs，移除使用不到的libs,使用proguard混淆代碼，它會對不用的代碼做優化，并且混淆后也能夠減少安裝包的大小
• 使用Lint工具查找沒有使用到的資源。去除不使用的圖片，String，XML等等
• 能用代碼繪制實現的功能，盡量不要使用大量的圖片

android 關于安全的問題，你所知道的所有的安全問題

• 錯誤導出組件
• 參數校驗不嚴
• WebView引入各種安全問題
• 不混淆、不防二次打包
• 明文存儲關鍵信息
• 錯誤使用HTTPS
• 山寨加密方法

Android之安全機制

• 代碼安全：反編譯，混淆proguard
• 應用權限的設置：操作增加限制，防止惡意應用進行非法操作給用戶造成敏感數據泄漏和設備被非法控制
• 數字證書：只有同一包名且采用同一數字證書的應用才被認為是同一個應用
• 網絡安全：DES，RSA，SSL
• 文件訪問控制：采用的UGO權限機制

關于APK數字簽名

• 所有的應用程序都必須有數字證書，Android系統不會安裝一個沒有數字證書的應用程序
• Android程序包使用的數字證書可以是自簽名的，不需要一個權威的數字證書機構簽名認證
• 如果要正式發布一個Android ，必須使用一個合適的私鑰生成的數字證書來給程序簽名，而不能使用adt插件或者ant工具生成的調試證書來發布
• 數字證書都是有有效期的，Android只是在應用程序安裝的時候才會檢查證書的有效期。如果程序已經安裝在系統中，即使證書過期也不會影響程序的正常功能

新特性

• Android5.0新特性
  • MaterialDesign設計風格
  • 支持多種設備
  • 支持64位ART虛擬機
• Android6.0新特性
  • 運行時權限
  • 大量漂亮流暢的動畫
  • 支持快速充電的切換
  • 支持文件夾拖拽應用
  • 相機新增專業模式
• Android7.0新特性
  • 分屏多任務
  • 增強的Java8語言模式
  • 夜間模式
• Android8.0新特性
  • 畫中畫模式

如何避免Overdraw

• 合理選擇控件容器：LinearLayout易用，效率高，表達能力有限。RelativeLayout復雜，表達能力強，效率稍遜
• 去掉window的默認背景：可以在onCreate()中setContentView()之后調用getWindow().setBackgroundDrawable(null);或者在theme中添加android:windowbackground="null"；
• 去掉其他不必要的背景
• ViewStu延時加載布局
• Merge減少層級的嵌套

SparseArray

• 是稀疏數組，為了節省內存空間，并且不影響數組中原有的內容值，采用一種壓縮的方式來表示稀疏數組的內容
• SparseArray是android里為<Interger,Object>這樣的Hashmap而專門寫的類,目的是提高內存效率
• 避免了自動裝箱（auto-boxing）
• 數據結構不會依賴于外部對象映射，用數組數據結構來保存映射，然后通過折半查找來找到對象
• 一般來說，SparseArray執行效率比HashMap要慢一點，因為查找需要折半查找，而添加刪除則需要在數組中執行，而HashMap都是通過外部映射。但相對來說影響不大，最主要是SparseArray不需要開辟內存空間來額外存儲外部映射，從而節省內存

Jar和Aar的區別

• Jar包里面只有代碼，aar里面不光有代碼還包括代碼還包括資源文件，比如 drawable 文件，xml 資源文件。對于一些不常變動的 Android Library，我們可以直接引用 aar，加快編譯速度

ART和Dalvik區別

• Dalvik：
  • Dalvik是Google公司自己設計用于Android平臺的Java虛擬機
  • .dex格式是專為Dalvik應用設計的一種壓縮格式，工作在寄存器
  • Dalvik經過優化，允許在有限的內存中同時運行多個虛擬機的實例，并且每一個Dalvik應用作為獨立的Linux進程執行
  • 獨立的進程可以防止在虛擬機崩潰的時候所有程序都被關閉
• ART：
  • Dalvik是依靠一個Just-In-Time(JIT)編譯器去解釋字節碼，開發者編譯后的應用代碼需要通過一個解釋器在用戶的設備上運行，并不高效
  • ART在應用安裝的時候就預編譯字節碼到機器語言，這一機制叫Ahead-Of-Time(AOT)編譯，在移除解釋代碼這一過程后，應用程序執行將更有效率，啟動更快
  • ART優點：1.系統性能的顯著提升應用啟動更快、2. 運行更快、3. 體驗更流暢、觸感反饋更及時、4. 更長的電池續航能力支持更低的硬件
  • ART缺點：1. 更大的存儲空間占用、2. 可能會增加10%-20%更長的應用安裝時間
• 區別：
  • ART：Ahead of Time ，Dalvik: Just in Time
  • ART上應用啟動快，運行快，但是耗費更多存儲空間，安裝時間長，總的來說ART的功效就是”空間換時間”