1.熱修復(fù)的幾種方式

???? ??? 1.通過更改dex加載順序?qū)崿F(xiàn)熱修復(fù)

???? ??? 熱修復(fù)是基于dex分包方案，和Android虛擬機(jī)的類加載器（ClassLoader）實(shí)現(xiàn)的

???? ??? 在打包apk的時候庐氮，會把java文件通過類加載器編譯成class文件怀偷，然后把class文件組合成class.dex文件眉枕，dex文件會把每一個類的id檢索起來，存在一個鏈表里面损合。將編譯好的class文件贵试，拆分成多個dex文件，將應(yīng)用啟動時必須用到的類和這些類的應(yīng)用類放到主dex文件攀操，其他代碼放到次dex文件

???? ????Android中的 Java.lang.ClassLoader類也不同與java中的Java.lang.ClassLoader類，加載的是dex文件

當(dāng)分包完成之后秸抚，會形成一個dex包的有序數(shù)組速和，當(dāng)需要加載類加載器的時候，會從數(shù)組中第一個dex包開始加載剥汤，直到找到這個類為止

在apk安裝的時候系統(tǒng)會將dex文件優(yōu)化成odex文件颠放，在優(yōu)化的過程中會涉及一個預(yù)校驗(yàn)的過程

如果一個類的static方法，private方法吭敢，override方法以及構(gòu)造函數(shù)中引用了其他類碰凶，而且這些類都屬于同一個dex文件，此時該類就會被打上CLASS_ISPREVERIFIED

如果在運(yùn)行時被打上CLASS_ISPREVERIFIED的類引用了其他dex的類，就會報(bào)錯

正常的分包方案會保證相關(guān)類被打入同一個dex文件

想要使得patch可以被正常加載欲低，就必須保證類不會被打上CLASS_ISPREVERIFIED標(biāo)記辕宏。而要實(shí)現(xiàn)這個目的就必須要在分完包后的class中植入對其他dex文件中類的引用

要在已經(jīng)編譯完成后的類中植入對其他類的引用，就需要操作字節(jié)碼砾莱，慣用的方案是插樁瑞筐。常見的工具有javaassist，asm等

Tinker的思路是這樣的腊瑟，通過修復(fù)好的class.dex 和原有的class.dex比較差生差量包補(bǔ)丁文件patch.dex聚假，在手機(jī)上這個patch.dex又會和原有的class.dex 合并生成新的文件fix_class.dex，用這個新的fix_class.dex 整體替換原有的dexPathList的中的內(nèi)容闰非，可以說是從根本上把bug給干掉了膘格。

AndFix 提供了一種運(yùn)行時在Native修改Filed指針的方式，實(shí)現(xiàn)方法的替換财松，達(dá)到即時生效無需重啟瘪贱，大手機(jī)廠商定制了自己的ROM，所以很多底層實(shí)現(xiàn)的差異游岳，導(dǎo)致AndFix的兼容性并不是很好

Sophix 便取長補(bǔ)短政敢，采用全量替換的思路，從一種更高的層次實(shí)現(xiàn)了熱修復(fù)

http://www.reibang.com/p/16ed4d233fd1

2.app瘦身

? ? 1.相對于多套資源胚迫，只使用720P的一套資源喷户，差別不大

? ? 2.混淆proguard中，是否保留符號表访锻，可不保留

? ? 3.刪除無用的語言資源褪尝，gradle設(shè)置

? ? 4.使用tinypng有損壓縮

? ? 5.非透明大圖使用jpg格式

? ? 6.微信Android資源混淆打包工具，采用７zip對APP進(jìn)行極致壓縮

? ? 7.使用著色方案期犬，減少只是顏色不同的圖片河哑，例如selector

2.Android各版本新特性

http://www.reibang.com/p/c4f1bf460c8b

3.同步異步方式小結(jié)

標(biāo)準(zhǔn) I/O

應(yīng)用程序平時用到 read/write 操作都屬于標(biāo)準(zhǔn) I/O，也就是緩存 I/O（Buffered I/O）龟虎。它的關(guān)鍵特性有：

對于讀操作璃谨，當(dāng)應(yīng)用程序讀取某塊數(shù)據(jù)時，如果這塊數(shù)據(jù)已經(jīng)在頁緩存中鲤妥，那么就不需要經(jīng)過物理讀盤操作佳吞。

對于寫操作，應(yīng)用程序會先將數(shù)據(jù)寫到頁緩存中去棉安，不需要等全部數(shù)據(jù)被寫回磁盤底扳，系統(tǒng)會定期將頁緩存中的數(shù)據(jù)刷到磁盤上。

mmap

mmap 把文件映射到進(jìn)程的地址空間贡耽，提高了 I/O 的性能衷模。

mmap 的優(yōu)點(diǎn)有：

減少系統(tǒng)調(diào)用鹊汛。只需要一次 mmap() 系統(tǒng)調(diào)用，后續(xù)所有的調(diào)用像操作內(nèi)存一樣阱冶。

減少數(shù)據(jù)拷貝刁憋。mmap 只需要從磁盤拷貝一次，由于做過內(nèi)存映射熙揍，不需要再拷貝回用戶空間职祷。

可靠性高协屡。mmap 把數(shù)據(jù)寫入頁緩存后郑口，跟緩存 I/O 的延遲寫機(jī)制一樣。

存在的缺點(diǎn)：

虛擬內(nèi)存增大醉箕。Apk意系、Dex泥耀、so 都是通過 mmap 讀取。mmap 會導(dǎo)致虛擬內(nèi)存增大蛔添，mmap 大文件容易出現(xiàn) OOM痰催。

磁盤延遲。mmap 通過缺頁中斷向磁盤發(fā)起真正的磁盤 I/O迎瞧，不能通過 mmap 消除磁盤 I/O 的延遲夸溶。

在 Android 中可以將文件通過 MemoryFile 或者 MappedByteBuffer 映射到內(nèi)存，然后進(jìn)行讀寫凶硅，使用這種方式對于小文件和頻繁讀寫操作的文件還是有一定優(yōu)勢的缝裁。

Direct I/O

直接 I/O 訪問文件方式減少了一次數(shù)據(jù)拷貝和一些系統(tǒng)調(diào)用的耗時，很大程度降低了 CPU 的使用率以及內(nèi)存的占用足绅。負(fù)面影響就是讀寫操作都是同步執(zhí)行捷绑，導(dǎo)致應(yīng)用程序等待。

NIO 是非阻塞 I/O氢妈，將 I/O 以事件的方式通知粹污，可以減少線程切換的開銷。NIO 的最大作用不是減少讀取文件的耗時首量，而是最大化提升應(yīng)用整體的 CPU 利用率壮吩。

4.eventbus

Event：事件，它可以是任意類型加缘，EventBus會根據(jù)事件類型進(jìn)行全局的通知粥航。

Subscriber：事件訂閱者，在EventBus 3.0之前我們必須定義以onEvent開頭的那幾個方法生百，分別是onEvent、onEventMainThread柄延、onEventBackgroundThread和onEventAsync蚀浆，而在3.0之后事件處理的方法名可以隨意取缀程，不過需要加上注解@subscribe，并且指定線程模型市俊，默認(rèn)是POSTING杨凑。

Publisher：事件的發(fā)布者，可以在任意線程里發(fā)布事件摆昧。一般情況下撩满，使用EventBus.getDefault()就可以得到一個EventBus對象，然后再調(diào)用post(Object)方法即可绅你。

四種線程模型

1.POSTING：默認(rèn)伺帘，表示事件處理函數(shù)的線程跟發(fā)布事件的線程在同一個線程。

2.MAIN：表示事件處理函數(shù)的線程在主線程(UI)線程忌锯，因此在這里不能進(jìn)行耗時操作伪嫁。

3.BACKGROUND：表示事件處理函數(shù)的線程在后臺線程，因此不能進(jìn)行UI操作偶垮。如果發(fā)布事件的線程是主線程(UI線程)张咳，那么事件處理函數(shù)將會開啟一個后臺線程，如果果發(fā)布事件的線程是在后臺線程似舵，那么事件處理函數(shù)就使用該線程脚猾。

4.ASYNC：表示無論事件發(fā)布的線程是哪一個，事件處理函數(shù)始終會新建一個子線程運(yùn)行砚哗，同樣不能進(jìn)行UI操作龙助。

使用流程

接收者復(fù)寫

doCreateView 注冊監(jiān)聽

?onDestroy

?onGetMessage 用@Subscribe注解指定線程模式，priority指定優(yōu)先級 ?

onGetStickyEvent 獲取粘性廣播频祝，即注冊接收器后也能收到之前的廣播 對應(yīng)的發(fā)送為postSticky

發(fā)送者 post message

regist

你只要記得一件事：掃描了所有的方法泌参，把匹配的方法最終保存在

subscriptionsByEventType（Map，key：eventType 常空； value：CopyOnWriteArrayList<Subscription>?）中沽一；

eventType是我們方法參數(shù)的Class，Subscription中則保存著

