先給出服務端的架構圖。
根據需求和原型設計，可能的模組劃分如下：
服務端與客戶端使用json交換資料，使用自定義json格式，約定返回code、message，實體封裝在result中，支援單個實體、實體列表、多個實體列表，定義如下：
}}
,主要api介面設計如下："media":} }
}
......也許你看到了，api做了二級網域名稱對映，同時為了服務端後期api版本的公升級管理，在url中加上了版本標識v1.0。命名方面我盡量做到restful的風格。對了，此處沒有使用https。為了解決資料傳輸的安全，我做了點特別的處理：對請求體和響應結果進行rsa加密（如果服務端返回的資料稍稍過大，這個rsa嚴重影響客戶端解密，後來我換成了aes），所有請求為post請求，所以api url後面沒有帶引數，你也看不到任何請求相關的資訊。
根據需求和原型設計，資料庫的設計大概需要兩周時間。其實一周基本搞定了，但為了考慮充分，留出一周時間來檢驗和調整。資料庫e-r圖略。
android本身就是mvc，所以我不打算引入mvp或mvvm。我的理念是職責分層，快速推出android 1.0。主要的包結構如下：
註冊登入，個人資訊，我的小孩，相簿管理，訊息通知，系統設定等等。
重**明輪子是不可取的。有些模組根本沒必要自己寫。以下是引入的第三方庫，以及優勢說明。
支援的記憶體快取，檔案系統快取或者sd卡快取
根據控制項(imageview)的大小對bitmap進行裁剪，減少bitmap占用過多的記憶體
較好的控制的載入過程，例如暫停載入，重新開始載入，一般使用在listview,gridview中，滑動過程中暫停載入，停止滑動的時候去載入
提供在較慢的網路下對進行載入
大檔案分塊上傳
刪除操作（不推薦在客戶端使用）
public先看一下登入的序列圖：inte***ce
datacallback
為了加快開發速度，重用**，adapter的使用有技巧。每次在getview中查詢控制項id、利用viewholder、賦值，最後返回convertview，看著都是差不多的**。是時候脫離這個苦海了。先看怎麼解決共用的viewholder問題。
publicviewholder的作用，就是通過convertview.settag與convertview進行繫結。當convertview復用時，直接從與之對應的viewholder(gettag)中拿到convertview布局中的控制項，省去了findviewbyid的時間。上面的**就是這樣的原理。static
extends view> t get(view view, int
id)
view childview =viewholder.get(id);
if (childview == null
)
return
(t) childview;
}
然後就是commonadapter了。
public好了，不貼**了。看不明白了這裡：android 快速開發系列 打造萬能的listview gridview 介面卡abstract
class commonadapterextends
baseadapter
@override
public
intgetcount()
@override
public t getitem(int
position)
@override
public
long getitemid(int
position)
@override
public view getview(int
position, view convertview, viewgroup parent)
public
abstract
void convert(commonviewholder viewholder, t item, int
position);
}
如aes128加密類、bitmaputils、securepreferences、stringutil、toastutil、ioutil等等。
為了保證資料交換、加解密正常，首先對某乙個介面進行測試，以驗證api service能正常跑通。比如可以先對登入進行模擬測試，看是否成功，同時包括異常的測試，服務端是不是處理了邊界異常，返回給客戶端的都是封裝過的異常資訊，而不是拋乙個敏感資訊給客戶端。提前進行介面測試有助於我們的基礎元件執行沒問題，方便後期其它模組的快速整合。
基礎元件封裝好後，除了少量的從網路獲取資料邏輯和本地資料庫的增刪改查，客戶端基本上就是介面的布局工作了。介面開發基本看熟練程度和自定義view的重用。
好了，基本就這些。兩個android開發人員兩個月內完成肯定是可以的，前提是至少有乙個熟手。後面再談談mvp，畢竟這個客戶端設計沒法進行單元測試，如果業務邏輯越來越複雜，activity的職責會越來越重，問題多多，不利於後期維護。
標籤:
android,
架構設計,
android architecture
好文要頂
關注我收藏該文
leoliang
關注 - 5
粉絲 - 62
+加關注
24 0
理解android虛擬機器體系結構
從.net的寵物商店到android mvc mvp
posted @
2016-01-11 23:59
leoliang 閱讀(
27)
編輯收藏
從零開始搭建架構實施Android專案
時間 2016 01 11 23 59 00 精華區 原文主題 資料庫 安卓開發 先給出服務端的架構圖。根據需求和原型設計，可能的模組劃分如下 服務端與客戶端使用json交換資料，使用自定義json格式，約定返回code message，實體封裝在result中，支援單個實體 實體列表 多個實體列表...
hadoop環境搭建 從零開始
對hadoop的認識只停留在是mapreduce的一種實現工具，大資料，分布式等抽象層面，完全沒有具象了解。搭建環境，完全從零開始，走了挺多彎路。總結之。0.目前較為普遍的起步方式是在虛擬機器上模擬多台搭建hadoop。初始時為調查找問，魯莽從cygwin下手，結果被缺失的linux知識打敗，浪費很...
從零開始學架構 00學習
這個專欄躺在極客時間裡已經躺了很久了，有空的時候才會去聽它，斷斷續續的學習沒有多大效果。還是希望能有時間系統的學習一遍，所以才會整理這份學習筆記，希望寫完了還回再回過頭看看吧。廢話不多說，直接總結乾貨。1.架構設計相對程式設計來說思維方式有很大的差異。架構設計是判斷和取捨，程式設計是邏輯和實現。2....