一、哎，最近換了家工作，結果工作很出的我意外，沒有干熟悉的根據需求寫代碼，反而讓我一個小菜鳥去重構一下App的架構（他們公司的app，已經上線了1.0版本了），沒辦法，只有硬着頭皮去先學習學習，再總結總結。
Hybrid APP架構設計思路 ---> https://segmentfault.com/a/1190000004263182
二,App與服務器的通信接口如何設計得好,可以從以下這幾個方面考慮
1、 安全機制的設計
----> 待研究
2、 接口數據的設計
接口的數據一般都采用JSON格式進行傳輸，不過，需要注意的是，JSON的值只有六種數據類型：
Number：整數或浮點數
String：字符串
Boolean：true 或 false
Array：數組包含在方括號[]中
Object：對象包含在大括號{}中
Null：空類型
所以，傳輸的數據類型不能超過這六種數據類型。以前，我們曾經試過傳輸Date類型，它會轉為類似於"2016年1月7日 09時17分42秒 GMT+08:00"這樣的字符串，這在轉換時會產生問題，不同的解析 庫解析方式可能不同，有的可能會轉亂，有的可能直接異常了。要避免出錯，必須做特殊處理，自己手動去做解析。為了根除這種問題，最好的解決方案是用毫秒數表示日期。
另外，以前的項目中還出現過字符串的"true"和"false"，或者字符串的數字，甚至還出現過字符串的"null"，導致解析錯誤，尤其是"null"，導致App奔潰，后來查了好久才查出來是該問題導致的。這都是 因為服務端對數據沒處理好，導致有些數據轉為了字符串。所以，在客戶端，也不能完全信任服務端傳回的數據都是對的，需要對所有異常情況都做相應處理。
服務器返回的數據結構，一般為：
{
code：0
message: "success"
data: { key1: value1, key2: value2, ... }
}
code: 狀態碼，0表示成功，非0表示各種不同的錯誤
message: 描述信息，成功時為"success"，錯誤時則是錯誤信息
data: 成功時返回的數據，類型為對象或數據
不同錯誤需要定義不同的狀態碼，屬於客戶端的錯誤和服務端的錯誤也要區分，比如1XX表示客戶端的錯誤，2XX表示服務端的錯誤。這里舉幾個例子：
0：成功
100：請求錯誤
101：缺少appKey
102：缺少簽名
103：缺少參數
200：服務器出錯
201：服務不可用
202：服務器正在重啟
錯誤信息一般有兩種用途：一是客戶端開發人員調試時看具體是什么錯誤；二是作為App錯誤提示直接展示給用戶看。主要還是作為App錯誤提示，直接展示給用戶看的。所以，大部分都是簡短的提示信 息。
data字段只在請求成功時才會有數據返回的。數據類型限定為對象或數組，當請求需要的數據為單個對象時則傳回對象，當請求需要的數據是列表時，則為某個對象的數組。這里需要注意的就是，不要將 data傳入字符串或數字，即使請求需要的數據只有一個，比如token，那返回的data應該為：
// 正確
data: { token: 123456 }
// 錯誤
data: 123456
3、接口版本的設計
接口不可能一成不變，在不停迭代中，總會發生變化。接口的變化一般會有幾種：
數據的變化，比如增加了舊版本不支持的數據類型
參數的變化，比如新增了參數
接口的廢棄，不再使用該接口了
為了適應這些變化，必須得做接口版本的設計。實現上，一般有兩種做法：
每個接口有各自的版本，一般為接口添加個version的參數。
整個接口系統有統一的版本，一般在URL中添加版本號，比如http://api.domain.com/v2。
大部分情況下會采用第一種方式，當某一個接口有變動時，在這個接口上疊加版本號，並兼容舊版本。App的新版本開發傳參時則將傳入新版本的version。
如果整個接口系統的根基都發生變動的話，比如微博API，從OAuth1.0升級到OAuth2.0，整個API都進行了升級。
有時候，一個接口的變動還會影響到其他接口，但做的時候不一定能發現。因此，最好還要有一套完善的測試機制保證每次接口變更都能測試到所有相關層面。
三、只是為了記錄學習別人的知識，好的地方是直接粘貼過來的，請各位看官見諒。