RXの芸術

問題、友達。 反応性はどこにでもあり、多すぎて誰もそれから隠すことはできません。 私たちは皆、ASyncTask、Service、またはContentProviderを書くことができます（私はそれを信じています！）。 ビットマップまたはドライブをデータ用にサーバーに向けることができます。 これは非常に明白です。 しかし、反応主義を適切に調理できると考えています。 これは常にそうではありません。



Androidでの適切なリアクティブプログラミングとは何ですか？







-こんにちは。 あなた自身についていくつか話してください。 あなたはどこで働いていますか？リアクティブなアプローチを促進し始めたとき、あなたは何をしますか？



-こんにちは。 私の名前は、Mtvey Malkov （ lNevermoreのハブ ）です。 私はおそらく5〜6年間Android開発者です。 現在、私は1つのスタートアップでScala開発に従事しています。 スタートアップはモスクワにあり、私はそれについてあまり話すことができません。 しかし、肝心なのは、Telegramのようなコミュニティプラットフォームになるということです。 実際、私はScalaのAndroidで書いています。



私がRxJavaに完全に翻訳した最初のプロジェクトは、2GISでの仕事でした。 アーキテクチャ、ベース、ネットワーキング-それだけです。 その後、彼は会議で一般的にRxJavaフレームワークと事後アプローチを積極的に推進し始めました。 今、私はScalaで執筆しています。そこでは、MightとMainで機能的なアプローチを使用しており、暇なときにジェットの世界のニュースに興味を持っています。



-Habrahabrのユーザーは、おそらくリアクティブプログラミングの概念を知っているでしょう。 Androidでのこのパラダイムの機能とリアクティブデータストリームについて教えてください。



-Android向けのプログラミングには、リアクティブプログラミングに関連する機能がかなりあります。 あとで説明するリアクティブプログラミングのすべての原則がAndroidに当てはまるわけではないことを伝えたいだけです。 根拠がないようにするために：スケーラビリティのようなものがあります。これは通常、多数のノードに対するスケーラビリティとして理解されます。つまり、ある種のサーバースケーラビリティです。 Androidでは、これはスレッドの単なるスケーラビリティであり、「実際のスケーラビリティ」ではありません。 また、システム全体に大きな影響を与えることはありません。 もちろん、それはまだ与えますが、別の方法で。



もう1つの特徴は、多くのAndroidが命令主義に結びついていることです。 つまり、可変性、データのボラティリティ、特にそのために、これらすべてをリアクティブフローでラップすることは非常に困難です。 これは、多くのハックを行う必要があるという事実につながり、事態を非常に複雑にします。 Androidの命令性により、多くの開発者は、リアクティブで命令的な世界を融合するために実際に考案され作成された主題などを使用することを余儀なくされています。 しかし実際には、誰もがObservableに簡単にラップするためにそれを使用していますが、これは大規模なプロジェクトで、特に長距離にわたって、アーキテクチャに悪影響を及ぼします。 それは、帝国主義のミッシュマッシュであり、それに対してとにかく反応主義が行われたように見えます。 すべての理由は、多くの人が怠けすぎて正しく実行できないか、正しく実行する方法がわからないためです。



実際、これは基本的にすべてです。正しいAndroidアーキテクチャでは、ネットワークインタラクション、キャッシング、および一般的にすべての一般的なビジネスロジックをAndroidパーツに結び付けてはならないためです。 したがって、実際には、これは他のプロジェクトと同様に機能する単なるビジネスロジックです。 アンドロイドだけではありません。



-リアクティブプログラミングの主な原則（フォールトトレランス、応答性、イベントの方向性、スケーリングの可能性）はかなり前に策定されました。 現在、これらの原則にどの程度同意していますか？



-実際にリアクティブプログラミングのイデオロギーの基礎であるリアクティブマニフェストの原則について話す場合、Habrahabrに関する私の記事でこれら5つのすべての原則を詳しく説明し、Android開発に投影しました。 そして確かにそうです、私はまだ彼らに同意します。 これがバックボーンであり、これらは基本原則であり、リアクティブアプローチを使用して開発するときに期待すべき主な影響であり、これらはリアクティブ主義を使用するときに戦わなければならない主なものです。



フォールトトレランスを採用する場合は、常にそれについて考える必要があります。 とても簡単ですが、常に念頭に置いておく必要があります。 エラーを正しく処理し、すべてのケースを処理して確認したかどうかを自問してください。 反応性はこれに便利なデバイスを提供しますが、それについてはまだ考えておく必要があります。 そして、これらすべての原則に従うことで、非常に優れたアーキテクチャと非常に優れたアプリケーションを構築できます。 また、スケーラビリティについて述べたように、Androidでは、スレッドに投影されない限り、いかなる影響も与えません。



