アップルの『 iOSアプリケーションプログラミングガイド（英語版）』に、『パフォーマンスと応答性のチューニング』という章があって、これが今読むとかなり参考になったので、引用します。 個人的には、「リソースをあらかじめロードしておくと高速化になりそうだけど、メモリの無駄遣いになって結果的に遅くなるので絶対にやるな」というのが一番ささりました。 画像ファイルはUIImage化しておくと使うときに速そうだなーとか考えてたところだったので。 他にも個人的にためになった部分を太字にしてあります。 メインスレッドを妨害しない アプリケーションのメインスレッド上で実行する処理のタイプを必ず制限します。メインスレッドは、アプリケーションがタッチイベントやその他のユーザ入力を処理する場所です。 アプリケーションが常にユーザに応答することを保証するには、時間のかかるタスクの実行や際限なく続く可能性のあるタスク
LRUなディスクキャッシュを実装する場合など、CoreDataに画像を突っ込みたくなることがあると思います。 しかし、画像をそのままattributesに突っ込むことはフェッチ速度の低下につながります。 何か上手い方法はないかな〜と思ってAppleのCoreDataプログラミングガイドを眺めていたら、ありました。 画像などのBLOBをCoreDataに突っ込む場合、BLOBであるattributeをエンティティから切り離すと良いそうです。 今回は、これについて検証したことを紹介します。 比較するデータ構造 ISFatUser attributesに画像が突っ込まれたエンティティです。 BLOBが入っているので”Fat”です。 ISUser 画像を別のエンティティに切り分けたエンティティです。 attributesに画像を持たない代わりに、画像を持つエンティティ(ISIcon)とrelat
ちょっと仕事で触ってみて分かった範囲のことを書きます。断りがない限り、 iPhone 3GS で Wifi 接続環境下においてテストしました。 ■キャッシュ無し vs キャッシュ有り executeFetchRequest:error: メソッドを用いて、 Entityのプロパティで一件だけ絞り込んで返すようなクエリは大変遅いということが分かりました。Indexを付けて実行してもほとんど速くなりません。どうやらそもそもバックエンドに使っているSqliteが大変遅い、特にコネクションを生成したり破棄したりするのが遅い感じがするので、ループで一件ずつ取得するなどのときはたくさんのSQLが実行されないようにする必要があります。 objectWithID: メソッドは試していないのでちょっと不明です。 回避策として、アプリが起動したタイミングで当該エンティティの全オブジェクトをあらかじめ取ってきて
Auto Layout made it's first appearance with Mac OS X Lion. One year later Apple introduced it on iOS 6 as the new and preferred way of laying out views (Auto Layout is enabled by default). It's main advantage is that it allows for more flexible layouts when dealing with multiple screen sizes, interface orientations and languages. The project I'm currently working on with Chris Eidhof uses Auto Lay
パフォーマンスを向上させる２５の基本Tips
Open In とは他のアプリへファイルを渡すあれ。 DropBoxはどんなファイルでも Open In で受け取れるようになっている。そこでDropboxのplistファイルを解析してみたというのがこの記事。 Open In … All Files | Coco...
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