subscriber, subscriberMethod（method, threadMode, eventType）, priority漓糙；包含了執(zhí)行改方法所需的一切铣缠。

post會根據(jù)實(shí)參去map查找進(jìn)行反射調(diào)用postToSubscription，然后判斷應(yīng)該在哪個線程去執(zhí)行該方法

5.死鎖

1.互斥條件：進(jìn)程對于所分配到的資源具有排它性昆禽，即一個資源只能被一個進(jìn)程占用蝗蛙，直到被該進(jìn)程釋放

2.請求和保持條件：一個進(jìn)程因請求被占用資源而發(fā)生阻塞時，對已獲得的資源保持不放醉鳖。

3.不剝奪條件：任何一個資源在沒被該進(jìn)程釋放之前捡硅，任何其他進(jìn)程都無法對他剝奪占用

4.循環(huán)等待條件：當(dāng)發(fā)生死鎖時，所等待的進(jìn)程必定會形成一個環(huán)路（類似于死循環(huán)）盗棵，造成永久阻塞壮韭。

解決死鎖的基本方法

預(yù)防死鎖：

資源一次性分配：一次性分配所有資源北发，這樣就不會再有請求了：（破壞請求條件）

只要有一個資源得不到分配，也不給這個進(jìn)程分配其他的資源：（破壞請保持條件）

可剝奪資源：即當(dāng)某進(jìn)程獲得了部分資源喷屋，但得不到其它資源琳拨，則釋放已占有的資源（破壞不可剝奪條件）

資源有序分配法：系統(tǒng)給每類資源賦予一個編號，每一個進(jìn)程按編號遞增的順序請求資源屯曹，釋放則相反（破壞環(huán)路等待條件）

6XML

有DOM狱庇、SAX、PULL三種解析方式

DOM是基于文檔驅(qū)動的方式恶耽∶苋危可用于直接訪問 XML 文檔的各個部分。

它是一次性全部將內(nèi)容加載在內(nèi)存中驳棱，生成一個樹狀結(jié)構(gòu),它沒有涉及回調(diào)和復(fù)雜的狀態(tài)管理批什。缺點(diǎn)是加載大文檔時效率低下。

SAX使用流式處理的方式社搅。是以事件為驅(qū)動的XML API驻债，使用回調(diào)函數(shù)來實(shí)現(xiàn)。優(yōu)點(diǎn)是解析速度快形葬，占用內(nèi)存少合呐。缺點(diǎn)是不能倒退。

PULL內(nèi)置于 Android 系統(tǒng)中笙以。也是官方解析布局文件所使用的方式淌实。

Pull 與 SAX 有點(diǎn)類似，都提供了類似的事件猖腕，如開始元素和結(jié)束元素拆祈。不同的是Pull解析器并沒有強(qiáng)制要求提供觸發(fā)的方法。因?yàn)樗|發(fā)的事件不是一個方法倘感，而是一個數(shù)字放坏。它使用方便，效率高老玛。

7.Asset目錄與res目錄的區(qū)別

assets：不會在 R文件中生成相應(yīng)標(biāo)記淤年，存放到這里的資源在打包時會打包到程序安裝包中。（通過 AssetManager 類訪問這些文件）

res：會在R文件中生成 id標(biāo)記蜡豹，資源在打包時如果使用到則打包到安裝包中麸粮，未用到不會打入安裝包中。

8.序列化镜廉，

https://blog.csdn.net/qq_25722767/article/details/51879120

表示將一個對象轉(zhuǎn)換成可存儲或可傳輸?shù)臓顟B(tài)弄诲。

需要序列化的原因有三種情況：

永久性保存對象，將對象的字節(jié)序列存儲到本地文件中娇唯；

對象在網(wǎng)絡(luò)中傳遞齐遵；

對象在IPC間傳遞凤巨。

9.Recyclerview和Listview的區(qū)別

在ListView中，ViewHolder需要自己來定義洛搀。通過ViewHolder可以緩存item里的view控件實(shí)例，避免了在getview中重復(fù)創(chuàng)建帶來的性能損耗佑淀，但這只是一種推薦的使用方式留美，不是必須使用的。而在RecyclerView中使用RecyclerView.ViewHolder則變成了必須伸刃，盡管實(shí)現(xiàn)起來稍顯復(fù)雜谎砾，但是在性能提升上有很大的好處。

ListView只能在垂直方向上滾動捧颅，Android API沒有提供直接讓ListView在水平方向上面滾動的支持景图。但RecyclerView提供了多種類型的展示方式，很容易就能修改展示方式碉哑。

挚币。

