問題タブ [ipad-3]

ここ数日、Web アプリのデバッグに取り組んでいますが、モバイル サファリでクラッシュする原因がわかりません。このアプリは iPad2 では素晴らしく動作しますが、何らかの理由で iPad3 ではクラッシュします。コードのすべての部分をコメントアウトしましたが、問題のように見えるのは、要素の絶対配置です。これがセクションの私のコードです。

アプリをクラッシュさせているコードの部分は次のとおりです。

これがアップルのバグかどうかわかりませんか？複数の要素を問題なく絶対配置しています。この 3 行 (およびその 3 行のみ) をコメントアウトすると、アプリは機能します。コードの他のセクションをコメントアウトして、これらの 3 行をそのままにしてみましたが、うまくいきません。誰にも提案はありますか?? ありがとうございました！

アプリにカスタム ビュー (から継承UIView) があります。カスタム ビューのオーバーライド

- (void) drawRect:(CGRect) rect

問題はdrawRect:、iPad 2 よりも iPad 3 の方が何倍も長く実行されることです (iPad 3 では約 0.1 秒、iPad 2 では 0.003 秒)。約30倍遅いです。

基本的に、私はいくつかの事前に作成されたレイヤーを使用して、drawRect:. 最後の電話

ほとんどの時間がかかります ( の合計時間の約 95% drawRect:)

何がそんなに遅くなっているのか、そしてその原因をどのように修正すればよいのでしょうか?

アップデート：

直接関与するスレッドはありません。私はsetNeedsDisplay:あるスレッドを呼び出し、drawRect:別のスレッドから呼び出されますが、それだけです。同じことがロックにも当てはまります (ロックは使用されません)。

タッチに応じてビューが再描画されます (塗り絵アプリです)。iPad 2 では、画面のタッチと更新の間に妥当な遅延が発生します。iPad 3でも同じことを達成したい。

フリーハンド描画を実装したビューがありますが、小さな問題があります。iPad 3ですべてが地獄に落ちたことに気づいたので、ストロークされた部分だけを更新するように描画コードを更新しようとしました（おそらく最初に行うべきだったように）。ただし、開封後の最初のストロークと約10秒のアイドル後の最初のストロークは非常に遅いです。すべてが「ウォームアップ」された後、それはバターのように滑らかで、drawRectあたり約0.15msしかかかりません。理由はわかりませんが、最初のdrawRectとアイドル後の最初のdrawRectで、ビューの長方形全体がダーティとしてマークされています（更新には約150ミリ秒かかります）。スタックトレースは、私の長方形がオーバーライドされていることを示していますCABackingStoreUpdate_

長方形が大きい場合はレイヤーを描画しないようにしましたが、コンテキスト全体が空白になります（宝くじのように古い領域を描画すると再び表示されます）。UIGraphicsGetCurrentContext（）で何が起こっているのか誰かが知っていますか？それは私が問題を想像できる唯一の場所です。つまり、私のビューコンテキストは、コンテキストジニーによってヤンクされたため、完全に再度レンダリングする必要があります。同じコンテキストを永続化するために使用できる設定はありますか？または、ここで何か他のことが起こっていますか...最初の表示後に完全な長方形を更新する必要はありません。

私のdrawRectは非常に単純です：

Apple からこの拒否メッセージを受け取りました。

iPad (第 3 世代) で起動時にアプリが終了することがわかりました

第 1 世代と第 2 世代の両方の iPad で問題なく iPhone アプリをテストし、Retina モードでシミュレーターを使用して iPad の第 3 世代をテストしました。Apple はクラッシュ ログを提供してくれなかったので、別のテスト デバイスにお金をつぎ込む前に、ここで質問します。

デバイスをクラッシュさせることがわかっているが、シミュレーターで動作することを確認する項目のリストはありますか? @2x グラフィックスの Retina 解像度のものでしょうか?

iPad3/iPad2のアプリを開発しています。私のバンドルには、iPad2 と @2xiPad3 の両方のイメージがあります。バンドルを使用すると正常に動作します。iPad2 では低解像度の画像が検出され、iPad 3 では高解像度の画像が検出されます。しかし、私の問題は、ドキュメントフォルダーからアクセスするときです。ドキュメントフォルダーに対して同じことを行うにはどうすればよいですか。バンドルの代わりにドキュメント フォルダーを使用すると、低解像度の画像のみが読み込まれます。これが私のコードです。

