Android應(yīng)用開(kāi)發(fā)中的架構(gòu)概覽

一、異步下載與網(wǎng)絡(luò)請(qǐng)求架構(gòu)

在Android應(yīng)用開(kāi)發(fā)中，架構(gòu)的搭建至關(guān)重要。我們關(guān)注異步下載和網(wǎng)絡(luò)請(qǐng)求模塊。這主要包括JSON、圖像等的異步下載，網(wǎng)絡(luò)請(qǐng)求的排序（scheduling），優(yōu)先級(jí)處理，以及多級(jí)別取消請(qǐng)求等功能。這些模塊確保了應(yīng)用在網(wǎng)絡(luò)交互方面的穩(wěn)定性和效率。

二、android-async-http的特點(diǎn)

android-async-http庫(kù)提供了強(qiáng)大的網(wǎng)絡(luò)請(qǐng)求功能。它支持在匿名回調(diào)中處理請(qǐng)求結(jié)果，確保UI線程不受阻塞。它還支持文件斷點(diǎn)上傳、智能重試、默認(rèn)gzip壓縮，并能將響應(yīng)解析成Json格式。更值得一提的是，它可以將Cookies持久化到SharedPreferences，提升網(wǎng)絡(luò)請(qǐng)求的管理效率。

三、Afinal框架的四大模塊

Afinal框架在Android開(kāi)發(fā)中是相當(dāng)實(shí)用的工具。其數(shù)據(jù)庫(kù)模塊采用orm框架，使用線程池操作sqlite，使得數(shù)據(jù)庫(kù)操作更為高效。注解模塊則是一個(gè)ioc框架，通過(guò)注解就能實(shí)現(xiàn)UI綁定和綁定，簡(jiǎn)化開(kāi)發(fā)流程。網(wǎng)絡(luò)模塊通過(guò)httpclient封裝http數(shù)據(jù)請(qǐng)求，支持ajax方式加載及文件下載、上傳功能。而圖片緩存模塊則能有效解決bitmap加載過(guò)程中的oom問(wèn)題和快速滑動(dòng)時(shí)的圖片錯(cuò)位現(xiàn)象。

四、xUtils框架的主要功能

xUtils框架在Android開(kāi)發(fā)中同樣受到廣泛歡迎。其數(shù)據(jù)庫(kù)模塊同樣采用orm框架，只需一行代碼就能完成增刪改查。注解模塊是一個(gè)ioc框架，通過(guò)注解綁定UI、資源和。網(wǎng)絡(luò)模塊支持同步和異步請(qǐng)求。圖片緩存模塊則能有效處理bitmap加載過(guò)程中的各種問(wèn)題。它還包括了如MVC模塊和http模塊等，豐富了開(kāi)發(fā)者的選擇。

五、ThinkAndroid的核心模塊

ThinkAndroid是一個(gè)集成了多種功能的開(kāi)發(fā)框架。它實(shí)現(xiàn)了MVC架構(gòu)，使視圖與模型分離，提高了代碼的可維護(hù)性。ioc模塊通過(guò)注解方式實(shí)現(xiàn)UI綁定、資源讀取和對(duì)象初始化。數(shù)據(jù)庫(kù)模塊采用orm框架操作sqlite。http模塊則通過(guò)httpclient封裝http請(qǐng)求，支持異步及同步方式加載，滿足了不同的網(wǎng)絡(luò)需求。 這些架構(gòu)和框架為Android應(yīng)用開(kāi)發(fā)提供了強(qiáng)大的支持，開(kāi)發(fā)者可以根據(jù)項(xiàng)目的具體需求選擇合適的工具，提升開(kāi)發(fā)效率和應(yīng)用性能。LoonAndroid的核心模塊及其特點(diǎn)

自動(dòng)注入框架

只需繼承框架內(nèi)的application，即可輕松實(shí)現(xiàn)各種功能，簡(jiǎn)化開(kāi)發(fā)流程。

圖片加載框架

