Android手機上GCM的設定方法

【注意！如果是在找iPhone，或純網頁版的GCM功能，建議別在我這篇文章裡浪費時間了，除非你搞不懂Key和SenderID之間的關係，弄不懂自己到底哪裡出錯。】

所謂的GCM，就是Android會時不時從網路上收到由「Google系統」所發出「針對你這支手機、要給你的資訊。」

它的結構並不難！只是有些資訊因為版本不停更換，不管是API說明，或是Console端介面，所以說明變得越來越模糊籠統，對新人來說越來越不友善。

但GCM只是種「如何實現非Google系統也能針對特定手機發送針對這支手機所發出的資訊」的機制，它的具體應用內容目前並沒有太多規範與限制！

所以要試著把「自己想做的事情和應用」給排除、專注在理解「發送GCM」上，反而會容易理解GCM的機制與應用方法



雖然網頁教學強調「Server Key」和「SenderID」是應用的基礎，但......

「Google Developer Console端設定」才是這項功能的核心！

(官網上的教學完全假設使用者已經對Console端運作的邏輯和每個欄位每個值得意義滾瓜爛熟......)

每一支GCM功能都要在Console端設定一項專案！

意思是說...一支網頁如果有發送GCM功能，它是否只能針對一項GCM功能？一支手機APP一次是否只能囊括一項GCM功能？...以上答案都是「不」！

理論上來說，一支APP裡面同時可以應用到很多個GCM功能。

比如A購物應用和B購物應用都有自己的GCM內容，能否做一支APP同時把兩支應用的GCM都改由同一支APP接收？(「我不想要購物，但我想要知道廣告消息？」)...

理論上來說，可以！

(2015/12/23：我自己是有測試過，成功了。但未來是否會針對這項特性做出限制？...不保證！)



GCM服務在Google Console上可以獨立成為一項專案嗎？

理論上來說可以，只是不知道為何，我連測試它的動力都沒有。可能是因為我是使用GAE平台來施作Service，而我的GCM服務就直接附屬GAE專案在裏頭。但對不使用GAE的使用者來說，這樣做可能反而很合理。

這是Google Console設定的邏輯。一項專案可以單純的只是一串Google API應用權限的集合，設定完之後任何網頁APP或手機APP都能使用這項專案的權限設定。

再講精準一點、講的懶人一點，一支手機APP中，可以使用兩組以上的Google API專案？...答案當然也是「可以」。(關鍵點在這組專案的這項功能是否讓特定APP使用。如果不行？那就是沒有權限！如果將特定APP的權限加入後，自然就可以使用了。)



這是很多菜鳥在思維跟管理上會犯的錯。(對！我是菜鳥！)

GCM服務並不屬於任何Web Service或是APP，而是Web Service或APP需要使用特定GCM專案時，需要將自己的權限加入GCM服務專案中。

將Web Service加入GCM服務專案後，就會產生一組Server Key。這組Key就是Authorization欄位中所要帶入的參數值。(我不會用XMPP，所以那段怎麼做，請自行研究一下。)

至於APP端需要的SenderID，其實就是這個GCM服務專案的專案ID！

(2015/12/23：不知道為何，中文版的Console上，每個專案都有兩組專案ID，一組是文字，另一組則是編號。這地方要取用編號。)

如果Service Key跟SenderID來自不同的GCM專案，就會產生「MismatchSenderID」的結果！

如果為了方便開發，APP端跟WebService可能會分頭進行，為了測試就用GAE設置了測試用的簡單WebService，這時候就很容易忽略了這個步驟.......

因為是GAE，所以一定會在Console上設置一組Google API專案。就很順手的把GCM服務也歸屬在這項專案中，也從中取得ServiceKey和加入APP權限......但不知道為何，使用的SenderID還是正式WebService的專案ID。



對.......

其實這整篇文只是想解釋MismatchSenderID造成的原因。

檢查參數內容是否是同一個物件實體？

假設物件A內有兩個參數，分別是字串B和長整數C。

物件A生成兩個實體參數，分別是實體一和實體二......

可以將實體一和實體二的B和C都設為同樣的數值內容，但如果用if(實體一 == 實體二)來檢查結果...

在Java中一定會得到false。

除非逐一針對B和C參數比對，不然永遠都會是false，──但這不是重點！



只要善用這個特性，可以輕鬆地完成「資料是否有更新」的比對。



