Essential Symbian Os Peformance Tips (japanese)

性能に関するヒント

販売の確実化 業界支援プログラムである Symbian Signed（アプリケー ション認証）を通じて、Symbian OS のソフトウェア開 発者はアプリケーションのデジタル署名を取得すること ができます。 Symbian Signed の認定を受けるために、アプリケーショ ンは様々な標準テストを通過しなければなりません。オ レンジ、ノキア、ソニーエリクソンをはじめとするネッ トワークオペレータや携帯電話メーカーの中には、チャ ネルを通じて販売する C++ および AppForge MobileVB/ Crossfire アプリケーションには認証が必要であると定め ている企業もあります。 Symbian Signed で認証されたアプリケーションは、 「application source untrusted（アプリケーションの出所 が信頼できない）」の警告メッセージなしに実行され、 ビジネスアプリケーションカタログへの掲載が可能で す 。 ま た 、 ISV は 認 証 を 受 け た ア プ リ ケ ー シ ョ ン に 「for Symbian OS」のロゴを使用することができます。

Symbian Signed の詳細は、www.symbiansigned.com をご覧ください。

性能に関するヒント

from

性能に関するヒント Essential Symbian OS シリーズより抜粋 1st edition, 12/06 発行元： Symbian Software Limited 2-6 Boundary Row Southwark London SE1 8HP UK（英国） www.symbian.com 商標、著作権、免責条項 Symbian、Symbian OS および関連する Symbian 商標は、すべて Symbian Software Ltd の商標です。Symbian は、本書に記載されたサードパーティ の商標権を承認しています。© Copyright Symbian Software Ltd 2006 All rights reserved. 本書のいかなる部分も Symbian Software Ltd の書面によ る明示的な許可なしに複写することは禁じられています。Symbian Software Ltd は、本書に記載された情報の適切性・正確性を保証するもの ではありません。本書の記載情報は一般情報としてのみ提供されたもの であり、その他の目的で使用および依存されるべきものではありません。

編集： Andrew Langstaff

デザイナー： James Mentz

編集責任者： Freddie Gjertsen Satu McNabb

校閲者： Mel Pullen Alon Or-Bach Krzysztof Bliszczak

デザイン顧問： Annabel Cooke

日本語版校閲者： 小西一弘

はじめに ネットワーク帯域が拡大の一途をたどり、それを活用す る様々な機能が次々に開発されている現在、スマート フォンソフトウェアにそれに対応するスループットと処 理能力の要求がこれまでになく高くなっています。これ らの性能に対する厳しい要求を満足するためには、効率 を最大限に追求するソフトウェア構築が不可欠です。 「サイクル単位」の性能が要求されない場合でも、簡単な 留意点に注意を払うことにより効率の高いコードを作成 することができます。

目次 性能とは？ .......................................................................... 1 性能の重要性 ...................................................................... 1 性能キラー .......................................................................... 1 コードが多すぎ、データが不十分 .................................... 2 ループ内のコードの繰り返し ........................................... 3 非効率的なヒープの使用 ............................................ 6 ライブラリに対する理解の不足 ........................................ 7 強制型変換 .......................................................................... 8 非効率的なファイルの使用 .............................................. 11 設計パターンの不適切な使用 .......................................... 14 汎用的で「将来が保証された」コード ........................... 15 エミュレータ上での開発とテスト................................... 17 開発者、コンパイラおよびコード................................... 18 その他のヒント................................................................. 19 ツール：サンプリング プロファイラ.............................. 20

1

性能とは？ 性能とは、ブート時間、ROM サイズ、RAM 使用領域、 画像表示やバッテリー保持時間など、デバイスが示す 測定可能な特性を示します。デバイスの使われ方や機 能によって、それぞれの特性に対する要求値が決定さ れ、ソフトウェアは、これらの要求を満足するように 設計・実装されなければなりません。

性能の重要性 高い性能が求められる場合の標準的ソリューションは、 CPU の高速化やキャッシングのための RAM 割り当ての 拡大です。しかし、携帯電話がバッテリーで駆動され るデバイスであること、コストの制限が大きいことを 考慮すると、これらのソリューションは現実的とは言 えません。

性能 キラー スマートフォンにおける性能の問題の多くは、より細 かな問題に分類することができます。本書では、これ らの問題についてそれぞれ検証します。

