我寫過手機 也寫過前後端，但是沒寫過手機遊戲
稍微提供一下初淺意見
※ 引述《cyclone350 (老子我最神)》之銘言：
: HI,
: 我完全沒有開發 android app 的經驗
: 在開發上我是提供 API，讓 APP 呼叫並且處理
: 但是 APP 在開發上跟我說的效能問題實在很難說服我
: 我下面會舉一些例子，希望有在開發 APP 的人或是有相關實際經驗的人
: 能跟我講 APP 的考量點
: # 例子1
: server 會提供一個商品列表，包含商品名稱、商品價錢、推薦順序
: ```
: [
: {name: "product1", price: 20, recommandOrder: "1evel1"},
: {name: "product2", price: 30, recommandOrder: "1evel1"},
: {name: "product3", price: 40, recommandOrder: "1evel1"},
: {name: "product4", price: 30, recommandOrder: "1evel2"},
: {name: "product5", price: 20, recommandOrder: "1evel3"},
: {name: "product6", price: 30, recommandOrder: "1evel3"}
: ]
: ```
: 從這邊可以看出來
: 第一個 level1 的商品是 product1
: 第一個 level2 的商品是 product4
: 第一個 level3 的商品是 product5
: 實際上我們每一次回傳的商品數量約 50~300 個
如果你有超多商品，而且每一筆的文字敘述 落落長
請問總資料量是多少K?還是M?
剛剛前面網友有提到網路品質等問題，你也要顧慮進去
此外每一個手機的PG都有跟OOM奮戰的經驗
OOM並不是記憶體不夠用，而是Dalvik Heap不夠用，
另外你剛剛提到商品，商品圖片Bitmap很吃記憶體，
畫面上數量不能太多，不然很容易OOM
我們常用的相簿瀑布牆（對不起我一時找不到適合名稱），
User使用上感覺很棒，幾千張相片可以不斷往上往下滑
其實是畫面上只有幾張照片而已，
當你捲軸滾到某處，畫面上只是秀出該處照片，
然後其他地方看不到照片都被Free了，只有佔空間的方框而已，
這樣才能省記憶體，否則照片太多會搞掛Android
還有他只是要一些排行前面的幾筆資料，你卻把全部資料都丟上去，
這樣對效能「最佳化」不友善
: 問題來了，app 團隊告知他們無法這樣計算，因為會有效能議題
: 但是… 為什麼一個普通的單次或兩次迴圈，
: 而且數量只有 300 的情況下會有效能議題
: app 團隊回應因為要建立物件對應 (hashMap)，所以會有效能議題
: 這實在是有點難說服我，因為依照我對手機的了解，可以跑 3D 遊戲
: 可以玩跑跑薑餅人，可以玩動作卡牌遊戲
: 究竟是為什麼一個沒有 IO 的普通迴圈會有效能問題?
: 請問是我少考慮甚麼東西嗎? 麻煩有經驗的人幫忙回答一下，謝謝
: