當前位置：首頁 > 运维知识 > Android >内容正文

Android

android edittext不可复制_精选Android中高级面试题：性能优化，JNI，设计模式

發(fā)布時間：2024/1/23 Android 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 android edittext不可复制_精选Android中高级面试题：性能优化，JNI，设计模式小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

性能優(yōu)化

1、圖片的三級緩存中，圖片加載到內存中，如果內存快爆了，會發(fā)生什么？怎么處理？

參考回答：首先我們要清楚圖片的三級緩存是如何的：

如果內存足夠時不回收。內存不夠時就回收軟引用對象

2、內存中如果加載一張 500 * 500 的 png 高清圖片。應該是占用多少的內存？

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

3、WebView 的性能優(yōu)化？

參考回答：一個加載網(wǎng)頁的過程中，native、網(wǎng)絡、后端處理、CPU 都會參與，各自都有必要的工作和依賴關系；讓他們相互并行處理而不是相互阻塞才可以讓網(wǎng)頁加載更快：

WebView 初始化慢，可以在初始化同時先請求數(shù)據(jù)，讓后端和網(wǎng)絡不要閑著。
常用 JS 本地化及延遲加載，使用第三方瀏覽內核
后端處理慢，可以讓服務器分 trunk 輸出，在后端計算的同時前端也加載網(wǎng)絡靜態(tài)資源。
腳本執(zhí)行慢，就讓腳本在最后運行，不阻塞頁面解析。
同時，合理的預加載、預緩存可以讓加載速度的瓶頸更小。
WebView 初始化慢，就隨時初始化好一個 WebView 待用。
DNS 和鏈接慢，想辦法復用客戶端使用的域名和鏈接。

