閒談：

從大二暑假的時候開始，一直想進騰訊或者阿裡，在招實習生的時候，最終遺憾落選。暑假的時候為了好好准備校招，我放棄了去步步高實習的機會，繼續在原來的一家公司實習。在暑假的時候找師兄師姐內推了騰訊，阿裡，最終都沒有通過簡歷篩選，沒有面試。說實話，剛開始內心是挺失落的，挺難受的，但經過一兩天的調整，我也意識到自己的錯誤，以前那種強烈想進bat的欲望漸漸淡了下來，當然並不是說不想進bat，只是不再那麼注重結果，更注重這奮斗過程中個人的成長。

360一面

差不多三十五分鐘

介紹你做過的項目 手寫單例模式 布局優化 有沒有用過什麼開源框架？ ImagLoader的實現原理 OnTouchEvent事件中 down事件 和up事件的傳遞 hashMap的實現 原理 LinkedHashMap的實現原理 內存管理及優化 點九圖

點九圖

https://isux.tencent.com/android-ui-9-png.html

放大後可以比較明顯的看到上下左右分別有一個像素的黑色線段，這裡分別標注了序號。簡單來說，

序號1和2標識了可以拉伸的區域，

序號3和4標識了內容區域。當設定了按鈕實際應用的寬和高之後，橫向會拉伸1區域的像素，縱向會拉伸2區域的像素。如下圖：<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPjxpbWcgYWx0PQ=="" src="/uploadfile/Collfiles/20160831/20160831091326386.png" title="\" />

這裡程序設置的文字垂直居中，水平居左的對齊方式。對齊方式是沒有問題的，但是對於這種大圓角同時又有些不規則邊框的的圖形來說，錯誤的標注方式會讓排版看起來很混亂。所以我們需要修正內容區域的線段位置和長度。

有兩點需要特別注意下：

1.最外圍的一圈像素必須要麼是純黑色，要麼是透明，一點點的半透明的像素都不可以有，比如說99%的黑色或者是1%的投影都不可以有;

2.文件的後綴名必須是.9.png，不能是.png或者是.9.png.png，這樣的命名都會導致編譯失敗。

內存管理及優化

我這裡答的是內存洩漏和oom
少用static靜態變量

1) 珍惜Services資源

我們知道service所在的Activity級別相對後台Activity的級別是比較 高的，一般不易被回收。
在service不再使用的時候，及時退出。最好的方法是使用IntentService

2）在UI不可見的時候釋放資源

當用戶切換到其它應用並且你的應用 UI不再可見時，你應該釋放你的應用UI上所占用的所有內存資源。在這個時候釋放UI資源可以顯著的增加系統緩存進程的能力，它會對用戶體驗有著很直接的影響。

為了能夠接收到用戶離開你的UI時的通知，你需要實現Activtiy類裡面的onTrimMemory()回調方法。你應該使用這個方法來監聽到TRIM_MEMORY_UI_HIDDEN級別的回調，此時意味著你的UI已經隱藏，你應該釋放那些僅僅被你的UI使用的資源。

請注意：你的應用僅僅會在所有UI組件的被隱藏的時候接收到onTrimMemory()的回調並帶有參數TRIM_MEMORY_UI_HIDDEN。這與onStop()的回調是不同的，onStop會在activity的實例隱藏時會執行，例如當用戶從你的app的某個activity跳轉到另外一個activity時前面activity的onStop()會被執行。因此你應該實現onStop回調，並且在此回調裡面釋放activity的資源，例如釋放網絡連接，注銷監聽廣播接收者。除非接收到onTrimMemory(TRIM_MEMORY_UI_HIDDEN))的回調，否者你不應該釋放你的UI資源。這確保了用戶從其他activity切回來時，你的UI資源仍然可用，並且可以迅速恢復activity。

3) 當內存緊張時釋放部分內存

關於onTrimMemory的介紹

在你的app生命周期的任何階段，onTrimMemory的回調方法同樣可以告訴你整個設備的內存資源已經開始緊張。你應該根據onTrimMemory回調中的內存級別來進一步決定釋放哪些資源。

TRIM_MEMORY_RUNNING_MODERATE：你的app正在運行並且不會被列為可殺死的。但是設備此時正運行於低內存狀態下，系統開始觸發殺死LRU Cache中的Process的機制。
TRIM_MEMORY_RUNNING_LOW：你的app正在運行且沒有被列為可殺死的。但是設備正運行於更低內存的狀態下，你應該釋放不用的資源用來提升系統性能（但是這也會直接影響到你的app的性能）。
TRIM_MEMORY_RUNNING_CRITICAL：你的app仍在運行，但是系統已經把LRU Cache中的大多數進程都已經殺死，因此你應該立即釋放所有非必須的資源。如果系統不能回收到足夠的RAM數量，系統將會清除所有的LRU緩存中的進程，並且開始殺死那些之前被認為不應該殺死的進程，例如那個包含了一個運行態Service的進程。
同樣，當你的app進程正在被cached時，你可能會接受到從onTrimMemory()中返回的下面的值之一:

