當我們在新開發一款APP時，我們在初期要如何設計架構呢？在這裏我根據我的經驗，總結了一些基本的架構思路。
客戶端架構設計的時候，首先需要充分考慮到所開發的app的類型，這裏我分爲功能型和服務型兩大類，功能型的app側重業務和功能，服務型的app側重服務和運算。下面我就具體來講講針對這兩種類型的通用架構。
功能型app
功能型app的activity比較多，整個app都以一個個activity承載業務和功能，在設計這類app時，我們需要考慮哪些要素呢？
由於activity比較多，我們需要考慮頁面的跳轉路由，這裏會有人說直接用startactivity就可以實現頁面的跳轉呀，但是一款APP我們在設計的時候，通常都是多module的架構，這樣可以把不同的模塊放在不同的module裏面，實現解耦，不同的module之間想要實現activity的跳轉，就需要採用路由協議了。在路由框架這一塊，阿里的ARouter算是用的比較多的一款開源框架，當然我們也可以自己實現，路由框架也不是很複雜。
其次，不同的activity之間需要通信，常見的線程間的通信工具有handler，回調，以及以生產者消費者爲代表的時間總線，或者是開源的eventbus這一類的事件總線，我們要根據業務類型已經想要達到的解耦標準，來選擇設計一種或者多種通信工具。進程間的通信方式有AIDL，內容提供者等Android原生提供的以binder爲基礎的通信方式，我們也可以自己設計socket或者網絡等方式來進行進程間通信。
由於業務比較多，我們還需要考慮如何沉澱公共組件等自定義View，以我們用來支撐我們業務的通用sdk，如埋點sdk，性能監控，分享sdk等等。
將我們的App需要涉及到的因素考慮完整，那麼我們就從下至上的去設計我們app的架構了，最底層的，應該是網絡層，網絡層之上，是支撐技術和功能的支撐層，公共庫包含路由工具，日誌打點上報工具，常用的方法庫，性能檢測工具以及其他的sdk，支撐層之上的，是一些通用的組件和ui庫，我稱之爲通用組件層，這一層包含了我們自定義的view，如下拉刷新的recyclerview等，通用層之上，就是我們的業務層了。
下面我來一一詳細介紹這四層
- 網路層：網絡層是最底層的東西，我們支撐層的許多sdk需要用到，比如日誌上報，推送sdk等等，業務層也需要用到，目前比較流行的網絡框架有Okhttp，retrofit，volley等等，有興趣的可以自行研究一下。
- 支撐層：支撐層使我們的技術和功能的支撐，這一層的東西很多，我們通用的工具類，或者第三方的分享sdk，推動sdk，或者是通信sdk，如eventbus等。上層的業務可能會用到的，這些都需要沉澱到支撐層來。
- 組件層：這一層一般是通用的自定義組件。
- 業務層：業務層就設計到我們具體的業務了，一般以包名來區分不同的業務。
這四層，我們一般都單獨放在不同的module，網絡層可以和支撐層放在一個module裏面，組件層的module引用支撐層的module，業務層的module引用組件層的module。
這只是一個通用的功能型的app的架構，我們一般都會根據這一基礎，結合自身的業務做擴展，比如業務非常的龐大的，那麼業務層我們可以做插件化或者bundle化。
服務型的app
服務型的app相比於功能性的app，service會更多一點，而業務會相對薄弱一點，所以我們在支撐層和組件層之間多了一個服務層，服務層的service可以是常駐的，也可以是非常駐的，既可以是實現繼承自系統的service服務，也可以是我們自己設計的service服務，我們可以用servicemanager來將服務層中的service服務統一管理起來。
總結
但在實際設計一個大型的App架構，所要考慮的東西遠比上面的多，架構也會比上面的通用的設計要複雜很多。但如果我們能熟悉一般通用的APP的架構設計，對我們在設計需要特殊架構，或者比較複雜的大型的APP的架構時，也會有很多參考價值。