API文件在此。
這東西很有趣。
如果沒有它，「將共用資料擺在Application」這樣的認知或建議其實不太好用。
不過這是「我」。我認為應該要將Activity模組化後，統一套用「讀取或導入資料」的流程。
但是很多人只是需要「有個地方取用資料」。
將資料存在Application中後，用getApplication()取出即可......
很合理很有效率的想法！
但假設「不合用」或「不夠用」吧！
那我們就需要考慮一下LifeCycleCallback的用法。
這是個介面，裡面有完整的相對應了所有Activity LifeCycle的函數。
每個Activity的LifeCycle函數中，都會先在super()中執行所有被Application註冊的Callback，然後「才是」設計師複寫的物件內容。(LifeCycle不是建構子，其實設計師可以隨意調整super()執行的位置。)
(注意！是所有被註冊了的Callback都會被執行！)
(再注意！不是只有Application有能力註冊Callback，其他類別也有能力；相對的，也不是只有Application有能力反註冊Callback。因此一個Callback運作的開始和結束是很有彈性的！不會比Service差，但又比Service精準！)
所以假設......純假設.......
Callback中會在onResume啟動一個Thread，然後在onStop中將Thread關閉。(偶爾會發生從某一個Activity A返回前一個Activity時，Activity A的onDestroy會在下一個Activity的onResume之後才運作，這種時候可能會產生意外！如果允許Callback內產生多個Thread，那該關閉哪個Thread可能就是個要頭痛一下的問題了！...不是無解，也不複雜。)
這樣就可以達到讓背景任務可以順利跨Activity運行、而且又能對應當下的Activity產生變化。(例如視頻撥放的功能，可以將Activity視為「視頻線上存放點」的切換或記錄器，而下載功能和下載資料緩存則建立在Callback中，等於達到常駐的效果，而不會隨著每個Activity的啟動或關閉而有資源管理的問題。...這只是初步構想，還沒實驗過。)
再假設......純假設.......
每個Callback類別都有對應的Interface可以讓Activity實作，然後在Application中註冊多個Callback，只是每個Callback在執行對應的生命週期函數以前，都會檢查傳入的Activity是否有實作自己對應的Interface...如果沒有就不執行，那就可以大幅簡化Activity要處理的工作。
但對我來說，這個介面真正實用之處在於它讓一個跨「多Activity」甚至「多APP」的Thread可以精準的知道「何時有Activity可以取用」。
舉例...
就假設要設計個最簡單的APP內建有獨立邏輯和功能的計時器吧！
計時流程如果要精準可靠，那就不能因為Activity切換而損失效能或時間失準。(注意！它有獨特邏輯，所以不是直接把手機時間拿出來顯示就好。)所以不能採用「每個Activity獨立啟動Thread」的做法。
但在UI1中，時間顯示在右上角，在UI2中，顯示在正中央，而UI3卻又顯示在左下角...所以上面說要記得設定一個Interface讓每個Activity設定自己顯時間值的方法，如果有這樣做，就可以將這個Thread寫在一個Callback中，讓Application在產生Acitivity前就先運行這個Thread。
研究完用法思考了一下...
凡事要在背景常駐處理的都寫個Service...會不會對系統負擔太大呢！
畢竟Service是個功能完整的Context！但LifeCycleCallback只是個簡化介面的實作。
如此一來，Android預設的幾個主要功能類別其實就越來越模糊了！遵守Activity、Service、BroadCast...這類的類別去設計規劃APP的架構，可能反而會是個阻礙。
但同樣的理由...當一隻APP背景存在數十個額外設定的Callback時，效能是不是一樣會變差？
所以設計一項服務真的要把各個功能切割成多個APP(其中有一個是所謂的Main APP)來完成，這樣每個APP前景背景都會變得很單純穩定！
這東西很有趣。
如果沒有它，「將共用資料擺在Application」這樣的認知或建議其實不太好用。
不過這是「我」。我認為應該要將Activity模組化後，統一套用「讀取或導入資料」的流程。
但是很多人只是需要「有個地方取用資料」。
將資料存在Application中後，用getApplication()取出即可......
很合理很有效率的想法！
但假設「不合用」或「不夠用」吧！
那我們就需要考慮一下LifeCycleCallback的用法。
這是個介面，裡面有完整的相對應了所有Activity LifeCycle的函數。
每個Activity的LifeCycle函數中，都會先在super()中執行所有被Application註冊的Callback，然後「才是」設計師複寫的物件內容。(LifeCycle不是建構子，其實設計師可以隨意調整super()執行的位置。)
(注意！是所有被註冊了的Callback都會被執行！)
(再注意！不是只有Application有能力註冊Callback，其他類別也有能力；相對的，也不是只有Application有能力反註冊Callback。因此一個Callback運作的開始和結束是很有彈性的！不會比Service差，但又比Service精準！)
所以假設......純假設.......
Callback中會在onResume啟動一個Thread，然後在onStop中將Thread關閉。(偶爾會發生從某一個Activity A返回前一個Activity時，Activity A的onDestroy會在下一個Activity的onResume之後才運作，這種時候可能會產生意外！如果允許Callback內產生多個Thread，那該關閉哪個Thread可能就是個要頭痛一下的問題了！...不是無解，也不複雜。)
這樣就可以達到讓背景任務可以順利跨Activity運行、而且又能對應當下的Activity產生變化。(例如視頻撥放的功能，可以將Activity視為「視頻線上存放點」的切換或記錄器，而下載功能和下載資料緩存則建立在Callback中，等於達到常駐的效果，而不會隨著每個Activity的啟動或關閉而有資源管理的問題。...這只是初步構想，還沒實驗過。)
再假設......純假設.......
每個Callback類別都有對應的Interface可以讓Activity實作，然後在Application中註冊多個Callback，只是每個Callback在執行對應的生命週期函數以前，都會檢查傳入的Activity是否有實作自己對應的Interface...如果沒有就不執行，那就可以大幅簡化Activity要處理的工作。
但對我來說，這個介面真正實用之處在於它讓一個跨「多Activity」甚至「多APP」的Thread可以精準的知道「何時有Activity可以取用」。
舉例...
就假設要設計個最簡單的APP內建有獨立邏輯和功能的計時器吧！
計時流程如果要精準可靠，那就不能因為Activity切換而損失效能或時間失準。(注意！它有獨特邏輯，所以不是直接把手機時間拿出來顯示就好。)所以不能採用「每個Activity獨立啟動Thread」的做法。
但在UI1中，時間顯示在右上角，在UI2中，顯示在正中央，而UI3卻又顯示在左下角...所以上面說要記得設定一個Interface讓每個Activity設定自己顯時間值的方法，如果有這樣做，就可以將這個Thread寫在一個Callback中，讓Application在產生Acitivity前就先運行這個Thread。
研究完用法思考了一下...
凡事要在背景常駐處理的都寫個Service...會不會對系統負擔太大呢！
畢竟Service是個功能完整的Context！但LifeCycleCallback只是個簡化介面的實作。
如此一來，Android預設的幾個主要功能類別其實就越來越模糊了！遵守Activity、Service、BroadCast...這類的類別去設計規劃APP的架構，可能反而會是個阻礙。
但同樣的理由...當一隻APP背景存在數十個額外設定的Callback時，效能是不是一樣會變差？
所以設計一項服務真的要把各個功能切割成多個APP(其中有一個是所謂的Main APP)來完成，這樣每個APP前景背景都會變得很單純穩定！
沒有留言:
張貼留言