OS X Yosemiteのアニメーションが遅いときにやったこと(2008-2012 Dual-GPU MacBook Pro)

Yosemiteさんアニメーションがカックカクやん

今更、Yosemiteのアニメーションが重い時にやったことを書きます。前提条件として2008-2012年までに発売されたDual-GPUを搭載しているMacBook Proが対象です。Dual-GPUはIntelのHDグラフィックスとディスクリートGPU(高性能)が2つ搭載されていて、使用状況に合わせてGPUを切り替えることで省電力に貢献しているとのこと。ディスクリートGPUの方が高性能なので、もちろんアニメーションについてもディスクリートGPUの方が良いと思っていたのですが、どうも逆の様です。Yosemiteのアニメーションだけで言うと確実にIntelのHDグラフィックスの方がヌルヌル動きます。(あくまで私の環境。MacBook Pro(15-inch, Mid 2010), OS X Yosemite 10.10.3, 2015/05現在)

2015/10/17 追記：
OS X El Capitan にアップデートしたらアニメーションの問題は全て解決してしまいました。この件だけで言えばOS X El Capitanにアップデートすることをオススメします。

IntelのHDグラフィックスGPUに固定しちゃう

ということで、IntelのHDグラフィックスにGPUを固定してしまえば良いことに。後はGPUのスイッチをある程度制御が可能なgfxCardStatus(free and open-source)を利用して固定するのみです。「Integrated Only」にすれば固定できます。(たまに強制的にディスクリートGPUになる場合もあります)

おわりに

一般的にはキャッシュクリアしたり、アニメーションを無効にしたり、透明度を下げたりすることで、ある程度不満は解消できるようですが、それ以外の方法として書きました。また、せっかく高性能なGPUを搭載しているのに、あえて使用しない方向へ設定しているという「なんでやねん感」がハンパないです。でも、結構ヌルヌル動くので自分は満足しています。

ちょっと誤解を招きそうなので追記。 OS起動後に何もアプリケーションを起動していない状況ではディスクリートGPUの方が滑らかにアニメーションしていますね。ですが、私の環境では特にターミナルを半透明背景で起動していると状況が逆転し、ディスクリートGPUの場合はカックカクです。この状況下でIntelのHDグラフィックスGPUの場合はまともにアニメーション出来ているということです。ディスクリートGPUの場合、Yosemiteの半透明やブラー効果のアクセラレーションが効いていないみたいな感じでしょうか。

Xcode6でView Debuggingすると必ずkernel panicになる場合の対処法

View Debuggingを行い、3Dローテーションすると落ちる

Xcode6の新機能であるView Debuggingですが、私の環境だと必ずkernel panicが発生しOSごと落ちてしまいます。(再現率100%)

カーネルパニック時のログ(一部抜粋)

panic(cpu 0 caller 0xffffff800cedc43e): Kernel trap at 0xffffff7f8e882115, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x00000000000089f4, CR3: 0x0000000022d92000, CR4: 0x0000000000000660
RAX: 0x0000000020000901, RBX: 0x00000000000000fc, RCX: 0x0000000000000000, RDX: 0xffffff80ffd92c30
RSP: 0xffffff81182cb8b0, RBP: 0xffffff81182cb8e0, RSI: 0x0000000000000000, RDI: 0x0000000000000000
R8:  0xffffff8100386000, R9:  0x0000000000010000, R10: 0x00000000000000b6, R11: 0x00000000000000b6
R12: 0xffffff80df56c000, R13: 0xffffff80df570813, R14: 0x0000000000000000, R15: 0xffffff81182cb9f8
RFL: 0x0000000000010202, RIP: 0xffffff7f8e882115, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x00000000000089f4, Error code: 0x0000000000000000, Fault CPU: 0x0