具備多重緩存機(jī)制，自動(dòng)回收不再使用的圖片資源，確保內(nèi)存安全，有效避免OOM和圖片錯(cuò)位等問(wèn)題。

網(wǎng)絡(luò)請(qǐng)求模塊

集成幾乎所有常用的HTTP請(qǐng)求方式，滿足應(yīng)用與網(wǎng)絡(luò)服務(wù)的通信需求。

其他集成模塊

集成了eventbus、驗(yàn)證框架、json解析器等，增強(qiáng)應(yīng)用的功能性和效率。

緩存模塊

通過(guò)簡(jiǎn)單的配置和設(shè)計(jì)，可實(shí)現(xiàn)高效的緩存功能，對(duì)緩存進(jìn)行靈活配置，滿足各種使用需求。

圖片緩存模塊

ImageView加載圖片時(shí)，無(wú)需擔(dān)心圖片加載過(guò)程中的OOM問(wèn)題，以及快速滑動(dòng)時(shí)出現(xiàn)的圖片錯(cuò)位現(xiàn)象。

配置器模塊

簡(jiǎn)化配置操作，目前支持Preference、Properties等配置文件，方便存取配置信息。

日志打印模塊

快速實(shí)現(xiàn)日志打印功能，并支持日志打印的擴(kuò)展，包括本地寫入sdcard和控制臺(tái)打印。

下載器模塊

具備多線程下載、后臺(tái)下載功能，支持?jǐn)帱c(diǎn)續(xù)傳，并可對(duì)下載進(jìn)行如開(kāi)始、暫停、刪除等操作。

網(wǎng)絡(luò)狀態(tài)檢測(cè)模塊

當(dāng)網(wǎng)絡(luò)狀態(tài)改變時(shí)，能夠進(jìn)行檢測(cè)和反饋，確保應(yīng)用在網(wǎng)絡(luò)變化時(shí)仍能良好運(yùn)行。

數(shù)據(jù)庫(kù)模塊

提供數(shù)據(jù)庫(kù)支持，具體實(shí)現(xiàn)可能由不同的開(kāi)發(fā)者完成，為應(yīng)用提供數(shù)據(jù)存儲(chǔ)和查詢功能。

關(guān)于制作APP的費(fèi)用：

制作一個(gè)APP的費(fèi)用因需求、復(fù)雜度和開(kāi)發(fā)團(tuán)隊(duì)的質(zhì)量等因素而異。簡(jiǎn)單的生活應(yīng)用APP，包括設(shè)計(jì)和開(kāi)發(fā)，費(fèi)用可能在3萬(wàn)到10萬(wàn)之間。對(duì)于游戲APP，特別是純單機(jī)游戲，費(fèi)用可能在5萬(wàn)到10萬(wàn)之間。對(duì)于復(fù)雜的前后臺(tái)APP，開(kāi)發(fā)成本較高，至少需要8萬(wàn)，并且可能需要多次升級(jí)才能達(dá)到較高的可用性。這樣的項(xiàng)目需要一個(gè)包括項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、UI設(shè)計(jì)師、iOS開(kāi)發(fā)工程師、Android開(kāi)發(fā)工程師、服務(wù)端開(kāi)發(fā)工程師、測(cè)試工程師和運(yùn)維工程師的完整團(tuán)隊(duì)，開(kāi)發(fā)周期可能在3到5個(gè)月，費(fèi)用可能在10萬(wàn)到20萬(wàn)之間。

App從原型到成品：團(tuán)隊(duì)協(xié)同與架構(gòu)設(shè)計(jì)的探索

一、初創(chuàng)階段：原型與效果的誕生

當(dāng)產(chǎn)品經(jīng)理繪制出App的原型圖后，設(shè)計(jì)師便接過(guò)接力棒，以巧手繪制出令人眼前一亮的效果圖。這一切，旨在為那個(gè)尚在藍(lán)圖中的App描繪出未來(lái)的模樣。而在這背后，大約三個(gè)月的開(kāi)發(fā)周期里，程序員們將開(kāi)始他們的編碼之旅，將App的各項(xiàng)功能一點(diǎn)點(diǎn)實(shí)現(xiàn)。商用App的開(kāi)發(fā)成本，通常從20萬(wàn)起步。

