1薄料、Glide緩存機(jī)制

Glide 優(yōu)點(diǎn)：支持 Gif、WebP泵琳、縮略圖摄职。甚至是 Video获列；支持優(yōu)先級處理；與 Activity/Fragment 生命周期一致击孩；內(nèi)存友好，默認(rèn) RGB_565

設(shè)置內(nèi)存緩存開關(guān)：skipMemoryCache(true)

設(shè)置磁盤緩存模式：diskCacheStrategy(DiskCacheStrategy.NONE)

可以設(shè)置4種模式：

DiskCacheStrategy.NONE：表示不緩存任何內(nèi)容巩梢。

DiskCacheStrategy.SOURCE：表示只緩存原始圖片。

DiskCacheStrategy.RESULT：表示只緩存轉(zhuǎn)換過后的圖片（默認(rèn)選項）且改。

DiskCacheStrategy.ALL ：表示既緩存原始圖片，也緩存轉(zhuǎn)換過后的圖片又跛。

Glide內(nèi)存緩存源碼分析

內(nèi)存存緩存的 讀存都在Engine類中完成。

Glide內(nèi)存緩存的特點(diǎn)

內(nèi)存緩存使用弱引用和LruCache結(jié)合完成的,弱引用來緩存的是正在使用中的圖片感混。圖片封裝類Resources內(nèi)部有個計數(shù)器判斷是該圖片否正在使用。

Glide內(nèi)存緩存的流程

讀：是先從lruCache取弧满，取不到再從弱引用中取庭呜；

存：內(nèi)存緩存取不到，從網(wǎng)絡(luò)拉取回來先放在弱引用里犀忱，渲染圖片募谎，圖片對象Resources使用計數(shù)加一；

渲染完圖片阴汇，圖片對象Resources使用計數(shù)減一数冬，如果計數(shù)為0，圖片緩存從弱引用中刪除搀庶，放入lruCache緩存拐纱。

Glide 流程：創(chuàng)建 Request 并將它交給RequestManager铜异，Request 啟動 Engine 去數(shù)據(jù)源獲取資源(通過 Fetcher )，獲取到后 Transformation 處理后交給 Target秸架。Glide 默認(rèn)通過 UrlConnection 獲取數(shù)據(jù)

2揍庄、三級緩存的流程

讀取： 內(nèi)存（強(qiáng)引用咕宿，軟引用）--文件--網(wǎng)絡(luò)

讀取圖片的時候，先讀取內(nèi)存緩存蜡秽，判斷強(qiáng)引用中是否存在圖片府阀，如果強(qiáng)引用中存在，則直接讀取芽突，如果強(qiáng)引用中不存在试浙，則判斷軟引用中是否存在，如果軟引用中存在寞蚌，則將軟引用中的圖片添加到強(qiáng)引用中并且刪除軟引用中的數(shù)據(jù)田巴，如果軟引用中不存在，則讀取文件存儲挟秤，如果文件存儲不存在壹哺，則網(wǎng)絡(luò)加載。

下載： 網(wǎng)絡(luò)--內(nèi)存（強(qiáng)引用艘刚，軟引用）--文件

首先根據(jù)圖片的網(wǎng)絡(luò)地址在網(wǎng)絡(luò)上下載圖片管宵，將圖片先緩存到內(nèi)存緩存中，緩存到強(qiáng)引用中 也就是LruCache中箩朴。如果強(qiáng)引用中空間不足秋度，就會將較早存儲的圖片對象驅(qū)逐到軟引用(softReference)中存儲，然后將圖片緩存到文件(內(nèi)部存儲外部存儲)中埠居；

LRU 是 Least Recently Used 最近最少使用算法：

其中用到的數(shù)據(jù)對象是LinkedHashMap事期，里面存儲的數(shù)據(jù)是強(qiáng)引用，當(dāng)每次訪問里面的一個值的時候捏浊，那么就將該數(shù)值放到隊列的頭部金踪，另一方面浊洞，當(dāng)添加的數(shù)據(jù)充滿整個隊列的時候法希，就將隊列的末尾數(shù)據(jù)移除苫亦，該移除的數(shù)據(jù)才有可能被系統(tǒng)進(jìn)行垃圾回收怨咪。

3、EventBus原理