最近碰到一個功能，(我保留了細節，只講大概，)要在Activity A中用網路去查詢資料，查詢完後將資料在Activity B鐘用列表(ListView)顯示，並且用彈出式視窗告知使用者「現在有幾筆資料」，然後在Activity C中可以看各筆資料的詳細內容.......並且重新設定查詢條件後再次查詢、查詢完後退回「上一頁(也就是Activity B)」。


用彈出式視窗告知使用者「現在有幾筆資料」是後來追加的功能，所以我設計的簡單，就是在Activity B的onResume中把列表的資料數顯示出來就是...

但問題是在Activity C中，使用者大部分只是單純的看完細節就退回Activity B，並不會重新設定查詢。

所以「判斷是否有重新設定查詢」仍是有必要的一件事。



方法很簡單。

資料要能跨三個Activity間傳遞並操作，方法就是使用一個static型態的ArrayList參數。

(在同一個APP中只要這樣做即可，Intent是很多餘的東西。)

每次只要有「查詢」，就會將這個static ArrayList參數重新產生一個實體。

然後在Activity B中設置一個物件類別專屬的ArrayList參數三，並在onResume中做if(實體一 == 實體二)的檢查，就可以快速精準地知道「使用者是否重新使用過查詢功能」。

(怕有人不知道：通常，將static ArrayList設為實體一，可以省去檢查實體二是否為null的動作。)



但如果ListView的Adapter直接使用參數三，這個方法「可能」會導致APP當機。

怕有人不知道......

安全的程序應該是再產生ArrayList參數四，然後用addAll()的方式將參數三內的資料全部倒進參數四中，然後再使用參數四來產生ListView的Adapter。

(資料量不要太誇張...一般來說這個動作是不吃什麼效能的。如果資料量很誇張，擔心記憶體，不要擔心效能。)

顯示圖片所遭遇的OOM...「原來要用WebView」

一個APP在Android上可以使用的記憶體空間最大為24MB。

但一張圖片轉成Bitmap「物件」後，實際大小會是檔案的四倍以上！

也就是說如果圖片有N張、總大小為4MB，那它轉為Bitmap物件後在記憶體中吃掉將近16MB的大小。

這時候如果加上APP本身其他功能在記憶體中佔的大小，很容易會發生「Out Of Memory」的Error！



或許有人會想：但Bitmap物件在Android APP中無法顯示或作用，需要丟給ImageView之類的UI元件後才會顯示，或許這些UI元件並不會保留Bitmap物件、會將它快速丟入Garbage回收列中。

如果是這樣...對一張已經轉給ImageView顯示的Bitmap進行recycle()指令應該會成功才對！但實際上log訊息卻跳出錯誤碼「不能對一張ImageView正在執行顯示的Bitmap執行recycle()」。



也就是說...

顯示圖片要遭遇的問題並不單單是「將圖檔從resource狀態轉成Bitmap的過程」，轉成Bitmap後存在記憶體中的實際大小本身就是問題的根源。



先解釋一下關於：將圖檔從resource狀態轉成Bitmap的過程...

Bitmap物件並沒有建構子，必須使用內建的static型態參數createBitmap()來產生，或是使用BitmapFactory物件的static型態參數decodeStream。

關於後者，顧名思義就是使用Stream來將resource檔轉成InputStream，然後........(不知道怎麼形容這個過程，反正就是接收Stream資料串就是了。Stream的資料串吐出資料的「開啟」機制一直是我覺得這個物件很「謎」的地方。大家可以直接點連結參考一下怎麼用Stream轉成Bitmap物件。)(連結一)

ImageView有setImageResource()的功能，但這功能本身也是將圖檔從resource索引值轉出成Bitmap物件，它的過程和會遭遇的問題跟上面在討論的並沒有不同。

網路上常見的「標準」解決方法(連結一)，其實僅僅只是將圖檔製作縮圖，取得一個比較小的Bitmap物件。



但...「挑戰」之所以是「挑戰」，就是因為永遠會有人、會有狀況來測驗標準/穩定方法的極限！

如果APP的程序中存在著一次要顯示/讀取多張大尺寸Bitmap，則這個方法(連結一)的穩定性會變得跟紙糊的沒兩樣！

大家用動態的流程想像一下...

假設我用縮放尺寸A來讀取的圖片1，然後將圖片1設給ImageView1，接著我要用相同的縮放尺寸A來讀取圖片2.......抱歉，OOM了！因為記憶體的環境已經跟讀取圖片1時的環境不同了！而這樣的環境已經無法用縮放尺寸A來讀取圖片2。



我曾經試過動態的變化縮放尺寸，讓每一張圖片都有「適合」自己的數值。

結果圖片的縮放品質會開始無底線的探底！

如果圖片是「不太講究品質的小icon」，那OOM的問題根本從一開始就不會發生！也就是說會發生OOM，一定都是解析度要講究、內容必須要可以讓使用者精確閱覽的圖片！



所以用Stream來縮放圖片(連結一)雖然符合Java解決問題的精神原則，但實際上根本沒有解決問題！

(其他還有一些「幻燈片/跑馬燈切換」的方式來展示多張圖片，但這都是從根本上限制「APP設計」，碰到「不行！我們就是要同時展示多張圖片！」時，依賴這種技巧等於讓程式設計師陷入一個叫天天不應、求地地不靈的死局。)


真正治標又治本的方式，就是製作一個存在手機端的小網頁，然後將圖片插入這個網頁中，在轉到WebView上顯示！(連結二)



不要聽到WebView就啞然失笑，「用WebAPP？效能不是很差嗎？」

這個方法除了圖片的顯示以外，其他都還是Java Code，效能等同於Native APP！



只是要注意一些小細節：

1.不要使用String.format來組成Html Tag。(執行後，經常會跳出Error，告訴我「Html少了個「"」。)
2.連結二中是Asset資源圖檔的版本，res中的resource資源檔有不同的file路徑寫法。(連結三)

3.如果有辦法精確控制WebView大小會更好，也可以輕鬆顯示多張圖片。(我有自己的秘訣，但.....解釋起來挺複雜的。如果能夠從「用Java動態設置」為方向去思考，會發現不難。)

關於Thread多線程

過去幾個禮拜在做「在Google Map上記錄使用者行走路徑」的功能...

(基於業務需求，不能附上詳細的程式碼。)

製作的過程中碰到最重要的幾個問題：

1.GPS的精準度和效率。
2.如何在行走過程中，開啟和關閉地圖，(地圖只是記錄行走路徑的附屬功能，可以獨立開啟跟關閉，)但又不會影響紀錄的效率和整體操作的流暢性。
3.紀錄行走的路徑資料量吃光了記憶體。

關於1，結果有點無解。

關於3，用即時的SQL讀寫來解決。

關於2，解決的過程中刷新了我對Thread的應用和設計心得.......




Thread的意義在於「不要讓單一項工作/任務吃光所有CPU的運算資源」，所以它會建議設計師在迴圈或程式碼中埋下Thread.sleep，來讓目前的工作/任務先暫時停止工作、把結果保留下來，然後處理其他工作。



我個人接觸Thread的初體驗是遊戲設計中的「畫面更新」功能。

畫面更新速率要穩定！(不穩定可以視為Thread設計失敗！)

但這是「畫面更新」的要點，而不是「Thread設計」的基本技巧，導致我一直以來在Thread的設計上，都會將Thread設計得過於僵硬強勢！──Thread結構都類似「畫面更新」的「無止盡的執行下去、直到程式關閉為止。」(這樣的Thread執行或許很穩定，但卻很難關掉、很難即刻反映APP的生命週期或開關。)

我想這是因為遊戲中都會將要運算和更新的資料量控制在一個穩定的範圍內，例如敵人數量要穩定、圖層數量要穩定。

所以不管是遊戲數值的運算、或畫面的更新，這兩個Thread的運算效率通常都會很穩定。(偶爾會有「爆擊」、「連續技」、「超大範圍攻擊」等事件發生，.......能否處理好就看工程師的功力了。)



但這次在更新地圖路徑的繪圖需求上，卻是完全彈性的！

資料量從一開始可能十筆二十筆，在五分鐘後會爆增到一百筆兩百筆，再十分鐘後又會增加到八百筆九百筆。

資料的量非常不穩定，所以「遊戲軟體」中「畫面更新」的Thread設計原則必然不適用！

將「數據運算」和「畫面更新」做成兩個完全平行、且穩定持續運作的Thread並不適合在這個運算資料量一直增加的設計中。



所以兩個Thread要從平行改為主從式設計。

一個Thread為穩定持續運作，另一個則被前面的Thread動態的生成啟動或關閉，...但在我這次的工作中，只有啟動、不需要關閉。(「畫面更新」Thread不需要循環執行，單一的功能執行完、則整個Thread關閉丟入記憶體回收列中.....，下次要更新畫面時，重啟一個Thread。)

這還是需要一些參數上的設計，例如「畫面更新開始」和「畫面更新結束」，畫面更新如果開始，就主Thread就不會再發出畫面更新的Thread，直到畫面更新結束為止。

(其實這是可以同一個參數解決的。)



這樣設計後，畫面的更新效率或許不太理想，時不時「使用者當下位置」跟「路徑線」會有點差距.......

但APP的整體操作完全不受影響。

正規的使用Handler更新畫面並且避免Handler Leaking發生

【可以先參考官方教學與範例。】

真正讓我想出不用Handler、而用BroadCast的方式更新畫面的原因...在於Handler很難用！



產生Handler的程式碼如果不是直接在Activity類別內，這個Handler最後不被執行的可能性...八成！

最發生的現象就是...在一個獨立在Activity外寫成的Thread/Runnable類別內，有一段生成/宣告Handler的程式碼，不管這段程式碼是宣告一個匿名物件、或確實寫一個class，也不管它寫在run()內或run()外，.......經驗來判斷是：「這個Handler一律都不會被執行。」。

Android開發者稱這個現象叫做「Handler Leaking」。

在Log訊息中可以看到系統發出關於這個現象的警告，意思大概是說「這個Handler不是在Activity內產生的......」

這個「直接在Activity類別內」...意思是說連Fragment和View本身也涵蓋在其中！

其他可能會發生的現象還有...在Activity中寫了個匿名物件，內有產生Handler的程式碼，但這段程式碼卻不是在Activity內被執行的！

(我個人模糊的形容方式是：要滿足以下兩個條件才「絕對」不會發生HandlerLeaking：

1.類別在Activity中設置為內類別/巢狀類別。2.在Activity中宣告產生實體物件，包含匿名物件。

門檻其實挺高。)

雖然官方的教學範本裡面有說到要在Handler的建構子中傳入Looper.getMainLooper()，但這個方法也不管用！(沒有成功過！)



所以要用自己的變化與創意補足這塊了！

網路上看到過很多人使用Activity內增加Inner Class擴充Handler的方式來處理這個狀況，但我不採用。

因為這變成在Activity外使用Handler時，還要取得Activity當作參數傳入這個自設的Handler類別的建構子中。

現階段沒有辦法直接做到「隨意的產生Handler，然後又隨意決定Handler的功能，」只能做到最接近、最不花費力氣的方式...

這兩個介面/函數和Handler仍然需要在Activity中實作，但全部只有21行程式碼，而且只要做一次。

然後用上圖的方式，就可以在任何可以取道Context或Activity的地方產生帶有特定效果的Handler。




如果只是單純的要傳一個數值參數，用emptyMessage(int what)即可，為何還要有個Object參數？

仔細想想，Message類別中帶有一個Object參數讓使用者可以隨意傳入物件，真正的意義恐怕就在這裡。

ImageView或任何View無法將圖檔設為資源檔

最近在工作上遭遇到一個狀況，就是要在畫面上用「跟螢幕等寬」的方式顯示一張長度超過「七吋平板」可以顯示能力的圖片。

顯示圖片本身還是小事，問題在某些手機上這張圖片會消失......

ScrollView的長度有順利展開到相對的長度，所以不是資源檔匯入失敗的問題。



用ImageView設定Resource，或是用一般View、一般ViewGroup、LinearLayout、FrameLayout、RelativeLayout，都無法讓圖片順利顯示在螢幕上。

最後卻是用將這張圖片切割成三張的方式，才讓這張圖順利顯示。



資源檔匯入的時候，顯然會使用比較獨特的記憶體區塊，某些手機將這個區塊畫的比較小，所以當圖檔過大時，要不是破損、要不就是整張不匯入...

這次有寬高，但圖片無內容，應該就是種「破損」。

這些年在Android上，我看過的網路傳輸並接收資料的模組架構，還有Intent、SingleTon模組、和Adapter機制

【我不是要寫文教大家怎麼去POST/GET資料，也不是要自以為是的跟大家分享Socket經驗(雖然我很想......)，我是想要分享我在設計Android APP時，設計「接收資料並呈獻到畫面上給使用者看」的過程中遭遇到的種種狀況。

這文對工程師意義可能不大，因為裡頭會談到一些Android架構的限制，工程師可能比較好奇怎麼凌駕這些限制，但我個人選擇和這些限制和平共處，──所以我的經驗和意見可能是不中看也不中用，但對非技術底的人來說可能比較有價值，例如設計或PM，因為在構思功能和流程時，不需要太多知識與經驗也知道要避開這些現象。】



Android的問題在於除了「Activity生命週期」的幾個階段被底層呼叫後，畫面一旦生成就不能隨便更動。要更動就必須要經由Handler、BroadCastReciever、或另起Activity。不然就必須要使用本來就可隨意更動的SurfaceView。

所以當畫面原本設計目的就是「不時要被網路資料更動」時，...注意！網路資料進出的時間點本來就不可能會等APP的「生命週期」，結果不是造成APP掛點，不然就是畫面跟實際接收到的資訊有落差。(前者是因為在生命周期外更動畫面，後者是因為生命周期外接收到的資訊不會反映在畫面上。)

要處理這個，我見到的兩大派作法：
1.大量使用Adapter，將資訊裝入Adapter中後進行簡單的「自動更新」。(給非技術底的：如果簡單描述Adapter，它就是個會針對資訊的內容快速產生畫面的工具，例如一百筆記錄了連絡資料的JSON。它有些限制，例如每筆資料間要最低限度的共通點、針對每筆資料產生的畫面通常也只能操做該筆資料...等。說它簡單，因為要啟動它的「自動更新」很簡單，而且「自動更新」的內容要多複雜就可以有多複雜，幾乎可以完全無視起動的時機點──因為系統會自動幫APP管理。)
2.在上一個Activity中使用一個Thread確保網路資料都已經接收完畢後，再啟動新的Activity、並直接使用剛接收到的網路資訊來決定畫面內容。(給非技術底的：這些字數完全無法描繪它實際上需要做的事情。)

第一種是Google在設計Android基本功能時常用的手法，不管是GMail、Google Play、或一些管理功能這類進行「系統控制」的「APP」。(對！一樣是給非技術底的：那些都是APP，Android底層是Linux，本來是只有文字的東西而已，凡是圖形介面、包含解鎖畫面都是種APP。)連FaceBook也是使用這樣的方式製作最新、最穩定的APP版本。(注意！這真的是最穩定，而且可能是最完美的APP型態。)

第二種在許多客製化打造的APP中經常使用。例如時不時接收網路傳來的JSON資料，然後將它分散到畫面上的數塊文字訊息欄中，或是變換背景顏色，甚至野心很大的更動它的佈局。



關於第一種，參考GMail、Google Play、還有FaceBook就可以知道這種設計方式的最大特徵。它們的畫面並不單調，程式不管是使用者體驗或功能都可以維持一定的穩定順暢。反觀第二種，就很考驗設計者和QC的耐心了！

以下是個範例客題：如果畫面被要求動態的、隨機的產生無數個欄位，每個欄位的內容功能都要隨網路資訊而有不同變化，而且網路資料的量、規則都無法預估.......

如果是第一種設計法，只要確保Adapter有呈現每種資料的能力，而網路接收資料正確、傳遞給Adapter的順序也如網路資料預估.......然後要求系統去自行「更新」即可。不管重新接收多少次資料、刪除單筆、插入多筆.........，都可以維持這個簡單的線性流程。(操作資料......操作一次、操作兩次、操作三次......操作N次，然後要求Adapter更新內容，一定可以精準的看到結果。)

如果是第二種設計法，就要先把畫面維持一個空白的大框架，然後接收完網路資料後開始數算數量，然後預估會需要在大框架中塞入幾個欄位，接著就開始逐一生成欄位。........

聽起來沒什麼、兩種差異不大，問題是用第一種方案中一行程式碼就可以做到的事情，為何要像第二種方案這樣寫數十、甚至數百行程式碼呢？

很多專案遲遲無法收尾，就是因為工程師被迫使用第二種。最後不管他們寫再多程式碼，都會發生「為何第一次新增條目時不會當機，刪除後新增就當機了，你的新增功能真的有做好嗎？」這類的Bug。因為第一種方法強制要求APP的畫面一律跟資料看齊，而第二種方式其實是寫很多修改畫面的程式碼，然後隨時判斷資料內容來決定要使用哪段程式碼修改畫面，只是這些方法即使相似處很多，但不是「永遠不夠用」，不然就是「會打架、會矛盾、會互扯後腿」。



另一個問題是我身為一個半路出家的技術狂最感興趣的現象。就是程式的「穩定壽命會縮短」。(以下所說其實已經是種理論性的天馬行空胡亂講...只是因為真的發生過，所以我寫下來。)

Activity是Android切割畫面與功能分界的一種機制，意義就有點像網路的「頁面」。

即使是同一個Activity之間，也無法直接交換資料，需要經過一些比較繁瑣的方式去設計它。

例如Intent，即使預設目的並不是要夾帶「畫面資料」，但很多人都會選擇這樣設計它。將下一個畫面的「標題」、「背景」...等資訊夾在Intent中，發送給下一個Activity。聰明的人、經驗夠的人都一定會經歷到Intent沒有忠實的把所有資訊傳給下個Activity的現象，例如前十筆資料都有帶到，後十筆資料就不見了。(這可能是因為Intent是用C/C++實做的，它並不是完美的物件導向定義出來的物件，即使它有嚴謹的建構子，但它其實會被轉換成非物件的型態在Activity和系統間傳遞，轉換回物件時，資料就消失在記憶體中了。──歡迎技術底更強的人吐嘲！)

所以老手應該都會使用Intent以外的方法傳遞資料。最常見的就是SingleTon。

所謂的SingleTon，就是在記憶體中畫置一塊區域，存放一個物件，然後這個物件中有存放資料的功能。因為這個物件嚴格說起來是「人人(任何Activity)都可以摸到裡面，所以只要知道這個物件存在的都可以往裡面塞資料、取資料」。

如果看過我其它文章的人就知道：使用SingleTon的人不見得很懂物件導向，他們只是覺得短短幾行程式碼可以有這個功用，就把它拿來用吧！

不管是SingleTon，或任何一種第二類資料傳輸法，理論上都會有個風險，就是記憶體會不夠用、記憶體管理會出錯。

不懂電腦原理的人一定會質疑「記憶體需求不都開好、規畫好，怎麼會不夠用？不夠用不能改良嗎？」

事實是：資料在記憶體中不會自己判斷自己是不是「已經不被需要了」，必須要程式要求它「請從記憶體中消失」，或是設計者關機斷電。一般來說，C/C++程式設計師都要自己管理這個動作，自己產生的、自己主動讀取的取用的資料，都要自己下指令、寫程式把它們清除；但Java/Android工程師不是如此，只要操作一種類似「索引值」的東西，系統內的某個特定程式就會定時按照索引值來清除記憶體內不要的資料。

不是開玩笑，真的有一支專門的系統程式負責這個工作。

但某些因素讓這支程式工作起來不太精準，經常會發生已經被排入要被清除的資料，清除程式竟然認為自己不可以清除它，但也不知道該拿它怎辦.........(或許是「索引值」管理程式出問題？或其他？)當這些「不知道該怎辦的資料」在記憶體中越堆越多，最終的後果就是程式效能越跑越慢、甚至當機。(所以重開機通常可以讓Android效能恢復，可見這個現象不是神話或笑話。)

可是「因為Android和Java的共通性」這種話講起來是很讓人心虛的。重點是：程式的動作越多、程式碼越多、管理調配的動作越多，就越容易產生這些「不知道該怎辦的資料」。譬如不用Adapter來產生動態畫面的APP在刷新畫面無數次後，最終的命運就是記憶體被那些「淘汰」的畫面元件吃光光.....(被丟掉的畫面變成「不知道該怎辦的資料」。)

使用第一種方法並不會保障「不知道該怎辦的資料」絕不會產生。

但是.......舉例來說，如果使用Intent傳遞資料，結果可能會造成資料傳遞完、Intent的一部份變成「不知道該怎辦的資料」，如果大量、頻繁使用Intent，結果就是造成APP從開始到「因為記憶體被這些資料吃光而無法正常運作」的周期縮短。

SingleTon也如此。

重點在於：第二類方法總是會造成「特定Activity需要的資料必須要在其他Activity中產生，並且使用額外物件管理或傳遞，處理跟接收本身也要產生額外的物件」，──附帶一提，所謂的物件也是種「資料」。這些物件越多，也就表示資料越多......

所以在單一Activity當下接收並管理資料，怎麼看都是王道。



寫這些，是因為公司某前輩離職前寫的程式開始被客戶抱怨「使用久了、操作頻繁了，就會當機」。

大老闆正在四處找更資深的工程師來解這個問題，我雖然知道解法、而且在別家公司也成功處理過類似的狀況，但.........先安靜.........