○とか□とかをいっぱい描かせる
個数、正確さを評価
ひとまずメモ

NSNetServiceBrowser で didFindService したときに resolve してはいけない や tableView:didSelectRowAtIndexPath: で insertRowsAtIndexPaths や deleteRowsAtIndexPaths をしてはいけない でハマったように iPhone OS では delegate で凝った処理をすると動かないことがある。
そんなときに performSelector ほげほげで遅延呼び出しをするわけだがこれにもいくつか方法があって悩ましい

（１）performSelectorOnMainThread:withObject:waitUntilDone:
動作はセレクタと引数のオブジェクトをメインスレッドのメッセージキューに積んで実行を待つ or ほっといて続けるよってな感じ
メインスレッド実行中に使うのはちょっと憚れる感もあるがリファレンスをつらつら眺めていると「メインスレッドで waitUntilDone に YES で使うと即時実行されるよ」的な記述もあるので想定内と思っていいだろう
内部的にはどんな実装になっているのだろうか。単純に考えれば同期オブジェクトで排他処理をしているキューに積む操作か、まぁそんなにコストはかからなそう。

（２）performSelector:withObject:afterDelay:
動作はセレクタと引数のオブジェクトを afterDelay 後にキューに積むよってな感じ
リファレンスには 0 を指定しても即時実行されずにキューに積まれるよって記述があるが、実際のところ内部的に Timer が使われるのか使われないのかはちとわからない
また実行をキャンセルできるというメリットもあるが有効な局面はほぼ無いと思う

ということでどっちを使うべきかなんだけど自分の好みとしてはやっぱり（１）かな
時間を指定するってのがちょっぴり抵抗があるので
しかしより汎用的なのは（２）でしょうね
別 Run Loop で使ったりも可能なので

こんな感じでまともな結論も出さずにこのエントリーは終わり
読んでるあなた、他にご意見等あれば是非コメントしてくださいな

2000年の WWDC に行ったときのことである
OS X 概要的なセッションの終わり、質疑応答である参加者がこう聞いた

「OS X で機能拡張はサポートしないの？」

答えはノー

Apple のスピーカーはだいたいこんな感じのことを返していた

機能拡張（や類するコントロールパネル）は失敗だった。これらのおかげで本来安定して動作する筈の MacOS が不安定になってしまっている。カーネルエクステンション等のサポートはするがカジュアルな OS ハッキングはサポートしない。

会場では少しだけため息のようなざわめきがあった
私もちょっと残念に思った
しかしまぁ本当に素の MacOS が安定していたかはさておき、このような決定に対してとやかくいう筋合いじゃないのは間違いないと思う

ちなみに件の質問をした人は Aaron や Kaleidoscope の開発者だったような…
ちと記憶が曖昧

図解＆実際の動画で折り紙の折り方を解説

で、コンテンツはどうするの？

なんとかなりそうな気がするけどねぇ、無理か

動画付きならこりゃ売れるぜぇぇぇ

コンテンツはどっから？

糸冬　了

少し前のことなんでびたいち記憶があやふやなんだけど自分の TL に「dealloc で self.hoge = nil と書こうぜ」のような内容のブログ？が流れてた
その場で指摘しようととも思ったんだけど follow, follower でなかった（たぶん）のでひとまずスルーしてた
最近、ちょくちょくブログを書いてるついでにこのことにも触れておこうと思う
予め予告しておくとともすれば物事を行儀で語る老害ウゼーな話になるかもしれない

その元記事を（覚えてる限り）要約する
dealloc を書くときにあるメンバ hoge の後始末を [hoge release] とするよりは self.hoge = nil にしたほうが安全じゃん
@property で assign にしようが retain にしようが途中で変えようが dealloc のコードをいぢらないで済むしね
たしか、こんな内容だ

しかし dealloc はオブジェクトが始末されるときに走るコードなので後始末はなるたけ”シンプル”かつ”他に依存”しないように書くべきだと思う
提唱された self.hoge = nil は実際には”setter メソッドの呼び出し”なので setter で複雑だったり他に依存（他メンバを参照したりとか）するようなコードが書かれているかもしれない
たとえ現状そうでなくても将来書くかもしれないし
もちろん getter, setter は”絶対に自分では記述しない”とかの縛りをいれればこれでも問題ないのかもしれないが

また assign や retain を書き直すケースで安全というところ
私はそんなに Objective-C のコードを書いてるわけでもないので経験不足により不正確な話かもしれないが基本データ型は assign だろうし NSObject 派生のオブジェクトは一部の例外（delegate など）を除いて盲目的に retain にしといたほうが無難じゃなかろうか

前エントリー「ぼくのかんがえた autorelease」の続きのようなもの

