在Android開發過程中搭建一個自己的應用框架有幾個步驟？需要注意什麼？

01-04

如:對application/baseactivity，圖片載入，資料庫等進行分析，謝謝

每個人對應用框架的理解不相同，但是最終達到的效果應該是一樣：

降低項目的複雜性
易擴展、易修改、可重用性強、可維護性強
職責單一，功能清晰

在android開發項目中，我們首先要考慮的是這個項目或者說這個產品的核心功能是什麼。比如，圖片處理和展示類app,我們更多考慮對大量圖片的處理，防止OOM等等；如果是理財營銷類軟體，比如微眾銀行、同花順這種大量採用H5頁面的app,考慮需要對webview控制項優化和Js交互框架的搭建；總之，框架是為了便於業務的展開，是為業務而服務的，框架的選擇是和業務需求緊密相連的。

那麼有沒有一些通用的東西可以抽取呢？從自己的一些實踐經驗來回答題主的一些問題，權當拋磚引玉。

項目工程搭建

App工程結構搭建：幾種常見Android代碼架構分析總結了一些關於項目工程搭建的範例。我們在搭建工程結構的時候可以盡量抽取一些共用的東西，例如，資料庫操作、base、task、事件觀察者、通用的工具類、UI公共組件等等，這些東西應該表現在代碼結構中。

這些包名的作用一目了然，在別人接手這個項目的時候就會相對簡單。

adapter 適配器，如果業務複雜，根據不同的業務可以添加子包來進行分類；
base 用來存放View的基類，例如BaseAcitivity、BaseFragment，甚至可以添加某些不同actionbar主題的Base類；
common 當然是存放一些共用的配置類信息，常量等等；
controller 控制器，將一部分的業務類需求放到裡面，充當db和View交互的中間層，減少Activity中業務的複雜性；
db資料庫類
event 觀察者模式，事件通知；
task一些AsyncTask任務類
view一些自定義組件
vo 值對象，其實就是給各個組件使用的對象，比如ListView的Item對象等等
widget UI界面
AppContext 自定義Application類

另外，根據自己的一些業務需求，我們可能需要單獨的抽取一些核心的包類。比如，理財類軟體在搭建工程結構的時候，可以單獨抽出了2個JS相關的核心包類：

2.AppContext 的處理

Application本身在一個應用中只會存在一個實例，所以它一般用來存儲一些全局的變數和一些只需要處理一次的數據。

context的管理。這個和BaseActivity組合使用，將每一個Activity放到一個列表中，需要的時候直接使用即可；

初始化和記錄一些app信息，例如app的版本信息、設備信息等等；
初始化特定的業務需求，例如有盟統計類、分享SDK、推送等等
記錄應用啟動次數、是否第一次安裝等等，如果在第一個版本不加，到後面版本使用次記錄會很麻煩（血淚教訓……）
記錄是否開啟處於調試模式。

在輸出日誌、錯誤消息的時候有用。

public final static boolean DEBUG=BuildConfig.DEBUG;

3.Base的處理

對BaseActivity的處理好壞一定程度上會影響項目的代碼可讀性，在Base裡面做一些規範化處理將會大大減少代碼的書寫量和提高可讀性。

將其Base類定義成抽象類，增加一些抽象方法，例如findView的處理、onClick的處理、初始化數據的處理。例如可以重載setContentView方法來規範子類的行為：

@Override public void setContentView(int layoutResID) { super.setContentView(layoutResID); findView(); initView(); setOnClick(); } /** * 獲取布局控制項 */ protected abstract void findView();


    /**

     * 初始化View的一些數據

     */

    protected abstract void initView();

/** * 設置點擊監聽 */ protected abstract void setOnClick();

通過這種規範可以大大減少後期代碼的混亂，onCreat方法中存在大量雜亂無章的代碼;

添加觀察者模式的支持。具體的可以看我的博客觀察者模式在android 上的最佳實踐
定義一些ActionBar上面的保護類方法，比如返回按鈕、下拉事件等等;

4.資料庫的處理

個人建議在處理資料庫的時候採用ContentProvider的方式，有2個優點：

採用URI的方式訪問，更加符合我們的使用習慣；
隨時可以提供給其它應用訪問資料庫；

5.圖片的處理

對圖片處理的文章很多，其實你只要把基本的一些開源框架原理搞清楚，對普通應用其實足夠了。

最近在做一個開源項目daliyan/MyBlog · GitHub 需要的可以參考參考，期待大牛的回答。

