2014年6月28日土曜日

Nexus 5 に Android Lを入れてみた

Google I/O 2014において、Androidの次バージョン(バージョンは5.0?)、Android Lが発表されました。せっかくNexus 5を持っているので、Android Lを入れてみました。

入れ方を簡単に説明すると以下のようになります。Fedoraではrootで実行する必要があること、それとNexus 5のデータは全て消えることになりますので、注意してください。
  • AndroidのSDKを入れる。(Fedora20の場合のインストール方法)
  • fastbootモードで起動する。((ボリュームダウンと電源キーを両方押しながら起動する)
  • PCと接続してブートアンロックをする。(コマンドラインで fastboot oem unlockを実行)
  • Android Lのイメージをここからダウンロードして解凍する。
  • 解凍して出来たファイルのflash-all.bat(Windowsの場合)、flash-all.sh(Mac OS, Linuxの場合)を実行する。
上記を行うと、Android Lがインストールされ、再起動します。再起動は結構時間がかかる(測っていないが10分以上?)ので気長に待ちましょう。




Android Lの特徴は以下です。
  • ARTという仕組みで2倍近い高速化
  • 「Material Design」という新しいデザイン
  • 省電力化
それで、使ってみた感想はというと、デザイン面ではここを見るとすごい気がしますが、あまり変わったような感じはしませんでした。アプリのMaterial Design対応がされていないからかもしれません。

高速化に関しても、それほど実感はできませんでした。省電力に関しても色々とさわっているせいでしょうが、それほど感じませんでした。

まだ開発者版プレビューですし、あまり期待しない方がいいのかもしれません。

一応OSの機能である通知、ロック画面、アプリ一覧などは変わっています。通知は2段階引き伸ばしで操作はしやすくなったのですが、バッテリー残量の確認や、通知の一括削除がしにくくなったなど、良し悪しがある感じです。

アプリの方は確認したかぎりではFirefoxが異常終了してしまいます。Dolphin BrowserもJet PackをONにすると異常終了してしまいます。もしかるすとFlash Playerが関連しており、ついにFlash Playerがダメになってしまったのかもしれません。また、QuickPicも異常に速度が遅いです。他にも色々とあるかもしれません。

開発者の人やよほど新しいもの好き以外の人は、急いで入れないほうがいいでしょう。

2014年6月14日土曜日

64bit化の利点 その2

前に64bit化の利点と欠点を書きましたが、その2です。

64bit化の利点として、他にも以下があるとのことでした。
  1. 消費電力が良い
  2. セキュリティが良い
1の消費電力が良いについては、ソースは忘れましたが、64bitの方がコードが最適化されているためだとかなんとかだったような・・・ ドライバの出来にも左右されるようです。Linuxでは、ドライバもソースは同じと思われますので、計測してみました。

 使用したのは以下のTAP-TST5です。


使用したOSはFedora20のLiveUSBで、Core i5-2500Kのデスクトップ機に以下のUSBメモリに入れてOSを起動しました。

OSが起動後、しばらくしてから確認すると32bit版と64bit版の両方とも41ワットでした。

元のソースが分からないですが、ARMの64bit版の話で、Intelの話では無かったかもしれません。また、64bitの方が速度が早く、処理が速く終わるからという話であったかもしれません。

ただし、メモリ使用量はやはり、64bitの方が多いです。freeコマンドで確認したところ、以下のようになっていました。

OSアイドル時消費電力使用メモリ(キャッシュ含む)使用メモリ(キャッシュ除く)
32bit41W1,368,672MB402,600MB
64bit41W1,594,216MB621,040MB

もしかすると、細かくは違うのかもしれませんが、少なくてもデスクトップ機レベルでのアイドル時においては消費電力はあまり変わらないようです。






セキュリティについては、ゴールデンウィークにInternet Explorerの脆弱性が話題になりましたが、64bitであれば対策方法があるとの話がありました。これは、64bit版のWindowsでは、DEP(データ実行防止:データに埋め込まれたプログラムの実行を阻止する)と呼ばれるセキュリティ機能がデフォルトで有効になっているためです。32bit版では設定を行う必要があります。

また、ASLR(アドレス空間配置のランダム化:データやプログラムのメモリに配置される位置をランダム化することで、読み取りや書き換えを困難にする)においても64bitの方がメモリの範囲が広いためによりランダムにしやすく、攻撃しにくいそうです。

特にWindowsを使う人はセキュリティを考えるなら64bit版を使用した方がいいのでしょう。

2014年6月7日土曜日

C/C++を勉強する価値

Appleが新しい言語Swiftを発表しました。既に色々な所で紹介されていますが、C/C++好きな人間からの感想です。

Appleのハードでアプリケーションを作りたかったら、Objective-Cを覚える必要がありました。Objective-Cは面白いプログラミング言語だとは思いますが、欠点も多い言語です。
  • C言語の部分と、オブエジェクト指向言語部分で文法がバラバラ。まさに付け足した感じで見た目が綺麗でない。
  •  特にオブジェクトのメモリ管理が難関。バージョン1では自分で参照カウンタを管理→バージョン2でガベージコレクタ→ARC(std::shared_ptrのようなもの)とコロコロと仕様が変わっている。
  •  メソッド(メンバ関数)やインスタンス変数(メンバ変数)の呼出が直接呼出や関数ポインタ呼出になっておらず、動的言語っぽく関数名の文字列から関数を取得するので遅い。
AndroidはJava言語でプログラミングをするのが一般的ですが、Javaに比べて扱いにくい言語であると思われます。意外に思われるかもしれませんが、 AndroidよりもiOSの方がアプリケーションのクラッシュ率は高いという報告が多いです。たぶん、これはObjective-Cというプログラミング言語のせいなのではないかと私は思っています。
 
これらを解決するための新しい言語がSwiftなのでしょう。Objective-Cに対してC言語のプログラムとソースレベルで混在できないという問題がありますが、それは大したことではないですし、iOSのアプリケーションは作りやすくなるかと思います。これからiOS用のプログラミングをする人にはSwiftを勉強したほうがいいでしょう。


さて、Swiftと言う言語ですが、パッと見た目はfuncやvarやletという予約後からJavascriptに似ていると私は思いました。また関数の返り値の型の指定はC++11っぽいと。しかし、実際にはRustという言語の影響が大きいようです。RustはMozillaによってC++の置き換えを狙って作られた言語で、C++に似た文法を採用しています。実際、Rustの言語仕様を見てみると、fn, letなどかなり似ており、RustからC++っぽい::などを除いたのが、Swiftと言う感じもします。

また、Haskelの利点でも言われていますが、「変数の値の変更がバグを産む」と言われています。C++でもconstキーワードがC言語に比べて重視されているのと似ていますが、letのような値を変えられない変数の定義を主役にするのが、なかなか面白いです。

また、Appleの発表ではObjective-CよりSwiftの方が、作成されたアプリケーションの方が速いとのことです。これは以下が考えられます。
  • id型のようななんでも型を無くして、型を型推論(C++11のautoと同じ)で簡単に型を付けられるようにしたこと。
  • letの値は変更できないことが保証されるため、最適化がしやすい。
  • メソッドの呼出方法が変わった(推測)
C/C++に比べると遅いのかもしれないですが、文法的にはJavascriptのような動的言語っぽく、C/C++やRustに比べてとっつきやすそうで、コンパイルできる言語としてはなかなか良い言語だと思いました。

しかし・・・

結局、AppleのAppleによるAppleのための言語というのが私には引っかかります。これからObjective-Cはどうなっていくのでしょう?APIであるCocoaがObjective-Cベースのため、簡単に消えることはないでしょうが、最終的には消えていくことになるような気がします。

RustもSwiftのように良いプログラミング言語ですが、知名度が低いのは言語を作った所の知名度のためでしょうし、Appleが廃れたときにはSwiftも廃れそうです。

Javaのように言語仕様の著作権を、その作成元のOracleが主張するような世の中では、Swiftが他のプラットフォームに移植されるとも考えにくい気がします。

その点、C/C++は歩みが遅かったり、色々と問題もありますが、ISOに承認されて誰でも使用できるプログラミング言語であることが利点だと思いました。Objective-Cと違い、SwiftはC言語を前提にはしておらず、また良い言語だとは思いますが、まだまだC/C++を勉強する価値はあるのでは無いかと思います。




おまけで同じく発表された3D APIのMetalの話。AMDのMantle、MicrosoftのDirectX12と、今までの3D APIに比べてハードよりの3D APIが話題になっている。今まで使用されていたOpenGLはMantle並にオーバーヘッドが少ないとのことなので、Metalはどこが違うのかと思ったら、Metalは更にハードよりで、PowerVR6に特化しているらしいです。Metalは従来より10倍速いと言っていますが、「ドローコールが」という書き方なので怪しく感じます。ゲーム全体の速度としてどうなるのだろうか?

iOSは画面サイズが固定化されているため、画面サイズの違う端末を作りにくい。iPadでは画面2分割案も出ていましたが、画面サイズが自由なAndroidやWindowsに比べて、かなり難しいでしょう。Appleの環境ではプログラミングもどんどん固定化されていくのでしょうね。

2014年6月1日日曜日

EeePC 901-X に Android-x86-4.4-RC2を入れてみた

前回に引き続き、元、Windows XPのNetbookパソコンであるEeePC 901-Xの活用方法です。

今回はAndroid 4.4(Kitkat)のx86版(普通のパソコン用)をインストールしてみました。Androidは、パソコンやスマホやタブレットなど全てのインターネット端末の中では、シェアNo.1の地位となっています。

そのAndroidが、普通のパソコンで使用することができます。 Windows XPの置き換えには最適かもしれません。


AndroidのLive USBの作成



まずは、AndroidのisoイメージをAndroid-x86のサイトからダウンロードします。2014年5月26日現在は、android-x86-4.4-RC2.isoが最新です。

ダウンロードが終わったら、LinuxやMac OS Xの場合は、ddコマンドでイメージをUSBメモリに書きます。

 $ sudo dd if=android-x86-4.4-RC2.iso of=/dev/sdX

/dev/sdXは、ドライブの番号で、実際は/dev/sdbや/dev/sdcなどです。

 Windowsの場合は、Win32 Disk Imagerを使うと良いと思います。使い方については過去の記事でも書いていますので、参考にしてください。


Android のインストール



Fedora 20の時と同様にUSBメモリからSDカードにインストールしてみます。USBメモリからの起動方法やSDカードからの起動方法はその記事を参照してください。


Live USBから起動をすると、メニューが表示されますが、一番上の「Live CD - Run Android-x86 with installation」を実行すると、インストールせずにAndroid-x86を試すことができます。




「Installation - Install Android-x86 to harddisk 」を選ぶとSDカードにインストールができ、次の画面に進み、インストールする場所を選択します。


「Flash Reader」となっているのがSDカードなので、それを選択します。ここで「FAT32[LBA]」となっているのを確認してください。次にフォーマットを選択します。



ここでは、「Do not format」 を選択してください「ext3」を選んだらSDカードが異常になり、再度SDカードのフォーマットが必要になってしまいました。注意してください。

その他、「boot loader」 はSDカードからの起動の設定と思われますので「Yes」とします。


「/system directory as read-write」に関しては、ディスクのスペースとインストールの時間が遅いとのことですが、気になるほどでは無いので「Yes」とします。



「user data」に関しては、大きいほうが良いと考え、初期値を変更して、最大値としまいた。



これらの設定が終わればインストール完了です。Rebootして、SDカードから起動するようにしてください。




EeePC 901-XでのAndroidの使用感(vs Fedora 20)



画面の動作のスムーズさについては、非常にスムーズです。Nexus 5などに比べても遜色ないスムーズさだと思います。しかし、Antutu Benchmarkでの結果は7660とかなり低いです。


それと動画に関しては、やはり動画再生支援がハードにないため、非常に遅いです。

操作に関しては、マウスカーソルを動かしてのタップと二本指でスクロールができます。ロングプレスとフリック操作はダブルタップ後に長押しや移動操作をすることでできますが、少々むずかしいです。ピンチイン・ピンチアウトは出来ないです。

WiFiは問題なくネットをすることができます。サスペンドは復帰がなぜか遅い問題があります。電源キーで電源を切ることができないので、ステータスメニュー内にあるPOWER OFFで電源を切ります。Fn+F?キーでの音量上下、光量上下もできます。前面カメラや音声入力も問題ありません。

Google Playも使用することができます。Google PlayからGoogle 日本語入力をインストールすると日本語入力も問題なく出来ました。それと、アプリによって画面が縦表示に勝手に変わり、元に戻せなくなるので、画面回転制御などのアプリをインストールすると良いです。

通常のAndroidはARM製CPUであり、x86版でアプリが動作するかが気になりますが、PC Watchでの記事によると「Houdini Binary Translator」 という仕組みで90%のソフトウェアが動くことになっているとのことです。

GPSなど機能が元々ない部分についてはどうしようもないです。その他、いくつか問題があり、Fedora 20に比べて少し不安定な気がしました。
  • アラームが動作しない。
  • アプリケーションリストの画像が表示されない。
  • 前面カメラで撮った画像が表示されない。
  • スリープから復帰しないことがある。
  •  ベンチマークソフト、Quadrant Standard Editionは不正終了してしまう。

個人的な感想ですが、EeePCではタッチパネルがなくフリック操作が難しいことや、Fedora 20では右クリックや中クリックが使え、ブラウザがフル機能で使えることを考えると、ブラウザ中心で使用するとなるとEeePCでは速度が遅くてもFedora 20の方がAndroidより便利かと思いました。

Androidならではのアプリも多いので、使いたいアプリが動くのであれば、EeePCをAndroid機にしてしまうのも良いかと思います。