移动端开发注意事项

1、跨平台性

所谓跨平台是指我们的接口要能够支持不同的终端，比如android、ios、windowsphone以及桌面软件、网站等，一套接口，支持多端。
当然从本质上讲，服务器端的接口跟终端是没有太大关系的，只是接口应该考虑到不同端的接入成本，采用通用的解决方案，比如通信协议就采用最常用的HTTP协议，如果是即时通信，可以采用开放的XMPP协议，做游戏的可以采用可靠的TCP协议，除非TCP不够用了，再采用定制的UDP协议。数据交换采用xml或者json格式等等。
总之，要达到的目标就是让不同的端能够很方便的使用你的接口。

2、良好的响应速度

如果要用一个指标来衡量接口的性能的话，那么我想最重要的就是响应速度了。接口应该以最快的速度将数据返回给请求者。试想，当我们打开一个页面，如果“努力加载中”之类的提示超过三五秒钟的话，我们肯定会变得不耐烦，移动app本来大部分就是用户在碎片化时间来使用的，在有限的时间内，用户恨不得获得的信息越多越好，即使你的app界面设计的再好，用户也不会买账。

提高响应速度又是个老生常谈的问题，大体上应该按照以下步骤来做：
a、初期，以功能为主，要保证功能完整，满足业务需求，这阶段可以使用动态的语言，比如java、php、asp.net等，配合设计良好的数据库结构和索引，能满足一定的需求；

b、其次，随着用户的增多，可以考虑一些缓存方案，缓存是解决性能问题的万金油，通常能起到立竿见影的效果。最常用的静态文件缓存，内存缓存等。

3、接口要为移动客户端考虑

接口不仅仅是提供数据和功能就完事了，更应该充分考虑移动端的特性，为移动端提供更加方便、快捷的接口。比如，在移动端里，下拉刷新和上拉加载更多是很常见的功能，如果接口仍然按照传统的web思路，只提供按页读取的话，就会造成移动端的额外的数据请求和计算。这时，接口就应该针对这两种类型的操作提供额外的支持。

再比如，对于一个新闻阅读类的app来说，最新的新闻列表里的文章，特别是前几条，用户很容易点击进去看，而后面的老的文章列表，一来用户下滑加载好几页的情况较少，二来过时的新闻用户也很少点。如果，接口在返回新闻列表时，对于最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的内容）信息一起传给客户端，这样，用户在打开新闻详情页的时候，就不用再从服务器端获取了，自然可以做到秒开。

当然，客户端要跟接口做好配合，搭配好，才能最大化的提高性能。
比如，移动端都有左右滑动来看上一篇、下一篇文章或者图片的功能，如果，当用户请求某篇文章的时候，服务器端顺便也把下一篇文章的内容返回回来了，那么当用户看下一篇的时候，是不是就很快了呢。

当然这种preload的方案也不能滥用，如果预加载数据的命中率较低的话，也不行，白白浪费了很多的流量。

所以，对于接口而言，尽量用少的链接传输多的数据，
比如，对于关于我们、版本更新以及一些系统配置信息，完全可以通过一次链接全部返回给客户端。

5、通用的数据交换格式

目前，对于接口和客户端的数据交换格式，基本上就是json，而现在使用json的应该占大多数。
交换的数据包括两种，一种是客户端请求服务器端接口时传递的一些参数，一种是服务器端返回给客户端的数据。

对于客户端的请求参数，现在也越来越多的接口要求采用json的格式，而不是以往最常见的key_value对了。

比如，接口需要username和password两个参数key_value pair的方式是：username=hutuseng&password=hutusengpwd

然后通过GET或者POST方式传送。
而通过json方式交换数据的话，格式如下，直接POST到服务器端。

{
‘username’:‘hutuseng’,
‘password’:‘hutusengpwd’
}

对于服务器端返回的json数据格式，需要注意两个问题：
一是汉字编码问题，因为json（javascript）内部支持Unicode编码，会将汉字等转换成unicode编码保存，所以在返回结果中，对于中文，可以直接输出中文，也可以输出中文的unicode编码，json解析器都会很好的解析。

二是字段的数据类型，特别是数字类型的，json中尽量转成数字格式

6、接口统计功能

在做PC端网站的时候，我们都会给我们的网站加上个统计功能，要么自己写统计系统，要么使用第三方的比如GA、百度等。
移动端接口API则需要我们自己实现统计功能，这时就需要我们尽可能多的收集客户端的信息，除了传统的IP、User-Agent之外，还应该收集一些移动相关的信息，比如手机操作系统，是android还是ios，都是什么版本，用户使用的网络状况，是2G、3G、4G还是WIFI 客户端APP是什么版本信息。

这样，有助于我们更好的了解我们用户的使用情况。

7、客户端与服务端的肥瘦平衡

在以前C/S、B/S架构时，我们就已多次讨论过这个问题，客户端是瘦点好还是肥点好，当然也没有固定答案，需要自己根据实际情况去做权衡。
但是，在移动开发中，由于客户端的修改会很费时费力，特别是IOS应用还要经过Apple审核，另外，当前IOS开发人员、Android开发人员的人工成本普遍较高，人才紧缺，基于这两点，能在服务器端实现的功能就不要放在客户端，毕竟服务器端程序的修改要比客户端方便、灵活、快捷的多。

8、隐式用户与显式用户

显式用户和隐式用户，我不知道这两个词用的是否确切。显式用户指的是，APP程序中有用户系统，一个username、password正确的合法用户，称之为显式的用户，通常显式用户都需要注册，登录以后能完成一些个人相关的操作。

隐式用户指的是，APP程序本身就没有用户系统，或者一个在没有登录的情况下，使用我们APP的用户。在这种情况下，可以通过客户端生成的UDID来标识一个用户。

有了用户信息，我们就能够了解不同用户的使用习惯，而不仅仅是全体用户的一个整体的统计信息，有了这些个体的信息之后，就可以做一些用户分群、个性化推荐之类的事情。

9、安全问题
网络安全已经从桌面互联网转到了移动互联网，从客户端蔓延到了接口API中。

传统固若金汤的网站，很可能因为接口的一点疏忽而遭受入侵。现在，在很多白帽子或者黑客的入侵思路中，先看看移动端接口是否存在漏洞，再看网站是否有漏洞。

所以，接口的安全工作不能马虎，暴力破解啊、伪造请求和数据啊、重复提交啊也要考虑到,如果数据特别敏感，可以考虑采用SSL/TLS等加密传输，或者客户端、服务器端约定一个加密算法和密钥，对来往传输的数据进行加密。

10、良好的接口说明文档和测试程序

接口文档有时候是项目初期就定下来的，前后端开发人员按照接口规范开发，有的是接口开发完成后写的。

接口文档要清晰、明了，包含多少个接口，每个接口的地址、参数、请求方式、数据交换格式、返回值等都要写清楚。

接口测试程序，有条件的话，也可以提供，方便前后端的调试。