還是For迴圈...換個方法測試

下面有三個迴圈，迴圈的資料型態就是int和short的差別。(第三個迴圈跟第二個迴圈都是short型態，可是迴圈內進行的運算資料從short改成long型態)

最後一張，當然是運算的結果。(花了多少時間進行運算。)

short型態的迴圈，執行速度快了兩成???(一旦改為long型態，時間爆增為兩倍？)

(這個測試還要考慮到「宣告一個資料」佔用的資源和時間...晚點再測試吧！)

數字加總，該用for迴圈？還是用公式？

JAVA新手初級最常做的for迴圈練習，就是計算從h到t的數字總合。

這個練習為何很重要？

........

或者該問：這個練習重要嗎？

其實這個練習的意義在瞭解for迴圈的結構跟意義，還有程式計算中「賦予參數一個數值」這個動作真正的意義。

不然真的要計算從h到t的數字總合，大家可以直接用公式就好：

好笑的問題是...

寫程式寫了不算短的時間，我還真沒在實際職場應用上計算過從h到t的數字總合 。

凡是要使用迴圈，一定都是為了讀取一個矩陣中的各個元素。

所以我不禁納悶：現實中使用for迴圈和用公式來計算從h到t的數字總合這個問題，在效能上的差距會有多少？

就我對計算機原理淺薄的理解上來說，X*N對電腦來說不過就是把「加X」這個動作做N次，X往往只是t和h的平均值，N則是之間的差。

這不也是迴圈在做的事情嗎？既然如此，效能可以差距到多少呢？

(為何會有circle這個數值？因為如果直接加總h到t，其實數字要非常大才能比較出效能差距，但如果加入circle這層迴圈，就可以放大那一點點小小的效能差距。)

我做了從0到10000的數字加總，與從100到10100的數字加總，一共兩總比較。

結果很遺憾的，用公式計算可以說大獲全勝。

(如果把circle改為30000，甚至300000，可以更明顯得看出來用公式與用迴圈的不同。)



其實用公式會快是理所當然的，畢竟For迴圈其實包含了判斷式、區域變數宣告、區域變數遞增計算，不需要處理這些，直接進行計算的公式當然快。

這堆程式只是想具體知道「到底差了多少？」



文章寫到這裡時，我又把circle調整為3300000，然後t調整為20000。(不付上程式了。)

用迴圈必須要跑上48秒的計算，用公式只要35毫秒就完成了。

可是計算從100到20100的加總時，迴圈要45秒，用公式卻跑了38毫秒。

所以我一口氣再把circle調整為9900000，t調整為40000，結果(公式)是109和115毫秒。(都是增加了一成左右的時間。)



請不要問我這一切有何意義。我只是想驗證看看而已。

好大一顆按鈕！2(加入static)

延續前一篇......

把唯一的一顆Button從onCreate()內的區域變數/物件改寫成一個static的類別物件。

其餘程式完全沒有影響......



(我沒有把OnClick的內容附在這張圖中，但基本上內容真的一樣。)

很遺憾！這個狂想不管用！

按下按鈕後，程式會掛掉！



所以Button在用動態生成時，建構子中傳入的「this」並不只是會認類別而以，顯然還會明確的辨識它是否為同一個物件。


好沒意義的結論........

等等！改用XML檔生成界面，再用findViewById指令把b指向XML中的Button...但b還是個static！

畫面出來了！而且按下按鈕......挺奇妙的！沒有辦法正常反應，按鈕的文字不會變化。事實上，Activity切換的事件並沒有發生。

再多嘗試下去意義已經不大了。UI原件必須要綁定Activity一起生成跟淘汰。

(???或是我的程式結構還有修正的空間???)

【開版文/Android】好大一顆按鈕！(用同一個Acitivty進行Activity切換)

這是一個Activity(我將它命名為BaseActivity)的OnCreate()的內容。

這個Activity就是產生一顆按鈕，而且是很大的一顆按鈕。每按一下這個按鈕，就會啟動一個新Activity，──但仔細看看程式，會發現這個Activity也是BaseActivity。

新的Activity和產生/呼叫它的舊Activity之間的差異在於按鈕上顯示的文字，──新的Activity會比舊的Activity多一個「？」。

(Activity No.0的按鈕如果沒有「？」，則Activity No.1會有一個「？」，以此類推，Activity No.2會有兩個「？」。)



一支APP有的時候會需要在具有不同功能的界面間切換畫面。Android的原始概念是希望讓設計者可以用「產生新頁」、「關閉目前頁面，回到上一個頁面」來實現這個切換的需要。

但實作時發現了一個問題，就是Activity本身的程式大小遠超過「功能」與「界面」的程式大小。

如果功能越多、需要的Activity越多，程式容量成長的幅度可能會遠遠超出預期容許範圍。

但(我覺得)這是許多教學程式/範例的撰寫者因為偷懶方便而聯合造成的美麗錯誤，仔細想一下就會知道「OnCreate()」的意義並不是「讓設計者設置/產生自己期望的功能」，而是「讓Android作業系統底層呼叫的接口」。

這兩者不能同時並存嗎？

不是不能，而是不需要！

「setContentView()」內傳入的View並「不一定」要由Activity產生！可以由獨立的物件產生。

這個獨立的物件程式大小絕對遠小於Activity。



寫這個練習程式的概念在於：用同一個Activity重覆呼叫/切換，然後在Bundle中帶入不同的「指令」來辨識該產生什麼樣的View傳入「setConentView()」。

至於為何會需要/想出這個概念？

主要是因為這篇文章「一個 App 下載值多少錢」。

因為手機內的記憶體越作越大，大家好像會開始縱容自己設計的APP檔案大小隨意成長。

其實我們沒有理由去相信/擔憂這個問題會變成災難，可是......如果能簡單幾個小動作就提升自己的程式效能，相信沒人拒絕、沒人會懶得動腦，同樣的，如果可以嘗試將自己的APP檔案瘦身，為何不做看看？

(我這個練習只是個人預想，到底有沒有效？拿這個方法來修改自己已經完成的APP會不會有效減小它的檔案大小？......完全沒根據啦！我本人從「領悟」到這點後，除非必要，否則我寫APP都嚴格奉行「只用一個Activity」，還沒機會去測試會發生什麼事。)