ListView對item的點(diǎn)擊事件實(shí)現(xiàn)較為簡單，Recyclerview的點(diǎn)擊事件實(shí)現(xiàn)就相對復(fù)雜扣典，但靈活性高妆毕。

ListView沒有提供局部刷新，RecyclerView提供了局部刷新的方法贮尖，而且在局部刷新的時候有一個漸變的動畫效果笛粘。

其實(shí)就是使用好帶payload參數(shù)的這個notifyItemChanged方法，以及重寫帶payload的這個onBindViewHolder方法湿硝，在onBindViewHolder中去刷新你想更新的控件即可薪前。

10.SparseArray

SparseArray比HashMap更省內(nèi)存，在某些條件下性能更好关斜，主要是因?yàn)樗苊饬藢ey的自動裝箱（int轉(zhuǎn)為Integer類型）示括，它內(nèi)部則是通過兩個數(shù)組來進(jìn)行數(shù)據(jù)存儲的，一個存儲key蚤吹，另外一個存儲value例诀，為了優(yōu)化性能，它內(nèi)部對數(shù)據(jù)還采取了壓縮的方式來表示稀疏數(shù)組的數(shù)據(jù)裁着，從而節(jié)約內(nèi)存空間繁涂。

SparseArray在存儲和讀取數(shù)據(jù)時候，使用的是二分查找法二驰。

數(shù)據(jù)量不大扔罪，最好在千級以內(nèi)

key必須為int類型，這中情況下的HashMap可以用SparseArray代替

11.對稱加密 非對稱加密

對稱加密:A與 B 之間之間的通訊數(shù)據(jù)都用同一套的密鑰來進(jìn)行加密解密桶雀。

優(yōu)點(diǎn)

簡單快捷矿酵，密鑰較短唬复，且破譯困難。

缺點(diǎn)

如果用戶一旦多的話全肮，管理密鑰也是一種困難敞咧。不方便直接溝通的兩個用戶之間怎么確定密鑰也需要考慮，這其中就會有密鑰泄露的風(fēng)險(xiǎn)辜腺，以及存在更換密鑰的需求休建。

對稱加密通常有 DES,IDEA,3DES 加密算法。

非對稱加密：用公鑰和私鑰來加解密的算法评疗。打個比方测砂，A 的公鑰加密過的東西只能通過 A 的私鑰來解密；同理百匆，A 的私鑰加密過的東西只能通過 A 的公鑰來解密砌些。顧名思義，公鑰是公開的加匈，別人可以獲取的到存璃；私鑰是私有的，只能自己擁有矩动。

缺點(diǎn)

加解密比對稱加密耗時.

優(yōu)點(diǎn)

比對稱加密安全.

但是非對稱加密也是存在漏洞有巧，因?yàn)楣€是公開的，如果有 C 冒充 B 的身份利用 A 的公鑰給 A 發(fā)消息悲没，這樣就亂套了篮迎，所以接下來就采用非對稱加密+摘要算法+數(shù)字簽名的機(jī)制來確保傳輸安全。

常見的非對稱加密算法有：RSA示姿、ECC（移動設(shè)備用）甜橱、Diffie-Hellman、El Gamal栈戳、DSA（數(shù)字簽名用）

12 listview下拉刷新

13 LRU

LruCache（Least Recently Used）算法的核心思想就是最近最少使用算法岂傲。

由此可見LruCache中維護(hù)了一個集合LinkedHashMap，該LinkedHashMap是以訪問順序排序的子檀。當(dāng)調(diào)用put()方法時镊掖，就會在結(jié)合中添加元素，并調(diào)用trimToSize()判斷緩存是否已滿褂痰，如果滿了就用LinkedHashMap的迭代器刪除隊(duì)尾元素亩进，即最近最少訪問的元素。當(dāng)調(diào)用get()方法訪問緩存對象時缩歪，就會調(diào)用LinkedHashMap的get()方法獲得對應(yīng)集合元素归薛，同時會更新該元素到隊(duì)頭。

sqlite cache策略

SQLite緩存替換算法是LRU（Least Recently Used，最近最少使用算法）主籍。實(shí)現(xiàn)比較簡單习贫，主要是由兩部分組成：

hash表。hash表主要是加快對緩存中數(shù)據(jù)頁的查找速度千元。hash表后面是一串鏈表苫昌，保存滿足該hash函數(shù)的所有的頁。SQLite是通過頁號來進(jìn)行hash操作的幸海，hash完找到鏈表的頭結(jié)點(diǎn)蜡歹，然后依次查找。

