相信大家都有體會(huì)，隨著功能模塊的增加，App越來越大，如果沒有良好的架構(gòu)設(shè)計(jì)，則代碼將會(huì)變得臃腫且不易維護(hù)，各功能模塊的耦合度會(huì)越來越高。因此可以把App模塊化，將一個(gè)完整的App劃分成幾個(gè)相對(duì)獨(dú)立的模塊，這樣即可以降低模塊間的耦合也利于復(fù)用。

?

開發(fā)工具的選擇

開發(fā)工具我將選用AndroidStudio，它是Google官方指定的Android開發(fā)工具，目前是1.2.2穩(wěn)定版，1.3的預(yù)覽版也已經(jīng)發(fā)布了。AndroidStudio的優(yōu)點(diǎn)就不需多說了，GitHub上大部分的Android開源庫也都已遷移到AndroidStudio上來，在未提供jar文件時(shí)，使用AndroidStudio可以極為方便地集成開源庫。最為重要的是Google已宣布將在年底前停止對(duì)EclipseAndroid開發(fā)工具的一切支持（Google?Ends?Support?for?Android?Eclipse?Tools），因此請(qǐng)?jiān)缛辙D(zhuǎn)移到AndroidStudio上來。

App設(shè)計(jì)風(fēng)格

這一點(diǎn)對(duì)于一個(gè)開發(fā)者來說，貌似沒有決定權(quán)，最終的決定權(quán)在產(chǎn)品部門手里。盡管這樣，我還是會(huì)盡力說服產(chǎn)品部門將App設(shè)計(jì)成MaterialDesign風(fēng)格。這一點(diǎn)說多了都是淚啊，作為一個(gè)Android開發(fā)者，卻整天開發(fā)著iOS風(fēng)格的App，相信很多公司都這樣，為了節(jié)省成本和時(shí)間，Android和iOS共用一套UI。舉一個(gè)最常見的例子，AndroidApp中每個(gè)頁面TitleBar的左上角放一個(gè)返回按鈕，這在iOS里是必須的，但Android有返回鍵啊，這樣設(shè)計(jì)對(duì)于Android完全是多此一舉。真心希望產(chǎn)品設(shè)計(jì)者尊重每種操作系統(tǒng)的風(fēng)格及使用習(xí)慣，不要再設(shè)計(jì)不倫不類的產(chǎn)品。MaterialDesign正好提供了一種這樣的規(guī)范，自MD規(guī)范發(fā)布以來，其優(yōu)雅的設(shè)計(jì)和清新的風(fēng)格已吸引了大批設(shè)計(jì)者和開發(fā)者，如今MD設(shè)計(jì)不止在Android上（已有官方類庫支持MD風(fēng)格），甚至在CSS、HTML、JavaScript網(wǎng)頁設(shè)計(jì)上都越來越火。因此，對(duì)于App的設(shè)計(jì)風(fēng)格，MaterialDesign當(dāng)仁不讓，也許你曾經(jīng)錯(cuò)過了AndroidDesign，請(qǐng)不要再錯(cuò)過Material?Design。安卓

一些相關(guān)的鏈接：

Material?Design官網(wǎng)

Material?Design配色模板

MD一個(gè)設(shè)計(jì)案例網(wǎng)站

MD風(fēng)格的Andorid抽屜源碼：Android-MaterialDesign-NavigationDrawer

MD風(fēng)格的一個(gè)App源碼（有妹子哦）：Android-MaterialDesign-DBMZ

版本支持

對(duì)于Android要支持的最低版本，可以參考各個(gè)版本的市場(chǎng)占有率，其實(shí)最靠譜的是根據(jù)自家App的統(tǒng)計(jì)數(shù)據(jù)來決定，目前我們的App最低支持2.2。以個(gè)人觀點(diǎn)認(rèn)為，雖然2.x的版本仍然有一部分用戶，但其實(shí)手機(jī)更新?lián)Q代特別快，為了更好的用戶體驗(yàn)，也為了應(yīng)用更新的API（很多第三方庫也都有版本要求），應(yīng)該提高最低支持的版本，大概3.0為宜，即API?Level為11。

App框架設(shè)計(jì)

相信大家都有體會(huì)，隨著功能模塊的增加，App越來越大，如果沒有良好的架構(gòu)設(shè)計(jì)，則代碼將會(huì)變得臃腫且不易維護(hù)，各功能模塊的耦合度會(huì)越來越高。因此可以把App模塊化，將一個(gè)完整的App劃分成幾個(gè)相對(duì)獨(dú)立的模塊，這樣即可以降低模塊間的耦合也利于復(fù)用。

