iOS / Androidモバイルデバイスへのコードの移植

あなたにとって何がより魅力的だと思いますか：新しい興味深いタスクに直面し、重要なアルゴリズムを開発するか、ある言語から別の言語に既存のロジックを書き換えて、特定のAPIの奇妙な機能と戦いますか？ 私は約8年間モバイル開発に携わっており、ためらうことなく最初のオプションを選択していますが、APIと戦うことも好きです。 私に同意するが、最初の問題に対処し、2番目の問題を最小化する方法をまだ知らない人は、猫の下を見るのは面白いでしょう。



この記事では、移植の一般原則に関する私の考えを共有します。 AndroidまたはiOS用のアプリケーションの特定のソフトウェア実装のジャングルには入りません。 アプリケーションをさまざまなデバイスに簡単に転送し、クロスプラットフォームと呼ばれるようにする方法を説明しようと思います。

アクションプラン

最初に、タスクの範囲を定義します。 この記事では、組み込みシステムについては触れません。組み込みシステムは、間違いなくモバイルテクノロジーの利益のためにも機能します。 最新のモバイルデバイスである電話とタブレットのみを検討します。 記事の最初の部分は、現代のモバイルプロセッサのアーキテクチャと制限、そして逆に、モバイル開発者がそれらから受け取る機能について説明します。 第二部では、移植可能なコードを書くために必要ないくつかの基本的なトリックについてお話します。

CPU

5年前、それほど前ではないが、独自のアーキテクチャを備えたモバイルプロセッサを製造するさまざまな企業がありました。 ただし、メインアーキテクチャは片手で数えることができるため、まだ余裕があります。 まず、ARMです。 それに加えて、通常Java NDKに含まれているMIPSと、Atomを備えたIntelがあります。



後で説明するすべての方法は、これらすべてのシステムに適用できます。 しかし、便宜上、最も一般的なARMプロセッサの例でそれらを検討します。 それらについて何を知る必要がありますか？

• 商業的観点から： コアライセンス 。 ライセンスを購入して、独自のプロセッサを作成できます。
• 技術的な観点から：システムオンチップ（System On Chip） 。 すべてのモジュールは1か所で組み立てられます。
• ソフトウェア開発者の観点から：強力なRISCアーキテクチャ

免許

ARM自体はプロセッサをリリースせず、リリースライセンスを販売し、さまざまな企業（Samsung、LG、Broadcom、Apple、Qualcomm、Freescale）がライセンスを購入して、シングルコアまたはマルチコアのプロセッサのバージョンを好きなようにリリースします。

ライセンスを与えるものは何ですか？ カーネルを取得するだけでなく、プロセッサを作成します。 あなたはそれを改良することができます：改善するか、逆に単純化します-これはあなたの権利です。 物語の例は、 XScaleプロセッサを搭載した有名なIntel です 。 彼らはv5TEのライセンスを購入し、真剣に作り直しました。 私の意見では、これは既存の処理の中でこれまでで最も成功したものです。 彼らはメモリを使った作業を改善し、キャッシュを増やし、そしてv5TEに基づいたIntelとSamsungの実装を比較すると、Intelはおそらく2倍勝ちました。 このプロセッサの主な機能は、40ビットバッテリを搭載したコプロセッサが初めて登場したことで、1クロックで4つの数値を乗算できるようになり、古いプロセッサには強力なSIMD命令セットを提供するワイヤレスMMXコプロセッサが搭載されました

システムオンチップ

エンジニアの観点から見ると、システムオンチップとは何ですか？ これは、さまざまなデバイスがインストールされている小さなマイクロプロセッサです。 ARMからライセンスを購入し、そこに1つ、2つ-必要なカーネルの数を入力します。 追加のコプロセッサ（グラフィック、DSPなど）、メモリ（ROM、フラッシュなど）さらに、必要に応じて、通常はI / Oインターフェイスがイーサネット、USB、COMポートに挿入されます。 このすべてを機能させるために、オシレーターとタイマーが同じクリスタルに追加され、ボード上の個々のブロックの追加のストラップが出ないようにします。



ARMでは、同じPentiumと比較してトランジスタの数が非常に少ないため、システムをチップに実装することが可能になりました。 このため、チップ上のスペースをほとんど占有せず、技術的には開発者がそこに望むものすべてに適合することが判明しました。 これらのすべてのユニットをCore i5に適合させることはできそうにありません-それ自体が大きく、大きなラジエーターを使用している場合でも（多くのトランジスタがあり、すべてが非常に熱くなるため）。

