前端【免費下載鏈接】getxOpen screens/snackbars/dialogs/bottomSheets without context, manage states and inject dependencies easily with Get.項目地址https://gitcode.com/gh_mirrors/ge/getx點擊查看免費下載本篇技術指南圍繞 GetGetX的依賴管理系統(tǒng)展開詳細講解Get.put、Get.lazyPut、Get.putAsync、Get.create四種實例化方法的參數(shù)與適用場景以及Get.find、Get.delete、replace/lazyReplace的使用方式并結合源碼剖析 Bindings、BindingsBuilder 與 SmartManagement 的底層實現(xiàn)。讀完本文你將能夠在不依賴 Provider context 與 InheritedWidget 的情況下完成依賴注入理解permanent與fenix的本質區(qū)別并為路由配置自動回收、按需重建的控制器生命周期。本文對應的原始文檔位于 documentation/ar_EG/dependency_management.md英文原版見 documentation/en_US/dependency_management.md全部源碼佐證均來自當前倉庫 lib/get_instance 與 lib/get_state_manager 等目錄。一、為什么需要 Get 的依賴管理器Get 提供了一套簡單而強大的依賴管理器你不需要 Provider 的context不需要InheritedWidget只需要一行代碼就能像獲取普通類一樣拿到你的 Controller 或 Bloc 實例Controller controller Get.put(Controller()); // 代替 Controller controller Controller();其核心思想是不要在你使用類的內部去實例化它而是把它實例化到 Get 這個全局容器里讓它在整個 App 范圍內可用。之后你可以像使用普通類一樣使用這個 controller或 Bloc 類。使用前有兩個重要提示文檔原文 Note如果你正在使用 Get 的狀態(tài)管理器請重點關注 Bindings API它能更輕松地將視圖與控制器連接起來Get 的依賴管理與其他部分狀態(tài)管理、路由是解耦的。即便你的應用已經在使用其他任何狀態(tài)管理器也無需更換可以直接無沖突地使用這套依賴注入管理器。從源碼看這套機制的核心是一個以類型和可選的 tag為 key 的 HashMap。在 extension_instance.dart 中_singl保存了所有通過Get.put注冊的實例工廠_getKey生成 key 的邏輯是name null ? type.toString() : type.toString() name即類型名 tag共同決定唯一性這正是同一類型可通過 tag 注冊多個實例的原理。二、四大實例化方法Instancing Methods文檔將注冊依賴的方式歸納為四種方法各有各的參數(shù)與適用場景。Get.put()最常用的同步注冊Get.put是最常見的插入依賴的方式例如視圖對應的 ControllerGet.putSomeClass(SomeClass()); Get.putLoginController(LoginController(), permanent: true); Get.putListItemController(ListItemController, tag: some unique string);Get.put支持的全部參數(shù)如下來自文檔Get.putS( // 必填想要保存的類實例比如 controller 或任何對象 // 注意S 表示它可以是任意類型的類 S dependency // 可選當你需要多個同類型實例時使用 // 因為通常用 Get.findController() 獲取類需要用 tag 告訴 Get 你要哪個實例 // 必須是唯一的字符串 String tag, // 可選默認情況下Get 會在實例不再被使用時將其釋放 // 例如被關閉的視圖的 controller。但如果這個實例需要在整個 App // 中一直存活比如 SharedPreferences 之類的實例就使用這個參數(shù) // 默認為 false bool permanent false, // 可選允許你在測試中先使用抽象類再將其替換為另一個類并繼續(xù)測試 // 默認為 false bool overrideAbstract false, // 可選允許你用一個函數(shù)來創(chuàng)建依賴而不是直接傳依賴本身 // 這個參數(shù)不常用 InstanceBuilderCallbackS builder, )結合源碼可以更精確地理解put的行為。在 extension_instance.dart 中S putS( S dependency, { String? tag, bool permanent false, }) { _insert( isSingleton: true, name: tag, permanent: permanent, builder: (() dependency)); return findS(tag: tag); }它通過內部方法_insert以isSingleton: true、permanent: permanent的方式把實例登記進_singl隨后立即調用findS也就是說put是注冊即初始化實例在調用返回時已經可用。_insert中還有一個細節(jié)如果該 key 已存在且不是isDirty狀態(tài)會直接返回避免重復注冊覆蓋。倉庫測試 get_instance_test.dart 驗證了Get.put后Get.find返回同一實例。Get.lazyPut()懶加載lazyPut允許你懶加載依賴只有第一次真正使用Get.find時才會實例化。這非常適合計算開銷大的類或者像 Bindings 類里集中注冊多個類、但當時并不需要全部使用的情況。/// ApiMock 只有在有人第一次使用 Get.findApiMock 時才會被調用 Get.lazyPutApiMock(() ApiMock()); Get.lazyPutFirebaseAuth( () { // ... 如果需要可以在這里寫一些邏輯 return FirebaseAuth(); }, tag: Math.random().toString(), fenix: true ) Get.lazyPutController( () Controller() )lazyPut的參數(shù)說明來自文檔Get.lazyPutS( // 必填一個方法在類第一次被調用時執(zhí)行 InstanceBuilderCallback builder, // 可選與 Get.put() 相同用于需要同一類的多個不同實例 // 必須是唯一的 String tag, // 可選與 permanent 類似區(qū)別在于實例在不再使用時會被丟棄 // 但當再次需要它時Get 會重新創(chuàng)建實例 // 與 bindings API 中的 SmartManagement.keepFactory 行為一致 // 默認為 false bool fenix false )源碼層面lazyPut與put一樣調用_insert但不會立即執(zhí)行find實例只是以工廠回調的形式注冊同時有個值得注意的默認邏輯fenix: fenix ?? Get.smartManagement SmartManagement.keepFactory,也就是說如果你沒有顯式傳fenix那么fenix的值會跟隨全局smartManagement配置當SmartManagement.keepFactory生效時lazyPut默認開啟 fenix 行為詳見后文 SmartManagement 章節(jié)。倉庫測試 get_instance_test.dart 驗證了 fenix 語義lazyPut(fenix: true)注冊的實例在Get.delete后再find會重新得到 count 歸零的新實例而fenix: false時delete之后find會直接拋出異常因為實例已從內存移除。Get.putAsync()異步注冊當需要注冊一個異步創(chuàng)建的實例時比如需要await初始化使用Get.putAsyncGet.putAsyncSharedPreferences(() async { final prefs await SharedPreferences.getInstance(); await prefs.setInt(counter, 12345); return prefs; }); Get.putAsyncYourAsyncClass( () async await YourAsyncClass() )參數(shù)說明來自文檔Get.putAsyncS( // 必填一個異步方法用于實例化你的類 AsyncInstanceBuilderCallbackS builder, // 可選與 Get.put() 相同用于同一類的多個不同實例 // 必須是唯一的 String tag, // 可選與 Get.put() 相同用于需要在整個 App 中保持存活的實例 // 默認為 false bool permanent false )與Get.put一樣putAsync也是注冊即初始化區(qū)別僅在于初始化過程是異步完成的注冊完成后同樣立即對實例調用find完成初始化。Get.create()每次 find 都重新制造Get.create是最特別的一個方法文檔原話This one is tricky建議先閱讀方法之間的差異一節(jié)再回來理解。Get.CreateSomeClass(() SomeClass()); Get.CreateLoginController(() LoginController());參數(shù)說明來自文檔Get.createS( // 必填一個返回類的函數(shù)每次調用 Get.find() 時都會用這個函數(shù)重新制造一個實例 // 示例Get.createYourClass(() YourClass()) FcBuilderFuncS builder, // 可選與 Get.put() 中的 tag 類似用于同一類的多個實例 // 當你有一個列表、每個列表項都需要自己的 controller 時非常有用 // 必須是唯一的字符串注意參數(shù)名是 name 而不是 tag String name, // 可選與 Get.put() 中的 permanent 類似用于需要在整個 App 中 // 保持存活的實例。區(qū)別在于Get.create 中 permanent 默認為 true bool permanent true )從當前倉庫源碼結構看Get.create的底層語義與內部方法spawn一致以isSingleton: false、permanent: true注冊工廠于是每次Get.find都會調用 builder 生成全新實例非單例同時因為permanent: true實例不會在頁面切換時被回收。文檔特別強調Get.create的目標是創(chuàng)建不共享、但不會被釋放的實例例如 listView 中每個列表項想要獨立且唯一的 controller因此Get.create必須與 GetWidget 配合使用。倉庫中 get_view.dart 的注釋也印證了這一點Get 會幫你緩存 controller因此可以安全地使用Get.create。測試 get_instance_test.dart 驗證了該語義連續(xù)兩次find得到的實例ct1 ct2為false。三、使用已注冊的實例Get.find 與 Get.delete想象你已經導航了無數(shù)個路由現(xiàn)在需要之前遺留在某個 controller 里的數(shù)據(jù)。傳統(tǒng)方案需要狀態(tài)管理器配合 Provider 或 get_it而 Get 只需要一行Get.find不需要任何額外依賴final controller Get.findController(); // 或者 Controller controller Get.find();是的看起來像魔法Get 會找到你的 controller 并把它交給你。哪怕你實例化了 100 萬個 controllerGet 也總能給你正確的那個。拿到實例后就能正常恢復數(shù)據(jù)Text(controller.textFromApi);由于返回值就是普通類你可以對它做任何事int count Get.findSharedPreferences().getInt(counter); print(count); // out: 12345移除一個實例Get.deleteController(); // 通常你不需要這樣做因為 GetX 會自動刪除不再使用的 controller從源碼看find首先檢查該 key 是否已注冊未注冊則拋出提示會提示你調用Get.put或Get.lazyPut已注冊則進入_initDependencies初始化流程——如果實例實現(xiàn)了GetLifeCycleMixin_startController會觸發(fā)其生命周期方法onStart()并依據(jù)smartManagement配置決定是否把該依賴與當前路由綁定RouterReportManager.reportDependencyLinkedToRoute這正是路由移除時自動回收依賴的機制來源。此外還有幾個實用的配套 APIGet.findOrNullT()已注冊則返回實例否則返回null不會拋異常見 extension_instance.dartGet.isRegisteredT({tag})判斷實例是否已注冊extension_instance.dartGet.isPreparedT({tag})判斷是否還有未被初始化的懶加載工廠extension_instance.dartGet.reset()/Get.resetInstance()清空所有注冊實例包括永久實例適合在單元測試的tearDown中使用見 extension_instance.dart。四、指定替代實例replace 與 lazyReplace已注冊的實例可以被替換為同類或擴展類的實例之后仍可通過原類型獲取。這就是replace與lazyReplace的用途abstract class BaseClass {} class ParentClass extends BaseClass {} class ChildClass extends ParentClass { bool isChild true; } Get.putBaseClass(ParentClass()); Get.replaceBaseClass(ChildClass()); final instance Get.findBaseClass(); print(instance is ChildClass); // true class OtherClass extends BaseClass {} Get.lazyReplaceBaseClass(() OtherClass()); final instance Get.findBaseClass(); print(instance is ChildClass); // false print(instance is OtherClass); // true源碼實現(xiàn)印證了替換 刪除 重新注冊replace先讀取原實例的permanent狀態(tài)用delete(force: permanent)刪除原實例再以相同permanent值put新實例lazyReplace先刪除再以lazyPut注冊新工廠且fenix未顯式傳入時默認取原實例的permanent值。這一能力與Get.put的overrideAbstract參數(shù)搭配常用于測試場景先用抽象類注冊再替換為具體實現(xiàn)類。倉庫測試 get_instance_test.dart 展示了抽象類Service分別通過lazyPut與spawncreate 語義注入Api實現(xiàn)的用法。五、permanent 與 fenix方法間的本質差異先厘清 permanent 與 fenix二者的根本區(qū)別在于你希望如何存儲實例。先重申默認行為GetX 默認會在實例不再被使用時將其刪除。例如屏幕 1 有 controller 1屏幕 2 有 controller 2當你用Get.off()或Get.offNamed()把第一條路由移出棧時controller 1 失去用途隨即被清除。使用permanent: truecontroller 不會在這次切換中丟失——非常適合希望在整個應用生命周期中存活的 Service。fenix: true用于不擔心它在頁面切換時丟失但當你需要它時它必須是活的的服務。它會釋放不再使用的 controller/service/類但當你再次需要時會從灰燼中重生重新創(chuàng)建一個新實例。各方法的底層差異文檔給出了非常清晰的底層機制對照結合 extension_instance.dart 中的_insert實現(xiàn)可以完全印證方法底層 insert 參數(shù)是否立即 find 初始化實例形態(tài)典型場景Get.putpermanent: false, isSingleton: true是調用后立即可用單例直接持有dependency視圖 ControllerGet.putAsyncpermanent: false, isSingleton: true是異步完成后立即 find單例需要 await 初始化的實例Get.createpermanent: true, isSingleton: false否等界面用到時才調用每次 find 新建builderFunc每次執(zhí)行列表項各自的獨立 Controller需配合 GetWidgetGet.lazyPut不調用 insert注冊到工廠區(qū)否首次 find 時創(chuàng)建首次 find 后成為單例計算開銷大、集中注冊但不立即使用的類逐條展開文檔原文要點Get.put 與 Get.putAsync遵循相同的創(chuàng)建順序區(qū)別僅是后者使用異步方法兩者都會創(chuàng)建并初始化實例直接通過內部方法insert以permanent: false、isSingleton: true插入內存isSingleton參數(shù)唯一的作用是決定取用dependency還是FcBuilderFunc作為依賴來源。隨后調用Get.find()立即初始化內存中的實例。Get.create顧名思義會創(chuàng)建依賴。與put類似也調用內部insert但permanent變?yōu)閠rue、isSingleton變?yōu)閒alse因為是創(chuàng)建不可能是單例。由于permanent: true默認享有頁面切換不丟失的好處同時Get.find()不會被立即調用而是等待界面真正使用它時才觸發(fā)。值得強調的是Get.create的設計目標就是創(chuàng)建不共享、但不會被釋放的實例。Get.lazyPut惰性過程。實例會被創(chuàng)建但不會立即被調用而是等待使用。與其他方法相反這里不會調用insert而是把實例插入內存的另一區(qū)域——負責判斷實例是否可以重建的區(qū)域文檔稱之為factory工廠。這樣未來要用的東西不會與正在使用的東西混在一起。fenix的魔法就在這里若fenix: false且smartManagement不是keepFactory那么首次Get.find時實例會從工廠區(qū)移到公共實例內存區(qū)隨即默認從工廠區(qū)移除若fenix: true實例即使在移入公共區(qū)后仍保留在工廠區(qū)將來可再次被調用重建。六、Bindings路由、狀態(tài)與依賴的完整集成Bindings 也許是 Get 包最突出的差異化能力之一路由管理器、狀態(tài)管理器與依賴管理器的完整集成。當路由從棧中移除時與之相關的所有 controller、變量和對象實例都會從內存中移除如果你使用了 streams 或 timers它們會被自動關閉你無需操心這些。自 Get v2.10 起完整實現(xiàn)了 Bindings API。你不再需要 init 方法甚至可以不手動聲明 controller 的類型——可以在合適的地方啟動你的 controller 與 services。Binding 類的作用是把依賴注入解耦同時把路由與狀態(tài)管理器、依賴管理器綁定在一起這讓 Get 能知道某個 controller 被使用時正在顯示哪個界面也知道在哪里、以何種方式釋放它。此外 Binding 類還允許你獲得 SmartManager 配置控制權決定依賴是在路由移出棧時、還是使用它的 widget 布局時被清理或兩者都不清理。Bindings 類創(chuàng)建一個實現(xiàn)Binding的類注意當前源碼中Bindings已標記為廢棄推薦使用Binding見 bindings_interface.dartclass HomeBinding implements Binding {}IDE 會自動提示你重寫dependencies方法在該方法里注冊這個路由要用到的所有類class HomeBinding implements Binding { override void dependencies() { Get.lazyPutHomeController(() HomeController()); Get.putService(() Api()); } } class DetailsBinding implements Binding { override void dependencies() { Get.lazyPutDetailsController(() DetailsController()); } }然后在路由聲明中告知 Get 使用該 Binding從而打通路由管理器 ? 依賴 ? 狀態(tài)使用命名路由getPages: [ GetPage( name: /, page: () HomeView(), binding: HomeBinding(), ), GetPage( name: /details, page: () DetailsView(), binding: DetailsBinding(), ), ];使用普通路由Get.to(Home(), binding: HomeBinding()); Get.to(DetailsView(), binding: DetailsBinding())這樣你就不必再擔心應用的內存管理Get 會替你完成。Binding 類會在路由被調用時執(zhí)行同時你也可以在GetMaterialApp中設置initialBinding集中注冊那些一開始就要創(chuàng)建的依賴GetMaterialApp( initialBinding: SampleBind(), home: Home(), );倉庫中initialBinding是GetMaterialApp與GetCupertinoApp的標準配置項見 get_cupertino_app.dart示例工程也采用了 Binding 路由的完整分層可參考 example/lib/routes/app_pages.dart 與 example_nav2/lib/app/routes/app_pages.dart。BindingsBuilder默認方式是為每個路由創(chuàng)建實現(xiàn)Bindings的類但也可以用BindingsBuilder回調直接用函數(shù)注冊任意依賴getPages: [ GetPage( name: /, page: () HomeView(), binding: BindingsBuilder(() { Get.lazyPutControllerX(() ControllerX()); Get.putService(() Api()); }), ), GetPage( name: /details, page: () DetailsView(), binding: BindingsBuilder(() { Get.lazyPutDetailsController(() DetailsController()); }), ), ];這樣就不必為每個路由單獨創(chuàng)建一個 Binding 類更簡潔。文檔說明兩種方式都完全有效按個人偏好選擇即可。七、SmartManagement智能內存管理GetX 默認會釋放不再使用的 controller即使發(fā)生異常、使用它的 widget 未被正確銷毀也不例外——這就是依賴管理的full模式。如果你希望改變 GetX 控制類釋放的方式可以通過SmartManagement類設置不同行為。源碼中它是一個三值枚舉定義于 smart_management.dart默認值為full見 get_interface.dart。如何修改通常你不需要修改此配置如果確實需要在GetMaterialApp上指定即可void main () { runApp( GetMaterialApp( smartManagement: SmartManagement.onlyBuilder // 在這里配置 home: Home(), ) ) }smartManagement是GetMaterialApp的內置配置參數(shù)默認SmartManagement.full見 get_material_app.dart。SmartManagement.full默認模式。釋放未被使用且未被標記為 permanent的類。絕大多數(shù)情況下你都應保持該配置不變如果你是 GetX 新手請不要改動它。SmartManagement.onlyBuilder該模式下只有通過init:啟動、或通過 Binding 里的Get.lazyPut()加載的 controller 才會被釋放。如果你使用Get.put()、Get.putAsync()或其他任何方式注冊SmartManagement 將沒有權限刪除該依賴。而默認行為full下即使是通過Get.put實例化的 widget 也會被移除這與onlyBuilder不同。注意命名當前倉庫源碼中的枚舉名為onlyBuilder單數(shù)部分文檔版本寫作onlyBuilders復數(shù)使用時以源碼為準。此外路由側也有對應邏輯RouterReportManager只有在smartManagement ! SmartManagement.onlyBuilder時才把依賴與路由綁定見 router_report.dart這解釋了為何onlyBuilder模式下Get.put注冊的實例不受路由生命周期管理。SmartManagement.keepFactory與SmartManagement.full一樣在依賴不再使用時移除它但會保留其工廠factory意味著當你再次需要該實例時會重新創(chuàng)建。因此它和lazyPut(fenix: true)效果等價——事實上源碼中l(wèi)azyPut的默認fenix正是跟隨smartManagement keepFactory見 extension_instance.dart。八、Bindings 底層工作原理文檔給出了非常直觀的底層說明Bindings 創(chuàng)建的是臨時工廠transitory factories——在你點擊跳轉另一界面的瞬間創(chuàng)建并在界面切換動畫結束的瞬間銷毀整個過程快到 analyzer 都無法察覺。當你再次導航到該界面時會重新調用一個新的臨時工廠。因此 Bindings 方式優(yōu)于直接使用SmartManagement.keepFactory但如果你不想創(chuàng)建 Bindings或想把所有依賴放在同一個 Binding 里keepFactory會是有效的替代。工廠本身占用內存極小——它不持有實例只保存一個具有該類形狀的函數(shù)內存成本非常低。不過由于本庫的設計目標是用最少的資源獲得最大性能Get 默認連工廠也會移除。二者按需選用即可。九、注意事項與最佳實踐Notes文檔在結尾給出了兩條關鍵提醒結合倉庫實現(xiàn)可歸納為以下最佳實踐不要在使用多個 Bindings 時使用SmartManagement.keepFactory。它被設計用于不使用 Bindings或僅在 GetMaterialApp 的 initialBinding 中關聯(lián)單個 Binding的場景。Bindings 完全是可選的。你也可以直接在類中使用Get.put()與Get.find()而毫無問題。但如果你使用 Services 或任何其他抽象建議使用 Bindings 以獲得更好的組織性。GetxService 不可被普通delete刪除。源碼 lifecycle.dart 說明與 GetxController 不同GetxService 一旦啟動就常駐內存例如 Auth 服務唯一的移除方式是Get.reset()。delete方法對實現(xiàn)GetxServiceMixin的實例也會直接返回除非force: true測試 get_instance_test.dart 驗證了這一行為普通delete后isRegistered仍為true只有delete(force: true)才會真正移除。permanent 實例的刪除需要 force。delete方法對permanent: true的實例會拒絕刪除并輸出錯誤日志除非顯式傳入force: true見 extension_instance.dart。在測試中善用Get.reset()。它會清空所有注冊實例包括永久實例與路由綁定clearRouteBindings保證測試之間互不污染見 extension_instance.dart。生命周期鉤子如果你的 Controller 混入GetLifeCycleMixin如 GetxController實例創(chuàng)建時會依次觸發(fā)onStart → onInit → onReady銷毀時觸發(fā)onDelete → onClose見 lifecycle.dart。這讓你可以在onClose中關閉 streams、timers、TextEditingController 等資源配合路由回收機制實現(xiàn)無泄漏的內存管理。以上內容完整繼承自 documentation/ar_EG/dependency_management.md并通過對 lib/get_instance/src/extension_instance.dart、lib/get_instance/src/bindings_interface.dart、lib/get_core/src/smart_management.dart、lib/get_instance/src/lifecycle.dart 與 test/instance/get_instance_test.dart 等源碼和測試的對照對每種方法的底層參數(shù)、內存行為與適用場景做了進一步印證與擴展。贊分享前端【免費下載鏈接】getxOpen screens/snackbars/dialogs/bottomSheets without context, manage states and inject dependencies easily with Get.項目地址https://gitcode.com/gh_mirrors/ge/getx點擊查看免費下載相關推薦GetX 依賴管理完全指南Get.put、Get.lazyPut、Bindings 與 SmartManagement 的實戰(zhàn)與源碼解析GetX 依賴管理完全指南Get.put、Get.lazyPut、Bindings 與 SmartManagement 的實戰(zhàn)與源碼解析 GetX當前倉庫前端GetX 依賴管理完全指南從 Get.put 到 Bindings 的注入、生命周期與內存管理GetX 依賴管理完全指南從 Get.put 到 Bindings 的注入、生命周期與內存管理 GetX當前倉庫 gh_mirrors/ge/getx 內前端GetX 依賴管理Dependency Management完整指南Get.put、Bindings 與 SmartManagement 源碼級解析GetX 依賴管理Dependency Management完整指南Get.put、Bindings 與 SmartManagement 源碼級解析 Ge前端創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考