在 Delphi Tokyo (10.2) 後,Delphi UI 的 Thread 在 Android 下發生了一點變化,原文如下:
Unification of Delphi and Java threads on Android: CallInUIThread has
been deprecated. All code is now running in the Java UI Thread, removing
the need for thread synchronization.
由此可推斷出,以前 FMX 在 Android 的運作模式如下:
|
FMX for android in before Delphi 10.1 |
因為 Delphi UI Thread 是基於 Java UI 之上,使用者操作 Java UI 層時,還需要經過 Delphi UI 層的同步處理才能觸發 Delphi 物件的相關事件,故效能和原生的 Java App 相比下會來得差一點。
而在 10.2 之後,不再是雙 Thread 並行,除了執行效能有顯著提升外,連 FMX 在 Android 平台都【自動升格為 Thrad safe 】了!
但問題來了,這種底層架構的調整,對於 FMX for Android 舊版本專案會有影響嗎?
答案很明顯的……
一定有!但不大
問題不大的原因在於,絕大多數的開發方式並不會使用到 Thread,也就是說,UI 層的問題在編譯程式時就已經解決了。
而最大的問題在:邏輯層面的 Bug。
既然是 Thread 層的修正,那問題一定也會出在 Thread 上。
首當其衝的當然就是『3rd party』了!(笑)
【
FGX-FireMonkey】的範例就有用上 Thread (TfgActivityDialog, TfgProgressDialog),相當經典,但在 10.2 時卻會發生元件畫面無法出現的問題。
相同的程式碼在 10.1 以前的程式流程是這樣的:
|
TfgAD = TfgActivityDialog |
如果程式碼不改變的情況,在 10.2 後『純 Java UI Thread』下的流程會是這樣:
於是 TfgActivityDialog 自然就看不到囉!(笑)
結論
FMX 還是一個年輕且在成長的框架,所以每當底層架構有所變化時,都要檢視一下自己的專案是否會因改版而必須有所更動,每一個版本的 What's New 內容非常重要,務必好好研讀。
其實上圖之所以會有這個問題不是 FGX 作者的問題 (就算是,作者也不再維護了……),主因還是會回到 Thread 控制根本上的不同,隨著架構的變化而重構專案程式碼才會是最佳解。
See also: