我寫過手機 也寫過前後端，但是沒寫過手機遊戲 稍微提供一下初淺意見 ※ 引述《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 的普通迴圈會有效能問題? : 請問是我少考慮甚麼東西嗎? 麻煩有經驗的人幫忙回答一下，謝謝 : --- : # 例子2 : APP 有一個商品列表頁，一個商品介紹頁面，一個商品使用規格 一個商品列表有多筆商品，裡面有每一筆的商品介紹及規格 所以是n * m 的二維資料囉 : 使用規格的意思是說 : 假如我買一個線上音樂，這個音樂可以選的音質，歌詞...等雜七雜八的設定 : app 團隊表示必須在一隻 API 內提供所有內容 : 也就是列表所有商品的介紹，細項，以及購買後的全部設定 : 有多個 request 會有效能問題 所以APP先取得List，然後針對每一筆發動 request 取得細項內容 請問我的解讀是否有誤？ 我認為你要搭配APP UI 提供適當的API，而且要多為對方著想 EX: UI 的List 上有簡單歌曲介紹，以及專輯照片歌手等... 所以你的List 不能有有單純商品名稱， 否則每一個item 都發動request， 這樣資料量，對Server 以及Client APP 都是傷害 : 這我就更難動了，我有寫過網頁 : 網頁現在趨勢是 ajax 互動，你要做某件事情，或取得某些資料，再呼叫 : 相對的 API 即可，也就是一個 API 目的都很單純，整體架構也比較有彈性、 : 方便修改 : 就算是最古老的 jsp 寫法，完全沒有 ajax，也是一個頁面一個 model : 怎麼會有一大堆頁面的所有資料包含在一個 model 的概念? : 而且假設多個 request 會有效能議題，那瀏覽器不就掛掉了? : 因為隨便一個頁面可能就有好幾十個 http request... : 請問是我少考慮甚麼東西嗎? 麻煩有經驗的人幫忙回答一下，謝謝 另外回文你提到的SQL例子，資料量大以及Full table Scan 都有可能影響DB效能 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.215.195.54 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/java/M.1472190253.A.006.html