32bitとか64bitとか何なのよって話

ども、
実家に帰省して母から
「いいもの食べさせてあげる」
と出されたお菓子が、半年前に自分が持って帰ったお土産だった東野です。

先日メーカーのHTCがAndroid初となる64bitのスマートフォン端末を発表しました。
しかし注意書きでこんな記述があります。

現行のAndroid OS(バージョン4.4、コードネーム:KitKat)は64bitをサポートしないが、
今秋公開とみられる次期Android(コードネーム:L)は64bit ABIsもサポートし、
Javaで作成されたアプリは、特別な変更をすることなく64ビットアーキテクチャで動作する。

長々と書かれていますが、要約すると
OSをAndroid4.4からAndroid Lにバージョンアップした時にアプリがJava以外のプログラミング言語で書かれていると、動作の保証は出来ませんよ
という事です。

Android : Java
iOS : Objective-C
Windows Phone : C#++

上記のように各スマートフォンOSのアプリを作る言語はマニュアルで定められていますが、
現在様々な中間ソフトがあり、それらを使う事でJavascriptやHTML5といった他の言語を使ってスマートフォンアプリを作る事が可能です。
しかしそれらを使って作られたアプリは動かないかもしれないのです。
誤動作の理由はいろいろあると思いますが、今回はその中の1つをご紹介したいと思います。

変数を定義する際、型を宣言しますよね。
利用したい数値によって型が異なり、それに利用されるメモリも異なりますが、
char型:1バイト
short型:2バイト
などです。

みんなの大好きなint型は何バイトなの???
long型は?
int型、long型はアプリを作成するマシンやアプリを動かすマシンのスペックによって2バイトであったり、4バイトであったりします。
例)
size

結果、例えば
・64bitマシンで作られたアプリを32bit環境で動かす
・64bitマシンで作られたアプリを32bitマシンで作られたアプリと通信する
などの場合、双方で同じ変数の型で作り方を統一していても、
片方が2バイト、片方が4バイトとして動作が異なるので、それが誤動作の原因になります。

32bit⇔64bit間でのやりとりは必ずサイズのマッピングをしなければなりません、面倒ですよね。

現在でも32bitマシンと64bitマシンの両方が存在してしまっているのは
いろんなメーカーやOSの開発の歴史のせいだとひとくくりに言ってよいです。

しかしちゃんとメリットも存在します。
それは処理速度です。
「4バイトのメモリを確保しろ」
と命令するより
「long型で使えるメモリを確保しろ」
と命令する方が、
結果サイズが4バイトになろうが8バイトになろうが、
そのマシンの得意な方法でメモリを確保しにいくので処理が速いのです。
その処理速度の差は微々たるものかもしれませんが、
システムの最も深い層で1秒間に何万回も何億回も呼び出される事を考えれば、アプリケーション層でその差がどうなるかは分かりますよね。
と、今回はアプリケーションを動かす根っこの方のお話でした。
アプリケーションを製作する時、知識として頭の片隅に置いておいて下さい。
そして僕の事は心の片隅に…

コメントを残す

メールアドレスが公開されることはありません。