メモリが潤沢な場合における autorelease のデメリットについて考えたとき、まぁたいしたことないんでないの？と思ってるってのが前エントリーだったが、それの延長でメモリが十分に少ない場合を想像してみる

○メモリが断片化しやすくて遅くならね？
実際に使用されているメモリ管理のアルゴリズムは調べてないがファーストマッチもしくはそれに似た特性を持ったものだとしとく
メモリの延べ使用量が同程度ならば確保・開放の間隔が広く使用量のピークが高いほうが断片化しやすい。また断片化することにより確保・開放のコストも線形的に増える
てことでこまめに alloc, release する場合に比べて autorelease による遅延 release は確保・開放の間隔が広くなるので”遅くなりやすい”ということがいえる
しかし
・そもそも autorelease は根絶できなくね？
・開放タイミングが揃うことにより断片化しづらくなるよね？
ってな側面もある
なので感覚的には”汚れやすい”けど”ひどく汚れる”までにかかる時間はそんなに変わらなそうって感じかなー
ここでの”ひどく汚れる”は空き領域としては十分にある筈なのにメモリ不足に陥る状態ぐらいに捉えてもらって

余談だがその昔 proxy サーバのようなものに別途メモリ管理機構を組み込んだことがあった
空き領域を一方向の線形リストで持ちファーストマッチで返す簡単なやつで（ここから記憶があやふや）32バイトアライン、不足したら1MBづつ追加するような機構で鬼のようなテキスト処理と DNS などのオンメモリキャッシュを扱ったが2MB程で事足りてたんじゃなかったっけな

閑話休題

なもんで私は「autorelease は遅い」って話から autorelease を闇雲に使わないようにするのはどうなの？って思っちょります
alloc, release は短いスコープの中に限るとか結構気を使わないとリークや多重解放を起こしてしまうリスクもあるし
しかしながら autorelease マンセー！なのもちょっと
メモリ消費の激しいオブジェクトを扱うとか凝った処理をするループの内側とかはあえて alloc, release にするとか、ループの内側の場合は少なくとも AutoreleasePool で挟んどくとか気を使ったほうがいいと思う

ここんとこ autorelease は遅いという話を目にするようになってちろっと調べたんだけどリクツについての記述が見つからない。そんな tweet をしたところいくつか反応があって情報交換はできた。結果としては残念ながらしっくりきていないんだけどそもそも自分がどう理解してるかってのも140文字のやりとりのなかでは説明が難しかったのでここに書いておこうと思う

ちなみに私は自分の書いたコードを見られるのは性癖を知られるくらい恥ずかしく感じるタイプで今までソースの公開※とかしたことがない
今回はソースのような体裁をとるがプログラマ同士ならば自分の拙い日本語よりもより正確に通じるだろうという判断、つか願い

※業務上どうしても同僚に見られてしまうが身内には自分のケツの穴だって晒せるくらい心を許すのでほぼ問題ない。また最近は自己研鑽のためにも全世界にケツの穴を晒してこうって覚悟もちらほら

以下、私の理解していることの説明ってことで間違いの指摘などは大歓迎だが”そうなんだ”などと鵜呑みにすることのなきよう、くれぐれも

まずは autorelease を多用すればメモリ使用量のピークが上がるということについて
ピークが上がれば Memory Warning が起こるもしくは頻発する　→　View Controller にぶらさがった View や自分の責任下でパージするオブジェクト等が棄てられる　→　パージしたものが必要になったらまた再構築　→　以下ループ

こんなん繰り返したらそら遅いわなって話は”共通理解”としておいておいて release に比べて autorelease を使う場合のコスト増がいかほどかってことに的を絞る。言い換えればメモリがふんだんにある環境下でどうなの？ってことだ

んで retain, release, autorelease や AutoreleasePool が中でなにやってるかなんだけどソースがあるわけでもないので想像してみるしかない。その結果をコードとして書き下ろした

まずは「ぼくのかんがえた NSObject のようなもの」
参照カウント式のオブジェクト管理についてのみ記述してある

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

//--------------------------------------------------
// MyObject.h
 
@interface MyObject {
	int		_retainCount;
}
 
@property (assign) int retainCount;
 
- (id)init;
- (id)retain;
- (id)autorelease;
- (void)release;
 
@end
 
 
//--------------------------------------------------
// MyObject.m
 
@implementation MyObject
 
@synthesize retainCount = _retainCount;
 
- (id)init {
	_retainCount++;
	return self;
}
 
- (id)retain {
	self.retainCount++;
	return self;
}
 
- (id)autorelease {
	[MyAutoreleasePool addObject:self];
	return self;
}
 
- (void)release {
	if (--self.retainCount <= 0) {
		[self dealloc];
	}
}
 