Backtrace (CPU 0), Frame : Return Address
0xffffff81182cb540 : 0xffffff800ce22f79
0xffffff81182cb5c0 : 0xffffff800cedc43e
0xffffff81182cb790 : 0xffffff800cef3976
0xffffff81182cb7b0 : 0xffffff7f8e882115
0xffffff81182cb8e0 : 0xffffff7f8e84efea
0xffffff81182cba60 : 0xffffff7f8e87e940
0xffffff81182cbb20 : 0xffffff7f8e84dad9
0xffffff81182cbb70 : 0xffffff800d2cf146
0xffffff81182cbb90 : 0xffffff800d2d0741
0xffffff81182cbbf0 : 0xffffff800d2ce1af
0xffffff81182cbd40 : 0xffffff800ceb6998
0xffffff81182cbe50 : 0xffffff800ce26bc1
0xffffff81182cbe80 : 0xffffff800ce139c5
0xffffff81182cbef0 : 0xffffff800ce1e013
0xffffff81182cbf70 : 0xffffff800cec9b9d
0xffffff81182cbfb0 : 0xffffff800cef4196
      Kernel Extensions in backtrace:
         com.apple.GeForceTesla(8.2.4)[B0074750-2FC6-3E26-BEA0-5AD5469686CF]@0xffffff7f8e83c000->0xffffff7f8e906fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[2852ACFE-FD28-3C37-9B39-885201BB8D25]@0xffffff7f8d4bf000
            dependency: com.apple.iokit.IONDRVSupport(2.4.1)[D41125CE-69BD-32E7-9B1D-4E83431662DD]@0xffffff7f8d8e0000
            dependency: com.apple.iokit.IOGraphicsFamily(2.4.1)[75D81741-64C1-3941-ADFA-9D6B6C434EE4]@0xffffff7f8d89d000
            dependency: com.apple.nvidia.classic.NVDAResmanTesla(8.2.4)[D61B2BB9-4289-318D-9197-5E1E13B1FF32]@0xffffff7f8d8f0000

BSD process name corresponding to current thread: Xcode

恐らくNVIDIAのGPUドライバが原因っぽいですね。

発生対象と対処

ネットで調べてもあまり同様の事象を発見出来なかったことから、あまり多くのユーザでは発生していないか、View Debuggingが使われていないかのどちらかと思います。まあ、前者でしょうか。 私のPCはMacBook Pro 15-inch, Mid 2010 で、この端末はGPUとしてIntelの統合グラフィックスとNVIDIAのGPUの2つ載っており、必要に応じて自動的に切り替えられています。 NVIDIAのGPUはGeForce GT 330Mが使用されています。 kernel panic時のログからNVIDIAのGPUドライバで落ちていることはわかっているので、Intel統合グラフィックスに固定してあげればこの問題を回避できるというわけです。 GPUの切り替えはユーティリティを利用します。gfxCardStatusというユーティリティが良いでしょう。Google ChromeやTwitterアプリなどはデフォルトでNVIDIAの高性能GPUを使用するので、Intel統合グラフィックスを 利用するにはアプリケーションを終了する必要があることに注意して下さい。私はこれで切り替えてからView Debuggingしたら見事に動作しました。

gfxCardStatusを起動するとメニューバーに常駐するので、以下のように統合グラフィックスを固定で使用するように指定します。この際、高性能GPUで動作しているアプリケーションが存在するとエラーダイアログが表示され、対象のアプリケーションを教えてくれます。

Xcode6でView Debuggingを起動(上段のキャプチャ)。グリグリ動きます(下段のキャプチャ)

あ〜、新しいマシン欲しいな〜。

iPhone5用ケース(TUNEWARE CarbonLOOK for iPhone 5 ブラック)

みなさまiPhone5購入しましたか？　私は ソフトバンクオンラインショップ で申し込み1Week程で入手することが出来ました。 入手後に一番悩むこと。ケースです。そうですケースです、ケースなのです。(3回言ってみましたｗ) とりあえず、気に入ったケースが見つかるまではハダカで良いやとも思いましたが、どうもiPhone4の時からケースを装着していたので、ケースに包まれていない状態が不安でたまらないのです。

購入したiPhone5用ケース

TUNEWARE CarbonLOOK for iPhone 5 ブラックを購入しました。
というのも、iPhone4の時もこれを使用していたからという、安易な理由だけです。 実は色々とアマゾンや楽天で探してみましたが、あれもこれもで時間ばかりかかり一向に1つに絞る事が出来なかったので、ケースの感触や使用感が分かるという理由で同じもののiPhone5用のケースに落ち着きました。
はじめに申しておきますが、私は以下の観点でケースを求めていました。

iPhone本体裏面のアップルマークは見えなくて良い。（逆にiPhone?くらいが良い）

黒系を求めているが、ただ真っ黒はいや。ちょっと変化がほしい。

ケースの薄さとかは気にしない。

iPhone表面のエッジを全て囲むようなケースは好きではない。（ソフト系ケースに多い）

本体保護という基本機能は無視出来ない。

クリアハード系は使用してくると傷が目立つので対象外。

といった所でしょうか。

装着感、その他

ケースはこのようになってます。