1.網(wǎng)絡(luò)模塊

已經(jīng)很少有單機(jī)版的App了吧，大部分都需要聯(lián)網(wǎng)，從服務(wù)器請(qǐng)求數(shù)據(jù)，因此網(wǎng)絡(luò)模模塊必不可少。GitHub上的開源網(wǎng)絡(luò)框架也特別多，個(gè)人認(rèn)為可以使用開源框架，目前我會(huì)選okHttp或者Volley，也許以后會(huì)有更好的網(wǎng)絡(luò)框架出現(xiàn)。注意如果使用開源框架，則必須要閱讀其源碼，必須能夠駕馭它，這樣就不至于當(dāng)bug出現(xiàn)時(shí)束手無策。當(dāng)然還可以自己寫網(wǎng)絡(luò)模塊，目前我們的App網(wǎng)絡(luò)模塊就完全是自己寫的，這樣的好處是自己熟悉所寫的代碼，當(dāng)有bug時(shí)可以迅速定位問題，同時(shí)注意處理一些聯(lián)網(wǎng)過程中的細(xì)節(jié)，如：

（1）對(duì)HTTPS的支持、HTTPS證書的驗(yàn)證（目前很多做法都是默認(rèn)允許所有HTTPS證書的，其實(shí)這樣做是不安全的，應(yīng)當(dāng)真正地做證書校驗(yàn)）

（2）支持Wap方式上網(wǎng)，移動(dòng)、聯(lián)通、電信代理的設(shè)置

（3）支持重定向、數(shù)據(jù)壓縮傳輸?shù)?/p>

（4）其他值得注意的問題

自己寫網(wǎng)絡(luò)框架可以完美地處理這些細(xì)節(jié)，但時(shí)間成本比較大。如果使用開源框架，一般都沒有處理這些細(xì)節(jié)，因此我們可以在第三方框架上做些修改，這樣時(shí)間成本將會(huì)節(jié)省很多。

2.圖片管理模塊

圖片也是App中不可少的元素，而且圖片是占用內(nèi)存的大戶，因此圖片管理框架特別重要，不好的圖片框架容易引起內(nèi)存泄露甚至導(dǎo)致崩潰。當(dāng)然可以自己實(shí)現(xiàn)圖片框架（目前我們也是這樣做的），實(shí)現(xiàn)圖片的下載、解碼、緩存等關(guān)鍵環(huán)節(jié)。個(gè)人建議可以采用一些比較好的圖片庫，也許會(huì)比我們自己管理圖片更完善和高效。我會(huì)推薦如下幾個(gè)圖片管理庫：

（1）Glide，Google的一些官方App，如Googlephotos都使用了，還要解釋更多嗎？

（2）Fresco，F(xiàn)aceBook的開源庫，功能超級(jí)強(qiáng)大，支持WebP、Gif、JPEG漸進(jìn)顯示，關(guān)鍵是其對(duì)圖片內(nèi)存的設(shè)計(jì)思想，使得圖片內(nèi)存開銷大大減少。

（3）Android-Universal-Image-Loader，在出現(xiàn)上述圖片庫之前，貌似這個(gè)最火吧，之前個(gè)人的App中也用了它。app推廣

（4）Picasso，Square的開源庫，據(jù)說Glide就是參考Picasso設(shè)計(jì)的。

3.本地?cái)?shù)據(jù)庫模塊

也許你的App需要用到本地?cái)?shù)據(jù)庫，那么建議你采用流行的ORM框架，如ActiveAndroid或greenDAO，使用第三方庫會(huì)大大方便你對(duì)sqlite的操作，個(gè)人認(rèn)為在使用中我們需要注意數(shù)據(jù)庫升級(jí)以及多線程并發(fā)操作數(shù)據(jù)庫的問題。

4.文件管理模塊

一個(gè)App，肯定會(huì)涉及到一些文件，如配置文件、圖片、視頻、音頻、SharedPreferences文件等。我們可以提供一個(gè)全局的文件管理模塊，負(fù)責(zé)文件的增、刪、改、查等操作。另外還需支持文件壓縮，文件的上傳與下載操作，對(duì)于下載需要支持多線程并發(fā)下載、斷點(diǎn)續(xù)傳等功能。

5.組件內(nèi)、組件間通信機(jī)制

