Android上絕大多數(shù)的代碼，都是由事件觸發(fā)的，或者說，幾乎所有代碼都是寫在某個回調(diào)上的，比如onCreate, onPause, onClick，onBind等等，而這些回調(diào)函數(shù)，全都是一個個的函數(shù)，也就是說，是一個一個小的過程。

單個事件內(nèi)完成的功能

對于一些簡單的情況，在某一個回調(diào)內(nèi)部就能完成的事件，大致上都是在回調(diào)中創(chuàng)建一個A類的對象，然后調(diào)用A類的某個方法，這個方法里面又用到了B類和C類的對象，經(jīng)過了一系列翻云覆雨的計算，我們最終得到了一些數(shù)據(jù)，用TextView顯示了出來，比如點擊一個按鈕彈出一個Toast顯示當(dāng)前軟件的版本號這樣的功能，只需要一個onClick就可以完成。所以我們可以粗暴的理解為，所有面向?qū)ο螅际腔谶^程的。因為只有一系列對象，按照某種特定的順序組織起來，調(diào)用里面特定的方法，才能得出一個有意義的功能。這也解釋了為什么很多SDK，就給你個方法，告訴你，你什么都不用管，在Application的onCreate里面調(diào)一下這個方法就好了。

理論上任何一個功能都可以用一個方法來完成多個事件配合完成的功能

再比如一些稍微復(fù)雜一點的功能，需要多個事件配合，比如計算器，當(dāng)用戶按下第一個數(shù)字的時候，觸發(fā)了onClick事件，你要把這個數(shù)字保存為activity的某個字段，接著，用戶按下了加號和第二個數(shù)字，你都要這樣保存起來，以便于在最終用戶按下等號的時候，你能把以前的一系列輸入獲取到，以計算出一個結(jié)果。也就是說，當(dāng)一個功能需要多個事件配合完成的時候，我們做的事情就是把各個事件的最終結(jié)果從局部作用域提升為類的字段，即提升可見性。當(dāng)可見性不那么好提升的時候，垃圾代碼就出現(xiàn)了。比如這樣的代碼：

五行缺Context

Context是非常常用的一個對象，無論是發(fā)廣播，還是啟動activity，啟動Service，獲取SharedPreferences，獲取資源等等，許多地方都需要用到context，加上Application對象一直存在，于是就想出了這么個辦法。

我并不反對通過提升可見性來實現(xiàn)多個事件之間的配合，比如計算器的例子，提升可見性就是一個簡潔優(yōu)雅的解決方案。但是很多時候為了提升某些字段的可見性，將字段設(shè)置為靜態(tài)字段是沒有必要的，而且有可能造成內(nèi)存泄漏。

什么樣的代碼簡潔清晰

我們之所以代碼寫得那么難受，很多時候是因為給的接口不夠“多”，試想一下，如果SD卡的文件被改動有回調(diào)，手機(jī)位置發(fā)生變化有回調(diào)，網(wǎng)絡(luò)狀態(tài)一變化就有回調(diào)，這會讓很多功能實現(xiàn)起來變得非常簡單。

封裝必要的回調(diào)函數(shù)

什么事件需要寫回調(diào)？通常是那些破壞代碼簡潔的邏輯，比如耗時的操作，像網(wǎng)絡(luò)請求，大量計算，獲取地理位置等，或者一直在被監(jiān)聽的事件，比如推送到本地的消息，文件被篡改、網(wǎng)絡(luò)狀態(tài)等。讓那些簡單不耗時的操作，比如讀取文件，彈出Toast或者設(shè)置TextView分門別類的放在這些回調(diào)里面，讓人一目了然。

這些是無法用MVP，MVVM等架構(gòu)解決的，原因很簡單，因為無論怎么分層，這些回調(diào)都是需要的，分層只是把這些回調(diào)放在不同的文件里面而已。軟件分層一方面是為了容易移植，另一方面是為了分離純Java的代碼，方便做單元測試。

回調(diào)是讓代碼簡潔的方式之一，在我們實際編碼的過程當(dāng)中，在此前的基礎(chǔ)上，還可能會遇到下面這個非常常見的問題。

臃腫的回調(diào)

無論我們愿不愿意，我們都是在以填充各種事件的回調(diào)來編寫android代碼的，這就導(dǎo)致一個問題，當(dāng)業(yè)務(wù)邏輯越來越復(fù)雜的時候，我們就很有可能會在同一個回調(diào)中，編寫多個毫不相關(guān)的任務(wù)的業(yè)務(wù)邏輯。

當(dāng)一個事件的回調(diào)中承載的事情越來越多，面向過程的思想就體現(xiàn)的越來越明顯。在實際編程的過程當(dāng)中，我偏向于同時具備面向?qū)ο蠛兔嫦蜻^程兩種思維方式，而不是簡單粗暴的認(rèn)為：面向?qū)ο蟾哐牛嫦蜻^程低俗。它們的本質(zhì)是相同的，褪去多態(tài)的光環(huán)，面向?qū)ο笾皇且环N將函數(shù)分門別類存放的一種建議。

如何解決回調(diào)過于臃腫的問題？

優(yōu)先考慮將這個回調(diào)的事件細(xì)分。典型的就是AbsListView類的onTouchEvent，onTouchEvent里面的邏輯非常復(fù)雜，為了避免堆積在一起過于凌亂，onTouchEvent被分解成了onTouchDown，onTouchMove，onTouchUp以及onTouchCancel。這樣一大塊代碼就會被打散，交給更細(xì)致的回調(diào)來分擔(dān)。

將onTouchEvent細(xì)分

如果某個事件的回調(diào)中執(zhí)行的業(yè)務(wù)邏輯，并不是一類（比如發(fā)送網(wǎng)絡(luò)請求刷新了一下ListView和讀取了一下配置文件），不像onTouchEvent這樣可以細(xì)分，那么問題就會變得比較麻煩，因為我們用事件的回調(diào)來解決問題的時候，我們真正想要的是回調(diào)函數(shù)執(zhí)行的時機(jī)，比如onResume就在那個特定的時機(jī)會被調(diào)用，如果你需要的就是這個時機(jī)，你就只能老老實實的在這里寫代碼，別無他法。為了代碼簡潔，我們能做的就是盡可能的將這個承擔(dān)了多個職責(zé)的回調(diào)寫的足夠簡單，最好是沒有循環(huán)，沒有分支，就是幾個赤裸裸的函數(shù)放在哪里，讓人一目了然。

回調(diào)只提供了一個處理問題的時機(jī)，很難保證單一職責(zé)

認(rèn)識到android軟件開發(fā)是在各種各樣的回調(diào)上搭建一切功能，是編寫代碼的第一步，是未來學(xué)習(xí)設(shè)計模式的基礎(chǔ)。

文／吳晨（簡書作者）原文鏈接：http://www.jianshu.com/p/8182921fea87