2

コードが多すぎ、データが不十分 開発段階において、アプリケーションの多くは動作に 影響を与えるようなパラメータを使用します。通常、 パラメータはファイルに保存され、起動時に読み込ま れ処理されます。 問題は、要求の最終決定やデフォルト値の設定により、 コンフィグレーションが静的になる場合に発生します。 パラメータのハードコード化は、しばしばアプリケー ションの要因分析を再度行う必要があることを意味し ます。 void { // // // // }

SomeCode(void) Open file New ReadStream Read some data members into a struct Close file, etc.

また、データ構造をビルド時にヒープ上に作成する場 合にも問題が発生します。 void ConstructL(void) { TFuncTable *fns = new (ELeave) TFuncTable; fns->iFunc1 = ExampleFunc1; fns->iFunc2 = ExampleFunc2; fns->iFunc3 = ExampleFunc3; iFuncTable = fns; }

3

この例においては、初期化された TfuncTable の const コピーを持つか、それをポイントする iFuncTable を持 つか、さらにもっとよいのは、iFuncTable の代わりに const バージョンを使用することです。 このような問題は明らかではなく、しばしば、インタ フェースクラスのかたちをとる関数テーブルを持つな ど、隠れている場合が多くあります。 場合によっては、分かりやすい C++ のコードとしてプ ログラミングの意図を表現することが困難な場合もあり ます。ファイルから読み込まれるデータ構造がサブ構造 を含む場合などは、理解が容易な const struct また は const class 宣言として表現することが難しくなり ます。 さらに、人が読める形式のデータファイルをコンパイ ル可能な C++ コードに変換する「生成コード」ソ リューションを開発者が選択する場合もあります。

ループ内のコードの繰り返し ComplexType の構成に伴って、しばしば、余分な計算が 発生します。 以下の例を参照してください。 ExampleClass::SimpleOperation(SimpleType a, SimpleType b) {

4

//creation of a complex type – this is //unnecessary, see text ComplexType c = b.MakeComplex(); // some other code } CExampleClass::DoSomeComplexComputation(...) { SimpleType a,b; while(moreToDo) { //some code SimpleOperation(a, b); // some other code that does not change //variable b } }

ここでは、ループ内で SimpleOperation()メソッド が呼び出され、ループが実行される度に、SimpleType タイプから同じ ComplexType が生成されます。しかし、 それらは、以降のコードで更新されていません。この不 要な ComplexType の繰り返しの生成によって、リソー スが浪費され、性能に深刻な影響を及ぼすことが考えら れます。ComplexType を SimpleOperation()に渡 すことによって、繰り返し生成されることを避けること ができます。

5

ExampleClass::SimpleOperation(SimpleType a, ComplexType &b) { // some code } ExampleClass::DoSomeComplexComputation(...) { SimpleType a; ComplexType b; //create b as a complex type //from outset while(moreToDo) { //pass b as a ComplexType instead of a //SimpleType SimpleOperation(a, b); //some code } }

このように、実行回数の多いループ内では計算や処理 の繰り返しを行わない配慮が必要です。

6

非効率的なヒープの使用 組み込みシステムにおいては、スタックの代わりに ヒープが頻繁に使用されます。スタック領域は通常一 時変数に使用されるため、過度のヒープ呼び出しを招 きがちなので注意が必要です。 void LoopWithHeap(void) { while(moreToDo) { CData *temp = new CData; GetData(temp); ProcessData(temp); delete temp; } }

できる限り、一時変数は再使用するようにしてください。 void LoopWithHeap(void) { CData *temp = new CData; while(moreToDo) { GetData(temp); ProcessData(temp); temp->Reset();

7

} delete temp; }

この他の例では、処理対象のデータ量に対して細かす ぎるセグメントデータ構造を使用することによっても 問題が発生しています。 また、realloc の過度の使用によっても非効率的な ヒープ使用が発生します。alloc、free および memcpy 呼び出しを使用し、十分な考慮を欠いた設計を行うと、 ヒープのセルサイズの増大を招きます。

ライブラリに対する理解の不足 通常 API のドキュメントには、実装時の注意まで詳しく 述べられていません。API に対する理解が十分でないま ま、または誤った理解に基づいてコーディングを行 なった場合、不必要あるいは重複した処理やデータの 変換を起こしやすくなります。 以下は、配列にアクセスし、SetElement メソッドで 境界チェックを行うクラスの例です。 void ArrayClass::SetSize(int aSize) { iMaxLength = aSize; }

8

void ArrayClass::SetElement(int aPos, unsigned char aChar) { if(aPos >= 0 && aPos < iMaxLength) { iRawArray[aPos] = aChar; } }

以下は、上記のクラスを使用するプログラムです。配列 に複数のエレメントを追加しています。 void ExampleClass::FillArray() { //some code myArray.SetSize(bytesToProcess); for(currentPos = 0; currentPos < bytesToProcess; currentPos++) { myArray.SetElement(currentPos, aByte); } }

呼び出し関数は、配列の上限が既に設定されたループ 内にあるため、SetElement による境界チェックは不 必要であり非効率です。

9

これには以下をはじめとする多くの原因が考えられま す。ExampleClass の開発者が ArrayClass による境 界チェックを認識していなかったこと、あるいは、 ArrayClass により適切な API が他に存在する可能性 を考慮しなかったこと、または、そのような API を提供 しなかった、ArrayClass の開発者が、そのクラスが そのような形で使用されることを想定していなかった ことなどです。

強制型変換 データ設計が不適切である場合、データタイプ変換の ために不要なプロセッサ時間が費やされます。これら の変換はしばしば静的なもののみであり、通常はデー タを外部 API に引き渡すために行われます。 下記は不適切なデータ変換の例です。 TInt intDrive; TChar ch = ((*drives)[i])[0]; RFs::CharToDrive(ch,intDrive); TDriveUnit curDrive(intDrive);

ここでは、TdriveUnit タイプを使用していますが、 TdriveUnit に格納されているのはドライブ名の文字 列であり、データを利用可能な形式に変換するために 3 回の処理が必要となっています。

10

実行回数の多いループでこの関数が呼び出されると仮 定すると、関数実行のプロセッサ時間の大半がこの変 換処理に費やされることになります。この例の場合は、 ドライブ名を後で直接使用できるよう、TdriveUnit をドライブ名とともに、あるいはドライブ名の代わり に格納することによって不必要な処理を回避すること ができます。 同様のコーディングによって、特定のデータオブジェ クトにそのインタフェースを変換するだけの目的で、 スタック上にダミーのデータオブジェクトが作成され てしまう場合があります。 以下の例を参照してください。メソッドの呼び出し時 にオブジェクトの作成が行われています。 iDllEntry.iName.Des().Zero(); iDllEntry.iName.Des().Append(aPath.Drive()); iDllEntry.iName.Des().Append(KSysBin); iDllEntry.iName.Des().Append(*resourceName); iDllEntry.iName.Des().Append(KDllExtension);

この例は 2 つの問題を表しています。 第 1 の問題は、結果が容易にローカルに格納され再利 用できるにもかかわらず、Des()の呼び出しにより行 われる強制型変換は一時的なオブジェクトを生成し、 しかも、このインスタンス内で 5 回もこの処理が行わ れていることです。

11

TPtr des = iDllEntry.iName.Des(); des.Zero(); des.Append(aPath.Drive()); des.Append(KSysBin); des.Append(*resourceName); des.Append(KDllExtension);

さらに、前述の問題ほど明白ではありませんが、コン パイラのオプションによっても不具合が発生していま す。Des()はインラインを想定して実装されています。 しかし、コンパイラはコードサイズを最適化するよう に指定されているため、関数が頻繁に呼び出されるに 従い、コンパイラはインライン修飾子を強要しないと 判断するようになります。

非効率的なファイルの使用 このカテゴリーでは多くの問題を取り扱います。それ らのうちのいくつかはファイルの誤った使用ばかりで はなく、RAM にアクセスするのと同等の速度を提供し ないより広範囲のすべてのデータソース、例えば、 ハードウェアやネットワークといったソース、にも適 応します。 ファイルシステムの非効率な使用は、ソフトウェアが、 ファイルシステムをデータベースのように使う（そこ では、ディレクトリ構造とファイル名のフォーマット がデータベースの構成を定義するのに使われる）場合 に発生することがあります。

12

他の問題が、ファイルや他のソースからブロック単位 で、しかも、連続的にデータを読み込んで処理する 「同期的」設計が原因となって起きることがあります。 これはブロック全体のデータが読み込まれるのを待つ ためにデータの処理が止まることを意味します。 以下の例で、複数のファイルから細かくデータを読み 込むことによる他の一般的な問題について述べます。 EXPORT_C CColorList* ColorUtils::CreateSystemColorListLC(RFs& aFs) { … CDirectFileStore* store; store=CDirectFileStore::OpenL(aFs, KGulColorSchemeFileName,EFileRead| EFileShareReadersOnly)); … RStoreReadStream stream; stream.OpenL(*store,store->Root())); … CColorList* colorList=CColorList::NewLC(); stream>>*colorList; return colorList; }

13

問題は、オーバーロードされた C++ >> オペレータの実装 に隠れています。呼び出されている InternalizeL 関 数の一部を以下に示します。 aStream>>card; const TInt count(card); TRgb rgb; for (TInt ii=0;ii>rgb; iEikColors->AppendL(rgb); }

それぞれの組込みクラスについて、さらにオーバーロー ドされた >> オペレータが呼び出されています。プログ ラムの論理を追うことで、関数はメモリ上に 32 ビット ブロックの構造を作成し、それぞれのブロックについて ファイルからの新規読み込みが発生していることがわか ります。ファイルサーバーにファイルの先読みキャッ シュがあったとしても、各読み込みの関数呼び出しの深 さは性能上の問題を引き起こします。 以下は、前述の問題を考慮したコーディング例です。 aStream>>card; const TInt count(card); aStream->ReadL(iEikColors, count * sizeof(TRgb));

これにより実行時間は高速化しますが、TRgb の内部 フォーマットが変化しないように配慮が必要です。

14

設計パターンの不適切な使用 設計パターンは、ソフトウェアの問題を既知のクラスに 分類する有用な手段です。これらの問題に対して、実績 ある共通のソリューションを適用することは容易です。 しかし、設計パターンの使用を、実際に問題を通して考 えることや設計ソリューションを引き出すことの代わり とされるべきではありません。 一旦ある特定の設計パターンが選択されたとしても、別 の問題が発生する場合もあります。設計パターンは通常 完全なオブジェクト指向の用語で記述される実装をさし ます。そのようなオブジェクト指向の抽象化は必ずしも 常に適切であるとは限りません。やみくもに既定ソ リューションを適用して、性能の弊害やコードの複雑化 を招くことも少なくありません。 以下の例を参照してください。ここでは、State パターン を活用しています。ステートマシーンを初期化するため、 開発者は Factory パターンを使用することに決めました。 CL2CAPStateFactory* CL2CAPStateFactory::NewL() { CL2CAPStateFactory* factory= new (ELeave) CL2CAPStateFactory(); CleanupStack::PushL(factory); // Create all the new states factory->iStates[EError] = new (ELeave) TL2CAPStateError(*factory);

15

factory->iStates[EClosed] = new (ELeave) TL2CAPStateClosed(*factory); factory->iStates[EListening] = new (ELeave) TL2CAPStateListening(*factory); // etc... CleanupStack::Pop(); return factory; }

しかし、このクラスとそれに含まれる State クラスの使 用をより詳細に検証すると、各 State が実行する Factory の参照は、ステートの切り替えのみに使用されており、 State パターンが別の方法で実装された場合には、複合 的な構成やそれに依存する Factory パターンの使用は不 要であることを意味します。

汎用的で「将来が保証された」コード このカテゴリーの問題はフレームワークやプラグイン に頼りすぎることによって起きます。また、ソフト ウェアの性能より開発の容易さを優先することが原因 となる場合もあります。 「.ini」ファイルに構成パラメータを格納するアプリケー ションを想定してください。開発段階においては、こ れらのパラメータが頻繁に変更され、編集し易い フォームであることは理解できます。しかし、これら が一旦静的になったとき、ファイルのロードや解析の ためのオーバーヘッドが性能への弊害となります。

16

「フレームワークとプラグイン」のアプローチは Symbian OS の設計の要ですが、これがしばしば不適切 に使用されているのも事実です。 フレームワークの使用は、プラグインをスキャンする ための管理コードが必要であるためのコードサイズ、 利用できるプラグインの変更確認、プラグイン DLL の ロードとリンク、ある特定のプラグインを選択するた めのコードといったオーバーヘッドが生じます。また、 フレームワークは一般的に、使用されているプラグイ ンに対して内部的にリクエストを転送する共通のクラ イアントインターフェースを提供するので、このオー バーヘッドが性能への弊害となります。 実行時における動的柔軟性が必要とされる場合は、こ れらは、すべて容認できる代償項目です。しかし、使 用するプラグインがソフトウェアの実行において静的 でありすぎると判断される場合は、これらの代償は容 認できなくなります。 将来が保証されたコーディングも重要ですが、技術が 間違ってあるいは不適切に適用される場合は、コード サイズや性能に弊害が生じます。

17

エミュレータ上での開発とテスト 開発ツールとして提供される Symbian OS のエミュレー タを使用してコード作成から動作させるまでのサイク ルを短縮することができます。また、エミュレータを 使用することで、高価なハードウェアツールを使用し ないで実行時のデバッグが可能です。 エミュレータは貴重な機能を提供しますが、特に出荷 期日のプレッシャーが迫る時、実機テストを忘れがち となります。実機テストを、リリース前にコードが ハードウェア上で動作することの検証や機能確認のみ にとどめるケースもしばしば見られます。これは、実 機上でのコード動作に関する理解不足につながり、直 接、性能問題の原因とはならない場合でも、開発の最 終段階や製品出荷後まで問題が見落とされることがし ばしば見られます。 このことは、顧客には、開発者が十分なテストを怠り、 適切な品質管理を行っていないと見えてしまいます。 さらには、大きなアーキテクチャの変更を行う余裕が なくなるため、すべての可能な改善の機会を少なくし てしまいます。

18

開発者、コンパイラおよびコード システムやプログラム言語を知ることと同様に、使用 するコンパイラの基本を理解することも重要です。 多くの最近のコンパイラには、小さなプログラムサイ ズ、あるいは高速な実行速度というように、望ましい 質のコード一式を生成するよう、様々な最適化フェー ズが含まれています。それらからどのようなフェーズ が選択され、コンパイラの生成コードにどのような影 響を及ぼすか理解することが重要です。 また、ある特定のコンパイラが提供する機能がすべて のコンパイラで使用できるとは限らないことにも注意 してください。

コンパイラの動きを知った上でのコーディング コンパイラを良く知り、ソースからどのようなコード が生成されるかを理解してください。杓子定規のコー ドを書かないでください。コンパイラの生成コードが、 ある特定の状況において最も効率が高いものであると は限らないからです。

アセンブラについて少しは知っておく アセンブラは、多くのソフトウェア開発者から「黒魔 術」として敬遠されがちです。しかし、ある特定のプ ラットフォーム上でどのようにコードが走るのか正確 に知るのに、アセンブラを理解することは大変役に立 ちます。

19

その他のヒント 本書で前述した「性能キラー」以外にも、コードを書 く際に留意すべき様々なことがあります。これらの多 くは常識的なものであり、通常、「コーディング標準」 として公表されています。その中から幾つか重要と考 えられるものを以下に述べます。

ループ内呼び出しの戻り値の格納 ループ内の条件ステートメントでの関数呼び出しは行 わないでください。各繰り返しの後、戻り値が変化し ない限り、関数の戻り値をローカル変数に保存するよ うにしてください。

必要なところにレファレンスおよびポインタを使用 パラメータのレファレンス渡しは通常使用されるよい 方法ですが、読み込み専用の整数タイプにレファレン スを渡さないでください。

ループを展開しない 最近のコンパイラでは、このような最適化は不要であ り、むしろ非生産的です。コンパイラは、必要に応じ てこの最適化を実行します。

長い if...else のチェーンを使用しない より効果的に実装される switch ステートメントを使用 するようにしてください。条件が文字列などのように 整数定数ではない場合は、switch を使用する前にルック アップ テーブルの使用を検討してください。

20

const 修飾子の適切な使用 読み取り専用変数を const として宣言すると、コンパ イラはよりよい効率のコードを生成します。

ツール：サンプリング プロファイラ このセクションは、ライセンシーの試作機やあるレベ ルの SDK にアクセス可能な開発者やレファレンスボー ドを使用している開発者を対象としています。 サンプリングプロファイラは、デバイス上のソフトウェ ア動作に関する大まかな統計的な見解を提供するツール です。このツールは、1 ミリ秒単位でスレッド ID および 現在のプログラムカウンタ値のログを記録します。また、 このデータを PC 上で分析するために使用されるコマン ドラインベースのプログラムも付いています。 この情報は性能の問題を解析したり、ありそうなボト ルネックのコードを見極めるのに利用できます。

ROM のビルド プロファイラを使用するには、同ツールを ROM に追加 する必要があります。これは buildrom コマンドライン に「profiler.iby」を追加することにより可能です。 buildrom h4hrp techview profiler.iby

プロファイラの起動 最も簡単な方法は eshell からプロファイラを制御します。 コマンドラインは以下の通りです。 start profiler start

21 <Shift> キーコンビネーションを使って他 のタスクへ切り替えることができるように、このコマ ンドはプロファイラ アプリケーションが走る他のス レッドをスタートさせます。

プロファイル対象コードの実行 この時点でプロファイラは起動され、サンプル収集を 開始します。解析されるコードを実行する前に少々待 つことで、示されるさまざまな量の処理を視覚的に分 割することにより、スレッドアクティビィティ分析 フェーズを助けることができます。

プロファイラの終了 必要なものをプロファイルした後に eshell に切り替え、 以下のコマンドでプロファイラを終了します。 profiler stop

それから、以下のコマンドによってプロファイラの データ ファイルをクローズします。 profiler unload

プロファイル データの取り出し レファレンスボードの C ドライブのルート ディレクト リに profiler.dat という名前のファイルがあるはずです。 このファイルを MMC カードにコピーして、分析のため ビルド マシンに転送します。

アクティビティ毎のデータを分析 プロファイルを行ったソフトウェアのアクティビティ の全体像を捕らえることができるグラフを生成するた

22 め、Excel で表示されるのに適した形式へデータを変換 しなければなりません。

プロファイル ファイルのコピー 名前を取り出すためのシンボルテーブルを作成するた め、プロファイルファイルを ROM フォルダーにコピー します。以下のコマンドで、アクティビティのフォー マット ファイルを作成します。 analyse –r h4hrp_001.techview.symbol profiler.dat -v –mx > profile.xls

アクティビティグラフの作成 Excel で profile.xls を開きます。スレッド名をグラフに表 示するために、データの最初の 6 行を削除します。これ らは概要データであり、これらの行があるとグラフが正 しく表示されません。同様に、最初の行のタイムスタン プもグラフ表示の邪魔になりますが、これらは、興味の あるグラフの部分と実際の時間をクロスレファレンスす るのに必要であり、削除することはできません。 必要なデータを選択し、「チャートウィザード」をク リックします。これにより 4 つのステージウィザード が開かれます。 • チャートタイプから ‘Area’、サブタイプから ‘Stacked’ を選択し、‘Next’ を選択します。 • 最初の列にタイムスタンプを表示しないようにエリア を調整します。‘A’ を ‘B’ に変更します。たとえば、 =profile!$A$2:$V$941 を =profile!$B$2:$V$941 に変更して、‘Next’ を選択し ます。

23 • 次のペーンを無視して ‘Next’ をクリックし、‘As new sheet’ を選択した後に ‘Finish’ をクリックします。

アクティブ セクションとスレッドの選択 生成されたグラフを使って、興味のある部分について プログラムが何をいつ行っていたのか分析することが できます。 マウスをデータエリアに移動すると、その時点で実行 されていたスレッドがポップアップウィンドウに表示 されます。それから、データシートの同じ行の最初の カラムの値を見てタイムスタンプを見つけるためにポ イントの列番号を使用することができます。さらに、 必要のない行を削除することもできます。Excel は行番 号の振り直しを行うため、最後の範囲から削除するよ うに気をつけてください。更新データに基づいてグラ フが再描画されます。

関数によるリストを作成 タイムスタンプの範囲とその間実行されたスレッドが 一旦分かれば、アクティビティの順に関数のリストを 作成することができます。 たとえば、EFile スレッドの 51300 から 76900 のタイム スタンプの範囲で呼び出された関数を表示したい場合 は、以下のコマンドを使用します。 analyse –r h4hrp_001.techview.symbol profiler.dat -bf –p –s51300-76900 –t EFile* > analysis.txt

24 • サンプル範囲を指定する際は、-s の後や 2 つの数値 の間や 2 つの数値を分けるハイフンの間にスペース を入れない。 • サンプル範囲には、アクティビティグラフを生成す るのに使用されたデータシートの最初のカラムのタ イムスタンプを指定する。 • スレッド名を指定する際は、-t の後にスペースを入 れる。名前の最初および最後の部分にワイルドカー ドを指定することができる。 出力ファイルを Notepad などのテキストエディタで開 き、指定されたタイムスタンプの範囲の中で実行され た関数のリストを見ることができます。通常、最初の 5 つ程度の関数が注目されるものです。次に、IDE に移 動し、関連するコード部分を調べます。

25

開発者リソース Symbian Developer Network http://developer.symbian.com

Symbian Developer Network Newsletter http://developer.symbian.com/main/getstarted/newsletterarchive

Symbian OS Tools Providers http://developer.symbian.com/main/tools

Sony Ericsson Developer World http://developer.sonyericsson.com

Forum Nokia http://forum.nokia.com

Sun Microsystems Developer Services http://developer.java.sun.com

開発者アンケート （所要時間 5 分） Symbian は、弊社の開発者サポートに関する皆様のご意 見を伺いたいと考えております。 皆様のご意見は、サポートプログラムの改善に活用さ せて頂く所存です。 弊社の活動にご意見を反映させたいとお考えの皆様は、 ぜひ下記サイトにアクセスしてアンケートにご協力く ださい。抽選で Symbian Press 発行のシリーズ書籍を差 し上げます。

http://developer.symbian.com

より発行

Symbian OS プラットフォーム セキュリティ Symbian OS のセキュリティモデル や Symbian Signed など、Symbian イニシアチブの詳細を解説。ライセ ンス保持者から ISV まで開発者必読 の啓蒙書。

Symbian OS リアルタイムカーネルプログラミング 現在、注目度 No.1 のスマートフォ ン オペレーティングシステムの最 新リアルタイムカーネルを解説。 Symbian OS のドライバーやサービ スの開発、カーネル移植、発売前の 携帯電話 OS 分析に携わる技術者に とって、Symbian OS のカーネル細 部を理解するために必読の書。 Symbian Press: www.symbian.com/books

より発行

Symbian OS C++ 開発者向け書籍： Developing Software for Symbian OS（英語版） Steve Babin 著 Symbian OS C++ for Mobile Phones – Volume 2（英語版） Richard Harrison 著 Accredited Symbian Developer Primer（英語版） Jo Stitchbury 著

翔泳社刊行の日本語版書籍： Symbian OS C++ プログラミング Richard Harrison 著 Symbian OS C++ 実践開発技法 Jo Stichbury 著

より発行

企業および IT 技術者向け： Rapid Mobile Enterprise Development for Symbian OS（英語版） Ewan Spence 著

Symbian OS プロジェクト管理者向け： Symbian for Software Leaders（英語版） David Wood 著

コネクティビティ アプリケーション開発者向け： Programming PC Connectivity Applications for Symbian OS （英語版） Ian McDowall 著

Java 開発者向け： Programming Java 2 Micro Edition for Symbian OS（英語版） Martin de Jode 著

より発行

発行書籍 Coding tips（英語版）/ コーディング技法（日本語版） Signing tips（英語版） Getting started（英語版） Essential UIQ – Getting Started（英語版）

翻訳書籍 （Getting started、中国語） （Coding Tips、中国語） （Performance Tips、中国語） UIQ

（Essential UIQ – Getting Started、中国語）

コーディング技法 性能に関するヒント Essential Symbian OS

コーディング技法

性能に関するヒント コード

測定

分析

改善

すべての開発者に必須。性能の問題の一般的原 因を洗い出し、開発環境で解決するための有用 なアドバイスならびに、最も効果的な方法でソ フトウェアを設計するヒントも提供。 性能に関するヒントは、Essential Symbian OS シリーズの一部であり、Symbian OS 開発者に とって参照しやすい形式で情報をまとめたもの です。

Symbian Press Symbian Press は、Symbian OS および関連技術 に関する実際的で信頼できる情報をタイムリー に提供することを目的として数々の書籍を発行 しています。Symbian Press に関する情報は、 www.symbian.com/books をご覧ください。