1.パフォーマンスの最適化（1）APP起動の最適化-https
：//juejin.im/post/5cc19374e51d456e781f2036-アプリケーションの最適化スキーム：
子スレッドを開き、スレッドにハンドラーを作成せず、UIを操作せず、非同期
レイジーロードの高い要件はありません、ネットワーク、データベース、画像ライブラリ、または一部のサードパーティライブラリなど、使用時に初期化します。
IntentService onHandleIntent（）メソッドを使用して、時間のかかる操作を初期
化し、FlashActivityを最適化します。
2.パフォーマンスの最適化（2）UIレンダリングの最適化-https：//juejin.im/post/5cc2dfc7e51d456e845b4260 CPU
を完了し、
xmlをオブジェクトに変換する時間を短縮するための16msレンダリングの要件を満たすために、これら2つのものの消費時間を削減する方法。2. GPUは、繰り返し描画する時間を短縮します。
3.パフォーマンスの最適化（3）APPメモリの異常な問題
-https：//juejin.im/post/5cd82a3ee51d456e781f20ce一般的なメモリ分析ツール：top / procrank; meinfo; Procstats; DDMS; MAT; Finder-Activity; LeakCanary; LeakInspector;
メモリリーク、理由：寿命の長いオブジェクトは、寿命の短いオブジェクトへの参照を保持します。素人の用語では、リサイクルする必要があるオブジェクトです。参照の問題はリサイクルされないため、最終的にOOMが発生します。
JAVA GCはどのようにメモリ再利用を決定しますか？
現在、仮想マシンは基本的に到達可能性分析アルゴリズムを使用していますが、参照カウントアルゴリズムを使用してみませんか？すべてのオブジェクトの参照カウントをカウントする場合の参照カウント方法について説明し、到達可能性分析アルゴリズムが参照カウントアルゴリズムの欠陥をどのように解決するかを比較してみましょう。
参照カウントアルゴリズム：各オブジェクトには参照カウンターがあります。オブジェクトが1回参照されると、カウンターが1つ増え、オブジェクト参照が1回無効になると、カウンターが1つ減ります。カウンターが0の場合、ゴミを意味し、GCでリサイクルできます。 。
GC Rootsから検索を開始すると、接続されたグラフ全体のオブジェクトのエッジがすべて生きているオブジェクトになります。GCRootsが到達できないオブジェクトは、ガベージコレクションオブジェクトになり、GCによっていつでも収集できます。
GCルートのオブジェクトとして使用できます：実行中の仮想マシンスタックによって使用される参照、静的プロパティ定数、JNIによって参照されるオブジェクト。
オブジェクトに強い参照がある場合、ガベージコレクターはそれを再利用しません。メモリスペースが不足している場合、Java仮想マシンはプログラムをクラッシュさせるためにOOMエラーをスローし、メモリを解決するために強い参照を持つオブジェクトをリサイクルしません。不十分な問題。強く参照されているオブジェクトが使用されなくなった場合は、GCがオブジェクトをリサイクルできるように、オブジェクトを弱める必要があります。
Java参照タイプ：強い参照;ソフト参照;弱い参照;ファントム参照。
メモリジッター：頻繁なメモリの割り当てと回復（割り当て速度が回復速度よりも速い場合）は、最終的にOOMを生成します。
4.パフォーマンスの最適化（4）ubuntuは、WeChat画像圧縮アルゴリズムに匹敵するlibjpeg画像圧縮ライブラリを完全にコンパイルします-https：//juejin.im/post/5ce15d0ce51d45106e5e6dac
iPhoneを使用してWeChat経由で画像を送信する場合、一部の画像は1Mしかないようです。 、しかし、解像度はAndroidフォンの5 Mの画像サイズよりも明確ですが、これはなぜですか？。
当時、GoogleがAndroidを開発していたとき、ほとんどの携帯電話の構成はそれほど高くないと考えられていたため、画像処理にはSkiaが使用されました。もちろん、このライブラリの最下層はまだjpeg画像圧縮処理を使用しています。ただし、ローエンドの携帯電話に適応できるようにするために（ここでのローエンドとは、ハードウェア構成が低い以前の携帯電話を指し、CPUとメモリは携帯電話で非常にタイトであり、パフォーマンスは低下します）、ハフマンアルゴリズムはCPUを集中的に使用し、コーデックを使用するためです。遅く、他のアルゴリズムを使用せざるを得ません。したがって、Skiaは、画像処理の下位バージョンでハフマンアルゴリズムをオンにしませんでした。
では、JEPGとは正確には何ですか？JEPG（フルネームはJoint Photographic Experts Group）は一般的な画像形式ですが、なぜここでJEPGに言及するのですか？これは、C / C ++ライブラリがオープンソースであるためです。最下層は画像圧縮用のハフマンアルゴリズム（libjpeg）に基づいています
。libjpeg-turboは、SIMD命令（MMX、SSE2、AVX2、NEON、AltiVec）を使用するJPEG画像コーデックです。 x86、x86-64、ARM、およびPowerPCシステムでベースラインJPEG圧縮と解凍を高速化し、x86およびx86-64システムでプログレッシブJPEG圧縮を高速化します。
ハフマンアルゴリズムを使用して画像を圧縮します。
JEPGLIB画像圧縮、ハフマンアルゴリズム画像圧縮LIBJPEG_SAMPLE-https://github.com/yangkun19921001/LIBJPEG_SAMPLE
5.パフォーマンスの最適化（5）長い画像の最適化、Weiboの読み込みの長い画像の方法を模倣-https：//juejin.im/post/5ce96da06fb9a07ee4633f50
長い画像の制御の読み込み、反Weiboの読み込み方法-https ：//github.com/yangkun19921001 / long_picture_view
6.パフォーマンスの最適化（6）上司がAPPの消費電力について質問します-https ：//juejin.im/post/5ce9088f6fb9a07ee4633ef3
コードの電力最適化部分-https ：
//github.com/yangkun19921001/batteryGoogleのオープンソース電力分析ツールbattery- historian- https://github.com/google/battery-historian
Battery Historianは、Android 5.0 Lollipop（APIレベル21）以降を実行しているAndroidデバイスのバッテリー関連の情報とイベントをチェックするためのツールであり、デバイスは接続されていません。
7.パフォーマンスの最適化（7）APK強化のDex
暗号化と復号化-https：//juejin.im/post/5cf3ee295188256aa76bb1e1APK強化dex暗号化と復号化-https ：
//github.com/yangkun19921001/DexEncryptionDecryption ClassLoaderは依然として非常に重要で、ホットです修理とホットロードはこの原則に基づいています。
8.パフォーマンスの最適化（8）APK強化アプリケーションの動的置換-https ：//juejin.im/post/5cf69d30f265da1b897abd53
ActivityThread.java
mian（）-> thread.attach（）-> attachApplication（）->送信されたAMSの受信パラメータの後、sendMessage（H.BIND_APPLICATION）->プロセスBIND_APPLICATION-> handleBindApplication（）ここでアプリケーションを準備します->アプリケーションapp = data.info.makeApplication（）-> mInitialApplication = app;
強化プロセスの原則：dex->暗号化->アライメント>署名->パッケージから下請け契約し、APKに圧縮します。
9.パフォーマンスの最適化（9）APPの安定性のホットリペアの原則の調査-https
：
//juejin.im/post/5cfce989f265da1b6c5f6991インストルメンテーションの原則：DexPathListを取得することを反映した場合、findClassがdexElementsをトラバースすることによってクラスを見つけることがソースコードからわかっています。プライベート配列dexElements、この配列の内部順序インデックスを外部で変更し、修復されたdexを[0]の位置に配置します。次に、修復されたdexの使用を優先できますか？明らかに、それは確立されています。
10.パフォーマンスの最適化（10）APP連続操作のプロセスキープアライブ実装-https ： //juejin.im/post/5cffe4d4f265da1b695d55d4
プロセスキープアライブソリューション-https ：//github.com/yangkun19921001/KeepAlive
キープアライブコンポーネント-https ：/ /github.com/fanqieVip/keeplive
は、携帯電話のロック画面のロック解除イベントを監視し、画面がロックされると1ピクセルの透明なアクティビティを開始し、ユーザーがロックを解除するとアクティビティを破棄することで、プロセスの優先度を上げる効果を実現します。
信頼性が高く（アクティビティ+サービスエスカレーション+サービスメカニズムアクティベーション+ JobSchedulerタイミングチェックプロセスが実行されているかどうか+サイレントファイルのバックグラウンド再生+デュアルプロセスガード）、究極のプロセスキープアライブプログラムを構成します。
11.パフォーマンスの最適化（11）ProGuardはコードとリソースを圧縮します-https：
//juejin.im/post/5d05dab06fb9a07ea9446e21 ProGuardとは何ですか？ProGuardは、コードとリソースを圧縮するためのツールとして理解でき、Javaクラスファイルの圧縮、最適化、難読化、および事前検証を提供できます。圧縮ステップは、未使用のクラス、フィールド、メソッド、および属性を検出して削除することです。最適化の手順は、メソッドのバイトコードを分析して最適化することです。難読化の手順は、残りのクラス、フィールド、およびメソッドの名前を短くて意味のない名前に変更することです。圧縮、最適化、および難読化により、コードがより小さく、より効率的になります。
12.パフォーマンスの最適化（12）APKの極端な圧縮-https
：
//juejin.im/post/5d0627f7f265da1bd4247e76最新バージョンのWeChat 6.5.7（イメージセレクターを除く）-https：//github.com/GitLqr/LQRWeChatAndResGuardはいAPKのサイズを縮小するツールであり、その原理はJava Proguardに似ていますが、リソース専用です。これにより、元々長いリソースパスが短縮されます。たとえば、res / drawable / wechatはr / d / aになります。