ケースの裏側はスウェード調になっているので、iPhoneへのソフトタッチ仕様になっている。

あくまでカーボン調なので、本物ではありません。触った感じは固めの布で覆われているような感じ。 まあ、値段相応の作りこみだと思います。それほどチープな感じは無いですが、そこまでの高級感も無いです。 実際に装着したイメージが以下です。

四隅のケースは若干スクリーン面より高くなっているので、画面を下向きに置いても傷が付きにくいかも。本当に微妙に高い程度なので、過信はしない方が良いです。

問題のカメラホール。

ストラップ用の穴（使いませんが）

気になる点

気になる点はカメラホールの穴が大きいこと！ちょっと大きすぎますよね。 iPhone4用の同じ製品はカメラとフラッシュ部分のみが綺麗にくり抜かれていたので、どうしてこんな馬鹿でかい 穴開けるんだと思っていたら、どうやらカメラやフラッシュがケースに干渉することが無いAppleの推奨値(iPhone 5用ケースのカメラホールが大きい理由)が存在するようで、それに従ったためこのような大きな穴と決定されたようです。
個人的には、それほど悪くは無いと思います。現状気に入って使用しております。
よかったらAmazonからどうぞ。
因みに、Amazonレビューでは酷評が多いですが、私はそれほど悪くは無いと思っているんですけど。私の感覚がズレているんでしょうか。まあ、ケースに何を求めているかで評価は決まってくるんでしょうね。

【正規代理店品】TUNEWEAR CarbonLOOK for iPhone5 ブラック TUN-PH-000167

posted with amazlet at 12.10.01

TUNEWEAR (2012-09-13)
売り上げランキング: 753

Amazon.co.jp で詳細を見る

Bloggerで急にSyntaxHighlighterの挙動がおかしくなったので調べてみた

この記事を書いている現在(2012/8/6)、BloggerでSyntaxHighlighterの挙動がおかしい。

何処がおかしいのか

気付いているのは以下

• 行番号が2桁になると潰れて表示される
• 変な箇所で改行がはいっている(これは良くわからないけど最後のセミコロンのみ改行されていたり)

1点目は以下のような感じ。これでは逆に読みづらくなってしまう。

CSSを見てみる

どうも怪しいのは、 http://agorbatchev.typepad.com/pub/sh/3_0_83/styles/shCore.css に定義されている以下の箇所。

.syntaxhighlighter table td.gutter .line {
  padding: 0 0.5em 0 1em !important;
}

この定義の「padding」の値がちょっとBloggerとの相性が良くないっぽい。 この値は行番号の上下左右の空白サイズを定義しているが、さにその外側を定義している 「td.gutter」のwidth定義値よりも大きくなってしまっているため結果的に2桁の行数になると改行されて表示 されてしまっている。ちなみに、「td.gutter」のwidth値はautoとなっているので他のレイアウトに 影響されて値が確定されていると思う。

何が原因なのよ

今まで動いていたので、このCSSが更新されたのか(更新履歴を見る限り最近更新されていない)、 Bloggerのテンプレートが更新されたのかのどちらかだと思われるのだが、それもなさそう。
とここで気が付きました。ブラウザです。自分はOS X(10.8)でGoogle Chrome(現在のVersion：21.0.1180.57) を使用していますが、試しにSafariで見てみたら全く問題なかった。うーん、そういうことだったのか、試しに SyntaxHighlighterを使用している他のブログも見てみましたが、Chromeで見るとダメで、SafariはOKでした。 IEは今Mac使っているので試せません。

対処

あくまで暫定的ですが、CSSを定義しなおして対処します。 SyntaxHighlighterを使うには以下のCSSファイルを読み込んでいると思いますが、その定義の直後に 該当のCSS定義を上書きします。

/* SyntaxHighlighterを使っている方はこの定義をしているはず */

/* 以下の定義を追加して上書き */

あくまで暫定。でも問題の1点目が改善されるだけ。2点目の変な所で改行される問題はこの対処では治りません。 現に上のコードをChrome上で見ると、2行目が改行されちゃって3行目としてカウントされてしまい、コードの最終行に行番号が表示されていません。個人的にこの2点目の問題はそれほど重症では無いので放置ｗ

詳解 Objective-C 2.0 第3版

posted with amazlet at 12.10.27

荻原 剛志
ソフトバンククリエイティブ
売り上げランキング: 1371

Amazon.co.jp で詳細を見る

Mac OSでstrace（あれ？存在しないぞ）