1唉匾、EvenetBus是一種發(fā)布-訂閱事件總線.代碼簡潔,開銷小,并很好的實(shí)現(xiàn)了發(fā)送者和接收者的解耦.(是一種觀察者模式)

getDefault()是一個“雙重校驗鎖”的單例模式巍膘，

2芋簿、EventBus的三要素

Event：事件，可以是任意類型的對象逮诲。

Subscriber：事件訂閱者

在EventBus3.0之前幽告，消息處理的方法只能限定于onEvent、onEventMainThread齐唆、onEventBackgroundThread和onEventAsync箍邮，他們分別代表四種線程模型叨叙。

在EventBus3.0之后，事件處理的方法可以隨便取名味滞，但是需要添加一個注解@Subscribe剑鞍，并且要指定線程模型（默認(rèn)為POSTING），四種線程模型下面會講到便脊。

Publisher：事件發(fā)布者

可以在任意線程任意位置發(fā)送事件光戈，直接調(diào)用EventBus的post(Object)方法∩谓埽可以自己實(shí)例化EventBus對象乎莉，但一般使用EventBus.getDefault()就好了奸笤，根據(jù)post函數(shù)參數(shù)的類型哼鬓，會自動調(diào)用訂閱相應(yīng)類型事件的函數(shù)。

3健盒、 EventBus的四種ThreadMode（線程模型）

POSTING（默認(rèn)）：在哪個線程發(fā)布出來的扣癣，事件處理函數(shù)就會在這個線程中運(yùn)行憨降，盡量避免執(zhí)行耗時操作，因為它會阻塞事件的傳遞士嚎，甚至有可能會引起ANR莱衩。

MAIN:事件的處理會在UI線程中執(zhí)行娇澎。事件處理時間不能太長，長了會ANR的册招。

BACKGROUND：如果事件是在UI線程中發(fā)布出來的勒极，那么該事件處理函數(shù)就會在新的線程中運(yùn)行，如果事件本來就是子線程中發(fā)布出來的键痛，那么該事件處理函數(shù)直接在發(fā)布事件的線程中執(zhí)行匾七。在此事件處理函數(shù)中禁止進(jìn)行UI更新操作。

ASYNC：無論事件在哪個線程發(fā)布丁频，該事件處理函數(shù)都會在新建的子線程中執(zhí)行席里，同樣拢驾，此事件處理函數(shù)中禁止進(jìn)行UI更新操作。

EventBus的工作原理

6.1 訂閱邏輯

1咖为、首先用register（）方法注冊一個訂閱者

2躁染、獲取該訂閱者的所有訂閱的方法架忌，findSubscriberMethods(subscriberClass)

3、根據(jù)該訂閱者的所有訂閱的事件類型备畦，將訂閱者存入到每個以 事件類型為key 以所有訂閱者為values的map集合中

4懂盐、然后將訂閱事件添加到以訂閱者為key 以訂閱者所有訂閱事件為values的map集合中

5糕档、如果是訂閱了粘滯事件的訂閱者拌喉，從粘滯事件緩存區(qū)獲取之前發(fā)送過的粘滯事件尿背，響應(yīng)這些粘滯事件田藐。

6.2 事件發(fā)送邏輯

1吱七、首先獲取當(dāng)前線程的事件隊列

2、將要發(fā)送的事件添加到事件隊列中

3司浪、根據(jù)發(fā)送事件類型獲取所有的訂閱者

4威蕉、根據(jù)響應(yīng)方法的執(zhí)行模式窜管，在相應(yīng)線程通過反射執(zhí)行訂閱者的訂閱方法

6.3 取消邏輯

1、首先通過unregister方法拿到要取消的訂閱者

2舷丹、得到該訂閱者的所有訂閱事件類型

3蜓肆、遍歷事件類型仗扬，根據(jù)每個事件類型獲取到所有的訂閱者集合蕾额，并從集合中刪除該訂閱者

4、將訂閱者從步驟2的集合中移除

6.4 利與弊

EventBus好處比較明顯退个，它能夠解耦和语盈，將業(yè)務(wù)和視圖分離缰泡，代碼實(shí)現(xiàn)比較容易。而且3.0后缠借，我們可以通過apt預(yù)編譯找到訂閱者泼返，避免了運(yùn)行期間的反射處理解析，大大提高了效率趴捅。當(dāng)然EventBus也會帶來一些隱患和弊端霹疫，如果濫用的話會導(dǎo)致邏輯的分散并造成維護(hù)起來的困難丽蝎。另外大量采用EventBus代碼的可讀性也會變差。

