[動画] Android Paranoid mitapからのレポート

Androidはほぼ10歳です。



2回目のAndroid Paranoid mitapでYandexのサンクトペテルブルクオフィスに来たすべての人とお祝いのお茶会でこれを祝うことにしました。 すぐに言ってやった。 残念ながら、マシュマロ、チョコレートチップクッキー、ジェリービーンズは3月28日に終了しました。







代わりに、ビデオに記録されたレポートと、Android開発者向けの有用な情報の短い絞り込みがあります。 カットの下で

• アプリケーションアイコンをクリックした後の動作。
• アプリケーションをKotlinに変換し、300行のコードに収める方法。
• Androidバックグラウンドツールの変更方法
• RecyclerViewでアニメーションをすばやく取得する方法。

RecyclerViewのアニメーションについて

Yandex.MoneyのDanil Ternovが、RecyclerViewでアニメーションを迅速かつコスト効率よく取得する方法について説明しました。



仕事で試してみたい人のために-GitHubのデモ。 実装の詳細はビデオにあります。

「アプリケーションアイコンをタップするとどうなるか、

さらに少し前に？」と、Sberbank TechnologiesのVladimir Tebloev氏は言います。 Androidのすべての生活がビューとアクティビティに制限されていると考えており、カーネル、ブートローダー、ダルウィックについて何も知らず、Androidが接合子を必要とする理由を常に疑問に思っている場合は、ビデオを見ることをお勧めします。 興味のある人のために-3つのエピソードで絞ります。



エピソード1-システムレベルと接合子



むかしむかし、若いモバイルOSのエンジニアは、4つのレベルのシステム操作を設計しました。

• ドライバーとバインダーを備えたカーネル。
• ルートライブラリ、OSライブラリ、およびDalvik。
• アプリケーションフレームワーク、不変のシステムコンポーネント-コンテンツプロバイダー、アクティビティマネージャーなど。
• カスタムアプリケーション。

少し前に、DalvikはAndroidランタイムに変わりましたが、これはプロセスの本質を変えませんでした-ランチャーアイコンをタップした後、信号を受信し、アクティビティマネージャーに渡し、Zygoteに転送され、新しいアプリケーションを作成します。



Zygoteは、システムの起動時に起動し、プライマリ仮想マシンを初期化するデーモンです。 Zygoteを使用すると、Androidアプリケーションのプロセスを作成して、すべてのアプリケーションを実行するために必要な自分とルートライブラリのクローンを作成できます。 必要なライブラリはすべてプライマリZygoteインスタンスですでに初期化されているため、これにより時間とメモリが節約されます。 あとは、Copy-on-Writeを使用してProcessIDを変更するだけです。





左側はプライマリインスタンス、中央はAndroidコンポーネントを担当するZygote、右側はアプリケーションです。



エピソード2-ライフサイクルとプロセスの相互作用



Androidには、5種類のプロセスと3つの優先度が割り当てられています。



重要な優先度は、アクティブなプロセス（ユーザーが現在対話しているプロセス）に割り当てられます。 これは、オープンアクティビティでも、UIの音楽プレーヤーでもかまいません。



通常、目に見えるプロセス、たとえば他者によってブロックされたアクティビティに高い優先度が与えられます。 アクティブなプロセスに十分なメモリがない場合、可視プロセスは終了します。 同じ優先順位には、ユーザーが対話しないサービスプロセスが含まれます。データプロセスのダウンロード、同期などを担当します。



優先度の低いプロセスは、すでに停止しているアクティビティに関連しています。 Androidは、これらのプロセスを起動順に並べ替え、メモリに保存して、古いものから新しいものの順に完了します。 最後のカテゴリ-「ゾンビプロセス」-一部のストリームを初期化できますが、ライフサイクルのすべてのコンポーネントは既に破棄されています。



プロセスが相互作用する主な方法は、バインダーを介したIPCです。 これは、すべてのAndroidルート構造が機能するドライバーです。 相互作用モデルを次の図に示します。







プロセスAのアクティビティが別のプロセスからデータを受信するとします。 Foo（）メソッドはバインダーにアクセスします。バインダーは、入力データを順番にシリアライズおよびパックし、処理のためにターゲットプロセスに渡します。 次に、必要なデータが逆シリアル化され、プロセスBがそれを使用して、逆の順序で操作を実行します。



それとは別に、ウラジミールはAndroidでアクティビティを作成するすべての段階について話しました。 詳細はすべてビデオに記載されています。

「ユーザーは60 FPSを望んでおり、

それがバックグラウンド作業の目的です。」