@end

次に「ぼくのかんがえた NSAutoreleasePool のようなもの」
autorelease されるオブジェクトの管理と一応ネスト可能なように記述してある

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

//--------------------------------------------------
// MyAutoreleasePool.h
 
@interface MyAutoreleasePool : MyObject {
	MyAutoreleasePool* _savedPool;
	id*		_objectPool;
	int		_objectCount;
}
 
@property (assign) MyAutoreleasePool* savedPool;
@property (assign) id* objectPool;
@property (assign) int objectCount;
 
+ (void)addObject:(id)object;
- (id)init;
- (void)dealloc;
- (void)addObject:(id)object;
 
@end
 
 
//--------------------------------------------------
// MyAutoreleasePool.m
 
static MyAutoreleasePool* sharedAutoreleasePool = nil;
 
@implementation MyAutoreleasePool
 
@synthesize savedPool = _savedPool;
@synthesize objectPool = _objectPool;
@synthesize objectCount = _objectCount;
 
+ (void)addObject:(id)object {
	[sharedAutoreleasePool addObject:object];
}
 
- (id)init {
	if (self = [super init]) {
		_objectPool = (id*)メモリ確保(sizeof(id) * MAX_POOL);
		_objectCount = 0;
 
		_savedPool = sharedAutoreleasePool;
		sharedAutoreleasePool = self;
	}
 
	return self;
}
 
- (void)dealloc {
	sharedAutoreleasePool = _savedPool;
 
	for (int i = 0; i < _objectCount; i++) {
		[_objectPool[i] release];
	}
	メモリ解放(_objectPool);
}
 
- (void)addObject:(id)object {
	if (self.objectCount < MAX_POOL) {
		self.objectPool[self.objectCount++] = object;
	} else {
		//どうすんべ？
		// ふつーに考えて realloc とかかな
	}
}
 
@end

以上、かなりシンプルなコードだが狙って単純化してるわけではなく（エラー処理はまったく考慮していないが）知ってる機能を満足するよう想像してみたらこんなかんじに帰結しただけ

で利用する場合を考えると release に比べて autorelease で増えるコストは

・AutoreleasePool オブジェクト生成・破棄のコスト（けっこう小）
　※自前で AutoreleasePool を用意した場合
・プール登録のコスト（極小）
・プール登録個数回ループ（かなり小）
　※ループ中の release は相殺

以上、とても”体感できるようなコスト増”には繋がらないだろうと思ってる
てな感じ

ちなみに autorelease 後、てけとーなオブジェクトで retain しておくと”イベントループの度に”参照されて遅いという話がありました
私は上述のコードのように想像しているのでこの話が腑に落ちず悶々としている、みたいなー

［追記］
・return self; が抜けまくってるので追加した
・init, dealloc 以外でメンバの直接参照している箇所を self. に修正
・ちなみにこのことを考え始めるきっかけとなったエントリ
　autorelease は遅いか速いか

つっても DL して粛々と作業しただけ
現時点では stable の Android-x86 1.6 live & installation usb image がお勧めか

○材料
・Eee PC（対象機種はリンク先を参照）
　※うちのマシン（1002HA）は列挙されてないけど特に問題はなさげ
・起動用 USB メモリとか SD とか

○調理
・イメージを起動用 USB とかに書き込み
・起動してインストールを選択
・ブートローダは環境にあわせてどぞー
　※別パーティションに ubuntu が入ってたのでパスした。んだっけかな？

でだ
OpenWnn が入ってないようなので一からビルドすべくソースを取りに行ったあたりで年末年始
年が明けてみると OpenWnn は動かない情報もちらほら
そんな中、chekela さんがビルドした OpenWnn x86 ライブラリを組み込んだ adamrocker さんの Simeji が公開されているのを発見！ありがたくちょうだいいたしました

・参考リンクから Simeji をインストール
　※予め ubuntu + chrome で落としておいた apk からはインストールできんかった。理由不明

○動作状況
・無線LANおっけー
・スリープおっけー
　※スリープ後、無線LANあうち？
・日本語入力おっけー
・二本指スクロールはうれしいがタップは切りたい。設定不明

○参考リンク
・Android-x86 – Porting Android to x86
・x86で動くSimeji
・Android x86をVMware Fusionにインストール

○謝辞
adamrocker さん、chekela さん、ありがとうございました

今どき昆虫採集なんてしないのかもしれんが

僕夏とかどうぶつの森風のノリで昆虫（植物、etc.）図鑑を”自分で”完成させるようなアプリ
説明を元にこれか？って写真を撮っていくのね
実際の写真と照らし合わせて答え合わせができるといいかな
iPhone より DSi のが向いてるかな、まいいか