4红省、Retrofit實(shí)現(xiàn)原理（squareup公司的開源）

Retrofit使用OkHttpClient來實(shí)現(xiàn)網(wǎng)絡(luò)請求吧恃，Retrofit使用動態(tài)代理麻诀，方法注解、建造者和適配器等成熟的技術(shù)或模式呻率。

1.動態(tài)代理創(chuàng)建一個接口的代理類

2.通過反射解析每個接口的注解呻引、入?yún)?gòu)造http請求

3.獲取到返回的http請求，使用Adapter解析成需要的返回值元践。

5单旁、oKhttp原理

OkHttp的底層是通過Java的Socket發(fā)送HTTP請求與接受響應(yīng)的(這也好理解惠啄，HTTP就是基于TCP協(xié)議的)任内，但是OkHttp實(shí)現(xiàn)了連接池的概念死嗦，即對于同一主機(jī)的多個請求越除，其實(shí)可以公用一個Socket連接外盯，而不是每次發(fā)送完HTTP請求就關(guān)閉底層的Socket饱苟，這樣就實(shí)現(xiàn)了連接池的概念。而OkHttp對Socket的讀寫操作使用的OkIo庫進(jìn)行了一層封裝类垦。

Okhttp支持5個并發(fā)KeepAlive城须，默認(rèn)鏈路生命為5分鐘(鏈路空閑后，保持存活的時間)砰琢，連接池有ConectionPool實(shí)現(xiàn)陪汽，對連接進(jìn)行回收和管理莺褒。

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

支持http請求雪情，https請求巡通。支持文件下載。

使用的是HttpURLConnection,不要擔(dān)心android版本的變換宴凉。（至少目前是都支持的）弥锄。

支持get蟆沫，post請求饭庞≈凵剑基于Http的文件上傳卤恳。加載圖片。

缺點(diǎn)：（400K）

比如callback回來是在線程里面, 不能刷新UI若债，需要我們手動處理拆座。

封裝比較麻煩冠息。

1逛艰、okhttp工作的大致流程

1.1、整體流程(建造者模式)

（1）菇绵、當(dāng)我們通過OkhttpClient創(chuàng)立一個Call咬最，并發(fā)起同步或者異步請求時欠动；

（2）、okhttp會通過Dispatcher（調(diào)度器）對我們所有的RealCall（Call的具體實(shí)現(xiàn)類）進(jìn)行統(tǒng)一管理翅雏，并通過execute()及enqueue()方法對同步或者異步請求進(jìn)行解決望几；線程池

（3）萤厅、execute()及enqueue()這兩個方法會最終調(diào)用RealCall中的getResponseWithInterceptorChain()方法，從阻攔器鏈中獲取返回結(jié)果楼誓；

（4）、阻攔器鏈中芬沉，依次通過RetryAndFollowUpInterceptor（重定向阻攔器）阁猜、BridgeInterceptor（橋接阻攔器）、CacheInterceptor（緩存阻攔器）黄刚、ConnectInterceptor（連接阻攔器）憔维、CallServerInterceptor（網(wǎng)絡(luò)阻攔器）對請求依次解決畏邢，與服務(wù)的建立連接后舒萎，獲取返回數(shù)據(jù)，再經(jīng)過上述阻攔器依次解決后章鲤，最后將結(jié)果返回給調(diào)用方败徊。

Volley

1.占用儲存空間

使用Volley 需要Volley.jar(120k)掏缎，加上自己的封裝最多140k。

2.功能介紹

Volley是Goole在2013年Google I/O大會上推出了一個新的網(wǎng)絡(luò)通信框架根欧，它是開源的。Volley 的特點(diǎn)：特別適合數(shù)據(jù)量小酥泛，通信頻繁的網(wǎng)絡(luò)操作。

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

非常適合進(jìn)行數(shù)據(jù)量不大呆躲，但通信頻繁的網(wǎng)絡(luò)操作。

內(nèi)部分裝了異步線程灰瞻。

支持get辅甥，post網(wǎng)絡(luò)請求璃弄。

圖片下載。

