私は RDP セッションを頻繁に使用していますが、接続先のサーバーが遅くなったりクラッシュしたりしても、RDP ウィンドウ/ツールバー自体は完全に応答/クリック可能であることに気付きました。これはおそらく、RDP ウィンドウが 1 つのプロセスであり、実際のサーバーが別であるためです。
アプリでこの種の流動性を実現するための開発中の手法はありますか?
ありがとう
私は RDP セッションを頻繁に使用していますが、接続先のサーバーが遅くなったりクラッシュしたりしても、RDP ウィンドウ/ツールバー自体は完全に応答/クリック可能であることに気付きました。これはおそらく、RDP ウィンドウが 1 つのプロセスであり、実際のサーバーが別であるためです。
アプリでこの種の流動性を実現するための開発中の手法はありますか?
ありがとう
UIの応答性を維持するために実行できる最も重要なことは、UIスレッドで実行する作業の量を最小限に抑えることです。つまり、実行する必要のある主要な処理では、スレッドを生成して(またはスレッドプールを使用して)作業をオフロードし、UIスレッドがUIの処理に戻ることができるようにします。
おそらく2つの別々のプロセスではなく、2つの別々のスレッドです。スレッドはサブプロセスのようなものです。
WindowsエクスプローラやGoogleChromeなど、複数のプロセスを使用するアプリケーションがあります。各ウィンドウまたはタブには、個別のプロセスがあります。それを表示するプロセスは1つありますが、コンテンツを管理するプロセスは異なります。これは主に、不安定になる可能性があるために行われます。プロセスがクラッシュすると、すべてのスレッドを含むアプリケーション全体が閉じられます。ロジックを別々のプロセスに配置することにより、ウィンドウの1つがクラッシュしても、アプリケーションは存続します。マルチスレッドアプリケーションをプログラムするのは少し難しいですが、このようなマルチプロセスのシングルウィンドウアプリケーションを開発するのは少し難しいです。