EPAM Vladimir Ivanovは7年間AndroidとiOS向けに執筆しており、Windows Phoneを埋めることに成功しました。 ウラジミールは、メインのAndroidスレッド以外のタスクを完了するためのツールの進化について語りました。 チェーン上のスピーチ-AsyncTask、ローダー、エグゼキューター、EventBus、RxJava、Kotlinのコルーチン。



レポートには多くの例がありますが、ここに小さな部分があります。



反復1-AsyncTask



天気予報を表示するアプリケーションを作成しているとします。 アクションのシーケンスはおよそ次のとおりです。

1. DoInBackground（）メソッドを定義します。
2. httpクライアントを使用して、サーバーにリクエストを送信します。
3. 応答を取得します。
4. ユーザーを表示します。

最後の段階では、複雑さが生じます。バックグラウンドからUIストリームに答えを取得して返すだけではできません。 UIが同時に他のスレッドを使用する場合、松葉杖と複雑なロックを考える必要があります。 これを避けるために、インターフェース開発者はUIストリームからのみ更新することをお勧めします。



したがって、UIで何かをする方法が必要です。 AsyncTaskは、このためにonPostExecuteメソッドを使用します。

public class LoadWeatherForecastTask extends AsyncTask < String, Integer, Forecast > { public void onPostExecute(Forecast forecast) { mTemperatureView.setText(forecast.getTemp()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチには1つの大きな問題といくつかの欠点があります。5年以上前の実動プロジェクトを除き、AsyncTaskは停止しました。



欠点は次のとおりです。



1）ネットワーク要求のための多くのコード。

2）AsyncTaskはアクティビティのライフサイクルについて何も知らないため、メモリリークを引き起こす可能性があります。

3）設定をオンザフライで変更する場合（たとえば、画面が上下逆になる）、リクエストを過剰に実行する必要があります。



反復2-ローダー



ローダーにはAndroid 3.0が付属しています-AndroidチームはAsyncTaskの問題を解決するためにそれらを考案しました。

 class WeatherForecastLoader(context: Context) : AsyncTaskLoader < WeatherForecast > (context) { override fun loadInBackground() : WeatherForecast { try { Thread.sleep(5000) } catch(e: InterruptedException) { return WeatherForecast("", 0F, "") } return WeatherForecast("Saint-Petersburg", 20F, "Sunny") } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特に、構成を変更するときに結果を再利用することについて話します。 問題は次のように解決されます。



1）アクティビティに関連付けられたLoaderManagerは、いくつかのローダーへのリンクを特別な構造で保存します。

2）アクティビティにより、すべてのLoaderManagerがNonConfigurationInstances内に保存されます。

3）新しいアクティビティを作成する場合、システムはNonConfigurationInstancesからデータを転送します。

4）アクティビティは、すべてのローダーでLoaderManagerを復元します。



短所：

1）まだ多くのコードがあります。

2）インターフェイスは依然として複雑であり、クラスは依然として抽象的です。

3）ローダーはAndroidのプラットフォームAPIであり、純粋なJavaで再利用できないことを意味します。



反復3-EventBusおよびThreadPoolExecutors



ThreadPoolExecutorsの出現により、バックグラウンドからUIへのデータ転送は次のようになり始めました。



1）Backgroundクラスを開始し、その中で-Service変数。

2）ScheduledThreadPoolExecutorでこのクラスを必要なサイズで初期化します。

3）クラスを実行可能または呼び出し可能にするヘルパーメソッドを作成します。

 public class Background { private val mService = ScheduledThreadPoolExecutor(5) fun execute(runnable: Runnable) : Future < *>{ return mService.submit(runnable) } fun < T > submit(runnable: Callable < T > ) : Future < T > { return mService.submit(runnable) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バックグラウンドで実行することに加えて、結果をUIに返す必要があります。 これを行うために、UIスレッドに何かをポストするハンドラーとメソッドを作成します。

 public class Background {…private lateinit var mUiHandler: Handler public fun postOnUiThread(runnable: Runnable) { mUiHandler.post(runnable) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのUIが特定のメソッドが完了したことを知る必要はありません。 責任を共有するために、EventBusを思いつきました。 これは、バックグラウンドスレッドからUIにイベントを送信する方法です。UIでは、複数のリスナーが共有バスに接続され、これらのイベントがこれらのイベントを処理します。







EventBusの既製の実装がいくつかあります。 それらのいくつかは、Google Guava、Otto、GreenBot Eventbusです。



マイナスのうち：

1. イベントデータソースは、その処理方法について何も知りません。
2. スピーカーの経験によると、しばらくすると、EventBusのコードをサポートできなくなります。

4番目の反復-RxJava、または「それで十分！」



誰かがバックグラウンド作業のための便利なツールを考え出す必要がありました。 その結果、イベントストリームを操作するための大きなフレームワークであるRxJavaができました。



GitHubで承認される必要があるコードを書いているとします。 必要な操作ごとにメソッドで開始する必要があります（この場合、ログインしてリポジトリのリストを取得します）。

 interface ApiClientRx { fun login(auth: Authorization) : Single < GithubUser > fun getRepositories(reposUrl: String, auth: Authorization) : Single < List < GithubRepository >> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実行の結果はSingle（ゼロまたは1つのイベントからのストリーム）になります。 作業の結果は、ユーザーが必要とするすべてを返す2つのメソッドのインターフェースです。



短所：

1. 急な学習曲線、学習は長くて難しい。
2. 多くの演算子、その違いを理解することは困難です。
3. 2つのクエリと2つの演算子からの単純なコード用に約20個のオブジェクトが作成されます。
4. 無関係なスタックトレース、30行のうち、コードに関連付けることができるのは1行のみです。

長所：

1. RxJavaは事実上の標準です。 VladimirはTwitterで調査を実施し、新しいプロジェクトの開発者の65％がRxJavaを使用することを発見しました。
2. 強力なAPI
3. RxJavaは、大規模なコミュニティを持つオープンソースフレームワークです。
4. RxJavaコードは、単体テストで簡単にカバーされます。

反復5-コルーチン



コルーチンは、Kotlin言語内でサポートされているバックグラウンドライブラリです。



その利点：



1.ノンブロッキングアプローチ-バックグラウンド作業中にメインスレッドが実行され、進行中に結果が埋め込まれます。

2.同期スタイルの非同期コード

 private fun attemptLogin() { launch(UI) { val auth = BasicAuthorization(login, pass) try { showProgress(true) val userInfo = login(auth).await() val repoUrl = userInfo.repos_url val list = getRepositories(repoUrl, auth).await() showRepositories(this@LoginActivity, list.map { it - >it.full_name }) } catch(e: RuntimeException) { Toast.makeText(this@LoginActivity, e.message, LENGTH_LONG).show() } finally { showProgress(false) } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3）演算子ではなく言語の手段。

4）勉強するだけ-学習曲線はほとんど曲線ではありません。

5）少し検討した後、ユニットテストは同期コードの場合とほぼ同じになります。



短所：



1）最近、実験状態から外れました。

2）これは言語の一部ではなく、ライブラリです。

3）すべてにアダプターがあるわけではありません。

4）コルーチンはRxJavaの代替ではありません。 複雑なイベントストリームがある困難なケースでは、あまり役に立ちません。



コルーチンに関する残りの例（例を含む）は、レポートで確認することをお勧めします。

Kotlinで300行プログラミングにコードを適合させる方法

1年前、Google IO 2017で、Kotlinが公式のAndroid言語になったことが発表されました。 Alfa BankのYuri Chechetkinによる、新しい言語への移行を開始し、クラスを300行に減らして、狂わないようにする方法に関するレポート。



このレポートは、コンパクトで美しい文章を書く方法に関する実践的な教育プログラムです。 Kotlinの主な機能を熟知している上級ユーザーを対象としています。



レポートには、2つの言語でのコードの使用例と比較例がたくさんあるため、ここでは興味深い事実と結論のみを示します。



Kotlinへの主要な移行の問題：

1. レガシーJavaコード。 数千行のコードの大規模なクラスは、開発環境を使用して変換するのが非常に困難です。
2. 依存関係-ロンボク、ストリームAPIなど。
3. チーム内の過剰なコード要件。 300行の制限のコードの定期的な自動チェックとコードレビューが実行されます。
4. Kotlinは新しい言語であり、統一された規則がなくなるまで要件を策定することは困難です。
5. Kotlinはより長い時間コンパイルします。
6. 構文糖は「大きな力ですが、大きな責任」です。

結論：

• Kotlinを使用して1年が経つと、コードが少なくなりました。コードがきれいになり、コードのレビューがより便利になりました。
• 古いJavaメソッド、追加の依存関係、標準言語機能のみはありません。
• 松葉杖とバグが少ない。
• より多くの機能-Kotlinで実装されたいくつかのものはJavaで書くことができません。

残りはビデオにあります。

YK Moneyチームのイベントや日常生活をVK 、 Facebook 、 Instagramでフォローしてください。

すべてのYandexの会議と会議はY. Vstrechahで行われます。