推薦文章：WebView 性能、體驗分析與優(yōu)化(https://tech.meituan.com/2017/06/09/webviewperf.html)

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

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

BitmapFactory 提供的加載圖片的四類方法(decodeFile、decodeResource、decodeStream、decodeByteArray)都支持 BitmapFactory.Options 參數(shù)，通過 inSampleSize 參數(shù)就可以很方便地對一個圖片進行采樣縮放

比如一張 10241024 的高清圖片來說。那么它占有的內存為 102410244，即 4MB，如果 inSampleSize 為 2，那么采樣后的圖片占用內存只有 512512*4, 即 1MB( 注意：根據(jù)最新的官方文檔指出，inSampleSize 的取值應該總是為 2 的指數(shù)，即 1、2、4、8 等等，如果外界輸入不足為 2 的指數(shù)，系統(tǒng)也會默認選擇最接近 2 的指數(shù)代替，比如 2)

綜合考慮。通過采樣率即可有效加載圖片，流程如下：

將 BitmapFactory.Options 的 inJustDecodeBounds 參數(shù)設為 true 并加載圖片
從 BitmapFactory.Options 中取出圖片的原始寬高信息，它們對應 outWidth 和 outHeight 參數(shù)
根據(jù)采樣率的規(guī)則并結合目標 View 的所需大小計算出采樣率 inSampleSize
將 BitmapFactory.Options 的 inJustDecodeBounds 參數(shù)設為 false，重新加載圖片

推薦文章：Android 高效加載大圖、多圖解決方案，有效避免程序OOM

(https://blog.csdn.net/guolin_blog/article/details/9316683)

5、內存回收機制與 GC 算法 (各種算法的優(yōu)缺點以及應用場景)；GC 原理時機以及 GC 對象？

內存判定對象可回收有兩種機制：

引用計數(shù)算法：給對象中添加一個引用計數(shù)器，每當有一個地方引用它時，計數(shù)器值就加 1；當引用失效時，計數(shù)器值就減 1；任何時刻計數(shù)器為 0 的對象就是不可能再被使用的。然而在主流的 Java 虛擬機里未選用引用計數(shù)算法來管理內存，主要原因是它難以解決對象之間相互循環(huán)引用的問題，所以出現(xiàn)了另一種對象存活判定算法。

可達性分析法：通過一系列被稱為『GCRoots』的對象作為起始點，從這些節(jié)點開始向下搜索，搜索所走過的路徑稱為引用鏈，當一個對象到 GC Roots 沒有任何引用鏈相連時，則證明此對象是不可用的。其中可作為 GC Roots 的對象：虛擬機棧中引用的對象，主要是指棧幀中的本地變量 *、本地方法棧中 Native 方法引用的對象、方法區(qū)中類靜態(tài)屬性引用的對象、方法區(qū)中常量引用的對象

GC 回收算法有以下四種：

分代收集算法：是當前商業(yè)虛擬機都采用的一種算法，根據(jù)對象存活周期的不同，將 Java 堆劃分為新生代和老年代，并根據(jù)各個年代的特點采用最適當?shù)氖占惴ā?/p>

新生代：大批對象死去，只有少量存活。使用『復制算法』，只需復制少量存活對象即可。

復制算法：把可用內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用盡后，把還存活著的對象『復制』到另外一塊上面，再將這一塊內存空間一次清理掉。實現(xiàn)簡單，運行高效。在對象存活率較高時就要進行較多的復制操作，效率將會變低

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

標記 - 清除算法：首先『標記』出所有需要回收的對象，然后統(tǒng)一『清除』所有被標記的對象。標記和清除兩個過程的效率都不高，清除之后會產(chǎn)生大量不連續(xù)的內存碎片，空間碎片太多可能會導致以后在程序運行過程中需要分配較大對象時，無法找到足夠的連續(xù)內存而不得不提前觸發(fā)另一次垃圾收集動作。

標記 - 整理算法：首先『標記』出所有需要回收的對象，然后進行『整理』，使得存活的對象都向一端移動，最后直接清理掉端邊界以外的內存。標記整理算法會將所有的存活對象移動到一端，并對不存活對象進行處理，因此其不會產(chǎn)生內存碎片

推薦文章：圖解 Java 垃圾回收機制(https://blog.csdn.net/justloveyou_/article/details/71216049)

6、內存泄露和內存溢出的區(qū)別？AS 有什么工具可以檢測內存泄露

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

7、性能優(yōu)化，怎么保證應用啟動不卡頓？黑白屏怎么處理？

應用啟動速度：取決于你在 application 里面時候做了什么事情，比如你集成了很多 sdk，并且 sdk 的 init 操作都需要在主線程里實現(xiàn)所以會有卡頓的感覺。在非必要的情況下可以把加載延后或則開啟子線程處理

另外，影響界面卡頓的兩大因素，分別是界面繪制和數(shù)據(jù)處理：

布局優(yōu)化 (使用 include，merge 標簽，復雜布局推薦使用 ConstraintLayout 等)
onCreate () 中不執(zhí)行耗時操作把頁面顯示的 View 細分一下，放在 AsyncTask 里逐步顯示，用 Handler 更好。這樣用戶的看到的就是有層次有步驟的一個個的 View 的展示，不會是先看到一個黑屏，然后一下顯示所有 View。最好做成動畫，效果更自然。
利用多線程的目的就是盡可能的減少 onCreate () 和 onReume () 的時間，使得用戶能盡快看到頁面，操作頁面。
減少主線程阻塞時間。
提高 Adapter 和 AdapterView 的效率。

推薦文章：Android 性能優(yōu)化之內存檢測、卡頓優(yōu)化、耗電優(yōu)化、APK 瘦身

(https://blog.csdn.net/csdn_aiyang/article/details/74989318)

黑白屏產(chǎn)生原因：當我們在啟動一個應用時，系統(tǒng)會去檢查是否已經(jīng)存在這樣一個進程，如果不存在，系統(tǒng)的服務會先檢查 startActivity 中的 intent 的信息，然后在去創(chuàng)建進程，最后啟動 Acitivy，即冷啟動。而啟動出現(xiàn)白黑屏的問題，就是在這段時間內產(chǎn)生的。系統(tǒng)在繪制頁面加載布局之前，首先會初始化窗口(Window)，而在進行這一步操作時，系統(tǒng)會根據(jù)我們設置的 Theme 來指定它的 Theme 主題顏色，我們在 Style 中的設置就決定了顯示的是白屏還是黑屏。

windowIsTranslucent 和 windowNoTitle，將這兩個屬性都設置成 true (會有明顯的卡頓體驗，不推薦)
如果啟動頁只是是一張圖片，那么為啟動頁專一設置一個新的主題，設置主題的 android:windowBackground 屬性為啟動頁背景圖即可
使用 layer-list 制作一張圖片 launcher_layer.xml，將其設置為啟動頁專一主題的背景，并將其設置為啟動頁布局的背景。

推薦文章：Android 啟動頁解決攻略

(https://blog.csdn.net/zivensonice/article/details/51691136)

8、強引用置為 null，會不會被回收？

參考回答：不會立即釋放對象占用的內存。如果對象的引用被置為 null，只是斷開了當前線程棧幀中對該對象的引用關系，而垃圾收集器是運行在后臺的線程，只有當用戶線程運行到安全點 (safe point) 或者安全區(qū)域才會掃描對象引用關系，掃描到對象沒有被引用則會標記對象，這時候仍然不會立即釋放該對象內存，因為有些對象是可恢復的(在 finalize 方法中恢復引用 )。只有確定了對象無法恢復引用的時候才會清除對象內存。

9、ListView 跟 RecyclerView 的區(qū)別：

動畫區(qū)別：

在 RecyclerView 中，內置有許多動畫 API，例如：notifyItemChanged (), notifyDataInserted (), notifyItemMoved () 等等；如果需要自定義動畫效果，可以通過實現(xiàn)(RecyclerView.ItemAnimator 類)完成自定義動畫效果，然后調用 RecyclerView.setItemAnimator ()；
但是 ListView 并沒有實現(xiàn)動畫效果，但我們可以在 Adapter 自己實現(xiàn) item 的動畫效果；

刷新區(qū)別：

ListView 中通常刷新數(shù)據(jù)是用全局刷新 notifyDataSetChanged ()，這樣一來就會非常消耗資源；本身無法實現(xiàn)局部刷新，但是如果要在 ListView 實現(xiàn)局部刷新，依然是可以實現(xiàn)的，當一個 item 數(shù)據(jù)刷新時，我們可以在 Adapter 中，實現(xiàn)一個 onItemChanged () 方法，在方法里面獲取到這個 item 的 position(可以通過 getFirstVisiblePosition ())，然后調用 getView () 方法來刷新這個 item 的數(shù)據(jù)；
RecyclerView 中可以實現(xiàn)局部刷新，例如：notifyItemChanged ()；

緩存區(qū)別：

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

JNI

1、對 JNI 是否了解？

參考回答：Java 的優(yōu)點是跨平臺，但也因為其跨平臺的的特性導致其本地交互的能力不夠強大，一些和操作系統(tǒng)相關的的特性 Java 無法完成，于是 Java 提供 JNI 專門用于和本地代碼交互，通過 JNI，用戶可以調用 C、C++ 編寫的本地代碼

NDK 是 Android 所提供的一個工具集合，通過 NDK 可以在 Android 中更加方便地通過 JNI 訪問本地代碼，其優(yōu)點在于：

提高代碼的安全性。由于 so 庫反編譯困難，因此 NDK 提高了 Android 程序的安全性
可以很方便地使用目前已有的 C/C++ 開源庫
便于平臺的移植。通過 C/C++ 實現(xiàn)的動態(tài)庫可以很方便地在其它平臺上使用
提高程序在某些特定情形下的執(zhí)行效率，但是并不能明顯提升 Android 程序的性能

2、如何加載 NDK 庫？如何在 JNI 中注冊 Native 函數(shù)，有幾種注冊方法？

public class JniTest{ //加載NDK庫 static{ System.loadLirary("jni-test"); }}

注冊 JNI 函數(shù)的兩種方法：

靜態(tài)方法
動態(tài)注冊

設計模式

1、你所知道的設計模式有哪些？

創(chuàng)建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問者模式、中介者模式、解釋器模式。

2、談談 MVC、MVP 和 MVVM，好在哪里，不好在哪里？

MVC：

視圖層 (View) 對應于 xml 布局文件和 java 代碼動態(tài) view 部分
控制層 (Controller) MVC 中 Android 的控制層是由 Activity 來承擔的，Activity 本來主要是作為初始化頁面，展示數(shù)據(jù)的操作，但是因為 XML 視圖功能太弱，所以 Activity 既要負責視圖的顯示又要加入控制邏輯，承擔的功能過多。
模型層 (Model)針對業(yè)務模型，建立數(shù)據(jù)結構和相關的類，它主要負責網(wǎng)絡請求，數(shù)據(jù)庫處理，I/O 的操作。

總結：具有一定的分層，model 徹底解耦，controller 和 view 并沒有解耦層與層之間的交互盡量使用回調或者去使用消息機制去完成，盡量避免直接持有 controller 和 view 在 android 中無法做到徹底分離，但在代碼邏輯層面一定要分清業(yè)務邏輯被放置在 model 層，能夠更好的復用和修改增加業(yè)務。

MVP：通過引入接口 BaseView，讓相應的視圖組件如 Activity，Fragment 去實現(xiàn) BaseView，實現(xiàn)了視圖層的獨立，通過中間層 Preseter 實現(xiàn)了 Model 和 View 的完全解耦。MVP 徹底解決了 MVC 中 View 和 Controller 傻傻分不清楚的問題，但是隨著業(yè)務邏輯的增加，一個頁面可能會非常復雜，UI 的改變是非常多，會有非常多的 case，這樣就會造成 View 的接口會很龐大。

MVVM：MVP 中我們說過隨著業(yè)務邏輯的增加，UI 的改變多的情況下，會有非常多的跟 UI 相關的 case，這樣就會造成 View 的接口會很龐大。而 MVVM 就解決了這個問題，通過雙向綁定的機制，實現(xiàn)數(shù)據(jù)和 UI 內容，只要想改其中一方，另一方都能夠及時更新的一種設計理念，這樣就省去了很多在 View 層中寫很多 case 的情況，只需要改變數(shù)據(jù)就行。

三者如何選擇？

如果項目簡單，沒什么復雜性，未來改動也不大的話，那就不要用設計模式或者架構方法，只需要將每個模塊封裝好，方便調用即可，不要為了使用設計模式或架構方法而使用。
對于偏向展示型的 app，絕大多數(shù)業(yè)務邏輯都在后端，app 主要功能就是展示數(shù)據(jù)，交互等，建議使用 mvvm。
對于工具類或者需要寫很多業(yè)務邏輯 app，使用 mvp 或者 mvvm 都可。

推薦文章：MVC、MVP、MVVM，我到底該怎么選？(https://juejin.im/post/5b3a3a44f265da630e27a7e6)

3、封裝 p 層之后。如果 p 層數(shù)據(jù)過大，如何解決？

參考回答：對于 MVP 模式來說，P 層如果數(shù)據(jù)邏輯過于臃腫，建議引入 RxJava 或則 Dagger，越是復雜的邏輯，越能體現(xiàn) RxJava 的優(yōu)越性。

推薦文章：RxJava+OkHttp+Retrofit+Dagger2+MVP 框架 (kotlin 版本)(https://juejin.im/post/5c6e601cf265da2dc675b69e#comment)

4、是否能從 Android 中舉幾個例子說說用到了什么設計模式？

AlertDialog、Notification 源碼中使用了 Builder(建造者)模式完成參數(shù)的初始化
Okhttp 內部使用了責任鏈模式來完成每個 Interceptor 攔截器的調用
RxJava 的觀察者模式；單例模式；GridView 的適配器模式；Intent 的原型模式
日常開發(fā)的 BaseActivity 抽象工廠模式

5、裝飾模式和代理模式有哪些區(qū)別？

參考回答：裝飾器模式與代理模式的區(qū)別就在于：

兩者都是對類的方法進行擴展，但裝飾器模式強調的是增強自身，在被裝飾之后你能夠在被增強的類上使用增強后的功能。
而代理模式則強調要讓別人幫你去做一些本身與你業(yè)務沒有太多關系的職責(記錄日志、設置緩存)代理模式是為了實現(xiàn)對象的控制，因為被代理的對象往往難以直接獲得或者是其內部不想暴露出來。

6、實現(xiàn)單例模式有幾種方法？懶漢式中雙層鎖的目的是什么？兩次判空的目的又是什么？

參考回答：單例模式實現(xiàn)方法有多種：餓漢，懶漢 (線程安全，線程非安全)，雙重檢查 (DCL), 內部類，以及枚舉。

所謂雙層檢驗鎖(在加鎖前后對實例對象進行兩次判空的檢驗)：加鎖是為了第一次對象實例化的線程同步，而鎖內還要有第二層判空是因為可能會有多個線程進入第一層 if 判斷內部，而在加鎖代碼塊外排隊等候，如果鎖內不進行第二次檢驗，仍然會出現(xiàn)實例化多個對象的情況。

推薦文章：單例模式的總結(https://xxxblank.github.io/2017/09/14/singleTon/)

7、用到的一些開源框架，介紹一個看過源碼的，內部實現(xiàn)過程。

參考回答：面試常客：Okhttp，Retrofit，Glide，RxJava，GreenDao，Dagger 等。

最后

今天關于面試的分享就到這里，還是那句話，有些東西你不僅要懂，而且要能夠很好地表達出來，能夠讓面試官認可你的理解，例如Handler機制，這個是面試必問之題。有些晦澀的點，或許它只活在面試當中，實際工作當中你壓根不會用到它，但是你要知道它是什么東西。

最后在這里小編分享一份自己收錄整理上述技術體系圖相關的幾十套騰訊、頭條、阿里、美團等公司19年的面試題，把技術點整理成了視頻和PDF(實際上比預期多花了不少精力)，包含知識脈絡 + 諸多細節(jié)，由于篇幅有限，這里以圖片的形式給大家展示一部分。

還有 高級架構技術進階腦圖、Android開發(fā)面試專題資料，高級進階架構資料幫助大家學習提升進階，也節(jié)省大家在網(wǎng)上搜索資料的時間來學習，也可以分享給身邊好友一起學習。

【Android核心高級技術PDF文檔，BAT大廠面試真題解析】

【算法合集】

【延伸Android必備知識點】

【Android部分高級架構視頻學習資源】

Android精講視頻領取學習后更加是如虎添翼！進軍BATJ大廠等(備戰(zhàn))！現(xiàn)在都說互聯(lián)網(wǎng)寒冬，其實無非就是你上錯了車，且穿的少(技能)，要是你上對車，自身技術能力夠強，公司換掉的代價大，怎么可能會被裁掉，都是淘汰末端的業(yè)務Curd而已！現(xiàn)如今市場上初級程序員泛濫，這套教程針對Android開發(fā)工程師1-6年的人員、正處于瓶頸期，想要年后突破自己漲薪的，進階Android中高級、架構師對你更是如魚得水，趕快領取吧！

【Android進階學習視頻】、【全套Android面試秘籍PDF】、【Android開發(fā)核心知識點筆記】可以私信我【安卓】免費獲取！

總結

以上是生活随笔為你收集整理的android edittext不可复制_精选Android中高级面试题：性能优化，JNI，设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：声光调制器实验研究_脉冲光抽运原子钟研究
下一篇： python字符串去头尾_悉尼大学某蒟蒻