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

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

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

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

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

五行缺Context

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

我并不反對通過提升可見性來實(shí)現(xiàn)多個(gè)事件之間的配合，比如計(jì)算器的例子，提升可見性就是一個(gè)簡潔優(yōu)雅的解決方案。但是很多時(shí)候?yàn)榱颂嵘承┳侄蔚目梢娦裕瑢⒆侄卧O(shè)置為靜態(tài)字段是沒有必要的，而且有可能造成內(nèi)存泄漏。

什么樣的代碼簡潔清晰

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

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

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

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

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

臃腫的回調(diào)

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

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

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

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

將onTouchEvent細(xì)分

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

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

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

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