當前位置：首頁 > IT技術(shù) > 移動平臺 > 正文

X-Library系列Android應用框架詳解
2021-09-09 13:53:01

自2017年初開始，我就致力于Android應用框架的研究，到2018年開始在Github上陸續(xù)開源系列作品，再到2019年收獲我的第一個star過千的項目，期間我付出了很多，失去了很多，同時也獲得了很多。

前言

為了能夠讓更多的人了解到我的開源項目，我也是使出了渾身解數(shù)，寫了不少文章和文檔來提高項目的曝光率，不過在這期間我也發(fā)現(xiàn)了不少問題：讀者的水平參差不齊，以往我寫的文章都是建立在有一定開發(fā)基礎之上的，這就導致了很多新手小白、學生黨看不懂，不會用，瞎折騰，這完全違背了我的初衷。我希望我的開源項目不僅能夠服務那些有一定開發(fā)經(jīng)驗的人，還能幫助那些熱愛Android的人學習并提升自己的開發(fā)水平，早日能夠跟上我們的步伐。

在接下來的數(shù)月里，我將一一詳細講解我開源的幾個熱門項目，介紹他們所使用的場景，解決的問題以及分析其中實現(xiàn)的邏輯。

概述

所有的技術(shù)框架都必須服務于實際生產(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的思維導圖：

X-Library系列Android應用框架詳解_library

Library簡介

XPage

一個非常方便的fragment頁面框架

XPage是我開源的第一個項目，也是最實用、最方便的項目之一。設計的初衷是希望能做一個通用的Activity作為殼，F(xiàn)ragment作為頁面填充展示，并且能夠?qū)崿F(xiàn)自由的切換和數(shù)據(jù)交互。

設計原由

當初做Android開發(fā)時每當我寫一個頁面，都需要創(chuàng)建一個Activity，并且還需要在manifest中注冊一堆Activity信息，這樣既不方便，而且對資源的開銷也比較大。因此當時我就設想能否創(chuàng)造出一個通用萬能的Activity容器，可以全權(quán)負責Fragment的切換展示和數(shù)據(jù)交互，只需要一行代碼即可完成所有的操作，還不需要自己手動去注冊，可以一鍵生成。

設計思路

剛開始的時候真的很難，沒有什么好的思路，最初只是簡單封裝了一個Activity，通過傳入一些key值從而獲取并加載對應的fragment，類似ARouter中Fragment發(fā)現(xiàn)那種。其實這樣做并沒有解決一個容器的問題，而且頁面切換也不是很靈活，不夠通用，使用起來也不是很方便。

突然有一天我發(fā)現(xiàn)Github上有個開源項目CorePage寫得非常好，完美地解決了我對一個Activity容器的問題，于是我決定仔細研究其代碼，并在其基礎上設計出了XPage的最初版本。

就在XPage正式投入使用的過程中，我發(fā)現(xiàn)還是存在不少問題的：

  • 1.對外API不夠靈活，使用起來不夠方便；

  • 2.每個Fragment仍需要手動注冊，很麻煩；

對于API不夠靈活的問題，我在之后的版本中陸續(xù)通過構(gòu)造者模式設計以及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)應用框架。囊括了最實用的AOP應用。

XAOP是我剛接觸到AOP(面向切片編程)思想后，靈光乍現(xiàn)編寫的應用庫，應該說是我使用得最多的庫了，因為有了它，編碼真的很方便！

設計原由

在我們平時開發(fā)的過程中，一定會遇到權(quán)限申請、線程切換、數(shù)據(jù)緩存、異常捕獲、埋點和方法執(zhí)行時間統(tǒng)計等問題。這些都是非常常見的問題，實現(xiàn)起來也不是很難，不過就是太麻煩了，還會讓程序多出很多重復性、模版化的代碼。

設計思路

讓我最初接觸到AOP思想的是JakeWharton的hugo,通過閱讀它的源碼之后，讓我對aspectj這項技術(shù)的動態(tài)代碼編織深深地著了迷。之后我詳細研究了aspectj相關(guān)的技術(shù)，并不斷搜集AOP在Android上的典型應用場景，然后通過aspectj這項技術(shù)去逐一實現(xiàn)。最后就成就了XAOP這個庫。

