2019中級Android開發社招面試解答之性能優化篇

注：由於實際開發與參考答案會有所不一樣，再者怕誤導你們，因此這些面試題答案仍是本身去理解！面試官會針對簡歷中提到的知識點由淺入深提問，因此不要背答案，多理解。

1.圖片的三級緩存中,圖片加載到內存中,若是內存快爆了,會發生什麼？怎麼處理？

參考回答：

• 首先咱們要清楚圖片的三級緩存是如何的

若是內存足夠時不回收。內存不夠時就回收軟引用對象

2.內存中若是加載一張500*500的png高清圖片.應該是佔用多少的內存?

參考回答：

• 不考慮屏幕比的話：佔用內存=500 500 4 = 1000000B ≈ 0.95MB
• 考慮屏幕比的的話：佔用內存= 寬度像素 x （inTargetDensity / inDensity） x 高度像素 x （inTargetDensity / inDensity）x 一個像素所佔的內存字節大小
• inDensity表示目標圖片的dpi（放在哪一個資源文件夾下），inTargetDensity表示目標屏幕的dpi

3.WebView的性能優化 ?

參考回答：
一個加載網頁的過程當中，native、網絡、後端處理、CPU都會參與，各自都有必要的工做和依賴關係；讓他們相互並行處理而不是相互阻塞纔可讓網頁加載更快：

• WebView初始化慢，能夠在初始化同時先請求數據，讓後端和網絡不要閒着。
• 經常使用 JS 本地化及延遲加載，使用第三方瀏覽內核
• 後端處理慢，可讓服務器分trunk輸出，在後端計算的同時前端也加載網絡靜態資源。
• 腳本執行慢，就讓腳本在最後運行，不阻塞頁面解析。
• 同時，合理的預加載、預緩存可讓加載速度的瓶頸更小。
• WebView初始化慢，就隨時初始化好一個WebView待用。
• DNS和連接慢，想辦法複用客戶端使用的域名和連接。

4.Bitmap如何處理大圖，如一張30M的大圖，如何預防OOM？

參考回答：避免OOM的問題就須要對大圖片的加載進行管理，主要經過縮放來減少圖片的內存佔用。

• BitmapFactory提供的加載圖片的四類方法（decodeFile、decodeResource、decodeStream、decodeByteArray）都支持BitmapFactory.Options參數，經過inSampleSize參數就能夠很方便地對一個圖片進行採樣縮放
• 好比一張10241024的高清圖片來講。那麼它佔有的內存爲102410244，即4MB，若是inSampleSize爲2，那麼採樣後的圖片佔用內存只有512512*4,即1MB（注意：根據最新的官方文檔指出，inSampleSize的取值應該老是爲2的指數，即一、二、四、8等等，若是外界輸入不足爲2的指數，系統也會默認選擇最接近2的指數代替，好比2）

綜合考慮。經過採樣率便可有效加載圖片，流程以下

• 將BitmapFactory.Options的inJustDecodeBounds參數設爲true並加載圖片
• 從BitmapFactory.Options中取出圖片的原始寬高信息，它們對應outWidth和outHeight參數
• 根據採樣率的規則並結合目標View的所需大小計算出採樣率inSampleSize
• 將BitmapFactory.Options的inJustDecodeBounds參數設爲false，從新加載圖片

5.內存回收機制與GC算法(各類算法的優缺點以及應用場景)；GC原理時機以及GC對象

參考回答：
內存斷定對象可回收有兩種機制：

• 引用計數算法：給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任什麼時候刻計數器爲0的對象就是不可能再被使用的。然而在主流的Java虛擬機裏未選用引用計數算法來管理內存，主要緣由是它難以解決對象之間相互循環引用的問題，因此出現了另外一種對象存活斷定算法。
• 可達性分析法：經過一系列被稱爲『GCRoots』的對象做爲起始點，從這些節點開始向下搜索，搜索所走過的路徑稱爲引用鏈，當一個對象到GC Roots沒有任何引用鏈相連時，則證實此對象是不可用的。其中可做爲GC Roots的對象：虛擬機棧中引用的對象，主要是指棧幀中的本地變量*、本地方法棧中Native方法引用的對象、方法區中類靜態屬性引用的對象、方法區中常量引用的對象

