如何設(shè)計(jì)App的架構(gòu)
一、明確App類(lèi)型與特點(diǎn)
在著手設(shè)計(jì)App的整體框架時(shí)，首先要明確我們所開(kāi)發(fā)的App的類(lèi)型和特點(diǎn)。常見(jiàn)的網(wǎng)絡(luò)交互數(shù)據(jù)方式有主動(dòng)請(qǐng)求（http）和長(zhǎng)連接推送兩種。對(duì)于數(shù)據(jù)展示類(lèi)型的App，頁(yè)面多，需頻繁進(jìn)行數(shù)據(jù)交互，主要依賴(lài)http請(qǐng)求；推送模塊如IM類(lèi)型App則更注重長(zhǎng)連接，對(duì)電量和流量消耗較為敏感。手機(jī)助手類(lèi)App主要調(diào)用系統(tǒng)API以輔助管理系統(tǒng)，網(wǎng)絡(luò)調(diào)用以http為主。游戲類(lèi)App一般包含游戲引擎和業(yè)務(wù)邏輯，網(wǎng)絡(luò)以長(zhǎng)連接為主，http為輔。
二、商業(yè)應(yīng)用網(wǎng)絡(luò)調(diào)用流程
對(duì)于大多數(shù)常見(jiàn)的App（類(lèi)型1），其主要工作在于：從服務(wù)端拉取數(shù)據(jù)展示給用戶，以及將用戶在客戶端的修改數(shù)據(jù)上傳至服務(wù)端。網(wǎng)絡(luò)調(diào)用相當(dāng)頻繁，需考慮網(wǎng)絡(luò)狀況不佳或無(wú)網(wǎng)絡(luò)情況下的App運(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ù)并展示。這其中，職責(zé)劃分明確，包括數(shù)據(jù)獲取、數(shù)據(jù)管理及數(shù)據(jù)展示。
三、傳統(tǒng)的Android App架構(gòu)
Android最原生且基礎(chǔ)的架構(gòu)可理解為MVC模式。在傳統(tǒng)的Android App中，Activity和Fragment掌握了Android系統(tǒng)中絕大多數(shù)的資源，并在內(nèi)部直接控制View。一般是以Activity和Fragment為核心，將網(wǎng)絡(luò)模塊、數(shù)據(jù)庫(kù)管理模塊、文件管理模塊、常用工具類(lèi)等分離成若干工具類(lèi)包，供Activity和Fragment使用。這種架構(gòu)是市面上大多數(shù)App所采用的。
四、傳統(tǒng)架構(gòu)的優(yōu)缺點(diǎn)
傳統(tǒng)Android App架構(gòu)的優(yōu)點(diǎn)在于開(kāi)發(fā)簡(jiǎn)單，以頁(yè)面為導(dǎo)向。若水平構(gòu)建得當(dāng)，項(xiàng)目可實(shí)現(xiàn)模塊化。Activity和Fragment作為核心，能迅速處理許多任務(wù)。其缺點(diǎn)也同樣明顯：維護(hù)難度較大，因以頁(yè)面為導(dǎo)向，共用的業(yè)務(wù)邏輯可能變得繁瑣。另一方面，測(cè)試較為困難，因?yàn)樗械臄?shù)據(jù)處理都在Activity和Fragment中進(jìn)行。若需先用假數(shù)據(jù)顯示，則需直接修改Activity和Fragment的數(shù)據(jù)控制邏輯。
五、面臨挑戰(zhàn)與未來(lái)發(fā)展
隨著業(yè)務(wù)復(fù)雜度的提升，Activity和Fragment的代碼量可能會(huì)激增。例如，電商App的購(gòu)物車(chē)功能，若只管理商品，可能僅需幾百行代碼。但隨業(yè)務(wù)的擴(kuò)展，需考慮優(yōu)惠券、滿減、運(yùn)費(fèi)計(jì)算等功能，代碼量可能會(huì)大幅上升。未來(lái)的App架構(gòu)設(shè)計(jì)需考慮如何更好地應(yīng)對(duì)業(yè)務(wù)復(fù)雜性和代碼量的增長(zhǎng)，同時(shí)保持代碼的清晰和可維護(hù)性。
一、Activity與Fragment的角色轉(zhuǎn)變
長(zhǎng)久以來(lái)，Activity和Fragment承擔(dān)了過(guò)多的數(shù)據(jù)處理邏輯，導(dǎo)致代碼繁雜且難以維護(hù)。在重新審視我們的項(xiàng)目后不難發(fā)現(xiàn)，大部分?jǐn)?shù)據(jù)處理工作其實(shí)并不需要直接利用Activity和Fragment的資源。為了解決這一問(wèn)題，我們可以考慮將這些數(shù)據(jù)處理邏輯剝離出來(lái)，交由專(zhuān)門(mén)的層級(jí)處理。
二、引入DataManager層
以一個(gè)典型的User對(duì)象為例，這類(lèi)全局?jǐn)?shù)據(jù)源的應(yīng)用往往伴隨著大量的數(shù)據(jù)處理邏輯。為了提高復(fù)用性并簡(jiǎn)化上層代碼，我們可以抽取出這些數(shù)據(jù)處理邏輯形成一個(gè)新的層次——DataManager層。這一層獨(dú)立于UI，向上層提供數(shù)據(jù)接口，且不涉及數(shù)據(jù)來(lái)源的具體細(xì)節(jié)，如內(nèi)存、緩存或網(wǎng)絡(luò)。Activity和Fragment則通過(guò)與DataManager交互，專(zhuān)注于數(shù)據(jù)的展示和用戶交互。
三、模塊化的數(shù)據(jù)處理架構(gòu)
在開(kāi)發(fā)Android應(yīng)用時(shí)，合理的架構(gòu)至關(guān)重要。除了上述的DataManager層，還有以下關(guān)鍵模塊：
異步下載管理：負(fù)責(zé)JSON、圖像等數(shù)據(jù)的異步下載。
網(wǎng)絡(luò)請(qǐng)求調(diào)度：管理網(wǎng)絡(luò)請(qǐng)求的排序和優(yōu)先級(jí)處理。
緩存機(jī)制：確保數(shù)據(jù)的快速訪問(wèn)并減少網(wǎng)絡(luò)負(fù)載。
多級(jí)別取消請(qǐng)求：確保在必要時(shí)能高效地取消網(wǎng)絡(luò)請(qǐng)求。
還有一些外部庫(kù)如android-async-http，提供了智能重試、gzip壓縮等功能，可以方便地集成到我們的應(yīng)用中。
四、Afinal框架的四大模塊
除了上述架構(gòu)外，Afinal框架為Android開(kāi)發(fā)提供了四大核心模塊：
數(shù)據(jù)庫(kù)模塊：利用線程池操作的ORM框架，簡(jiǎn)化SQLite操作。
注解模塊：IOC框架實(shí)現(xiàn)UI綁定和綁定的注解方式，減少代碼量。
網(wǎng)絡(luò)模塊：通過(guò)httpclient封裝的http數(shù)據(jù)請(qǐng)求，支持ajax加載及文件下載上傳功能。
圖片緩存模塊：通過(guò)FinalBitmap優(yōu)化圖片加載，避免OOM和圖片錯(cuò)位等問(wèn)題。
4. xUtils框架
xUtils框架是Android開(kāi)發(fā)中的一項(xiàng)重要工具，它包含了四大核心模塊，為開(kāi)發(fā)者提供全面的解決方案。
數(shù)據(jù)庫(kù)模塊
這一模塊采用Android中的orm框架，使得數(shù)據(jù)的增刪改查變得異常簡(jiǎn)單，只需一行代碼即可輕松實(shí)現(xiàn)。
注解模塊
此模塊相當(dāng)于Android的ioc框架，完全通過(guò)注解方式進(jìn)行UI、資源和的綁定，大大提高了開(kāi)發(fā)效率和便捷性。
網(wǎng)絡(luò)模塊
網(wǎng)絡(luò)模塊支持同步和異步方式的請(qǐng)求，滿足各種網(wǎng)絡(luò)操作的需求。
圖片緩存模塊
在加載bitmap時(shí)，該模塊能有效解決oom和快速滑動(dòng)時(shí)圖片錯(cuò)位等問(wèn)題，提升用戶體驗(yàn)。
ThinkAndroid的主要模塊
ThinkAndroid是一款功能豐富的Android開(kāi)發(fā)框架，其主要包含以下模塊：
MVC模塊
實(shí)現(xiàn)視圖與模型的分離，使代碼結(jié)構(gòu)更清晰。
ioc模塊
這是Android的ioc模塊，通過(guò)注解方式實(shí)現(xiàn)UI綁定、res中資源的讀取以及對(duì)象的初始化。
數(shù)據(jù)庫(kù)模塊
采用Android中的orm框架，通過(guò)線程池操作sqlite，更加高效和穩(wěn)定。
http模塊
通過(guò)httpclient封裝http數(shù)據(jù)請(qǐng)求，支持異步及同步方式加載。
緩存模塊
設(shè)計(jì)簡(jiǎn)潔，配置隨意，能很好地實(shí)現(xiàn)緩存功能。
圖片緩存模塊
在imageview加載圖片時(shí)，無(wú)需擔(dān)心oom和快速滑動(dòng)時(shí)的圖片錯(cuò)位問(wèn)題。
配置器模塊
簡(jiǎn)易實(shí)現(xiàn)配對(duì)配置的操作，目前支持Preference、Properties存取配置。
日志打印模塊
快速實(shí)現(xiàn)日志打印，支持?jǐn)U展，包括本地打印和控制臺(tái)打印。
下載器模塊
實(shí)現(xiàn)多線程下載、后臺(tái)下載、斷點(diǎn)續(xù)傳等功能，并可以對(duì)下載進(jìn)行控制。
網(wǎng)絡(luò)狀態(tài)檢測(cè)模塊
當(dāng)網(wǎng)絡(luò)狀態(tài)改變時(shí)，進(jìn)行檢測(cè)和調(diào)整。
LoonAndroid的主要模塊
LoonAndroid提供了一系列實(shí)用的開(kāi)發(fā)工具，其主要模塊包括：
自動(dòng)注入框架
只需繼承框架內(nèi)的application即可輕松使用。
圖片加載框架
具有多重緩存和自動(dòng)回收功能，最大限度保證內(nèi)存安全。
網(wǎng)絡(luò)請(qǐng)求模塊
一、客戶端的視頻編解碼方式
在客戶端的視頻處理中，我們常見(jiàn)的編解碼方式包括軟編碼和硬編碼。軟編碼方式以其出色的兼容性和編碼效果著稱(chēng)，但相應(yīng)的，它的能耗較高且處理速度較慢。硬編碼則借助顯卡等硬件資源，能夠?qū)崿F(xiàn)較低的能耗和更快的處理速度，但在兼容性和效果方面稍顯不足，特別是在一些低配的機(jī)型上表現(xiàn)更為明顯。目前多數(shù)采用軟硬結(jié)合的方式，以求在效果和效率之間達(dá)到平衡。
二、服務(wù)端視頻處理要點(diǎn)
服務(wù)端主要負(fù)責(zé)視頻的審核、轉(zhuǎn)碼以及抽幀生成截圖等工作，其中ffmpeg是常用的處理工具。由于視頻處理資源消耗較大，服務(wù)端的機(jī)器數(shù)量需求較多。在服務(wù)端進(jìn)行的視頻處理操作都會(huì)盡量控制在一個(gè)合理的范圍內(nèi)，以提高效率和降低成本。
三、短視頻APP中的音視頻不同步問(wèn)題
在短視頻APP中，音視頻不同步是最令人頭疼的技術(shù)問(wèn)題之一。為解決此問(wèn)題，我們通常采用時(shí)間戳方案。選擇一個(gè)時(shí)間線性遞增的參考時(shí)鐘；然后，在生成數(shù)據(jù)流時(shí)，為每個(gè)數(shù)據(jù)塊打上包括開(kāi)始時(shí)間和結(jié)束時(shí)間的時(shí)間戳；在播放時(shí)，根據(jù)數(shù)據(jù)塊上的時(shí)間戳和當(dāng)前參考時(shí)鐘的時(shí)間來(lái)安排播放。
四、時(shí)間戳的重要性
避免音視頻不同步的關(guān)鍵在于正確的時(shí)間戳。如果數(shù)據(jù)塊上的時(shí)間戳本身存在問(wèn)題，那么無(wú)論怎么調(diào)整播放都無(wú)法解決不同步的問(wèn)題。在生成數(shù)據(jù)流時(shí)，視頻流和音頻流都是參考同一參考時(shí)鐘的時(shí)間，而數(shù)據(jù)流之間并不發(fā)生參考關(guān)系。也就是說(shuō)，視頻流和音頻流是通過(guò)一個(gè)中立的第三方（參考時(shí)鐘）來(lái)實(shí)現(xiàn)同步的。
五、播放時(shí)的數(shù)據(jù)流控制
在播放時(shí)，基于時(shí)間戳的數(shù)據(jù)流控制是解決問(wèn)題的另一個(gè)關(guān)鍵。對(duì)于數(shù)據(jù)塊早到或晚到的情況，需要采取不同的處理方法。只有確保數(shù)據(jù)流按照時(shí)間戳的順序準(zhǔn)確播放，才能避免音視頻不同步的現(xiàn)象，提升用戶體驗(yàn)。
視頻編解碼、服務(wù)端處理以及音視頻同步問(wèn)題都是短視頻APP開(kāi)發(fā)中的關(guān)鍵技術(shù)環(huán)節(jié)。只有深入理解并妥善解決這些問(wèn)題，才能為用戶提供更加優(yōu)質(zhì)、流暢的觀看體驗(yàn)。