解決痛點

  • 可以解決快速點擊的問題
  • 解決Android6.0以上動態(tài)權(quán)限申請的問題
  • 線程自由切換的問題
  • 日志埋點問題
  • 緩存問題（磁盤緩存和內(nèi)存緩存）
  • 異常捕獲處理
  • 業(yè)務攔截（登陸驗證、有效性驗證等）

項目地址

https://github.com/xuexiangjys/XAOP

XUI

一個簡潔而又優(yōu)雅的Android原生UI框架，解放你的雙手！

XUI可以說是我花費心血最多的開源項目了，目前稍微大一點的項目我都會選擇引入它。XUI幾乎涵蓋了目前Android開發(fā)所需要的所有組件，可以說有了XUI之后，可以大大提高我們的開發(fā)效率，讓我們可以將精力很多地放在業(yè)務功能和數(shù)據(jù)處理上?？梢哉fXUI是目前Github上組件最全、文檔最詳細、案例最多的Android原生UI庫。

設計原由

相信做過Android的人都知道Android原生組件在國內(nèi)很不受設計師的待見，至于Google推行的Material Design設計風格更是無人問津，這就導致了設計師給出的原型圖幾乎是清一色的IOS風格，更尷尬的是，網(wǎng)上Android相關(guān)的開源UI庫是少之又少，這可就為難死我們了，幾乎所有的基礎組件都需要自己重寫。之前也寫過React和Vue，發(fā)現(xiàn)它們都有非常方便的UI庫，而且使用起來也非常方便，直接在示例代碼的基礎上修修改改就能大致上實現(xiàn)自己想要的效果，極大地提高了開發(fā)的效率。

設計思路

在開始著手做這樣一個開源庫之前，我是一點思路都沒有的。好在在2017年的某一天，我接觸到了QMUI,通過閱讀它的源碼，我發(fā)現(xiàn)它的設計思路非常好，可以通過設置不同的主題樣式、組件屬性等實現(xiàn)不同的組件效果，非常靈活；除此之外，它還對UI主題風格做了較為詳細的制定和歸類，可以說很有啟發(fā)意義。于是我就遵循了QMUI的思路，開啟了XUI的編寫。

解決痛點

  • 簡潔優(yōu)雅，盡可能少得引用資源文件的數(shù)量，項目庫整體大小不足1M。
  • 組件豐富，提供了絕大多數(shù)我們在開發(fā)者常用的功能組件。
  • 使用簡單，為方便快速開發(fā)，提高開發(fā)效率，對api進行了優(yōu)化，提供一鍵式接入。
  • 樣式統(tǒng)一，框架提供了一系列統(tǒng)一的樣式，使UI整體看上去美觀和諧。
  • 兼容性高，框架還提供了3種不同尺寸設備的樣式（4.5英寸、7英寸和10英寸），并且最低兼容到Android 17, 讓UI兼容性更強。
  • 擴展性強，各組件提供了豐富的屬性和樣式API，可以通過設置不同的樣式屬性，構(gòu)建不同風格的UI。

項目地址

https://github.com/xuexiangjys/XUI

XUpdate

一個輕量級、高可用性的Android全量版本更新框架。

XUpdate是為了解決在不同項目組、不同平臺之間進行統(tǒng)一的Android全量版本更新的庫。它具有輕量、靈活、低耦合、高可用等特點，可以很方便地定制屬于自己的版本更新。

設計原由

在沒有XUpdate之前的版本更新，Android版本更新基本都是靠寫各種版本更新工具類來實現(xiàn)版本更新，更可怕的是有時在不同項目組或者平臺之間，它們的版本更新完全是不一樣的，這樣的結(jié)果就是會寫無數(shù)的版本更新工具類，并且每次更換一個項目組或者平臺就需要從頭重寫再寫一遍，非常得麻煩。當時我就在想，版本更新作為一個Android應用基本都有，且內(nèi)容相對穩(wěn)定的功能，有沒有可能設計出一個通用的、不為業(yè)務或者平臺所影響的基礎庫呢？

設計思路

