Androidプロセス：私はあなたを生んだ、私と...

システムがプロセスを不必要に終了させた後、アプリケーションに何が起こるかを考えたことはありますか？ 悲しいことに、多くの人は、それがパラレルユニバースで発生し、彼らに関係がないかのように、それについても心配していません。 初心者は特にこの傾向があります。 リンクスタティックの安定性に対する彼らの盲目的な信仰は、単に驚くべきものです。



この記事では、アプリケーションプロセスに関連する第6戒律違反（殺さない）の結果として発生する可能性のあるいくつかのエラーと、それが他の世界からどれだけうまく戻るかを確認する方法について説明します。



プロセスがシステムによって強制終了される可能性があることは秘密ではありません。 そして、あなたは疑問に思っていました、これを真似することは本当に可能ですか？ システムをアプリケーションに「誘発」して、高貴なメモリを食い尽くす他のアプリケーションをたくさん起動し、適切なアプリケーションを殺すことでシステムがダウンすることを願うことができます。 ある種のシャーマニズムであることが判明しました。これは管理者のパスですが、プログラマーのパスではありません。 アプリケーションを簡単かつ迅速に強制終了できる方法、およびシステムがリソースを解放するように実行する方法に興味がありました。 結局、「実験条件」でこの動作を繰り返すことができれば、開発段階で多くのエラーをキャッチしたり、簡単に再現して原因を特定したりできます。



判明したように、必要なメカニズムはすでにSDKにあり、これは...ドラムロール...「アプリケーションの終了」ボタンです。







クリックすると、次のコードを実行するのに似ています。

//       . // ,   "Terminate Application"   “1”. System.exit(1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、これはプロセスを強制終了します。 システムが不要なプロセスを削除しようとすると、同様のアクションが発生します。



アプリケーションが完全に停止した後にアプリケーションを再開する状況を再現するには、次の一連のアクションを実行する必要があります。

1. Android Stidioを使用して、アプリケーションを起動します。
2. [ホーム]ボタンを押して、アプリケーションを最小化します。
3. Android Studioで、[Android]タブに移動し、アプリケーションを選択して[アプリケーションの終了]ボタンをクリックします。
4. 最小化されたアプリケーションを展開します。

Activityが破壊後の回復を適切に処理しない場合、すぐにそれに気付くでしょう。 せいぜい、それは落ちるでしょう、最悪の場合、それは凍ります。



そのため、最も秘密のタイプのエラーの1つを誘引することを学びました。 これらの間違いを予測する方法を学びましょう。 最も明白なケースから始めましょう。それから、あまり明確でないケースにスムーズに進みましょう。

状況1：静的は信頼できない

この状況を想像してください。1つのアクティビティで、特定のデータセット（姓と名など）を入力します。 このアクティビティは、データ入力の正確性を厳密に監視するため、データの「正確性」、および一般にそれらが入力されたという事実を確実に保証することができます。

[次へ]ボタンをクリックすると、入力されたデータを保存するオブジェクトが作成され、静的リンクに書き込まれます。次に、2番目のアクティビティが開き、このデータが適切な形式で表示されます。 たとえば、彼は次のように書いています。「あなたの名前はウラジミールプーチンです。」

コードからわかるように、最初のアクティビティでは、開発者は「bother」しないことを決定し、データを静的変数に配置しました。 これは、単純なシリアル化を受け入れられない、かなり異常なオブジェクトを渡す必要がある場合に非常に魅力的です。 彼はまた、2番目のアクティビティについて長く考えず、ゼロをチェックしませんでした。 なぜ、最初のアクティビティがすでにすべてを行ったのはいつですか



2番目のアクティビティでプロセスを正しく破棄するために、上記のシーケンスを実行します。 アプリケーションがクラッシュします。



どうした

ここでの問題は、nullのチェックの欠如ではありません。 最悪の問題は、ユーザーデータの損失です。 特にこれが唯一の場所である場合、静的オブジェクトはデータウェアハウスであってはなりません。 これは、通常の変数とシングルトンの両方に適用されます。 そのため、重要なものが静的に保存されている場合は、いつでもこの重要なものを失う準備をしてください。



どうする

このようなエラーの存在は、多くの場合、プログラマの資格が低いか、怠感が高すぎることを示しています。 それを正しく行う方法について、多くのチュートリアルが書かれています。 上記の例では、バンドルを介したデータ転送が最適です。 このデータをSharedPreferencesに書き込むことも、データベースの作成を検討する必要があります。

重要：シングルトンも静的変数であることを忘れないでください。 シングルトンを使用する場合は、データへのアクセスを容易にするツールとしてのみ機能する必要がありますが、データの唯一のリポジトリではありません。



Magic Powerアプリケーション