可直接在主線程調(diào)用服務(wù)端并處理返回結(jié)果疏咐。

可以取消請求脐供，容易擴(kuò)展政己，面向接口編程。

4.缺點(diǎn)

對大文件下載 Volley的表現(xiàn)非常糟糕仅孩。

只支持http請求辽慕。

接圖片加載赦肃，性能一般。

使用的是httpclient船侧，HttpURLConnection镜撩。不過在android 6.0不支持httpclient了队塘，如果想支持得添加org.apache.http.legacy.jar。

APK執(zhí)行過程

代碼編譯形成APK的過程中遮怜，其實(shí)在里面生成了一個classes.dex文件，解壓APK文件如下圖：

APK結(jié)構(gòu)

這個classes.dex文件就是所有代碼的集合即碗，是一個可執(zhí)行文件剥懒，apk運(yùn)行過程實(shí)質(zhì)上是解壓apk運(yùn)行classes.dex這個文件冯遂。

apk首次運(yùn)行的時候會對這個dex文件進(jìn)行優(yōu)化蛤肌，優(yōu)化后生成一個odex文件，存在于緩存中展东，下次再啟動就直接打開這個odex文件盐肃，達(dá)到快速打開目的权悟。而執(zhí)行apk的過程就是遍歷這個dex并作出相應(yīng)操作的過程，遍歷后的dex方法存放在一個Elements數(shù)組中谦铃，它的長度限制是65536.即日常說的65K.

如果我們apk因為太龐大或者是引用三方庫太多導(dǎo)致方法數(shù)超過65K,就會報錯.

而谷歌已經(jīng)在Android 5.0開始支持Multdex.

6驹闰、Tinker原理

簡單來說撒会，在編譯時通過新舊兩個Dex生成差異path.dex诵肛。在運(yùn)行時，將差異patch.dex重新跟原始安裝包的舊Dex還原為新的Dex惫谤。這個過程可能比較耗費(fèi)時間與內(nèi)存珠洗，所以我們是單獨(dú)放在一個后臺進(jìn)程:patch中。為了補(bǔ)丁包盡量的小蝴猪，微信自研了DexDiff算法自阱，它深度利用Dex的格式來減少差異的大小沛豌。

補(bǔ)丁包的合成流程：當(dāng)tinker收到補(bǔ)丁包bug path后赃额，它會開啟一個service，和當(dāng)前有問題的bug的dex合成一個新的fixed dex文件芍锦，然后置于tinker dex文件加載路徑娄琉。

補(bǔ)丁包的加載流程：獲取到fixed dex文件后吓歇，通過反射DexPathList中的dexElements數(shù)組城看，將fixed dex插入到dexElements數(shù)組的最前面。classloader在尋找bug class的時候主卫，找到的就是最前面的dex文件中我們已修復(fù)的fixed class簇搅。

AndFix（阿里開源）

提供了一種運(yùn)行時在Native修改Filed指針的方式软吐，實(shí)現(xiàn)方法的替換，達(dá)到即時生效無需重啟肠仪，對應(yīng)用無性能消耗的目的备典。

HotFix：QQ空間超級補(bǔ)丁技術(shù)

大眾點(diǎn)評：NuWa（不能修改資源文件，可動態(tài)加載）

7吮蛹、Android組件化開發(fā)

組件化好處：

1潮针、架構(gòu)清晰業(yè)務(wù)組件間完成接耦合倚喂。

2端圈、每個業(yè)務(wù)組件都可以根據(jù)BU需求完成獨(dú)立app發(fā)布。

3吨灭、開發(fā)中使開發(fā)者更加輕松喧兄，開發(fā)中加快功能開發(fā)調(diào)試的速度啊楚。

4、業(yè)務(wù)組件整體刪除添加替換變得非常輕松拯辙，減少工程中的代碼資源等冗余文件涯保。

5周伦、業(yè)務(wù)降級专挪，業(yè)務(wù)組件在促銷高峰期間可以業(yè)務(wù)為單元關(guān)閉片排，保證核心業(yè)務(wù)組件的順利執(zhí)行率寡。

#####項目組件化方案

概述：

1冶共、module library 切換潭枣。

2幻捏、組件間跳轉(zhuǎn)uri跳轉(zhuǎn)。

3谐岁、組件間通訊 binder機(jī)制伊佃。

