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