APP
自2017年初開始，我就致力于Android應(yīng)用框架的研究，到2018年開始在Github上陸續(xù)開源系列作品，再到2019年收獲我的第一個star過千的項目，期間我付出了很多，失去了很多，同時也獲得了很多。
前言
為了能夠讓更多的人了解到我的開源項目，我也是使出了渾身解數(shù)，寫了不少文章和文檔來提高項目的曝光率，不過在這期間我也發(fā)現(xiàn)了不少問題：讀者的水平參差不齊，以往我寫的文章都是建立在有一定開發(fā)基礎(chǔ)之上的，這就導(dǎo)致了很多新手小白、學(xué)生黨看不懂，不會用，瞎折騰，這完全違背了我的初衷。我希望我的開源項目不僅能夠服務(wù)那些有一定開發(fā)經(jīng)驗的人，還能幫助那些熱愛Android的人學(xué)習(xí)并提升自己的開發(fā)水平，早日能夠跟上我們的步伐。
在接下來的數(shù)月里，我將一一詳細(xì)講解我開源的幾個熱門項目，介紹他們所使用的場景，解決的問題以及分析其中實現(xiàn)的邏輯。
概述
所有的技術(shù)框架都必須服務(wù)于實際生產(chǎn)，否則就是耍流氓。
我一直認(rèn)為這世上沒有絕對完美的事物，當(dāng)然技術(shù)也并不例外。在做Android的最初幾年里，我一直認(rèn)為技術(shù)是產(chǎn)品的靈魂，用于創(chuàng)造產(chǎn)品而又高于產(chǎn)品，是無可替代的，這也是我初期為何執(zhí)著于技術(shù)的原因。漸漸地，當(dāng)一項技術(shù)趨于成熟的時候，你會發(fā)現(xiàn)其實技術(shù)也并不是想象中的那么重要，同樣的功能或是產(chǎn)品，你可以用2種或者更多的技術(shù)方案來實現(xiàn)，這個時候你才會發(fā)現(xiàn)，原來技術(shù)也如同資本、人力、市場和物料等資源，只是我們實現(xiàn)目的的工具而已。
其實X-Library正是我早期做Android開發(fā)過程中積累沉淀下來的技術(shù)經(jīng)驗，并通過我后期不斷完善之后形成的。雖說可能不及大廠和google爸爸他們開源的項目那么牛掰，不過相信我，這些框架都是在實際生產(chǎn)中誕生出來的優(yōu)秀項目，相比大廠和google爸爸他們開源的項目，他們可能更適合中小企業(yè)或者獨立開發(fā)者的你使用哦！
下面是X-Library的思維導(dǎo)圖：
Library簡介
XPage
一個非常方便的fragment頁面框架
XPage是我開源的第一個項目，也是最實用、最方便的項目之一。設(shè)計的初衷是希望能做一個通用的Activity作為殼，F(xiàn)ragment作為頁面填充展示，并且能夠?qū)崿F(xiàn)自由的切換和數(shù)據(jù)交互。
設(shè)計原由
當(dāng)初做Android開發(fā)時每當(dāng)我寫一個頁面，都需要創(chuàng)建一個Activity，并且還需要在manifest中注冊一堆Activity信息，這樣既不方便，而且對資源的開銷也比較大。因此當(dāng)時我就設(shè)想能否創(chuàng)造出一個通用萬能的Activity容器，可以全權(quán)負(fù)責(zé)Fragment的切換展示和數(shù)據(jù)交互，只需要一行代碼即可完成所有的操作，還不需要自己手動去注冊，可以一鍵生成。
設(shè)計思路
剛開始的時候真的很難，沒有什么好的思路，最初只是簡單封裝了一個Activity，通過傳入一些key值從而獲取并加載對應(yīng)的fragment，類似ARouter中Fragment發(fā)現(xiàn)那種。其實這樣做并沒有解決一個容器的問題，而且頁面切換也不是很靈活，不夠通用，使用起來也不是很方便。
突然有一天我發(fā)現(xiàn)Github上有個開源項目CorePage寫得非常好，完美地解決了我對一個Activity容器的問題，于是我決定仔細(xì)研究其代碼，并在其基礎(chǔ)上設(shè)計出了XPage的最初版本。
就在XPage正式投入使用的過程中，我發(fā)現(xiàn)還是存在不少問題的：
-
1.對外API不夠靈活，使用起來不夠方便；
-
2.每個Fragment仍需要手動注冊，很麻煩；
對于API不夠靈活的問題，我在之后的版本中陸續(xù)通過構(gòu)造者模式設(shè)計以及Android主題屬性等手段解決了。
而對于手動注冊的問題，我正是借鑒了ARouter的思路，通過Android APT技術(shù)，從而實現(xiàn)了Fragment信息的自動注冊。
解決痛點
-
只需要一個Activity容器就可以實現(xiàn)多個頁面的交互。
-
Fragment自由切換和數(shù)據(jù)交互。
-
無需在manifest中注冊一堆Activity信息，通過@Page注解一鍵自動注冊。
項目地址
https://github.com/xuexiangjys/XPage
XAOP
一個輕量級的AOP(Android)應(yīng)用框架。囊括了最實用的AOP應(yīng)用。
XAOP是我剛接觸到AOP(面向切片編程)思想后，靈光乍現(xiàn)編寫的應(yīng)用庫，應(yīng)該說是我使用得最多的庫了，因為有了它，編碼真的很方便！
設(shè)計原由
在我們平時開發(fā)的過程中，一定會遇到權(quán)限申請、線程切換、數(shù)據(jù)緩存、異常捕獲、埋點和方法執(zhí)行時間統(tǒng)計等問題。這些都是非常常見的問題，實現(xiàn)起來也不是很難，不過就是太麻煩了，還會讓程序多出很多重復(fù)性、模版化的代碼。
設(shè)計思路
讓我最初接觸到AOP思想的是JakeWharton的hugo,通過閱讀它的源碼之后，讓我對aspectj這項技術(shù)的動態(tài)代碼編織深深地著了迷。之后我詳細(xì)研究了aspectj相關(guān)的技術(shù)，并不斷搜集AOP在Android上的典型應(yīng)用場景，然后通過aspectj這項技術(shù)去逐一實現(xiàn)。最后就成就了XAOP這個庫。
解決痛點
- 可以解決快速點擊的問題
- 解決Android6.0以上動態(tài)權(quán)限申請的問題
- 線程自由切換的問題
- 日志埋點問題
- 緩存問題（磁盤緩存和內(nèi)存緩存）
- 異常捕獲處理
- 業(yè)務(wù)攔截（登陸驗證、有效性驗證等）
項目地址
https://github.com/xuexiangjys/XAOP
XUI
一個簡潔而又優(yōu)雅的Android原生UI框架，解放你的雙手！
XUI可以說是我花費(fèi)心血最多的開源項目了，目前稍微大一點的項目我都會選擇引入它。XUI幾乎涵蓋了目前Android開發(fā)所需要的所有組件，可以說有了XUI之后，可以大大提高我們的開發(fā)效率，讓我們可以將精力很多地放在業(yè)務(wù)功能和數(shù)據(jù)處理上?？梢哉fXUI是目前Github上組件最全、文檔最詳細(xì)、案例最多的Android原生UI庫。
設(shè)計原由
相信做過Android的人都知道Android原生組件在國內(nèi)很不受設(shè)計師的待見，至于Google推行的Material Design設(shè)計風(fēng)格更是無人問津，這就導(dǎo)致了設(shè)計師給出的原型圖幾乎是清一色的IOS風(fēng)格，更尷尬的是，網(wǎng)上Android相關(guān)的開源UI庫是少之又少，這可就為難死我們了，幾乎所有的基礎(chǔ)組件都需要自己重寫。之前也寫過React和Vue，發(fā)現(xiàn)它們都有非常方便的UI庫，而且使用起來也非常方便，直接在示例代碼的基礎(chǔ)上修修改改就能大致上實現(xiàn)自己想要的效果，極大地提高了開發(fā)的效率。
設(shè)計思路
在開始著手做這樣一個開源庫之前，我是一點思路都沒有的。好在在2017年的某一天，我接觸到了QMUI,通過閱讀它的源碼，我發(fā)現(xiàn)它的設(shè)計思路非常好，可以通過設(shè)置不同的主題樣式、組件屬性等實現(xiàn)不同的組件效果，非常靈活；除此之外，它還對UI主題風(fēng)格做了較為詳細(xì)的制定和歸類，可以說很有啟發(fā)意義。于是我就遵循了QMUI的思路，開啟了XUI的編寫。
解決痛點
- 簡潔優(yōu)雅，盡可能少得引用資源文件的數(shù)量，項目庫整體大小不足1M。
- 組件豐富，提供了絕大多數(shù)我們在開發(fā)者常用的功能組件。
- 使用簡單，為方便快速開發(fā)，提高開發(fā)效率，對api進(jìn)行了優(yōu)化，提供一鍵式接入。
- 樣式統(tǒng)一，框架提供了一系列統(tǒng)一的樣式，使UI整體看上去美觀和諧。
- 兼容性高，框架還提供了3種不同尺寸設(shè)備的樣式（4.5英寸、7英寸和10英寸），并且最低兼容到Android 17, 讓UI兼容性更強(qiáng)。
- 擴(kuò)展性強(qiáng)，各組件提供了豐富的屬性和樣式API，可以通過設(shè)置不同的樣式屬性，構(gòu)建不同風(fēng)格的UI。
項目地址
https://github.com/xuexiangjys/XUI
XUpdate
一個輕量級、高可用性的Android全量版本更新框架。
XUpdate是為了解決在不同項目組、不同平臺之間進(jìn)行統(tǒng)一的Android全量版本更新的庫。它具有輕量、靈活、低耦合、高可用等特點，可以很方便地定制屬于自己的版本更新。
設(shè)計原由
在沒有XUpdate之前的版本更新，Android版本更新基本都是靠寫各種版本更新工具類來實現(xiàn)版本更新，更可怕的是有時在不同項目組或者平臺之間，它們的版本更新完全是不一樣的，這樣的結(jié)果就是會寫無數(shù)的版本更新工具類，并且每次更換一個項目組或者平臺就需要從頭重寫再寫一遍，非常得麻煩。當(dāng)時我就在想，版本更新作為一個Android應(yīng)用基本都有，且內(nèi)容相對穩(wěn)定的功能，有沒有可能設(shè)計出一個通用的、不為業(yè)務(wù)或者平臺所影響的基礎(chǔ)庫呢？
設(shè)計思路
在著手寫XUpdate之前，我特地去Github上搜了一圈有關(guān)Android版本更新的內(nèi)容，發(fā)現(xiàn)AppUpdate這個項目star數(shù)量最多。但是當(dāng)我翻閱它的源碼之后發(fā)現(xiàn)，它設(shè)計得并不優(yōu)美，內(nèi)部耦合非常嚴(yán)重，不過優(yōu)點就是Android版本更新的功能基本都涵蓋了。于是我就照著它所擁有的功能，結(jié)合了我對版本更新的理解進(jìn)行了重新設(shè)計，感興趣的可點擊查看框架UML設(shè)計圖。
解決痛點
- 使用簡單，只需一行代碼即可完成版本更新功能。
- 功能強(qiáng)大，兼容Android6.0、7.0、8.0，支持靜默更新和自動更新，支持國際化。
- 擴(kuò)展性強(qiáng)，可自定義請求API接口、提示彈窗、下載服務(wù)、文件加密器等。
- 搭建簡單，只需提供json內(nèi)容即可支持版本更新。
- 配套齊全，默認(rèn)提供了后臺服務(wù)和管理界面。
項目地址
- Android基礎(chǔ)庫: https://github.com/xuexiangjys/XUpdate
- 版本更新后臺服務(wù): https://github.com/xuexiangjys/XUpdateService
- 版本更新管理系統(tǒng): https://github.com/xuexiangjys/xupdate-management
XHttp2
一個功能強(qiáng)悍的網(wǎng)絡(luò)請求庫，使用RxJava2 + Retrofit2 + OKHttp組合進(jìn)行封裝。
XHttp2的出現(xiàn)主要是為了解決網(wǎng)絡(luò)請求前后端統(tǒng)一、靈活性、易用性和可拓展性等問題。它提供了豐富的API調(diào)用和功能，可以靈活地設(shè)置請求參數(shù)、攔截器、緩存策略，動態(tài)添加參數(shù)、異常攔截捕獲、自定義請求等。
設(shè)計原由
在沒有設(shè)計XHttp2之前，網(wǎng)絡(luò)請求我用過async-http、Volley、okhttp等網(wǎng)絡(luò)請求，普遍的做法就是寫一個網(wǎng)絡(luò)請求的工具類，提供幾種常用的請求方法進(jìn)行調(diào)用，這樣做確實可以，但是也存在很多問題：
-
靈活性差。請求參數(shù)一般都是固定的，不可以靈活地設(shè)置，每次有新的請求方式都需要增加更多的方法。
-
易用性差。每次請求可能都需要構(gòu)建一個請求實體，并且不同的請求需要調(diào)用不同的方法，傳入不同的參數(shù)，往往一個請求需要寫很多重復(fù)的代碼。
-
耦合度高。如果需要切換一種請求方式的話，需要修改所有工具類調(diào)用相關(guān)的代碼，非常麻煩。
-
請求的行為不好控制。例如請求策略的控制、請求線程的控制、緩存策略的控制、請求響應(yīng)以及異常處理的控制等。
-
可拓展性差。無法自定義請求的形式，很難對請求進(jìn)行統(tǒng)一和有效的管理，不利于解決前后端統(tǒng)一的問題。
但是自從有了Retrofit之后，以上的問題都得到了很好的解決?？梢哉fRetrofit真的是一個不錯的網(wǎng)絡(luò)請求框架，很好地體現(xiàn)了設(shè)計模式的優(yōu)美。當(dāng)然，Retrofit也有自己的問題：
-
Retrofit定義的接口返回類型不支持二次泛型。
-
Retrofit雖具備高度的靈活性，但卻缺乏易用性，無法對請求進(jìn)行統(tǒng)一的管理，所以使用起來不是那么方便。
-
Retrofit的擴(kuò)展性不強(qiáng)。不支持自定義請求形式，只能在其提供的框架內(nèi)進(jìn)行網(wǎng)絡(luò)請求。
設(shè)計思路
XHttp2最初的設(shè)計思路來源于RxEasyHttp 和axios。綜合使用了原型模式、構(gòu)建者模式、代理模式、策略模式、模板模式、裝飾模式、外觀模式、中介者模式、責(zé)任鏈模式和觀察者模式，并且嚴(yán)格遵循Java設(shè)計模式的七大設(shè)計原則進(jìn)行了嚴(yán)格地設(shè)計。想了解更多設(shè)計細(xì)節(jié)的點擊查看XHttp2的設(shè)計類圖。
解決痛點
- 提供了一整套統(tǒng)一的請求形式、攔截器、緩存、線程控制、請求響應(yīng)、異常處理的解決方案。
- 解決網(wǎng)絡(luò)請求前后端統(tǒng)一的問題。
- 解決Retrofit易用性差的問題。
- 解決網(wǎng)絡(luò)請求靈活性、易用性和可拓展性等問題。
項目地址
https://github.com/xuexiangjys/XHttp2
XPush
一個輕量級、可插拔的Android消息推送框架。一鍵集成推送（極光推送、友盟推送、信鴿推送、華為、小米推送等），提供有效的?；顧C(jī)制，支持推送的拓展，充分解耦推送和業(yè)務(wù)邏輯，解放你的雙手！
XPush是對Android各大消息推送平臺錯綜復(fù)雜的API進(jìn)行統(tǒng)一的整合和管理，提供一致性的入口和出口，簡化消息推送的集成和使用。
設(shè)計原由
做過Android消息推送的人都知道，Android不僅設(shè)備碎片化嚴(yán)重，推送平臺也是五花八門的。早在2017年工信部就號召所有的廠商來制定統(tǒng)一的Android消息推送平臺，可到現(xiàn)在也沒有下文（究其原因還是這其中的利益太大了，誰也不想妥協(xié)）。我們不能將希望全都寄托在這個完全沒有定數(shù)的事件上，代碼終歸要寫，功能終歸要上，與其受制于人，不如自己革命，搞一個自己能控制的消息推送全平臺解決方案來得靠譜。
設(shè)計思路
雖然目前市面上各家提供的消息推送服務(wù)都各不相同，但仔細(xì)研究了之后就會發(fā)現(xiàn)它們其中是有很多共性的地方。其實我們完全可以提取一下公因數(shù)，將他們共性的地方提取出來并建立統(tǒng)一的管理，這樣就可以非常方便地接入和切換各大消息推送平臺了。這樣帶來的好處就是，無論后臺推送平臺或者方式如何變化，我們都不需要修改業(yè)務(wù)代碼，只需要簡單切換一下推送客戶端的實現(xiàn)方式就行了，做到消息推送和業(yè)務(wù)代碼的隔離。
解決痛點
- 弱化了Android各大消息推送平臺的差異。
- 簡化了Android各大消息推送平臺的集成和使用。
- 提供了一致性的消息推送入口和出口。
- 支持推送消息的過濾處理。
項目地址
https://github.com/xuexiangjys/XPush
XQRCode
一個非常方便實用的二維碼掃描、解析、生成庫
XQRCode作為一個二維碼掃描的應(yīng)用庫，是基于zxing的識別功能實現(xiàn)的。它的設(shè)計目標(biāo)就是方便、好用以及易拓展。
設(shè)計原由
二維碼掃描功能在App中可以說是一個非常常見的功能了，而且在網(wǎng)上也有很多相關(guān)的開源庫，那我為何還要自己重復(fù)造輪子呢？其實最初我使用的也是別人的開源庫：android-zxingLibrary.使用起來很方便，但問題也很多。還是那句話，易用性和靈活性不能很好地共存。雖然使用起來非常方便，但是默認(rèn)提供的掃描界面效果并不是很理想，而且想自定義掃描界面非常地麻煩，很多掃描參數(shù)都無法自定義設(shè)置，不支持多次掃描，代碼的耦合性非常高。
設(shè)計思路
通過提供兩種自定義的方式：1.組件屬性自定義（自定義Fragment） 2.主題樣式自定義（自定義Activity） 這兩種方式以解決界面UI自定義難的問題。同時為一些重要的參數(shù)提供可設(shè)置的API。
解決痛點
- 二維碼掃描界面自定義難的問題。
- 二維碼多次掃描的問題。
- 二維碼生成和解析的問題。
項目地址
https://github.com/xuexiangjys/XQRCode
XLog
一個簡易的日志打印框架（支持打印策略自定義，默認(rèn)提供2種策略：logcat打印和磁盤打?。?/p>
XLog是一個非常方便易用的日志打印框架，主要提供日志打印輸出的能力?？梢造`活地控制日志打印的樣式和策略。
設(shè)計原由
在沒有XLog之前做日志打印的時候，基本都是基于工具類進(jìn)行打印的，這就出現(xiàn)了一個比較嚴(yán)重的問題：定制化的問題。因為不同等級的日志需要打印的內(nèi)容是不一樣的，而且不同業(yè)務(wù)下打印的日志信息內(nèi)容也是不一樣的。例如：崩潰日志需要將盡可能的信息都記錄下來，單獨存成一個文件；一般性的錯誤日志需要將堆棧信息打印出來；關(guān)鍵點的日志需要將入?yún)?、出參、耗時以及所處線程等信息都打印出來；一般性的埋點信息可能只需要打印極少的內(nèi)容…
當(dāng)日志打印出現(xiàn)如上需求的時候，想只通過簡簡單單的工具類來實現(xiàn)日志打印就顯得非常蹩腳了。
設(shè)計思路
為了解決定制化的問題，這里我借鑒了logger的設(shè)計思想，將日志打印拆分為兩個部分：日志格式策略和打印策略。日志格式策略主要負(fù)責(zé)日志輸出信息和樣式的處理，而打印策略主要負(fù)責(zé)日志輸出打印。
除此之外，為了能夠?qū)Ξ惓１罎⑦M(jìn)行定制化處理，我還專門設(shè)計了一套崩潰處理的定制化方案，支持崩潰信息展示、郵件發(fā)送等形式。
解決痛點
- 解決日志定制化的問題。支持自定義日志格式策略IFormatStrategy和打印策略ILogStrategy。
- 支持自定義日志文件存儲形式（文件前綴、時間片存儲等）。
- 支持自定義崩潰日志處理【默認(rèn)提供了3種處理方式】。
- 支持第三方打印接口的適配。
項目地址
https://github.com/xuexiangjys/XLog
XRouter
一個輕量級的Android路由框架，基于ARouter上進(jìn)行改良，優(yōu)化Fragment的使用，可結(jié)合XPage使用。
XRouter是我在仔細(xì)研讀ARouter框架的源碼之后，結(jié)合我使用XPage過程中遇到的問題，而進(jìn)行重新改寫的一個框架，一般是配合XPage使用。
設(shè)計原由
在我使用ARouter的時候，我發(fā)現(xiàn)它對Fragment的支持并不是很友好。說到底它主要還是為Activity路由服務(wù)的。而在我的XPage中Activity類非常少，因此使用起來極為不方便，不過ARouter的依賴注入設(shè)計得還是挺好的，因此改進(jìn)它對Fragment的支持就顯得尤為重要。
解決痛點
- 讓ARouter對Fragment的支持更加友好。
- 配合XPage使用。
項目地址
https://github.com/xuexiangjys/XRouter
XOrmlite
一個方便實用的OrmLite數(shù)據(jù)庫框架，支持一鍵集成。
XOrmlite是我在接觸了APT（編譯時注解處理）技術(shù)后，在數(shù)據(jù)庫框架構(gòu)建上的一項應(yīng)用。通過它，你可以一鍵集成ormlite數(shù)據(jù)庫框架，非常得方便。
設(shè)計原由
做Android都必定會和SQLite打交道，無奈在Google還沒有提供Room數(shù)據(jù)庫框架的時候，真的是要被SQLite折騰廢了，好在后來有了ormlite數(shù)據(jù)庫框架。
在使用了ormlite一段時間后，我發(fā)現(xiàn)應(yīng)用使用的數(shù)據(jù)庫不一定都是內(nèi)存數(shù)據(jù)庫，可能還需要讀取操作外部存儲的數(shù)據(jù)庫，于是我又對其做了一定的封裝，讓其同時支持內(nèi)部數(shù)據(jù)庫和外部存儲數(shù)據(jù)庫，同時增加了數(shù)據(jù)庫連接池的功能。
但就是這樣，在使用的過程中我仍然發(fā)現(xiàn)庫在項目間的移植非常麻煩,每次引入都需要創(chuàng)建幾個幾乎完全類似的類，而應(yīng)對的通常做法就是復(fù)制粘貼，有時有的地方不修改就可能導(dǎo)致出錯，總之還是比較麻煩的。同時，在數(shù)據(jù)庫第一次打開的時候，我們還需要根據(jù)數(shù)據(jù)庫類去創(chuàng)建對應(yīng)的數(shù)據(jù)庫表，有的時候漏了個沒發(fā)現(xiàn)，結(jié)果就有可能出現(xiàn)排查了一下午問題最后發(fā)現(xiàn)是漏寫了一個類的尷尬。因此需要使用APT技術(shù)，在程序編譯時自動幫我們生成那幾個我們每次都需要創(chuàng)建的類以及收集我們所有使用到的數(shù)據(jù)庫實體類信息，這樣就可以大大減少錯誤的發(fā)生，降低了庫的引入難度。
設(shè)計思路
XOrmlite的設(shè)計思路很簡單，就是基于享元模式做了一個數(shù)據(jù)庫連接池，然后對Ormlite數(shù)據(jù)庫進(jìn)行了二次封裝，然后通過APT技術(shù)分別生成數(shù)據(jù)庫框架構(gòu)建所需要的連接池和實現(xiàn)接口，并自動收集項目中所使用到的所有數(shù)據(jù)庫實體信息類用于數(shù)據(jù)庫表的初始創(chuàng)建。
解決痛點
- 支持自動生成數(shù)據(jù)庫管理倉庫DataBaseRepository和自動搜索所有的數(shù)據(jù)庫表類，并自動創(chuàng)建數(shù)據(jù)庫表，簡化了數(shù)據(jù)庫框架的引入。
- 支持內(nèi)部存儲和外部存儲兩種數(shù)據(jù)庫，支持自定義數(shù)據(jù)庫存儲位置。
- 提供了常用的數(shù)據(jù)庫操作API，簡化了數(shù)據(jù)庫的使用。
項目地址
https://github.com/xuexiangjys/XOrmlite
XTCP
一個便捷的TCP消息包拼裝和解析框架
XTCP是一套能夠自動進(jìn)行TCP消息包拼包、拆包和解析的框架，類似于Google的protobuf.
設(shè)計原由
相信做過Android嵌入式開發(fā)或者智能硬件的人都知道，設(shè)備間的通訊基本都是基于自定義TCP協(xié)議來實現(xiàn)的。Http協(xié)議其實也是TCP協(xié)議的一種，但由于它攜帶的附帶信息過多，效率并不高，因此在做嵌入式開發(fā)的時候一般的做法都是自定義TCP協(xié)議來實現(xiàn)通訊。但是自定義協(xié)議這就需要牽涉到組包和拆包的工作。如果協(xié)議少的話，手動拆解包還是可行的。但是如果當(dāng)協(xié)議的數(shù)量達(dá)到百來條以上的話，這個時候再進(jìn)行手動拆解包的話就相當(dāng)累了，而且如果協(xié)議發(fā)生變化的話，改起來不但非常痛苦，而且也容易出錯，代碼的可讀性和可維護(hù)性都比較差。
設(shè)計思路
通過APT（編譯時注解處理）技術(shù)，對標(biāo)注了@Protocol和@ProtocolField類進(jìn)行自動統(tǒng)計和建立映射關(guān)系，解析時借鑒了Gson的思路，采用注解反射和遞歸的方式進(jìn)行拼包和解析。
解決痛點
- 簡單通過@Protocol和@ProtocolField的配置，即可讓實體對象擁有自動轉(zhuǎn)化為TCP傳輸?shù)腷yte數(shù)據(jù)和自動byte數(shù)據(jù)解析。
- 支持byte、short、int、long、byte[]、short[]、int[]、long[]、String等常用基礎(chǔ)類型，支持類型的拓展。
- 支持無符號數(shù)和有符號數(shù)兩種。
- 支持BCD編碼格式【時間、int、float、double等】。
- 支持大端和小端兩種存儲方式，支持設(shè)置全局默認(rèn)存儲方式和局部存儲方式。
- 支持short、int、long讀取長度的自定義。
- 支持對實體字段進(jìn)行排序，避免解析錯亂。
- 支持自定義協(xié)議項和協(xié)議解析器。
- 支持對不定長數(shù)組解析【需要注意的是，在一條協(xié)議中有且只能有一個不定長的數(shù)組，否則將無法解析成功】。
- 支持自動協(xié)議映射，自動根據(jù)讀取的opcode識別出對應(yīng)的協(xié)議并進(jìn)行解析，并根據(jù)對應(yīng)注冊的協(xié)議信息判斷協(xié)議是否有響應(yīng)。
項目地址
https://github.com/xuexiangjys/XTCP
XUtil
一個方便實用的Android工具類庫
XUtil主要是我平時在開發(fā)過程中對一些實用工具類的整理。除此之外還包括一些常用的代碼混淆配置和Android Gradle腳本。
項目地址
https://github.com/xuexiangjys/XUtil
RxUtil2
一個實用的RxJava2工具類庫
RxUtil2主要包含了RxJava2常用操作符的相關(guān)應(yīng)用。
解決痛點
- RxBus 支持多事件定義，支持?jǐn)?shù)據(jù)攜帶，支持全局和局部的事件訂閱和注銷。
- 提供統(tǒng)一的訂閱池管理。
- 支持非侵入式的訂閱生命周期綁定。
- 提供簡易的線程調(diào)度輔助工具。
- RxBinding 和 RxJava 常用操作符使用工具。
項目地址
https://github.com/xuexiangjys/RxUtil2
XIPC
一個Android通用的IPC(進(jìn)程通信)框架。該項目主要是模仿餓了么開源項目Hermes的設(shè)計進(jìn)行的自我理解改寫。
XIPC是一套非常方便的IPC(進(jìn)程通信)框架。它可以將進(jìn)程間通信的蹩腳方式（寫AIDL接口）簡化為像調(diào)用本地服務(wù)一樣方便。當(dāng)初也是因為想摸清Hermes的實現(xiàn)原理，于是從0開始跟著源碼自己手?jǐn)]了一個。
設(shè)計原由
其實Android進(jìn)程間通訊的方式有很多種，例如：Bundle、AIDL、Socket、ContentProvider等，其中因AIDL方式提供的功能更強(qiáng)大，且支持實時通訊，因此成為很多人進(jìn)行進(jìn)程通訊的方式。但問題就是，使用AIDL方式來實現(xiàn)進(jìn)程通訊較為復(fù)雜，且需要處理好線程同步等問題，使用起來不是很方便。如果進(jìn)程通訊使用的場景不多的話，姑且使用AIDL的方式還算湊合，但如果使用的地方非常多的話，那就非常麻煩了，因為可能需要定義一堆接口和服務(wù)，那用起來是真的很麻煩了。
設(shè)計思路
XIPC主要借鑒了Retrofit的設(shè)計思路，采用動態(tài)代理、注解反射、AIDL、服務(wù)綁定和進(jìn)程間垃圾回收等技術(shù)實現(xiàn)。詳細(xì)實現(xiàn)原理請點擊查看.
解決痛點
- 支持自定義服務(wù)接口實現(xiàn)進(jìn)程通信，無需定義AIDL接口，所有IPC通信就像調(diào)用本地函數(shù)一樣簡單。
- 支持自定義接口服務(wù)（服務(wù)發(fā)現(xiàn)）、獲取單例和獲取工具類方法。
- 支持進(jìn)程通信的接口回調(diào)。
- 支持接口回調(diào)的線程控制。
- 擁有垃圾回收機(jī)制，防止接口回調(diào)內(nèi)存泄漏。
- 支持跨進(jìn)程和跨應(yīng)用通信。
項目地址
https://github.com/xuexiangjys/XIPC
XVideo
一個能自動進(jìn)行壓縮的小視頻錄制庫
XVideo主要采用FFmpeg技術(shù)實現(xiàn)視頻錄制。主要解決使用系統(tǒng)API視頻錄制文件過大的問題，支持在視頻錄制的過程中自動進(jìn)行視頻壓縮。
解決痛點
- 支持自定義小視頻錄制時的視頻質(zhì)量。
- 支持自定義視頻錄制的界面。
- 支持自定義最大錄制時長和最小錄制時長。
- 支持自定義屬性的視頻壓縮。
項目地址
https://github.com/xuexiangjys/XVideo
XFloatView
一個簡易的懸浮窗實現(xiàn)方案
解決痛點
- 支持自定義布局的懸浮窗。
- 支持自定義拖動事件、點擊事件。
- 支持懸浮窗自動吸附效果。
- 支持初始化懸浮窗的位置。
- 支持懸浮窗翻轉(zhuǎn)吸附。
- 支持各手機(jī)廠商Rom的懸浮窗權(quán)限申請。
項目地址
https://github.com/xuexiangjys/XFloatView
微信公眾號
?
本文摘自 ：https://blog.51cto.com/u