主要有三個角色：

1沛善、主工程（殼工程mudele）：主要負(fù)責(zé)事情不塞入任何具體業(yè)務(wù)邏輯金刁，主要用于使用組合業(yè)務(wù)組件、初始化配置和發(fā)布應(yīng)用配置等操作媳友。

2醇锚、組件（module/library）：主要實(shí)現(xiàn)具體業(yè)務(wù)邏輯坯临，盡可能保證業(yè)務(wù)獨(dú)立性，例如現(xiàn)在手淘這樣一個大型的app幾乎每個bu功能塊都能夠拿出來作為一個獨(dú)立業(yè)務(wù)app赶促。但是沒有這么大型也可以按照小一些的業(yè)務(wù)邏輯來區(qū)分組件衷笋，例如：購物車組件、收銀臺組件爵赵、用戶中心組件等，具體更具自己的項目需要來劃分烁峭。

3约郁、公共庫（library）：公共使用的工具類但两、sdk等庫谨湘，例如eventbus、xutils坊罢、rxandroid擅耽、自定義工具類等等乖仇，這些庫可以做成一個公共common sdk、也可以實(shí)現(xiàn)抽離很細(xì)按照需求依賴使用航夺。

他們之間的關(guān)系則是 主工程依賴組件阳掐、組件依賴公共庫冷蚂。

組件開發(fā)中分為兩種模式一種開發(fā)測試模式蝙茶、一種是發(fā)布模式：

1、開發(fā)測試模式：這種模式下面組件應(yīng)該是獨(dú)立module模式钳恕，module是可以獨(dú)立運(yùn)行的，只要保證他對其他業(yè)務(wù)沒有依賴就可以獨(dú)立開發(fā)測試厘肮。

2类茂、發(fā)布模式：這時候組件應(yīng)該library模式被主工程依賴組合托嚣，發(fā)布運(yùn)行，所有業(yè)務(wù)將組合成完整app發(fā)布運(yùn)行兢哭。

Activity之間的跳轉(zhuǎn)：路由框架ARouter

是ARouter是阿里巴巴開源的Android平臺中對頁面厦瓢、服務(wù)提供路由功能的中間件啤月，提倡的是簡單且夠用谎仲。

GitHub：https://github.com/alibaba/ARouter

四：ARouter 優(yōu)勢

從 ARouter Github 了解到它的優(yōu)勢：

支持直接解析標(biāo)準(zhǔn)URL進(jìn)行跳轉(zhuǎn)郑诺，并自動注入?yún)?shù)到目標(biāo)頁面中

支持多模塊工程使用

支持添加多個攔截器，自定義攔截順序

支持依賴注入辙诞，可單獨(dú)作為依賴注入框架使用

支持InstantRun

支持MultiDex(Google方案)

映射關(guān)系按組分類飞涂、多級管理祈搜，按需初始化

支持用戶指定全局降級與局部降級策略

頁面容燕、攔截器、服務(wù)等組件均自動注冊到框架

支持多種方式配置轉(zhuǎn)場動畫

支持獲取Fragment

完全支持Kotlin以及混編

典型的應(yīng)用：

從外部URL映射到內(nèi)部頁面官卡，以及參數(shù)傳遞與解析

跨模塊頁面跳轉(zhuǎn)，模塊間解耦

攔截跳轉(zhuǎn)過程评甜，處理登陸仔涩、埋點(diǎn)等邏輯

跨模塊API調(diào)用熔脂，通過控制反轉(zhuǎn)來做組件解耦

---------------------?

8、Android插件化開發(fā)

Android 插件化—— 指將一個程序劃分為不同的部分旬薯，比如一般 App 的皮膚樣式就可以看成一個插件

Android 組件化—— 這個概念實(shí)際跟上面相差不那么明顯适秩，組件和插件較大的區(qū)別就是：組件是指通用及復(fù)用性較高的構(gòu)件秽荞，比如圖片緩存就可以看成一個組件被多個 App 共用

?Android 動態(tài)加載—— 這個實(shí)際是更高層次的概念，也有叫法是熱加載或 Android 動態(tài)部署阶捆，指容器（App）在運(yùn)?狀態(tài)下動態(tài)加載某個模塊钦听，從而新增功能或改變某?部分行為