Applicationクラスをシングルトンとして使用する、またはApplicationクラスのonCreate（）メソッドでシングルトンを初期化するためのヒントをどのくらいの頻度で表示しますか。 伝えられるところでは、その後、彼はレーニンよりもクールになります。つまり、どんな状況でもすべての生き物よりも元気になります。 おそらく、これは私だけが遭遇する特別な妄想の場合です。 さらに、私が見つけたすべての出版物は、シングルトンの同様の特性を明らかにしていない。 彼らの中には、アクティビティクラスで開始した場合、ガベージコレクタによってシングルトンが破壊される可能性があると言う人もいます（私には少しワイルドに聞こえます）。 他のクラスでは、クラスローダーからクラスをアンロードすることで怖がっています（これはすでに真実のようです）。



今、私はここで何が真実で、何が推測であるかを知るつもりはありません。 いずれにせよ、これはリンクの統計情報を失う可能性を減らすだけですが、プロセスを停止することからあなたを救うわけではありません。 プロセスを停止すると、クラスローダーが完全に破壊され、それに伴いApplicationクラスを含むすべてのクラスが破壊されます。

状況2：すべての問題の解決策としてのsetRetainInstance

プログラマーが名と姓を使用して、フラグメントダイアログを使用して例を繰り返すことを決めたとします。

そのため、姓と名を入力するためのテキストフィールドを持つDialogFragmentがあります。 このフラグメントは、リスナーデータエントリに設定できます。 onCreate（）でリスナーへの参照を失わないために、setRetainInstance（true）が呼び出されます。



画面にボタンがあり、クリックするとこのダイアログが表示されます。



このような実装は、画面の回転に対して耐性があります。 すべてが時計のように機能します。 とりあえず...

ダイアログが開いているときに、プロセスのunningな破壊に一連のアクションを適用します。 デプロイされても、何も起こりません。 ただし、invokePersonChooseが呼び出されると、アプリケーションはNullPointerExceptionでクラッシュします。



どうした

setRetainInstance（true）は、ダイアログの破棄を許可しませんでした。 プロセスの破壊後、それにもかかわらず対話は破壊されました。 アクティビティは、フラグメントを可能な限り復元します。 残念ながら、リスナーは完全に異なるオブジェクトのために完全に異なる場所にインストールされているため、復元されません。 invokePersonChooseメソッドのダイアログでリスナーの呼び出しが発生すると、例外がスローされます。 そして、nullチェックがない場合の問題はありません。 空のリンクに適切に応答せずにヌルチェックを行うと、さらに悪い解決策になります。



どうする

フラグメントからアクティビティにメッセージを送信する方法の多くは、インターネットで説明されています。 残念ながら、すべてが正しいわけではありません。 次の方法は正しく、私のお気に入りの1つです。