TRIM_MEMORY_BACKGROUND: 系統正運行於低內存狀態並且你的進程正處於LRU緩存名單中最不容易殺掉的位置。盡管你的app進程並不是處於被殺掉的高危險狀態，系統可能已經開始殺掉LRU緩存中的其他進程了。你應該釋放那些容易恢復的資源，以便於你的進程可以保留下來，這樣當用戶回退到你的app的時候才能夠迅速恢復。
TRIM_MEMORY_MODERATE: 系統正運行於低內存狀態並且你的進程已經已經接近LRU名單的中部位置。如果系統開始變得更加內存緊張，你的進程是有可能被殺死的。
TRIM_MEMORY_COMPLETE: 系統正運行與低內存的狀態並且你的進程正處於LRU名單中最容易被殺掉的位置。你應該釋放任何不影響你的app恢復狀態的資源。
因為onTrimMemory()的回調是在API 14才被加進來的，對於老的版本，你可以使用onLowMemory)回調來進行兼容。onLowMemory相當與TRIM_MEMORY_COMPLETE。

Note: 當系統開始清除LRU緩存中的進程時，盡管它首先按照LRU的順序來操作，但是它同樣會考慮進程的內存使用量。因此消耗越少的進程則越容易被留下來。

4) 避免bitmaps的浪費

當你加載一個bitmap時，僅僅需要保留適配當前屏幕設備分辨率的數據即可，如果原圖高於你的設備分辨率，需要做縮小的動作。請記住，增加bitmap的尺寸會對內存呈現出2次方的增加，因為X與Y都在增加。

Note:在Android 2.3.x (API level 10)及其以下, bitmap對象的pixel data是存放在native內存中的，它不便於調試。然而，從Android 3.0(API level 11)開始，bitmap pixel data是分配在你的app的Dalvik heap中, 這提升了GC的工作效率並且更加容易Debug。因此如果你的app使用bitmap並在舊的機器上引發了一些內存問題，切換到3.0以上的機器上進行Debug。

5) 使用優化的數據容器

利用Android Framework裡面優化過的容器類，例如SparseArray, SparseBooleanArray, 與 LongSparseArray。 通常的HashMap的實現方式更加消耗內存，因為它需要一個額外的實例對象來記錄Mapping操作。另外，SparseArray更加高效在於他們避免了對key與value的autobox自動裝箱，並且避免了裝箱後的解箱。

6) 請注意內存開銷

對你所使用的語言與庫的成本與開銷有所了解，從開始到結束，在設計你的app時謹記這些信息。通常，表面上看起來無關痛癢(innocuous)的事情也許實際上會導致大量的開銷。例如：

Enums的內存消耗通常是static constants的2倍。你應該盡量避免在Android上使用enums。
在Java中的每一個類(包括匿名內部類)都會使用大概500 bytes。
每一個類的實例花銷是12-16 bytes。
往HashMap添加一個entry需要額一個額外占用的32 bytes的entry對象。
7) 請注意代碼“抽象”

通常，開發者使用抽象作為”好的編程實踐”，因為抽象能夠提升代碼的靈活性與可維護性。然而，抽象會導致一個顯著的開銷：通常他們需要同等量的代碼用於可執行。那些代碼會被map到內存中。因此如果你的抽象沒有顯著的提升效率，應該盡量避免他們。

8) 使用ProGuard來剔除不需要的代碼

ProGuard能夠通過移除不需要的代碼，重命名類，域與方法等方對代碼進行壓縮，優化與混淆。使用ProGuard可以使得你的代碼更加緊湊，這樣能夠使用更少mapped代碼所需要的RAM。

9) 對最終的APK使用zipalign

在編寫完所有代碼，並通過編譯系統生成APK之後，你需要使用zipalign對APK進行重新校准。如果你不做這個步驟，會導致你的APK需要更多的RAM，因為一些類似圖片資源的東西不能被mapped。

Notes: Google Play不接受沒有經過zipalign的APK。

360二面

一面過了十多分鐘以後，接著就進行二面，都是視頻面試，差不多二十分鐘左右

AsyncTak的原理及常用方法 APK從安裝到啟動的過程 平時是怎樣學習的？ 學習和實習是在怎樣協調的 ？ 有360手機助手有什麼想了解的嗎？

對360手機助手有什麼想了解的？

這裡我提問的是省流量升級是怎樣實現的？
後面追問是不是利用動態加載技術。面試官解釋的是不是你，是對比版本之間的二進制文件差異。

面試總結

題外話

兩輪面試面試官人都挺好的，都面帶笑容個，感覺很好說話，當天晚上我加了面試官的微信，問他多久會出結果，面試官問我說後面有沒有接到電話，我說沒有，然後面試官說應該被刷了。

個人心得

可能是第一次視頻面試，感覺個人太緊張了，有好多原理性的東西講著講著就忘記講了，面試的時候真的是太緊張了，發揮不太好，平時一定要多總結，不然面試的時候一下子總結地不太好，發揮不出應有的水平。