“移动和性能是一个庞大而可怕的话题，而实际上说它庞大而可怕是没有理由的。”Scott Barber是坐落在佛罗里达州Palm Bay的PerfTestPlus公司的总裁及首席技术官，他说“除非你知道如何处理这个问题，否则这件事情非常具有挑战性。但是到了最后，我想说其实并没有人们所想的那么难。”
Barber说：“我们的性能挑战是基于非常简单的情况，就是努力使笔记本或者台式机性能摆脱那种庞大却功能较差的设备。”
Nazmi Savga是Imprezzio Global的软件构架师：“移动平台与标准PC相比较弱，因此，面临的主要挑战就是要编写一个行为像PC但是运行在移动平台上的应用程序。”
Barber说：“不久之前，我们创建和交付软件的一般方式与现如今申请移动应用程序的思维过程类似。”
Stephen Pierzchala是坐落在密歇根州底特律Compuware 公司的技术策略师，他认为：“在移动Web和本地移动应用两个方面，与我们使用了很多年的台式机中有许多相同的规则。可以将其归结为一个原则，根据这个原则可以推广出其他许多原则：了解你的客户。”
了解目标对象
Pierzchala说，从移动应用性能角度来了解你的客户，意味着要知道客户使用的是什么浏览器、什么操作系统、设备类型及什么类型的连接。所有这些因素对应用程序都构成限制，值得深入思考，而且是越早越好。
Barber说，理想的情况下，团队开始考虑应用程序在概念阶段所运行的目标设备或者设备组。他承认，这个过程非常困难。如果项目要六个月的开发周期，你还会为如今或者以后的移动设备构建应用程序吗?
Barber说：“事实是每个人都想做最新、最棒的设计，随后他们会决定他们需要向后兼容的应用程序，这会创造一场噩梦。如果一开始就做出这样的决定，还会有希望。如果后期才做出这个决定，那么你就是搬起石头砸自己的脚。”
最新平台上可用的特性和功能在以前的版本中未必适用，或者从一个移动平台到另一个移动平台也未必适用。Savga说：“架构师应该了解应用程序将会在哪类平台上运行，应该考虑不同平台间的差异。架构师应该意识到这是一个受限制的平台，或者意识到与一个标准PC相比它有许多缺陷，例如内存和磁盘空间。”
当开发人员事前决定出应用程序将会运行在什么类型的操作系统及浏览器上时，Barber将这种方法与Web开发作比较。他说：“在某种意义上它只是一个过时的概念。”
网络电话出现障碍了?
另外一个移动应用性能技巧是：总是将网络流程放在后台处理，这对于资深的开发人员来说非常熟悉。Matt Vlasach是坐落在美国亚利桑那州Mesa的Unwired Revolution公司的移动集成服务总监，该公司是一个移动解决方案开发公司，Matt Vlasach解释说：“等待一个响应时不要阻塞UI，当正在运行这样一个网络任务时，你一定要谨慎。如果你在主线上做了任何处理，即使响应结束应用程序也会被冻结。要使用异步的Web请求，并且要恰当地处理这些事情。”
Vlasach说，可以用同样的方法来开发一个桌面或者Web应用程序。“注意‘当你正等着处理网络事情时不要阻止用户正在进行的程序。’这更复杂，需要花费更多的时间，用户体验开发需要更长的周期，但是在用户体验和实际使用中却存在很大的差异。”
将性能介绍从业务逻辑和数据中分离出来
Savga建议开发人员和架构师要了解三个层次，系统包括一个表示(或者用户界面)层、业务层及数据层，对每一个层级的构建都要谨慎。他说：“代码中的功能不应该在其他层或者项目其他部分被复制。这样做会使代码维护容易些，同时对性能方面的维护也有帮助。”
当涉及到表示层的应用程序，架构师需要考虑一下屏幕尺寸以及如何显示用户界面(UI)。如果对于所有可能的方案都采用常规设计，并用这些方案来处理UI更改，应用程序的性能将会受到影响。
Savga说：“最好的方法是根据屏幕尺寸创建一个不同的设计，因此，当应用程序识别出不同尺寸的屏幕时它会自行切换。否则，对于不同尺寸的屏幕都创建一个常规UI，在你进行用户体验时就会出现很多性能问题。”
说到这，让我们回顾下刚开始说的原则：“要了解你的客户是谁，以及传递正寻找的内容时的能力限制是什么。”
