android bitmap转图片_这是一份面向Android开发者的复习指南
來(lái)自：簡(jiǎn)書(shū)，作者：九心
鏈接：https://www.jianshu.com/p/b3c1b9c6dd40
前言
相信很多同學(xué)都會(huì)有這樣的感受，前三天剛剛復(fù)習(xí)的知識(shí)點(diǎn)，今天問(wèn)的時(shí)候怎么就講不出個(gè)所以然了呢？
本文的目的就是致力于幫助大家盡可能的建立Android知識(shí)體系，希望大家會(huì)喜歡~
必讀
知識(shí)結(jié)構(gòu)
覆蓋的知識(shí)點(diǎn)有Android、Java、Kotlin、Jvm、網(wǎng)絡(luò)和設(shè)計(jì)模式。
面向人群
正在求職的中高級(jí)Android開(kāi)發(fā)
食用指南
和大部分人一樣，我在復(fù)習(xí)完第一遍Android知識(shí)的情況下，看到相關(guān)的知識(shí)回答的仍然不能夠令自己滿意。
在第二遍系統(tǒng)復(fù)習(xí)的時(shí)候，我著重記住每個(gè)知識(shí)點(diǎn)的關(guān)鍵字，根據(jù)這些關(guān)鍵字拼湊出大概的知識(shí)點(diǎn)，最后看到每個(gè)知識(shí)點(diǎn)的時(shí)候，就知道大概會(huì)問(wèn)哪些內(nèi)容，達(dá)到這種境界以后，你就可以從容的面對(duì)每次面試了。
簡(jiǎn)單的做法就是為每個(gè)知識(shí)點(diǎn)建立腦圖，盡可能把自己想到的關(guān)鍵點(diǎn)羅列出來(lái)，也就是下面每個(gè)章節(jié)前面的腦圖。
除此以外，我還為大家提供了可能會(huì)問(wèn)到的面試題。
一、Android基
1. Activity
# Activity的四大啟動(dòng)模式，以及應(yīng)用場(chǎng)景？
Activity的四大啟動(dòng)模式：
standard：標(biāo)準(zhǔn)模式，每次都會(huì)在活動(dòng)棧中生成一個(gè)新的Activity實(shí)例。通常我們使用的活動(dòng)都是標(biāo)準(zhǔn)模式。
singleTop：棧頂復(fù)用，如果Activity實(shí)例已經(jīng)存在棧頂，那么就不會(huì)在活動(dòng)棧中創(chuàng)建新的實(shí)例。比較常見(jiàn)的場(chǎng)景就是給通知跳轉(zhuǎn)的Activity設(shè)置，因?yàn)槟憧隙ú幌肭芭_(tái)Activity已經(jīng)是該Activity的情況下，點(diǎn)擊通知，又給你再創(chuàng)建一個(gè)同樣的Activity。
singleTask：棧內(nèi)復(fù)用，如果Activity實(shí)例在當(dāng)前棧中已經(jīng)存在，就會(huì)將當(dāng)前Activity實(shí)例上面的其他Activity實(shí)例都移除棧。常見(jiàn)于跳轉(zhuǎn)到主界面。
singleInstance：單實(shí)例模式，創(chuàng)建一個(gè)新的任務(wù)棧，這個(gè)活動(dòng)實(shí)例獨(dú)自處在這個(gè)活動(dòng)棧中。
2. 屏幕適配
# 平時(shí)如何有使用屏幕適配嗎？原理是什么呢？
平時(shí)的屏幕適配一般采用的頭條的屏幕適配方案。簡(jiǎn)單來(lái)說(shuō)，以屏幕的一邊作為適配，通常是寬。
原理：設(shè)備像素px和設(shè)備獨(dú)立像素dp之間的關(guān)系
px = dp * density
假設(shè)UI給的設(shè)計(jì)圖屏幕寬度基于360dp，那么設(shè)備寬的像素點(diǎn)已知，即px，dp也已知，360dp，所以density = px / dp，之后根據(jù)這個(gè)修改系統(tǒng)中跟density相關(guān)的知識(shí)點(diǎn)即可。
3. Android消息機(jī)制
# Android消息機(jī)制介紹？
Android消息機(jī)制中的四大概念：
ThreadLocal：當(dāng)前線程存儲(chǔ)的數(shù)據(jù)僅能從當(dāng)前線程取出。
MessageQueue：具有時(shí)間優(yōu)先級(jí)的消息隊(duì)列。
Looper：輪詢消息隊(duì)列，看是否有新的消息到來(lái)。
Handler：具體處理邏輯的地方。
過(guò)程：
準(zhǔn)備工作：創(chuàng)建Handler，如果是在子線程中創(chuàng)建，還需要調(diào)用Looper#prepare()，在Handler的構(gòu)造函數(shù)中，會(huì)綁定其中的Looper和MessageQueue。
發(fā)送消息：創(chuàng)建消息，使用Handler發(fā)送。
進(jìn)入MessageQueue：因?yàn)镠andler中綁定著消息隊(duì)列，所以Message很自然的被放進(jìn)消息隊(duì)列。
Looper輪詢消息隊(duì)列：Looper是一個(gè)死循環(huán)，一直觀察有沒(méi)有新的消息到來(lái)，之后從Message取出綁定的Handler，最后調(diào)用Handler中的處理邏輯，這一切都發(fā)生在Looper循環(huán)的線程，這也是Handler能夠在指定線程處理任務(wù)的原因。
# Looper在主線程中死循環(huán)為什么沒(méi)有導(dǎo)致界面的卡死？
導(dǎo)致卡死的是在Ui線程中執(zhí)行耗時(shí)操作導(dǎo)致界面出現(xiàn)掉幀，甚至ANR，Looper.loop()這個(gè)操作本身不會(huì)導(dǎo)致這個(gè)情況。
有人可能會(huì)說(shuō)，我在點(diǎn)擊事件中設(shè)置死循環(huán)會(huì)導(dǎo)致界面卡死，同樣都是死循環(huán)，不都一樣的嗎？Looper會(huì)在沒(méi)有消息的時(shí)候阻塞當(dāng)前線程，釋放CPU資源，等到有消息到來(lái)的時(shí)候，再喚醒主線程。
App進(jìn)程中是需要死循環(huán)的，如果循環(huán)結(jié)束的話，App進(jìn)程就結(jié)束了。
建議閱讀：
《Android中為什么主線程不會(huì)因?yàn)長(zhǎng)ooper.loop()里的死循環(huán)卡死？》
https://www.zhihu.com/question/34652589
# IdleHandler介紹？
介紹：
IdleHandler是在Hanlder空閑時(shí)處理空閑任務(wù)的一種機(jī)制。
執(zhí)行場(chǎng)景：
MessageQueue沒(méi)有消息，隊(duì)列為空的時(shí)候。
MessageQueue屬于延遲消息，當(dāng)前沒(méi)有消息執(zhí)行的時(shí)候。
會(huì)不會(huì)發(fā)生死循環(huán)：
答案是否定的，MessageQueue使用計(jì)數(shù)的方法保證一次調(diào)用MessageQueue#next方法只會(huì)使用一次的IdleHandler集合。
4. View事件分發(fā)機(jī)制和View繪制原理
剛哥的《Android開(kāi)發(fā)藝術(shù)探索》已經(jīng)很全面了，建議閱讀。
5. Bitmap
# Bitmap的內(nèi)存計(jì)算方式？
在已知圖片的長(zhǎng)和寬的像素的情況下，影響內(nèi)存大小的因素會(huì)有資源文件位置和像素點(diǎn)大小。
像素點(diǎn)大小：
常見(jiàn)的像素點(diǎn)有：
ARGB_8888：4個(gè)字節(jié)
ARGB_4444、ARGB_565：2個(gè)字節(jié)
資源文件位置：
不同dpi對(duì)應(yīng)存放的文件夾
比如一個(gè)一張圖片的像素為180*180px，dpi(設(shè)備獨(dú)立像素密度)為320，如果它僅僅存放在drawable-hdpi，則有：
橫向像素點(diǎn)?=?180?*?320/240?+?0.5f?=?240?px縱向像素點(diǎn)?=?180?*?320/240?+?0.5f?=?240?px
如果它僅僅存放在drawable-xxhdpi，則有：
180?*?所以，對(duì)于一張180*180px的圖片，設(shè)備dpi為320，資源圖片僅僅存在drawable-hdpi，像素點(diǎn)大小為ARGB_4444，最后生成的文件內(nèi)存大小為：
橫向像素點(diǎn)?=?180?*?320/240?+?0.5f?=?240?px縱向像素點(diǎn)?=?180?*?320/240?+?0.5f?=?240?px
內(nèi)存大小?=?240?*?240?*?2?=?115200byte?約等于?112.5kb
建議閱讀：
《Android Bitmap的內(nèi)存大小是如何計(jì)算的？》
https://ivonhoe.github.io/2017/03/22/Bitmap&Memory/
# Bitmap的高效加載？
Bitmap的高效加載在Glide中也用到了，思路：
獲取需要的長(zhǎng)和寬，一般獲取控件的長(zhǎng)和寬。
設(shè)置BitmapFactory.Options中的inJustDecodeBounds為true，可以幫助我們?cè)诓患虞d進(jìn)內(nèi)存的方式獲得Bitmap的長(zhǎng)和寬。
對(duì)需要的長(zhǎng)和寬和Bitmap的長(zhǎng)和寬進(jìn)行對(duì)比，從而獲得壓縮比例，放入BitmapFactory.Options中的inSampleSize屬性。
設(shè)置BitmapFactory.Options中的inJustDecodeBounds為false，將圖片加載進(jìn)內(nèi)存，進(jìn)而設(shè)置到控件中。
二、Android進(jìn)階
Android進(jìn)階中重點(diǎn)考察Android Framework、性能優(yōu)化和第三方框架。
1. Binder
# Binder的介紹？與其他IPC方式的優(yōu)缺點(diǎn)？
Binder是Android中特有的IPC方式，引用《Android開(kāi)發(fā)藝術(shù)探索》中的話(略有改動(dòng))：
從IPC角度來(lái)說(shuō)，Binder是Android中的一種跨進(jìn)程通信方式；Binder還可以理解為虛擬的物理設(shè)備，它的設(shè)備驅(qū)動(dòng)是/dev/binder；從Android Framework來(lái)講，Binder是Service Manager連接各種Manager和對(duì)應(yīng)的ManagerService的橋梁。從面向?qū)ο蠛虲S模型來(lái)講，Client通過(guò)Binder和遠(yuǎn)程的Server進(jìn)行通訊。
基于Binder，Android還實(shí)現(xiàn)了其他的IPC方式，比如AIDL、Messenger和ContentProvider。
與其他IPC比較：
效率高：除了內(nèi)存共享外，其他IPC都需要進(jìn)行兩次數(shù)據(jù)拷貝，而因?yàn)锽inder使用內(nèi)存映射的關(guān)系，僅需要一次數(shù)據(jù)拷貝。
安全性好：接收方可以從數(shù)據(jù)包中獲取發(fā)送發(fā)的進(jìn)程Id和用戶Id，方便驗(yàn)證發(fā)送方的身份，其他IPC想要實(shí)驗(yàn)只能夠主動(dòng)存入，但是這有可能在發(fā)送的過(guò)程中被修改。
# Binder的通信過(guò)程？Binder的原理？
圖片：
其實(shí)這個(gè)過(guò)程也可以從AIDL生成的代碼中看出。
原理：
Binder的結(jié)構(gòu)：
Client：服務(wù)的請(qǐng)求方。
Server：服務(wù)的提供方。
Service Manager：為Server提供Binder的注冊(cè)服務(wù)，為Client提供Binder的查詢服務(wù)，Server、Client和Service Manager的通訊都是通過(guò)Binder。
Binder驅(qū)動(dòng)：負(fù)責(zé)Binder通信機(jī)制的建立，提供一系列底層支持。
從上圖中，Binder通信的過(guò)程是這樣的：
Server在Service Manager中注冊(cè)：Server進(jìn)程在創(chuàng)建的時(shí)候，也會(huì)創(chuàng)建對(duì)應(yīng)的Binder實(shí)體，如果要提供服務(wù)給Client，就必須為Binder實(shí)體注冊(cè)一個(gè)名字。
Client通過(guò)Service Manager獲取服務(wù)：Client知道服務(wù)中Binder實(shí)體的名字后，通過(guò)名字從Service Manager獲取Binder實(shí)體的引用。
Client使用服務(wù)與Server進(jìn)行通信：Client通過(guò)調(diào)用Binder實(shí)體與Server進(jìn)行通信。
更詳細(xì)一點(diǎn)？
Binder通信的實(shí)質(zhì)是利用內(nèi)存映射，將用戶進(jìn)程的內(nèi)存地址和內(nèi)核的內(nèi)存地址映射為同一塊物理地址，也就是說(shuō)他們使用的同一塊物理空間，每次創(chuàng)建Binder的時(shí)候大概分配128的空間。數(shù)據(jù)進(jìn)行傳輸?shù)臅r(shí)候，從這個(gè)內(nèi)存空間分配一點(diǎn)，用完了再釋放即可。
2. 序列化
# Android有哪些序列化方式？
為了解決Android中內(nèi)存序列化速度過(guò)慢的問(wèn)題，Android使用了Parcelable。
| 易用性 | 簡(jiǎn)單 | 不是很簡(jiǎn)單 |
| 效率 | 低 | 高 |
| 場(chǎng)景 | IO、網(wǎng)絡(luò)和數(shù)據(jù)庫(kù) | 內(nèi)存中 |
3. Framework
Zygote孕育進(jìn)程過(guò)程？
# Activity的啟動(dòng)過(guò)程？
建議閱讀：
《3分鐘看懂Activity啟動(dòng)流程》
https://www.jianshu.com/p/9ecea420eb52
# App的啟動(dòng)過(guò)程？
介紹一下App進(jìn)程和System Server進(jìn)程如何聯(lián)系：
App進(jìn)程
ActivityThread：依賴于Ui線程，實(shí)際處理與AMS中交互的工作。
ActivityManagerService：負(fù)責(zé)Activity、Service等的生命周期工作。
ApplicationThread：System Server進(jìn)程中ApplicatonThreadProxy的服務(wù)端，幫助System Server進(jìn)程跟App進(jìn)程交流。
System Server：Android核心的進(jìn)程，掌管著Android系統(tǒng)中各種重要的服務(wù)。
具體過(guò)程：
用戶點(diǎn)擊App圖標(biāo)，Lanuacher進(jìn)程通過(guò)Binder聯(lián)系到System Server進(jìn)程發(fā)起startActivity。
System Server通過(guò)Socket聯(lián)系到Zygote，fork出一個(gè)新的App進(jìn)程。
創(chuàng)建出一個(gè)新的App進(jìn)程以后，Zygote啟動(dòng)App進(jìn)程的ActivityThread#main()方法。
在ActivtiyThread中，調(diào)用AMS進(jìn)行ApplicationThread的綁定。
AMS發(fā)送創(chuàng)建Application的消息給ApplicationThread，進(jìn)而轉(zhuǎn)交給ActivityThread中的H，它是一個(gè)Handler，接著進(jìn)行Application的創(chuàng)建工作。
AMS以同樣的方式創(chuàng)建Activity，接著就是大家熟悉的創(chuàng)建Activity的工作了。
# Apk的安裝過(guò)程？
建議閱讀：
《Android Apk安裝過(guò)程分析》
https://www.jianshu.com/p/953475cea991
# Activity啟動(dòng)過(guò)程跟Window的關(guān)系？
建議閱讀：
《簡(jiǎn)析Window、Activity、DecorView以及ViewRoot之間的錯(cuò)綜關(guān)系》
https://juejin.im/post/5dac6aa2518825630e5d17da
# ?Activity、Window、ViewRoot和DecorView之間的關(guān)系？
建議閱讀：
《總結(jié)UI原理和高級(jí)的UI優(yōu)化方式》
https://www.jianshu.com/p/8766babc40e0
4. Context
# 關(guān)于Context的理解？
建議閱讀：
《Android Context 上下文 你必須知道的一切》
https://blog.csdn.net/lmj623565791/article/details/40481055
5. 斷點(diǎn)續(xù)傳
# 多線程斷點(diǎn)續(xù)傳？
基礎(chǔ)知識(shí)：
Http基礎(chǔ)：在Http請(qǐng)求中，可以加入請(qǐng)求頭Range，下載指定區(qū)間的文件數(shù)。
RandomAccessFile：支持隨機(jī)訪問(wèn)，可以從指定位置進(jìn)行數(shù)據(jù)的讀寫(xiě)。
有了這個(gè)基礎(chǔ)以后，思路就清晰了：
通過(guò)HttpUrlConnection獲取文件長(zhǎng)度。
自己分配好線程進(jìn)行制定區(qū)間的文件數(shù)據(jù)的下載。
獲取到數(shù)據(jù)流以后，使用RandomAccessFile進(jìn)行指定位置的讀寫(xiě)。
6. 性能優(yōu)化
# 平時(shí)做了哪些性能優(yōu)化？
建議閱讀：
《Android 性能優(yōu)化最佳實(shí)踐》
https://juejin.im/post/5b50b017f265da0f7b2f649c
7. 第三方庫(kù)
一定要在熟練使用后再去查看原理。
# Glide
Glide考察的頻率挺高的，常見(jiàn)的問(wèn)題有：
Glide和其他圖片加載框架的比較？
如何設(shè)計(jì)一個(gè)圖片加載框架？
Glide緩存實(shí)現(xiàn)機(jī)制？
Glide如何處理生命周期？
...
建議閱讀：
《Glide最全解析》
https://blog.csdn.net/sinyu890807/category_9268670.html
《面試官：簡(jiǎn)歷上最好不要寫(xiě)Glide，不是問(wèn)源碼那么簡(jiǎn)單》
https://juejin.im/post/5dbeda27e51d452a161e00c8
# OkHttp
OkHttp常見(jiàn)知識(shí)點(diǎn)：
責(zé)任鏈模式
interceptors和networkInterceptors的區(qū)別？
建議看一遍源碼，過(guò)程并不復(fù)雜。
# Retrofit
Retrofit常見(jiàn)問(wèn)題：
設(shè)計(jì)模式和封層解耦的理念
動(dòng)態(tài)代理
建議看一遍源碼，過(guò)程并不復(fù)雜。
# RxJava
RxJava難在各種操作符，我們了解一下大致的設(shè)計(jì)思想即可。
建議尋找一些RxJava的文章。
# Android Jetpack(非必須)
我主要閱讀了Android Jetpack中以下庫(kù)的源碼：
Lifecycle：觀察者模式，組件生命周期中發(fā)送事件。
DataBinding：核心就是利用LiveData或者Observablexxx實(shí)現(xiàn)的觀察者模式，對(duì)16進(jìn)制的狀態(tài)位更新，之后根據(jù)這個(gè)狀態(tài)位去更新對(duì)應(yīng)的內(nèi)容。
LiveData：觀察者模式，事件的生產(chǎn)消費(fèi)模型。
ViewModel：借用Activty異常銷毀時(shí)存儲(chǔ)隱藏Fragment的機(jī)制存儲(chǔ)ViewModel，保證數(shù)據(jù)的生命周期盡可能的延長(zhǎng)。
Paging：設(shè)計(jì)思想。
以后有時(shí)間再給大家做源碼分析。
建議閱讀：
《Android Jetpack源碼分析系列》
https://blog.csdn.net/mq2553299/column/info/24151
三、Java基礎(chǔ)
Java基礎(chǔ)中考察頻率比較高的是Object、String、面向?qū)ο蟆⒓稀⒎盒秃头瓷洹?/p>
1. Object
# equals和==的區(qū)別？equals和hashcode的關(guān)系？
==：基本類型比較值，引用類型比較地址。
equals：默認(rèn)情況下，equals作為對(duì)象中的方法，比較的是地址，不過(guò)可以根據(jù)業(yè)務(wù)，修改equals方法。
equals和hashcode之間的關(guān)系：
默認(rèn)情況下，equals相等，hashcode必相等，hashcode相等，equals不是必相等。hashcode基于內(nèi)存地址計(jì)算得出，可能會(huì)相等，雖然幾率微乎其微。
2. String
# String、StringBuffer和StringBuilder的區(qū)別？
String：String屬于不可變對(duì)象，每次修改都會(huì)生成新的對(duì)象。
StringBuilder：可變對(duì)象，非多線程安全。
StringBuffer：可變對(duì)象，多線程安全。
大部分情況下，效率是：StringBuilder>StringBuffer>String。
3. 面向?qū)ο蟮奶匦?/strong>
# Java中抽象類和接口的特點(diǎn)？
共同點(diǎn)：
抽象類和接口都不能生成具體的實(shí)例。
都是作為上層使用。
不同點(diǎn)：
抽象類可以有屬性和成員方法，接口不可以。
一個(gè)類只能繼承一個(gè)類，但是可以實(shí)現(xiàn)多個(gè)接口。
抽象類中的變量是普通變量，接口中的變量是靜態(tài)變量。
抽象類表達(dá)的是is-a的關(guān)系，接口表達(dá)的是like-a的關(guān)系。
# 關(guān)于多態(tài)的理解？
多態(tài)是面向?qū)ο蟮娜筇匦?#xff1a;繼承、封裝和多態(tài)之一。
多態(tài)的定義：允許不同類對(duì)同一消息做出響應(yīng)。
多態(tài)存在的條件：
要有繼承。
要有復(fù)寫(xiě)。
父類引用指向子類對(duì)象。
Java中多態(tài)的實(shí)現(xiàn)方式：接口實(shí)現(xiàn)，繼承父類進(jìn)行方法重寫(xiě)，同一個(gè)類中的方法重載。
4. 集合
# HashMap的特點(diǎn)是什么？HashMap的原理？
HashMap的特點(diǎn)：
基于Map接口，存放鍵值對(duì)。
允許key/value為空。
非多線程安全。
不保證有序，也不保證使用的過(guò)程中順序不會(huì)改變。
簡(jiǎn)單來(lái)講，核心是數(shù)組+鏈表/紅黑樹(shù)，HashMap的原理就是存鍵值對(duì)的時(shí)候：
通過(guò)鍵的Hash值確定數(shù)組的位置。
找到以后，如果該位置無(wú)節(jié)點(diǎn)，直接存放。
該位置有節(jié)點(diǎn)即位置發(fā)生沖突，遍歷該節(jié)點(diǎn)以及后續(xù)的節(jié)點(diǎn)，比較key值，相等則覆蓋。
沒(méi)有就新增節(jié)點(diǎn)，默認(rèn)使用鏈表，相連節(jié)點(diǎn)數(shù)超過(guò)8的時(shí)候，在jdk 1.8中會(huì)變成紅黑樹(shù)。
如果Hashmap中的數(shù)組使用情況超過(guò)一定比例，就會(huì)擴(kuò)容，默認(rèn)擴(kuò)容兩倍。
當(dāng)然這是存入的過(guò)程，其他過(guò)程可以自行查閱。這里需要注意的是：
key的hash值計(jì)算過(guò)程是高16位不變，低16位和高16位取抑或，讓更多位參與進(jìn)來(lái)，可以有效的減少碰撞的發(fā)生。
初始數(shù)組容量為16，默認(rèn)不超過(guò)的比例為0.75。
5. 泛型
# 說(shuō)一下對(duì)泛型的理解？
泛型的本質(zhì)是參數(shù)化類型，在不創(chuàng)建新的類型的情況下，通過(guò)泛型指定不同的類型來(lái)控制形參具體限制的類型。也就是說(shuō)在泛型的使用中，操作的數(shù)據(jù)類型被指定為一個(gè)參數(shù)，這種參數(shù)可以被用在類、接口和方法中，分別被稱為泛型類、泛型接口和泛型方法。
泛型是Java中的一種語(yǔ)法糖，能夠在代碼編寫(xiě)的時(shí)候起到類型檢測(cè)的作用，但是虛擬機(jī)是不支持這些語(yǔ)法的。
泛型的優(yōu)點(diǎn)：
類型安全，避免類型的強(qiáng)轉(zhuǎn)。
提高了代碼的可讀性，不必要等到運(yùn)行的時(shí)候才去強(qiáng)制轉(zhuǎn)換。
# 什么是類型擦除？
不管泛型的類型傳入哪一種類型實(shí)參，對(duì)于Java來(lái)說(shuō)，都會(huì)被當(dāng)成同一類處理，在內(nèi)存中也只占用一塊空間。通俗一點(diǎn)來(lái)說(shuō)，就是泛型只作用于代碼編譯階段，在編譯過(guò)程中，對(duì)于正確檢驗(yàn)泛型結(jié)果后，會(huì)將泛型的信息擦除，也就是說(shuō)，成功編譯過(guò)后的class文件是不包含任何泛型信息的。
6. 反射
# 動(dòng)態(tài)代理和靜態(tài)代理
靜態(tài)代理很簡(jiǎn)單，運(yùn)用的就是代理模式：
聲明一個(gè)接口，再分別實(shí)現(xiàn)一個(gè)真實(shí)的主題類和代理主題類，通過(guò)讓代理類持有真實(shí)主題類，從而控制用戶對(duì)真實(shí)主題的訪問(wèn)。
動(dòng)態(tài)代理指的是在運(yùn)行時(shí)動(dòng)態(tài)生成代理類，即代理類的字節(jié)碼在運(yùn)行時(shí)生成并載入當(dāng)前的ClassLoader。
動(dòng)態(tài)代理的原理是使用反射，思路和上面的一致。
使用動(dòng)態(tài)代理的好處：
不需要為RealSubject寫(xiě)一個(gè)形式完全一樣的代理類。
使用一些動(dòng)態(tài)代理的方法可以在運(yùn)行時(shí)制定代理類的邏輯，從而提升系統(tǒng)的靈活性。
四、Java并發(fā)
Java并發(fā)中考察頻率較高的有線程、線程池、鎖、線程間的等待和喚醒、線程特性和阻塞隊(duì)列等。
1. 線程
# 線程的狀態(tài)有哪些？
附上一張狀態(tài)轉(zhuǎn)換的圖：
# 線程中wait和sleep的區(qū)別？
wait方法既釋放cpu，又釋放鎖。
sleep方法只釋放cpu，但是不釋放鎖。
# 線程和進(jìn)程的區(qū)別？
線程是CPU調(diào)度的最小單位，一個(gè)進(jìn)程中可以包含多個(gè)線程，在Android中，一個(gè)進(jìn)程通常是一個(gè)App，App中會(huì)有一個(gè)主線程，主線程可以用來(lái)操作界面元素，如果有耗時(shí)的操作，必須開(kāi)啟子線程執(zhí)行，不然會(huì)出現(xiàn)ANR，除此以外，進(jìn)程間的數(shù)據(jù)是獨(dú)立的，線程間的數(shù)據(jù)可以共享。
2. 線程池
線程池的地位十分重要，基本上涉及到跨線程的框架都使用到了線程池，比如說(shuō)OkHttp、RxJava、LiveData以及協(xié)程等。
# 與新建一個(gè)線程相比，線程池的特點(diǎn)？
節(jié)省開(kāi)銷：線程池中的線程可以重復(fù)利用。
速度快：任務(wù)來(lái)了就能開(kāi)始，省去創(chuàng)建線程的時(shí)間。
線程可控：線程數(shù)量可空和任務(wù)可控。
功能強(qiáng)大：可以定時(shí)和重復(fù)執(zhí)行任務(wù)。
# 線程池中的幾個(gè)參數(shù)是什么意思，線程池的種類有哪些？
線程池的構(gòu)造函數(shù)如下：
public?ThreadPoolExecutor(int?corePoolSize,int?maximumPoolSize,long?keepAliveTime,??????????????????????????TimeUnit?unit,
??????????????????????????BlockingQueue?workQueue)?{
參數(shù)解釋如下：
corePoolSize：核心線程數(shù)量，不會(huì)釋放。
maximumPoolSize：允許使用的最大線程池?cái)?shù)量，非核心線程數(shù)量，閑置時(shí)會(huì)釋放。
keepAliveTime：閑置線程允許的最大閑置時(shí)間。
unit：閑置時(shí)間的單位。
workQueue：阻塞隊(duì)列，不同的阻塞隊(duì)列有不同的特性。
線程池分為四個(gè)類型：
CachedThreadPool：閑置線程超時(shí)會(huì)釋放，沒(méi)有閑置線程的情況下，每次都會(huì)創(chuàng)建新的線程。
FixedThreadPool：線程池只能存放指定數(shù)量的線程池，線程不會(huì)釋放，可重復(fù)利用。
SingleThreadExecutor：單線程的線程池。
ScheduledThreadPool：可定時(shí)和重復(fù)執(zhí)行的線程池。
# 線程池的工作流程？
圖片來(lái)自《線程池是怎樣工作的》
https://www.jianshu.com/p/9de89960ec01
簡(jiǎn)而言之：
任務(wù)來(lái)了，優(yōu)先考慮核心線程。
核心線程滿了，進(jìn)入阻塞隊(duì)列。
阻塞隊(duì)列滿了，考慮非核心線程(圖上好像少了這個(gè)過(guò)程)。
非核心線程滿了，再觸發(fā)拒絕任務(wù)。
3. 鎖
# 死鎖觸發(fā)的四大條件？
互斥鎖
請(qǐng)求與保持
不可剝奪
循環(huán)的請(qǐng)求與等待
# synchronized關(guān)鍵字的使用？synchronized的參數(shù)放入對(duì)象和Class有什么區(qū)別？
synchronized關(guān)鍵字的用法：
修飾方法
修飾代碼塊：需要自己提供鎖對(duì)象，鎖對(duì)象包括對(duì)象本身、對(duì)象的Class和其他對(duì)象。
放入對(duì)象和Class的區(qū)別是：
鎖住的對(duì)象不同：成員方法鎖住的實(shí)例對(duì)象，靜態(tài)方法鎖住的是Class。
訪問(wèn)控制不同：如果鎖住的是實(shí)例，只會(huì)針對(duì)同一個(gè)對(duì)象方法進(jìn)行同步訪問(wèn)，多線程訪問(wèn)同一個(gè)對(duì)象的synchronized代碼塊是串行的，訪問(wèn)不同對(duì)象是并行的。如果鎖住的是類，多線程訪問(wèn)的不管是同一對(duì)象還是不同對(duì)象的synchronized代碼塊是都是串行的。
# synchronized的原理？
任何一個(gè)對(duì)象都有一個(gè)monitor與之相關(guān)聯(lián)，JVM基于進(jìn)入和退出mointor對(duì)象來(lái)實(shí)現(xiàn)代碼塊同步和方法同步，兩者實(shí)現(xiàn)細(xì)節(jié)不同：
代碼塊同步：在編譯字節(jié)碼的時(shí)候，代碼塊起始的地方插入monitorenter
指令，異常和代碼塊結(jié)束處插入monitorexit指令，線程在執(zhí)行monitorenter指令的時(shí)候嘗試獲取monitor對(duì)象的所有權(quán)，獲取不到的情況下就是阻塞方法同步：synchronized方法在method_info結(jié)構(gòu)有AAC_synchronized標(biāo)記，線程在執(zhí)行的時(shí)候獲取對(duì)應(yīng)的鎖，從而實(shí)現(xiàn)同步方法
# synchronized和Lock的區(qū)別？
主要區(qū)別：
synchronized是Java中的關(guān)鍵字，是Java的內(nèi)置實(shí)現(xiàn)；Lock是Java中的接口。
synchronized遇到異常會(huì)釋放鎖；Lock需要在發(fā)生異常的時(shí)候調(diào)用成員方法Lock#unlock()方法。
synchronized是不可以中斷的，Lock可中斷。
synchronized不能去嘗試獲得鎖，沒(méi)有獲得鎖就會(huì)被阻塞；Lock可以去嘗試獲得鎖，如果未獲得可以嘗試處理其他邏輯。
synchronized多線程效率不如Lock，不過(guò)Java在1.6以后已經(jīng)對(duì)synchronized進(jìn)行大量的優(yōu)化，所以性能上來(lái)講，其實(shí)差不了多少。
# 悲觀鎖和樂(lè)觀鎖的舉例？以及它們的相關(guān)實(shí)現(xiàn)？
悲觀鎖和樂(lè)觀鎖的概念：
悲觀鎖：悲觀鎖會(huì)認(rèn)為，修改共享數(shù)據(jù)的時(shí)候其他線程也會(huì)修改數(shù)據(jù)，因此只在不會(huì)受到其他線程干擾的情況下執(zhí)行。這樣會(huì)導(dǎo)致其他有需要鎖的線程掛起，等到持有鎖的線程釋放鎖
樂(lè)觀鎖：每次不加鎖，每次直接修改共享數(shù)據(jù)假設(shè)其他線程不會(huì)修改，如果發(fā)生沖突就直接重試，直到成功為止
舉例：
悲觀鎖：典型的悲觀鎖是獨(dú)占鎖，有synchronized、ReentrantLock。
樂(lè)觀鎖：典型的樂(lè)觀鎖是CAS，實(shí)現(xiàn)CAS的atomic為代表的一系列類
# CAS是什么？底層原理？
CAS全稱Compare And Set，核心的三個(gè)元素是：內(nèi)存位置、預(yù)期原值和新值，執(zhí)行CAS的時(shí)候，會(huì)將內(nèi)存位置的值與預(yù)期原值進(jìn)行比較，如果一致，就將原值更新為新值，否則就不更新。
底層原理：是借助CPU底層指令cmpxchg實(shí)現(xiàn)原子操作。
4. 線程間通信
# notify和notifyAll方法的區(qū)別？
notify隨機(jī)喚醒一個(gè)線程，notifyAll喚醒所有等待的線程，讓他們競(jìng)爭(zhēng)鎖。
# wait/notify和Condition類實(shí)現(xiàn)的等待通知有什么區(qū)別？
synchronized與wait/notify結(jié)合的等待通知只有一個(gè)條件，而Condition類可以實(shí)現(xiàn)多個(gè)條件等待。
5. 多線程間的特性
# 多線程間的有序性、可見(jiàn)性和原子性是什么意思？
原子性：執(zhí)行一個(gè)或者多個(gè)操作的時(shí)候，要么全部執(zhí)行，要么都不執(zhí)行，并且中間過(guò)程中不會(huì)被打斷。Java中的原子性可以通過(guò)獨(dú)占鎖和CAS去保證
可見(jiàn)性：指多線程訪問(wèn)同一個(gè)變量的時(shí)候，一個(gè)線程修改了變量的值，其他線程能夠立刻看得到修改的值。鎖和volatile能夠保證可見(jiàn)性
有序性：程序執(zhí)行的順序按照代碼先后的順序執(zhí)行。鎖和volatile能夠保證有序性
# happens-before原則有哪些？
Java內(nèi)存模型具有一些先天的有序性，它通常叫做happens-before原則。
如果兩個(gè)操作的先后順序不能通過(guò)happens-before原則推倒出來(lái)，那就不能保證它們的先后執(zhí)行順序，虛擬機(jī)就可以隨意打亂執(zhí)行指令。happens-before原則有：
程序次序規(guī)則：單線程程序的執(zhí)行結(jié)果得和看上去代碼執(zhí)行的結(jié)果要一致。
鎖定規(guī)則：一個(gè)鎖的lock操作一定發(fā)生在上一個(gè)unlock操作之后。
volatile規(guī)則：對(duì)volatile變量的寫(xiě)操作一定先行于后面對(duì)這個(gè)變量的對(duì)操作。
傳遞規(guī)則：A發(fā)生在B前面，B發(fā)生在C前面，那么A一定發(fā)生在C前面。
線程啟動(dòng)規(guī)則：線程的start方法先行發(fā)生于線程中的每個(gè)動(dòng)作。
線程中斷規(guī)則：對(duì)線程的interrupt操作先行發(fā)生于中斷線程的檢測(cè)代碼。
線程終結(jié)原則：線程中所有的操作都先行發(fā)生于線程的終止檢測(cè)。
對(duì)象終止原則：一個(gè)對(duì)象的初始化先行發(fā)生于他的finalize()方法的執(zhí)行。
前四條規(guī)則比較重要。
# volatile的原理？
可見(jiàn)性
如果對(duì)聲明了volatile的變量進(jìn)行寫(xiě)操作的時(shí)候，JVM會(huì)向處理器發(fā)送一條Lock前綴的指令，將這個(gè)變量所在緩存行的數(shù)據(jù)寫(xiě)入到系統(tǒng)內(nèi)存。
多處理器的環(huán)境下，其他處理器的緩存還是舊的，為了保證各個(gè)處理器一致，會(huì)通過(guò)嗅探在總線上傳播的數(shù)據(jù)來(lái)檢測(cè)自己的數(shù)據(jù)是否過(guò)期，如果過(guò)期，會(huì)強(qiáng)制重新將系統(tǒng)內(nèi)存的數(shù)據(jù)讀取到處理器緩存。
有序性
Lock前綴的指令相當(dāng)于一個(gè)內(nèi)存柵欄，它確保指令排序的時(shí)候，不會(huì)把后面的指令拍到內(nèi)存柵欄的前面，也不會(huì)把前面的指令排到內(nèi)存柵欄的后面。
6. 阻塞隊(duì)列
# 通常的阻塞隊(duì)列有哪幾種，特點(diǎn)是什么？
ArrayBlockQueue：基于數(shù)組實(shí)現(xiàn)的有界的FIFO(先進(jìn)先出)阻塞隊(duì)列。
LinkedBlockQueue：基于鏈表實(shí)現(xiàn)的無(wú)界的FIFO(先進(jìn)先出)阻塞隊(duì)列。
SynchronousQueue：內(nèi)部沒(méi)有任何緩存的阻塞隊(duì)列。
PriorityBlockingQueue：具有優(yōu)先級(jí)的無(wú)限阻塞隊(duì)列。
# ConcurrentHashMap的原理
數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)跟HashMap一樣，不做介紹。
JDK 1.8之前采用的是分段鎖，核心類是一個(gè)Segment，Segment繼承了ReentrantLock，每個(gè)Segment對(duì)象管理若干個(gè)桶，多個(gè)線程訪問(wèn)同一個(gè)元素的時(shí)候只能去競(jìng)爭(zhēng)獲取鎖。
JDK 1.8采用了CAS + synchronized，插入鍵值對(duì)的時(shí)候如果當(dāng)前桶中沒(méi)有Node節(jié)點(diǎn)，使用CAS方式進(jìn)行更新，如果有Node節(jié)點(diǎn)，則使用synchronized的方式進(jìn)行更新。
五、網(wǎng)絡(luò)
掌握網(wǎng)絡(luò)知識(shí)其實(shí)是需要一個(gè)系統(tǒng)的過(guò)程，在時(shí)間充裕的情況下，建議還是系統(tǒng)化的學(xué)習(xí)。
高頻網(wǎng)絡(luò)知識(shí)有TCP、HTTP和HTTPS。
1. HTTP和HTTPS
# HTTP是哪一層的協(xié)議，常見(jiàn)的HTTP狀態(tài)碼有哪些，分別代表什么意思？
HTTP協(xié)議是應(yīng)用層的協(xié)議。
常見(jiàn)的HTTP狀態(tài)碼有：
| 1xx | 請(qǐng)求已經(jīng)接收，繼續(xù)處理 |
| 2xx | 服務(wù)器已經(jīng)正確處理請(qǐng)求，比如200 |
| 3xx | 重定向，需要做進(jìn)一步的處理才能完成請(qǐng)求 |
| 4xx | 服務(wù)器無(wú)法理解的請(qǐng)求，比如404，訪問(wèn)的資源不存在 |
| 5xx | 服務(wù)器收到請(qǐng)求以后，處理錯(cuò)誤 |
# HTTP 1.1 和HTTP 2有什么區(qū)別？
HTTP 2.0基于HTTP 1.1，與HTTP 2.0增加了：
二進(jìn)制格式：HTTP 1.1使用純文本進(jìn)行通信，HTTP 2.0使用二進(jìn)制進(jìn)行傳輸。
Head壓縮：對(duì)已經(jīng)發(fā)送的Header使用鍵值建立索引表，相同的Header使用索引表示。
服務(wù)器推送：服務(wù)器可以進(jìn)行主動(dòng)推送
多路復(fù)用：一個(gè)TCP連接可以劃分成多個(gè)流，每個(gè)流都會(huì)分配Id，客戶端可以借助流和服務(wù)端建立全雙工進(jìn)行通信，并且流具有優(yōu)先級(jí)。
# HTTP和HTTPS有什么區(qū)別？
簡(jiǎn)單來(lái)說(shuō)，HTTP和HTTPS的關(guān)系是這樣的
HTTPS = HTTP + SSL/TLS
區(qū)別如下：
HTTP作用于應(yīng)用層，使用80端口，起始地址是http://，明文傳輸，消息容易被攔截，串改。
HTTPS作用域傳輸層，使用443端口，起始地址是https://，需要下載CA證書(shū)，傳輸?shù)倪^(guò)程需要加密，安全性高。
# SSL/TLS的握手過(guò)程？
這里借用《趣談網(wǎng)絡(luò)協(xié)議》的圖片：
# HTTPS傳輸過(guò)程中是如何處理進(jìn)行加密的？為什么有對(duì)稱加密的情況下仍然需要進(jìn)行非對(duì)稱加密？
過(guò)程和上圖類似，依次獲取證書(shū)，公鑰，最后生成對(duì)稱加密的鑰匙進(jìn)行對(duì)稱加密。
對(duì)稱加密可以保證加密效率，但是不能解決密鑰傳輸問(wèn)題；非對(duì)稱加密可以解決傳輸問(wèn)題，但是效率不高。
2. TCP相關(guān)
# TCP的三次握手過(guò)程，為什么需要三次，而不是兩次或者四次？
只發(fā)送兩次，服務(wù)端是不知道自己發(fā)送的消息能不能被客戶端接收到。
因?yàn)門(mén)CP握手是三次，所以此時(shí)雙方都已經(jīng)知道自己發(fā)送的消息能夠被對(duì)方收到，所以，第四次的發(fā)送就顯得多余了。
# TCP的四次揮手過(guò)程？
大致意思就是：
Client：我要斷開(kāi)連接了
Server：我收到你的消息了
Server：我也要斷開(kāi)連接了
Client：收到你要斷開(kāi)連接的消息了
之后Client等待兩個(gè)MSL(數(shù)據(jù)包在網(wǎng)絡(luò)上生存的最長(zhǎng)時(shí)間)，如果服務(wù)端沒(méi)有回消息就徹底斷開(kāi)了。
# TCP和UDP有什么區(qū)別？
TCP：基于字節(jié)流、面向連接、可靠、能夠進(jìn)行全雙工通信，除此以外，還能進(jìn)行流量控制和擁塞控制，不過(guò)效率略低
UDP：基于報(bào)文、面向無(wú)連接、不可靠，但是傳輸效率高。
總的來(lái)說(shuō)，TCP適用于傳輸效率要求低，準(zhǔn)確性要求高或要求有連接。而UDP適用于對(duì)準(zhǔn)確性要求較低，傳輸效率要求較高的場(chǎng)景，比如語(yǔ)音通話、直播等。
# TCP為什么是一種可靠的協(xié)議？如何做到流量控制和擁塞控制？
TCP可靠：是因?yàn)榭梢宰龅綌?shù)據(jù)包發(fā)送的有序、無(wú)差錯(cuò)和無(wú)重復(fù)。
流量控制：是通過(guò)滑動(dòng)窗口實(shí)現(xiàn)的，因?yàn)榘l(fā)送發(fā)和接收方消息發(fā)送速度和接收速度不一定對(duì)等，所以需要一個(gè)滑動(dòng)窗口來(lái)平衡處理效率，并且保證沒(méi)有差錯(cuò)和有序的接收數(shù)據(jù)包。
擁塞控制：慢開(kāi)始和擁塞避免、快重傳和快恢復(fù)算法。這寫(xiě)算法主要是為了適應(yīng)網(wǎng)絡(luò)中的帶寬而作出的調(diào)整。
六、設(shè)計(jì)模式
經(jīng)常考察的設(shè)計(jì)模式不多，活學(xué)活用即可。
1. 六大原則
設(shè)計(jì)模式的六大原則是：
單一職責(zé)：合理分配類和函數(shù)的職責(zé)
開(kāi)閉原則：開(kāi)放擴(kuò)展，關(guān)閉修改
里式替換：繼承
依賴倒置：面向接口
接口隔離：控制接口的粒度
迪米特：一個(gè)類應(yīng)該對(duì)其他的類了解最少
2. 單例模式
單例模式被問(wèn)到的幾率很大，通常會(huì)問(wèn)如下幾種問(wèn)題。
# 單例的常用寫(xiě)法有哪幾種？
懶漢模式
public?該模式的主要問(wèn)題是每次獲取實(shí)例都需要同步，造成不必要的同步開(kāi)銷。
DCL模式
public?高并發(fā)環(huán)境下可能會(huì)發(fā)生問(wèn)題。
靜態(tài)內(nèi)部類單例
public?枚舉單例
public?優(yōu)點(diǎn)：線程安全和反序列化不會(huì)生成新的實(shí)例
# DCL模式會(huì)有什么問(wèn)題？
對(duì)象生成實(shí)例的過(guò)程中，大概會(huì)經(jīng)過(guò)以下過(guò)程：
為對(duì)象分配內(nèi)存空間。
初始化對(duì)象中的成員變量。
將對(duì)象指向分配的內(nèi)存空間(此時(shí)對(duì)象就不為null)。
由于Jvm會(huì)優(yōu)化指令順序，也就是說(shuō)2和3的順序是不能保證的。在多線程的情況下，當(dāng)一個(gè)線程完成了1、3過(guò)程后，當(dāng)前線程的時(shí)間片已用完，這個(gè)時(shí)候會(huì)切換到另一個(gè)線程，另一個(gè)線程調(diào)用這個(gè)單例，會(huì)使用這個(gè)還沒(méi)初始化完成的實(shí)例。
解決方法是使用volatile關(guān)鍵字：
public?3. 需要關(guān)注的設(shè)計(jì)模式
重點(diǎn)了解以下的幾種常用的設(shè)計(jì)模式：
工廠模式和抽象工廠模式：注意他們的區(qū)別。
責(zé)任鏈模式：View的事件分發(fā)和OkHttp的調(diào)用過(guò)程都使用到了責(zé)任鏈模式。
觀察者模式：重要性不言而喻。
代理模式：建議了解一下動(dòng)態(tài)代理。
4. MVC\MVP\MVVM
MVC、MVP和MVVM應(yīng)該是設(shè)計(jì)模式中考察頻率最高的知識(shí)點(diǎn)了，嚴(yán)格意義上來(lái)說(shuō)，它們不能算是設(shè)計(jì)模式，而是框架。
# MVC、MVP和MVVM是什么？
MVC：Model-View-Controller，是一種分層解偶的框架，Model層提供本地?cái)?shù)據(jù)和網(wǎng)絡(luò)請(qǐng)求，View層處理視圖，Controller處理邏輯，存在問(wèn)題是Controller層和View層的劃分不明顯，Model層和View層的存在耦合。
MVP：Model-View-Presenter，是對(duì)MVC的升級(jí)，Model層和View層與MVC的意思一致，但Model層和View層不再存在耦合，而是通過(guò)Presenter層這個(gè)橋梁進(jìn)行交流。
MVVM：Model-View-ViewModel，不同于上面的兩個(gè)框架，ViewModel持有數(shù)據(jù)狀態(tài)，當(dāng)數(shù)據(jù)狀態(tài)改變的時(shí)候，會(huì)自動(dòng)通知View層進(jìn)行更新。
# MVC和MVP的區(qū)別是什么？
MVP是MVC的進(jìn)一步解耦，簡(jiǎn)單來(lái)講，在MVC中，View層既可以和Controller層交互，又可以和Model層交互；而在MVP中，View層只能和Presenter層交互，Model層也只能和Presenter層交互，減少了View層和Model層的耦合，更容易定位錯(cuò)誤的來(lái)源。
# MVVM和MVP的最大區(qū)別在哪？
MVP中的每個(gè)方法都需要你去主動(dòng)調(diào)用，它其實(shí)是被動(dòng)的，而MVVM中有數(shù)據(jù)驅(qū)動(dòng)這個(gè)概念，當(dāng)你的持有的數(shù)據(jù)狀態(tài)發(fā)生變更的時(shí)候，你的View你可以監(jiān)聽(tīng)到這個(gè)變化，從而主動(dòng)去更新，這其實(shí)是主動(dòng)的。
# ViewModel如何知道View層的生命周期？
事實(shí)上，如果你僅僅使用ViewModel，它是感知不了生命周期，它需要結(jié)合LiveData去感知生命周期，如果僅僅使用DataBinding去實(shí)現(xiàn)MVVM，它對(duì)數(shù)據(jù)源使用了弱引用，所以一定程度上可以避免內(nèi)存泄漏的發(fā)生。
七、算法題
沒(méi)什么好說(shuō)的，Leetcode + 《劍指Offer》，著重記住一些解決問(wèn)題的思路。
除此以外，你還得記住一些常用的算法：排序、反轉(zhuǎn)鏈表、樹(shù)的遍歷和手寫(xiě)LruCache，這些都寫(xiě)不出來(lái)，就尷尬了。
如果你不想閱讀書(shū)籍，可以參考一下這個(gè)Github，親眼見(jiàn)證了從3k Star到34k Star，跪了：
【fucking-algorithm】：
https://github.com/labuladong/fucking-algorithm
簡(jiǎn)歷中最重要的是項(xiàng)目經(jīng)歷。
可能有的同學(xué)會(huì)說(shuō)，我天天在公司擰螺絲，根本沒(méi)什么東西可寫(xiě)。
所以我們?cè)谄綍r(shí)的工作中，不應(yīng)該僅僅滿足于寫(xiě)一些業(yè)務(wù)代碼，而應(yīng)該常常思考：
在結(jié)合的業(yè)務(wù)的情況下，我可以再做一點(diǎn)什么？
對(duì)于已經(jīng)寫(xiě)完的代碼，我還可以做哪一些優(yōu)化？
九、寫(xiě)在最后
經(jīng)常聽(tīng)到一些同學(xué)調(diào)侃，Boss不聘、前程堪憂、拉不上鉤，確實(shí)，今年的大環(huán)境比較嚴(yán)峻，但是一些高級(jí)崗位仍然稀缺。
談一下我自己，小廠背景、18年畢業(yè)、普通學(xué)校，所以，大廠都沒(méi)給過(guò)面試機(jī)會(huì)，好在前兩周內(nèi)推成功了，我也抓住了這次機(jī)會(huì)，成功獲得了大廠的Offer。
所以我想表達(dá)什么？打鐵還需自身硬，一定是得建立完比較完整的知識(shí)體系的前提下，當(dāng)機(jī)會(huì)來(lái)臨的時(shí)候，才能夠穩(wěn)穩(wěn)地把握住，希望和大家共勉~
如果大家還有什么問(wèn)題，歡迎在下方留言和我討論。
分享不易，你的點(diǎn)贊是我分享的動(dòng)力。
注：因?yàn)槠L(zhǎng)，文章有所刪減。
主要參考：
https://github.com/LRH1993
本來(lái)每一章節(jié)開(kāi)始都是腦圖的，后來(lái)我看是在看不清就刪除了，抱著試一試的心態(tài)發(fā)現(xiàn)作者更新了百度云原圖下載，就又傳了一遍，就放最后吧，算是給堅(jiān)持到最后的朋友放置的福利，我試了下，湊合能看清。
如果還是想要更高清的自己下載哈：
鏈接:https://pan.baidu.com/s/1bUQccZiuLv8EVKImMDziZQ?
密碼:wyc8
●編號(hào)684，輸入編號(hào)直達(dá)本文
●輸入m獲取到文章目錄
推薦↓↓↓Java編程
更多推薦《25個(gè)技術(shù)類公眾微信》
涵蓋：程序人生、算法與數(shù)據(jù)結(jié)構(gòu)、黑客技術(shù)與網(wǎng)絡(luò)安全、大數(shù)據(jù)技術(shù)、前端開(kāi)發(fā)、Java、Python、Web開(kāi)發(fā)、安卓開(kāi)發(fā)、iOS開(kāi)發(fā)、C/C++、.NET、Linux、數(shù)據(jù)庫(kù)、運(yùn)維等。
總結(jié)
以上是生活随笔為你收集整理的android bitmap转图片_这是一份面向Android开发者的复习指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： H5开发流程
- 下一篇： Android OpenCV实现文字识别