著者：ビジー魚の技術 - クラウドO
背景
私たちは、アルバムからの基本的なニーズの写真やビデオを取得しているので、アルバムは、トピックの周りに開いていないときの機能を関連画像、動画をやってで。最も直接的な方法は、カスタムUI、複数の選択肢の画像として、いくつかの高度な機能が死ぬことを、満たされている安全なインタフェースの基本的な機能を呼び出すことです。
我々は、それはまた、アルバムを処理するためのシステムのインタフェースを呼び出し、公式image_pickerを調査し、カスタマイズ可能なレベルは高くはないが、我々の要求を満たすことができません。だから我々は、自分自身のアルバムフラッタコンポーネントを開発することを選択しました。
私たちのコンポーネントは、次のような特徴を持っている必要があります。
- アプリ内で画像を完了していない、ビデオを選択し、システム・コンポーネントのアルバムに依存する必要
- 画像の総数は複数選択することができ、指定された選択した画像をサポートしています
- 数の複数の選択肢の選択は、UIを反映する場合。
- あなたは、画像を選択し、ビデオを制御することができます。例えば：ユーザーのみが動画を選択できるように、画像は灰色です。
- 、ズームすることができます写真のプレビュー時間も選択リストに直接追加することができます。
デザインのアイデア
使いやすいAPI、機能が豊富なために高い抵抗性を有する、および柔軟な。フルアクセスコンポーネントを選択することもサービスも、モジュール上のUIをカスタマイズするために選択することができます。
フラッターは、UIプレゼンテーション層、ネイティブプラットフォームによって提供される特定のデータを行います。このモデルは、ネイティブUIコードとデータコードエンジニアリングから隔離されています。私たちは、多くの場合、時間のネイティブコンポーネントの開発にMVCアーキテクチャを使用します。フラッターコンポーネント開発のアイデアは、基本的に似ています。次のように全体的な構造は次のようになります。
側面に見ることができるようにフラッターは、ここでは、一般的なMVCアーキテクチャで、モデルビューは、モデルを再構築するために変更を反映するために変更されますウィジェットビュー、ビューとモデルのバインディングです。ビューイベントは、データを取得し、モデルを更新するために、ネイティブコントローラをトリガします。メソッドチャンネル通信によるネイティブ・フラッター、二つの層の間には強い依存性がありません、単に通信プロトコルが合意することができます押してください。
ネイティブ側の一部、モデル適応、前髪画面、フルスクリーンの識別などを主に担当UIAdapter。許可は、メディア処理アプリケーションが権限を読み書きする責任があります。キャッシュキャッシュは、大きな画像プレビューでの応答時間を改善し、GPUのテクスチャを担当しています。デコーダは、ビットマップを解析するための責任がある、OpenGLはテクスチャーの責任回しビットマップ。
それは注意する必要があります。これは、外部フラッターテクスチャへの依存の実現です。前のアルバムへのJavaヒープメモリ使用量の相対大幅な削減を達成しましたので、アルバム全体を見るために写真のほとんどでは、コンポーネントGPUのテクスチャです。あなたはシステムを殺されるのメモリ、アプリケーションのリスクに起因するローエンドトップアルバムネイティブシステムで機械を使用している場合。この現象は、システムアルバム、アプリの再起動からの復帰です。フラッターアルバムのコンポーネントを使用して、上記経験するローエンドマシンで変更されました。
いくつかの詳細
1ページの読み込み
アルバムリストは、GridViewのコンポーネントがいくつかのコンストラクタを持って舞う、たくさんの写真をロードする必要があるため、比較的容易に間違いが最初で、ウィジェットの大量の提供を要求する最初の関数を使用することです。第二のコンストラクタを選択する必要があり、コールバックIndexedWidgetBuilderウィジェット、遅延読み込みの一種と同等のものを取得する際に、GridViewコントロールがスライドします。
GridView.builder({
...
List<Widget> children = const <Widget>[],
...
})GridView.builder({
...
@required IndexedWidgetBuilder itemBuilder,
int itemCount,
...
})プロセスをスライディング、あなたは資源を回復したいとき、私たちはここにここにある見えない絵グライドは、対応するテクスチャが削除されます。メモリに上昇した後、連続したスライドGridViewコントロールは、常に成長しない、安定になります。経験のメモリが揺るがすよう繰り返し前後に急速なスライドテクスチャの作成と削除は、非常に良いではない場合。
したがって、我々は、ステートマシンの状態の絵を維持なし、ロード、ロードされた、Wait_Dispose、配置されていません。なし荷積から状態にロードされ始めて、ユーザーが見ているこの時間は、データステータスコールバックは、画像アイコンを表示するためにロードされます再ビルドウィジェットツリーこの時間に戻ってくる空白のプレースホルダや図面、ユーザーがあります状態Wait_Disposeに陥るために時間がかかり、この時間はあなたがロードされた状態に戻すと、滑りやすいWait_Disposeから来る場合は、すぐに処分しないで廃棄していきません。ユーザーが戻った状態からスライドしていない場合は配置されているのWait_Disposeを入力します。配置されているの状態を入力するとき、あなたがロード処理を再取る必要があるときは、画像が表示されます。
2アルバムビッグ・ショー：
あなたが特定の画像のGridViewコントロールをクリックすると、この絵は、より明確にユーザーフレンドリーな表示を画像を拡大実施します。私たちは、カメラの画像が非常に高い解像度であることを知っている、完全にロードされた場合には、偉大なメモリのオーバーヘッドになりますので、我々はときデコードビットマップ、およびのみ1080にスケールアップされています。画像を拡大する三つのステップに要約することができます。
- ビットマップファイルのデコードから、1
- 2ビットマップテクスチャに変換し、ビットマップを解放します
- ディスプレイに舞うする3テクスチャ
ステップ1において、ネイティブビットマップデコード経験アンドロイドは、デコードビットマップの幅と高さに等しく適用し、次に表示倍率の大きさ、および必要なビットマップデコードから計算されます。
Androidのフォトアルバムを直接表示扱われていない、画像を90度に問題が回転した場合、それはビットマップ回転する必要があるが、大部分は回転の角度である、私のテストマシンで上記のマトリックス1080の画像を使用して回転さは約200msのを取りますOpenGLのテクスチャを回転させた座標た場合、わずか約10ミリ秒よりも大きいので、テクスチャOpenGLの回転を使用するより良い選択です。
プレビューは、水平方向のスライドページビューを入力します全体像の間に、ページビューのフラッターは、一般的に、隣接するページをロードするためのイニシアチブを取ることはありませ。インデックスが予め作成されていない場合、例えば、表示インデックスは、ページ4,6の5ページです。我々は0.9999となっPageControllerでパラメータを設定することができviewportFractionのためのトリッキーな方法があります。ページインデックスも表示される必要があるように、前の、例えば、ページインデックスに表示される、5時間である。4、6 0.0001。そのようなインデックスが1未満の画素表示ページ4,6であり、実質的に見えません。
PageController(viewportFraction=0.9999)
ネイティブ側で事前にロードされていることを行うための別の方法があります。たとえば、次の隣接画像4,6テクスチャが予めロードされたときにロードされた最初の5枚の画像において、場合4,6にスライドするとき、テクスチャキャッシュを直接使用します。
テクスチャキャッシュの後、直接質問：テクスチャのリリースだろうか？終了プレビューページの解放の時間が表示されるまで、ユーザは無限に成長するメモリを参照している場合、すべてのテクスチャは、非常に適切ではありません。したがって、我々は、テクスチャの最も古いがリリースされる、摺動時、5つのLRUキャッシュテクスチャを維持します。ページが終了すると全体のLRUキャッシュは破棄されます。
メモリーについて3
GPUのテクスチャを使用してアルバムの写真は、大幅にアプリケーション全体のパフォーマンスに一定の改善があり、Javaヒープメモリの使用量を削減します。それ以外の場合はメモリリークの危険性があるだろう、GPUメモリはタイムリーな使用後に削除するために限られた必要性がある、ということに注意してください。必要がGPUのスレッドでのことを確認、または何の効果を削除しないようにする場合また、Androidプラットフォームは、テクスチャを削除します。
試験を比較した上方Huawei社P8は、Android5.0は、フラッタオリジナルネイティブアルバムやアルバム全体的なメモリ・フットプリントを基本的に同じ、GridViewのリストページには、約13M最大メモリを追加します。違いは、Javaヒープメモリを使用して、元のネイティブのアルバムは、フラッターアルバムネイティブメモリを使用していることです。
概要
アルバム・コンポーネントAPIは、単純で使いやすく、高度にカスタマイズ可能です。構造化フラッター側は、自分の目標を達成するために書き換えることができるカスタマイズされたUIウィジェットが求められています。このアルバムは、アルバム自体のシステムに依存しない別のコンポーネントは、一貫性のUI、相互作用および既存のアプリを維持するために、完了しています。後部支持ますますアルバム将来的に再生するために関連すると同時に。
次の手順
私たちは、GPUのテクスチャを使用しているので、高精細4K表示画像をサポートするために考えることができ、クライアントのメモリは、あまりにも多くの圧力を持っていません。しかし、4Kビットマップ画像テクスチャのターンは、UIの相互作用は、上記の荷重条件をサポートするために行われる必要があり、より多くの時間を消費します。
コンポーネントの豊富な機能を備えた、安定、社会に恩返しするために、開いています。