自接觸Android以來，我一直在尋找一種比較健壯的開發方法。譬如避免在UI線程進行IO操作，防止重復的網絡請求，對重要數據進行緩存并且準確的更新這些緩存等等。當然，代碼結構也要保持盡量清晰。

本文并不是給你提供一個權威精準的解決方案，更多的是去探討在靈活性、可讀性和健壯性之間有著很好平衡的App的一種開發方式。

一些現有的解決方案

在Android的初期版本，許多人處理多任務時會選擇 AsyncTask 。大體上來說，AsyncTask非常難用，許多文章也提到了它的問題。后來，Honeycomb（3.0）引入了可配置性更好的 Loaders。到了2012年，基于Android Service的開源項目Robospice問世，帶來了新的解決方案，這里介紹了 Robospice的工作原理。

Robospice 比起 AsyncTask 的確好太多了，但是依然存在一些問題。比如下面這段常見代碼，通過Robospice在Activity中發起一個請求的過程。你并不需要細讀，只要有個大概的概念就好：

FollowersRequest request = new FollowersRequest(user);  
lastRequestCacheKey = request.createCacheKey();  
spiceManager.execute(request, lastRequestCacheKey,  
    DurationInMillis.ONE_MINUTE, 
    new RequestListener<FollowerList> { 
      @Override 
      public void onRequestFailure(SpiceException e) { 
          // On success 
      } 
  
      @Override 
      public void onRequestSuccess(FollowerList listFollowers) { 
        // On failure 
      } 
    }); 

然后是請求的具體代碼:

public class FollowersRequest extends SpringAndroidSpiceRequest<FollowerList> {  
  private String user; 
  
  public FollowersRequest(String user) { 
    super(FollowerList.class); 
    this.user = user; 
  } 
  
  @Override 
  public FollowerList loadDataFromNetwork() throws Exception { 
    String url = format("https://api.github.com/users/%s/followers", user); 
    return getRestTemplate().getForObject(url, FollowerList.class); 
  } 
  
  public String createCacheKey() { 
      return "followers." + user; 
  } 
} 

存在的問題

你需要為每個請求都做上述的處理，代碼會顯得很臃腫：

- 對于你的每種請求你都需要繼承SpiceRequest寫一個特定的子類。

- 同樣的，對于每種請求你都需要實現一個RequestListener來監聽。

- 如果你的緩存過期時間很短，用戶就需要花較長時間等待你的每個請求結束。

- RequestListener持有了Activity的隱式引用，那么是不是還需要內存泄露的問題。

綜上，這并不是一個很好的解決方案。

五步，讓程序簡潔而健壯

在我開始開發Candyshop的時候，我嘗試了其他的方法。我試圖通過混合一些擁有有趣特性的庫來構造一個簡單而健壯的解決方案。這是我用到的庫的列表：

* AndroidAnnotations用來處理后臺任務，EBean等等……

* Spring RestTemplate用來處理 REST(含狀態傳輸)的網絡請求，這個庫和AndroidAnnotations配合的非常好。

* SnappyDB這個庫主要用來將一些 Java 對象緩存到本地文件中。

* EventBus 通過 Event Bus 來解耦處理 App 內部組建間的通訊。

下圖就是我將要詳細講解的整體架構：

***步 一個易于使用的緩存系統

你肯定會需要一個持久化的緩存系統，保持這個系統盡可能簡單。

@EBean 
public class Cache {  
    public static enum CacheKey { USER, CONTACTS, ... } 
  
    public <T> T get(CacheKey key, Class<T> returnType) { ... } 
    public void put(CacheKey key, Object value) { ... } 
} 

第二步 一個符合REST的Client

這里我通過下面的例子來說明。記得要確保你使用 REST API 放在同一個地方。

@Rest(rootUrl = "http://anything.com") 
public interface CandyshopApi { 
  
    @Get("/api/contacts/") 
    ContactsWrapper fetchContacts(); 
  
    @Get("/api/user/") 
    User fetchUser(); 
  
} 

第三步 應用級的事件總線（Event Bus）

在程序最初的時候就初始化Event bus對象,然后應用的全局都可以訪問到這個對象。在Android中， Application初始化是一個很好的時機。

public class CandyshopApplication extends Application {  
    public final static EventBus BUS = new EventBus(); 
    ... 
} 

第四步 處理那些需要數據的Activity

對于這一類的Activity，我的處理方式和Robospice非常類似，同樣是基于Service解決。不同的是，我的Service并不是Android提供的那個，而是一個常規的單例對象。這個對象可以被App的各處訪問到，具體的代碼我們會在第五步進行講解，在這一步，我們先看看這種處理Activity代碼結構是怎么樣的。因為，這一步可以看到的是我們簡化效果***烈的部分!

@EActivity(R.layout.activity_main) 
public class MainActivity extends Activity { 
  
    // Inject the service 
    @Bean protected AppService appService; 
  
    // Once everything is loaded… 
    @AfterViews public void afterViews() { 
        // … request the user and his contacts (returns immediately) 
        appService.getUser(); 
        appService.getContacts(); 
    } 
  
