1. Android四大組件及使用，
Activity :應用程式中，一個Activity通常就是一個單獨的螢屏，它上面可以顯示一些控制元件也可以監聽并處理用戶的事件做出回應，
BroadcastReceive廣播接收器:應用可以使用它對外部事件進行過濾只對感興趣的外部事件(如當電話呼入時，或者資料網路可用時)進行接收并做出回應，廣播接收器沒有用戶界面，然而，它們可以啟動一個activity或serice 來回應它們收到的資訊，或者用NotificationManager 來通知用戶，通知可以用很多種方式來吸參考戶的注意力──閃動背燈、震動、播放聲音等，一般來說是在狀態欄上放一個持久的圖示，用戶可以打開它并獲取訊息，
Service 服務:一個Service 是一段長生命周期的，沒有用戶界面的程式，可以用來開發如監控類程式，
Content Provider內容提供者 :android平臺提供了Content Provider使一個應用程式的指定資料集提供給其他應用程式，這些資料可以存盤在檔案系統中、在一個SQLite資料庫、或以任何其他合理的方式，
2. 螢屏適配，常用方案，
Android螢屏適配的發展
??1、dp直接適配
??2、寬高限定符適配
??3、UI適配框架Autolayout
目前最好的適配方案
??1、SmallestWidth適配（sw限定符適配）
??2、今日頭條適配方案
??3、AutoSize
3.布局優化，
- 使用工具檢測（Hierarchy Viewer）；
- 使用include 和merge標簽減少復用布局而產生的布局嵌套，使用ViewStub懶加載減少渲染元素；
- 診斷過度繪制，優化過度繪制
4. 懶加載有什么缺點，
- ViewStub物件只可以Inflate一次；
- ViewStub不支持merge
5. MVC、MVP、MVVM區別，
MVC的特點
它將資料、視圖、控制分開，實作了松耦合，
View將事件傳遞到Controller中
Controller完成想要業務后改變Model狀態
Model更新View
MVC的優點
實作了解耦合，修改其中一層時，不用修改另外兩層代碼
可維護性高，松耦合也就意味著維護起來更加方便
重用性高
MVC的缺點
由于控制元件的資料系結都需要在Activity中完成，Activity/Fragment在View與Controller的定義中有點模糊，
伴隨著業務的增加，Controller容易變得臃腫，
MVP的特點
View接受事件，傳遞給Presenter
Presenter做邏輯處理，修改Model
Model通知Presenter資料變化，Presenter更新View
MVP的優點
將Model與View完全分隔，提高了可擴展性，
便于測驗，在測驗Presenter時，只要實作View的介面并注入到Presenter就可以測驗Presenter的業務邏輯，
MVP的缺點
與MVC一樣，P層起到的控制功能伴隨著業務的增多，也會變得臃腫，
Presneter需要持有View的參考，同時View也需要持有Presenter的參考，控制上存在一定復雜度，
MVVM的特點
View接受事件，轉交給ViewModel
ViewModel操作Model更新資料
Model更新后通知ViewModel，ViewModel更新View資料
MVVM的優點
低耦合，由于ViewModel的存在,View可以獨立于Model變化與修改；同理，Model也可以獨立于View變化與修改，
可重用性，一個ViewModel可被多個View重復系結，實作同一組業務，
ViewModel中解決了MVP中V-P互相持有參考的問題，使得結構更清晰，簡潔
MVVM的缺點
ViewModel持有Model的依賴，
資料系結方式使得bug難以確定是在View中還是在Model中，
6.Glide加載大圖原理，如何防止記憶體溢位，
清單檔案可以增大系統分配給APP的最大記憶體，默認大概60M，
Android：盡量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設定一張大圖，
因為這些函式在完成decode后，最終都是通過java層的createBitmap來完成的，需要消耗更多記憶體，
因此，改用先通過BitmapFactory.decodeStream方法，創建出一個bitmap，再將其設為ImageView的 source，
decodeStream最大的秘密在于其直接呼叫JNI>>nativeDecodeAsset()來完成decode，
Glide：在加載圖片的時候，不要快取資源，如果可以獲取控制元件尺寸的話，可以控制加載的尺寸；
.skipMemoryCache(true) //禁止Glide記憶體快取
.diskCacheStrategy(DiskCacheStrategy.NONE) //不快取資源
7.記憶體優化，
常見的記憶體泄漏：
- 靜態參考（自身代碼和第三方代碼）
- 集合內參考
- Handler訊息未清除
- 非靜態的內部類中持有外部內的應用
- 匿名內部類/非靜態內部類和異步執行緒
實踐：
- 先解決程式中記憶體占用較大的業務模塊中的記憶體泄漏，不熟悉MAT的使用的可以看看這個
- 移除程式中多余的代碼和參考，這里使用默認的lint檢測再配合shrinkResources來洗掉無效資源
- 優化圖片，保證圖片放置在合理的檔案夾，根據View大小加載合適的圖片大小，根據手機狀態配置bitmap和回收策略
- 優化物件創建，比如string，使用物件池等
8.WebView和H5頁面優化
- 當App啟動的時候，就在Application里初始化一個Webview，對，就是直接new；當需要用的時候就直接取這個單例形式的webview去加載網頁，這樣就把webview初始化的等待時間變得用戶無感知；不過每次使用的時候需要清空上次使用的頁面內容
- 使用WebView快取
- H5頁面預加載
- HTML 應用程式快取機制
應用程式快取（簡稱 AppCache) 為 web 應用的離線訪問提供了支持，其原理是基于 manifest 屬性和 manifest 檔案，manifest 快取會一直保存，直到快取被清除，manifest 檔案被修改，或瀏覽器更新 AppCache，
- Monkey測驗，
- APP啟動流程，從點擊桌面圖示開始，
- 網路優化，
- APP卡頓處理，
- 怎么多渠道打包；分渠道不打包某些第三方包（比如在華為手機應用市場的apk不打包小米推送的jar包），
- 架構適配X86，ARM等，
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/332121.html
標籤：其他