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

自2017年初開始，我就致力於Android應用框架的研究，到2018年開始在Github上陸續開源系列做品，再到2019年收穫個人第一個star過千的項目，期間我付出了不少，失去了不少，同時也得到了不少。

前言

爲了可以讓更多的人瞭解到個人開源項目，我也是使出了渾身解數，寫了很多文章和文檔來提升項目的曝光率，不過在這期間我也發現了很多問題：讀者的水平良莠不齊，以往我寫的文章都是創建在有必定開發基礎之上的，這就致使了不少新手小白、學生黨看不懂，不會用，瞎折騰，這徹底違背了個人初衷。我但願個人開源項目不只可以服務那些有必定開發經驗的人，還能幫助那些熱愛Android的人學習並提高本身的開發水平，早日可以跟上咱們的步伐。

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

概述

全部的技術框架都必須服務於實際生產，不然就是耍流氓。

我一直認爲這世上沒有絕對完美的事物，固然技術也並不例外。在作Android的最初幾年裏，我一直認爲技術是產品的靈魂，用於創造產品而又高於產品，是無可替代的，這也是我初期爲什麼執着於技術的緣由。漸漸地，當一項技術趨於成熟的時候，你會發現其實技術也並非想象中的那麼重要，一樣的功能或是產品，你能夠用2種或者更多的技術方案來實現，這個時候你纔會發現，原來技術也如同資本、人力、市場和物料等資源，只是咱們實現目的的工具而已。

其實X-Library正是我早期作Android開發過程當中積累沉澱下來的技術經驗，並經過我後期不斷完善以後造成的。雖然說可能不及大廠和google爸爸他們開源的項目那麼牛掰，不過相信我，這些框架都是在實際生產中誕生出來的優秀項目，相比大廠和google爸爸他們開源的項目，他們可能更適合中小企業或者獨立開發者的你使用哦！

下面是X-Library的思惟導圖：

---

Library簡介

XPage

一個很是方便的fragment頁面框架

XPage是我開源的第一個項目，也是最實用、最方便的項目之一。設計的初衷是但願能作一個通用的Activity做爲殼，Fragment做爲頁面填充展現，而且可以實現自由的切換和數據交互。

設計起因

當初作Android開發時每當我寫一個頁面，都須要建立一個Activity，而且還須要在manifest中註冊一堆Activity信息，這樣既不方便，並且對資源的開銷也比較大。所以當時我就設想可否創造出一個通用萬能的Activity容器，能夠全權負責Fragment的切換展現和數據交互，只須要一行代碼便可完成全部的操做，還不須要本身手動去註冊，能夠一鍵生成。

設計思路

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

忽然有一天我發現Github上有個開源項目CorePage寫得很是好，完美地解決了我對一個Activity容器的問題，因而我決定仔細研究其代碼，並在其基礎上設計出了XPage的最第一版本。

就在XPage正式投入使用的過程當中，我發現仍是存在很多問題的：

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

• 2.每一個Fragment仍須要手動註冊，很麻煩；

對於API不夠靈活的問題，我在以後的版本中陸續經過構造者模式設計以及Android主題屬性等手段解決了。

而對於手動註冊的問題，我正是借鑑了ARouter的思路，經過Android APT技術，從而實現了Fragment信息的自動註冊。

解決痛點

• 只須要一個Activity容器就能夠實現多個頁面的交互。

• Fragment自由切換和數據交互。

• 無需在manifest中註冊一堆Activity信息，經過@Page註解一鍵自動註冊。

項目地址

github.com/xuexiangjys…

---

XAOP

一個輕量級的AOP(Android)應用框架。囊括了最實用的AOP應用。

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

設計起因

在咱們平時開發的過程當中，必定會遇到權限申請、線程切換、數據緩存、異常捕獲、埋點和方法執行時間統計等問題。這些都是很是常見的問題，實現起來也不是很難，不過就是太麻煩了，還會讓程序多出不少重複性、模版化的代碼。

設計思路

讓我最初接觸到AOP思想的是JakeWharton的hugo,經過閱讀它的源碼以後，讓我對aspectj這項技術的動態代碼編織深深地着了迷。以後我詳細研究了aspectj相關的技術，並不斷蒐集AOP在Android上的典型應用場景，而後經過aspectj這項技術去逐一實現。最後就成就了XAOP這個庫。