這幾天沒事在找一些比較酷炫的效果，畢竟App也要看臉=_=,就放幾個絕對乾貨吧。

material icon lib:code-mc/material-icon-lib · GitHub,可不是官方圖標集合哦，庫簡介：Library containing over 1000 material vector icons that can be easily used as Drawable or as a standalone View.

List of Android UI/UX Libraries：wasabeef/awesome-android-ui · GitHub，反正我見沒見過，做沒做過的效果全在這兒看到了，精美可用的loading anim,圖表控制項，特效什麼的全收集了。

盡情使用吧！

---------------------原答案-----------------------------------------

回答的好少啊，我先拋磚引玉一下吧。

Application,BaseActivity這個沒什麼好說的，但是一定要熟練，太常用了。

想快速寫App:

繼承Application類（存放全局數據，注意同步，一些SDK也要求在這初始化）

+創建BaseActivity（做好頁面的緩存策略，別對Bundle savedInstanceState視而不見）

+Volley（網路通信）

+Fresco（圖片載入）

+ORMLite（ORM,不多說）

+EventBus(為了解耦)

1、在搭自己的框架之前，你需要熟練應用別人的框架。用多了別人的框架，自己再寫的時候，就可以想怎麼做可能像別人的那樣易用。

2、設計模式的熟練應用，為了自己好寫（易拓展），別人好用（易定製）。

單例模式進行初始化，防止資源泄露。

像IM類、音視頻通信類、通用的網路請求等框架，都需要全局的一個初始化，一般涉及到後台的一個獨立進程或線程。舉一個具體的栗子,Volley的使用：

mRequestQueue = Volley.newRequestQueue(this);

一個典型的單例模式，我們看一下Volley的源碼，它的裡面確實不像一般的單利模式寫法：

注意到一個queue.start();//請求隊列的start

跟進去：

一個stop(),是不是算一個單例啊？

不用猜了，下面的那些調用start()方法的實例全是線程實例。

抽象工廠模式進行最外層的包裝，主要照顧老用戶。

在框架升級時，增添一個新的FactoryMethod就可以了，API介面基本不許變動。

比如，我要做一個音視頻處理工具，原來只有音頻處理能力：

AudioVideoProcessor audioProcessor = AudioVideoProcessorFactory.CreateAudioProcessor();//抽象工廠創建 audioProcessor.openFile(...);//打開文件 audioProcessor.encode(EncodeEnginer encoderEnginer);//調用編碼器 audioProcessor.sendRtpStream(...);//發送Rtp流

我現在也做了視頻處理部分，那就只需要加一個新的工廠方法就可以了，其他API不需要變動。

建造者模式滿足小白與高階用戶。

小白用戶有上面的抽象工廠創建實例，直接調用，做個demo騙騙導師，水水論文結果神馬的還是不錯的！

但我們對於一些高階的用戶需要一些有逼格的功能，他們在做產品中需要更多的個性化，這時候就應該拿出建造者模式了，接著上面的例子：

AudioVideoProcessorBuilder audioVideoProcessorBuilder = new AudioVideoProcessorBuilder()//建造者模型精細的把握各項參數 .setResize(ResizeStyleOptions.W_H_16_9)//長寬比 .setMaxBitrate(BitRateOptions.64_K)//碼流率 .setP2PMode(P2PModeOptions.NAT);//p2p穿透方式 AudioVideoProcessor videoProcessor = audioVideoProcessorBuilder.getVideoProcessor();

是不是人民群眾喜聞樂見的庫的調用方式！

策略模式進行容錯處理。

為了框架使用者不罵你，多樣化的容錯處理是必要的。

再次拿Volley開刀！

對於Volley這樣的網路請求框架來說，必要的重連機制是必不可少的，你看：

當然，再次照顧小白（主要水作業的學生黨），Volley也提供了

默認的重連策略。

容錯的具體處理委託給這些策略類。

目前就想到這麼多，其他的再補。

參考Jake大神的u2020項目吧

上面推薦的wasabeef/awesome-android-ui · GitHub，跪了，太全了，1！萬！個！贊！

可參考 http://www.github.com/huntermr/FastAndroid

我寫的一個東西，可以作為參考，有興趣的可以一起寫zhaozepeng/Android_framework · GitHub

個人認為開源中國的開源客戶端也是一個很好的學習資源.

虔誠拜讀，大牛們的言論回答可謂簡潔精闢，作為現在還是技術渣的我，很有啟發。