飲一杯茶，刷刷題聽聽別人的建議，面試足矣

時間 2020-05-18

原文原文鏈接

前言

其實對於不少人來講，都和我原來有一樣一個疑慮：到底去大廠仍是創業型公司？去大公司一個蘿蔔一個坑，要往上走須要運氣+實力足夠好才能脫穎而出，創業型公司，可能更容易實現本身的想法和舞臺，能把能力表現的淋漓盡致，但是會碰到更多的問題，公司經營不下去了怎麼辦？薪資待遇不如大廠？java

一丶大廠offer？

我相信每一個程序員的夢想都是獲得大廠的offer，我以爲這很正常，這並非咱們的飯後談資而是每一個技術人的追求。像阿里、騰訊、美團、字節跳動、京東等等的技術氛圍與技術規範度仍是要明顯優於一些創業型公司/小公司，若是說可以在這樣的公司鍛鍊幾年，相信對本身能力的提高仍是很是大的。但不是每一個人都可以進入大廠的，這每每取決於咱們的能力、學歷、面試表現等因素。git

如今面試大公司你說你沒有架構開發經驗估計都拿不出手，熱修復，框架，glide，OKHTTP，flutter，NDK，音視頻~源碼原理等等已然大廠面試所必須的知識。可是，你真進入大廠了，可能幾年都用不上這些知識，仍是老老實實去寫代碼。程序員

二丶抱怨不如努力提高自我

相比於前幾年來講，如今的面試難度提高了很多。你說說如今程序員這麼多，你投遞的公司可能與你一塊兒投遞的就有300人，可人家只招5人，那怎麼辦？簡歷PASS掉一大批，而後面試再PASS掉一大批。從這樣來看，如今流行說的：「面試造火箭，工做擰螺絲」仍是頗有道理的，提升面試難度只是爲了從不少人中招到本身須要的那些人。github

不少人都抱怨如今工做愈來愈難找了，的確，互聯網行業如今確實沒有以前好找工做了。我以爲有面試

1丶很大一部分對本身的技術的認識還停留在過去的那一兩年，
2丶是半路出家的人的基礎確定是沒有大學習踏實學習計算機知識的人好的，這就形成不少培訓班出生的人很難往前走；
3丶是互聯網行業確實對年輕的人有一部分偏心，畢竟剛畢業的大學生仍是比較廉價的，可是互聯網行業並非吃青春飯。
4.市場逐漸趨於完善，每一個崗位對技術的要求愈來愈嚴謹，形成一種飽和不缺人的現象。
5.高級開發越來卻越缺人，中低級市場飽和

因此，無論是應屆生仍是工做幾年的小夥伴都要對本身有一個清晰的認識，搞清楚你本身所欠缺的能力，搞清楚你本身的優點(企業爲何要招你)。知道本身不足的地方以後，就要去努力！算法

互聯網行業其實仍是挺公平的，雖然面試的時候會將你的學歷做爲參考，可是若是你的能力真的厲害，你的簡歷真的豐富的話，面試官仍是會很欣賞這樣的應聘者的。api

三丶如何清晰的認知本身的不足，提高我的實力

我在這裏所說的我的硬實力更多的指的是我的的專業能力，好比構建高質量網站的能力或者是對專業知識的掌握程度。緩存

我以爲不管是對於新手仍是老手，想要提升我的硬實力最重要的就是不斷深刻學習而且將理論實踐，最好能夠將理論在具體項目中實踐一下。安全

給還在學校的同窗們一個建議：若是條件容許的話儘可能去參加一些比賽，可能你的技術並不太好，你的心裏還很猶豫本身是否是具有參加比賽的能力，可是我仍是推薦你去嘗試一下。服務器

爲何呢？一個比賽的準備時間，說長點就是 5 ~ 6 個月，說短點也就是 2 ~ 3 個月。在參加這個比賽以前，比賽用到的不少技術你可能沒有實際應用過，甚至連聽都沒有聽過。可是這幾個月的時間應該足夠讓你去學習了，若是你的態度好而且自學能力不差的話通常是沒有問題的。

到了最後，你可能並無收穫到一個優秀的名次，可是我以爲參加比賽的經歷對你的幫助纔是最大的。若是後面你還會參加其餘比賽的話，我以爲你必定會作的愈來愈好。

除了比賽，實際項目對本身的我的能力提高與鍛鍊也是很是大的。

多去實踐，將學到的東西運用到實際項目中去。不少人都找我抱怨過沒有實際項目讓本身去作。下面我會介紹到幾種讓你能夠有項目經驗的方式，項目經驗對於技術能力的提高和麪試都是很重要的。

想要提升我的硬實力，那麼學習一門新技術的方法必定是相當重要了。