二、明確方向：App的類型與特點(diǎn)

在探討如何設(shè)計(jì)App架構(gòu)之前，我們首先要明白自己正在打造的是哪種類型的App。網(wǎng)絡(luò)交互數(shù)據(jù)的方式主要有兩種：主動(dòng)請(qǐng)求（http）與長(zhǎng)連接推送。根據(jù)這兩種方式，我們可以將開(kāi)發(fā)的App劃分為不同類型。

對(duì)于數(shù)據(jù)展示類型的App，頁(yè)面眾多，需要與后端頻繁進(jìn)行數(shù)據(jù)交互，主要依賴http請(qǐng)求。而推送模塊，特別是在即時(shí)通訊（IM）類App中，長(zhǎng)連接的使用則更為關(guān)鍵。這類App對(duì)電量和流量消耗較為敏感。

手機(jī)助手類App主要圍繞系統(tǒng)API的調(diào)用，旨在輔助管理系統(tǒng)，網(wǎng)絡(luò)調(diào)用以http為主。

至于游戲類App，一般分為游戲引擎和業(yè)務(wù)邏輯兩部分，業(yè)務(wù)邏輯多通過(guò)腳本編寫，網(wǎng)絡(luò)則以長(zhǎng)連接為主，http為輔。

大部分App可歸為第一類：即服務(wù)端數(shù)據(jù)的展示、用戶數(shù)據(jù)的上傳。這意味著網(wǎng)絡(luò)調(diào)用的頻繁性，還需考慮網(wǎng)絡(luò)波動(dòng)或無(wú)網(wǎng)絡(luò)情況下的運(yùn)行流程。成熟的商業(yè)應(yīng)用的網(wǎng)絡(luò)調(diào)用流程大致為：UI發(fā)起請(qǐng)求-檢查緩存-調(diào)用網(wǎng)絡(luò)模塊-解析返回JSON/統(tǒng)一處理異常- JSON對(duì)象映射為Java對(duì)象-緩存- UI獲取數(shù)據(jù)并展示。這其中，數(shù)據(jù)獲取、數(shù)據(jù)管理、數(shù)據(jù)展示三大職責(zé)明確。

三、基礎(chǔ)架構(gòu)：Android App的架構(gòu)設(shè)計(jì)探索

對(duì)于Android App而言，最基礎(chǔ)、最原生的架構(gòu)可理解為MVC。在Android系統(tǒng)中，Activity和Fragment掌握著絕大多數(shù)的資源，并直接控制View。傳統(tǒng)的Android App架構(gòu)通常以Activity和Fragment為核心。網(wǎng)絡(luò)模塊、數(shù)據(jù)庫(kù)管理模塊、文件管理模塊以及常用工具類等都被分離成若干工具類包，供Activity和Fragment調(diào)用。

這種架構(gòu)的優(yōu)點(diǎn)在于開(kāi)發(fā)簡(jiǎn)單，以頁(yè)面為導(dǎo)向。若開(kāi)發(fā)者水平到位，項(xiàng)目能夠?qū)崿F(xiàn)模塊化。隨著業(yè)務(wù)邏輯的復(fù)雜化，維護(hù)難度加大，測(cè)試也變得困難。當(dāng)業(yè)務(wù)邏輯增多時(shí)，Activity和Fragment的代碼量可能激增。

面對(duì)這些問(wèn)題，開(kāi)發(fā)者需要尋求更高效的解決方案，如采用更先進(jìn)的架構(gòu)模式、進(jìn)行代碼重構(gòu)、引入模塊化開(kāi)發(fā)等策略，以適應(yīng)日益復(fù)雜的業(yè)務(wù)需求。

