アプリ開発提案テクニック
操業準備
プロジェクトの業務コードが始まる前に、これらの問題を解決したほうがいいです。それらは:コンポーネントルーティング 非同期処理 モジュール工学 グローバルネットワークブロック 異常統一プロセッサ ベースビューコンポーネントパッケージ ログ記録ツール カスタムMVPテンプレートなど、無数の同じコードを書き込むテンプレートを解決する 。
機種が合う
特定の機種に問題がある場合は、焦らないでください。私たちは次の方法を試してもいいです。逆コンパイルrom、下の階の変更（条件が高い） を見てください。当該メーカーのエンジニアに連絡する（できれば） コピー全体として、私たちはapiのソースコードを呼び出して単独で依存し、システム内の を放棄します。は、この機種で正常な同種のappに対して逆方向のコードを参照して を実現する。は、様々なバージョンのAndroid APIの変化を参照して、ソースから を行うことができます。反射を利用してこの特定の機種の中のある私達が知りたい方法を取得し、動的に調整する 。
崩壊を検査して退却します。
1.アプリがデバッグ中にフラッシュバックが発生した場合、ログcatの下でログが新しくなったプロセスによって消去されます。この時にフィルタをNo filterに選択してログレベルをerrorに選択してください。前回の崩壊のログが表示されます。
2.携帯は私達のそばにないという状況があります。私達もデバッグツールを使うことができません。この場合、いくつかの第三者のログ記録ツールにアクセスすることができます。開発状態では、友盟360などのsdkは推奨されていません。私たちのアプリはネットに接続できないので、崩壊してしまいます。ログをローカルファイルに保存することができます。また携帯を使う人が送ってきます。普通この人はテストです。
3.appがログ保存ツールに接続されていない場合、data/anr/ディレクトリの下ですべてのANR異常情報を見ることができます。しかし、スパーミッションが必要です。そうでないとアクセスできません。
APP性能体験最適化
1.素材は圧縮したものを使う必要があります。パンダのPNG圧縮をおすすめします。
2.資源はコードで描くことができます。静的な資源を使わないでください。
3.複雑なレイアウトでは、例えば多くのアプリのトップページに異なるタイプのアイテムをロードする必要があります。RecyclerViewの多種類のローディングを使って、データを更新する時は必ず単独でitemを使ってapiを更新します。notifyiteme changed（）の方法は絶対に使わないでください。ここでは二つのパラメータのnotifyItem Changd（1，gfg）の方法を使います。
4.データを怠けて読み込むか、または並べて読み込む
5.混淆はカバンを小さくすることができます。（xml資源classなど）
6.あまり遊んでいない場合は、できるだけ静的な引用を書かないようにしてください。匿名内部類のようなメモリ漏れの原因となるもの。自分のミスを心配して書いたら、必ず分析して、彼らを取り出してください。
7.Activityの階層はあまり深くしないでください。深すぎると、低メモリデバイス上でスタックの底に回収されます。
アドバイスとテクニック
1.どこかのコードが多重的にパッケージ化されていることを発見したり、改良された方がいいと思います。泥だらけになるとますますぼろぼろになります。後で直す＝永遠に不可能です。
2.debugコンパイルの間に使われないabiをフィルタしてもいいです。配置を加速させます。
3.できるだけ新しいsupport library依存を維持します。高いバージョンの中でいくつかのバグを修正しました。
4.サードパーティパッケージにアクセスする時は、自分のモジュールと独立して、いつでもデカップリングし、気軽に多重することが望ましい。
第三者パケットにアクセスする時は、自分のモジュールと独立して、いつでも結合して、自由に多重するようにしたほうがいいです。多くの人が理解していないかもしれません。例を挙げると、imgloaderをfrescoに置き換える必要があるなら、前に独立して自分の方法を出すと簡単です。
5.複数のnativeライブラリに依存する場合、いくつかのabiでサポートされていないことが発見されると、最小のabiを維持する必要があります。そうでないと、いくつかの機種に優先的に読み取ります。より適切なアーキテクチャです。壊滅的な崩壊をもたらす。例えば、ARMフォルダの中に二つのsoが含まれています。ARMv 8の中に一つだけあります。その時、携帯は優先的にARMV 8をロードした場合、SOライブラリの崩壊異常をもたらす。
6.第三者依存ライブラリを勝手に導入しないでください。ごく一部の機能を使っているだけなら、自分でカプセル化することを勧めます。
7.第三者のプライベートアプリを含めて暴露する場合は、反射で実現してください。もちろん、これらのすべては私達が彼らのsdkソースを翻訳して読むことができます。紛らわしいかもしれません。この時はダイナミックデバッグを使ってフォローします。
8.公式のsupportバッグは第三者よりずっといい場合が多いです。ただ私たちは知らないか、あるいはよく知らないです。
9.グラデーション、純色図、一本の線を持つ図はshapeを使います。静止図は不要です。血事件が起こる！
10.検索で問題を解決できない時、ソースを読むのは一番早い解決策です。当てたり試したりしないでください。縁あってコードを書いて問題を解決します。
11.パッケージコントロールの場合、リソースの種類を確認することに注意する
例えば、Image.setImageResource（img）
ここのimgは検査を強くして、タイプの検査をして、他の人が使う時誤って書き間違えたことを防止します。私たちが自発的に異常を投げないといけないからです。LayoutInflaterで反射によってxmlを解析する時に提示したエラーログはとても醜いです。普通はまたたくさんの呼び出しスタックとフラッシュバックが伴います。
12.コールドスタート最適化、Application起動時に過多なタスクをしない＆最初のActivityでも同じです。初期化したホワイトスクリーンWindowを一枚の写真にして移行したほうがいいです。
プロジェクトの業務コードが始まる前に、これらの問題を解決したほうがいいです。それらは:
機種が合う
特定の機種に問題がある場合は、焦らないでください。私たちは次の方法を試してもいいです。
崩壊を検査して退却します。
1.アプリがデバッグ中にフラッシュバックが発生した場合、ログcatの下でログが新しくなったプロセスによって消去されます。この時にフィルタをNo filterに選択してログレベルをerrorに選択してください。前回の崩壊のログが表示されます。
2.携帯は私達のそばにないという状況があります。私達もデバッグツールを使うことができません。この場合、いくつかの第三者のログ記録ツールにアクセスすることができます。開発状態では、友盟360などのsdkは推奨されていません。私たちのアプリはネットに接続できないので、崩壊してしまいます。ログをローカルファイルに保存することができます。また携帯を使う人が送ってきます。普通この人はテストです。
3.appがログ保存ツールに接続されていない場合、data/anr/ディレクトリの下ですべてのANR異常情報を見ることができます。しかし、スパーミッションが必要です。そうでないとアクセスできません。
APP性能体験最適化
1.素材は圧縮したものを使う必要があります。パンダのPNG圧縮をおすすめします。
2.資源はコードで描くことができます。静的な資源を使わないでください。
3.複雑なレイアウトでは、例えば多くのアプリのトップページに異なるタイプのアイテムをロードする必要があります。RecyclerViewの多種類のローディングを使って、データを更新する時は必ず単独でitemを使ってapiを更新します。notifyiteme changed（）の方法は絶対に使わないでください。ここでは二つのパラメータのnotifyItem Changd（1，gfg）の方法を使います。
4.データを怠けて読み込むか、または並べて読み込む
5.混淆はカバンを小さくすることができます。（xml資源classなど）
6.あまり遊んでいない場合は、できるだけ静的な引用を書かないようにしてください。匿名内部類のようなメモリ漏れの原因となるもの。自分のミスを心配して書いたら、必ず分析して、彼らを取り出してください。
7.Activityの階層はあまり深くしないでください。深すぎると、低メモリデバイス上でスタックの底に回収されます。
アドバイスとテクニック
1.どこかのコードが多重的にパッケージ化されていることを発見したり、改良された方がいいと思います。泥だらけになるとますますぼろぼろになります。後で直す＝永遠に不可能です。
2.debugコンパイルの間に使われないabiをフィルタしてもいいです。配置を加速させます。
3.できるだけ新しいsupport library依存を維持します。高いバージョンの中でいくつかのバグを修正しました。
4.サードパーティパッケージにアクセスする時は、自分のモジュールと独立して、いつでもデカップリングし、気軽に多重することが望ましい。
第三者パケットにアクセスする時は、自分のモジュールと独立して、いつでも結合して、自由に多重するようにしたほうがいいです。多くの人が理解していないかもしれません。例を挙げると、imgloaderをfrescoに置き換える必要があるなら、前に独立して自分の方法を出すと簡単です。
5.複数のnativeライブラリに依存する場合、いくつかのabiでサポートされていないことが発見されると、最小のabiを維持する必要があります。そうでないと、いくつかの機種に優先的に読み取ります。より適切なアーキテクチャです。壊滅的な崩壊をもたらす。例えば、ARMフォルダの中に二つのsoが含まれています。ARMv 8の中に一つだけあります。その時、携帯は優先的にARMV 8をロードした場合、SOライブラリの崩壊異常をもたらす。
6.第三者依存ライブラリを勝手に導入しないでください。ごく一部の機能を使っているだけなら、自分でカプセル化することを勧めます。
7.第三者のプライベートアプリを含めて暴露する場合は、反射で実現してください。もちろん、これらのすべては私達が彼らのsdkソースを翻訳して読むことができます。紛らわしいかもしれません。この時はダイナミックデバッグを使ってフォローします。
8.公式のsupportバッグは第三者よりずっといい場合が多いです。ただ私たちは知らないか、あるいはよく知らないです。
9.グラデーション、純色図、一本の線を持つ図はshapeを使います。静止図は不要です。血事件が起こる！
10.検索で問題を解決できない時、ソースを読むのは一番早い解決策です。当てたり試したりしないでください。縁あってコードを書いて問題を解決します。
11.パッケージコントロールの場合、リソースの種類を確認することに注意する
例えば、Image.setImageResource（img）
ここのimgは検査を強くして、タイプの検査をして、他の人が使う時誤って書き間違えたことを防止します。私たちが自発的に異常を投げないといけないからです。LayoutInflaterで反射によってxmlを解析する時に提示したエラーログはとても醜いです。普通はまたたくさんの呼び出しスタックとフラッシュバックが伴います。
12.コールドスタート最適化、Application起動時に過多なタスクをしない＆最初のActivityでも同じです。初期化したホワイトスクリーンWindowを一枚の写真にして移行したほうがいいです。