LRU鏈表涕烧。LRU鏈表是通過SQLite操作hash表中的元素的來實(shí)現(xiàn)的。SQLite對hash表中頁進(jìn)行一次操作汗洒，就會將該頁放到LRU鏈表的頭部议纯，因?yàn)樵擁撌亲罱畛Ｓ玫降摹Ｈ绻彺嫘枰鎿Q溢谤，則需要從LRU鏈表尾部取出瞻凤，然后回寫到數(shù)據(jù)庫文件中。

14gradle的工作原理

有一個語言叫g(shù)roovy 世杀，咱用它制定一些規(guī)則阀参，來完成上面所說的操蛋的構(gòu)建的事。這種新的腳本語言就是gradle

15.GreenDao數(shù)據(jù)庫

GreenDAO是一個開源的Android ORM(“對象/關(guān)系映射”)瞻坝，通過ORM（稱為“對象/關(guān)系映射”）

DaoMaster:：DaoMaster保存數(shù)據(jù)庫對象（SQLiteDatabase）并管理特定模式的DAO類（而不是對象）蛛壳。它有靜態(tài)方法來創(chuàng)建表或刪除它們。它的內(nèi)部類OpenHelper和DevOpenHelper是SQLiteOpenHelper實(shí)現(xiàn)所刀，它們在SQLite數(shù)據(jù)庫中創(chuàng)建模式衙荐。

DaoSession：管理特定模式的所有可用DAO對象，您可以使用其中一個getter方法獲取該對象浮创。DaoSession還提供了一些通用的持久性方法忧吟，如實(shí)體的插入，加載斩披，更新溜族，刷新和刪除。

XXXDao：數(shù)據(jù)訪問對象（DAO）持久存在并查詢實(shí)體垦沉。對于每個實(shí)體煌抒，greenDAO生成DAO。它具有比DaoSession更多的持久性方法乡话，例如：count摧玫，loadAll和insertInTx。

Entities ：可持久化對象。通常, 實(shí)體對象代表一個數(shù)據(jù)庫行使用標(biāo)準(zhǔn) Java 屬性(如一個POJO 或 JavaBean )诬像。

16屋群，AOP面向切片編程

AOP（Aspect-Oriented Programming，面向切面的編程）坏挠，它是可以通過預(yù)編譯方式和運(yùn)行期動態(tài)代理實(shí)現(xiàn)在不修改源代碼的情況下給程序動態(tài)統(tǒng)一添加功能的一種技術(shù)芍躏。它是一種新的方法論，它是對傳統(tǒng)OOP編程的一種補(bǔ)充降狠。

AOP在安卓中主要是指把某一方面的一些功能提取出來與一批對象進(jìn)行隔離对竣，提取之后我們就可以對某個單方面的功能進(jìn)行編程，如請求網(wǎng)絡(luò)時榜配，需要先判斷網(wǎng)絡(luò)是否連通

17.sf

這兩個方法的區(qū)別在于：

1. apply沒有返回值而commit返回boolean表明修改是否提交成功

2. apply是將修改數(shù)據(jù)原子提交到內(nèi)存, 而后異步真正提交到硬件磁盤, 而commit是同步的提交到硬件磁盤否纬，因此，在多個并發(fā)的提交commit的時候蛋褥，他們會等待正在處理的commit保存到磁盤后在操作临燃，從而降低了效率。而apply只是原子的提交到內(nèi)容烙心，后面有調(diào)用apply的函數(shù)的將會直接覆蓋前面的內(nèi)存數(shù)據(jù)膜廊，這樣從一定程度上提高了很多效率。

3. apply方法不會提示任何失敗的提示淫茵。

18java虛擬機(jī)和dalvik虛擬機(jī)

Dalvik和Java之間的另外一大區(qū)別就是運(yùn)行環(huán)境——Dalvik經(jīng)過優(yōu)化爪瓜，允許在有限的內(nèi)存中同時運(yùn)行多個虛擬機(jī)的實(shí)例，并且每一個 Dalvik應(yīng)用作為一個獨(dú)立的Linux進(jìn)程執(zhí)行匙瘪。

（1）虛擬機(jī)很小铆铆，使用的空間也小丹喻；

（2）Dalvik沒有JIT編譯器算灸；

（3）常量池已被修改為只使用32位的索引，以簡化解釋器驻啤；

（4）它使用自己的字節(jié)碼菲驴，而非Java字節(jié)碼

19 數(shù)據(jù)庫隔離等級

數(shù)據(jù)庫四個隔離級別為read uncommitted，read committed骑冗，repeatable read赊瞬，serializable，依次解決臟讀贼涩，不可重復(fù)讀巧涧，幻讀問題。