從原型到成品，從架構(gòu)設(shè)計(jì)到團(tuán)隊(duì)協(xié)同，每一個(gè)環(huán)節(jié)都凝聚著開(kāi)發(fā)者的智慧與努力。只有不斷優(yōu)化流程、提升技能、適應(yīng)變化，才能打造出優(yōu)秀的App產(chǎn)品。重構(gòu)項(xiàng)目架構(gòu)：從數(shù)據(jù)處理角度解析Activity與Fragment的角色轉(zhuǎn)變

一、問(wèn)題的發(fā)現(xiàn)

在分析和優(yōu)化項(xiàng)目的過(guò)程中，我們發(fā)現(xiàn)一個(gè)顯著的痛點(diǎn)：Activity和Fragment承擔(dān)了過(guò)多的數(shù)據(jù)處理邏輯。這導(dǎo)致代碼結(jié)構(gòu)混亂，難以維護(hù)，且不利于復(fù)用。我們需要重新審視Activity和Fragment的角色定位。

二、分層架構(gòu)的引入

在多數(shù)項(xiàng)目中，數(shù)據(jù)處理是一個(gè)核心環(huán)節(jié)。當(dāng)我們深入研究自己的項(xiàng)目時(shí)，會(huì)發(fā)現(xiàn)許多數(shù)據(jù)處理代碼并不需要Activity和Fragment的資源。多個(gè)頁(yè)面往往需要共享數(shù)據(jù)和請(qǐng)求邏輯。例如，應(yīng)用中的User對(duì)象通常是全局單例?；诖耍覀?cè)O(shè)想將數(shù)據(jù)處理的邏輯統(tǒng)一抽取出來(lái)，形成一個(gè)獨(dú)立的數(shù)據(jù)管理層——DataManager層。這一層專注于數(shù)據(jù)處理，不依賴于具體的UI界面，極大地提升了代碼復(fù)用性。

三、DataManager層的構(gòu)建

DataManager層作為中間層，負(fù)責(zé)處理所有與數(shù)據(jù)相關(guān)的操作。它不關(guān)心數(shù)據(jù)的具體來(lái)源，無(wú)論是內(nèi)存、緩存還是網(wǎng)絡(luò)。這一層的主要任務(wù)是集中處理數(shù)據(jù)，向上層提供數(shù)據(jù)接口。這樣，Activity和Fragment便不再承擔(dān)數(shù)據(jù)處理的職責(zé)，從而專注于數(shù)據(jù)的獲取與展示。

四、項(xiàng)目包結(jié)構(gòu)的調(diào)整

在項(xiàng)目中實(shí)施上述架構(gòu)調(diào)整時(shí)，我們需要對(duì)包結(jié)構(gòu)進(jìn)行相應(yīng)調(diào)整。將數(shù)據(jù)處理相關(guān)的代碼統(tǒng)一放置在DataManager層，確保Activity和Fragment的代碼中不再涉及數(shù)據(jù)處理邏輯。通過(guò)清晰的包結(jié)構(gòu)劃分，項(xiàng)目代碼將更具可讀性、可維護(hù)性。這也為后續(xù)的擴(kuò)展和維護(hù)打下了堅(jiān)實(shí)的基礎(chǔ)。

五、Activity和Fragment的新角色

經(jīng)過(guò)重構(gòu)后，Activity和Fragment將專注于數(shù)據(jù)的展示和用戶交互。它們持有DataManager的引用，負(fù)責(zé)從DataManager中獲取數(shù)據(jù)并展示給用戶，同時(shí)向DataManager傳遞用戶輸入的數(shù)據(jù)。在這一新的角色定位下，Activity和Fragment不再進(jìn)行網(wǎng)絡(luò)請(qǐng)求和緩存讀寫等數(shù)據(jù)處理操作，從而實(shí)現(xiàn)了職責(zé)的清晰劃分。這樣的設(shè)計(jì)使得代碼更加簡(jiǎn)潔、高效，更易于維護(hù)和擴(kuò)展。