必定要有本身的技術優點，可能你懂得不是最多的，可是別人不會的你卻會，那麼你就是厲害的！

四丶寫簡歷的時候項目經驗這欄，怎麼纔有項目經驗

若是實在沒有實際項目讓你去作，我以爲你能夠經過下面幾種方式：

1.在網上找一個符合本身能力與找工做需求的實戰項目視頻或者博客跟着老師一塊兒作。作的過程當中，你要有本身的思考，不要淺嘗輒止，對於不少知識點，別人的講解可能只是知足項目就夠了，你本身想多點知識的話，對於重要的知識點就要本身學會去往深出學。
2.Github或者碼雲上面有不少實戰類別項目，你能夠選擇一個來研究，爲了讓本身對這個項目更加理解，在理解原有代碼的基礎上，你能夠對原有項目進行改進或者增長功能。
3.本身動手去作一個本身想完成的東西，遇到不會的東西就臨時去學，現學現賣。

簡歷

華爲Android開發工程師

阿里

公司到底想要什麼樣的人才?
我的方面：人品好，與公司以及團隊文化契合，學習能力不錯，抗壓；
能力方面： 能力與你要應聘的崗位所匹配（不少時候不要認爲本身能力很強公司就會招聘你，這意味着公司可能會花更多的錢聘用你。若是你的能力達不到的話，公司通常還會考慮你的潛力如何）；

面試注意：

1.提早準備好自我介紹
2.提早準備技術面試
3.面試以前作好定向複習
4.面試覆盤
5.提早知道有哪些技術問題常問，以及非技術問題

五丶面試，刷題

1.Glide的緩存機制

Glide的緩存機制，主要分爲2種緩存，一種是內存緩存，一種是磁盤緩存。

使用內存緩存的緣由是： 防止應用重複將圖片讀入到內存，形成內存資源浪費。

使用磁盤緩存的緣由是： 防止應用重複的從網絡或者其餘地方下載和讀取數據。

具體來說，緩存分爲加載和存儲：

當加載一張圖片的時候，獲取順序：Lru算法緩存-》弱引用緩存-》磁盤緩存（若是設置了的話）。

當想要加載某張圖片時，先去LruCache中尋找圖片，若是LruCache中有，則直接取出來使用，並將該圖片放入WeakReference中，若是LruCache中沒有，則去WeakReference中尋找，若是WeakReference中有，則從WeakReference中取出圖片使用，若是WeakReference中也沒有圖片，則從磁盤緩存/網絡中加載圖片。

將緩存圖片的時候，寫入順序：弱引用緩存-》Lru算法緩存-》磁盤緩存中。當圖片不存在的時候，先從網絡下載圖片，而後將圖片存入弱引用中，glide會採用一個acquired（int）變量用來記錄圖片被引用的次數，當acquired變量大於0的時候，說明圖片正在使用中，也就是將圖片放到弱引用緩存當中；若是acquired變量等於0了，說明圖片已經再也不被使用了，那麼此時會調用方法來釋放資源，首先會將緩存圖片從弱引用中移除，而後再將它put到LruResourceCache當中。這樣也就實現了正在使用中的圖片使用弱引用來進行緩存，不在使用中的圖片使用LruCache來進行緩存的功能。

另：從Glide4.x開始，讀取圖片的順序有所改變：弱引用緩存-》Lru算法緩存-》磁盤緩存

2.`ThreadLocal`的使用場景？與`Synchronized`相比有什麼特性？

ThreadLocal和Synchronized雖然都和多線程有關.
可是ThreadLocal是爲了多線程時,每一個線程對變量的獨立訪問.線程間該變量值互不影響.內部是由一個ThreadLocalMap,key爲當前線程的弱引用,value爲變量值.

Synchronized則是另外一個意思.多線程時經過同步鎖實現多個線程同時只能有一個線程對變量/方法訪問.

3.Kotlin中集合遍歷有哪幾種方式？

for,foreach,while,do while,遞歸,還有集合的高階方法

4.對於GIF 圖片加載有什麼思路和建議

gif圖實際上就是多幀合併的圖

參考Fresco內部實現：

View層使用一個Drawable，包含bitmap，並依據gif的信息不斷的更新並繪製bitmap
C層提供api功能，例如：輸入gif數據流，提供解析gif信息、更新bitmap等功能

5.爲何說Http是可靠的數據傳輸協議

HTTP是屬於應用層的協議，TCP（傳輸控制協議）和UDP（用戶數據報協議）是屬於傳輸層的協議。

咱們都知道TCP協議是面向鏈接的，每次進行鏈接都要進行三次握手和四次揮手，因此它的鏈接是可靠的。而HTTP是在TCP上層的協議，因此它也是可靠的。