GC回收算法有如下四種：

• 分代收集算法：是當前商業虛擬機都採用的一種算法，根據對象存活週期的不一樣，將Java堆劃分爲新生代和老年代，並根據各個年代的特色採用最適當的收集算法。

• 新生代：大批對象死去，只有少許存活。使用『複製算法』，只需複製少許存活對象便可。

  • 複製算法：把可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用盡後，把還存活着的對象『複製』到另一塊上面，再將這一塊內存空間一次清理掉。實現簡單，運行高效。在對象存活率較高時就要進行較多的複製操做，效率將會變低

• 老年代：對象存活率高。使用『標記—清理算法』或者『標記—整理算法』，只需標記較少的回收對象便可

  • 標記-清除算法：首先『標記』出全部須要回收的對象，而後統一『清除』全部被標記的對象。標記和清除兩個過程的效率都不高，清除以後會產生大量不連續的內存碎片，空間碎片太多可能會致使之後在程序運行過程當中須要分配較大對象時，沒法找到足夠的連續內存而不得不提早觸發另外一次垃圾收集動做。
  • 標記-整理算法：首先『標記』出全部須要回收的對象，而後進行『整理』，使得存活的對象都向一端移動，最後直接清理掉端邊界之外的內存。標記整理算法會將全部的存活對象移動到一端，並對不存活對象進行處理，所以其不會產生內存碎片

6.內存泄露和內存溢出的區別 ？AS有什麼工具能夠檢測內存泄露

參考回答：

• 內存溢出(out of memory)：是指程序在申請內存時，沒有足夠的內存空間供其使用，出現out of memory；好比申請了一個integer，但給它存了long才能存下的數，那就是內存溢出。
• 內存泄露(memory leak)：是指程序在申請內存後，沒法釋放已申請的內存空間，一次內存泄露危害能夠忽略，但內存泄露堆積後果很嚴重，不管多少內存,早晚會被佔光。memory leak會最終會致使out of memory！
• 查找內存泄漏可使用Android Studio 自帶的AndroidProfiler工具或MAT

7.性能優化,怎麼保證應用啓動不卡頓? 黑白屏怎麼處理?
參考回答：

• 應用啓動速度，取決於你在application裏面時候作了什麼事情，好比你集成了不少sdk，而且sdk的init操做都須要在主線程裏實現因此會有卡頓的感受。在非必要的狀況下能夠把加載延後或則開啓子線程處理

• 另外，影響界面卡頓的兩大因素，分別是界面繪製和數據處理。

  • 佈局優化(使用include，merge標籤，複雜佈局推薦使用ConstraintLayout等)
  • onCreate() 中不執行耗時操做 把頁面顯示的 View 細分一下，放在 AsyncTask 裏逐步顯示，用 Handler 更好。這樣用戶的看到的就是有層次有步驟的一個個的 View 的展現，不會是先看到一個黑屏，而後一下顯示全部 View。最好作成動畫，效果更天然。
  • 利用多線程的目的就是儘量的減小 onCreate() 和 onReume() 的時間，使得用戶能儘快看到頁面，操做頁面。
  • 減小主線程阻塞時間。
  • 提升 Adapter 和 AdapterView 的效率

黑白屏產生緣由：當咱們在啓動一個應用時，系統會去檢查是否已經存在這樣一個進程，若是不存在，系統的服務會先檢查startActivity中的intent的信息，而後在去建立進程，最後啓動Acitivy，即冷啓動。而啓動出現白黑屏的問題，就是在這段時間內產生的。系統在繪製頁面加載佈局以前，首先會初始化窗口（Window），而在進行這一步操做時，系統會根據咱們設置的Theme來指定它的Theme 主題顏色，咱們在Style中的設置就決定了顯示的是白屏仍是黑屏。

