我写过手机 也写过前后端，但是没写过手机游戏
稍微提供一下初浅意见
※ 引述《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 的普通循环会有效能问题?
: 请问是我少考虑什么东西吗? 麻烦有经验的人帮忙回答一下，谢谢
: