スポンサーリンク

ACE合格への学習ノート （１）システムアーキテクチャ （Android技術者認定試験の要点整理）

Android 資格 ライセンス


Androidアプリケーション技術者認定試験・ベーシックの勉強メモ。

今回の範囲は（１）システムアーキテクチャ。

出題範囲の全体像
http://www.oesf.jp/modules/training/i...

（１）システムアーキテクチャ

項目：

  1. システムアーキテクチャ概要
  2. ライセンス形態


学習リソース

Android技術者認定試験「ACE」ドリル（1）：Androidのシステムアーキテクチャ 〜全体像を理解するために〜
http://monoist.atmarkit.co.jp/mn/arti...


Androidアプリケーション技術者認定試験ベーシックの試験対策Wiki
http://wiki.livedoor.jp/ace_study/


「Androidのアーキテクチャ」のまとめ
http://blog.flatlabs.net/20110522_104...


▼Androidメモ▼パッケージとアーキテクチャ要素
http://www.saturn.dti.ne.jp/npaka/and...

書籍・・・
インプレスジャパン，「徹底攻略 Androidアプリケーション技術者認定試験ベーシック」。
その正誤表：

お詫びと訂正：徹底攻略 Androidアプリケーション技術者認定試験ベーシック問題集
http://www.impressjapan.jp/support/af...

（１−１）システムアーキテクチャ概要

構成要素

階層順に：

  • アプリケーション（開発者が作るもの。成果物。マーケットで流通するもの。）
  • アプリケーションフレームワーク（開発者が覚えるべきもの。ミドルウェアをJavaで呼び出すための便利なAPI。Javaで実装されている）
  • 下記の２つ：
    • Androidランタイム（Dalvik VM。アプリの実行環境）
    • ライブラリ（WebKitやSQLiteなどのミドルウェア）
  • Linuxカーネル（2.6。各種ドライバ類を同梱）

これらの全階層を網羅して提供してくれている（＝フルスタック）というのがすごい点。

この階層図の構成要素を答えさせる問題は，試験に頻出。

インサイドAndroid
http://itpro.nikkeibp.co.jp/article/C...

  • Androidのソフトウェアスタックの図

簡略化すると：

  • AP層：AP
  • AP FW層：API
  • ランタイム：VM
  • ライブラリ層：エンジン類
  • カーネル層：ドライバ類
Androidランタイム，Dalvik仮想マシン

特徴：

  • レジスタベース（メモリ上のスタックを介さないので，スタックベースよりも省メモリ）
  • Googleが開発
  • Dalvikバイトコード（dexファイル）を利用
    • .java＞.class＞.dex

Androidの仕組みを知る(2) Android Runtimeとアプリケーション・フレームワーク
http://itpro.nikkeibp.co.jp/article/C...

  • メモリー上にスタックを確保しないのでメモリーのフットプリント（動作に必要なメモリー量）が小さい


Dalvik、Androidのバーチャルマシーンが激しい論議を巻き起こす
http://www.infoq.com/jp/news/2007/11/...


組み込み機器用ソフトウエア向けのJava開発・実行環境として

「J2ME」が存在するにも関らず，

あえてDalvikを作りなおしたというのが面白い点。


アプリケーションごとに，基本的な実行モデルは

  • プロセス
  • 仮想マシン
  • LinuxユーザID

が別。

ユーザIDを共有すると，仮想マシンもプロセスも共有。


ランタイムは，仮想マシンのほかに「コアライブラリ」を含む。

これはJ2SEにほとんど準拠したJava言語のライブラリ。swingなどの一部機能が欠落。純正Javaではない。

「標準ライブラリ」とも。

わかった気になる気になるandroid
http://dev.ariel-networks.com/Members...

  • Androidランタイム 標準ライブラリ
    • 「javaで書かれたandroidのコアライブラリ」

上記サイトには「コアライブラリがJavaで実装されている」とあるが，

それは間違いだろう。

すべてのJava関数をピュアJavaで実装することはできない。（鶏と卵）

例えばソケットを扱うJava関数を実現したい場合，OSのカーネルAPIをコールするような機械語（もしくはバイトコード）が必要だ。


ライブラリ
  • 2Dグラフィックエンジン：SGL
  • 3Dグラフィックエンジン：3D ライブラリ
  • 2D/3Dグラフィックスの統合をサポート：Surface Manager（※「Manager」と名前につくが，しかしアプリケーションフレームワークではない。間違えやすい。）

ミドルウェア達のこと。SQLite，SSLなど。

各種エンジン類。


「ライブラリ」と「コアライブラリ（標準ライブラリ）」の違いに注意。

単に「ライブラリ」といった場合は，ネイティブコードのミドルウェア層のことを指す。

ランタイムまわりの「コアライブラリ」と言った場合，Java言語を動作させるためのJ2SEクラスライブラリもどきのことを指す。