在著手寫XUpdate之前，我特地去Github上搜了一圈有關(guān)Android版本更新的內(nèi)容，發(fā)現(xiàn)AppUpdate這個項目star數(shù)量最多。但是當我翻閱它的源碼之后發(fā)現(xiàn)，它設計得并不優(yōu)美，內(nèi)部耦合非常嚴重，不過優(yōu)點就是Android版本更新的功能基本都涵蓋了。于是我就照著它所擁有的功能，結(jié)合了我對版本更新的理解進行了重新設計，感興趣的可點擊查看框架UML設計圖。

解決痛點

  • 使用簡單，只需一行代碼即可完成版本更新功能。
  • 功能強大，兼容Android6.0、7.0、8.0，支持靜默更新和自動更新，支持國際化。
  • 擴展性強，可自定義請求API接口、提示彈窗、下載服務、文件加密器等。
  • 搭建簡單，只需提供json內(nèi)容即可支持版本更新。
  • 配套齊全，默認提供了后臺服務和管理界面。

項目地址

XHttp2

一個功能強悍的網(wǎng)絡請求庫，使用RxJava2 + Retrofit2 + OKHttp組合進行封裝。

XHttp2的出現(xiàn)主要是為了解決網(wǎng)絡請求前后端統(tǒng)一、靈活性、易用性和可拓展性等問題。它提供了豐富的API調(diào)用和功能，可以靈活地設置請求參數(shù)、攔截器、緩存策略，動態(tài)添加參數(shù)、異常攔截捕獲、自定義請求等。

設計原由

在沒有設計XHttp2之前，網(wǎng)絡請求我用過async-http、Volley、okhttp等網(wǎng)絡請求，普遍的做法就是寫一個網(wǎng)絡請求的工具類，提供幾種常用的請求方法進行調(diào)用，這樣做確實可以，但是也存在很多問題：

  • 靈活性差。請求參數(shù)一般都是固定的，不可以靈活地設置，每次有新的請求方式都需要增加更多的方法。

  • 易用性差。每次請求可能都需要構(gòu)建一個請求實體，并且不同的請求需要調(diào)用不同的方法，傳入不同的參數(shù)，往往一個請求需要寫很多重復的代碼。

  • 耦合度高。如果需要切換一種請求方式的話，需要修改所有工具類調(diào)用相關(guān)的代碼，非常麻煩。

  • 請求的行為不好控制。例如請求策略的控制、請求線程的控制、緩存策略的控制、請求響應以及異常處理的控制等。

  • 可拓展性差。無法自定義請求的形式，很難對請求進行統(tǒng)一和有效的管理，不利于解決前后端統(tǒng)一的問題。

但是自從有了Retrofit之后，以上的問題都得到了很好的解決?？梢哉fRetrofit真的是一個不錯的網(wǎng)絡請求框架，很好地體現(xiàn)了設計模式的優(yōu)美。當然，Retrofit也有自己的問題：

  • Retrofit定義的接口返回類型不支持二次泛型。

  • Retrofit雖具備高度的靈活性，但卻缺乏易用性，無法對請求進行統(tǒng)一的管理，所以使用起來不是那么方便。

  • Retrofit的擴展性不強。不支持自定義請求形式，只能在其提供的框架內(nèi)進行網(wǎng)絡請求。

設計思路

XHttp2最初的設計思路來源于RxEasyHttp 和axios。綜合使用了原型模式、構(gòu)建者模式、代理模式、策略模式、模板模式、裝飾模式、外觀模式、中介者模式、責任鏈模式和觀察者模式，并且嚴格遵循Java設計模式的七大設計原則進行了嚴格地設計。想了解更多設計細節(jié)的點擊查看XHttp2的設計類圖。

解決痛點

  • 提供了一整套統(tǒng)一的請求形式、攔截器、緩存、線程控制、請求響應、異常處理的解決方案。
  • 解決網(wǎng)絡請求前后端統(tǒng)一的問題。
  • 解決Retrofit易用性差的問題。
  • 解決網(wǎng)絡請求靈活性、易用性和可拓展性等問題。

項目地址

https://github.com/xuexiangjys/XHttp2

XPush

一個輕量級、可插拔的Android消息推送框架。一鍵集成推送（極光推送、友盟推送、信鴿推送、華為、小米推送等），提供有效的?；顧C制，支持推送的拓展，充分解耦推送和業(yè)務邏輯，解放你的雙手！