RISCアーキテクチャ

開発者にとって重要なアーキテクチャ機能を検討してください。

• まず、 ロード/ストアアーキテクチャです。 すべての操作は、レジスタを使用して実行されます。ロード済み-カウント済み-アップロード済み、その他はありません。 メモリ内のオペランドを使用して演算を実行することはできません。
• レジスタを確実に使用するために、カーネルには大きなレジスタファイルがあります（32ビットの16レジスタ） 。 それらは原則として同等です。 もちろん、目的を暗示しているように見える特殊な名前を持つものもありますが、任意のレジスタに関連するすべての操作にアクセスできます。
• 固定コマンド長 。 ARMモードでは、これは通常32ビットです：1コマンド-1ワード、次々。 何も変わらず、すべてが予測可能であるため、コンベアは確かにこの事実に満足しています。
• ARMの機能の1つは、メモリオフセットにアクセスするだけでなく、プリインクリメント、レジスタ内のオフセット付きポストインクリメント、または直接数値形式でメモリから読み込み、ロードする機能です。 強力なアドレス指定チーム-ARMの最も重要な機能の1つ
• すべての操作は1ビートで完了する傾向があります。 多かれ少なかれ-これらは異なるコアのニュアンスです。
• ARMのもう1つの優れた機能は、 条件付き実行です。 命令（算術演算、または単にフラグをチェックする）を作成するとき、フラグはまだあり、次の操作は条件が満たされた場合にのみ実行されます。 したがって、大規模な移行を行う必要はありません。 これは非常に便利です。生産性を向上させながら、コンベアをリセットしません。
• クイックシフト。 ARMでは、シフト付きの算術演算を実行できます。+ =（j << 2）; 1つのコマンドに変換され、1つのサイクルで実行されます。

ARMファミリー

ARMファミリの開発と進歩：

• ARM9がベースと見なされます。 これは過去のものですが、使用されていますが、最新の携帯電話では使用されていません。
• ARM9EはまだAndroidに含まれているため、これを考慮する必要があります。 ARM9Eは、音声処理アルゴリズムを大幅に高速化するDSP命令を導入しました。
• ARM10コアはほとんど気付かれませんでした。
• ARM11に基づいてさまざまなデバイスが登場しましたが、最初のiPhoneは最も象徴的なデバイスでした。 ここでの革新は、XScaleのIntelのワイヤレスMMXよりも弱いものの、SIMD命令の出現でした。
• Cortexは、これまでで最も一般的なコアです。 マルチコアCortex A9システムでもシングルコアCortex A8システムでもかまいませんが、アーキテクチャは同じで、ARMv7です。 ここで、ARMはNEONと呼ばれる小さな革命を起こしました。 これは、ARMv7アーキテクチャに含まれていますが、チップ上にない場合がある独立したコプロセッサです。 NEONの機能は、並列の加算、減算、シフト、および飽和を提供する64ビットおよび128ビットのコマンドの存在です。 ARMが本格的なSIMDを備えているのはここにあり、デジタル信号を処理するときに高速化を実現します。
• ARMは、「明るい未来」、つまりARMv8アーキテクチャを備えた64ビットCortex-A50コアを発表しました。 これらは、以前の個別の32ビットモードでのすべてとの完全な互換性を約束します。

親指

前の段落の表の最後の行について個別に説明します。 親指とは何ですか？ これは元々、パッケージ化されたARM命令のセットでした。 コードの速度とコンパクトさの間で2番目を選択する場合、機能が制限された短い16ビット命令が優れたソリューションです。



Thumb2は、Thumbの進化版です。 ARM命令の一部が含まれており、Thumbのようにコード密度を確保し、同時に本格的なARMのパフォーマンスを維持するように設計された16ビットおよび32ビットの命令のセットで構成されています。

クロスプラットフォーム

私は自由にクロスプラットフォームを定義します：「クロスプラットフォームコードは、別のシステムに転送するコストが、このコードをゼロから書くコストよりはるかに少ないコードと考えることができます。」 つまり、「ある種のアルゴリズムがあり、iOSでも同じことをしたいので、このプラットフォームでも同じことをしなければならない」という状況を移植することはしません。 これは移植ではなく、書き直しです。 アルゴリズムを移植するには、クロスプラットフォームの条件を満たす必要があります。



クロスプラットフォームコードを記述する原則を「分離と統合」と定義します。 私はそれが何であるかを説明しようとします。 これらの点は仮定ではなく、これが私のビジョンです。