? ? ?在java開發(fā)中隨處可見使用jar包的插件機(jī)制進(jìn)行開發(fā)朴上，但在android中痪宰，目前較成熟的插件機(jī)制基本沒有，看到的帖子中提到了重寫dexclassloader可以完美的解決插件問題碉碉，但都只簡要描述了原理淮韭，沒有源碼或關(guān)鍵代碼靠粪，下面對網(wǎng)絡(luò)中的思路進(jìn)行總結(jié)．

? ? ?目前插件包有兩種格式：一種是apk,一種是dex包．對插件的接入機(jī)制來說也有兩種：一種是需要安裝，一種是不需要安裝．結(jié)合插件包的格式來說插件的方式只有三種：１昔善，apk安裝，２翩概，apk不安裝钥庇，３咖摹，dex包．三種方式其實(shí)主要是解決兩個方面的問題：１，加載插件中的類吐句，２嗦枢，加載插件中的資源．第一個加載類的問題两入，這三個方式都可以很好的解決．但目前三種方式都沒有很完美的解決第２個問題．

? ? ?１，apk安裝方式．插件apk安裝后，可以在主程序中通過包名加載到插件的context,有了插件的context就可以解決加載插件資源的問題．但出現(xiàn)的新問題是：如果插件a,b,c間公用一個底層jar包紧武，那么在abc間傳送數(shù)據(jù)時，需要進(jìn)行序列化和反序列化朋鞍，因為a中jar包的data類與b中jar包的data類雖然都是同樣的jar包也是同樣的類滥酥，但兩個類在java機(jī)制來是由不同的classloader加載的坎吻，是不同的類．那么就會出現(xiàn)插件間jar包冗余和數(shù)據(jù)傳遞的效率不好問題．總之能解決問題．

? ? ?２宇葱，apk不安裝，這個是不推薦的方式．可以通過dexclassloader加載到插件a中的類诸尽，但插件沒有安裝就無法獲得插件apk的context您机，也就無法加載到資源，網(wǎng)絡(luò)上有牛人通過將主程序的context替換關(guān)鍵的對象（如classloader,assertmanager等）咸产，偽造成插件的context锐朴，然后通過偽context也可以獲得插件資源．目前個人驗證的問題為：獲取到的layout資源中的textview顯示文本有問題蔼囊，無法顯示在layout設(shè)定的文本．同時個人猜測這種hack的方式或許有其它的未知的問題畏鼓，但不排除高手已經(jīng)解決了這個問題．

? ? ?３云矫，dex包，這個基本是java開發(fā)中jar包的方式．同樣通過dexclassloader加載到插件中的類挑社，但依舊沒有context,也無法加載到資源．要使用布局痛阻，只能在插件中使用java代碼來寫布局．這種方式最簡單（１阱当，類似jar包的方式糜工，也可以隨意導(dǎo)出單個類的jar包然后轉(zhuǎn)化為dex包，不存在打包成apk需要完整的工程和依賴關(guān)系的要求．２油坝，底層的公用jar包所有插件可以公共一個免钻，傳遞數(shù)據(jù)不用反復(fù)的序列化和反序列化．），也是最復(fù)雜的（布局文件全部代碼寫凤覆，難調(diào)試盯桦，難維護(hù)）．

Android插件化框架有很多

Dynamic-load-apk（阿里）：主要是通過代理來完成Activity,Service的相關(guān)操作 拥峦，不支持Service和BroadcastReceiver略号。

ACDD玄柠、

DroidPlugin（360）：

共享進(jìn)程：為android提供一個進(jìn)程運(yùn)行多個apk的機(jī)制羽利，通過API欺騙機(jī)制瞞過系統(tǒng)

占坑：通過預(yù)先占坑的方式實(shí)現(xiàn)不用在mainfest注冊这弧，通過一帶多的方式實(shí)現(xiàn)服務(wù)管理

Hook機(jī)制：動態(tài)代理實(shí)現(xiàn)函數(shù)hook匾浪，Binder代理繞過部分系統(tǒng)服務(wù)限制户矢，IO重定向（先獲取原始Object–>Read,然后動態(tài)代理Hook Object后–>Write回去殉疼，達(dá)到瞞天過海的目的）

輕量級的插件化框架——small框架瓢娜，VirtualAPK（滴滴）

