[2017/8/24]
現在發現其實Android有些更簡單的機制可以處理這種狀況...
ActivityLifecycleCallBacks...這東西的使用機制比較複雜。
或是LifecycleObserver...但這東西我沒實用過，我習慣使用LifecycleCallbacks
[2017/8/24 !!]
==========================================================
寫一個Activity或Service，然後在onCreate()中加入Log訊息，會發現當「程式/APP」大到某個程度時，會經常(其實是變成例行公事)一個Activity或Service連續開啟(執行「onCreate()」)兩次。
雖然第一次開啟的Activity/Service最後都會關掉(都會立刻轉到「onDestroy()」)，但是程式整體結構會變得很難掌控。
開啟不是開啟，關閉不是關閉，如果有別的程序──例如等一下會講到的執行緒──要去判斷/讀取這些Activity/Service內的參數時，可能就糗了......
再講明白一點：Thread啟動、將Activity/Service當作傳入引數要求Thread判斷裡頭的參數......結果不到一秒鐘的時間，Activity/Service已經被關閉，但Thread才剛完成「生成」和「啟動」而已，結果進入執行緒的任務中要開始工作時要去判讀Activity/Service的參數......當機！
有些人會認為應該要在執行緒中加入極為精密、精準的判斷邏輯，避免掉這樣的錯誤發生，「這才是程式設計。」
我不否認「程式設計本來就是門苦工」，產品使用者不曉得在智慧型手機上按一下螢幕、或在電腦上點一下滑鼠，這個「按」與「點」，本身就包含了無數行程式碼。(像寫這個的工程師們致敬。)
但這不代表我們應該只認可「苦工」，而放棄、或否定尋找其它秘訣的機會。
(而且：最苦工的方法想也知道會讓Thread效率變差。)
其實解決方法很簡單，(這部落格講的是Java/Android，所以這些經驗主要應用在Java上，)基本上已經摸過一定程度的Java工程師都知道在Thread中的迴圈要用一個外面可以控制的參數A來決定Thread是否要繼續執行。
這個參數A可能是個Boolean值，程式進入onCreate，則Boolean轉為True，程式執行onClose，則Boolean轉為False。
但僅僅是這樣還不夠解決問題。(像如果用Activity或Service本身的物件是否還存在、是否為Null來做判斷.......抱歉！沒成功過。)
可是真的要解決問題也非常簡單......
Thread有run()函數，這個函數內的程式碼可以被無限執行、並同時排程。
在run()的最開頭，只要用排程的方式先讓它「休息0.5秒」，等到「休息0.5」秒結束後，真正要值行任務內容時，參數A已經變成了False，這個Thread自然也會跳入關閉狀態、然後乖乖等著被回收，不會干染下一個Activity/Service啟動並產生真正穩定的Thread。
應該不會有人會問「0.5秒太短了，不管用，該怎麼辦？」........
================================================
這篇文講的東西很碎，但我以為Java本來就是這樣的東西。它的學習門檻很低，應用門檻也很低，要用它的人、可以用它的地方其實都很多。
但是它的門檻低，後面卻有一階比一階高的樓梯，沒有多種其他層面知識的人跳進來學Java，其實很快就會遭遇障礙。
把程式設計的基礎，例如迴圈和判斷式的使用、物件的設計等很基本的東西講的淺白易懂，然後接下來馬上轉為「基礎教完了，要開始把你們當成專業級的對待，」然後下一個教程、範例、或項目(隨便怎麼稱呼)，馬上開始用「我只講這麼多，剩下的要自己理解自己推敲」的態度........所以Java程式設計師能夠活過「初階」的很少，特別是這種語言標榜著所有人都能學。
孔子講「舉一隅不以三隅反者，吾未往也。」這是舉一反三的典故。
聽起來很了不起、很霸氣，但如果今天的「教學」都用這種態度，那小學生學會九九乘法表的一到三之後，豈不是要自己歸納出剩下的四五六七八九的訣竅？
整體的知識水平要提升、科技要進步......這種態度(期望丟出去的教學能夠有最大話的回收)就有嚴重的問題。
所以我開這個部落格、分享這些很碎很碎的技巧。
除了因為還是會有人需要用到，也是為了讓那些沒辦法第一步就達到舉一反三的人可以達到有能力舉一反三。
現在發現其實Android有些更簡單的機制可以處理這種狀況...
ActivityLifecycleCallBacks...這東西的使用機制比較複雜。
或是LifecycleObserver...但這東西我沒實用過，我習慣使用LifecycleCallbacks
[2017/8/24 !!]
==========================================================
寫一個Activity或Service，然後在onCreate()中加入Log訊息，會發現當「程式/APP」大到某個程度時，會經常(其實是變成例行公事)一個Activity或Service連續開啟(執行「onCreate()」)兩次。
雖然第一次開啟的Activity/Service最後都會關掉(都會立刻轉到「onDestroy()」)，但是程式整體結構會變得很難掌控。
開啟不是開啟，關閉不是關閉，如果有別的程序──例如等一下會講到的執行緒──要去判斷/讀取這些Activity/Service內的參數時，可能就糗了......
再講明白一點：Thread啟動、將Activity/Service當作傳入引數要求Thread判斷裡頭的參數......結果不到一秒鐘的時間，Activity/Service已經被關閉，但Thread才剛完成「生成」和「啟動」而已，結果進入執行緒的任務中要開始工作時要去判讀Activity/Service的參數......當機！
有些人會認為應該要在執行緒中加入極為精密、精準的判斷邏輯，避免掉這樣的錯誤發生，「這才是程式設計。」
我不否認「程式設計本來就是門苦工」，產品使用者不曉得在智慧型手機上按一下螢幕、或在電腦上點一下滑鼠，這個「按」與「點」，本身就包含了無數行程式碼。(像寫這個的工程師們致敬。)
但這不代表我們應該只認可「苦工」，而放棄、或否定尋找其它秘訣的機會。
(而且：最苦工的方法想也知道會讓Thread效率變差。)
其實解決方法很簡單，(這部落格講的是Java/Android，所以這些經驗主要應用在Java上，)基本上已經摸過一定程度的Java工程師都知道在Thread中的迴圈要用一個外面可以控制的參數A來決定Thread是否要繼續執行。
這個參數A可能是個Boolean值，程式進入onCreate，則Boolean轉為True，程式執行onClose，則Boolean轉為False。
但僅僅是這樣還不夠解決問題。(像如果用Activity或Service本身的物件是否還存在、是否為Null來做判斷.......抱歉！沒成功過。)
可是真的要解決問題也非常簡單......
Thread有run()函數，這個函數內的程式碼可以被無限執行、並同時排程。
在run()的最開頭，只要用排程的方式先讓它「休息0.5秒」，等到「休息0.5」秒結束後，真正要值行任務內容時，參數A已經變成了False，這個Thread自然也會跳入關閉狀態、然後乖乖等著被回收，不會干染下一個Activity/Service啟動並產生真正穩定的Thread。
應該不會有人會問「0.5秒太短了，不管用，該怎麼辦？」........
================================================
這篇文講的東西很碎，但我以為Java本來就是這樣的東西。它的學習門檻很低，應用門檻也很低，要用它的人、可以用它的地方其實都很多。
但是它的門檻低，後面卻有一階比一階高的樓梯，沒有多種其他層面知識的人跳進來學Java，其實很快就會遭遇障礙。
把程式設計的基礎，例如迴圈和判斷式的使用、物件的設計等很基本的東西講的淺白易懂，然後接下來馬上轉為「基礎教完了，要開始把你們當成專業級的對待，」然後下一個教程、範例、或項目(隨便怎麼稱呼)，馬上開始用「我只講這麼多，剩下的要自己理解自己推敲」的態度........所以Java程式設計師能夠活過「初階」的很少，特別是這種語言標榜著所有人都能學。
孔子講「舉一隅不以三隅反者，吾未往也。」這是舉一反三的典故。
聽起來很了不起、很霸氣，但如果今天的「教學」都用這種態度，那小學生學會九九乘法表的一到三之後，豈不是要自己歸納出剩下的四五六七八九的訣竅？
整體的知識水平要提升、科技要進步......這種態度(期望丟出去的教學能夠有最大話的回收)就有嚴重的問題。
所以我開這個部落格、分享這些很碎很碎的技巧。
除了因為還是會有人需要用到，也是為了讓那些沒辦法第一步就達到舉一反三的人可以達到有能力舉一反三。
沒有留言:
張貼留言