1. まず、 統一された型付け -組み込みのネイティブ型はプラットフォームによって異なる可能性があるため、単一型でコードを記述することが重要です
2. コードのアルゴリズム部分と非アルゴリズム部分への分離。 アルゴリズムはシステムコールと基本操作を取得します
3. ハードウェア依存部分 ：プログラムをアルゴリズム部分（数学）とシステムに依存する部分に分割します

各項目について詳しく見ていきましょう。

シングルタイピング

#if defined(_MSC_VER) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed __int64 int64_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned __int64 uint64_t; #elif defined(LINUX_ARM) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed long long int64_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned long long uint64_t; #else #include <stdint.h> #endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

単一の類型化とはどういう意味ですか？ タイプを定義するだけです。 上記の例では、stdintについて説明しています。 MicrosoftコンパイラーおよびLinux用に定義されています。 さらに制御したい場合は、「my_love_int8」、「my_love_int16」と記述し、プログラムでこれらのタイプを使用できます。 これは、たとえば、ネットワークで作業する場合に非常に役立ちます。持っているすべてのパケットがint16であり、それらの間の距離が0であり、オフセットが他の何もないことを常に確信しています。 結局のところ、突然2バイトになるcharを介してすべてを定義すると、すべてがどこか間違った方向に進みます。

 struct NetworkStatistics { uint16_t currentBufferSize; uint16_t preferredBufferSize; uint16_t currentPacketLossRate; uint16_t currentDiscardRate; uint16_t currentExpandRate; uint16_t currentPreemptiveRate; uint16_t currentAccelerateRate; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、プラットフォーム/コンパイラ/言語のバージョンに依存するコードの読み書きを簡素化するために、独自の統一定義を導入することは非常に便利です。 など：

 #if defined(__APPLE__) # ifdef TARGET_OS_IPHONE # define MAILRU_OS_IOS # elif defined(TARGET_IPHONE_SIMULATOR) # define MAILRU_OS_IOS # define MAILRU_OS_IOS_SIMULATOR # elif defined(TARGET_OS_MAC) || defined (__OSX__) # define MAILRU_OS_MACOSX # else # define MAILRU_OS_MACOSX # endif #elif defined(_WIN64) # define MAILRU_OS_WIN64 # define MAILRU_OS_WINDOWS #elif _WIN32 # define MAILRU_OS_WIN32 # define MAILRU_OS_WINDOWS #elif ANDROID # define MAILRU_OS_ANDROID #else # error Unsupported OS target! #endif #if defined(_M_X64) || defined(__x86_64__) # define MAILRU_ARCH_X86_FAMILY # define MAILRU_ARCH_64_BIT #elif defined(__ARMEL__) || defined(__arm) || defined(_M_ARM_FP) # define MAILRU_ARCH_ARM_FAMILY # define MAILRU_ARCH_32_BIT #elif defined(__ppc__) # define MAILRU_ARCH_PPC_FAMILY # define MAILRU_ARCH_32_BIT #else # error Please add support for your architecture in typedefs.h #endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アルゴリズム

私の練習では、音声コーデックやビデオコーデックなど、多くの重いアルゴリズムがありました。 移植を容易にするために、アルゴリズムがシステム関数を使用しないことが望ましく、システムライブラリをまったく使用しないことがさらに望ましいです。

システムコール

移植可能なマネージコードを記述するための基本原則の1つは、アルゴリズム内でmallocを使用しないことです。 アルゴリズムは必要なメモリ量を決定し、この値をメモリマネージャに渡します。メモリマネージャは初期化中にメモリを既に割り当て、割り当てられたピースへのリンクを提供します。 アルゴリズムはこの部分を使用します。 幸福と調和。

 // Interface int32 MyAlgorithm_GetMemSizeNeed() int32 MyAlgorithm_Init(void *memory) void *MyAlgorithm_Destroy() // Using { void *m = MyManager_GetMem(MyAlgorithm_GetMemSizeNeed()); MyAlgorithm_init(m); //... m = MyAlgorithm_Destroy(); MyManager_FreeMem(m); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アルゴリズムがメモリ自体を割り当てるとどうなりますか？ プロセスを頻繁に作成および強制終了し、さらに多くのアルゴリズムがある場合、メモリのランダムな割り当てと解放が開始され、メモリの断片化が始まります。 これにより、空きメモリの合計量が必要量を超えた場合でも、ある時点で必要な量のメモリを割り当てることができなくなるという事実につながります。 RAMは、特にモバイルデバイスでは、依然としてかなり高価なリソースです。

同じ原則により、他のシステム機能を区別することが望ましい。

基本操作

基本操作とは、Cにはないが頻繁に使用する非特定操作の割り当てを意味します。



単純なCLZ操作（先頭のゼロをカウント）を検討してください。 Cにはこのような操作はありません。必要に応じて、ゼロをカウントするアルゴリズムを作成できます。 トリックは、一部のプロセッサ、特にARMで、ハードウェアレベルで実装されることです。 これらの場合、私たちは持っているものを冷静に使用します。 このため、コンパイラには組み込み関数が含まれている場合があります。 コンパイラがこのような関数を実装していない場合（この例のように、GCCの実装）、アセンブラー操作を配置できます。 この操作が実装されていないプロセッサの場合、別個のコードを記述する必要があります。 ただし、これは基本的な操作です。 それはどうですか？ 基本操作を1回作成し、コードで呼び出します。移植する必要がある場合は、単体テストを作成し、この操作を移植し、単体テストで結果を確認します。 すべてが問題なければ、使用するコードも問題ありません。

不測の事態

基本的な操作を強調する必要性を示すために、一見単純な例、int64のシフトを示します。 原則として、このコマンドはCで記述されていますが、標準のintではなくint64であるため、さまざまな方法で実装できます。 異なるシステムのInt64は異なる方法で呼び出されますが、それほど悪くはありません。 最大の問題は、さまざまな方法で実行できることです。

例：uint64 >> n

 uint64_t LogicalShiftRigth(uint64_t number, int shift) { return number >> shift; } uint64_t test = 0x1234567812345678; uint64_t res63 = LogicalShiftRigth(test, 63); uint64_t res64 = LogicalShiftRigth(test, 64);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

論理右シフトと呼ばれる基本操作を検討してください。 63と64だけシフトする必要のある数値があります。これらは境界値です。 ご存知のように、最も問題を引き起こすのは境界値です。 res63とres64で何が起こりますか？ 理論的には、ゼロがあるはずです。 しかし、実際には、すべてがそれほど単純ではありません。







プラットフォームのビット深度に応じて、さまざまな結果が得られますが、すべてが徹底的にルールに従って行われます。 そのため、基本的な演算子で論争の的となっていることを強調し、個別に移植する場合はそれらのテストを行うほうが良いのです。

ハードウェア依存部品

モバイルアプリケーションのデバイス依存部分には、次の機能があります。

• Android、iOS、その他のAPIフレームワークに大きく依存しています。
• 多くの場合、 非ネイティブの手段を使用します。 たとえば、Androidでビデオを使用するコードには次のアルゴリズムがあります。エンジンはCで記述されています。JNIを介してJavaを呼び出し、次にJNIを介して結果を返します。
• 移植性の低い言語を使用します 。 移植性の低い言語の場合、たとえばObjective-CやJavaなどの属性があります。 JavaはCと比較してクロスプラットフォーム言語と見なされているという事実にもかかわらず、普遍性は明らかに欠けています。

基本的なラッパー

コードのデバイス依存部分で作業を何らかの形で統一するために、基本的なラッパーのセットを選択することをお勧めします。 ラッパーのリストのバージョンを提供します。

• システムログ 通常のprintf（）は開発に大いに役立ちます。 各プラットフォームには独自のフレームワークがあります。 たとえば、iOSの場合はNSLog、Androidの場合はLogcatです。
• メモリマネージャー 。 すでにわかったように、malloc / freeを実行する独自のメモリマネージャを用意することをお勧めします。 さらに、メモリリークを探すように彼に教えることができます。
• ミューテックス/アトミック操作も、システムごとに実装が異なります。
• スレッドマネージャー -ミューテックス用のアドオンと、マルチスレッドアプリケーションを作成するためのメインAPI。
• システム情報は、実行時に何かを変更する場合に役立ちます。 コードが複数のプロセッサ用に最適化されている場合、実行時のシステムを確認し、必要な部分を接続できます。
• トレース/ロギングは、単なるシステムログではなくなりました。 これはデバッグエラーであり、すべてのプラットフォームで同じであれば素晴らしいことです。
• ファイルの操作には、ファイルの入力/出力、.pmダンプなどが含まれます。 単一のインターフェースを介して出力することは非常に便利です。
• プロファイリングツール 。 重いコードを使用している場合、標準ツールを使用すると、何がどこで失われたかをすぐに見つけることができるとは限りません。 もちろん、特定のプラットフォームごとにネイティブツールを使用することも、クロスプラットフォームのクロックやログなどを記述してコードで呼び出すこともできます。

追加のラッパー

デバイスの動作によっては、追加のラッパーが必要になる場合があります。 以下は、ラッパーの使用を必須にするハードウェア部品の短いリストです（これらは、移植をスムーズに行うために必要です）。

• ソケット/ネットワーク
• オーディオ機器
• ビデオ機器
• 入力機器

小計

上記のすべての推奨事項に従って、携帯する単一のタイプを介して記述されたアルゴリズムを取得します。 このアルゴリズムは、介入をまったく必要としません。 理論的には、すぐにコンパイルして獲得する必要があります。 単体テストを行う方が良いでしょう。 アルゴリズムがコンパイルされてテストに合格した場合、ほとんどの場合、すべてが問題ありません。 基本操作も移植されますが、移植されない場合があります。



ハードウェアにはすでに移植が必要です。 そして、できるだけシステムに近いインターフェースを持っている方が良いです。 それらはチェックしやすくなり、より速く移植されます。

注意！

最後に、いくつかの一般的な推奨事項を示したいと思います。移植可能なコードを書くとき、私は何を探すべきですか。

• データ/コードメモリ。 携帯端末にはメモリがあまりないことを忘れないでください。 彼女は常に不足しており、常にどこかで逃げようとしている人は彼女の自由な手綱を与える価値があります。 したがって、断片化を回避するには、独自のメモリマネージャを使用することをお勧めします。 さらに、コードは小さいことが望ましいです。ARM固有の操作が重要でない場合は、Thumb2を使用することをお勧めします。
• データのアライメント。 ARMv7より前は、ARMアーキテクチャは非境界整列データへのアクセスをサポートしていませんでした。 ただし、この動作が可能になった後でも、この操作により、操作が簡単な追加のプロセッサが発生します。 したがって、メモリをintの境界に沿って配置することをお勧めします。さらに、キャッシュの境界に沿ってメモリを配置することをお勧めします。これにより、高速ブートが提供されます。
• プロセッサの最適化。 重いアルゴリズム、特に音声とビデオがある場合、最適化なしでは何も機能しません。 そして、突然離陸すると、バッテリー全体をすぐに使い果たしてしまいます。
• 浮動小数点。 デフォルトでは、ARMには浮動小数点はありません。 NEONブロックがCortexに登場し、浮動小数点演算を実装していますが、すべてのデバイスではありません。 iOSを実行しているスマートフォンについて、常に浮動小数点が存在することがわかっている場合、Androidデバイスのメーカーはそれを拒否して保存することができます。 したがって、Androidの場合、Get CPU Featuresが私たちの助けになります。そこでは、浮動小数点のチェックが行われます。
• 整数除算。 彼にとって、物事は浮動小数点の場合と同じです。すべてのカーネルがintをintに分割できるわけではありません。これは覚えておく価値があります。
• スレッドとMainThread。 アプリケーションがマルチスレッドでない場合は、マルチスレッドにします。 モバイルアプリケーションでUIをダウンロードするのは恐ろしいことです。シングルスレッドの実装では、ブレーキからアプリケーションのクラッシュまで、さまざまな効果が可能です。 既にマルチスレッドシステムを使用している場合は、MainThreadに注意してください。多くの処理はシステムからのみ実行される必要があるためです。

簡単な要約

1. まず、プロセッサアーキテクチャを理解すると、移植の品質が向上します。
2. 第二に、移植を成功させる鍵は、優れたクロスプラットフォームコードです。 つまり、既存のコードを書き換えるのに費やす時間が少ないほど、より良く、より速く、より安くなります。 誰もが、特にマネージャーは幸せになります。
3. 3番目：コードの移植性のシンプルさは、アーキテクチャの健全性によって決まります。 したがって、新しいアプリケーションを作成する場合は、最初にクロスプラットフォームと考えてください。 転送する予定がない場合でも、他の誰かがこれを行う必要があります。

クロスプラットフォームコードの実装の良い例をご覧になりたい場合は、libjingleに注意することをお勧めします。 この記事で説明したほぼすべての仮定が満たされています。



コードの移植をさらに簡単にする方法を知っている場合、または私が述べたポイントの詳細について議論したい場合は、コメントでお話させていただきます。