[問題] android 開發 java 的效能考量

看板java作者 (老子我最神)時間7年前 (2016/08/09 23:25), 7年前編輯推噓8(809)
留言17則, 8人參與, 最新討論串1/6 (看更多)
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 個 問題來了,app 團隊告知他們無法這樣計算,因為會有效能議題 但是… 為什麼一個普通的單次或兩次迴圈, 而且數量只有 300 的情況下會有效能議題 app 團隊回應因為要建立物件對應 (hashMap),所以會有效能議題 這實在是有點難說服我,因為依照我對手機的了解,可以跑 3D 遊戲 可以玩跑跑薑餅人,可以玩動作卡牌遊戲 究竟是為什麼一個沒有 IO 的普通迴圈會有效能問題? 請問是我少考慮甚麼東西嗎? 麻煩有經驗的人幫忙回答一下,謝謝 --- # 例子2 APP 有一個商品列表頁,一個商品介紹頁面,一個商品使用規格 使用規格的意思是說 假如我買一個線上音樂,這個音樂可以選的音質,歌詞...等雜七雜八的設定 app 團隊表示必須在一隻 API 內提供所有內容 也就是列表所有商品的介紹,細項,以及購買後的全部設定 有多個 request 會有效能問題 這我就更難動了,我有寫過網頁 網頁現在趨勢是 ajax 互動,你要做某件事情,或取得某些資料,再呼叫 相對的 API 即可,也就是一個 API 目的都很單純,整體架構也比較有彈性、 方便修改 就算是最古老的 jsp 寫法,完全沒有 ajax,也是一個頁面一個 model 怎麼會有一大堆頁面的所有資料包含在一個 model 的概念? 而且假設多個 request 會有效能議題,那瀏覽器不就掛掉了? 因為隨便一個頁面可能就有好幾十個 http request... 請問是我少考慮甚麼東西嗎? 麻煩有經驗的人幫忙回答一下,謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.193.196.217 ※ 文章網址: https://www.ptt.cc/bbs/java/M.1470756355.A.BCA.html

08/09 23:31, , 1F
我覺得你應該考慮自己學一下Android app
08/09 23:31, 1F

08/09 23:31, , 2F
你懷疑團隊跟你說的,那你就會相信網友說的話嗎?XD
08/09 23:31, 2F
cyclone350: 會阿 *[m 08/09 23:32 我覺得還是表達的方式會讓我無法理解 例如我問說 為什麼這個 sql 需要跑超過 10 秒 A 回答: 因為有好多資料阿 B 回答: 因為這個sql查詢欄位沒建 index,所以搜尋複雜度是 O(n) 我如果只有聽到 A 的回答,我自然會去想說,其他 sql 資料也不比這個少啊 為什麼其他 sql 只有 0.1 秒就跑完了 我沒有 index 方面的知識,但是透過 B 的說法,就可以解釋 為什麼只有這個 sql 特別慢了 現在我需要一個 "B" 來提醒我,所以不是相不相信的問題, 是我想理解效能考量的方式

08/09 23:35, , 3F
以前寫過一點 當時最難處理的是RAM的問題
08/09 23:35, 3F

08/09 23:37, , 4F
不過API開發已經有特定對口,還是在規格上雙方好好討論
08/09 23:37, 4F

08/09 23:37, , 5F
我最近就有串接合作廠商API..都讓我想把對方砍了
08/09 23:37, 5F
※ 編輯: cyclone350 (123.193.196.217), 08/09/2016 23:53:10

08/09 23:43, , 6F
狀況二 如果是所有資訊要在一個頁面中顯示 那要求合理阿
08/09 23:43, 6F
※ 編輯: cyclone350 (123.193.196.217), 08/09/2016 23:54:39

08/10 00:01, , 7F
從Ui角度來想,這全部資料要一次顯示?使用者一次需要看那
08/10 00:01, 7F

08/10 00:01, , 8F
麼多資料?
08/10 00:01, 8F

08/10 00:14, , 9F
看你的回應應該是 你們雙方溝通有問題吧...
08/10 00:14, 9F

08/10 00:33, , 10F
兩邊都開發的我來指點迷津,1.麻煩傳簡單明瞭的資料來,不
08/10 00:33, 10F

08/10 00:33, , 11F
想在處理過一次。2.不要用網頁的思維來看APP,移動裝置同一
08/10 00:33, 11F

08/10 00:33, , 12F
個主題的資料能一次請求全回來最好
08/10 00:33, 12F

08/10 07:56, , 13F
搜尋複雜度是 O(n) XDDDDD
08/10 07:56, 13F

08/14 12:47, , 14F
第一個問題, 我比較想知道對方覺得怎麼做比較好?
08/14 12:47, 14F

08/14 21:23, , 15F
可能是覺得product list可以先用level分開來吧
08/14 21:23, 15F

01/12 09:32, , 16F
我的主管是size超過2MB的書單api不處理, 來處理其他size
01/12 09:32, 16F

01/12 09:32, , 17F
小於10k的
01/12 09:32, 17F
文章代碼(AID): #1NgVO3lA (java)
討論串 (同標題文章)
文章代碼(AID): #1NgVO3lA (java)