作者cyclone350 (老子我最神)
看板java
标题[问题] android 开发 java 的效能考量
时间Tue Aug 9 23:25:52 2016
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://webptt.com/cn.aspx?n=bbs/java/M.1470756355.A.BCA.html
1F:→ james732: 我觉得你应该考虑自己学一下Android app 08/09 23:31
2F:→ james732: 你怀疑团队跟你说的,那你就会相信网友说的话吗?XD 08/09 23:31
→ cyclone350: 会阿 *[m 08/09 23:32
我觉得还是表达的方式会让我无法理解
例如我问说
为什麽这个 sql 需要跑超过 10 秒
A 回答: 因为有好多资料阿
B 回答: 因为这个sql查询栏位没建 index,所以搜寻复杂度是 O(n)
我如果只有听到 A 的回答,我自然会去想说,其他 sql 资料也不比这个少啊
为什麽其他 sql 只有 0.1 秒就跑完了
我没有 index 方面的知识,但是透过 B 的说法,就可以解释
为什麽只有这个 sql 特别慢了
现在我需要一个 "B" 来提醒我,所以不是相不相信的问题,
是我想理解效能考量的方式
3F:推 pupuliao: 以前写过一点 当时最难处理的是RAM的问题 08/09 23:35
4F:→ pupuliao: 不过API开发已经有特定对口,还是在规格上双方好好讨论 08/09 23:37
5F:→ pupuliao: 我最近就有串接合作厂商API..都让我想把对方砍了 08/09 23:37
※ 编辑: cyclone350 (123.193.196.217), 08/09/2016 23:53:10
6F:推 pupuliao: 状况二 如果是所有资讯要在一个页面中显示 那要求合理阿 08/09 23:43
※ 编辑: cyclone350 (123.193.196.217), 08/09/2016 23:54:39
7F:推 now99: 从Ui角度来想,这全部资料要一次显示?使用者一次需要看那 08/10 00:01
8F:→ now99: 麽多资料? 08/10 00:01
9F:推 pupuliao: 看你的回应应该是 你们双方沟通有问题吧... 08/10 00:14
10F:推 MIM23: 两边都开发的我来指点迷津,1.麻烦传简单明了的资料来,不 08/10 00:33
11F:→ MIM23: 想在处理过一次。2.不要用网页的思维来看APP,移动装置同一 08/10 00:33
12F:→ MIM23: 个主题的资料能一次请求全回来最好 08/10 00:33
13F:推 lucky1lk: 搜寻复杂度是 O(n) XDDDDD 08/10 07:56
14F:推 ctrlbreak: 第一个问题, 我比较想知道对方觉得怎麽做比较好? 08/14 12:47
15F:→ KeySabre: 可能是觉得product list可以先用level分开来吧 08/14 21:23
16F:推 kairy: 我的主管是size超过2MB的书单api不处理, 来处理其他size 01/12 09:32
17F:→ kairy: 小於10k的 01/12 09:32