§Play 2.5 的新功能
此頁面重點介紹 Play 2.5 的新功能。如果您想了解移轉到 Play 2.5 所需進行的變更，請查看 Play 2.5 移轉指南。
§基於 Akka Streams 的新串流 API
Play 2.5 的主要主題是從 Play 基於迭代器的非同步 IO API 移轉到 Akka Streams。
基本上，任何時候您透過網路進行通訊，或讀寫檔案系統中的資料時，都會涉及一些串流。在許多情況下，這種串流是在低階層級進行，而框架會將具體化的值以內存訊息的形式公開給您的應用程式。許多 Play 動作都是如此，主體剖析器會將請求主體串流轉換為物件（例如剖析後的 JSON 物件），應用程式會使用該物件，而回傳的結果主體是 JSON 物件，然後 Play 會將其轉回串流。
傳統上，在 JVM 上，串流使用封鎖的 InputStream 和 OutputStream API 執行。這些 API 需要一個專用的執行緒才能使用它們 - 讀取時，該執行緒必須封鎖並等待資料，寫入時，該執行緒必須封鎖並等待資料刷新。非同步框架（例如 Play）提供了許多優點，因為它透過不使用這些封鎖 API 來限制其所需的資源。相反地，對於串流，需要使用非同步 API，其中會通知框架有資料要讀取或資料已寫入，而不是必須讓執行緒封鎖並等待它。
在 Play 2.5 之前，Play 使用 Iteratees 作為此非同步串流機制，但現在它使用 Akka Streams。
§為什麼不使用 Iteratees?
Iteratees 是一種處理非同步串流的功能性方法。它們非常強大，同時也提供了一個非常小的 API 表面 - Iteratee API 包含一個方法 fold，其餘的只是建立在此方法之上的輔助程式。Iteratees 還提供了非常高的安全性，只要您的程式碼編譯，您不太可能遇到與 iteratee 本身實作相關的任何錯誤，例如並發性或錯誤處理，大多數錯誤會出現在 iteratee 的「業務」邏輯中。
雖然這種安全性與簡潔性很棒，但它的後果是它有一個非常陡峭的學習曲線。使用 Iteratees 進行程式設計需要從傳統的 IO 處理中轉變思維，許多開發人員發現進行此轉變所需的投資對他們的 IO 需求來說太高。Iteratees 的另一個缺點是它們實際上無法在 Java 中實作，因為它們依賴於許多高階功能程式設計功能。
§為什麼使用 Akka Streams
Akka Streams 在安全性、簡潔性和熟悉度之間取得良好的平衡。Akka Streams 故意限制你能做的事情，讓你只能正確地做事，但不像迭代器那樣多。對於大多數開發人員來說，它們在概念上更熟悉，提供函式和命令式兩種使用方式。Akka Streams 也有第一類 Java API，讓你在 Java 中實作任何需要的串流需求變得更簡單。
§Akka Streams 在哪裡使用？
在你的 Play 應用程式中會遇到 Akka Streams 的地方包括
- 篩選器
- 串流回應主體
- 請求主體剖析器
- WebSocket
- 串流 WS 用戶端回應
§Reactive Streams
Reactive Streams 是非同步串流的新規範，排定納入 JDK9，並作為獨立函式庫提供給 JDK6 以上版本。一般來說，它不是一個終端使用者函式庫，而是一個串流函式庫可以實作以互相整合的 SPI。Akka Streams 和迭代器都提供 Reactive Streams SPI 實作。這表示現有的迭代器程式碼可以輕鬆地與 Play 的新 Akka Streams 支援一起使用。這也表示任何其他 Reactive Streams 實作都可以用在 Play 中。
§迭代器的未來
迭代器仍然有一些它們發揮作用的用例。目前，沒有計畫要讓它們過時或從 Play 中移除，儘管它們可能會移到獨立函式庫中。由於迭代器提供 Reactive Streams 實作，它們將永遠可以在 Play 中使用。
§更好地控制 WebSocket 框架
Play 2.5 WebSocket API 讓您可以直接控制 WebSocket 框架。您現在可以傳送和接收二進位、文字、ping、pong 和關閉框架。如果您不想擔心這個層級的細節，Play 仍會自動將您的 JSON 或 XML 資料轉換成正確類型的框架。
§新的 Java API
Play 2.5 的 Java API 提供與 Scala API 相同的功能。我們引進了幾個新的 Java API 來執行這項工作
HttpRequestHandler，允許在要求送至路由器之前攔截要求。EssentialAction，用於EssentialFilter和HttpRequestHandler的低階動作。EssentialFilter/Filter，用於以 Java 編寫篩選器。BodyParser，允許以 Java 編寫自訂主體剖析器。
§Java API 已更新為使用 Java 8 類別
當 Play 2.0 在 2012 年發布時，Java 幾乎不支援 Play 的非同步函式程式設計樣式。沒有 lambda，futures 只有阻擋介面，而且沒有常見的函式類別。Play 提供了自己的類別來填補這個缺口。
在 Play 2.5 中，這個情況已經改變。Java 8 現在出貨時對 Play 的程式設計樣式有更好的支援。在 Play 2.5 中，Java API 已重新整理為使用標準的 Java 8 類別。這表示 Play 應用程式將會與其他 Java 函式庫整合得更好，而且看起來更像是慣用的 Java。
以下是主要變更
- 使用 Java 函式介面 (
Runnable、Consumer、Predicate等)。(請參閱遷移指南。) - 使用 Java 8 的
Optional取代 Play 的F.Option。 (請參閱遷移指南。) - 使用 Java 8 的
CompletionStage取代 Play 的F.Promise。 (請參閱遷移指南。)
§支援其他記錄架構
許多使用者想使用他們自己選擇的記錄架構，但在 Play 2.5 之前無法做到。現在，Play 對 Logback 的固定相依性已移除，Play 應用程式現在可以使用任何相容於 SLF4J 的記錄架構。Logback 預設包含在內，但您可以在 build.sbt 檔案中加入設定來停用它，並以您自己選擇的架構取代它。請參閱 Play 的 記錄文件，以取得在 Play 中使用其他記錄架構的更多資訊。
Play 應用程式需要對其組態做一些小變更，因為 Play 的一個 Logback 類別已移至獨立套件，作為變更的一部分。請參閱 遷移指南 以取得更多詳細資料。
§記錄 SQL 陳述式
Play 現在有一個簡單的方法來記錄 SQL 陳述式，建立在 jdbcdslog 之上，適用於所有 JDBC 資料庫、連線池實作和持續性架構（Anorm、Ebean、JPA、Slick 等）。當您啟用記錄時，您會看到傳送至資料庫的每個 SQL 陳述式，以及關於陳述式執行時間的效能資訊。
如需關於如何使用 SQL 記錄的更多資訊，請參閱 Play 的 Java 和 Scala 資料庫文件。
§Netty 原生 Socket 傳輸
如果您在 Linux 上執行 Play 伺服器，現在可以使用 Netty 4.0 中引入的 原生 Socket 功能 來提升效能。
您可以在 Play 文件中了解如何在 設定 Netty 中使用原生 Socket。
§效能改善
感謝各種效能最佳化，Play 2.5 的效能測試架構顯示每秒約 60K 個要求，比 Play 2.4.x 改善了將近 20%。
§WS 改善
Play WS 已升級到 AsyncHttpClient 2.0，現在包含一個要求管線篩選器（Scala、Java），可用於以 cURL 格式 記錄要求。
下一步：遷移指南
在此文件說明中發現錯誤？此頁面的原始程式碼可以在 這裡 找到。在閱讀 文件說明指南 後，請隨時提出拉取要求。有問題或建議要分享嗎？前往 我們的社群論壇 與社群展開對話。