image@2x~ipad.pngドキュメントディレクトリにも置いています。しかし、ipad3 では自動的に検出されません。拡張子なしの画像名も使ってみました。しかし、問題は解決しません。

iPad 1 で動作する Air アプリがあります。しかし、iPad 3 にインストールしようとすると、アプリのインストールに失敗します (役に立たないメッセージが表示されます)。ただし、この iPad に別のアプリをインストールすることは可能です。Adobe Air 3.2 SDK があります。App.xml構成は以下です

何か案は？

PSエラーログを見つけました

ユーザーがペイントしたり、他のビューを追加したりできるビューから画像を取得しようとしています。iPad1＆2では、これまでのところすべてが正常に機能しています。しかし、iPad3では犬のように動作します。レイヤーのrenderInContextメソッドを使用しています。

これはおそらくipad2と同じCPUが原因であることがわかりますが、約1秒かかります。ユーザーがペイントまたは追加するほど、レンダリングに時間がかかります。時には最大5秒で、これは本当に受け入れられません。では、パフォーマンスを向上させるためのオプションはありますか？より小さなレンダリング品質を設定する可能性があります-最高の網膜解像度でのレンダリングは必要ありません...

助けていただければ幸いです！前もって感謝します

画像ビューのアニメーションに大きな遅延があります。

ナビゲーションベースのアプリケーションを作成しています。

3 番目のビュー コントローラーの viewDidLoad で、イメージ ビューを作成し、それをサブ ビューとして追加しました。

ボタンをクリックすると、myImageViewをあるアニメーションから別のアニメーションに切り替えたいと思います。

画像のアニメーション配列が 2 つあります。初めて。

ボタンをクリックすると、次のように画像ビューがアニメーション化されます。

次のボタンを押すと、同じ ImageView を別の一連の画像配列でアニメーション化しました。

私の最初の問題は、3 番目のビュー コントローラーに移動する際の遅延でした。

この遅延は、3 番目のビュー コントローラーへの最初のナビゲーションでのみ発生します。画像のキャッシングが原因かと思いますが、2回目以降はナビゲーションの遅延がありません.UIImage imageNamed関数の画像キャッシング。したがって、初回のナビゲーションの遅延を回避するために、アプリのデリゲート自体から画像を強制的にロードしました。

強制荷重の方法を以下に示します。

しかし、最初のアニメーションにはまだ遅延があり、アプリケーションのパフォーマンスに非常に悪い影響を与えています。どうすればこの問題を解決できますか。

UIAlertViewがデリゲート内のハンドラーをトリガーしないというこの問題に遭遇しました。すべてのiOS5.0以降/iOS6ベータ（iPhone4 / 4s、iPod、ipad1 / 2）デバイスで正常に動作しますが、問題はiPad3のiOS6ベータ3でのみ発生します。

スケーリング技術を使用して、Retina ディスプレイでのキャンバス Web アプリの解像度を向上させています。基本的に、ここで説明する手法は次のとおりです。

http://zsprawl.com/iOS/2012/03/html5-canvas-and-retina-displays/

ただし、横向きモードと縦向きモードで実行すると、パフォーマンスに大きな違いがあることがわかりました。これを実証するために、jsFiddle テスト アプリをセットアップしました。埋め込みバージョンを表示すると、違いがわかります。

http://jsfiddle.net/SaJ69/embedded/result/

（ /embedded/result/ を削除すると、元のフィドルに移動します。2つのリンクを含む投稿しかできませんでした）

これを iPad3 で表示しているときに縦向きと横向きを切り替えると (切り替えるたびにブラウザ ウィンドウを更新する必要があります)、縦向きモードが横向きモードよりも途切れ途切れになっていることがわかります。これを自分の Web サーバーで (jsFiddle ではなく) 実行すると、結果がより顕著になります。

私はいくつかのフレーム レート メトリックを実行しようとしましたが、ブラウザーが実際に更新される回数ではなく、描画呼び出しを行う回数のみを測定しています。

誰でもこれについて何か洞察がありますか？これはハードウェア関連の問題ですか? 理論的には、同じ描画呼び出しを実行し、同じ数のピクセルを埋めていますよね?

-クリス