性能優化總結（四）：預加載的設計

什麼是預加載，為什麼要用它？

我們所需要的API

一個簡單的例子

什麼是預加載？

    預加載其實就是在真正開始使用資料之前，先異步把資料加載好，等到需要使用時，就可以直接使用之前加載好的資料。這時，由于資料已經加載完成，而不用等待漫長的加載過程，是以程式的速度得到一個明顯的提升。

    那麼，什麼時候需要使用它呢？我覺得，主要是這種情況：當我們可以預知程式接下來的步驟中，很可能會用到一些資料，而擷取這些資料的操作比較耗時的時候，我們就可以使用預加載的方式，提前把資料準備好。

    預加載需要使用異步方法，也就是使用背景線程來加載資料。這樣做的好處當然是不會阻塞目前的主線程。（不過如果目前線程本身就是用于異步加載資料的話，那就沒必要再新開線程了。）

    但是，這些并不是我想要的API……

    目前系統中預加載使用的場景需求是這樣的：

預加載可以對指定的資料擷取操作（loading action）進行封裝，在需要時調用。

使用資料的子產品（使用者），并不一定知道是誰、在何時給它提前加載的資料。它隻會申請使用資料。

發起異步加載的子產品（發起者），應該知道使用者是誰。

多個發起者之間沒有關系，但是都可以為某一使用者發起預加載。但是保證真正的資料加載操作，隻會發生一次。

支援重新加載。

一個類中，支援對它不同的資料進行不同加載方式，以友善按需加載。

從使用者的角度來看，不管有沒有發起者為它進行預加載，它都可以申請并拿到想要的資料。也就是說：

當沒有發起者為它進行預加載，那麼它的資料申請會導緻即時的資料加載；

如果已經發起了預加載，而且資料已經加載完成，則直接擷取到加載好的資料；

如果資料沒有完成，則資料使用者需要等待資料的加載完成後，才可以擷取到資料并繼續目前的操作。

    其中，最重要的就是最後點。

    可以看到，這裡需要用到異步操作、線程間同步。是以我們需要基于上面提到的多種API來實作，這裡我們使用的是簡單的線程池的方式，比較簡單，不再贅述。

    最後設計出的API大緻是這樣的：

預加載是一個經常會被使用到的模式，希望對大家有用。

本文轉自BloodyAngel部落格園部落格，原文連結：http://www.cnblogs.com/zgynhqf/archive/2010/06/30/1768604.html，如需轉載請自行聯系原作者