移動APP服務端設計開發注意要點

2014年，移動APP的熱度絲毫沒有減退，怎麼爲您的移動端app設計良好的服務器端接口（API）呢？ 下面談談我我的的一些想法。

2014年，移動APP的熱度絲毫沒有減退，並無像桌面軟件被WEB網站那樣所取代，不但如此，愈來愈多的傳統應用、網站也都開始製做本身的移動APP，也就是咱們常說的IOS客戶端、Android客戶端。

這彷彿又回到了多年前的CS架構，那時候咱們用VB、VC、Delphi在Windows平臺上快速開發各類應用程序。
不一樣的是，現在的移動端APP基本上都是聯網從服務器端獲取各類數據，客戶端只是一個簡單的表現層的工具。

不只僅是移動APP，包括面向服務的SOA架構，都須要制定一套統1、規範的接口，那麼，作這樣的後端接口須要注意哪些問題呢？

一、跨平臺性

所謂跨平臺是指咱們的接口要可以支持不一樣的終端，好比android、ios、windowsphone以及桌面軟件、網站等，一套接口，支持多端，就像當年Java的口號同樣「Write Once,Run Anywhere」。
固然從本質上講，服務器端的接口跟終端是沒有太大關係的，只是接口應該考慮到不一樣端的接入成本，採用通用的解決方案，好比通訊協議就採用最經常使用的HTTP協議，若是是即時通訊，能夠採用開放的XMPP協議，作遊戲的能夠採用可靠的TCP協議，除非TCP不夠用了，再採用定製的UDP協議。數據交換採用xml或者json格式等等。

總之，要達到的目標就是讓不一樣的端可以很方便的使用你的接口。

二、良好的響應速度

若是要用一個指標來衡量接口的性能的話，那麼我想最重要的就是響應速度了。接口應該以最快的速度將數據返回給請求者。試想，當咱們打開一個頁面，若是「努力加載中」之類的提示超過三五秒鐘的話，咱們確定會變得不耐煩，移動app原本大部分就是用戶在碎片化時間來使用的，在有限的時間內，用戶巴不得得到的信息越多越好，即便你的app界面設計的再好，用戶也不會買帳。

提升響應速度又是個老生常談的問題，大致上應該按照如下步驟來作：
a、初期，以功能爲主，要保證功能完整，知足業務需求，這階段可使用動態的語言，好比java、php、asp.net等，配合設計良好的數據庫結構和索引，能知足必定的需求；

b、其次，隨着用戶的增多，能夠考慮一些緩存方案，緩存是解決性能問題的萬金油，一般能起到立竿見影的效果。最經常使用的靜態文件緩存，memcached內存緩存等。

c、而後，單臺機器的吞吐率不行了，經過負載均衡多加幾臺機器就好了。七八臺機器，支持天天千萬級的接口調用是可行的。或者，直接採用CDN的解決方案，將絕大多數的靜態資源交給CDN去處理。

總之，要達到的目標就是快，一個頁面，秒開最好，超過三秒就須要找找緣由了。

三、接口要爲移動客戶端考慮

接口不只僅是提供數據和功能就完事了，更應該充分考慮移動端的特性，爲移動端提供更加方便、快捷的接口。好比，在移動端裏，下拉刷新和上拉加載更可能是很常見的功能，若是接口仍然按照傳統的web思路，只提供按頁讀取的話，就會形成移動端的額外的數據請求和計算。這時，接口就應該針對這兩種類型的操做提供額外的支持。

再好比，對於一個新聞閱讀類的app來講，最新的新聞列表裏的文章，特別是前幾條，用戶很容易點擊進去看，然後面的老的文章列表，一來用戶下滑加載好幾頁的狀況較少，二來過期的新聞用戶也不多點。若是，接口在返回新聞列表時，對於最新的列表，能夠直接把文章的正文（或者部分正文，好比一屏的內容）信息一塊兒傳給客戶端，這樣，用戶在打開新聞詳情頁的時候，就不用再從服務器端獲取了，天然能夠作到秒開。

好比訪問第一頁時，接口能夠返回文章內容，以下所示 ，content=1表示加載文章內容newslist?page=1&pagesize=20&content=1；其餘頁時，newslist?page=5&pagesize=20&content=0 ,不用加載文章內容。

固然，客戶端要跟接口作好配合，搭配好，才能最大化的提升性能。
好比，移動端都有左右滑動來看上一篇、下一篇文章或者圖片的功能，若是，當用戶請求某篇文章的時候，服務器端順便也把下一篇文章的內容返回回來了，那麼當用戶看下一篇的時候，是否是就很快了呢。

固然這種preload的方案也不能濫用，若是預加載數據的命中率較低的話，也不行，白白浪費了不少的流量。

四、考慮移動端的網絡狀況和耗電量

若是讓咱們說出哪類app比較好，可能還不大好說，可是若是讓咱們說出哪些app不好，咱們確定會說出那些體積很大、佔用內存多、界面很卡、費電的app很差。

對於移動APP開發者來講，網絡流量和電池電量是不得不考慮的問題。對於網絡狀況，接口應該具有爲不一樣的網絡提供不一樣的內容的能力，
一般，移動端的上網方式無非是2G（GSM、GPRS、EDGE）、3G（CDMA、TDSCDMA、WCDMA）、WIFI，設想一下，若是用戶在流量須要花錢的狀況下，你的app給用戶展現了視頻、音頻、大量的圖片而沒有通知用戶的狀況下，用戶會怎麼想，畢竟國內的流量費用仍是很貴的。

還以上面的新聞列表接口爲例，若是咱們可以知道用戶的網絡狀況，只有在wifi的狀況下才給用戶傳輸封面圖、縮略圖之類的， 是否是能夠幫用戶節省不少流量呢。 不過，您也許會說，這些跟接口沒啥關係吧，服務器端的接口還能管得了客戶端的網絡流量和電量？

newslist?page=1&pagesize=20&content=1&network=wifi
對於電量，首先咱們要弄清楚，app的哪些方面會消耗電量？好比app有大量的計算、有很炫的視覺畫面都會消耗電量，另外，不斷的移動網絡連接也會消耗大量的電量，咱們都知道移動網絡是經過無線電波來通信的，那麼發射裝置就須要消耗必定的電量來發射和接收無線信號。特別的是，頻繁的連接會不斷的切換網絡設備與移動基站之間鏈接狀態，這都會消耗一部分電量。

因此，對於接口而言，儘可能用少的連接傳輸多的數據，
好比，對於關於咱們、版本更新以及一些系統配置信息，徹底能夠經過一次連接所有返回給客戶端。

五、通用的數據交換格式

目前，對於接口和客戶端的數據交換格式，基本上就是兩種，xml和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解析器都會很好的解析。

好比下面兩種方式都是能夠的。

{
    "code":"208",
    "data":"\u53c2\u6570\u4e0d\u5b8c\u6574"
} 
{ 
    "code": "208", 
    "data": "參數不完整" 
}

 

二是字段的數據類型，特別是數字類型的，json中儘可能轉成數字格式，
好比{'userid':128 } 不要寫成 {'userid':'128' }

六、接口統計功能

在作PC端網站的時候，咱們都會給咱們的網站加上個統計功能，要麼本身寫統計系統，要麼使用第三方的好比GA、百度等。
移動端接口API則須要咱們本身實現統計功能，這時就須要咱們儘量多的收集客戶端的信息，除了傳統的IP、User-Agent以外，還應該收集一些移動相關的信息，好比手機操做系統，是android仍是ios，都是什麼版本，用戶使用的網絡情況，是2G、3G、4G仍是WIFI 客戶端APP是什麼版本信息。

這樣，有助於咱們更好的瞭解咱們用戶的使用狀況。

七、客戶端與服務端的肥瘦平衡

在之前C/S、B/S架構時，咱們就已屢次討論過這個問題，客戶端是瘦點好仍是肥點好，固然也沒有固定答案，須要本身根據實際狀況去作權衡。
可是，在移動開發中，因爲客戶端的修改會很費時費力，特別是IOS應用還要通過Apple審覈，另外，當前IOS開發人員、Android開發人員的人工成本廣泛較高，人才緊缺，基於這兩點，能在服務器端實現的功能就不要放在客戶端，畢竟服務器端程序的修改要比客戶端方便、靈活、快捷的多。

八、隱式用戶與顯式用戶

顯式用戶和隱式用戶，我不知道這兩個詞用的是否確切。顯式用戶指的是，APP程序中有用戶系統，一個username、password正確的合法用戶，稱之爲顯式的用戶，一般顯式用戶都須要註冊，登陸之後能完成一些我的相關的操做。

隱式用戶指的是，APP程序自己就沒有用戶系統，或者一個在沒有登陸的狀況下，使用咱們APP的用戶。在這種狀況下，能夠經過客戶端生成的UDID來標識一個用戶。

有了用戶信息，咱們就可以瞭解不一樣用戶的使用習慣，而不只僅是全體用戶的一個總體的統計信息，有了這些個體的信息以後，就能夠作一些用戶分羣、個性化推薦之類的事情。

九、安全問題
網絡安全已經從桌面互聯網轉到了移動互聯網，從客戶端蔓延到了接口API中。

傳統固若金湯的網站，極可能由於接口的一點疏忽而遭受入侵。如今，在不少白帽子或者黑客的入侵思路中，先看看移動端接口是否存在漏洞，再看網站是否有漏洞。

客戶端APP與接口的通訊很容易被獲得，只要在中間路由上嗅探一下就行，whireshark、tcpdump這類工具使得這項工做變得簡單無比。

因此，接口的安全工做不能馬虎，暴力破解啊、SQL Injection啊、僞造請求和數據啊、重複提交啊也要考慮到,若是數據特別敏感，能夠考慮採用SSL/TLS等加密傳輸，或者客戶端、服務器端約定一個加密算法和密鑰，對來往傳輸的數據進行加密、解密；若是不採用RESTful API，能夠採用基於WSDL和SOAP的Web Service的安全措施。

十、良好的接口說明文檔和測試程序

接口文檔有時候是項目初期就定下來的，先後端開發人員按照接口規範開發，有的是接口開發完成後寫的。

接口文檔要清晰、明瞭，包含多少個接口，每一個接口的地址、參數、請求方式、數據交換格式、返回值等都要寫清楚。

接口測試程序，有條件的話，也能夠提供，方便先後端的調試。

 

十一、版本的維護

隨着業務的變化，客戶端APP和服務器端API都會發生變化，增長新的功能，修改已有的功能， 增長功能還好說， 若是是接口須要修改，那麼就面臨着同一個接口要同時爲不一樣版本的客戶端服務的問題。 所以，服務器端接口也要作好相應的版本維護。