ちょっととあるプロセスが気になったのでstraceで調べようと思ったのですが、Macにstraceは存在しないみたいです。 mac portsにも無い。うーん。 調べていたら以下のコマンドがあったので忘れないようにメモ。

Mac OSでstraceコマンドに代わるコマンドたち

[2013/12/5 更新] straceに代わるコマンドが発行するシステムコールを表示するコマンドとして dtrussというコマンドがありました。

• dtruss
• sc_usage
• fs_usage

詳細はmanコマンドで調べて欲しいですが、

sc_usageコマンドはシステムコールの統計情報を表示します。
fs_usageコマンドはファイルシステムに関するシステムコールを表示します。

sc_usageは統計情報なので、表示としてはtopコマンドのシステムコール版のようなイメージですね。 fs_usageは指定したプロセスがコールしているファイルシステム等に関するシステムコールがリアルタイムに 表示されるイメージです。私の場合、straceを使う場面は該当プロセスがどのファイルにアクセスしているとか、 どの通信をしているのかが知りたい時なので、そういう意味でstraceに近いのはfs_usageの方かもしれません。

sc_usage 使用例

　以下はTerminalのシステムコール統計を表示します。引数にプロセス名を指定します。また、管理者権限で実行する必要があるので、sudoコマンドで実行する必要があります。

MacBook-Pro:~ naoyuki$ sudo sc_usage Terminal

fc_usage 使用例

使い方はsc_usageと同じです。プロセス名を引数に指定します。

MacBook-Pro:~ naoyuki$ sudo fs_usage Terminal

その他コマンド

　私がLinuxを使用している時に該当プロセスが使用しているファイルを調べるコマンドに
lsofというコマンドがあるのですが、これはMacに標準で存在しました。

% lsof -p [pid]

のように使用します。このコマンドは管理者権限の必要は無いようなので、sudoの指定は必要無いです。

Macbook-Proが電源アダプタ接続時のみスリープしない件(解決済み)

ちょっと前からMacbookを電源アダプタに接続している場合のみスリープしなくなっちゃいました。 不思議なのはバッテリー駆動時ではスリープできるのです。 Macbookは基本スリープ運用しているので、電源アダプタ接続時のみとはいえスリープ出来ないのは結構いたいです。

スリープ出来ない時のMacbook-Proの様子

スリープ出来ない事象は以下のような感じでした。

• 電源アダプタ接続時、Macbookのディスプレイを閉じてもスリープランプが点滅しない。
• ディスプレイを開けると一瞬画面が表示された後に画面がブラックアウトする。
• 画面がブラックアウトしても、一度バッテリー駆動にすると画面が映る。
• 画面左上のアップルメニューからスリープしてもダメ。
• 自動スリープもダメ。
• バッテリー駆動時はスリープが可能。
• OSはMac OS X バージョン 10.7.3

色々ネットで調べて、常駐アプリだとか、共有設定だとかスクリーンセーバーだとかPRAMクリアだとか試しましたが、 事象は改善せずです。

解決へ向けて

スリープ出来ない原因は多々あると思われますが、もしpmset -gコマンド実行結果が以下(赤字の部分)のようなら 私と同じ原因の可能性があり、解決できるかもしれません。
ターミナルを起動して以下コマンドを実行します。

MacBook-Pro:~ naoyuki$ pmset -g
Active Profiles:
Battery Power           -1
AC Power                -1*
Currently in use:
 womp           0
 halfdim        1
 sms            1
 panicrestart   15
 gpuswitch      2
 hibernatefile  /var/vm/sleepimage networkoversleep       0
 disksleep      10
 sleep          0 (imposed by 16) 
 hibernatemode  3
 ttyskeepawake  1
 displaysleep   15
 acwake         0
 lidwake        1

上記結果の「sleep 0 (imposed by 16)」のようにsleepの値が0になっていてその後ろに括弧でメッセージが 書かれています。

 sleep          0 (imposed by 16) 

の16という数字はPIDらしいです。このPIDのプロセスが原因でスリープ出来ないことを意味しているっぽい。 私の環境ではcupsのデーモンプロセスがこのPIDに該当しました。プロセスIDはターミナル上で ps -ef を実行するか アクティビティモニタで確認出来ます。
ここで、いきなりPID 16のプロセスをKILLするのは怖いのでCUPSのデーモンを調べてみました。 どうもCUPSの設定はWEBインタフェースで提供されているらしく、ブラウザから「http://localhost:631」とすれば 管理画面にアクセス出来ます。