-より重要なのは、リソースの集中度または信頼性ですか？ 結局のところ、Androidでのスレッドの発行には制限があります。アプリケーションがリソースをより要求するようになったという理由だけで、予算のデバイスを船外に放り投げることができます:)



-もちろん、そしてもちろん、信頼性ははるかに重要です。なぜなら、現在、Androidの世界では、多くのデバイスが安価なセグメントにあるという傾向があるからです。 インドではAndroid Oneが発売され、アメリカでは数ドルで電話が販売されています。 つまり、Nexus 6Pと同様に動作しない、非常に安価で超安価なAndroidスマートフォンがありました。 そのようなスマートフォンの所有者はますます増えており、すべてを片付けることはできません。



ただし、もちろん、リソースの集中度も忘れることはできません。 これは二次的なものではなく、これらの2つの原則は互いに並行する必要があります。 同じreactivschinaで、デバイスに応じて、コアの数に応じて、操作用に異なるスレッド数を設定できます。 つまり、予算のあるデバイスでは何かがより遅く機能するようにしますが、正確に機能し、明確に機能します。 もっと時間がかかりますが、それでも。 これらの間でバランスを見つけることは価値がありますが、両方に注意を払う必要があります！



「テクノロジーとフレームワークに関してかなり保守的だと言っていました。」 RxJavaフレームワークとその長所と短所について教えてください。



-Framework-driven-developmentのようなものがあります。 これは病気です。そもそもフロントエンドでしょう。 そして、Androidの世界全体。 あなたが問題を迅速に解決できないことを想像してください。もちろん、あなたは考えるのが面倒であり、未知のインド人によって書かれたある種のフレームワークを見つけようとしていると想像してください。 このフレームワークにはバージョン1.0.0または1.0.1があります。つまり、彼は一度だけパッチを適用し、約3年前にそれを作成しました。 そして彼はどういうわけかあなたのニーズを満たしています。 ライブラリは拡張可能ではなく、クラッシュする可能性がありますが、何らかの形で動作します。 これは非常に一般的であり、人々は常にそのようなフレームワークをプロジェクトに取り入れています。 私はこれを行うことができないと信じており、したがって、私はこの点でかなり保守的であると随所に書いています。



RxJavaフレームワークはどうですか？ 近くにすでに強力なコミュニティが存在することは非常にクールであり、多くの場合、それ自体を修正し、バグは常に修正されます。 RxJava代入が異なる方向に進むのはクールです。 Androidにとって非常に重要ないくつかのイベントを迅速に処理することを目指しており、RxJavaがサーバー側で適切に機能することを保証するように機能します。 たとえば、バックプレッシャー処理はすでに追加されており、これはバックエンドのものです。 以前は、on-backpressure-bufferとon-backpressure-dropしかありませんでしたが、これらのすべてのバックプレッシャーをカスタム処理できるようになりました。 最新のAndroidでは、負荷の高いシステムだけでなく、これにも対処する必要があります。 特に、システムがreactivschinaで構築されている場合、多数のスレッドがあり、1つは非常に高速にデータを書き込み、もう1つはゆっくりとデータを読み取り（もちろんノルウェー語のリーダー）、その後ハンドラーはチョークを開始します。 また、これも処理する必要がありますが、通常、Android開発者はバックプレッシャーが何であるかをあまり認識しておらず、これらの言葉を聞いて非常に驚いています。 これは重要であり、Android開発のプロセスで知る必要があります。



もちろん、RxJavaにも欠点があります。 実際、Androidについて話している場合、これはまったく異なるアプローチであるということです。 これまで、このOSでは命令型アプローチがより多く使用され、RxJavaはより機能的です。 また、RxJavaを正しく「調理」する方法を知っている人はほとんどいません。 私自身でさえ、RxJavaのすべての概念を非常に正確に理解しているわけではありません。 しかし、私の防御では、実際的なレベルでさえ、誰もがこのフレームワークを理解しているわけではないと言うことができます。 :)



また、明らかな欠点として、オブジェクトのコピーが多数あることに注意する必要があります。 これがもたらすことは理解できます。 これはGCの追加の負担です。



-RxJava対Bolts：2つの基本的な違いは？ あなたの個人的な好み、そして具体的なアプローチそれぞれの可能性は何ですか？



-私は実質的にボルトを使用していませんでした。とてもきれいに突くようにしました。 RxJavaの構文は、よりネイティブで簡潔に思えます。 彼女は格好良く、とても快適に見えます。 しかし、同時に、Boltsは事後対応的なアプローチの観点でより深いです。 非同期と待機だけで配信します。ちなみに、これらは「通常の」RxJavaにはありません。 ボルトは、私には低レベルであり、基本的なものに近いようです。



その可能性は明確で巨大です。 どちらのライブラリも、開発に大きな影響を与えました。 Boltsはまだあまり使用されていないため、RxJavaは、私が知る限り、より大きな影響を与えています。 どのライブラリを使用するかは誰もが選択できますが、RxJavaの方が構文と理解の点でシンプルであるように思えます。



