今日は、プライベートフォトアルバムにある大量のイメージを読み込み、スライドさせるためのソリューションを紹介します。
サムネイル画面で小さなサムネイルをクリックし、大きなHDイメージの全画面表示に移ってから1秒間の間に何が起こるかを詳しく説明します。
[]
従来の思考回路
小さなイメージをクリックした後
1.まず、スクロールビューフレームワークを作成します：異なるサイズの2つのスクロールビュー、1つのイメージのジェスチャーズーム用の小さなスクロールビュー、すべてのイメージを順番に水平に読み込むための大きなスクロールビュー。
2.スクロールビューフレームを作成した後、写真を読み込みます。
3.すべては、大きなイメージを選択するためにユーザーに提示されたページにジャンプする準備ができています。
アルバム内の写真が10枚程度であれば、イメージを読み込むステップは技術的に難しいことではありません。クラッシュしますか？それともユーザーを待たせるのでしょうか？ このステップを分割し、最適化する必要があります。
scrollviewフレームワークは、APIを理解する必要があり、その後、脳を移動し、ここではヒントですが、多くの人々が写真と写真の間に黒いボーダーの間隔を達成するために私に尋ねた、ああ、コードを貼り付けます：
#define PADDING 20
- (NSInteger)loadPhotos
{
//写真をクリーンアップする
for (UIView *v in [_scrollView subviews]) {
[v removeFromSuperview];
}
workingFrame = [[UIScreen mainScreen]bounds];
workingFrame.origin.x = PADDING;
for (int i = 0; i < int_total; i++) {
CGRect frame = workingFrame;
WQPhoto *photoView = [[WQPhoto alloc] initWithFrame:frame];
[photoView setScroller:self];
[photoView setIndex:i];
WQAlbumPhoto *photo = [albumObject._photos objectAtIndex:i];
[photo cleanThumbnail];
if (i == int_current) {
//オリジナルイメージを読み込む
[photoView setImage:photo.oriImage];
[photoView setIsLoad:YES];
}else if (int_current - 10 < i && i < int_current + 10){
//左右のサムネイルを読み込む
[photoView setImage:photo.thumbnail4view];
}
[_scrollView addSubview:photoView];
workingFrame.origin.x = workingFrame.origin.x + 2 * PADDING
+ workingFrame.size.width;
}
//スクロールできる
[_scrollView setContentSize:CGSizeMake(workingFrame.origin.x, workingFrame.size.height / 2)];
[_scrollView setContentOffset:CGPointMake(360 * int_current, 0)];
//残りのサムネイルを読み込む
loadThread = [[NSThread alloc]initWithTarget:self selector:@selector(loadImages) object:nil];
return 0;
}
低解像度イメージの使用
考えてみれば、すべてのイメージを元の高解像度で読み込み、各イメージに付随する低解像度のイメージを事前に保存して、スペースと時間を交換する****時間は本当に必要ありません。
マルチスレッドタスク
それでも、写真の枚数が一定量に達すると、消費される時間はミリ秒ではなく、満足のいくエクスペリエンスではなく、ページがジャンプしたときにラグが生じます。
そこで、マルチスレッドを使ってタスクをさらに分割し、ジャンプを実行しながらバックグラウンドで低解像度のイメージを読み込むステップを実行することを考えました。
高速フリップ体験の最適化
この分割により、即座にジャンプを実現でき、満足のいく体験ができます。なぜなら、低解像度のグラフを読み込むタスクのスレッドは、まだ多くのIO処理を実行している可能性があり、時間内にそれに追いつくことができないからです。 完璧にするためには、低解像度のグラフを読み込むステップをもう一度分解して、卓越を目指すべきです。
ページのジャンプ時間が許す範囲内で、ユーザーが選択した写真の元のHDイメージをロードしながら、左右に近い写真の低解像度イメージをできるだけ多くロードします。
残りの低解像度チャートを読み込むには？
ユーザーは、負荷の両側の中央として選択したイメージをクリックし、直接2つのスレッドは、左と右の負荷でなければならないと思い、その後、実際にロードするために一緒に左と右について考えることは、それらの消費のスレッドの開口部を避けるために、サイクルにすることができます。
-(BOOL)loadImages
{
for (int i = int_current - 10, j = int_current + 10 ; !( i < 0 && int_total - 1 < j); --i, ++j) {
if (!(i < 0)) {
WQPhoto *photo_pre = [_scrollView.subviews objectAtIndex:i];
WQAlbumPhoto *photoPre = [albumObject._photos objectAtIndex:i];
[photo_pre setImage:photoPre.thumbnail4view];
}
if (!(int_total - 1 < j)) {
WQPhoto *photo_next = [_scrollView.subviews objectAtIndex:j];
WQAlbumPhoto *photoNext = [albumObject._photos objectAtIndex:j];
[photo_next setImage:photoNext.thumbnail4view];
}
}
return YES;
}
***そしてチョッパー。
メモリフットプリントを最小化します。 元のイメージは低解像度のイメージよりもはるかに大きいため、ユーザーがあるイメージから別のイメージに切り替えると、現在のイメージは高解像度の元のサイズとして読み込まれ、元のイメージは低解像度のイメージに置き換えられます。 読み書きの回数は増えますが、メモリはかなり節約できます。
実を言うと、市場に出回っているフォトアルバムのアプリの中には、パラパラとめくっているときにラグでカクカクするものが結構あるんです(笑) ......。