    /* 
        The result of the previous calls will 
        come as events through the EventBus. 
        We'll probably update the UI, so we 
        need to use @UiThread. 
    */ 
  
    @UiThread public void onEvent(UserFetchedEvent e) { 
        ... 
    } 
  
    @UiThread public void onEvent(ContactsFetchedEvent e) { 
        ... 
    } 
  
    // Register the activity in the event bus when it starts 
    @Override protected void onStart() { 
        super.onStart(); 
        BUS.register(this); 
    } 
  
    // Unregister it when it stops 
    @Override protected void onStop() { 
        super.onStop(); 
        BUS.unregister(this); 
    } 
  
} 

一行代碼完成對用戶數據的請求，同樣也只需要一行代碼來解析請求所返回的數據。對于通訊錄等其他數據也可以用一樣的方式來處理，聽起來不錯吧！

第五步——單例版的后臺服務

正如我在上一步說的那樣，這里使用的Service并不是Android提供的Service類。其實，一開始的時候，我考慮使用Android提供的Services，不過***還是放棄了，原因還是為了簡化。因為 Android提供的Services通常情況下是為那些在沒有Activity展示情況下但還需要處理的操作提供服務的。另一種情況，你需要提供一些功能給其他的應用。這其實和我的需求并不完全相符，而且用單例來處理我的后臺請求可以讓我避免使用復雜的借口，譬如：ServiceConnection，Binder等等……

這一部分可以探討的地方就多了。為了方便理解，我們從架構切入展示當Activity調用getUser()和getContacts()的時候究竟發生了什么。

你可以把下圖中每個serial當作一個線程：

正如你所看到的，這是我非常喜歡的模式。大部分情況下用戶不需要等待，程序的視圖會立刻被緩存數據填充。然后，當抓取到了服務端的***數據，視圖數據會被新數據替代掉。與此對應的是，你需要確保你的Activity可以接受多次同樣類型的數據。在構建Activity的時候記住這一點就沒有任何問題啦。

下面是一些示例代碼：

// As I said, a simple class, with a singleton scope 
@EBean(scope = EBean.Scope.Singleton) 
public class AppService { 
  
    // (Explained later) 
    public static final String NETWORK = "NETWORK"; 
    public static final String CACHE = "CACHE"; 
  
    // Inject the cache (step 1) 
    @Bean protected Cache cache; 
  
    // Inject the rest client (step 2) 
    @RestService protected CandyshopApi candyshopApi; 
  
    // This is what the activity calls, it's public 
    @Background(serial = CACHE) 
    public void getContacts() { 
  
        // Try to load the existing cache 
        ContactsFetchedEvent cachedResult = 
            cache.get(KEY_CONTACTS, ContactsFetchedEvent.class); 
  
        // If there's something in cache, send the event 
        if (cachedResult != null) BUS.post(cachedResult); 
  
        // Then load from server, asynchronously 
        getContactsAsync(); 
    } 
  
    @Background(serial = NETWORK) 
    private void getContactsAsync() { 
  
        // Fetch the contacts (network access) 
        ContactsWrapper contacts = candyshopApi.fetchContacts(); 
  
        // Create the resulting event 
        ContactsFetchedEvent event = new ContactsFetchedEvent(contacts); 
  
        // Store the event in cache (replace existing if any) 
        cache.put(KEY_CONTACTS, event); 
  
        // Post the event 
        BUS.post(event); 
  
    } 
  
} 

似乎每個請求之中的代碼還是有點多!實際上，這是我為了更好說明才進行了展開。不難發現，這些請求都遵守了類似的模式，所以你可以很容易的構造一個 Helper 來簡化他們。比如 getUser()可以是這樣的:

@Background(serial = CACHE) 
public void getUser() { 
    postIfPresent(KEY_USER, UserFetchedEvent.class); 
    getUserAsync(); 
} 
  
@Background(serial = NETWORK) 
private void getUserAsync() { 
    cacheThenPost(KEY_USER, new UserFetchedEvent(candyshopApi.fetchUser())); 
} 

那么serial是用來做什么的？ 讓我們看看文檔是怎么說的：

默認情況下，所有@Background的匿名方法都是并行執行的。但是如果兩個方法使用了同樣名字的serial則會順序運行在同一個線程中，一個接著一個執行。

雖然把網絡請求放在一個線程中順序執行可能會導致性能下降，但是這使得“先POST然后GET獲得數據”的那類事務處理起來非常容易，這是個特性值得為此犧牲一些性能。退一步講，如果你真的發現性能不可接受，還是可以很容易使用多個serial來解決。現在版本的Candyshop中，我同時使用了四個不同的serial。

總結

這里描述的解決方案是我幾個月前想到的很初級的一個想法。今天，我已經解決掉所有遇到的特殊情況，并且非常享受在這樣的架構下開發。當然，這個方案 中還有一些很棒的東西我想要和大家分享，比如：錯誤處理、緩存超時機制、POST請求、對無用操作的忽略，但是因為篇幅原因這里我就不繼續講述了。

那么，你是否也找到了能讓你享受每天工作的框架？

原文鏈接： joanzap   翻譯：zerob13

譯文鏈接： http://blog.jobbole.com/66606/