read uncommitted：寫事務(wù)阻止其他寫事務(wù)遥倦，避免了更新遺失谤绳，但是未阻止讀事務(wù)占锯。

read committed：寫事務(wù)阻止讀寫事務(wù)，讀事務(wù)不會阻止其他事務(wù)缩筛。解決臟讀問題

repeatable read：讀事務(wù)會阻止其他寫事務(wù)消略，但不會阻止其他讀事務(wù)。解決不可重復(fù)讀問題

serializable：讀加共享鎖瞎抛，寫加排他鎖艺演。讀事務(wù)可并發(fā)。但是讀寫桐臊，寫寫互斥胎撤，基本上是一個個執(zhí)行事務(wù)，所以叫做串行化断凶。解決幻讀問題

臟讀：讀取到未提交數(shù)據(jù)伤提，導(dǎo)致獲取到不準(zhǔn)確數(shù)據(jù)。

不可重復(fù)讀： （同一個事務(wù)中）同一select語句认烁，兩次讀取到已提交數(shù)據(jù)飘弧，數(shù)據(jù)內(nèi)容（數(shù)據(jù)信息）不一致。

幻讀：（可以不是同一事務(wù)）同一select語句砚著， 兩次讀取到已提交數(shù)據(jù)，數(shù)據(jù)內(nèi)容（數(shù)據(jù)條數(shù)）不一致痴昧。

23.observer模式的應(yīng)用和 update的區(qū)別

24 rxjava的理解

RxJava 的優(yōu)勢也是簡潔稽穆，但它的簡潔的與眾不同之處在于，隨著程序邏輯變得越來越復(fù)雜赶撰，它依然能夠保持簡潔舌镶。

http://www.reibang.com/p/b1ab67ebdfca

25.dagger2+rxjava+retrofit2+mvp

dagger2的優(yōu)勢，省去無謂的體力勞動豪娜，增加開發(fā)效率餐胀，代碼解耦

rxjava的優(yōu)勢，盡管項(xiàng)目里的邏輯不斷的變?yōu)閺?fù)雜瘤载，但是rxjava異步代碼依然簡潔易懂否灾。

retrofit2的優(yōu)勢，簡潔功能卻強(qiáng)勁鸣奔，自定義GSON解析墨技，添加攔截器等

mvp的優(yōu)勢，結(jié)構(gòu)清晰挎狸，代碼解耦扣汪，維護(hù)性較高

26 保活

常用的毕谴遥活方式

Activity提權(quán)

Service提權(quán)

廣播拉活

“全家桶”拉活

Service機(jī)制(Sticky)拉活

賬戶同步拉活

JobScheduler拉活

推送拉活

Native拉活(NDK)

雙進(jìn)程守護(hù)(JobScheduler和兩個Service結(jié)合用)

27 glide

現(xiàn)在Android上的圖片加載框架非常成熟崭别，從最早的老牌圖片加載框架UniversalImageLoader，到后來Google推出的Volley，再到后來的新興軍Glide和Picasso茅主，當(dāng)然還有Facebook的Fresco舞痰。每一個都非常穩(wěn)定，功能也都十分強(qiáng)大暗膜。但是它們的使用場景基本都是重合的匀奏，也就是說我們基本只需要選擇其中一個來進(jìn)行學(xué)習(xí)和使用就足夠了，每一個框架都嘗試去掌握的話則有些浪費(fèi)時間学搜。Glide和Picasso 有90%相似度娃善，而Glide在Picasso基礎(chǔ)上進(jìn)行的二次開發(fā)，可以其優(yōu)勢顯而易見瑞佩。

兩級內(nèi)存緩存：先從LruCache中尋找聚磺，如果找到了緩存，將圖片移出LruCache炬丸，加入activeResources弱引用緩存瘫寝。如果在LruCache中沒找到的話到activeResources弱引用緩存中尋找。如果在內(nèi)存緩存中找到稠炬，則引用計(jì)數(shù)加1焕阿。使用中的圖片用弱引用緩存來管理，沒有使用的圖片用LruCache來管理首启，判斷圖片有沒有使用的依據(jù)之一是引用計(jì)數(shù)暮屡，當(dāng)引用計(jì)數(shù)等于0時，將圖片從弱引用緩存中移走毅桃，加入LruCache中褒纲。

http://www.reibang.com/p/7b1ff697b06f

28 butterknife

