0

XCode の Utility Application プロジェクト テンプレートを使用して作成された非常に単純なアプリがあります。私の MainView には、2 つの UIPickerView コンポーネントと 2 つのボタンがあります。FlipSideView には別の UIPickerView があります。

メイン ビューのピッカーにはそれぞれ 4 つのセグメントがあり、各セグメントには 8 つの行があります。反対側のピッカーには、8 行のセグメントが 1 つだけあります。すべてのピッカーのすべての行は単なるテキストです。

この設定だけで、ボタンを押してビューを前後に反転すると、アニメーションが実際に開始される前に顕著な遅延が表示され、失われた時間を埋めようとしているかのように、実際にはアニメーションが本来よりも速く進んでいるように見えます。

Interface Builder でピッカーを削除し、電話にアプリをロードすると、アニメーションが自然に見えるようになりました。また、1 つのピッカー (フリップサイド ピッカー) だけを試してみましたが、まだ正常に見えます。したがって、私の現在の理論は、メイン ビューに含まれるオブジェクトの数が原因であるというものです。それほど多くはないと思いますが (4 x 8 x 2 = 64)、完全に間違っている可能性があります。これはほとんど私の最初のアプリなので、何かひどく間違ったことをしているのかもしれません。あるいは、電話の処理が思ったよりもはるかに制限されているのかもしれません。

pickerView:viewForRow:forComponent:reusingView: を使用してピッカー ビューを作成し、うまく機能するかどうかを確認することを考えていますが、これが単なる時間の無駄であるかどうかはわかりません。

助言がありますか?

ありがとうルイ

PS: 3.1.2 の 3G 電話でのテスト

4

1 に答える 1

0

行とコンポーネントの数は、ピッカー ビュー自体のパフォーマンスとはほとんど関係がありません。ピッカー ビューはテーブルのように機能し、実際にはメモリ内にコンポーネントと行の数はありません。代わりに、一度に画面に表示される同じ一握りのビューを交換して再利用します。したがって、それぞれが一度に 5 行を表示する 4 つのコンポーネントがある場合、ピッカー ビューは、各コンポーネントに数百の論理行がある場合でも、20 を超えるビューを保持することはありません。

したがって、ピッカー ビューのデータソース内の論理要素の数は、その視覚的なパフォーマンスとは無関係です。

ピッカー ビューとトランジションで何が表示されているか正確にはわかりませんが、ピッカー ビューを読み込んで構成するカスタム コードのどこかで停止した可能性が高いです。ブレークポイント/ログを設定して、移行中にどこで時間を費やしているかを確認します。

于 2010-03-26T04:08:31.980 に答える