タグ

GCとAndroidに関するraimon49のブックマーク (12)

  • 過去のブーム(並列プログラム)の現状を考える

    みんな割と未来の予言はよくするが、あんまりその結果を振り返らんよなぁ。 現在のディープラーニングのブームをどう捉えるか、というか、 プログラマのキャリアという点でどう接していくか、を考えるにあたり、 過去のブームを考えてみるのは良いんじゃないか、という気がした。 最近並列GCや並行GCの章を読んでいて、 一昔前の大きなブームとしてはParallel computingがあったなぁ、と思い出した。 ということでこの事について、専門にしてなかった部外者プログラマの目にどう映ったかを記しておきたい。 なお、「XXXだと言われていた」はあんまりソースとかを確認したりはしてません。 なんとなく自分はそう聞いていた気がしたしそう思ってた、程度のものです。 かつて思っていたことと当時の状況 Parallel computingはだいたい10年くらい前の時点ではその後の大きなトレンドとして明らかに存在して

    raimon49
    raimon49 2019/08/27
    10年前に予測されていたパラダイムの振り返り記事。こういうの大事。
  • ARTのメモリ管理

    MVP開発をするための要求の詰め方/How to think about requirements for MVP development

    ARTのメモリ管理
    raimon49
    raimon49 2015/08/20
    Dalvik VMからARTへの変遷
  • LeakCanaryでメモリリークを検出する - Qiita

    Squareがメモリリークを検出するライブラリ square/leakcanary を公開したので、さっそく使ってみたらすごく便利だった話です。 A small leak will sink a great ship Piwaiが書いたLeakCanaryの記事がこちらです。 LeakCanary: Detect all memory leaks! 要約すると、 Squareではビットマップキャッシュに顧客の署名を書いていたが、端末の画面のサイズ分のメモリを確保するので、署名をするときにクラッシュすることがあり、それがOOMの大半を占めていた。 Bitmap.Configを変更したり、OOMをキャッチしてGCを走らせたりしたが、問題の解決には至らなかった。 我々は間違ったアプローチを取っていたことに気が付いた。ビットマップの大きさではなくメモリリークが根的な原因だったのだ。 通常であれば

    LeakCanaryでメモリリークを検出する - Qiita
  • Shibu's Diary: iOSはなぜAndroidの半分のスペックでも快適なのか

    渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 iPhone6/6 Plusのメモリが1GBしかない理由 この記事が突っ込みどころが多いと話題になっています。初期の頃はiOSのなめらかな動きと比べたらAndroidは劣化版と言われても反論できない感じでしたが、Nexus 4/Nexus 5ともなるとだいぶ快適で乗り換えても違和感なく使えるようになりましたが、同じぐらいの快適さが得られるハードウェアを比べてみると、メモリも半分で、コア数も半分で、クロック周波数も半分で、バッテリーにやさしいハードウェアになっていることは確か。なぜそれでやっていけるのか、ということについて僕なりの理解をまとめます。元の英語記事は読んでません。 メモリ管理方式の違い Androidはマーク・アンド・スイープ方式のGCで、iOSはNSAutorele

    raimon49
    raimon49 2014/11/20
    バックグラウンドタスクの違いは確かに。
  • 最近のAndroid事情に対応した「OutOfMemoryErrorを知る」発表スライドを公開しました - ひつじのにっき

    横浜Android and モバイルOS プラットフォーム部で発表した資料です。 資料はAndroidアプリ開発者をターゲットにまとめました。OutofMemoryErrorの発生原理とメモリ管理について最新事情を加味してまとめました(新版、なのはAndroid 1.xのころの発表が古いのにまだ参照されていたりで、さすがに最新事情に合わせて更新したかったのです)。 Androidアプリにおけるメモリ事情は(初期に比べたら)改善していますが、OpenCVなど画像処理の需要、高解像度対応を踏まえると依然として十分とは言いがたいユースケースもあります。そんな中でメモリ資源をうまく使うための指標となれば幸いです。 資料にもある通り書きかけの状態ですのでコメントやmentionなど「こんな情報があるから書き加えて」「ここ調べて」「こういうのがおすすめ」「ここ間違えてる!」というご意見いただければ嬉し

    最近のAndroid事情に対応した「OutOfMemoryErrorを知る」発表スライドを公開しました - ひつじのにっき
    raimon49
    raimon49 2013/09/26
    >メモリキャッシュについてはSoftReferenceではなくLruCacheが主流になっています。Android 2.3系でコンカレントGCが採用されたころからの流れで、LruCacheクラスはv4 Support Libraryを使えばAndroid 1.6(!)までバックポートされてます
  • ImageViewとBitmap#recycle覚書 - hidecheckの日記

    開発してるとActivityにBitmapを持たせたいことってよくある でもメンバで持ってると自前で解放しなくてはならない。 Bitmapのメモリ管理はネイティブ側で管理されてるので明示的に開放する必要がある。 マジで?って思ったので実験してみた 実験内容 以下のパターンでBitmapActivityがどのように変化するかを確認 実験1 ImageViewを持たないActivity 実験2 レイアウトでImageViewを持ったActivity 実験3 レイアウトでImageViewを持ち、メンバ変数でもImageViewをもつActivity 実験4 ImageViewを持ち、メンバ変数でBitmapをもつActivity 実験5 Bitmap#recycleの正しい使い方 使うアプリ こんな感じのアプリ 実験2〜4 MainActivity>BitmapActivity>(戻るキーで)

    ImageViewとBitmap#recycle覚書 - hidecheckの日記
    raimon49
    raimon49 2013/07/30
    BitmapDrawableが参照しているとImageViewにsetしたBitmapは回収されない。imageView.setImageDrawable(null); -> bitmap.recycle(); -> bitmap = null;
  • JavaScript(V8)で避けるべき(だった?)クロージャの使い方 - kazuhoのメモ置き場

    Grokking V8 closures for fun (and profit?) に、ほんの少しだけ触れられている話なんですが。 ごく最近まで V8 には、オブジェクトリテラルの中で関数リテラルを使った場合に非常に遅くなる(というかGCが多発する)問題があった。 たとえば、 function doit() { for (var i = 0; i < 1000; ++i) { for (var j = 0; j < 1000; ++j) { var o = { f: function () { return i + j; } }; } } } doit(); というコードを node-0.6.19 で実行すると、以下のように mark-sweep GC が大量に発生して処理に時間がかかっていることが分かる。 $ time /usr/local/node-0.6.19/bin/node -

    JavaScript(V8)で避けるべき(だった?)クロージャの使い方 - kazuhoのメモ置き場
    raimon49
    raimon49 2013/02/06
    >最新版で修正されているとは言え、ブラウザがアップデートされない Android では、JavaScript コード側での対応が引き続き必要な案件のひとつ / つらい
  • Private Presentation

    Private content!This content has been marked as private by the uploader.

    Private Presentation
    raimon49
    raimon49 2011/05/28
    Dalvik on Android 2.3 リーディング マークのビットマップで回収オブジェクトを判定
  • [ケータイ用語の基礎知識]第495回:Gingerbread とは

    raimon49
    raimon49 2010/12/07
    コンカレントGC採用
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    raimon49
    raimon49 2010/11/06
    ここまで気配り必要なのか。ケータイアプリを思い出す。
  • throw Life - Dalvik VMのGarbage Collection概要

    ちょっと時間ができたので、知り合いのブログを読みあさってました。 すると、安藤恐竜さんとこでこんな翻訳記事を見つけました。 Track memory allocations(日語超訳) 大半のケースでは、数多くの小さくて短命なオブジェクトが原因でGCが起動される。世代別GCのような場合には、このようなオブジェクトの回収を最適化し、頻繁にGCが起動されることを防ぐことができる。AndroidのGCは、残念ながらそのような最適化を行うことができず、パフォーマンスに影響の多い一連のコードの中で、短命なオブジェクトを作ると、そのままアプリケーションの性能にとって影響が多くなってしまう。 マジっすか?!一応原文もチェック。 Track memory allocations Most of the time, garbage collection occurs because of tons

  • Android のメモリ管理は大変です

    ■理想 AndroidってJavaだからメモリ管理なんてしなくてもいいよね!! なんて思っていた時代が私にもありました・・・ ■現実 @Override protected void onDestroy() { super.onDestroy(); // 画面が回転した時など、Activityが破棄されるときに呼び出されます // すべてのメモリはここで開放します // - 特に危険なのが内部クラス(MyWebChromeClientなど)、正しく開放しないとActivityが開放されません // - セットしたbackgroundのcallbackもnullにしないと開放が行われません // - webViewのdestroy()を忘れると後からGCが走ったときにVMがクラッシュします this.webView.stopLoading(); this.webView.setWebChro

    raimon49
    raimon49 2010/10/06
    null 明示
  • 1