公開: 21 July 2020 - 3 min read

JetBrainsのブログで、Roman ElizarovがKotlin/Nativeとマルチプラットフォームの世界ではしました。

この記事をお読みになった後、ご質問があり、ご意見をお聞きになりたい場合は、ください。

明示的なスレッド制御という "凍結された "同時実行モデルは変わりつつあります。

私は過去2年以上、この同時実行とランタイム・モデルについて議論してきました。セキュリティの観点からは、気に入る点がたくさんあります。無制限の共有メモリー・アクセスは、控えめに言っても問題があります。実行時にいくつかのルールを強制することは、余分なセキュリティを意味し、JVMコードがどのように設計されているかを考えさせられます。もっと違うやり方があるのでは？

もちろん、一歩引いて考えれば、私はこのモデルを説明するためにここ数年、多くのコンテンツを作ってきました。ということは、もしかしたら開発者が学ぶのが難しいということかもしれません。確かにユニークなモデルであり、JVMとNativeが異なるルールの下で生きているという事実は、実にいくつかの混乱の原因となっています。

そのブログの言い換え

ブログのいくつかの部分を取り上げて、それについて議論したいと思います。最も重要なポイントはTL;DRにあります。

「既存のコードは引き続き機能し、サポートされます。

この投稿は将来の変更についてのものであり、あなたのNativeコードはこれらの将来の変更と互換性があることを強調しておきます。

"これらの問題に対処するため、Kotlin/Nativeにおけるオブジェクト共有の制限を解除することを可能にする、Kotlin/Native用の代替メモリ・マネージャの開発に着手しました......"

これは、実行時に強制されるスレッド制約モデルがなくなることを意味します。オブジェクトの共有」が何を意味するのか、混乱があります。グローバル・オブジェクトだけではありません。完全なメモリー管理モデルのことです。

「既存のコードとほぼ互換性のある形で導入する予定です。

"ほとんど互換性がある "というと問題があるように聞こえるかもしれませんが、よほどエキゾチックなものでない限り、問題なく動作するはずです。フリーズはまだ存在しますが、KN並行処理に関する質問を送信）オプションになります。アノテーションは、たとえ何もしなくなったとしても、実装されます。

あなたのコードは引き続き動作し、多くの場合、より速く動作します。

"そして、Kotlin/Nativeだけでなく、Kotlin言語全体でKotlinが不変データを扱う方法を改善する方法を検討します。"

このセクションは興味深い。JVMとNativeの実行時の動作の違いは、最大の問題のひとつです。言語内のイミュータブル・データを改善し、それを並行処理のベスト・プラクティスに適用することは良いことのように聞こえますが、どうなるかは見てみないとわかりません。

「また、Kotlin/Native用のマルチスレッドライブラリもリリースされる予定です。

これは重要です。マルチスレッド・コルーチン分岐を使うアプリケーションにとって。Romanの投稿で議論されている潜在的なメモリー・リークを避けるために慎重に使用してください。今後もサポートしていきます。

今は？

まあ、個人的には、会議で話す他のことを探しに行くつもりですが......)

それ以外は何も変わっていません。メモリー・マネージャーのアップデートの時期は未定ですが、かなり先になると思ってください。何ヶ月も先のことではありません。つまり、当分の間、Kotlin/Nativeのコードを書くなら、フリーズモデルとそのコードの書き方を理解する必要があるということです。これまで話してきたことはすべてまだ当てはまります。

KMPはプラットフォームとして成熟し続けており、現在Native用に書いている並行コードは、これらのアップデートがある限り動作し続けます。

基本的なことをより詳しく説明するのではなく、特定の作業のやり方を中心にコンテンツを作り始めるかもしれませんね。基本的には技術的なレシピです。例えば、FlowやSqldelightの使い方、様々なシナリオでのネットワークの扱い方など。現在のメモリモデルの詳細はほとんど隠すことができますし、そのような変更が来たときには、移行のためのコードを書けばいいのです。

ですから、今はあまり変わっていませんが、変化は確実に起こりつつあります。最終的には、これはエコシステムにとって良いことであり、採用を増やすことになるでしょう。このことについては、また後ほどお話ししたいと思います。