XPush是對Android各大消息推送平臺錯綜復雜的API進行統(tǒng)一的整合和管理，提供一致性的入口和出口，簡化消息推送的集成和使用。

設計原由

做過Android消息推送的人都知道，Android不僅設備碎片化嚴重，推送平臺也是五花八門的。早在2017年工信部就號召所有的廠商來制定統(tǒng)一的Android消息推送平臺，可到現(xiàn)在也沒有下文（究其原因還是這其中的利益太大了，誰也不想妥協(xié)）。我們不能將希望全都寄托在這個完全沒有定數(shù)的事件上，代碼終歸要寫，功能終歸要上，與其受制于人，不如自己革命，搞一個自己能控制的消息推送全平臺解決方案來得靠譜。

設計思路

雖然目前市面上各家提供的消息推送服務都各不相同，但仔細研究了之后就會發(fā)現(xiàn)它們其中是有很多共性的地方。其實我們完全可以提取一下公因數(shù)，將他們共性的地方提取出來并建立統(tǒng)一的管理，這樣就可以非常方便地接入和切換各大消息推送平臺了。這樣帶來的好處就是，無論后臺推送平臺或者方式如何變化，我們都不需要修改業(yè)務代碼，只需要簡單切換一下推送客戶端的實現(xiàn)方式就行了，做到消息推送和業(yè)務代碼的隔離。

解決痛點

  • 弱化了Android各大消息推送平臺的差異。
  • 簡化了Android各大消息推送平臺的集成和使用。
  • 提供了一致性的消息推送入口和出口。
  • 支持推送消息的過濾處理。

項目地址

https://github.com/xuexiangjys/XPush

XQRCode

一個非常方便實用的二維碼掃描、解析、生成庫

XQRCode作為一個二維碼掃描的應用庫，是基于zxing的識別功能實現(xiàn)的。它的設計目標就是方便、好用以及易拓展。

設計原由

二維碼掃描功能在App中可以說是一個非常常見的功能了，而且在網(wǎng)上也有很多相關(guān)的開源庫，那我為何還要自己重復造輪子呢？其實最初我使用的也是別人的開源庫：android-zxingLibrary.使用起來很方便，但問題也很多。還是那句話，易用性和靈活性不能很好地共存。雖然使用起來非常方便，但是默認提供的掃描界面效果并不是很理想，而且想自定義掃描界面非常地麻煩，很多掃描參數(shù)都無法自定義設置，不支持多次掃描，代碼的耦合性非常高。

設計思路

通過提供兩種自定義的方式：1.組件屬性自定義（自定義Fragment） 2.主題樣式自定義（自定義Activity） 這兩種方式以解決界面UI自定義難的問題。同時為一些重要的參數(shù)提供可設置的API。

解決痛點

  • 二維碼掃描界面自定義難的問題。
  • 二維碼多次掃描的問題。
  • 二維碼生成和解析的問題。

項目地址

https://github.com/xuexiangjys/XQRCode

XLog

一個簡易的日志打印框架（支持打印策略自定義，默認提供2種策略：logcat打印和磁盤打?。?/p>