• アクティビティは、目的のインターフェイスを実装します。
  
  
  アクティビティコードピース

   public class Situation2Activity extends Activity implements OnPersonChooseListener { //… @Override public void onPersonChoose(Person person) { Toast.makeText( Situation2Activity.this, String.format( getString(R.string.sit02_summary_message), person.firstName, person.lastName), Toast.LENGTH_SHORT ).show(); } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• フラグメントは、getActivityを介してアクティビティへの参照を取得し、対応するインターフェイスに導きます。 さらに、すべての作業はインターフェイスを介して実行されます。
  
  
  リスナーを断片的に取得する

   public void onAttach(Activity activity) { super.onAttach(activity); if (activity instanceof OnPersonChooseListener) mListener = (OnPersonChooseListener) activity; else throw new RuntimeException("Activity must implement OnPersonChooseListener."); }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

忘れてはならない唯一のことは、アクティビティはメッセージの送信に関してすでに破棄されているということです。 したがって、フラグメントがアクティビティに追加されているかどうかを確認してください。

アクティビティに加えて、親フラグメントまたはターゲットフラグメントを使用できます。



setRetainInstanceに関するほんの一言

これはsetRetainInstanceの特殊なケースにすぎません。 彼が隠すことができる（そして解決しない）問題の数はもう少しです。 リスナーとともに、他のすべての変数も失われます。 onSaveInstanceStateメソッドで保存されなかったものはすべて失われます。

また、ダイアログクラスが匿名の場合、問題を隠します。 新しいダイアログオブジェクトを作成するときに、いくつかのメソッドがオーバーライドされるとします。この場合、匿名クラスオブジェクトが作成されます。



このダイアログが破棄され、システムがそれを復元しようとすると、ClassNotFoundExceptionがスローされます。

ケース3：壊れたスレッド

アプリケーションの本質を次のようにします。

画面上のボタン。 ボタンをクリックすると、進行状況ダイアログが開き、UIとの対話がブロックされます。



コードから理解できるように、このダイアログはブロードキャストメッセージを送信することで閉じることができます。 これは、リンクを保存する必要がなく、アプリケーションコンテキストがあれば十分であることを意味します。

ダイアログを開始した直後に、しばらくの間何かをするスレッドが開始されます。 作業の最後に、スレッドはメッセージを送信して進行ダイアログを閉じます。



このコードを実行して、アプリケーションの最小化のためにその完了を待たずにプロセスをオフにすると、デプロイ時に問題が発生することはなく、アプリケーションはクラッシュせず、ダイアログが表示されます。 私たちは少し待っています...私たちはまだ待っています...それから私たちはまだ待っています...それは長い間行われていたはずですが、ダイアログは閉じません。



どうした

プロセスが破棄されると、そのすべてのスレッドが停止し、復元されると、メインスレッドのみが開始されます。 したがって、スレッドの実行時間が長すぎる場合は、停止する準備をしてください。 また、長い間何かをする必要はありません。待機通知を使用している場合でも、このレーキを踏むことができます。 パブリック静的最終オブジェクトをブロック用のオブジェクトとして使用すると、プロセスが強制終了されるときに静的オブジェクトが例外でないことを既に知っているため、特に面白いでしょう。



どうする

タスクが別のサービスに移動して新しいプロセスで実行するのに時間がかかる場合、さらにフォアグラウンド通知を出力する場合、プロセスは強制終了されます。 待機通知の場合、すべてが少し複雑になり、特定の状況に依存します。 一般に、スレッドの操作のトピックは非常に広範囲であり、特定のアドバイスを与えることはここでは不適切です。 複雑にならない限り、野生に登ることはできません。そこから抜け出すことはできません。

ケース4：どこへの手紙

単一のビューを持つアクティビティがあります。 彼女は、ブロードキャストメッセージを受信するように登録されています。 アクティビティがこのようなメッセージを受信すると、このメッセージの内容に応じてビューの色が変わります。 [表示]をクリックすると、2番目のアクティビティが開き、色を変更するために同じメッセージを送信できます。



画面の回転中に最初のアクティビティが破壊されないように、configChangesがマニフェストファイルに追加されます。

 <activity android:name=".situation_04.Situation4FirstActivity" android:configChanges="orientation|screenSize"/>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のアクティビティにはボタンがあり、クリックすると色を変更するメッセージが送信されます。



最初のアクティビティに戻ると、ビューの色が変更されます。



ただし、2番目のアクティビティに切り替えて、アプリケーションを最小化し、プロセスを強制終了してからアプリケーションをデプロイすると、予期しないことが発生します。 色変更ボタンを何度クリックしても、最初のアクティビティに戻ると、そのビューは真っ白になります。



どうした

アクティビティのスタックが保持されたという事実にもかかわらず、アプリケーションがデプロイされた後、2番目のアクティビティのみが復元されました。 実際、色変更メッセージはどこにも行きませんでした。 その時以来、このイベントにサブスクライブされたオブジェクトはありませんでした。 最初のアクティビティに戻ったときに復元されましたが、色変更イベントをサブスクライブするには遅すぎました。



どうする

まず第一に、主なものを理解する必要があります-あるアクティビティで作業する場合、残りのアクティビティは存在しません。 情報を伝える必要がある場合は、そのためのsetResultを使用してください。 それでも、盲目的にライフサイクルに頼るべきではありません。 例からわかるように、アクティビティ1がアクティビティ2を起動した場合、これは最初のアクティビティのonCreateメソッドが実行されたことを意味しません。

この例では、アクティビティスタックの問題だけでなく、メッセージの送信に関連するすべての問題も示していることに注意してください。 唯一の例外は、マニフェストに登録されているか、AlarmManagerを介してスケジュールされているBroadcastReceiverです。 他のすべては、受信者へのメッセージの配信について100％の保証を与えるものではありません。

おわりに

「経験豊富なコーダー」にとって、これらの状況は明白に思えるかもしれず、例は非常に不自然であるため、単純に現れます。 しかし、私たちはかつてゼロから始めて、今では恥ずべきことになるコードを書きました。 私の旅の最初にこのレーキを知っていれば、額の円錐形が少なくなります。 この記事が、真の多数の初心者のAndroidプログラマーの道しるべになるのに役立つことを願っています。 「経験者」から、コメントを見てうれしいです。 さらに良いことに、リストを完成させたり書いたりすると、この記事は「How？！」カテゴリのバグを見つけるのに役立ちました。 これはできません！」



これで終わります。 ご清聴ありがとうございました。 最後になりますが、私のスリーブにはまだ1つの異常なケースがあります。 まだ最後まで研究されていませんが、すぐにこのタフなナッツを割ってみたいと思います。 継続を待ちます。