私はそれが有用見つけることができれば、長い時間のためのインタビューのトピックを行い、あなたが今日に最適の崩壊の側面についての記事を集める助けていない面接を終了し、パートナーシップの少しのアイデアを持っている必要がありますかわからない、コレクションは面接、フォローアップを更新していきますポイントフォロワー
APPの開発者は何をする（フラッシュバック）がクラッシュが発生しましたか？多くの人々は、すべてのJava崩壊を失った「ダイジェスト」、例外をキャッチし、ログによると、バックのコードのフラッシュを見つけると言うでしょう。プログラムは、他の異常を持っているかどうかに関しては、それは、神が、チューブを望んでいるものです。はい、緊急事態のため、この方法では解決策と考え、真実が何であるかフラッシュバック？かどうかの根本原因を解決しますか？
クラッシュ率は客観このインデックスの崩壊を測定する方法、そして、アプリケーションの品質レベルの基本的な指標であり、そしてどのように我々は、安定性とクラッシュ関連をご覧ください。
Androidの2つのクラッシュ：
- Javaのクラッシュ
- ネイティブクラッシュ
簡単に言えば、ジャワの崩壊は、Javaコードで、キャッチされない例外は、プログラムが予期せず終了する原因がありました。クラッシュネイティブ、それは一般的に、ネイティブコードで不正なアドレスへのアクセスであるので、それはアドレス問題整列させることができる、またはプログラム・イニシアチブは、対応する信号の信号は、プログラムが予期せず終了する原因となる必要があります場所中止を、取りました。
私たちはどのように捉えると異常な手順を表示される「崩壊」、および製品の崩壊は、これらの例外は、比較的大きな関係を持って処理します。多くの中小企業のために、あなたはいくつかのサードパーティのサービスを選択することができます。現在、さまざまなプラットフォームにはユニオンのアリ友人、テンセントBugly、網易クラウドキャッチ、GoogleのFirebaseなどを含め、繁栄しています。レバレッジを理解するために！
クラッシュ率はそれのアプリケーションの安定性と完全に同等にできないのですか？答えは確かではありません。クラッシュの処理、私たちはしばしば、この問題にANR（アプリケーションが応答しない、応答しない）が発生します。
システムダイアログボックスは非常にユーザー耐え難いあるユーザの操作を、中断するポップアップ表示されますときANRが発生します。
ANRのアプローチ：
FileObserver変更を/data/anr/traces.txtモニター使用。残念ながら、ROMの高いバージョンの多くは、ファイルのアクセス権を読んでいません。あなたが唯一の他のパスを考えるかもしれない。この時間は、あなたは、Googleが海外のサービスを再生使用することができ、かつ国内のマイクロチャネルは、HCフレームワークは、アンドリュースが実装されたシステムに依存しない通信フレームワークのセットです（Hardcoderフレームワークを使用し、それはへのリアルタイムアプリケーションROMベンダーと「話」を可能に、目標は完全にスピードと品質のアプリケーションを改善するためのスケジューリングシステムリソース、そして効果的にすべての人の携帯電話の体験を向上させる）、ベンダーに大きな権限を獲得することです。また、携帯電話のROOTをオフにすることができますし、traces.txtファイルを取得します。
頻繁にクラッシュに加えて、いくつかの例は、アプリケーションが、例えば、予期せず終了する原因があります。
- イニシアチブ自殺。Process.killProcess（）、出口（）、等
- クラッシュ。またはJavaネイティブ・クラッシュの出現
- システムが再起動されます。異常なシステム、停電、ユーザーは自動的に再起動し、その上、我々は、アプリケーションの起動時間が少ないの前のレコードの値よりも実行されて比較することができます
- システムによって殺されました。タスクマネージャのシステムから交差殺さ低メモリキラー、など
- ANR
アプリケーションの起動時に私たちは、イニシアチブの自殺または更新フラグの崩壊後、休暇を通じてので、この次のスタート動作チェックの際に発生するかどうかを確認することができるようになります、フラグを設定することができます。理論的には、この例外トラップメカニズムが100％までである、上記5つの出口のシナリオに対応して、私たちは自殺を除外しており、残りの3つの異常終了を監視することを望んで、（単独クラッシュ統計を）両方のシナリオをクラッシュするためのイニシアチブをとります報道。
ANR、低メモリキラー、殺すために強いシステム、クラッシュ、停電やその他の問題が正常にキャプチャすることができないように、この異常終了を検出することにより、反射させることができます。もちろん、ユーザーがタスクマネージャのシステムからアプリケーションを越えなど、偽陽性のいくつかの異常率があるでしょう。大規模なデータラインの場合、それはまだ私たちはコード内のいくつかの隠し問題を発見することができます。
台湾によると、状態の適用前と後に、私たちが突然異常に前面と背面の終了に分け予期せず終了終了することができます。舞台裏の主な原因である異常終了「システムによって殺害」、もちろん、我々はそうで異常事態ANR、OOMとしてより関連性を持っているであろう、フロントデスク異常終了についてもっと心配になります。
私たちの毎日の仕事が困難な様々な問題が発生します、「崩壊」は、問題のより一般的な種類の一つです。問題は、事件を解決する必要が解決するとより多くの経験は、我々は準のより多くの熟練した、迅速なポジショニングを分析します。もちろん、ルーチンの多くは、私たちがどのような情報に注意を払う必要があり、このような「犯罪現場」用として、またありますか？どのように多くの「証人」と「手がかり」を見つけるには？何が一般的なプロセス「を、ケースを調査」されますか？「例」のさまざまな種類の調査方法を使用すべきかでしたか？
クラッシュ「真実は常に唯一である」と信じてすることはひどいではありません。
墜落現場は、私たちの「最初のシーン」である、それは多くの貴重な手がかりを保持します。今、あなたは、より多くの情報の中にさらなる分析のためのより明確な方向性をタップすることができ、よりもむしろ推測に頼ります。
クラッシュに関する基本的な情報、我々はクラッシュの予備的な判断をすることができます。プロセス名、スレッド名。プロセスの崩壊は、クラッシュがUIスレッドでの場所ではありません、フォアグラウンド・プロセスまたはバックグラウンド・プロセスです。
スタックとタイプの崩壊。崩壊は、Javaの崩壊、ネイティブクラッシュやANRの一部であり、それは懸念のクラッシュポイントの異なるタイプで同じではありません。特に望ましいスタックはスタックを折りたたみ、内部の特定のシステムクラッシュのコード、又はAPPコードを参照。
FATAL EXCEPTION: main
Process: com.cchip.csmart, PID: 27456
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.TextView.setText(int)' on a null object reference
at com.cchip.alicsmart.activity.SplashActivity$1.handleMessage(SplashActivity.java:67)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:179)
at android.app.ActivityThread.main(ActivityThread.java:5672)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:674)
情報システムは、時々、いくつかの重要な手がかりと、問題を解決するために、私たちに非常に大きな助けています。
Logcat。これは、ログアプリケーション、システムを実行しています。システムのアクセス許可の問題なので、Logcatは、現在APPに関連する情報が含まれていてもよい獲得。イベントを記録するシステムは、ファイル/システムの/ etc /イベント・ログのタグに記録されているいくつかの基本的なAPPの実行を、logcatを特徴とします。
//system logcat:
10-25 17:13:47.788 21430 21430 D dalvikvm: Trying to load lib ...
//event logcat:
10-25 17:13:47.788 21430 21430 I am_on_resume_called: 生命周期
10-25 17:13:47.788 21430 21430 I am_low_memory: 系统内存不足
10-25 17:13:47.788 21430 21430 I am_destroy_activity: 销毁 Activty
10-25 17:13:47.888 21430 21430 I am_anr: ANR 以及原因
10-25 17:13:47.888 21430 21430 I am_kill: APP 被杀以及原因
モデル、システム、メーカー、CPU、ABI、Linuxバージョン。寸法が数十できるだけ多くを収集することにより、一般的な問題を探すことに役立つだろう。
OOM、ANRは、仮想メモリが使い果たされるなど、メモリに関連するクラッシュの多くは直接関連しています。ユーザーの携帯電話のメモリは「2GB以下」との二つの領域「よりも2ギガバイト」に分かれている場合は、「2ギガバイトを以下」見つける崩壊の利用者率は「2GB以上」のユーザー数倍です。
残りのシステムメモリ。システムメモリの状態について、あなたは直接、ファイルは/ proc / meminfoのを読むことができます。システムの利用可能なメモリが非常に小さい場合（10％未満のMemTotal）、OOM、GC、システムの自殺を引き出しやその他の問題の多くは、頻繁に非常に受けやすいです。
アプリケーションは、メモリを使用しています。Javaのメモリ、RSS（常駐セットサイズ）、PSS（比例セットサイズ）を含め、私たちは、アプリケーション自体のメモリの大きさと分布を占めると結論付けることができます。PSSと計算RSS / procの/セルフ/ SMAPによっては、例えば、そうやので、さらにより詳細な分類統計APK、DEXすることができます。
仮想メモリ。仮想メモリは、/ procの/自己/利用可能状況は、あなたが/ procを/セルフ/マップファイルを使用して、特定の分布を得ることができます。時々、私たちは、一般的に、仮想メモリにはほとんど注意を払って、多くの同様のOOM、tgkillおよびその他の問題は、仮想メモリによって引き起こされます。
Name: com.xmamiga.name // 进程名
FDSize: 800 // 当前进程申请的文件句柄个数
VmPeak: 3004628 kB // 当前进程的虚拟内存峰值大小
VmSize: 2997032 kB // 当前进程的虚拟内存大小
Threads: 600 // 当前进程包含的线程个数
一般的には、32ビットプロセスのために、アプリケーション障害の問題を引き起こす可能性がある32ビットCPU、メモリ3GBの仮想メモリーた場合です。64ビットCPU場合は、仮想メモリは、一般的に3〜4ギガバイトの間です。私たちは、64ビットプロセスをサポートする場合はもちろん、仮想メモリが問題になることはありません。Google Playはサポートが90％を超えてきましたが、店はリリースを区別するCPUアーキテクチャのタイプをサポートしていない、最高に広がるものの、2019年8月には時間がかかり、国の64ビット、64ビットのデバイスをサポートしている必要がありますが必要です。
時には、アプリケーション・ヒープ・メモリとデバイスメモリを見つける比較的大きな関係とリソースをリークする可能性がある、非常に適切である、またはメモリ割り当てエラーが発生します。
ファイルハンドルFD。利用可能なの/ proc /自己/制限することにより、ファイルハンドルの制限、ファイルハンドルの最大数は、一般的に1024単一のプロセスを開くことが許可されています。ファイルは、800がより危険であるよりも多くを扱う場合は、文書またはスレッド漏れがある場合は、我々は、ログに対応する出力すべてのFDとファイル名にさらなる調査が必要です。
opened files count 812:
0 -> /dev/null
1 -> /dev/log/main4
2 -> /dev/binder
3 -> /data/data/com.xmamiga.sample/files/test.config
...
スレッドの数。スレッドサイズの現在の数は、仮想メモリがあまりにも多くのスレッドとファイルが圧力を扱う必要があります、スレッドは2メガバイトの仮想メモリを考慮することができる、上記のステータスファイルによって得ることができます。私の経験では、400以上のスレッドの数は、より危険である場合。すべてのスレッドに関連付けられている問題がある場合は、ログに出力され、対応するスレッドIDスレッド名にさらなる調査が必要です。
threads count 412:
1820 com.xmamiga.crashsdk
1844 ReferenceQueueD
1869 FinalizerDaemon
...
JNI。それに注意を払っていない場合は、故障引用しやすい、JNIを使用する場合は、いくつかのクラッシュ爆発リストを引用。
システムに加えて、実際には、私たちのアプリケーションを使用すると、関連する情報の多くを残すことができ、より良い自分自身を知っています。クラッシュシーン。ビジネスで発生した活動または断片、で発生したクラッシュ、RBIの開発プロセスの詳細ログは異なるキーの操作パス、我々はクラッシュが私たちに比較的大きな助けになります再現重要なユーザ操作のパスを、記録することができます。その他のカスタム情報。関心の異なるアプリケーションにフォーカスは同じではないかもしれません。
あなたがサイト上でとても多くの情報を持っていたら、あなたは本当の「検出」ツアーを開始することができます。限りの努力を費やすことをいとわないとして「ケース」のほとんどは、真実を最後にすることができます。いくつかの珍しいまたはキーポイントを見つけることが常に熱心な忍耐と慎重な分析を通じて恐れて問題とすること、さらには疑うと検証するためにあえてしないでください。
重要な情報を見つけるためにログを介して最終のフォーカス嘘を特定し、分析し、問題が一般的な判断力を持っています。一般的に、私はこの段階で優先順位を設定すると、以下の点に焦点を当てることができますお勧めします。
- 重大度を確認してください。解決それはまた、費用対効果の高い、私たちの優先順位トップのクラッシュに依存したり、そのような主な機能の崩壊など、ビジネスに大きな影響を持ってクラッシュ。コーナーの崩壊を解決するために数日を費やすことはありません、削除された次のバージョンの機能を置くことが可能です。
- 基本的な情報の崩壊。そして、記載クラッシュタイプの異常決意、判断の実質的に崩壊しています。
このステップは、すでに結論付けることができた後、一般的には、最も単純に崩壊します。
Javaの崩壊。NullPointerExceptionなど、より明白なクラッシュのJava型は、NULLポインタで、OutOfMemoryErrorがリソースの不足で、この時間は、「メモリ情報」と「情報資源」のログを参照して、さらに行く必要があります。
ネイティブクラッシュ。私たちは、信号、コード、障害addrと他のコンテンツと同様に、クラッシュJavaスタックの時間を観察する必要があります。各信号の意味について、あなたはクラッシュ信号導入を表示することができます。より一般的SIGSEGVとSIGABRT、前者一般に不正ポインタをもたらす、ヌルポインタによるもので、主にANRの後者であり、（アボートを呼び出す）結果として終了します。
ANR。原因はロック待ちためであるかどうか、メインスレッドのスタックを見てみましょう。そして、さらにI / Oの問題、あるいはCPUの競争の問題を決定するために、iowaitの、CPU、GC、システムサーバおよびその他の情報ログANRを見て、または伴うGCリードの大規模な数にこだわっています。
上記の方法は、まだ効果的に問題を見つけていない場合、私たちは共通点は何もない崩壊のこの種を見つけることを試みること。共通点を見つけ、違いはさらに、それより遠くの問題から発見されます。
モデルは、システムが、ROMには、ベンダーは、情報システムは、そのような一般的な問題として、重合寸法として用いることができる収集ABIは、x86の電話で、このモデルは、Android 8.0であるだけでなく、だけでなく、サムスンだけでなく、さシステム上。アプリケーション情報は、このようなようにオープンリンク、動画が再生され、国、地域及びあるとして重合寸法として使用することができます。
一般的には、あなたの次の繰り返し発生する問題についてより明確なガイドラインを持つことができました。
我々はすでにクラッシュの原因について知っている場合は、さらに多くの情報を確認するために、我々はクラッシュを再現しようとする必要があります。我々はクラッシュするか見当もつかないが、また、ユーザの操作パスを再現して、クラッシュの原因を分析するために行くために試してみたい場合。
「限りローカル再生、私はできソリューションとして」、私はこれはテスト言葉で多くの開発であると考えています。我々は、ログを増やすか、さらなる分析のための機器やツールのデバッガ、GDBや他の種類を使用するために使用することができ、上記の主な理由は、安定した再生経路のように自信を持っています。
我々は素晴らしい問題の多様性を発生することがあります。例えば、メーカーが基本となる実装を変更し、新しいAndroidシステムの実装が変更される可能性があり、我々は時々、製造元のマニュアルブラシROMまたはROMを引っ張って行く必要があり、Googleに行くのソースコードをオンにする必要があります。私たちは孤独、繰り返し憶測、白髪を繰り返し、繰り返し検証を我慢する必要がある多くの困難な問題。 - しかし、この問題は深刻な手続き問題ではなく、ペニー賢明とポンド愚かを見ることです。
システムがクラッシュし、多くの場合、私たちは非常に無力な感じさせる、それはメーカーがつながる修正ROMであってもよいし、バグのAndroidのバージョンである可能性があります。スタックは、このような場合には完全に私たち自身のコードを折りたたむことがあり、直接問題を特定することは困難です。行うことができます：
-
考えられる原因については。上記の一般的な分類を通じ、我々はいくつかのベンダー固有のROMでのシステムの問題のバージョン、または問題を見てみましょう。クラッシュログは、私たち自身のコードを持っていますが、オペレーティング・パスとログではないかもしれないが、あなたには、いくつかの疑問点を見つけることができます。
-
避けるようにしてください。不審なコードの呼び出し、不適切なAPIを使用するかどうかを見る、あなたは避ける他の実装を置き換えることができます。
-
フックは解決します。ここでは、Javaのフックとネイティブフックに分かれています。これだけの例外を生きるダイレクトキャッチの練習を参照して、システムにアンドロイド7.0、アンドロイド8.0表示されることがあります。
あなたはこれらの例の両方を行う場合は、上記のほとんどは、システムのほとんどが同様にクラッシュし、解決したり、崩壊を避けることができるはずです。もちろん、常にユーザーの実際の環境に依存する必要があるいくつかの困難な問題があり、これらは、トレースする能力を持っており、同様のダイナミックをデバッグする必要があります。
攻撃と守備の崩壊が長いプロセスであり、我々はそれが芽の段階で挟持され、早期のクラッシュを防ぎます。問題のいくつかをカバーするために強制的ならば技術者として、私たちは盲目的にこれらの数の崩壊を追求するべきではありません、ユーザーエクスペリエンス最初に、より多くの逆効果になりがち必要があります。私たちは、プロセスが背後に実行されていることを確実にするために、崩壊の原因の本質を理解し、本当の問題は、最初からソースを隠そうとするのキャッチを使用して自由に感じるべきではありません。崩壊を解決するだけでなく、表面にポイントを行う過程では、このクラッシュは解決するが、クラッシュや予防のこのタイプを解決する方法を検討すべきではないだけのために。