ジョブが溜まっていたようでこのプリントジョブを削除してから再度 pmset -g コマンドを実行すると、

sleep 180

のようになり(私はこの時、電源接続時スリープ設定を3時間に設定)、imposedのメッセージが削除されていました。この状態でスリープを試してみたら見事 スリープが可能になっていました。いやー良かった良かった。終わり。

MacBook Proのメモリ増設(4G → 8G)

アマゾンで8Gメモリが3000円台で売られていたので、前々からどうかなぁ〜っと思ってました。 私のMacBook Pro(15inch 2010 mid)は、標準で4Gのメモリを積んでいますがLionにしたあたりからメモリが厳しい、と感じていたこともありダメ元？で買ってみました。ちなみに、この商品はアマゾンレビューで評価も良く一部認識しない等の問題が報告されていましたが、殆どは問題なく認識して使用出来ているレビューが大半でした。
結論を書いてしまいますが、私は無事8Gを認識し、問題なく使用する事が出来ました。
注）本レビューは全ての端末で該当メモリが使用できることを保証するものでは有りません。＃一応書いておきます。

購入したメモリ(8G)

私は約2年前に購入したMacBook Pro 15-inch,Mid 2010を使用しているので、以下のメモリが丁度良いです。

DDR3 (Double Data Rate Small Outline Dual Inline Memory Module) 方式

30 mm (1.18 インチ)

2 GB または 4 GB

204 ピン

PC3-8500 DDR3 1066 MHz タイプの RAM

シー・エフ・デー販売 メモリ ノートPC用 DDR3 SO-DIMM PC3-8500 CL7 256x8Mbit 4GB 2枚組 W3N1066Q-4G

2011年モデル以降の場合、以下になると思います。
詳細はこちらを参照下さい。
メモリ交換の手順も載っています。

DDR3 (Double Data Rate Small Outline Dual Inline Memory Module) 方式

67.6mm x 30mm (1.18 インチ)

2 GB または 4 GB

204 ピン

PC3-10600 DDR3 1333 MHz タイプの RAM

シー・エフ・デー販売 Elixir ノートPC用メモリ DDR3-1333（PC3-10600） SODIMM CL9 4GB 2枚セット W3N1333Q-4G

メモリの交換

Appleの公式手順はこちら。
特に解説する必要も無いと思いますが、私は少しハマった所があったので、その部分を書きます。 まずは裏面のネジ10本をはずします。ネジはかなり小さいので無くさないように注意して下さい。私の場合、長いネジ３本、短いネジ７本の構成でした。外すと以下のように丸見え状態に。

矢印の部分がメモリのピンです。

メモリの取り外し

メモリの取り外しはメモリの両脇にあるピンを両脇側へ広げ、メモリが斜め上側へ向きを変えるのでそのままメモリを外します。 ２枚目も同様に行います。

メモリの取り付け

新しいメモリを斜めに挿して、水平に倒してます。２枚目も同様に。
私はここでやっちゃいました。２枚目のメモリの差し込みがあまい状態で水平に倒してしまったので、メモリの枠？に丁度ハマってしまい、今度は取るにも取れなくなってしまいました。なんとか取り外してやり直す事が出来ましたが、指す時は「斜め」の状態の時に十分に差し込みを確認してから水平に倒して下さい。

起動、メモリの確認

端末を起動し、「アップルメニュー」ー「このMacについて」で確認すると見事に8Gを認識していました。

Apple Hardware Test

8Gを認識していたので、もう十分なのですが、メモリを浅く挿してしまった失敗時の取り外しの時にやや強引に取り出してしまったので、一応ハードウェアテストを実行してみました。このApple Hardware Test(以下、AHT)ですが、マニュアルには「再起動してDボタンを押し続ける」と記載されているのですが、何度やっても普通に起動されてしまってAHTが始まりませんでした。
Lionにアップグレードしたから？かわかりませんが、Mac購入時に付属されるDVDに格納されているらしく、該当のDVDを挿入した状態で、再起動しDボタンを押下することで起動出来ました。DVDは以下のです。

起動後と診断後の画面。診断自体は５分程度で終わりました。

まだ、１日しか使用していませんが、現状まったく問題はありません。やっぱり8Gは余裕があって良いです。Xcodeを起動中でも気にしないで他のアプリを起動出来ますし、明らかに全体的なパフォーマンスが向上した印象を感じます。

MACでのスクリーンショット取得

いつも忘れてしまうので、メモっておきます。

