ネタバレの下に自分の推論の説明を掲載します。
UI
まず、ビジュアルコンストラクターを使用しないでください。 決して。 例外は、Androidのxmlマークアップの基本を知らない完全に初心者の開発者であり、その後、手動でマークアップを実行し、すべてのゴミをクリーンアップすることを条件とします。
ネタバレ
問題は、ビジュアルコンストラクターがAndroidではなく、そこに表示されるビューがアプリケーション全体ではないため、正しく設定しようとすると、コンストラクターが中央揃えの代わりにインデント、FrameLayoutの代わりにLinearLayout、または過剰なネストを使用できることです。 このようなレイアウトに出くわしたら（わかりやすくするために属性を減らします）、これを実行しないでください。
そして、下に2枚の絵だけを描く必要がありました。
<RelativeLayout> <LinearLayout android:orientation=”vertical” > <LinearLayout android:orientation=”horizontal” > <FrameLayout> <!—- --> </FrameLayout> </LinearLayout> <LinearLayout android:orientation=”horizontal” > <FrameLayout> <!—- --> </FrameLayout> </LinearLayout> </LinearLayout> </RelativeLayout>
そして、下に2枚の絵だけを描く必要がありました。
第二に、RelativeLayoutはどこにも使用しないでください。 ビューを整理する場合、LinearLayoutがサービスにあります。 すべてのビューが厳密に配置されている場合、いつでもFrameLayoutに頼ることができます。
ネタバレ
私はほとんどどこでも会いますが、何らかの理由で、異なるタイプのビューが異なる時間にロードされることを誰もが理解しているわけではありません。 RelativeLayoutは最も長く、最も長く、FrameLayoutは（子ビューを含むことができる要素の）最も軽いものの1つです。 そして、これがActivityルート要素に影響を与えない場合、リストの顕著な減速になります。
PSこれはRelativeLayoutを放棄するための呼び出しではありません。場合によっては、それなしでは方法がありません。 しかし、一部でのみ。 まったくない！
PSこれはRelativeLayoutを放棄するための呼び出しではありません。場合によっては、それなしでは方法がありません。 しかし、一部でのみ。 まったくない！
第三に。 マージンまたはパディング？ 便利なクリック可能な要素を作成する場合は、パディングが唯一の要素です！ 非アクティブな要素が持つインデントが必要な場合は、マージンが許可されます。
ネタバレ
真実は簡単です。 要素が大きいほど、押すのが便利です。 マージン-要素自体の場所、パディング-環境の場所。 さらに、画像でさえインデントがあり、すべての解像度で厳密に示され、 文書化されています。 これらのルールを順守してください。これらのルールは、あなたとあなたのユーザーの生活を大いに促進します。
4番目。 xmlはJavaで記述する部分と同じコードであることを忘れないでください。 したがって、XMLマークアップの重複が最小限に抑えられていることを確認してください。可能であれば、複数の場所で使用する場合は独自のコントロールを作成してください（複数でない場合は、個別に作成することをお勧めします）。
ネタバレ
このアドバイスは、遅かれ早かれ、アプリケーションのさまざまなコントロールの動作や表示を変更する必要があるため、ユーザーではなく開発者の利益になる可能性が高くなります。 それらがすべて1つの場所にあり、きちんと並べ替えられていると、簡単になります。
データベース
Androidで最も一般的なデータベースであるSQLiteに関しては、1つのポイントのみがあります。 彼女は遅いです。 とても。 最適化と非同期操作を無視しないでください。
ネタバレ
この事実は、小さなまたは静的なデータセットを持つプロジェクトでは顕著ではありませんが、アプリケーションが大量のデータの継続的な同期を必要とする場合（たとえば、大規模な倉庫のオフラインクライアント）、アプリケーションの同時更新と操作は困難または不可能になる場合があります。 これは、SQLiteの1つの単純な機能によるものです。データベースから読み取るか、まったく書き込まないかのいずれかです（ダーティリーディングなどは考慮しません。非常に必要な場合を除き、初心者が使用しない方がよいためです）。
テスト中
良いアプリケーションがテスト済みのアプリケーションであることは秘密ではありません。 したがって、複雑で単体テスト、別の開発者によるコードレビューなどを無視しないでください。 内気なことは何もありません。優れたプログラマーは間違いを犯さない人ではなく、間違いを見つけて将来的にそれを考慮に入れる人です。
ヒントについて言えば、アプリケーションの内部デバイスだけでなく、すべてのインターフェイス（たとえば、ネットワークを操作するためのアダプター、別のアプリケーション、データベースを操作するためのアダプター）にインターフェースを使用することをお勧めします。 次に、自分自身をテストするときに、ありがとうと言います。
ネタバレ
全体のポイントは、ユニットテストを使用すると、特定の要求に対して何がもたらされるかを確実に把握できれば、テストを書くのがはるかに簡単になるということです。 外部ソースを使用する場合（100％使用可能であっても）、前のテストでそれらのデータセットをいつでも破壊できます。 インターフェイスを使用する場合、テストで必要なものを返すスタブクラスを簡単に作成できます。
ローカリゼーションとリソース
ハードコードされた文字列を使用しないでください。 リソース（R.string.your_string）を使用します。 たとえ複数の言語をサポートしていなくてもサポートすることはありません。
ネタバレ
まず、あなたの行が別のファイルにアップロードされると-あなたと彼らが正しい書き方をチェックする人の両方にとって-それらで作業するのがはるかに簡単です（はい、数千行のコードを書いた後、ネイティブ言語忘れられるようになり、陳腐なタイプミスを忘れてはならない。
第二に、複数のアプリケーション言語のサポートは決してないと考えても、あなたは間違っています。 プロジェクトに少なくとも何か価値がある場合は、少なくとも英語に翻訳することは理にかなっています。 この場合、ハードコードされた文字列を引き出すことは非常に困難です。
第二に、複数のアプリケーション言語のサポートは決してないと考えても、あなたは間違っています。 プロジェクトに少なくとも何か価値がある場合は、少なくとも英語に翻訳することは理にかなっています。 この場合、ハードコードされた文字列を引き出すことは非常に困難です。
言語、画面解像度、向き、サイズ、国など、さまざまなリソースのグループが存在することに注意してください。これのかなりの部分を占める必要はないかもしれませんが、それらに慣れる必要があります。 将来的には、異なるデバイスでの要素のレンダリング/配置に問題があるため、これにより多くの時間を節約できます。