解決痛點

• 能夠解決快速點擊的問題
• 解決Android6.0以上動態權限申請的問題
• 線程自由切換的問題
• 日誌埋點問題
• 緩存問題（磁盤緩存和內存緩存）
• 異常捕獲處理
• 業務攔截（登錄驗證、有效性驗證等）

項目地址

github.com/xuexiangjys…

---

XUI

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

XUI能夠說是我花費心血最多的開源項目了，目前稍微大一點的項目我都會選擇引入它。XUI幾乎涵蓋了目前Android開發所須要的全部組件，能夠說有了XUI以後，能夠大大提升咱們的開發效率，讓咱們能夠將精力不少地放在業務功能和數據處理上。能夠說XUI是目前Github上組件最全、文檔最詳細、案例最多的Android原生UI庫。

設計起因

相信作過Android的人都知道Android原生組件在國內很不受設計師的待見，至於Google推行的Material Design設計風格更是無人問津，這就致使了設計師給出的原型圖幾乎是清一色的IOS風格，更尷尬的是，網上Android相關的開源UI庫是少之又少，這可就爲難死咱們了，幾乎全部的基礎組件都須要本身重寫。以前也寫過React和Vue，發現它們都有很是方便的UI庫，並且使用起來也很是方便，直接在示例代碼的基礎上修修改改就能大體上實現本身想要的效果，極大地提升了開發的效率。

設計思路

在開始着手作這樣一個開源庫以前，我是一點思路都沒有的。好在在2017年的某一天，我接觸到了QMUI,經過閱讀它的源碼，我發現它的設計思路很是好，能夠經過設置不一樣的主題樣式、組件屬性等實現不一樣的組件效果，很是靈活；除此以外，它還對UI主題風格作了較爲詳細的制定和歸類，能夠說頗有啓發意義。因而我就遵循了QMUI的思路，開啓了XUI的編寫。

解決痛點

• 簡潔優雅，儘量少得引用資源文件的數量，項目庫總體大小不足1M。
• 組件豐富，提供了絕大多數咱們在開發者經常使用的功能組件。
• 使用簡單，爲方便快速開發，提升開發效率，對api進行了優化，提供一鍵式接入。
• 樣式統一，框架提供了一系列統一的樣式，使UI總體看上去美觀和諧。
• 兼容性高，框架還提供了3種不一樣尺寸設備的樣式（4.5英寸、7英寸和10英寸），而且最低兼容到Android 17, 讓UI兼容性更強。
• 擴展性強，各組件提供了豐富的屬性和樣式API，能夠經過設置不一樣的樣式屬性，構建不一樣風格的UI。

項目地址

github.com/xuexiangjys…

---

XUpdate

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

XUpdate是爲了解決在不一樣項目組、不一樣平臺之間進行統一的Android全量版本更新的庫。它具備輕量、靈活、低耦合、高可用等特色，能夠很方便地定製屬於本身的版本更新。

設計起因

在沒有XUpdate以前的版本更新，Android版本更新基本都是靠寫各類版本更新工具類來實現版本更新，更可怕的是有時在不一樣項目組或者平臺之間，它們的版本更新徹底是不同的，這樣的結果就是會寫無數的版本更新工具類，而且每次更換一個項目組或者平臺就須要從頭重寫再寫一遍，很是得麻煩。當時我就在想，版本更新做爲一個Android應用基本都有，且內容相對穩定的功能，有沒有可能設計出一個通用的、不爲業務或者平臺所影響的基礎庫呢？

設計思路

在着手寫XUpdate以前，我特意去Github上搜了一圈有關Android版本更新的內容，發現AppUpdate這個項目star數量最多。可是當我翻閱它的源碼以後發現，它設計得並不優美，內部耦合很是嚴重，不過優勢就是Android版本更新的功能基本都涵蓋了。因而我就照着它所擁有的功能，結合了我對版本更新的理解進行了從新設計，感興趣的可點擊查看框架UML設計圖。

解決痛點

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

項目地址

• Android基礎庫: github.com/xuexiangjys…
• 版本更新後臺服務: github.com/xuexiangjys…
• 版本更新管理系統: github.com/xuexiangjys…

---

XHttp2

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