-2GIS、Soundcloud、Facebookなどのトップデベロッパーの最新のアプリケーションをどのように評価しますか？また、パラダイムへのアプローチの違いは何ですか？



-これらはまったく異なるアプリケーションであり、それらは異なるものに関するものであるという事実から始まります。 地理位置情報と地図に関する2GIS、音楽に関するSoundcloud、および社会的なことに関するFacebook。 それらは完全に異なる技術で書かれているため、興味深い選択がされています。 2GISはQt 5 + QMLで記述され、SoundcloudはRxJava反応性を使用するJavaアプリケーションであり、FacebookはReactive Nativeで記述されています。 少なくともこれにはすでに根本的な違いがあります。 さらに、ユーザーとの関係にも違いがあります。



つまり、たとえば、Facebookはすべてのガイドラインに準拠しておらず、Facebookのメッセンジャーにはポップアップやオーバーレイなどがあります。 チャットをすると、デスクトップ上でチャット相手の顔が見えます。 そして、それをクリックすることにより、現在画面上にあるすべてのものに重なるアプリケーションが開きます。 これを行うのはあまり適切ではなく、個人的に私を悩ます。



Soundcloudは、多くの標準ユーザーインターフェイスマテリアルを取り入れようとしますが、それでも非常に美しいものです。 音楽の再生中に実行される彼らのトラックはすべて、フロントエンドだけを開発するのは非常にクールで困難です。



2GISは2GISです。 （ちなみに、「doubleGIS」ではなく「dvigis」と発音するのは正しくないことをご存じですか？今ではご存知です！:)独自のロックがあり、QMLがあり、特に標準のAndroidウィジェットを使用できないようです。 肝心な点は、標準的な材料設計にも従おうとすることですが、常に成功するとは限りません。



SoundcloudやTelegramなど、非常に高速に動作するアプリケーションが本当に好きです。 それらを評価する方法がわかりません。 アプリケーションは安定してうまく機能します。誰かがデザインを気に入っても、他のデザインは気に入らないかもしれません。 そして、それらはすべて異なるパラダイムを持っています。



-モバイル開発（Elm）以外の領域でのリアクティブプログラミングとアプリケーションの動的開発をどのように評価しますか？



-エルムについては何も言うことができません。 私が見るように、リアクティブプログラミング自体は勢いを増しています。 サーバー側で非常に優れたニッチを見つけたため、多くの企業がサーバー側でそれを使用しているため、高負荷で機能する拡張性の高いサービスを作成できます。 BigDataでは、Akka StreamsやRxJavaなども簡単に確認できます。 これは、RxJavaでほぼ完全に記述されたNetflixのような「クール」な（ロード、分散、およびなんらかの）サービスです。



フロントエンドに関しては、私は実際にウェブのトレンドをフォローしていません。 しかし、私は彼らがClojureScriptでたくさん書いていること、RxJSがあることを知っています。RxJSもそのニッチを見つけたようです。 主なことは、このすべてがさらに進歩し発展することです。なぜなら、反応主義は多くの場所で役に立ち、アプローチ全体がニッチに陥るとif辱されるからです。



- メビウス2016カンファレンスでのThe Art of Rxについての講演は何ですか？



-報告は、反応主義がどこに向かっているのか、そして実際にそれを正しく準備する方法について、かなり哲学的であるように計画されています。 このアプローチを使用したアプリケーションアーキテクチャの構築に関連するいくつかの側面を検討します。 この言語は、「アーキテクチャ」と「プログラミング」という言葉を組み合わせることにはなりません。 奇妙なことに、多くの人がこれらの間違いを犯します！ どうやって見つけたの？ はい、とても簡単です！ あらゆる種類のフォーラムでよく見かけます。 なんで？ はい、人々は反応主義自体で何度も間違ったことをするので、これをすべて維持することは非常に難しくなり、反応的なアプローチの全体的なアイデアは崩れているようです。 さて、レポートでは、RxJava自体の内部のいくつかのアーキテクチャのことを考慮しようとします。 つまり、同じフラットマップが実際にどのように機能するか、Zipに関連する興味深いことを示します。また、たとえば、ObservableからObservableを作成する方法など、いくつかの内部的なものに触れます。 一般的に、私はかなり興味深い作品を準備しました:)。



多くの人はおそらくそれについて考えたことすらなかったでしょうし、私はそれが興味深く有益なものになるような方法ですべてを提示しようとします。 最も重要なことは有益です。

---

便利なリンク

• MatthewのMobius 2015のビデオとスライドでは 、反応性について説明しています。
• Android用のリアクティブプログラミングに関するHaberに関するMatveyの記事 。
• Moxius 2016 でのRxおよびAndroid向けScala に関する Matveyのパフォーマンスのお知らせ。