那爲何TCP可靠？
首先來說一下網絡的分層，因特網協議能夠分爲五層，分別是：

應用層->傳輸層->網絡互聯層->網絡訪問層->物理層

或許你以爲很抽象，可是經過栗子你就會發現並無那麼複雜
如訪問一個Http請求:

怎麼訪問到這個網站呢？首先咱們須要經過網絡，多是移動網或者寬帶網等（這就是物理層，它是一個傳輸介質），而後找到對應那一臺被咱們訪問的服務器的mac地址（網絡訪問層）進行鏈接，再匹配它的IP（網絡互聯層）是否對應，肯定了主機後，再經過端口號9090（傳輸層）訪問對應的進程，因爲一個進程裏面有不少業務模塊，而咱們須要訪問main模塊（應用層），最終經過不一樣層來實現網站的訪問。

每一個層都是相互獨立，而且向下依賴，而傳輸層是能肯定惟一主機的，由於咱們能夠經過mac地址、host和端口來肯定惟一的一臺訪問主機上面的進程。或許有的人會問，那若是網絡中斷呢？那不就不可靠了嗎，咱們常說的網絡中斷是屬於物理層，因爲是向下依賴，傳輸層的創建是依賴於下面的三層（網絡互聯層、網絡訪問層、物理層）已經鏈接成功，若是下面的層都沒有鏈接成功，也就沒有傳輸層這一說了，因此傳輸層協議是一個「靠譜」的協議。

咱們經過分層瞭解了傳輸層是「靠譜」的協議，那麼怎麼保證它是可靠的呢？

那就要講到三次握手和四次揮手的做用了。

三次握手就是在創建鏈接以前須要客戶端須要先給服務端發出SYN(c)報文，當服務器收到後須要返回客戶端ACK=SYN(c)+1，而且傳輸本身生成的SYN(s)給客戶端，客戶端收到後進入已鏈接狀態，須要再回一個ACK=SYN(s)+1給服務器，服務器收到ACK後也進入了鏈接狀態，這就是一個三次握手的過程，經過雙方進行三次通訊保證此時雙方都已經進入準備狀態。

四次揮手就是在結束鏈接的時候，客戶端會發送FIN(c)給服務器，服務器收到後回覆客戶端ACK=FIN(c)+1告知客戶端收到客戶端的結束請求了，這時客戶端就會進入CLOSING(半關閉狀態)，等待服務器的結束請求。在一段小延遲時間後，服務器也會發送一個FIN(s)請求給客戶端，客戶端收到後發送ACK=FIN(s)+1給服務器，服務器收到ACK後就進入技術狀態。客戶端在等待2個MSL（避免服務器收不到ACK）後也進入結束狀態。

在每次進行鏈接和斷開鏈接都須要通過複雜的三次握手和四次握手，從而保證了每一個鏈接都是可靠的，因此TCP協議是可靠的，而HTTP就是TCP上層的協議，全部鏈接都是基於TCP協議的。

在咱們可以肯定每一個請求對應的惟一主機和端口號，而且經過Http協議添加響應的請求數據信息（如模塊名字等）肯定請求的代碼位置，而且在每次請求都經過三次握手和四次揮手保證鏈接的可靠性，因此一個Http請求是可靠的。

6.如何繞過Android9.0針對反射的限制

雙重反射，即利用反射調用反射API，這個時候系統進行棧回溯，發現直接調用者是反射API，反射API也是系統API，就直接經過了

7.談一談Activity，View，Window三者的關係

在activity中調用attach，建立window；

建立的window是其子類phonewindow，在attach中建立phonewindow;

在activity中調用setcontentview(R.layout.xx);其實就是調用getwindow.setcontentview()

建立parentview；將指定的R.layout.xx佈局進行填充

調用viewgroup,調用viewGroup先移除removeAllview();在進行添加新的view --addview（）.

8.如何進行單元測試的？以及如何應用在MVP和MVVM中？

單元測試庫 junit mockito Rebolectric

說下mvp工程中的測試方法測試主要有三大部分

1. 普通工具類使用 junit 直接測試
2. mvp的p 使用 @mock標註view的接口, 初始化真正的p, 直接調用p的方法看看 verify view的某些方法是否按照預期被調用
3. mvp的v 用 rebolectric 去setup 一個Activity, 而後用這個庫找到界面上的按鈕,或者觸發生命週期( onstart),判斷一下當前界面的某些view是否被顯示或者 textview的值或者 dialog 是否顯示 toast是否彈出錯誤
4. 還有網絡部分的測試,能夠直接使用junit進行測試判斷下返回值是否符合預期