對(duì)于一個(gè)App，組件通信必不可少，通信類型可以分為點(diǎn)對(duì)點(diǎn)和點(diǎn)對(duì)面的的通信，點(diǎn)對(duì)點(diǎn)即只有唯一的接收者可以響應(yīng)消息，點(diǎn)對(duì)面則類似于消息廣播，即所有注冊(cè)過的都可以響應(yīng)消息。在Android中，通常使用消息機(jī)制來實(shí)現(xiàn)，但消息機(jī)制的耦合度比較高。目前也有一些通信框架，如EventBus、Otto等事件總線框架，這些框架可以極大地降低組件間的耦合，但無法完美地實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)通信，因此建議消息機(jī)制和事件總線機(jī)制結(jié)合使用。移動(dòng)營(yíng)銷

6.數(shù)據(jù)處理框架

其實(shí)還應(yīng)該有一個(gè)數(shù)據(jù)處理框架，當(dāng)發(fā)出數(shù)據(jù)請(qǐng)求后（走子線程），經(jīng)網(wǎng)絡(luò)模塊返回?cái)?shù)據(jù)（一般為JSON格式），JSON數(shù)據(jù)一般不能直接交給View層使用，需要解析成對(duì)應(yīng)的Model，同時(shí)如有需要，還要緩存數(shù)據(jù)，因此這些流程可以抽象成一個(gè)數(shù)據(jù)處理的框架。這個(gè)框架可以認(rèn)為接受數(shù)據(jù)請(qǐng)求的url，并將數(shù)據(jù)Model返回給Activity或Fragment。對(duì)于JSON數(shù)據(jù)解析，建議使用fastjson，速度快且穩(wěn)定，缺省值也比較完善。

7.線程調(diào)度模塊

其實(shí)Android中有很多操作，如請(qǐng)求數(shù)據(jù)、下載圖片、清除緩存等都是需要在子線程中執(zhí)行的，往往很多時(shí)候都是直接起一個(gè)Thread來做了，這樣做就會(huì)很亂而且線程多了將難以管理。因此可以抽象出一個(gè)線程調(diào)度模塊，它維護(hù)一個(gè)線程池，如果有需要線程的話就通過線程調(diào)度模塊取線程來做，這樣就方便統(tǒng)一管理。當(dāng)然第三方庫中的線程操作我們將無法歸到線程調(diào)度模塊來管理，但其他涉及到線程的操作都應(yīng)該來統(tǒng)一處理。

8.業(yè)務(wù)層

業(yè)務(wù)層大概就是四大組件、Fragment、View了，建議盡可能地使用原生組件，少用自定義組件，因?yàn)樵M件性能是最好的。另外建議使用MVC模式就好，只要設(shè)計(jì)管理好自己的邏輯，至于MVP、MVVM等模式個(gè)人認(rèn)為都有缺陷，總之尋求一個(gè)折中吧，有得必有失。app營(yíng)銷

9.APK動(dòng)態(tài)加載機(jī)制

隨著App的增大，功能的擴(kuò)展，很多App已經(jīng)采用了APK動(dòng)態(tài)加載的機(jī)制，也可以叫做插件化。由于本人沒有在實(shí)際的App中應(yīng)用過，所以不便發(fā)表過多評(píng)論。但這種機(jī)制個(gè)人認(rèn)為很有前途，這種機(jī)制將利于App的解耦、功能擴(kuò)展和局部升級(jí)。具體可以參考一個(gè)商用的解決方案：ApkPlug-移動(dòng)應(yīng)用模塊化解決方案和一個(gè)開源的APK動(dòng)態(tài)加載框架。

10.App的安全性考慮

AndroidApp的安全問題很少有人重視，但這的確是一個(gè)很嚴(yán)重的問題，一些好的App經(jīng)常被人破解。建議將一些核心算法等寫成.so庫，重要的邏輯放在服務(wù)器端，數(shù)據(jù)請(qǐng)求采用加密等，另外打包APK時(shí)至少要混淆代碼，還可以采用APK加殼機(jī)制，總之這類的防范措施永遠(yuǎn)不嫌多。

如今互聯(lián)網(wǎng)上，量只需要0.1元一個(gè)A，市場(chǎng)上絕對(duì)最低的價(jià)格。同時(shí)在上量，一對(duì)一的客服幫助，全自動(dòng)操作，完全保密，技術(shù)時(shí)時(shí)配合，用戶可以反饋質(zhì)量效果，方面也會(huì)虛心接受用戶建議，把量服務(wù)做得更好。