Embedded Technology 2010に行って来た その１

パシフィコ横浜で12/1〜3まで開催されていたEmbedded Technology 2010へ行ってきました。
１〜２日は会社の出展ブースにて説明員もやっていました。


今年の展示はいろいろな意味であつかったです。
Android関連の展示も去年よりも増えている印象でした。


詳しくは続きから





Embedded Technology 2010は世界最大級の専門技術展＆カンファレンスだそうです。
当日は会社のブースにてAndroidからラジコンを操縦できるデモをひっそりと行っていました。
説明員はほどほどでカンファレンスや展示を見て回りました。


初日にAndroid関連のカンファレンスがあり、事前予約をせず、当日に飛び込みで参加しました。
はじめの５分くらいが聞けませんでしたが、そのときのメモ


推定＋報告

　１６万台出荷／日

　５０種類以上の端末

　なんちゃって込みで１００種類以上

　３０のマニファクチャが出荷

　世界で７８００万台出荷

　５０キャリアがサポート

国内の組み込みソフト産業の現状
　日本の輸出産業の５６．７％の製品に組み込みソフトウェアが含まれている
　世界市場が大きくなるほど日本製品のシェアが下がる傾向がある
　SHARPが日本一のメーカー
　　→世界では１０位くらい？
　ノキアが世界一
　車は世界シェアが伸びるにつれて日本製品のシェアが伸びている
　　→政府が関与しなかった産業は伸びた？



標準化＋差別化
　標準OSを使ってどこで差別化するか
　１４ヶ月の開発期間で日本の携帯電話は作ってる



Androidのモジュールを必要なものだけを引っこ抜いてLight Weight Androidとして作ってる
　→必要なものだけをあとでリンク
　→部品の低コスト化、起動の高速化、
　→Eclipse環境で必要なモジュールが指定できる



ドリアン(EM)の説明
　２．２ベース
　Linaro
　MIDに向けたCTS　ラティス
　３月末にパプリックリリース予定





■Linaro
ARM 小林さん
会社？団体
今年１月に発表


linuxを使う上での問題点
　１、linuxが完成品でない
　２、ディストリのフラグメンテーション
　　　　バージョンが統一されていない
　３、ARM特有　Socにおけるフラグメンテーション
　　　　カーネル、パワーマネージメント、グラフィック、マルチメディア系
　４、ARMに十分に最適化されていない
　　　　Intel向け
　
なぜLinaro?
　オープンソースベースのデバイスが世界中にあふれる
　先ほどの問題を解決する


ビジョン
　SoCメーカーはプラットフォームを含めて展開したい
　それぞれのプラットフォームへの対応を簡単に速くできるようにする


Linaro
　非営利団体（ARMとかがスポンサー）
　Linaroの日本支部はない
　８０人のエンジニア
　　→２０１１年に１００人を目指す
　オープンな組織
　世界中のプロジェクトとコラボレーション
　方針は参加企業やオープンソースコミュニティとで決めていく
　ARMパートナーシップ


ストラトジー
　生態系を構成する
　シリコンパートナー、アップストリーム（コミュニティ）、ダウンストリーム（デストリ）
　最適化をする




エンジニアリング構成
　アラインド
　　→カーネルコンソリでーション
　　　V7への最適化
　　→Toolchain
　　　GCCの最適化
　　電源管理
　　


　プラットフォーム
　　チップへ落とす


　ランディング


開発サイクル
　６ヶ月リリースサイクル
　プラン、実行、リリース、メンテナンス
　メンテナンスも６ヶ月


何をしている？
　複数のエンジニアが働く
　多くの人が必要な事に時間をつかう
　差別化の部分には活動をしない
　カーネル、一部の重要なミドルウェア
　A8,A9,A15をターゲットにする


www.linaro.org




■組み込みソフト　効率的
　@mhidaka
　tech boosterの中の人
　pageview 100,000/month
　増加率　５０％／月
　ユニークユーザ　15,000/month


アプリケーションの目的
　製品の価値向上
　　サービスとかはそのための手段


　機能の向上、パフォーマンス
　　品位を向上させることで製品の価値があがる