アプリケーションフレームワーク

アプリケーション開発に必要な機能を提供。

  • Activity Manager（アプリケーションのライフサイクルを管理）
  • Window Manager

など。

各種マネージャ。


アプリケーションは、基本的にはライブラリを直接使用するのではなく、
アプリケーションフレームワークを通して利用。

ミドルウェアを便利に利用するためのAPI。


アプリケーションフレームワーク層の存在は，デベロッパにとってありがたい。

ミドルウェアを直接呼び出そうと思ったら，JNIで頑張ってC++のコードを書く必要があるからだ。

でもこの層がJNIをラッピングしてくれるおかげで，ネイティブコードを意識せずに済み，言語はJavaだけで済む。


バージョン
  • Androidのバージョン
  • APIのバージョン

がある。
前者がマイナーバージョンアップ（+0.1）した場合であっても，後者は１ずつ増加する。


（１−２）ライセンス形態

Apache License 2.0

自由に改変して商用化できる。業務用に非常に使いやすい。

適用対象：

  • アプリケーションフレームワーク
  • 標準ライブラリ
  • ランタイム
  • 開発したアプリケーション

コピーレフトの考え方は存在しない。

GNU GPL

改変物の頒布者に対して，改変したソースコードを公開する義務あり。業務に使いにくい。

適用対象：

  • Linuxカーネル部分とそのライブラリ


開発者であれば，LinuxのカーネルのライセンスがGPLになってくれている事に対して感謝すべきだろう。

LinuxがコピーレフトのGPLを採用しているおかげで，その商用改変物であるRedHatディストリビューションも強制的にGPLライセンスとなる。

そしてRedHatは頒布対象者である第三者に対してソースコードの公開義務を自動的に負い，改変を許可せざるを得なくなる。


そのおかげで，

RedHatのクローンであるCentOSやTurboLinuxといった派生物が生まれ，

それらの製品もGPLライセンス下でオープンに公開されることになり，今に至る。


つまり，いま無料のLinuxの定番であるCentOSを利用できるのは，

元をただせばLinuxのカーネルのライセンスがGPLである事のおかげなのである。

記事：オープンソースとレッドハットのメリット
http://www.jp.redhat.com/magazine/jp/...

  • LinuxカーネルがGPLを採用しているため、それを利用しているRed Hat Enterprise Linuxも、もちろんGPL


特集：プログラマよ立ち上がれ！ OSS開発者への道
http://www.catch.jp/oss/oss_license_sd/

  • GPLでは、「派生物も同じライセンスで配布すること」という“コピーレフト”の考え方を適用しています。つまり、GPLのソフトウェアを改変したら、その改変版もGPLで公開する必要があります
BSD License

ライブラリ層の中のC言語の標準ライブラリは，Google独自の「Bionic libc」。

ライセンスはBSD Licenseで，とても緩い。

改変物のソースコードに公開義務がないし，改変物の頒布に際して初期開発者を意識する必要もない。

BSD License（Berkeley Software Distribution License）
http://ja.wikipedia.org/wiki/BSD%E3%8...
著作権表示、ライセンス条文、無保証の旨の三点をドキュメント等に記載さえしておけば、BSDライセンスのソースコードを他のプログラムに組み込み、しかも組み込み後のソースコードを非公開にできるため、再配布時のライセンス条件を制限するGPLに比べ、商用化及び標準規格の制定に利用しやすい


定番の「GNU libc」の利用を避けたのは，ライセンスがLGPLになってしまうのを避けるため。

※GPLとLGPLの主な違いは，

  • プログラムの動的リンクに関する点。動的リンク対象がLGPLであっても，リンク元にはLGPLは適用されない。
  • コピーレフトではない点

GPLやMITやCCなど主要ライセンスの内容と意味のまとめ
http://smkn.xsrv.jp/blog/2009/03/summ...

  • GPLは何代にも渡っても「フリーソフトウェアであり続ける事」を可能にする
  • LGPLはGPLライセンスの制約を若干緩めたもので、主にライブラリやモジュールみたいなものに使用されている


以上のAndroid関連のライセンスをまとめると，下記表のようになる。

ライセンス名 Android中の
適用箇所		 コピーレフト 改変物配布時の
ソース公開義務
Apache
License		 上位層の
大部分		 無し 無し
BSD
License		 Bionic libc 無し 無し
GPL Linux
カーネル		 有り 有り
LGPL Webkit等
（世間の代表は
GNU libc）		 無し 動的リンク
なら無し


補足

関連記事：

Androidアプリケーション技術者認定試験ベーシック(ACE)　資格制度の概要と，合格者に学ぶ学習法
http://language-and-engineering.hatenablog.jp/entry/20110923/p1



　

language_and_engineering 読者になる

広告を非表示にする
スポンサーリンク
スポンサーリンク