ButterKnife是一個專注于Android系統(tǒng)的View注入框架,以前總是要寫很多findViewById來找到View對象，有了ButterKnife可以很輕松的省去這些步驟钥飞。是大神JakeWharton的力作莺掠，目前使用很廣。最重要的一點(diǎn)读宙，使用ButterKnife對性能基本沒有損失彻秆，因?yàn)锽utterKnife用到的注解并不是在運(yùn)行時反射的，而是在編譯的時候生成新的class结闸。項(xiàng)目集成起來也是特別方便掖棉，使用起來也是特別簡單。

29git

rebase會把你當(dāng)前分支的 commit 放到公共分支的最后面,所以叫變基

不要在公共分支使用rebase

本地和遠(yuǎn)端對應(yīng)同一條分支,優(yōu)先使用rebase,而不是merge

為什么不要再公共分支使用rebase?

因?yàn)橥蠓诺倪@些 commit 都是新的,這樣其他從這個公共分支拉出去的人膀估，都需要再 rebase,相當(dāng)于你 rebase 東西進(jìn)來幔亥，就都是新的 commit 了

設(shè)計(jì)模式

https://www.cnblogs.com/davidwang456/p/11328433.html

工廠模式

https://www.runoob.com/design-pattern/factory-pattern.html

觀察者模式

https://www.runoob.com/design-pattern/observer-pattern.html

生產(chǎn)消費(fèi)模式

https://blog.csdn.net/Virgil_K2017/article/details/89283946

mvp

https://blog.csdn.net/pizifusheng/article/details/80948341

單例模式

http://www.reibang.com/p/ad86f107425c

apk打包過程

過AAPT工具進(jìn)行資源文件（包括AndroidManifest.xml、布局文件察纯、各種xml資源等）的打包帕棉，生成R.java文件针肥。

通過AIDL工具處理AIDL文件，生成相應(yīng)的Java文件香伴。

通過Javac工具編譯項(xiàng)目源碼慰枕，生成Class文件。

通過DX工具將所有的Class文件轉(zhuǎn)換成DEX文件即纲，該過程主要完成Java字節(jié)碼轉(zhuǎn)換成Dalvik字節(jié)碼具帮，壓縮常量池以及清除冗余信息等工作。

通過ApkBuilder工具將資源文件低斋、DEX文件打包生成APK文件蜂厅。

利用KeyStore對生成的APK文件進(jìn)行簽名。

如果是正式版的APK膊畴，還會利用ZipAlign工具進(jìn)行對齊處理掘猿，對齊的過程就是將APK文件中所有的資源文件舉例文件的起始距離都偏移4字節(jié)的整數(shù)倍，這樣通過內(nèi)存映射訪問APK文件

的速度會更快唇跨。

APK的安裝流程

資源管理器解析APK里的資源文件稠通。

解析AndroidManifest文件，并在/data/data/目錄下創(chuàng)建對應(yīng)的應(yīng)用數(shù)據(jù)目錄买猖。

然后對dex文件進(jìn)行優(yōu)化改橘，并保存在dalvik-cache目錄下。

將AndroidManifest文件解析出的四大組件信息注冊到PackageManagerService中玉控。

安裝完成后飞主，發(fā)送廣播。

WEEX

本質(zhì)

新建WebViewManager繼承自SimpleViewManager<BridgeWebView>

實(shí)現(xiàn)createViewInstance方法 返回一個webview實(shí)例

兩種交互方式

1.通過injectedJavaScript 注入JS 奸远，在H5頁面加載之后立即執(zhí)行。相當(dāng)于webview端主動調(diào)用

2.Webview 和 H5 相互發(fā)送監(jiān)聽消息

?Weex主要包括三大部分：JS Bridge讽挟、Render懒叛、Dom，分別對應(yīng)WXBridgeManager耽梅、WXRenderManager薛窥、WXDomManager?。通過WXSDKManager統(tǒng)一管理眼姐。其中JS Bridge和Dom運(yùn)行在獨(dú)立的HandlerThread中诅迷，而Render運(yùn)行在UI線程。JS Bridge主要用來和 JS 端實(shí)現(xiàn)進(jìn)行雙向通信众旗，比如把js端的dom結(jié)構(gòu)傳遞給Dom線程罢杉。Dom主要是用于負(fù)責(zé)dom的解析、映射贡歧、添加等等的操作滩租，最后通知UI線程更新赋秀。而Render負(fù)責(zé)在UI線程中對dom實(shí)現(xiàn)渲染。

Weex 渲染流程

虛擬DOM.

構(gòu)造樹結(jié)構(gòu). 分析虛擬DOM JSON數(shù)據(jù)以構(gòu)造渲染樹(RT).

