Androidの保存方法

SharedPrefence、単純な構成データおよびその他の
SQLiteの保存、複雑なリレーショナルデータの保存
ファイル、通常はログファイル、ローカルファイルキャッシュ、protobuf、7z
ContentProviderの保存、クロスプロセスデータアクセス、通常はSQLiteと組み合わせて使用、他のアプリプロセスへのデータの提供使用する。
ネットワークストレージ、ネットワークストレージにはシリアル化/逆シリアル化が含まれます（protobuf、xml、json）

SharedPrefence

SharedPrefenceのコミットと適用

applyには戻り値がなく、commitは変更が正常に送信されたかどうかを示すブール値を返します。
コミットとは、コンテンツを同期的にハードディスクに送信し、applyはすぐにメモリに変更を送信し、非同期スレッドを開いてハードディスクに送信します。送信が失敗した場合、通知は届きません。
すべてのコミット送信は同期プロセスであり、非同期送信を適用するよりも効率が遅くなります。送信結果の成功を気にしない場合は、適用方法をお勧めします。
適用は非同期スレッドを使用してディスクに書き込むことであり、コミットは同期的にディスクに書き込むことです。したがって、メインスレッドでcommitを使用する場合、ANRの問題が発生するかどうかを考慮する必要があります。（大規模なデータストレージには適していません）

マルチプロセスの問題-> mmkv

SQLite

SQLiteStatement
は、トランザクションを
使用し、インデックス、
非同期スレッドを使用し、統合管理のためにデータベースを書き込みます

インターネット

シリアル化
デシリアライズ

xml
json
protobufプラットフォームに依存しない
7z圧縮（ジョブ）

protobuf

すでにxml / jsonがありますが、なぜprotobufを使用するのですか

xml、json、protobufの利点と比較して：

簡潔：XMLには多くの解析コードが必要ですが、protobufは自動的にコードを生成します
小さいサイズ：メッセージサイズはxmlの1 / 10-1 / 3のみです
高速：解析速度はxmlより20〜100倍高速です
Protobufコンパイルシステムを使用する：プログラミングで使いやすいデータアクセスコードを生成できます
互換性を高めるために、プロトコルバッファ設計の原則は、下向きまたは上向きの互換性をサポートできるようにすることです。

短所：
1。バイナリ形式では読みやすさが低下します。
パフォーマンスを向上させるために、protobufはエンコードにバイナリ形式を使用します。これは、読みやすさの低下に直接つながります。これは、開発とテストの効率に直接影響します。もちろん、通常の状況では、protobufは非常に信頼性が高く、大きな問題を引き起こすことはありません。
2.自己記述の欠如
一般的に言えば、XMLは自己記述的ですが、protobuf形式はそうではありません。プロトコルコンテンツのバイナリ形式を提供します。作成した構造と一致しない場合は機能しません。

プロジェクトでprotobufを使用する

コマンドラインでprotobufを使用するには、コマンド
を使用してprotobufファイル（protobufファイルのサフィックスは.proto）をjavaファイルにコンパイルする場合は、protobufツールをインストールしてから、protocコマンドを使用してコンパイルする必要があります。

Androidスタジオプロジェクトでのprotobufの使用
1）まず、protobufツールプラグインをグローバルbuid.gradleファイルに追加する必要があります。

クラスパス 'com.google.protobuf：protobuf-gradle-plugin：0.8.10'

2）次に、app /buid.gradleファイルで次のようにします。

①このプラグインを追加

    apply plugin: 'com.google.protobuf'

②依存関係を追加する

     implementation 'com.google.protobuf:protobuf-java:3.7.1'

③protobuf構成を追加

protobuf {
    
    
    //配置protoc编译器
    protoc {
    
    
        artifact = 'com.google.protobuf:protoc:3.7.1'
    }
    //这里配置生成目录，编译后会在build的目录下生成对应的java文件
   generateProtoTasks {
    
    
        all().each {
    
     task ->
           task.builtins {
    
    
                remove java
           }
           task.builtins {
    
    
                java {
    
    }
           }
        }
    }
}

④protobufファイルのディレクトリを追加します（android {}）