XHttp2的出現主要是爲了解決網絡請求先後端統1、靈活性、易用性和可拓展性等問題。它提供了豐富的API調用和功能，能夠靈活地設置請求參數、攔截器、緩存策略，動態添加參數、異常攔截捕獲、自定義請求等。

設計起因

在沒有設計XHttp2以前，網絡請求我用過async-http、Volley、okhttp等網絡請求，廣泛的作法就是寫一個網絡請求的工具類，提供幾種經常使用的請求方法進行調用，這樣作確實能夠，可是也存在不少問題：

• 靈活性差。請求參數通常都是固定的，不能夠靈活地設置，每次有新的請求方式都須要增長更多的方法。

• 易用性差。每次請求可能都須要構建一個請求實體，而且不一樣的請求須要調用不一樣的方法，傳入不一樣的參數，每每一個請求須要寫不少重複的代碼。

• 耦合度高。若是須要切換一種請求方式的話，須要修改全部工具類調用相關的代碼，很是麻煩。

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

• 可拓展性差。沒法自定義請求的形式，很難對請求進行統一和有效的管理，不利於解決先後端統一的問題。

可是自從有了Retrofit以後，以上的問題都獲得了很好的解決。能夠說Retrofit真的是一個不錯的網絡請求框架，很好地體現了設計模式的優美。固然，Retrofit也有本身的問題：

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

• Retrofit雖具有高度的靈活性，但卻缺少易用性，沒法對請求進行統一的管理，因此使用起來不是那麼方便。

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

設計思路

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

解決痛點

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

項目地址

github.com/xuexiangjys…

---

XPush

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

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

設計起因

作過Android消息推送的人都知道，Android不只設備碎片化嚴重，推送平臺也是五花八門的。早在2017年工信部就號召全部的廠商來制定統一的Android消息推送平臺，可到如今也沒有下文（究其緣由仍是這其中的利益太大了，誰也不想妥協）。咱們不能將但願全都寄託在這個徹底沒有定數的事件上，代碼終歸要寫，功能終歸要上，與其受制於人，不如本身革命，搞一個本身能控制的消息推送全平臺解決方案來得靠譜。

設計思路

雖然目前市面上各家提供的消息推送服務都各不相同，但仔細研究了以後就會發現它們其中是有不少共性的地方。其實咱們徹底能夠提取一下公因數，將他們共性的地方提取出來並創建統一的管理，這樣就能夠很是方便地接入和切換各大消息推送平臺了。這樣帶來的好處就是，不管後臺推送平臺或者方式如何變化，咱們都不須要修改業務代碼，只須要簡單切換一下推送客戶端的實現方式就好了，作到消息推送和業務代碼的隔離。

解決痛點

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

項目地址

github.com/xuexiangjys…

---

XQRCode

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

XQRCode做爲一個二維碼掃描的應用庫，是基於zxing的識別功能實現的。它的設計目標就是方便、好用以及易拓展。

設計起因

二維碼掃描功能在App中能夠說是一個很是常見的功能了，並且在網上也有不少相關的開源庫，那我爲什麼還要本身重複造輪子呢？其實最初我使用的也是別人的開源庫：android-zxingLibrary.使用起來很方便，但問題也不少。仍是那句話，易用性和靈活性不能很好地共存。雖然使用起來很是方便，可是默認提供的掃描界面效果並非很理想，並且想自定義掃描界面很是地麻煩，不少掃描參數都沒法自定義設置，不支持屢次掃描，代碼的耦合性很是高。

設計思路

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

解決痛點

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

項目地址

github.com/xuexiangjys…

---

XLog

一個簡易的日誌打印框架（支持打印策略自定義，默認提供2種策略：logcat打印和磁盤打印）

XLog是一個很是方便易用的日誌打印框架，主要提供日誌打印輸出的能力。能夠靈活地控制日誌打印的樣式和策略。

設計起因

在沒有XLog以前作日誌打印的時候，基本都是基於工具類進行打印的，這就出現了一個比較嚴重的問題：定製化的問題。由於不一樣等級的日誌須要打印的內容是不同的，並且不一樣業務下打印的日誌信息內容也是不同的。例如：崩潰日誌須要將盡量的信息都記錄下來，單獨存成一個文件；通常性的錯誤日誌須要將堆棧信息打印出來；關鍵點的日誌須要將入參、出參、耗時以及所處線程等信息都打印出來；通常性的埋點信息可能只須要打印極少的內容....

