Android開発における問題点と対応する解決(継続更新)
5223 ワード
最近ブログを書くことが少なくなったので、これからもよく更新しなければなりません.
------------------------------------------------------------
1.特定のビジネスニーズのtry cath異常では、catchの可能なRuntimeExceptionが必要です.そうしないと、catchの不全による予期せぬ問題(appクラッシュなど)が発生する可能性があります.
この問題を第一に選んだのは、この間、プロジェクトでこのような状況が発生し、このような状況は注意したり忘れたりしやすいが、その間違いは致命的だからだ.
Java/Android開発では、1つの関数を呼び出すと、この関数はAタイプの異常を投げ出し、自然に呼び出す場所でtry.catchこの異常、そしてほとんどの場合、キャプチャ異常はEclispeによって自動的に提示されて生成され、関数がA異常を投げ出すと呼び出される場所catch Aは、実際にはcatch Aの後にcatch(Exception ex){}を追加しなければならない.原因は、特定の不確定な問題が発生して放出される可能性のある他の異常タイプ(実際には特定のRuntimeException異常/unchecked異常であり、符号化時にcatch RuntimeExceptionは推奨されなかったが、モバイル開発の特定のビジネスシーンに加えてキャプチャすることでAppの予期せぬクラッシュを効果的に防止できる)を防止することにある.
前回、プッシュメッセージ受信時にnew JSONObject()と遭遇すると、当然ながらJSONExceptionのみがcatchとなり、それ以上のcatch Exceptionはないが、実際にはサービス側からのデータフォーマットの誤りによりjavaが投げ出す.lang.Number FormatExceptionでは、コードを一歩一歩追跡したところ、catchに届かず、ソースコードにこの異常が投げ出される可能性があることが判明し、appがクラッシュすることになります.これからはご用心!
2.soファイルディレクトリによるUnsatisfiedLinkError:...:findLibrary returned nullの問題.
Android開発では、外部soファイルを参照することが避けられない場合があり、1つのプロジェクトで複数の異なる外部soファイルを参照する必要がある場合があります.異なる導入ライブラリ内のsoファイルのディレクトリが異なる可能性があるため、パッケージ化後に生成されるプロジェクトlibディレクトリのディレクトリ構造は異なる外部soファイルディレクトリの集合である.armabi/armeabi-v 7 a/x 86/mipsなどが発生する可能性がありますが、一般的にarmabiはあるはずですが、この3つのディレクトリのファイルが異なる場合、特定の機種でこのようなエラーが発生する可能性があります.なぜなら、異なる機種のCPU構造が異なるため、異なるディレクトリの下のパケットを検索するが、外部ライブラリの異なるsoファイルディレクトリにはarmabiの下にa、b soファイルがある可能性があり、x 86の下にはaしか含まれていない可能性があるため、解決策は以下の通りである.
他のディレクトリ(armabi-v 7 a/mips/x 86など)を直接削除し、armabiディレクトリのみを保持し、x 86ディレクトリが存在しない場合、対応する機種も自然にarmabiディレクトリの下で対応するsoファイルを検索します.
3.Can't create handler inside thread that has not called Looper.prepare.
この問題は、Androidの非UIスレッドがUIを修正する操作を行うことができないため、実際には古典的である(もちろん、厳密にはSurface ViewとTextureViewを除く)、一般的にはサブスレッドでToast.makeTextなどの操作.一般に、サブスレッドおよびプライマリスレッドメッセージ通信メカニズムによって解決される.
一般的な解決策は次のとおりです.
1).Handler-Message方式;
2).Handler-postDelay方式;
3).activity.runOnUIThread(runnable)方式など.
4.RadioGroupのRadioButton check()メソッド呼び出しによるonCheckedChanged()マルチコールバック問題.
RadioGroup-RadioButtonは、複数のオプションのうち1つだけを選択する場合に適しており、デフォルトのスタイルを変更することで、ナビゲーションメニューのタブなどのニーズに便利です.setOnCheckedChangeListener()は、内部のラジオボタンcheck状態の変更に便利で実用的なコールバックを提供します.符号化ではradioGroupと直接書く.パラメータがRadioButtonのidであるcheck(xxx)は、onCheckedChanged()が複数回実行されていることをよく発見します.ソースコードを見ると、チェック()メソッドが実行されると、RadioGroupはラジオの前後の異なる状態をコールバックしていることがわかります.実際の論理では、現在選択されているラジオボタンだけをコールバックするのが一般的です.
以下のように解決することができる:radioButton.setChecked(true);ここで、radioButtonは現在選択されているradioGroupです.
5.Notificationパラメータオーバーライドの問題
Appでは、複数のNotificationが表示されている場合、notification IDは現在のApp内のNotification IDとして使用され、異なるNotification idは、このアプリケーション内の複数の異なるNotificationを通知バーに同時に表示できることを示す.ユーザが個々のNotificationをクリックすると、このNotificationで設定されたpendingIntentがユーザのクリック操作に応答し、pendingIntentを設定する際には、特にパラメータのパラメータ伝達の問題に注意する必要がある.
複数の通知がある場合、後の通知をクリックして取得したパラメータ値が最初の通知のパラメータ値である場合、pendingIntentのflagsパラメータが正しく設定されていません.普通はPendingIntentに設定すべきです.FLAG_UPDATE_CURRENTは、このパラメータを設定すると逆になり、前の通知で取得したパラメータ値が最後の通知伝達のパラメータ値になった場合、requestCodeパラメータが正しく設定されていないためです.requestCodeパラメータをNotification idと同じ値に設定すればよい.
6.AndroidManifestから.xmlでchannelを取得中にエラーメッセージが表示されました:Key xx expected String but value was a java.lang.Integer. The default value was reurned.
AndroidManifestについてxmlでchannel名を構成すると、数値文字列を直接使用すると、上記のように取得したchannel値がnullになります.
以下のように修正します.
あるいは、チャネル名として直接数値文字列を使用することは推奨されません.
------------------------------------------------------------
1.特定のビジネスニーズのtry cath異常では、catchの可能なRuntimeExceptionが必要です.そうしないと、catchの不全による予期せぬ問題(appクラッシュなど)が発生する可能性があります.
この問題を第一に選んだのは、この間、プロジェクトでこのような状況が発生し、このような状況は注意したり忘れたりしやすいが、その間違いは致命的だからだ.
Java/Android開発では、1つの関数を呼び出すと、この関数はAタイプの異常を投げ出し、自然に呼び出す場所でtry.catchこの異常、そしてほとんどの場合、キャプチャ異常はEclispeによって自動的に提示されて生成され、関数がA異常を投げ出すと呼び出される場所catch Aは、実際にはcatch Aの後にcatch(Exception ex){}を追加しなければならない.原因は、特定の不確定な問題が発生して放出される可能性のある他の異常タイプ(実際には特定のRuntimeException異常/unchecked異常であり、符号化時にcatch RuntimeExceptionは推奨されなかったが、モバイル開発の特定のビジネスシーンに加えてキャプチャすることでAppの予期せぬクラッシュを効果的に防止できる)を防止することにある.
前回、プッシュメッセージ受信時にnew JSONObject()と遭遇すると、当然ながらJSONExceptionのみがcatchとなり、それ以上のcatch Exceptionはないが、実際にはサービス側からのデータフォーマットの誤りによりjavaが投げ出す.lang.Number FormatExceptionでは、コードを一歩一歩追跡したところ、catchに届かず、ソースコードにこの異常が投げ出される可能性があることが判明し、appがクラッシュすることになります.これからはご用心!
2.soファイルディレクトリによるUnsatisfiedLinkError:...:findLibrary returned nullの問題.
Android開発では、外部soファイルを参照することが避けられない場合があり、1つのプロジェクトで複数の異なる外部soファイルを参照する必要がある場合があります.異なる導入ライブラリ内のsoファイルのディレクトリが異なる可能性があるため、パッケージ化後に生成されるプロジェクトlibディレクトリのディレクトリ構造は異なる外部soファイルディレクトリの集合である.armabi/armeabi-v 7 a/x 86/mipsなどが発生する可能性がありますが、一般的にarmabiはあるはずですが、この3つのディレクトリのファイルが異なる場合、特定の機種でこのようなエラーが発生する可能性があります.なぜなら、異なる機種のCPU構造が異なるため、異なるディレクトリの下のパケットを検索するが、外部ライブラリの異なるsoファイルディレクトリにはarmabiの下にa、b soファイルがある可能性があり、x 86の下にはaしか含まれていない可能性があるため、解決策は以下の通りである.
他のディレクトリ(armabi-v 7 a/mips/x 86など)を直接削除し、armabiディレクトリのみを保持し、x 86ディレクトリが存在しない場合、対応する機種も自然にarmabiディレクトリの下で対応するsoファイルを検索します.
3.Can't create handler inside thread that has not called Looper.prepare.
この問題は、Androidの非UIスレッドがUIを修正する操作を行うことができないため、実際には古典的である(もちろん、厳密にはSurface ViewとTextureViewを除く)、一般的にはサブスレッドでToast.makeTextなどの操作.一般に、サブスレッドおよびプライマリスレッドメッセージ通信メカニズムによって解決される.
一般的な解決策は次のとおりです.
1).Handler-Message方式;
2).Handler-postDelay方式;
3).activity.runOnUIThread(runnable)方式など.
4.RadioGroupのRadioButton check()メソッド呼び出しによるonCheckedChanged()マルチコールバック問題.
RadioGroup-RadioButtonは、複数のオプションのうち1つだけを選択する場合に適しており、デフォルトのスタイルを変更することで、ナビゲーションメニューのタブなどのニーズに便利です.setOnCheckedChangeListener()は、内部のラジオボタンcheck状態の変更に便利で実用的なコールバックを提供します.符号化ではradioGroupと直接書く.パラメータがRadioButtonのidであるcheck(xxx)は、onCheckedChanged()が複数回実行されていることをよく発見します.ソースコードを見ると、チェック()メソッドが実行されると、RadioGroupはラジオの前後の異なる状態をコールバックしていることがわかります.実際の論理では、現在選択されているラジオボタンだけをコールバックするのが一般的です.
以下のように解決することができる:radioButton.setChecked(true);ここで、radioButtonは現在選択されているradioGroupです.
5.Notificationパラメータオーバーライドの問題
Appでは、複数のNotificationが表示されている場合、notification IDは現在のApp内のNotification IDとして使用され、異なるNotification idは、このアプリケーション内の複数の異なるNotificationを通知バーに同時に表示できることを示す.ユーザが個々のNotificationをクリックすると、このNotificationで設定されたpendingIntentがユーザのクリック操作に応答し、pendingIntentを設定する際には、特にパラメータのパラメータ伝達の問題に注意する必要がある.
複数の通知がある場合、後の通知をクリックして取得したパラメータ値が最初の通知のパラメータ値である場合、pendingIntentのflagsパラメータが正しく設定されていません.普通はPendingIntentに設定すべきです.FLAG_UPDATE_CURRENTは、このパラメータを設定すると逆になり、前の通知で取得したパラメータ値が最後の通知伝達のパラメータ値になった場合、requestCodeパラメータが正しく設定されていないためです.requestCodeパラメータをNotification idと同じ値に設定すればよい.
6.AndroidManifestから.xmlでchannelを取得中にエラーメッセージが表示されました:Key xx expected String but value was a java.lang.Integer. The default value
AndroidManifestについてxmlでchannel名を構成すると、数値文字列を直接使用すると、上記のように取得したchannel値がnullになります.
以下のように修正します.
1 public String getChannel() { 2 String channel = null; 3 try { 4 ApplicationInfo ai = getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA); 5 channel = ai.metaData.getString("UMENG_CHANNEL"); 6 if (channel == null) { 7 channel = String.valueOf(ai.metaData.getInt("UMENG_CHANNEL")); 8 } 9 } catch (NameNotFoundException e) { 10 e.printStackTrace(); 11 } 12
13 return channel; 14 }あるいは、チャネル名として直接数値文字列を使用することは推奨されません.