添加樣式. 為渲染樹的各個節(jié)點(diǎn)添加樣式.

創(chuàng)建視圖. 為渲染樹各個節(jié)點(diǎn)創(chuàng)建Native視圖.

綁定事件. 為Native視圖綁定事件.

CSS布局. 使用 css-layout 來計(jì)算各個視圖的布局.

更新視窗(Frame). 采用上一步的計(jì)算結(jié)果來更新視窗中各個視圖的最終布局位置.

最終頁面呈現(xiàn).

skia

https://blog.csdn.net/jxt1234and2010/article/details/42572559

指令層：SkPicture律想、SkDeferredCanvas->SkCanvas

這一層決定需要執(zhí)行哪些繪圖操作猎莲，繪圖操作的預(yù)變換矩陣，當(dāng)前裁剪區(qū)域技即，繪圖操作產(chǎn)生在哪些layer上著洼，Layer的生成與合并。

2而叼、解析層：SkBitmapDevice->SkDraw->SkScan身笤、SkDraw1Glyph::Proc

這一層決定繪制方式，完成坐標(biāo)變換澈歉，解析出需要繪制的形體（點(diǎn)/線/規(guī)整矩形）并做好抗鋸齒處理展鸡，進(jìn)行相關(guān)資源解析并設(shè)置好Shader。

3埃难、渲染層：SkBlitter->SkBlitRow::Proc莹弊、SkShader::shadeSpan等

這一層進(jìn)行采樣（如果需要），產(chǎn)生實(shí)際的繪制效果涡尘，完成顏色格式適配忍弛，進(jìn)行透明度混合和抖動處理（如果需要）

指令層與實(shí)現(xiàn)層分離

SkCanvas不直接執(zhí)行渲染，由SkBaseDevice根據(jù)設(shè)備類型考抄，選擇渲染方法细疚。這樣雖然是同一套API，但可以用作GPU繪圖川梅、pdf繪制疯兼、存儲顯示列表等各種功能。在API集上做優(yōu)化贫途，避免冗余繪制吧彪，也因此成為可能（注：這個google雖然在嘗試，但目前看來沒有明顯效果丢早，實(shí)現(xiàn)起來確實(shí)也很困難）姨裸。

2、圖=形+色的設(shè)計(jì)思想

由SkDraw和SkScan類中控制繪制的形怨酝，由SkBlitter和SkShader控制繪制的色傀缩，將繪圖操作分解為形狀與色彩兩部分，這一點(diǎn)和OpenGL的頂點(diǎn)變換——光柵——片斷著色管線相似农猬，非常有利于擴(kuò)展赡艰，各種2D圖元的繪制基本上就完全支持了。

3斤葱、性能調(diào)優(yōu)集中化

將耗時的函數(shù)抽象都抽象為proc瞄摊，由一個工廠制造勋又，便于集中對這一系列函數(shù)做優(yōu)化。

圖像處理

這種情況下换帜，開發(fā)者自行基于目標(biāo)Bitmap創(chuàng)建Canvas楔壤，調(diào)用Canvas的API繪制圖像，一般是作圖像的縮放惯驼、旋轉(zhuǎn)處理蹲嚣，也可以加入漸變特效。（不是 lockCanvas 或 繼承 onDraw 方法中傳入的Canvas祟牲，就別想拿去上屏了）

3隙畜、圖像編解碼

Skia對各種類型的圖片作了適配，提供統(tǒng)一的接口说贝，開發(fā)者調(diào)用BitmapFactory议惰，BitmapFactory進(jìn)一步調(diào)用jni——skia。

（1）關(guān)于圖像全解乡恕，這部分調(diào)用邏輯看上去簡單言询，實(shí)際上對于輸入輸出流的處理還是比較復(fù)雜的，涉及Java的流——Skia規(guī)定的流——對應(yīng)解碼庫的流兩重轉(zhuǎn)換傲宜。

（2）關(guān)于區(qū)域解碼运杭，這部分是google為平衡內(nèi)存——性能——顯示速度而設(shè)計(jì)的方案，一些Android機(jī)器上的圖庫打開照片時有一塊一塊漸漸清晰的過程函卒，就是區(qū)域解碼然后局部刷新的結(jié)果辆憔。

區(qū)域解碼分成兩步：

a、創(chuàng)建tileIndex报嵌，以便查找某個區(qū)域所對應(yīng)的碼流位置虱咧。

b、解碼：輸入指定區(qū)域锚国，按照tileIndex查找對應(yīng)碼流腕巡，將對應(yīng)區(qū)域的圖片解出來，這個過程一般會調(diào)用多次跷叉。