當日志打印出現如上需求的時候，想只經過簡簡單單的工具類來實現日誌打印就顯得很是蹩腳了。

設計思路

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

除此以外，爲了可以對異常崩潰進行定製化處理，我還專門設計了一套崩潰處理的定製化方案，支持崩潰信息展現、郵件發送等形式。

解決痛點

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

項目地址

github.com/xuexiangjys…

---

XRouter

一個輕量級的Android路由框架，基於ARouter上進行改良，優化Fragment的使用，可結合XPage使用。

XRouter是我在仔細研讀ARouter框架的源碼以後，結合我使用XPage過程當中遇到的問題，而進行從新改寫的一個框架，通常是配合XPage使用。

設計起因

在我使用ARouter的時候，我發現它對Fragment的支持並非很友好。說到底它主要仍是爲Activity路由服務的。而在個人XPage中Activity類很是少，所以使用起來極爲不方便，不過ARouter的依賴注入設計得仍是挺好的，所以改進它對Fragment的支持就顯得尤其重要。

解決痛點

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

項目地址

github.com/xuexiangjys…

---

XOrmlite

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

XOrmlite是我在接觸了APT（編譯時註解處理）技術後，在數據庫框架構建上的一項應用。經過它，你能夠一鍵集成ormlite數據庫框架，很是得方便。

設計起因

作Android都一定會和SQLite打交道，無奈在Google尚未提供Room數據庫框架的時候，真的是要被SQLite折騰廢了，好在後來有了ormlite數據庫框架。

在使用了ormlite一段時間後，我發現應用使用的數據庫不必定都是內存數據庫，可能還須要讀取操做外部存儲的數據庫，因而我又對其作了必定的封裝，讓其同時支持內部數據庫和外部存儲數據庫，同時增長了數據庫鏈接池的功能。

但就是這樣，在使用的過程當中我仍然發現庫在項目間的移植很是麻煩,每次引入都須要建立幾個幾乎徹底相似的類，而應對的一般作法就是複製粘貼，有時有的地方不修改就可能致使出錯，總之仍是比較麻煩的。同時，在數據庫第一次打開的時候，咱們還須要根據數據庫類去建立對應的數據庫表，有的時候漏了個沒發現，結果就有可能出現排查了一下午問題最後發現是漏寫了一個類的尷尬。所以須要使用APT技術，在程序編譯時自動幫咱們生成那幾個咱們每次都須要建立的類以及收集咱們全部使用到的數據庫實體類信息，這樣就能夠大大減小錯誤的發生，下降了庫的引入難度。

設計思路

XOrmlite的設計思路很簡單，就是基於享元模式作了一個數據庫鏈接池，而後對Ormlite數據庫進行了二次封裝，而後經過APT技術分別生成數據庫框架構建所須要的鏈接池和實現接口，並自動收集項目中所使用到的全部數據庫實體信息類用於數據庫表的初始建立。

解決痛點

• 支持自動生成數據庫管理倉庫DataBaseRepository和自動搜索全部的數據庫表類，並自動建立數據庫表，簡化了數據庫框架的引入。
• 支持內部存儲和外部存儲兩種數據庫，支持自定義數據庫存儲位置。
• 提供了經常使用的數據庫操做API，簡化了數據庫的使用。

項目地址

github.com/xuexiangjys…

---

XTCP

一個便捷的TCP消息包拼裝和解析框架

XTCP是一套可以自動進行TCP消息包拼包、拆包和解析的框架，相似於Google的protobuf.

設計起因

相信作過Android嵌入式開發或者智能硬件的人都知道，設備間的通信基本都是基於自定義TCP協議來實現的。Http協議其實也是TCP協議的一種，但因爲它攜帶的附帶信息過多，效率並不高，所以在作嵌入式開發的時候通常的作法都是自定義TCP協議來實現通信。可是自定義協議這就須要牽涉到組包和拆包的工做。若是協議少的話，手動拆解包仍是可行的。可是若是當協議的數量達到百來條以上的話，這個時候再進行手動拆解包的話就至關累了，並且若是協議發生變化的話，改起來不但很是痛苦，並且也容易出錯，代碼的可讀性和可維護性都比較差。

設計思路

