在開始時表現良好的API會隨著時間的推移而導致性能降低。學習如何管理和解決這些性能問題是開發者必須具備的技能之一。

作為一名工程師，你花了很多時間在API上——你要么是為別人構建API，要么是在使用別人的API。使用API既是一門藝術，也是一門科學。工程師們犯的常見的錯誤之一就是對性能的思考不夠充分。我們希望讓事情先做起來，然后再處理性能問題。這很好，但是如果在構建v1的時候能夠意識到這一點，你以后就可以避免。如果你使用API的時間夠長，我相信你知道剛開始一切都很順利，但隨著時間的推移，API就會變得緩慢。

當我們在使用別人API時，這些API是我們幾乎無法控制的，那就會變得很棘手。通常，許多API在初的幾毫秒內就會響應，但隨著時間的推移，復雜性的增加，它們開始變得緩慢。一些用戶操作可能會在我們正在使用的API中觸發一個代價高昂的查詢，然后就會出現問題。API不能保證預期性能，所以在使用API時，意識到這點會督促您關注什么樣的東西會減慢它們的速度，尤其是在項目的關鍵路徑上。

我們來看一個或兩個用戶操作共享一個視圖區域以顯示其響應的用例。如果其中一個連接到這些操作的API需要花很長時間，那么我們可能會遇到，如果處理不當視圖就會混亂的情況。

例如Google’amzn股票’，您會看到如下所示：由用戶選擇的時間范圍控制的一個單一的股票趨勢圖，如1天、5天、1個月等。

當我們切換時間段時，視圖區域會反映變化。讓我們假設您的API調用獲取1年趨勢圖會出現問題，用戶點擊它，它一直在加載，那么用戶失去耐心，切換到一個較短的時間段，比如3個月，則立刻加載出圖表。當用戶正在查看3個月的圖表時，剛開始獲取1年數據的API調用返回其響應并重新繪制具有1年數據的圖表。

這不是一個復雜的問題。你可以查看當前活躍的時間段，忽略晚到的響應。但是，當您構建v1時，您可能不認為在開發UI時需要這種處理，因為當您開發它時，所有的API都會立即返回。您可能沒有預料到API會在某些場景中或隨著時間的推移而減慢。

現在，如果這種情況影響到應用程序中提供多個組件的公共共享服務的狀態，情況可能會變得更糟，并且在這種情況下尋找根本原因會變得非常復雜。

我們來看看如何解決這個問題。一個簡單的方法是在該公共共享服務中維護一個標記，以跟蹤我們當前期待響應的后臺API。但是如果我們多次調用同一個API會怎么樣呢?標志是行不通的。我們可以延長標志來存儲每個后臺API調用的“狀態”，但這會變得混亂和復雜,每當我們去存儲狀態,我們都要承擔很大的風險，因為“記住”API的變化，我們需要保持狀態更新，但這幾乎總會導致不良的缺陷。

所以你維護的“全局”狀態越少越好。它不僅有助于保持代碼簡單和模塊化，而且還為您提供更多自由去提高并發性。

在這種情況下，一種更好的方法是，不要處理來自慢速API的響應，而是簡單地停止接收來自它的響應。只需終止那些您不再關心響應和繼續運行的API。您可以通過跟蹤所有正在進行的API調用來輕松地執行此操作，并且當您需要啟動新的API調用時，只需終止不再需要的先前的調用即可。

如果您使用的是jQuery ajax方法，那么請保留對jQuery ajax方法返回的XMLHttpRequest的引用，并在適當的時候調用您的流中的中止方法。

如果您使用的是ES6 promises，那么對不起，這是行不通的——您不能終止與promises相關的一個正在進行的API調用。更多關于promises使用在這里。

歡迎來到RxJS世界！RxJS試圖通過完全異步的事件驅動模型來為API性能的混亂帶來秩序。如果某件事需要時間，那就花點時間吧。讓我們用我們所擁有的一切來運行。我不是在這里討論它是好是壞，或者它是否是好的方法，但是我發現用RxJS處理這些類型的情況是很方便的。

在這種情況下，您可以簡單地在您的可觀察對象上使用一個switch 結構，并獲得您感興趣的新異步事件，而不必擔心任何狀態維護或終止先前正在進行的API。當您使用正確的構造時，這個庫內部為您做了所有這些操作，所以您不必擔心它們！

以plunker為例。

在這個例子中，一個緩慢的API使用Observable.timer。 作為共享服務構造函數的一部分創建的RxJS主體實例asyncActionSubject，使用switch結構來簡單地切換到返回的新observable。 其余的都由RxJS框架負責。在這里查看RxJSGitHub頁面了解更多詳細信息。

關鍵小貼士

1. 在使用API時，請始終考慮什么情況可能導致其減慢。您可以根據API正在做什么，返回多少和什么類型的數據，以及如果您正在測試的簡單例子變得復雜時將會發生什么。如果你的代碼路徑結合許多過濾器和選擇器為用戶操作服務,那么這一點尤為重要。
2. 始終考慮大局–用戶如何與您的代碼交互,進而影響你正在使用的API?退一步,思考會出什么錯，從源頭處理這些情況。
3. 總是盡可能分散和無狀態。集中和有狀態是調試和并發性的敵人。這可以節省很多麻煩。
4. 小心使用異步調用——它們是好的,但它們也會很棘手。了解它們在您的情況下如何工作，以及當調用按時間順序返回時會發生什么。
5. 后,越少越好。即使一個API返回很多數據量，低數據量和實際上消耗的少數據量。