2017年05月30日

「Androidを支える技術U」を読んで その4

 今回で最後になります。

 第一巻、二巻を通じて、素人の私でもAndroidの凄さ、素晴らしさが少しは理解できたかと思います。

 このような素晴らしい書籍を発行された著者に改めて感謝いたしますm(__)m

4.管理者がいなくても動き続けるシステム

 私が最初に触ったAndroidの端末はサムスンのGalaxy Sでした。この端末は、よくハングして、ひとりでに再起動する不安定な端末でした。ですが、著作を読むと、この再起動は、どうしようもなくなった時に停止することなく再起動するようになっていた訳で、それはそれでよくできたシステムだったのかしれないなと、今は思います。

 最後は、そんなシステムを、著作に従って、電源投入の開始時点から見ていきます。

 まず、以前書きましたが、Androidは一般に言われているようにセキュリティが甘いシステムではありません。著作によれば、Android のブートローダーは通常、端末メーカーのみが知る秘密鍵で署名されているシステムイメージだけをロードします。署名されていないシステムイメージはロードをしません。このようにしてシステムイメージに悪意のあるファイルをこっそり追加したりするのを防いでいます。こうしてルートパーティションやRAMディスクなどは署名されたものと同じであることが保証され、後から変なウイルスなどがこっそり入り込むことができなくなっています。ハードウェアとソフトウェアが独立している PC などでは実現しづらい仕組みだそうです。

 次に、今までに見てきたように、Androidは、勝手にプロセスをkillしていきます。そのため、重要なシステムがkillされることもあるかと思いますが、それでも最近の端末はハングすることなく、ずっと電源を入れたままでも、安定して動いてくれています。

 著書を読んでみると、その背景が理解できます。いや、理解できたつもりかも(^_^;)

 再起動が自動で行われることで、万―OOMKiller(Out Of Memory Killer)などである程度重要なサービスがkillされてしまっても、自動的に再起動されてシステム全体としてはメンテナンスフリーで安定して動き続けます。

 さらに詳細な説明があります。私の頭では半分も理解できませんでしたが、雰囲気で見てください(^_^;)

 異常終了すると通信用のソケットが残ってしまって再帰動時にソケットの作成に失敗してうまく起動しなくなるというのは、出来の悪いデーモンにはありがちなことです。 Android では init が正しく後処理をしてくれるのでそういった心配は必要ありません。各サービスがどのようなソケットを作っているかという情報がすべてinit.rc に記述されているため、あるプロセスが異常終了したときもそのプロセスが持っていたソケットをinitプロセスが正確に把握しているため、正しく後処理を行います。サービスは、oneshotの指定がない限り、異常終了した場合などでも自動的に再起動されます。この機能を実現するためには、そのサービスが使用しているソケットや、そのサービスが再起動する時に一緒に再起動をしなくてはならないサービスの情報などが必要となります。 それぞれのデーモンが自分勝手にソケットなどを管理していると、そのうちの1つがうまく再起動に対応していないだけで全体としてモジュール郡の再起動ができないシステムとなってしまいます。 Android では再起動の時などに問題になりがちなソケットの管理をinitが行うことでこうした出来の悪いサービスができる可能性を減らしているわけです。

 なんか、凄いという気持ちになってくるでしょう?

 結果として、このようにして管理者のいない携帯電話というシステムを家電的に使うことができるわけです。

 …ということで、最近のAndroid端末は、昔に比べると安定してきたなぁとしみじみ思いました。


posted by 【なかま】 at 10:44 | Comment(0) | android

2017年05月10日

iアプリを支えたかった技術 その1

1.iアプリで使われていた邪道な技術

 先日、「Androidを支える技術」の感想を書いたところですが、その昔、私がiアプリを開発し公開していた頃、私なりに…というか、野良iアプリ(ドコモの公式サイト以外で配布されていたアプリをこのように言いました。)開発者の間では、それなりの邪道な技術がありました。

  当時のiアプリは、セキュリティが大変厳しく、データ保存などはもってのほか、着信履歴や電話帳の取得なども今のandroidで許されることは、ほとんどできませんでした。特にデータ通信に関しては、自分のアプリをダウンロードして来たサイトにしか接続できないようになっており、そのためか、iアプリを対象としたウィルスは、一部存在していたようですが、ほとんど聞きませんでした。

 そのため、野良アプリ開発者の間では、どうにかしてこれらの制限を回避する方法が、ひたすら探求されていた訳です。

 そこで、今回は、もう誰も振り返らないこれらの技術ですが、「Androidを支える技術」に張り合って(張り合えないって(^_^;))、自分の記憶として書き留めておきたいと思います。

2.画像ファイルを利用したデータ保存

 iアプリにとって、データ保存の方法が正式に存在しないというのは、かなり致命的でした。個人のデータを蓄積するスケジューラアプリなどは、こつこつと書き溜めておいた数カ月の予定が、アプリの不具合や、誤ったアンインストールによって一瞬にして消滅してしまいます。私も何度かデータを失い、バックアップが取れていたらなぁと悔しい思いをした経験があります。

 当時のiアプリがその外部に書き出しを許されていたのは、画像の保存だけでした。カメラアプリでは撮影したデータを保存することができていました。

 そこで、当時の野良アプリ開発者は、ここに目を付けることとなります。

 当時許されていた画像の種類は、GIFとJPGでした。

 GIF画像のフォーマットを研究してみると、そこには、コメントブロックという、画像を作成したアプリ名とか作成時間やカメラの絞りの値とかの情報を書き込めるところがあるのに気が付きます。これを利用できないかと思いました。

 そこで、画像エディタを使い、手始めに1ピクセルのGIF画像を作成してみました。次にこれを byte の配列としてiアプリの内部に保持し、このコメントブロックの位置にそのままiアプリのデータをテキストで書き込んでみました。当初はうまくいきましたが、データが大きくなるにつれ、GIF画像が壊れて作成できなくなりました。

 ここで、GIFの公式ドキュメントをよく見てみました。GIFのコメントブロックのフォーマットは、先頭1バイトが長さ、後に続く1〜255バイトがデータで、最大長255バイトとなっています。つまり、大きなデータは256バイト単位に分割する必要があることがわかりました。

 理屈はわかりましたので、この正式なGIFフォーマットにそってデータを作成し、このコメントブロックにおさめてやればiアプリからGIF画像として書き出すことで、iアプリのデータが外部媒体に保存できるようになりました。

 しかし、当時は、やはり機種によっては正式フォーマットに従っていてもGIF画像作成に失敗することがありました。機種によってはiアプリからGIF画像に書き出すときに、余計なことに、折角書き込んだコメントブロックにカメラの絞りなどの撮影状況を書き込んでしまうものがあったのです。これはどうしようもありませんでした。

 そこで、もうひとつ許されていたJPGは利用できないものかと思いました。これも公式ドキュメントを読んでコメントブロックに書き込もうとしたのですが、野良アプリ作成の先駆者達の情報を探してみると、単に1ピクセルとして作ったJPG画像の後に、テキストデータを付け足すと保存可能とのことでしたので、やってみるとうまくいきました。

 ですので、当時は、あちこちの友人からドコモのガラケーを預かっていろいろとテストしてみました。その結果、GIFが利用できる機種とJPGが利用できる機種、両方利用できる機種があることが判明しました。そこで、iアプリの中では、機種毎に条件分岐して画像の種類を振り分ける方法をとった訳です。

 実は、この機種毎のテストこそ、大変な時間と労力がかかりました。

 今は懐かしい、古き良き時代の話でした(^^)

今も持っているテスト用のガラケー

garakei_list.png
続きを読む
posted by 【なかま】 at 15:15 | Comment(0) | android

2017年05月06日

