我写过手机 也写过前後端，但是没写过手机游戏 稍微提供一下初浅意见 ※ 引述《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/cn.aspx?n=bbs/java/M.1472190253.A.006.html