安卓部分
1. 安卓跨進程通信(IPC)的幾種方式
- Bundle:四大組件間的進程間通信方式,簡單易用,但傳輸的數據類型受限。
- 文件共享: 不適合高併發場景,並且無法做到進程間的及時通信。
- Messenger: 數據通過Message傳輸,只能傳輸Bundle支持的類型。
- ContentProvider:android 系統提供的,簡單易用,但使用受限,只能根據特定規則訪問數據。
- AIDL:功能強大,支持實時通信,但使用稍微複雜。
- Socket:網絡數據交換的常用方式。
https://www.sohu.com/a/314677281_216613
2. View和SurfaceView的區別
- view只能在主線程中更新UI,不能在子線程中更新,而SurfaceView可以在任何線程中更新UI;
- SurfaceView可以控制幀數,執行動畫效率View的高;
- SurfaceView是放在最底層,可以在它上邊添加一些層,而且不能是透明的;
https://www.jianshu.com/p/6d39ce9e4f9b
3. View的繪製原理
- View的繪製過程就是從ViewRoot的performTraversals方法開始的,它經過measure、layout、draw三個過程才能最終將一個View繪製出來:
- measure用來測量View的寬和高。
- layout用來確定View在父容器中放置的位置。
- draw用來將view繪製在屏幕上。
https://blog.csdn.net/u014316462/article/details/52054352
4. 簡述JNI
- JNI翻譯過來就是java本地接口,它相當於一個媒介,使得java代碼能夠和其它語言寫的代碼進行交互
- 把app一些重要的算法邏輯用c/c++來寫,通過JNI來調用,可以加大被人反編譯破解apk的難度
- 通過JNI可以移植一些其它語言寫好的功能,比如:ffmpeg音視頻解碼庫
5. 簡述TCP/IP,HTTP,HTTPS,TCP,UDP,Socket
- TCP/IP 是互聯網相關的各類協議族的總稱,比如:TCP,UDP,IP,FTP,HTTP,ICMP,SMTP 等都屬於 TCP/IP 族內的協議。像這樣把與互聯網相關聯的協議集合起來總稱爲 TCP/IP。
- TCP/IP 參考模型:這一網絡協議共分爲四層:數據鏈路層、網絡層、傳輸層和應用層。在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。在傳輸層中有TCP協議與UDP協議。在應用層有HTTP,FTP、TELNET、SMTP、DNS等協議。
- HTTP全稱是HyperText Transfer Protocal,即:超文本傳輸協議,HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束後,會主動釋放連接。從建立連接到關閉連接的過程稱爲“一次連接”。
- HTTPS(Secure Hypertext Transfer Protocol)安全超文本傳輸協議。 它是一個安全通信通道HTTPS是HTTP over SSL/TLS,HTTP是應用層協議,TCP是傳輸層協議,在應用層和傳輸層之間,增加了一個安全套接層SSL/TLS:
- SSL (Secure Socket Layer,安全套接字層)
- TLS (Transport Layer Security,傳輸層安全協議)
- SSL使用40 位關鍵字作爲RC4流加密算法
- TCP(Transmission Control Protocol)協議全稱是傳輸控制協議,是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。TCP 是面向連接的、可靠的流協議。
- UDP User Datagram Protocol)協議全稱是用戶數據報協議,在網絡中它與 TCP 協議一樣用於處理數據包,是一種無連接的協議,提供面向事務的簡單不可靠信息傳送服務。
- socket只是一種連接模式,不是協議,socket是對TCP/IP協議的封裝,Socket本身並不是協議,而是一個調用接口(API),通過Socket,我們才能使用TCP/IP協議。
https://blog.csdn.net/WHB20081815/article/details/67640804
https://blog.csdn.net/chaoshenzhaoxichao/article/details/79785318
6. Https和Http的區別
- https協議需要到CA申請證書。
- http是超文本傳輸協議,信息是明文傳輸;https 則是具有安全性的ssl加密傳輸協議。
- http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,後者是443。
- http的連接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。
https://www.cr173.com/Guide/302667_1.html
7. TCP和UDP的區別
- TCP 是面向連接的,UDP 是面向無連接的
- UDP程序結構較簡單
- TCP 是面向字節流的,UDP 是基於數據報的
- TCP 保證數據正確性,UDP 可能丟包
- TCP 保證數據順序,UDP 不保證
https://blog.csdn.net/zhang6223284/article/details/81414149
8. android的消息機制
- android的消息機制指的是Handler的運行機制,主要通過四個類來完成,分別是:Handler,Message,MessegeQuque,Looper來完成
- 它的運行流程是這樣的,首先在主線程中創建Handler,然後在分線程中使用handler.sendMessage()方法把消息發送到MessegeQuque中,MessegeQuque以隊列的形式保存消息,Looper一直以輪詢的方式一直監聽着消息隊列,一旦消息隊列有消息,就把他提取出來,交給主線程的handler來處理,這樣就完成了一次消息運轉
https://blog.csdn.net/wsq_tomato/article/details/80301851
9. handler爲什麼出現內存泄漏?
- 首先Handler使用是用來進行線程間通信的,所以新開啓的線程是會持有Handler引用的,如果在Activity等中創建Handler,並且是非靜態內部類的形式,就有可能造成內存泄漏。
- 首先,非靜態內部類是會隱式持有外部類的引用,所以當其他線程持有了該Handler,線程沒有被銷燬,則意味着Activity會一直被Handler持有引用而無法導致回收。
- 同時,MessageQueue中如果存在未處理完的Message,Message的target也是對Activity等的持有引用,也會造成內存泄漏。
- 解決的辦法:
- 使用靜態內部類+弱引用的方式:靜態內部類不會持有外部類的的引用,當需要引用外部類相關操作時,可以通過弱引用還獲取到外部類相關操作,弱引用是不會造成對象該回收回收不掉的問題.
- 在外部類對象被銷燬時,將MessageQueue中的消息清空。例如,在Activity的onDestroy時將消息清空。
https://blog.csdn.net/wsq_tomato/article/details/80301851
10. Activity的啓動模式
- standard模式是Activity默認的啓動模式, 在此模式下,每次啓動新的Activity時,都會進入任務棧,並處於任務棧的棧頂。而且,在該模式下,系統不會判斷該Activity在棧中是否真實存在,每次啓動時都會選擇創建一個新的實例。
- singleTop模式,大體上與standard模式類似,其中不同的是,如果啓動的Activity已經位於任務棧的棧頂時,則直接使用它,不用再去創建一個新的實例。但是如果啓動的Activity沒有位於任務棧的棧頂,則要去創建一個新的實例位於任務棧的棧頂。
- singleTask模式可以使Activity在整個應用程序種只存在一個實例。當指定爲該模式時,每次啓動Activity時,系統首先會檢查任務棧種是否存在該Activity的實例,若是存在則直接使用,並且會將當前Activity上的所有A
- ctivity出棧。若是沒有發現存在,則會創建一個新的實例。
- singleInstance模式,Activity在整個系統中都只有一個實例.當指定爲該模式時,Activity會啓動一個新的任務棧來管理這個Activity。
11. Activity和Fragment數據交互
- 構造方法的參數傳遞
- bundle傳遞
- 廣播
- 本地持久化存儲
- evenbus
- 接口回調
- viewmodel
- 靜態變量
12. okhttp的原理
https://blog.csdn.net/songzi1228/article/details/101050603
13. 事件的分發機制
事件的分發
上面的Log,是我手指按下去的時候打印出來的,這個時候我並沒有移動和擡起手指
所以順序是
1.進入activity的dispatchTouchEvent
2.事件傳遞進入viewgroup的dispatchTouchEvent
3.判斷攔截器
4.攔截器返回數據,不攔截,進入view
5.進入view的dispatchTouchEvent
6.進入view的onTouchEvent
7.返回view的onTouchEvent
8.返回viewgroup的onTouchEvent
9.返回activity的dispatchTouchEvent
14. 自定義view
- View的繪製流程
- 自定義控件:
- 1.組合控件。這種自定義控件不需要我們自己繪製,而是使用原生控件組合成的新控件。如標題欄。
- 2、繼承原有的控件。這種自定義控件在原生控件提供的方法外,可以自己添加一些方法。如製作圓角,圓形圖片。
- 3、完全自定義控件:這個View上所展現的內容全部都是我們自己繪製出來的。比如說製作水波紋進度條。
- View的繪製流程:OnMeasure()——>OnLayout()——>OnDraw()
- 第一步:OnMeasure():測量視圖大小。從頂層父View到子View遞歸調用measure方法,measure方法又回調OnMeasure。
- 第二步:OnLayout():確定View位置,進行頁面佈局。從頂層父View向子View的遞歸調用view.layout方法的過程,即父View根據上一步measure子View所得到的佈局大小和佈局參數,將子View放在合適的位置上。
- 第三步:OnDraw():繪製視圖。ViewRoot創建一個Canvas對象,然後調用OnDraw()。
作者:魔都_大白
鏈接:https://www.jianshu.com/p/7afb776a1ea3
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯繫作者獲得授權並註明出處。
15. Binder機制
1、首先 Binder 驅動在內核空間創建一個數據接收緩存區;
2、接着在內核空間開闢一塊內核緩存區,建立內核緩存區和內核中數據接收緩存區之間的映射關係,以及內核中數據接收緩存區和接收進程用戶空間地址的映射關係;
3、發送方進程通過系統調用 copy_from_user() 將數據 copy 到內核中的內核緩存區(通過序列化,反序列化拷貝),由於內核緩存區和接收進程的用戶空間存在內存映射,因此也就相當於把數據發送到了接收進程的用戶空間,這樣便完成了一次進程間的通信。
作者:吳小博Toby
鏈接:https://www.jianshu.com/p/ab1cc84b0192
來源:簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。
16. 插件化、組件化、熱修復的原理
- 組件化:組件化開發就是將一個app分成多個模塊,每個模塊都是一個組件(Module),開發的過程中我們可以讓這些組件相互依賴或者單獨調試部分組件等,但是最終發佈的時候是將這些組件合併統一成一個apk,這就是組件化開發。
- 插件化:插件化架構下,每個業務模塊都是一個獨立可運行的APP,插件化顧名思義,更多是想把需要實現的模塊或功能當做一個獨立的提取出來,減少宿主的規模,當需要使用到相應的功能時再去加載相應的模塊。
- 熱修復:熱修復和插件化有一定的相同之處,他們都是從系統加載器的角度出發,無論是採用hook方式,亦或是代理方式或者是其他底層實現,都是通過“欺騙”Android 系統的方式來讓宿主正常的加載和運行插件(補丁)中的內容。插件化強調的是按需加載,動態更新。熱修復則是從修復bug的角度出發,強調的是在不需要二次安裝應用的前提下修復已知的bug。
作者:八分半
鏈接:https://www.jianshu.com/p/cdfba36245e8
來源:簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。
17. ARouter原理
- ARouter 是通過註解的方式結合android提供的啓動Activity的API實現頁面的跳轉及參數的傳遞的。
- 路由框架會在項目的編譯期通過註解處理器apt掃描所有添加@Route註解的Activity類,然後將Route註解中的path地址和Activity.class文件映射關係保存到它自己生成的java文件中,只要拿到了映射關係便能拿到Activity.class。、
- 最後通過Android提供的啓動Activity的api來進行啓動activity
http://www.pianshen.com/article/8521186521/
18. HTTPS工作原理
採用對稱加密對數據進行加密,然後將加密後的數據data和密鑰key一起傳給服務器,服務器根據key對數據進行解密。
19. Android 中的線程有那些,原理與各自特點
https://blog.csdn.net/merbn/article/details/88609668
20. Rxjava
21. 常見的設計模式
- 單例模式
- Builder模式
- 策略方法模式
- 工廠方法模式
- 觀察者模式
- 組合模式
- 適配模式
- 模板方法模式
- 代理模式
https://www.cnblogs.com/kma-3/p/7096057.html
22. AsyncTask是串行還是並行執行?
串行執行
23. AMS,WMS,PMS 創建過程
24. LruCache使用極其原理
LruCache算法就是Least Recently Used,也就是最近最少使用算法。
他的算法就是當緩存空間滿了的時候,將最近最少使用的數據從緩存空間中刪除以增加可用的緩存空間來緩存新內容。
這個算分的內部有一個緩存列表。每當一個緩存數據被訪問的時候,這個數據就會被提到列表頭部,每次都這樣的話,列表的尾部數據就是最近最不常使用的了,當緩存空間不足時,就會刪除列表尾部的緩存數據。
————————————————
版權聲明:本文爲CSDN博主「喵了個嗚s」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/qq_25806863/article/details/77548468
25. 如何避免OOM?(安卓的內存優化)
- 從三個方面來講,第一,減少對象的內存佔用,第二,內存對象的重複利用,第三,避免對象的內存泄漏
- 減少對象的內存佔用
- 使用更加輕量的數據結構
- 避免在android裏面使用Enum
- 減少Bitmap對象的內存佔用
- 使用更小的圖片
- 內存對象的重複利用
- 複用系統自帶的資源
- 注意在ListView/GridView等出現大量重複子組件的視圖裏對ConvertView的複用
- Bitmap對象的複用
- 避免在自定義view的onDraw方法裏面執行對象的創建
- 使用StringBuilder來對字符串頻繁的拼接
- 避免對象的內存泄漏
- 注意Activity的泄露,內部類引用導致Activity的泄漏
- Activity Context被傳遞到其他實例中,這可能導致自身被引用而發生泄漏。
- 注意臨時Bitmap對象的及時回收
- 注意監聽器的註銷
- 注意緩存容器中的對象泄漏
- 注意WebView的泄露
- 注意Cursor對象是否及時關閉
https://www.jianshu.com/p/6cbd5bc49464
26. 如何實現進程保活
這個有點不太瞭解,以前有做過,不知道現在還能不能用,就是啓動兩三個進程在後臺兩兩監聽,其中一個掛了,其餘的進程知道了就再重啓那個進程,大概是這樣
27. 說下冷啓動和熱啓動
- app冷啓動: 當應用啓動時,後臺沒有該應用的進程,這時系統會重新創建一個新的進程分配給該應用, 這個啓動方式就叫做冷啓動(後臺不存在該應用進程)
- app熱啓動: 當應用已經被打開, 但是被按下返回鍵、Home鍵等按鍵時回到桌面或者是其他程序的時候,再重新打開該app時, 這個方式叫做熱啓動(後臺已經存在該應用進程)
28. ANR的原因
https://www.125la.com/955.html
29. 圖片的3級緩存原理
- 首先先從內存獲取圖片,如果內存有圖片那就直接顯示圖片
- 如果內存沒有圖片,那就從磁盤獲取圖片,並且把圖片加載到內存,並顯示出來
- 如果磁盤沒有圖片,那就從網絡獲取圖片,然後把圖片保存到磁盤,並且把圖片加載到內存,最後把圖片顯示出來
30. 說下AIDL的使用與原理
- 使用
- 服務端首先要創建一個Service用來監聽客戶端的鏈接請求,然後創建一個AIDL文件,將暴露給客戶端的接口在這個AIDL文件中聲明,最後在Service中實現這個AIDL接口即可。
- 客戶端做的事情比較簡單,首先需要綁定服務端的Service,綁定成功後,將服務端返回的Binder對象轉成AIDL接口所屬的類型,接着就可以調用AIDL中的方法了
- 原理
31. 內存泄漏的場景和解決辦法
-
非靜態內部類的靜態實例
非靜態內部類會持有外部類的引用,如果非靜態內部類的實例是靜態的,就會長期的維持着外部類的引用,組織被系統回收,解決辦法是使用靜態內部類 -
多線程相關的匿名內部類和非靜態內部類
匿名內部類同樣會持有外部類的引用,如果在線程中執行耗時操作就有可能發生內存泄漏,導致外部類無法被回收,直到耗時任務結束,解決辦法是在頁面退出時結束線程中的任務 -
Handler內存泄漏
Handler導致的內存泄漏也可以被歸納爲非靜態內部類導致的,Handler內部message是被存儲在MessageQueue中的,有些message不能馬上被處理,存在的時間會很長,導致handler無法被回收,如果handler是非靜態的,就會導致它的外部類無法被回收,解決辦法是1.使用靜態handler,外部類引用使用弱引用處理2.在退出頁面時移除消息隊列中的消息 -
Context導致內存泄漏
根據場景確定使用Activity的Context還是Application的Context,因爲二者生命週期不同,對於不必須使用Activity的Context的場景(Dialog),一律採用Application的Context,單例模式是最常見的發生此泄漏的場景,比如傳入一個Activity的Context被靜態類引用,導致無法回收 -
靜態View導致泄漏
使用靜態View可以避免每次啓動Activity都去讀取並渲染View,但是靜態View會持有Activity的引用,導致無法回收,解決辦法是在Activity銷燬的時候將靜態View設置爲null(View一旦被加載到界面中將會持有一個Context對象的引用,在這個例子中,這個context對象是我們的Activity,聲明一個靜態變量引用這個View,也就引用了activity) -
WebView導致的內存泄漏
WebView只要使用一次,內存就不會被釋放,所以WebView都存在內存泄漏的問題,通常的解決辦法是爲WebView單開一個進程,使用AIDL進行通信,根據業務需求在合適的時機釋放掉 -
資源對象未關閉導致
如Cursor,File等,內部往往都使用了緩衝,會造成內存泄漏,一定要確保關閉它並將引用置爲null -
集合中的對象未清理
集合用於保存對象,如果集合越來越大,不進行合理的清理,尤其是入股集合是靜態的 -
Bitmap導致內存泄漏
bitmap是比較佔內存的,所以一定要在不使用的時候及時進行清理,避免靜態變量持有大的bitmap對象 -
監聽器未關閉
很多需要register和unregister的系統服務要在合適的時候進行unregister,手動添加的listener也需要及時移除
查找內存泄漏可以使用Android Profiler工具或者利用LeakCanary工具。
————————————————
版權聲明:本文爲CSDN博主「csbhwy」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/wcsbhwy/article/details/89360469
32. ART和Dalvik區別
- 在Dalvik下,應用每次運行都需要通過即時編譯器(JIT)將字節碼轉換爲機器碼,即每次都要編譯加運行,這雖然會使安裝過程比較快,但是會拖慢應用以後每次啓動的效率。而在ART 環境中,應用在第一次安裝的時候,字節碼就會預編譯(AOT)成機器碼,這樣的話,雖然設備和應用的首次啓動(安裝慢了)會變慢,但是以後每次啓動執行的時候,都可以直接運行,因此運行效率會提高。
- ART佔用空間比Dalvik大(字節碼變爲機器碼之後,可能會增加10%-20%),這也是著名的“空間換時間大法"。
- 預編譯也可以明顯改善電池續航,因爲應用程序每次運行時不用重複編譯了,從而減少了 CPU 的使用頻率,降低了能耗。
————————————————
版權聲明:本文爲CSDN博主「SEU_Calvin」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/SEU_Calvin/article/details/52354964
33. 屏幕適配
- smallestWidth適配,或者叫sw限定符適配。指的是Android會識別屏幕可用高度和寬度的最小尺寸的dp值(其實就是手機的寬度值),然後根據識別到的結果去資源文件中尋找對應限定符的文件夾下的資源文件。
- smallestWidth的適配機制由系統保證,我們只需要針對這套規則生成對應的資源文件即可,不會出現什麼難以解決的問題,也根本不會影響我們的業務邏輯代碼,而且只要我們生成的資源文件分佈合理,,即使對應的smallestWidth值沒有找到完全對應的資源文件,它也能向下兼容,尋找最接近的資源文件。
- 這是比較成熟的方案了,也是我比較常用的屏幕適配方案
34. 安卓的性能優化
- 卡頓優化
- 內存優化
- 穩定性優化
- 耗電優化
- 安裝包大小優化
- 數據庫的優化
- 網絡優化
https://my.oschina.net/nicksong/blog/3043796
35. Serializable 和 Parcelable區別
- Serializable是java中的序列化接口,其使用起來簡單但是開銷很大,序列化和反序列化過程需要大量I/O操作。一般在保存數據到 SD 卡或者網絡傳輸時建議使用 Serializable 即可
- 而Parcelable是Android中序列化方式,一般在運行時數據傳遞時建議使用 Parcelable。,他的缺點就是使用起來稍微麻煩點,但是他的效率很高。
36. MVC、MVP、MVVM
- MVC:用戶的對View操作以後,View捕獲到這個操作,會把處理的權利交移給Controller(Pass calls);Controller接着會執行相關的業務邏輯,這些業務邏輯可能需要對Model進行相應的操作;當Model變更了以後,會通過觀察者模式(Observer Pattern)通知View;View通過觀察者模式收到Model變更的消息以後,會向Model請求最新的數據,然後重新更新界面。
- MVP:和MVC模式一樣,用戶對View的操作都會從View交移給Presenter。Presenter同樣的會執行相應的業務邏輯,並且對Model進行相應的操作;而這時候Model也是通過觀察者模式把自己變更的消息傳遞出去,但是是傳給Presenter而不是View。Presenter獲取到Model變更的消息以後,通過View提供的接口更新界面。
- MVVM:MVVM的調用關係和MVP一樣。但是,在ViewModel當中會有一個叫Binder,或者是Data-binding engine的東西。以前全部由Presenter負責的View和Model之間數據同步操作交由給Binder處理。你只需要在View的模版語法當中,指令式地聲明View上的顯示的內容是和Model的哪一塊數據綁定的。當ViewModel對進行Model更新的時候,Binder會自動把數據更新到View上去,當用戶對View進行操作(例如表單輸入),Binder也會自動把數據更新到Model上去。這種方式稱爲:Two-way data-binding,雙向數據綁定。
————————————————
版權聲明:本文爲CSDN博主「萬能程序者」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/SUPERIT1/article/details/83794598