• windowIsTranslucent和windowNoTitle，將這兩個屬性都設置成true (會有明顯的卡頓體驗，不推薦)
• 若是啓動頁只是是一張圖片，那麼爲啓動頁專注設置一個新的主題，設置主題的android:windowBackground屬性爲啓動頁背景圖便可
• 使用layer-list製做一張圖片launcher_layer.xml，將其設置爲啓動頁專注主題的背景，並將其設置爲啓動頁佈局的背景。

8.強引用置爲null，會不會被回收？

參考回答：
不會當即釋放對象佔用的內存。 若是對象的引用被置爲null，只是斷開了當前線程棧幀中對該對象的引用關係，而 垃圾收集器是運行在後臺的線程，只有當用戶線程運行到安全點(safe point)或者安全區域纔會掃描對象引用關係，掃描到對象沒有被引用則會標記對象，這時候仍然不會當即釋放該對象內存，由於有些對象是可恢復的（在 finalize方法中恢復引用 ）。只有肯定了對象沒法恢復引用的時候纔會清除對象內存。

9.ListView跟RecyclerView的區別

參考回答：
動畫區別：

• 在RecyclerView中，內置有許多動畫API，例如：notifyItemChanged(), notifyDataInserted(), notifyItemMoved()等等；若是須要自定義動畫效果，能夠經過實現（RecyclerView.ItemAnimator類）完成自定義動畫效果，而後調用RecyclerView.setItemAnimator()；
• 可是ListView並無實現動畫效果，但咱們能夠在Adapter本身實現item的動畫效果；

刷新區別：

• ListView中一般刷新數據是用全局刷新notifyDataSetChanged()，這樣一來就會很是消耗資源；自己沒法實現局部刷新，可是若是要在ListView實現局部刷新，依然是能夠實現的，當一個item數據刷新時，咱們能夠在Adapter中，實現一個onItemChanged()方法，在方法裏面獲取到這個item的position（能夠經過getFirstVisiblePosition()），而後調用getView()方法來刷新這個item的數據；
• RecyclerView中能夠實現局部刷新，例如：notifyItemChanged()；

緩存區別：

• RecyclerView比ListView多兩級緩存，支持多個離ItemView緩存，支持開發者自定義緩存處理邏輯，支持全部RecyclerView共用同一個RecyclerViewPool(緩存池)。
• ListView和RecyclerView緩存機制基本一致，但緩存使用不一樣

10.ListView的adapter是什麼adapter
參考回答：

• BaseAdapter：抽象類，實際開發中咱們會繼承這個類而且重寫相關方法，用得最多的一個適配器！
• ArrayAdapter：支持泛型操做，最簡單的一個適配器，只能展示一行文字〜
• SimpleAdapter：一樣具備良好擴展性的一個適配器，能夠自定義多種效果！
• SimpleCursorAdapter：用於顯示簡單文本類型的listView，通常在數據庫那裏會用到，不過有點過期，不推薦使用！

11.LinearLayout、FrameLayout、RelativeLayout性能對比，爲何？
參考回答：

• RelativeLayout會讓子View調用2次onMeasure，LinearLayout 在有weight時，也會調用子 View 2次onMeasure
• RelativeLayout的子View若是高度和RelativeLayout不一樣，則會引起效率問題，當子View很複雜時，這個問題會更加嚴重。若是能夠，儘可能使用padding代替margin。
• 在不影響層級深度的狀況下,使用LinearLayout和FrameLayout而不是RelativeLayout。

到此性能優化篇就完了，若是須要更多面試資料和更多Android知識的能夠加個人 QQ合做羣：925019412