40インチ4KディスプレイでのAndroidStudio

 さて、わたくしこと、この度40インチのディスプレイを購入しました(^^)/すべてはandroid開発のためです。

 プロの方ならばなんていうこともないでしょうが、サンデープログラマの私としては、今まではLG電子の27インチだったものですから、晴れて2画面となりました!(^^)!

 全体像は以下のとおりです。

AllDisp.png

1. 機種名など

・40インチディスプレイ
 I-O DATA モニター ディスプレイ LCD-M4K401XVB 40型 (4K対応/60Hz/リモコン付/5年保証)です。アマゾンで、¥ 62,585 でした。

 使用感

 画面の表示はきれいだと思います。クロムブラウザのスムーススクロールも非常になめらかです。

 気になるのは、起動時には、2つ繋いでいる画面の27インチのデスクトップがまず表示され、続いて40インチのデスクトップが表示されるのですが、約5秒ほど間隔があきます。これは、まあ、ビデオカードのせいかもしれませんが。

 また、このディスプレイは子画面を表示する機能があって、リモコンで操作するのですが、その切替時には、約5秒から7秒程度画面が真っ暗になり、その後表示されます。

 それから、大きさはかなり大きい(幅91センチ×高さ56センチ(台座含む))ので、その重さのため設置には苦労するかなと思いましたが、一人でも大丈夫でした。ただ、一人で、最初台座をディスプレイに固定するには、倒してディスプレイを壊さないかと、ちょっとひやひやしながらの作業でした。

 また、台座のアームの幅が約52センチあります。私は机が狭いので、台座がはみ出してしまい、しかたなく、書籍を敷いて凌いでいます(^_^;)しかし、地震とか考えると、なんらかの対策を考えないといけないと思います。

・ビデオカード
 玄人志向 ビデオカードGEFORCE GTX 1050搭載 GF-GTX1050-2GB/OC/SF です。アマゾンで、¥ 12,690  でした。この4Kディスプレイには、さすがにマザーボード内蔵のビデオカードでは対応できなかったので。

・トラックボール
 ついでに、部屋と机が狭いので、マウスをやめてトラックボールにしました。LOGICOOL ワイヤレストラックボール M570t です。アマゾンで、¥ 4,463 でした。

 使用感

 アマゾンで一番評判の良いトラックボールということで購入しましたが、なかなか思う位置にカーソルを移動させるのに苦労しています。カーソルの移動速度を最低にして、加速を最高にしてみるとちょっとはかわったようですが、なかなか慣れません。私の作業机の狭さには最適なのでしょうが。

 それから、贅沢な悩みですが、40インチ画面では画面が広すぎて、すぐにマウスカーソルを見失ってしまいます(^_^;)そこで、Windowsを使い始めて、初めてマウスカーソルに軌跡を付けてみました。さらにコントールキーを叩くと、カーソル位置を示す円形の波紋が広がるようにしてみました。これで随分と見失わなくなったようです(^_^;)

 それから、トラックボールを使い始めて、改めてWindowsや各種アプリのショートカットキーでの操作を多用するようになりました。やはり、キーボードからの処理の方が速い部分もありますね。

2. 画面の設定
 解像度は 3840×2160 ですが、これをそのまま表示するとあまりにも文字が小さくなるので、WIN10のカスタムスケーリングを160% にしています。

3. AndroidStudioの状況
 これらの2つのディスプレイに、Android Studioを表示すると壮観ですね。

  右に表示している27インチ画面(1920x1080)
RightWindow.png

 右には、今までの27インチにAndroidStudio本体から分離したAndroid Monitor とエミュレーターを表示。

  左に表示している40インチ画面(3840x2160)
AndroidStudio.png

 左の40インチにAndroid Studioです。画面を3分割して、左から
  • プロジェクト
  • ブックマーク
  • エディタ
  • 検索結果
となっています。

 参考までm(__)m
posted by 【なかま】 at 00:35 | Comment(0) | android