經過APT（編譯時註解處理）技術，對標註了@Protocol和@ProtocolField類進行自動統計和創建映射關係，解析時借鑑了Gson的思路，採用註解反射和遞歸的方式進行拼包和解析。

解決痛點

• 簡單經過@Protocol和@ProtocolField的配置，便可讓實體對象擁有自動轉化爲TCP傳輸的byte數據和自動byte數據解析。
• 支持byte、short、int、long、byte[]、short[]、int[]、long[]、String等經常使用基礎類型，支持類型的拓展。
• 支持無符號數和有符號數兩種。
• 支持BCD編碼格式【時間、int、float、double等】。
• 支持大端和小端兩種存儲方式，支持設置全局默認存儲方式和局部存儲方式。
• 支持short、int、long讀取長度的自定義。
• 支持對實體字段進行排序，避免解析錯亂。
• 支持自定義協議項和協議解析器。
• 支持對不定長數組解析【須要注意的是，在一條協議中有且只能有一個不定長的數組，不然將沒法解析成功】。
• 支持自動協議映射，自動根據讀取的opcode識別出對應的協議並進行解析，並根據對應註冊的協議信息判斷協議是否有響應。

項目地址

github.com/xuexiangjys…

---

XUtil

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

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

項目地址

github.com/xuexiangjys…

---

RxUtil2

一個實用的RxJava2工具類庫

RxUtil2主要包含了RxJava2經常使用操做符的相關應用。

解決痛點

• RxBus 支持多事件定義，支持數據攜帶，支持全局和局部的事件訂閱和註銷。
• 提供統一的訂閱池管理。
• 支持非侵入式的訂閱生命週期綁定。
• 提供簡易的線程調度輔助工具。
• RxBinding 和 RxJava 經常使用操做符使用工具。

項目地址

github.com/xuexiangjys…

---

XIPC

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

XIPC是一套很是方便的IPC(進程通訊)框架。它能夠將進程間通訊的蹩腳方式（寫AIDL接口）簡化爲像調用本地服務同樣方便。當初也是由於想摸清Hermes的實現原理，因而從0開始跟着源碼本身手擼了一個。

設計起因

其實Android進程間通信的方式有不少種，例如：Bundle、AIDL、Socket、ContentProvider等，其中因AIDL方式提供的功能更強大，且支持實時通信，所以成爲不少人進行進程通信的方式。但問題就是，使用AIDL方式來實現進程通信較爲複雜，且須要處理好線程同步等問題，使用起來不是很方便。若是進程通信使用的場景很少的話，姑且使用AIDL的方式還算湊合，但若是使用的地方很是多的話，那就很是麻煩了，由於可能須要定義一堆接口和服務，那用起來是真的很麻煩了。

設計思路

XIPC主要借鑑了Retrofit的設計思路，採用動態代理、註解反射、AIDL、服務綁定和進程間垃圾回收等技術實現。詳細實現原理請點擊查看.

解決痛點

• 支持自定義服務接口實現進程通訊，無需定義AIDL接口，全部IPC通訊就像調用本地函數同樣簡單。
• 支持自定義接口服務（服務發現）、獲取單例和獲取工具類方法。
• 支持進程通訊的接口回調。
• 支持接口回調的線程控制。
• 擁有垃圾回收機制，防止接口回調內存泄漏。
• 支持跨進程和跨應用通訊。

項目地址

github.com/xuexiangjys…

---

XVideo

一個能自動進行壓縮的小視頻錄製庫

XVideo主要採用FFmpeg技術實現視頻錄製。主要解決使用系統API視頻錄製文件過大的問題，支持在視頻錄製的過程當中自動進行視頻壓縮。

解決痛點

• 支持自定義小視頻錄製時的視頻質量。
• 支持自定義視頻錄製的界面。
• 支持自定義最大錄製時長和最小錄製時長。
• 支持自定義屬性的視頻壓縮。

項目地址

github.com/xuexiangjys…

---

XFloatView

一個簡易的懸浮窗實現方案

解決痛點

• 支持自定義佈局的懸浮窗。
• 支持自定義拖動事件、點擊事件。
• 支持懸浮窗自動吸附效果。
• 支持初始化懸浮窗的位置。
• 支持懸浮窗翻轉吸附。
• 支持各手機廠商Rom的懸浮窗權限申請。

項目地址

github.com/xuexiangjys…

---

聯繫方式

微信公衆號