ショートカットキーにてキャプチャ

キャプチャの種類	キーボードショートカット
画面全体をキャプチャ	shift+command+3
マウスで選択部分をキャプチャ	shift+command+4 カーソルが照準(?)アイコンに変わるので、キャプチャ範囲をドラッグして指定します。
ウィンドウをキャプチャ	shift+command+4の後にspace カーソルが一旦照準(?)アイコンに変わるので、その後にspaceキーを押すとカメラアイコンに変わります。キャプチャしたいウィンドウを選択します。

※いずれも、キャンセルはESCキーです。

アプリケーションにてキャプチャ

Dockにて、
アプリケーション　→　ユーティリティ　→　グラブ.app というソフトがあります。

TextWranglerでバックスラッシュ(\)の入力が出来ない。

MAC環境に移行してから、テキスト編集は基本的にターミナルでvimかGUIではEmacsを利用していました。バックスラッシュの入力は今まで意識していませんでしたが（¥ではなく\と表示されるな〜くらいは認識してました）、TextWranglerを使っての編集で、エスケープとしてのバックスラッシュを入力したつもりでもそのまま文字列として認識されてしまい、あれ？あれれ？という感じです。

TextWranglerで普通のCコードを書いてみます。

printf("test1¥ntest2¥n");

これを実行すると、

line1¥nline2¥n

となっちゃいます。

今まではターミナルでvimを使っていたので気づかなかったのですが、vimでバックスラッシュを入力すると '\' となってます。TextWranglerの場合は '¥' となっちゃいます。
実際に文字コードがどうなっているのかはさておき、見た目的に'\'となっていないとエスケープとして認識してくれないみたいですね。

で、問題はどうやって '\' を入力するかですが、

option + ¥

で '\' の入力が出来ました。
実はこのブログ上でも\を入力するためには同様の操作が必要だったので、TextWranglerに限った話ではなくMAC的には常識？な話だったりして。

追伸
よくよく考えてみたら、キーバインドの設定で変更が可能ですね。
私はGoogle日本語入力システムを使用していますが、ことえりでも一緒だと思います。

これで普通に\と入力できます。
ん？ 今度は、¥と入力するにはどうしたら？？ option + ¥ かと思ったら違いました。
option + y で ¥ と入力できます。うーん、なんかややこしいな。

Bloggerでコードハイライト

Bloggerではデフォルトでコードハイライトの機能が無いので、色々と探していたらgoogle-code-prettifyというのがありました。他にもBlogger Syntax Highlighterというのがある様ですがなぜかうまく動かなかったので、google-code-prettyを使うことにしました。
設定方法はクリボウさんのBLOGを参考にさせていただきました。ありがとうございました。表示イメージとしては以下の様になります。
ちなみに、スマートフォンからは正しく表示されないです。

#import <Foundation/NSObject.h>
@interface Car : NSObject {
        int wight;
        int distance;
        int gas;
}
- (id) init;
- (int) wight;
- (int) gas;
- (int) distance;
- (id) front;
- (id) frontDistance:(int) dt;
- (id) back;
- (id) backDistance:(int) dt;
@end

ちなみにブログ上ではHTMLの編集で以下のように記述する。

<pre class="prettyprint" > something code... </pre>

追伸
どうも、BloggerのCSSが悪さをしているのだとは思うけど、デフォルトの設定で使用すると行間が開きすぎて見た目が宜しく無いな〜と感じ得ていましたが、以下のように直接CSS指定で調度良い行間となりました。

<pre class="prettyprint" style="line-height: 1em;"> something code... </pre>

スマートフォンでBloggerをみる

iPhoneで自分のブログを見た時、当然スマートフォン用に変換されてページが見れるんだろうなと思っていたのですが、普通にPC用ページがそのまま表示されて、かなりアレ？と思いました。なんとなくスマートフォン用に変換とかはBloggerが真っ先に実装してそうなイメージがあったので。
私はBloggerを最近使い始めたので、知らないのは私だけなのかもしれませんが、Blogger in Draft があってDraft版としてはモバイルテンプレート機能が実装されているようでした。
以下に有効にする手順を書いておきます。

Blogger in Draftの有効

1. ダッシュボードを表示する。
2. 一番最下部の「その他コンテンツ」の「ツールとリソース」内に「Blogger in Draft」があります。クリックします。
3. Draft版のダッシュボードになるので、「設定」-「メールとモバイル」に「モバイルテンプレート（ベータ版）があります。

モバイルテンプレート（ベータ版）