アプリ管理ソフト
　ユーザーが求める物を出す
　　→一部不具合があっても出す？
　
組み込みアプリケーションの品位
　リソースが限られる
　　→メモリ、CPU、消費電力、ネットワーク
　効率的に使う事
　　技術の無駄使いをしない


標準化されたミドルウェア
　WebKit OpenGL OpenCore


Java Heap
　DalvikVMで管理（最大24MB)


Native Heap
　NDKなどネイティブ呼び出しはOSで管理


DDMS -> Sysinfoでメモリ使用量がみれる
　概算はわかるが、正確な値が見えない


System Process Zygote(ザイゴート）
　ザイゴートはアプリケーションで共有
　各アプリにヒープは割り当てられるが、ザイゴートにもある


DDMSで表示しているのは共有メモリを利用プロセス全員で割っている


cat /proc?
　


OutOfMemoryKiller
　利用可能メモリが枯渇したとき
　Shread Direty, Provate Dirty カーネル利用分で埋まる
　これがでたら致命的


LowMemoryKiller
　利用可能メモリが減ったとき
　優先順位でキルしていく


DDMSでヒープを確認する
　常に増加していればメモリリーク


Allocation Tracker
　メモリアロケーションを追跡する事ができる
　確保のされ方や使われ方がみれる


メモリリークは計測しないとわからない
　メモリはリークするもの！
　メモリ確保の繰り返しが頻繁なら効率化のポイントになる
　
データを保存する方法
　preference
　シリアライズ
　ファイル
　SQLite
　サーバーサイド


処理のオーバーヘッド
　GDD2010 ティムブレイ　高性能なAndroidアプリを作るには

アプリケーション処理
　１アプリ１スレッド
　　→ごまかしましたw
　
非同期処理
　AsyncTask
　　スレッドの再利用はできない
　　処理の進捗把握が可能


　IntentService
　　サービスとして動作
　　スレッドを再利用できる


パフォーマンス解析
　hierarchyView
　　GUIコンポーネント構成解析


フレームワークのソースから、列挙体や定数を引っ張ってくる


■ブリリアントさん
　@yoshi_rr


　W-SIMをBeagleBoardにつなぐ事ができそうだ


　ビーグルボード１７枚
　焦げたらカレーのにおいw


　オライリー　Android Hacks


　NFC（FeliCa）を利用して病院


　Androidで植物工場をやっている
　AndroidでLEDの制御をしている
　LEDの色で成長がかわる
　クラウドとの連携をしている
　　→app engineかEC2でLEDの制御情報をあげている
　LEDの制御はテレビの裏側のLED制御レベルが必要
　E-11


　FeliCaを追加する場合
　　ハードウェアからアプリケーションまで作る必要がある
　　　→シンビアン等と同じ
　　Androidだから有利だという訳ではない
　　GUIの部分が少しコストが安くなるかな？


　Androidはフレームワークに存在しない箇所を追加する場合はSymbianやBrewと同じ


　端末のシステムバージョンアップ
　　Symbianは一部
　　Androidは全体
　　　→どこがバージョンアップされるのかわからないからやり直し量が多い
　　　　範囲が広く、ペースも速い。メーカ、CPともに想定外の変更がある
　　　　アプリのAPIは標準を守ろうとする


　バージョンアップしないと端末の魅力がなくなると思ってしまう
　Googleはお金をもらってないからしがらみなく自由にバージョンアップしてくる
　バージョンアップすると動作確認が必要になってくる
　
　特許訴訟のリスクがある
　　例）マルチタッチ、ピンチズーム
　　→訴訟対象は端末メーカーにどうぞ


　Android独自の特徴としてメーカーに対しての特許訴訟を訴えられる可能性が高い
　
結論
　動かすだけなら安い
　品質の確保と維持にはお金がかかる
　　→他のプラットフォームでも同じ
　結局はガラパゴスに戻ってくる




　どのような変更が安いのか？どうすればソース変更に振り回されにくくなるのかが今後のノウハウになる
　　→標準化とか？


　Googleの戦略に振り回されないようにする必要がある