9眠砾、直播SDK

使用七牛的直播平臺提供的sdk進(jìn)行推流和拉流柒巫，使用環(huán)信IM來作為用戶系統(tǒng)的管理直播聊天室中消息收發(fā)谷丸、發(fā)送禮物、彈幕泉唁、私信等功能

10亭畜、Databinding

DataBinding主要解決了兩個問題：

1、需要多次使用findViewById迎卤，損害了應(yīng)用性能且令人厭煩

2拴鸵、更新UI數(shù)據(jù)需切換至UI線程，將數(shù)據(jù)分解映射到各個view比較麻煩

總體思路

DataBinding解決這些問題的思路非常簡單蜗搔。就是針對每個Activity的布局劲藐，在編譯階段，生成一個ViewDataBinding類的對象碍扔，該對象持有Activity要展示的數(shù)據(jù)和布局中的各個view的引用（這里已經(jīng)解決了令人厭煩的findViewById問題）瘩燥。同時該對象還有如下可喜的功能：

將數(shù)據(jù)分解到各個view

在UI線程上更新數(shù)據(jù)

監(jiān)控數(shù)據(jù)的變化，實(shí)時更新

一不同、對布局文件進(jìn)行預(yù)處理

首先厉膀，DataBinding會對根元素為<layout>的布局文件進(jìn)行預(yù)處理(本例中即activity_main.xml)，

二企软、生成ActivityMainBinding與BR類**

現(xiàn)在仗哨，DataBinding將會依據(jù)上面兩個xml文件（即activtiy_main.xml和activtiy_main-layout.xml）生成兩個類，一個類是ActivityMainBinding苇倡，它繼承自ViewDataBinding晓褪，里面包含如下fields：實(shí)際上，BR中的常量是一種標(biāo)識符变过，它對應(yīng)一個會發(fā)生變化的數(shù)據(jù)，當(dāng)數(shù)據(jù)改變后崭孤，你可以用該標(biāo)識符通知DataBinding，很快嗤形，DataBinding就會用新的數(shù)據(jù)去更新UI。

三霹期、生成ActivityMainBinding實(shí)例并綁定

11、Android馬甲包

馬甲包是指與原APP包除了包名吭产，簽名、包名稱圖標(biāo)等給用戶加以區(qū)分的東西不一樣之外，其他功能基本不變的APP包寺董。

1.簽名文件路徑配置（只有一個簽名文件，不同馬甲包對應(yīng)不同別名就行）

2.主module的build.gradle中一些相關(guān)配置

3.AndroidManifest.xml中的一些相關(guān)配置（${}的使用）

4.獲取MetaData值和getPackageName()獲取包名

5.如何打包（通過命令方式御吞、Tasks、Generate signed APK打包生成多個馬甲包揍诽。）

12狐肢、RXJava原理

基于觀察者模式，事件流將從上往下，從訂閱源傳遞到觀察者。

Rx框架的優(yōu)點(diǎn)可以避免回調(diào)嵌套漆际，更優(yōu)雅地切換線程實(shí)現(xiàn)異步處理數(shù)據(jù)擂找。配合一些操作符塘雳，可以讓處理事件流的代碼更加簡潔，邏輯更加清晰沸呐。

LooperScheduler的代碼很清晰呼渣，內(nèi)部持有一個Handler蓝角，用于線程的切換，利用?subscribeOn()?結(jié)合?observeOn()?來實(shí)現(xiàn)線程控制

RxJava是一種基于觀察者模式的響應(yīng)式編程框架冰沙，其中的主要角色有：

13插龄、RXAndroid

RxAndroid，這是一個擴(kuò)展庫坞琴，更好的兼容了Android特性，比如主線程，UI事件等卫枝。

Android上會有生命周期的問題马篮，可能會導(dǎo)致內(nèi)存泄漏：Observable持有Context導(dǎo)致的內(nèi)存泄露掷匠。在這個問題上顽决，我們的解決方法是這樣的：就是在訂閱的時候厕氨，用一個Subscription來保存它，然后在退出這個Activity的時候取消訂閱。

14贤徒、Bugly功能

1、應(yīng)用升級功能

2、熱更新使用

3潘明、異常上報腌巾、運(yùn)營統(tǒng)計（鵝廠內(nèi)部使用的RDM異常上報）