android觀察者模式
Ⅰ 觀察者模式 在android中什麼時候會用到
android中注冊簡訊和聯系人的變更,就會用到觀察者模式
通過ContentProvider注冊一個observer實現的
Ⅱ Android 開發中常用到的設計模式有哪些
設計模式總共是23種，常用的有下面幾種 ：
1 單例模式，application 就是單例 可以存儲一些數據例如記錄activity的啟動數量 ；
2 觀察者模式： button的onClickListener ，監聽button的響應；
3 適配器模式 ：例如recyclerView 的adapter ；
4 命令模式： 例如開源庫eventBus ，把數據封裝好 發送出去，然後接收； 等等等等，很多
Ⅲ android用到哪些設計模式
1 Android設計模式系列-組合模式
2 Android設計模式—策略模式
3 Android設計模式系列-單例模式
4 Android設計模式系列--工廠方法模式
5 Android設計模式系列-適配器模式
6 Android設計模式系列--原型模式
7 Android設計模式系列--觀察者模式
8 Android設計模式系列--模板方法模式
Ⅳ Android-Lifecycle原理解析
Event觸發的時機：
而在androidx.activity.ComponentActivity和androidx.core.app.ComponentActivity中，該方法的實現，其實都是一樣的。
但是這兩個Activity，其實都有自己的mLifecycleRegistry對象。
LifecycleRegistry對象其實可以理解為觀察者模式中的Observable，也就是被觀察者，而LifecycleRegistry對象的創建，其實是傳入一個LifecycleOwner實現類對象，而androidx.activity.ComponentActivity和androidx.core.app.ComponentActivity實現了LifecycleOwner介面，所以傳入的是this。
LifecycleRegistry中聚合了多個LifecycleObserver，生命周期改變時，通知LifecycleObserver進行相應方法的調用。
在LifecycleRegistry類中的addObserver方法中，其實就是通過封裝LifecycleObserver生成了一個ObserverWithState對象，然後放入FastSafeIterableMap中，而FastSafeIterableMap其實就是一個自定義列表，用於保存觀察者並且可在遍歷期間處理刪除/添加。
其實在自定義的某個類去實現LifecycleObserver介面的時候，在activity中，是需要通過getLifecycle().addObserver()進行注冊的，這個過程其實就是調用了LifecycleRegistry的addObserver()方法。
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);會將LifecycleObserver對象封裝在對象中。但是這里的需要判斷是實現了哪個介面，比如androidx.activity.ComponentActivity中的構造函數中，因為是直接new LifecycleEventObserver匿名內部類實現介面對象，則isLifecycleEventObserver為true，就不會new ()，而在自定義一個類的時候，一般實現LifecycleObserver介面，則就會new ()
androidx.activity.ComponentActivity的構造函數：這里是new LifecycleEventObserver
自定義的BasePresenter：這里是實現LifecycleObserver介面
所以上面的兩種不同的實現，BasePresenter實現的是LifecycleObserver，所以這個LifecycleObserver的最終實現是。而ComponentActivity因為是new LifecycleEventObserver，所以這個匿名內部類對象就是最終實現。
在androidx.core.app.ComponentActivity的onCreate方法中，會調用
這里使用ReportFragment，如果是api29以及以上的，則可以直接注冊回調來獲取Activity的生命周期回調。如果是api29以下的，則需要手動給Activity添加一個空白的Fragment，類似於Glide監聽生命周期回調的做法。
LifecycleCallbacks的定義如上，是在ReportFragment中定義的，其實就是使用了Application.ActivityLifecycleCallbacks來實現了。
其實就是在androidx.core.app.ComponentActivity中添加一個ReportFragment，而ReportFragment的生命周期方法，其實都調用了一個dispatch方法。
所以在ReportFragment的生命周期方法，其實就會通過調用對應的dispatch方法進而調用到了Activity的getLifecycle()方法獲取到一個LifecycleRegistry對象，然後調用LifecycleRegistry的handleLifecycleEvent()方法。
這里需要事先獲取到Activity的下一個生命周期狀態，而這個狀態過程其實與Fragment的類似，都是先升序，然後再降序的一個過程。即ON_CREATE是CREATED，ON_RESUME是RESUMED，然後ON_PAUSE是變成STARTED
而上面調用的sync()方法，其實其內部會調用兩個方法backwardPass()和forwardPass()，一個是逆推，一個是順推，其實就是可以認為一個是正序，一個是倒序。
比如forwardPass()，其實其內部就是遍歷剛才緩存Observer的集合，找到每個Observer
而這里的dispatchEvent，其實就是ObserverWithState的方法，因為ObserverWithState內部封裝了LifecycleEventObserver對象，而LifecycleEventObserver對象又是封裝了LifecycleObserver對象的。
比如Activity的，其實onStateChanged是在androidx.activity.ComponentActivity的構造器中添加註冊的LifecycleEventObserver監聽接收對應的處理回調，在這里就會根據是ON_STOP還是ON_DESTROY進行回調的處理，也就是生命周期的處理。
這樣的生命周期回調，在自定義類實現LifecycleObserver介面的時候，也可以採用註解的方式注冊對應的LifecycleEventObserver監聽，這樣的生命周期的回調，其實就是回調到對應的註解和事件的方法中。這樣是採用了類似於apt註解處理器的方式，生成了對應的java類
這里需要注意，如果是自定義添加監聽的時候，是實現了LifecycleEventObserver，那麼在分發的時候，調用ObserverWithState的dispatchEvent方法去分發，就會直接回調到了自定義LifecycleEventObserver實現類中的onStateChanged中；而如果是使用LiveData添加觀察者的話，則是封裝成LifecycleBoundObserver對象，然後通過其onStateChanged方法繼續進一步的處理分發，調用到對應的Observer的onChanged方法進行最終的處理
如果這里的分發是分發到上面的那個自定義的BasePresenter，則需要經過
從上面的原理解析，可以知道，Lifecycle的生命周期的感知和分發，其實也是依賴於一個ReportFragment，這其實也是一個空的Fragment，這樣的做法，其實與Glide的生命周期的監聽是類似的做法，都是採用一個空的Fragment來監聽生命周期的變化，然後在不同的生命周期做不同的操作。
Ⅳ android設計模式中的觀察者模式能說一下嗎
/*
*觀察者模式
*定義對象間的一種一個(Subject)對多(Observer)的依賴關系，當一個對象的狀態發送改變時，所以依賴於它的
*對象都得到通知並被自動更新
*
*當然，MVC只是Observer模式的一個實例。Observer模式要解決的問題為：
*建立一個一（Subject）對多（Observer）的依賴關系，並且做到當「一」變化的時候，
*依賴這個「一」的多也能夠同步改變。最常見的一個例子就是：對同一組數據進行統計分析時候，
*我們希望能夠提供多種形式的表示（例如以表格進行統計顯示、柱狀圖統計顯示、百分比統計顯示等）。
*這些表示都依賴於同一組數據，我們當然需要當數據改變的時候，所有的統計的顯示都能夠同時改變。
*Observer模式就是解決了這一個問題。
*
*適用性：
*1.當一個抽象模型有兩個方面，其中一個方面依賴於另一方面
*將這兩者封裝成獨立的對象中以使它們可以各自獨立的改變和服用
*
*2.當對一個對象的改變需要同時改變其他對象，而不知道具體有多少對象有待改變
*
*3.當一個對象必須通知其它對象，而它又不能假定其它對象是誰
*
*參與者：
*1.Subject（目標）
*目標知道它的觀察者，可以有任意多個觀察者觀察同一個目標
*提供注冊和刪除觀察者對象的介面
*
*2.Observer（觀察者）
*為那些在目標發生改變時需獲得通知的對象定義個更新的介面
*
*3.ConcreteSubject（具體目標）
*將有關狀態存入各ConcreteObserver對象
*當它的狀態發送改變時，向它的各個觀察者發出通知
*
*4.ConcreteObserver（具體觀察者）
*維護一個指向ConcreteObserver對象的引用
*存儲有關狀態，這些狀態應與目標的狀態保持一致
*實現Observer的更新介面是自身狀態與目標的狀態保持一致
*
*
**/
Ⅵ Android 開發中常用到的設計模式有哪些
工廠模式是基礎，用的最廣泛。
適配器模式，c#有DataAdapter 類，android 有Adapter 類。
觀察者模式，涉及gui 的編程都會用到，簡單的控制項對單擊滑鼠的響應都是觀察者模式。
迭代器模式，c#中每次foreach 都是對迭代器的調用。
訪問者模式，對一個集合中的不同元素用不同的方法就會用到訪問者模式，如果對集合中的元素採用統一方法但需要不同的統一方法就是策略模式。
裝飾模式，靈活的給類添加功能。模版模式，充分利用多態大大減少了代碼的冗餘。
Ⅶ Android中常用的幾種設計模式
一.單例模式，二.建造者模式，三.觀察者模式 Observer（觀察者），Observable(被觀察者)四.工廠者模式：Factory
Ⅷ android源碼里哪些地方用到了觀察者模式
1. Subject被觀察者。是一個介面或者是抽象類，定義被觀察者必須實現的職責，它必須能偶動態地增加、取消觀察者，管理觀察者並通知觀察者。
2. Observer觀察者。觀察者接收到消息後，即進行update更新操作，對接收到的信息進行處理。
3. ConcreteSubject具體的被觀察者。定義被觀察者自己的業務邏輯，同時定義對哪些事件進行通知。
4. ConcreteObserver具體觀察者。每個觀察者在接收到信息後處理的方式不同，各個觀察者有自己的處理邏輯。
觀察者模式有什麼優點呢：
觀察者和被觀察者之間是抽象耦合的，不管是增加觀察者還是被觀察者都非常容易擴展。
根據單一職責原則，每個類的職責是單一的，那麼怎麼把各個單一的職責串聯成真實的復雜的邏輯關系呢，觀察者模式可以起到橋梁作用。
觀察者模式是松耦合的典型。
在Android源碼中，其中一個經典的使用到觀察者模式的就是Android控制項的事件監聽模型。
Ⅸ android中觀察者模式的應用場景是什麼
你說的場景是符合這個模式的：
觀察者模式的應用場景：
1、 對一個對象狀態的更新，需要其他對象同步更新，而且其他對象的數量動態可變。
2、 對象僅需要將自己的更新通知給其他對象而不需要知道其他對象的細節。
觀察者模式的優點：
1、 Subject和Observer之間是松偶合的，分別可以各自獨立改變。
2、 Subject在發送廣播通知的時候，無須指定具體的Observer，Observer可以自己決定是否要訂閱Subject的通知。
3、 遵守大部分GRASP原則和常用設計原則，高內聚、低偶合。