sourceSets {
    
    
      main {
    
    
          proto {
    
    
              srcDir 'src/main/java/com/protobufdir'
          }
      }
}

3）src / main / java / com / protobufdirディレクトリに新しいprotobufbean.protoファイルを作成し、次のコードを追加します。

syntax = "proto3";
package com.example.protobufdemo;//包名


option java_package = "com.example.protobuf02";
option  java_outer_classname = "Person";
option csharp_namespace = "android";
message _Person{
    
    

    string name = 1;
    int32 id = 2;
    string email = 3;

    enum _PhoneType{
    
    
        MOBILE = 0;
        HOME = 1;
        WORK = 2;
    }

    message _PhoneNumber{
    
    
        string number =1;
        _PhoneType type = 2;
    }

    repeated _PhoneNumber phone = 4;//数组


}

4）プロジェクトを再構築します。ASビルドプロジェクトでは、.protoファイルがjavaファイルに生成されます。
これらの生成されたjavaファイルは、\ app \ build \ generate \ source \ proto \ debug \ java \ディレクトリにあります。
これらの生成されたjavaファイルは、プロジェクトに直接配置できるシリアル化および逆シリアル化APIをカプセル化します。呼び戻す。

言語仕様

メッセージ定義

メッセージの名前を決定し、メッセージに意味のある名前を付けます。
フィールドのタイプを指定します
フィールドの番号を定義します。プロトコルバッファでは、フィールドの番号は非常に重要です。フィールド名は、参照およびコード生成専用です。フィールドの番号範囲（19000〜19999）はプロトコルバッファーによって予約されていることに注意してください。

フィールドの制約

requiredは、フィールドに値を割り当てる必要があり、空であってはならないことを指定します（この制約はv3で削除されます）。
オプションの指定フィールドはオプションであり、空にすることもできます。オプションのフィールドの場合、[default]を使用してデフォルト値を指定することもできます。指定しない場合、フィールドタイプのデフォルト値が使用されます。
繰り返し使用して、フィールドをコレクションとして指定します

フィールドタイプ

プロトファイルには複数のメッセージタイプを同時に定義できます。コードを生成する場合、生成するコードの対象言語によって処理方法が異なります。たとえば、Javaはメッセージタイプごとに.javaファイルを生成します。
フィールドのタイプを他のメッセージタイプとして指定できます
importキーワードを使用して、他のprotoファイルをインポートします
protoファイル内のメッセージのタイプもネストできます
protoファイルでは、extensionsキーワードを使用して、後でサードパーティに拡張するときに使用するためにフィールド番号の一部を予約できます。
oneofキーワードはフィールドのセットを指定し、少なくとも1つのフィールドに値を割り当てる必要があります

フィールドタイプを定義するときに使用できるように、プロトコルバッファには多くのスカラータイプが用意されています。
ここに写真の説明を挿入

エンコーディングプロトコル

ベース128可変長エンコーディング

いわゆる可変長エンコーディングは、固定長エンコーディングの反対です。固定長エンコーディングは、固定バイト数で表されます。たとえば、int32タイプ番号は4バイトを使用して固定されますが、可変長エンコーディングは、数バイトを使用するために数バイトを必要とします。たとえば、int32タイプの番号1の場合、1バイトだけで十分です。Base-128可変長エンコーディングには2つの原則があります
各バイトは、最後のバイトを除いて、番号を表すために下位7ビットを使用し、他のバイトの最上位ビットは1に設定されます。
リトルエンディアンのバイトオーダーを使用する
tag-length-valuetag-length-value

ここに写真の説明を挿入

ネガティブエンコーディング処理

ZigZagエンコーディングを採用する
(n <<1)^(n>>31)或者(n<<1)^(n>>63)

ビッグエンディアンシーケンス
最初に高次を書き込み、次にローエンドシーケンスを書き込み低
次を
最初に書き込み、次に高次を書き込みます

プロトコルバッファシリアル化プロトコルとアプリケーション
 [Protobuf] Protobufのコーディングとデコードのルールの詳細

Androidのパフォーマンスの最適化-ストレージの最適化