XLog是一個非常方便易用的日志打印框架，主要提供日志打印輸出的能力?？梢造`活地控制日志打印的樣式和策略。

設計原由

在沒有XLog之前做日志打印的時候，基本都是基于工具類進行打印的，這就出現(xiàn)了一個比較嚴重的問題：定制化的問題。因為不同等級的日志需要打印的內(nèi)容是不一樣的，而且不同業(yè)務下打印的日志信息內(nèi)容也是不一樣的。例如：崩潰日志需要將盡可能的信息都記錄下來，單獨存成一個文件；一般性的錯誤日志需要將堆棧信息打印出來；關(guān)鍵點的日志需要將入?yún)ⅰ⒊鰠?、耗時以及所處線程等信息都打印出來；一般性的埋點信息可能只需要打印極少的內(nèi)容…

當日志打印出現(xiàn)如上需求的時候，想只通過簡簡單單的工具類來實現(xiàn)日志打印就顯得非常蹩腳了。

設計思路

為了解決定制化的問題，這里我借鑒了logger的設計思想，將日志打印拆分為兩個部分：日志格式策略和打印策略。日志格式策略主要負責日志輸出信息和樣式的處理，而打印策略主要負責日志輸出打印。

除此之外，為了能夠?qū)Ξ惓１罎⑦M行定制化處理，我還專門設計了一套崩潰處理的定制化方案，支持崩潰信息展示、郵件發(fā)送等形式。

解決痛點

  • 解決日志定制化的問題。支持自定義日志格式策略IFormatStrategy和打印策略ILogStrategy。
  • 支持自定義日志文件存儲形式（文件前綴、時間片存儲等）。
  • 支持自定義崩潰日志處理【默認提供了3種處理方式】。
  • 支持第三方打印接口的適配。

項目地址

https://github.com/xuexiangjys/XLog

XRouter

一個輕量級的Android路由框架，基于ARouter上進行改良，優(yōu)化Fragment的使用，可結(jié)合XPage使用。

XRouter是我在仔細研讀ARouter框架的源碼之后，結(jié)合我使用XPage過程中遇到的問題，而進行重新改寫的一個框架，一般是配合XPage使用。

設計原由

在我使用ARouter的時候，我發(fā)現(xiàn)它對Fragment的支持并不是很友好。說到底它主要還是為Activity路由服務的。而在我的XPage中Activity類非常少，因此使用起來極為不方便，不過ARouter的依賴注入設計得還是挺好的，因此改進它對Fragment的支持就顯得尤為重要。

解決痛點

  • 讓ARouter對Fragment的支持更加友好。
  • 配合XPage使用。

項目地址

https://github.com/xuexiangjys/XRouter

XOrmlite

一個方便實用的OrmLite數(shù)據(jù)庫框架，支持一鍵集成。

XOrmlite是我在接觸了APT（編譯時注解處理）技術(shù)后，在數(shù)據(jù)庫框架構(gòu)建上的一項應用。通過它，你可以一鍵集成ormlite數(shù)據(jù)庫框架，非常得方便。

設計原由

做Android都必定會和SQLite打交道，無奈在Google還沒有提供Room數(shù)據(jù)庫框架的時候，真的是要被SQLite折騰廢了，好在后來有了ormlite數(shù)據(jù)庫框架。

在使用了ormlite一段時間后，我發(fā)現(xiàn)應用使用的數(shù)據(jù)庫不一定都是內(nèi)存數(shù)據(jù)庫，可能還需要讀取操作外部存儲的數(shù)據(jù)庫，于是我又對其做了一定的封裝，讓其同時支持內(nèi)部數(shù)據(jù)庫和外部存儲數(shù)據(jù)庫，同時增加了數(shù)據(jù)庫連接池的功能。

但就是這樣，在使用的過程中我仍然發(fā)現(xiàn)庫在項目間的移植非常麻煩,每次引入都需要創(chuàng)建幾個幾乎完全類似的類，而應對的通常做法就是復制粘貼，有時有的地方不修改就可能導致出錯，總之還是比較麻煩的。同時，在數(shù)據(jù)庫第一次打開的時候，我們還需要根據(jù)數(shù)據(jù)庫類去創(chuàng)建對應的數(shù)據(jù)庫表，有的時候漏了個沒發(fā)現(xiàn)，結(jié)果就有可能出現(xiàn)排查了一下午問題最后發(fā)現(xiàn)是漏寫了一個類的尷尬。因此需要使用APT技術(shù)，在程序編譯時自動幫我們生成那幾個我們每次都需要創(chuàng)建的類以及收集我們所有使用到的數(shù)據(jù)庫實體類信息，這樣就可以大大減少錯誤的發(fā)生，降低了庫的引入難度。

設計思路

XOrmlite的設計思路很簡單，就是基于享元模式做了一個數(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.

設計原由

相信做過Android嵌入式開發(fā)或者智能硬件的人都知道，設備間的通訊基本都是基于自定義TCP協(xié)議來實現(xiàn)的。Http協(xié)議其實也是TCP協(xié)議的一種，但由于它攜帶的附帶信息過多，效率并不高，因此在做嵌入式開發(fā)的時候一般的做法都是自定義TCP協(xié)議來實現(xiàn)通訊。但是自定義協(xié)議這就需要牽涉到組包和拆包的工作。如果協(xié)議少的話，手動拆解包還是可行的。但是如果當協(xié)議的數(shù)量達到百來條以上的話，這個時候再進行手動拆解包的話就相當累了，而且如果協(xié)議發(fā)生變化的話，改起來不但非常痛苦，而且也容易出錯，代碼的可讀性和可維護性都比較差。

設計思路

通過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等常用基礎類型，支持類型的拓展。
  • 支持無符號數(shù)和有符號數(shù)兩種。
  • 支持BCD編碼格式【時間、int、float、double等】。
  • 支持大端和小端兩種存儲方式，支持設置全局默認存儲方式和局部存儲方式。
  • 支持short、int、long讀取長度的自定義。
  • 支持對實體字段進行排序，避免解析錯亂。
  • 支持自定義協(xié)議項和協(xié)議解析器。
  • 支持對不定長數(shù)組解析【需要注意的是，在一條協(xié)議中有且只能有一個不定長的數(shù)組，否則將無法解析成功】。
  • 支持自動協(xié)議映射，自動根據(jù)讀取的opcode識別出對應的協(xié)議并進行解析，并根據(jù)對應注冊的協(xié)議信息判斷協(xié)議是否有響應。

項目地址

https://github.com/xuexiangjys/XTCP

XUtil

一個方便實用的Android工具類庫

XUtil主要是我平時在開發(fā)過程中對一些實用工具類的整理。除此之外還包括一些常用的代碼混淆配置和Android Gradle腳本。

項目地址

https://github.com/xuexiangjys/XUtil

RxUtil2

一個實用的RxJava2工具類庫

RxUtil2主要包含了RxJava2常用操作符的相關(guān)應用。

解決痛點

  • RxBus 支持多事件定義，支持數(shù)據(jù)攜帶，支持全局和局部的事件訂閱和注銷。
  • 提供統(tǒng)一的訂閱池管理。
  • 支持非侵入式的訂閱生命周期綁定。
  • 提供簡易的線程調(diào)度輔助工具。
  • RxBinding 和 RxJava 常用操作符使用工具。

項目地址

https://github.com/xuexiangjys/RxUtil2

XIPC

一個Android通用的IPC(進程通信)框架。該項目主要是模仿餓了么開源項目Hermes的設計進行的自我理解改寫。

XIPC是一套非常方便的IPC(進程通信)框架。它可以將進程間通信的蹩腳方式（寫AIDL接口）簡化為像調(diào)用本地服務一樣方便。當初也是因為想摸清Hermes的實現(xiàn)原理，于是從0開始跟著源碼自己手擼了一個。

設計原由

其實Android進程間通訊的方式有很多種，例如：Bundle、AIDL、Socket、ContentProvider等，其中因AIDL方式提供的功能更強大，且支持實時通訊，因此成為很多人進行進程通訊的方式。但問題就是，使用AIDL方式來實現(xiàn)進程通訊較為復雜，且需要處理好線程同步等問題，使用起來不是很方便。如果進程通訊使用的場景不多的話，姑且使用AIDL的方式還算湊合，但如果使用的地方非常多的話，那就非常麻煩了，因為可能需要定義一堆接口和服務，那用起來是真的很麻煩了。

設計思路

XIPC主要借鑒了Retrofit的設計思路，采用動態(tài)代理、注解反射、AIDL、服務綁定和進程間垃圾回收等技術(shù)實現(xiàn)。詳細實現(xiàn)原理請點擊查看.

解決痛點

  • 支持自定義服務接口實現(xiàn)進程通信，無需定義AIDL接口，所有IPC通信就像調(diào)用本地函數(shù)一樣簡單。
  • 支持自定義接口服務（服務發(fā)現(xiàn)）、獲取單例和獲取工具類方法。
  • 支持進程通信的接口回調(diào)。
  • 支持接口回調(diào)的線程控制。
  • 擁有垃圾回收機制，防止接口回調(diào)內(nèi)存泄漏。
  • 支持跨進程和跨應用通信。

項目地址

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

微信公眾號

X-Library系列Android應用框架詳解_自定義_02

?

本文摘自 ：https://blog.51cto.com/u

開通會員，享受整站包年服務立即開通 >
推薦內(nèi)容