タグ

programmingとcacheに関するastk_fのブックマーク (9)

  • Facebook: iOSアプリのアーキテクチャ - ワザノバ | wazanova

    https://www.youtube.com/watch?v=XhXC4SKOGfQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 39分前 FacebookのiOSチーム、Adam ErnstとAri Grantによる@Sacle 2014での講演。データモデルとビューレイヤの改善の取組みについて紹介してくれてます。 1) データモデル 背景 2年前からHTML5からネイティブに切り替えて一旦大きく改善したが、その後機能を追加するたびにアプリのパフォーマンスが悪化。 ネイティブに移行後、オブジェクトのキャッシュレイヤとしてiOSのCore Dataを使ったのが失敗であった。 Core Dataの役割は「整合性を含むオブジェクトグラフ管理」 Facebook iOSアプリの場合、サーバ側を正のデータとするが、

  • Android Tips #51 ネットワーク通信・キャッシュ処理をより速く、簡単に実装できるライブラリ “Volley” を使ってみた | DevelopersIO

    Android Tips #51 ネットワーク通信・キャッシュ処理をより速く、簡単に実装できるライブラリ “Volley” を使ってみた Volley とは 先日開催された Google I/O 2013 で Volley というネットワーク処理を高速化するライブラリが発表・公開されました。Volley を使うとよくあるネットワーク通信処理やキャッシュ処理を今までより簡単に実装することができます。物凄く魅力的ですね!以下のような機能があるようです。 JSON や画像ファイルなどのダウンロード非同期処理の簡素化 リクエストのスケジューリング リクエストの優先順位付け メモリキャッシュ・ディスクキャッシュ 強力で簡単なリクエストキャンセル Activity が存在しないときの自動キャンセル ということで Volley をアプリに入れて使うまで試してみたいとおもいます。またセッションの内容は以下

    Android Tips #51 ネットワーク通信・キャッシュ処理をより速く、簡単に実装できるライブラリ “Volley” を使ってみた | DevelopersIO
  • LruCacheの使い方

    TwitterのツイートをListViewに表示するという処理で、TwitterアイコンのキャッシュにLruCacheを使ってみたメモです。 TwitteアイコンのキャッシュにSoftReferenceを使っていたのですが、2.2 と 2.3 / 4.xで挙動が違って困っていたところ、以下のツイートに出会う。 2.3 から GC の方式が変わったので、SoftReference や WeakReference で Bitmap をキャッシュするのはあんまり意味ないからオススメしないそうだ — Yuki Anzaiさん (@yanzm) 8月 14, 2012 これどこ情報なんだろう?ListViewに表示するTwitterアイコンのキャッシュにSoftReference使ってるけど、確かに2.2、2.3、4.xで動き違って困ってた。2.3と4.xはすぐキャッシュが解放されてて再取得が走る.

  • Android バックグラウンドで Bitmap を処理する

    Processing Bitmaps Off the UI Thread の内容に補足を付けて解説してます。 前回のエントリーで大きい画像を効果的に読む込む方法を解説しましたが、デコードするデータがディスクやネットワークにある場合、BitmapFactory の decode* メソッドは UI スレッドで行ってはいけません(というかメモリ上以外のデータを読み込む場合は全部だめ)。 これらの処理はディスクやネットワークのスピード、画像のサイズ、CPUのパワーなどさまざまな要因で完了までの時間が変わり、いつ完了するのかわかりません。 もし画像のデコード処理で UI スレッドをブロックしてしまうと、最悪 ANR が発生します。 そこで、AsyncTask を使ってバックグランドで Bitmap を読み込むようにします。 ■ AsyncTask を使う 特に何も考えないで作ると、きっとこんな感じ

  • Android 大きい画像を効果的に読み込む

    Loading Large Bitmaps Efficiently の内容なのですが、補足も入れてメモっておきます。 端的にいうと、 実際に表示するサイズより大きい Bitmap を読みこむのはメモリの無駄 (拡大させるとかなら話は別だけど) ・高解像度のカメラで取られた写真は往々にしてディスプレイのピクセルサイズより大きい ・サムネイルとして使うのに元のサイズのまま読み込むのはばかげてる ・大きいサイズの Bitmap をメモリに展開したら OutOfMemoryException になる ステップとしては3つ 1. メモリに Bitmap 展開せずに、サイズや MimeType だけを取得する 2. 1. の情報をもとにサブサンプルにサイズを決める 3. 2. で決めたサブサンプルで Bitmap をメモリに読み込む 1. メモリに Bitmap 展開せずに、サイズや MimeType

  • Android Bitmap をキャッシュする

    Caching Bitmaps に補足をつけて解説しています。 前回のバックグラウンドで Bitmap を処理するで、最後に(でもキャッシュは、、、?)と書きました。 そう!キャッシュ!キャッシュ大事。 前回までの段階でもまだ ListView で使うには問題が残っています。 既にタスクが走り終わって ImageView に画像がセットされている行をいったんスクロールアウトし、再度スクロールして画面に表示すると、またタスクが走ってしまいます。 スクロールするたびに読み込み状態になるのはユーザーとしてはうれしくないですよね。 そこでキャッシュを使って、一旦読み込んだ画像が再度必要になったときに利用できるようにします。 キャッシュとしてはメモリキャッシュとディスクキャッシュを利用することができます。 ■ メモリキャッシュ メモリキャッシュの利点は読み込みが速いこと、欠点はメモリを消費することで

  • BOOT_COMPLETEDが受信出来ない - Google グループ

  • CacheオブジェクトにはSoftReferenceを | Techfirm Android Lab

    Android、いかがですか。 今日もOut Of Memory、出していますでしょうか。 そんなあなたに朗報です。 少しでもメモリにやさしいプログラムを。 今日はSoftReferenceのお話です。 トレードオフ Androidで(というよりもJavaで)パフォーマンスに最も影響を与えるのはインスタンス生成の部分ではないでしょうか。 ループの中でインスタンスを生成しようものなら、たちまちあなたのUIは機敏さを失うことになるでしょう。 インスタンス生成はGCの源です。ストップザワールドを少しでも避けるためには極力newなどは控えなければなりません。 となると、インスタンスを作らないことが究極なのですが、全く作らないというわけにはいきません。ならば、一度作ったインスタンスは再利用しようではありませんか。 その時に役に立つのがキャッシュです。一度作ったインスタンスはキャッシュに保持し

  • 403 Forbidden

    \閉鎖予定のサイトも売れるかも?/ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう

  • 1