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