厳密なAndroid開発から離れて、iPhoneアプリケーションを作成したいと思っています。私の理解では、iOSアプリケーションのバックエンドをC / C ++でコーディングでき、NDKを使用してAndroidアプリにC /C++コードを含めることもできます。しかし、私の質問はどうですか？私はかなりグーグルで検索しましたが、明確で簡潔な答えを見つけることができません。NDKのサンプルコードを見ると、すべての関数名などがAndroid（または少なくともJava）固有であるように思われるため、このC / C ++バックエンドを使用してiPhoneフロントエンドを開発することはできませんか？この問題についていくつか説明していただければ幸いです。もし利用できる場合は、私を助けるためのコードを教えてください。（C / C ++ファイルから文字列を読み取り、iOSおよびAndroidアプリに表示する単純なHello Worldでも）。
みんなありがとうクリス
私はほぼ独占的に「ビジネス/ユーティリティ/生産性」アプリケーションに取り組んでいることに注意してください。かなり標準的なUI要素に大きく依存し、プラットフォームとの統合が期待されるもの。この答えはそれを反映しています。まったく異なる状況にあるゲーム開発者への良いコメントについては、ShaggyFrogの回答に対するMitchLindgrenのコメントを参照してください。
@ShaggyFrogはここでは間違っていると思います。C ++で効果的なテスト済みのコードがある場合、AndroidとiPhoneの間で共有しない理由はありません。私はそれを実行するプロジェクトに取り組んできましたが、非常に成功する可能性があります。ただし、避けるべき危険があります。
最も重要なのは、「最小公分母」に注意することです。自己完結型のアルゴリズムコードは、非常によく共有されます。スレッドを管理したり、ネットワーク上で通信したり、OSと対話したりする複雑なフレームワークは、プラットフォームのパラダイムを破り、すべてのプラットフォームで同じように機能しないLCDを撮影することを強制しない方法で行うのがより困難です。 。特に、プラットフォームのフレームワークを使用してネットワークコードを作成することをお勧めします。これには、多くの場合、最上層がプラットフォーム固有で、最下層がプラットフォーム固有であり、中間が移植可能である「サンドイッチ」アプローチが必要です。注意深く設計すれば、これは非常に良いことです。
スレッド管理とタイマーも、プラットフォームのフレームワークを使用して実行する必要があります。特に、Javaはスレッドを多用しますが、iOSは通常、スレッドを回避するためにrunloopに依存しています。iOSがスレッドを使用する場合、GCDが強く推奨されます。繰り返しになりますが、ここでの解決策は、真に移植可能なアルゴリズムを分離し、プラットフォーム固有のコードにその呼び出し方法を管理させることです。
スレッド化が進んでいて、ネットワークやUIコードが大量に分散している複雑な既存のフレームワークがある場合、それを共有するのは難しいかもしれませんが、それでも、書き直すのではなく、リファクタリングする方法を探すことをお勧めします。
Linux、Windows、Androidで共有されるクロスプラットフォームコードを幅広く扱うiOSおよびMac開発者として、Androidは共有するプラットフォームの中で群を抜いて最も厄介であると言えます（Windowsはこの区別を保持していましたが、Androidは吹き飛ばされましたそれを離れて）。Androidには、コードを共有することが賢明でない場合がほとんどです。しかし、コードを再利用する機会はまだたくさんあるので、それらを追求する必要があります。
感情は健全ですが（Do n't Repeat Yourselfのポリシーに従っています）、そのコードを効率的に共有できる場合にのみ実用的です。この場合、2つのプラットフォームのコードを異なる言語（iPhoneではC / C ++ / Obj-C、AndroidではJava）で記述する必要がある、クロスプラットフォーム開発への「1回限りの書き込み」アプローチは実際には不可能です。
この場合、2つの異なるコードベースを（2つの異なる言語で）作成することをお勧めします。アドバイス：JavaコードをC ++のように記述したり、C++コードをJavaのように記述したりしないでください。私は数年前、JavaからC ++に「移植」した製品を持っていた会社で働いていましたが、C++のようにC++コードを記述していなかったため、難しいことは言うまでもなく、あらゆる種類の問題が発生しました。読む。
私は同様の質問にこれと同じ答えを投稿しましたが、それは関連があると思います...
私はプラットフォーム抽象化にBatteryTechを使用しており、プロジェクト構造は次のようになっています。
私のPCで：
gamename-一般的なコードのみが含まれています
gamename-android-主にBatteryTechのAndroid固有のコードとAndroid構成を保持し、ビルダーは一般的なコードのgamenameプロジェクトを指します
gamename-win32-Windowsに構築するためだけに、gamenameプロジェクトのコードを使用します
私のMacの場合：
gamename-一般的なコードのみが含まれています
gamename-ios-iPhone / iPadビルド、共通コードをインポート
gamename-osx-OSXネイティブビルド。共通コードをインポートします。
そして、SVNを使用してPCとMacの間で共有しています。私の唯一の本当の問題は、Windowsの共通コードベースにクラスを追加し、Macで更新してSVNからそれらをプルダウンする場合です。XCodeには、スクリプトなしでプロジェクトに自動的に追加する方法がないため、毎回手動でプルする必要があります。これは面倒ですが、世界の終わりではありません。
これらすべてのものはBatteryTechに付属しているので、一度入手すれば簡単に理解できます。
この状況では、共有コードベースを作成するのが非常に実用的です。セットアップと整理にはいくらかのオーバーヘッドがありますが、主な利点は次のとおりです。1）共通の機能を共有することでコードの量を減らす2）共通のコードベースにバグ修正を共有する。私は現在、プロジェクトで検討している2つのルートを認識しています。ネイティブc / c ++を使用するか（ガベージコレクションを失い、プロセッサごとにターゲットを設定することで速度を上げる）、または c＃バインディングを提供するmonodroid/monotouchを使用します。各OSのプラットフォーム機能（これがどれほど成熟しているかはわかりません）。
3Dを使用してゲームを作成している場合は、間違いなくアプローチ＃1を使用します。
C / C ++共有を使用することに加えて、 lib。
ゲームのようなクロスプラットフォームアプリを開発する場合は、Unity3Dのようなモノベースのフレームワークを使用することをお勧めします。
それ以外の場合、ネイティブUIを必要とし、モバイルプラットフォーム間でビジネスロジックコードを共有したいビジネスアプリを開発する場合は、クライアントビジネスロジックセンターとしてLua組み込みエンジンを使用することをお勧めします。
クライアントUIは引き続きネイティブであり、最高のUIパフォーマンスを実現します。つまり、AndroidのJavaやiOSのObjectCなどです。ロジックはすべてのプラットフォームで同じLuaスクリプトと共有されます。したがって、Luaレイヤーはクライアントサービスと似ています（サーバー側のサービスと比較してください）。
-アンダーソンマオ、2013-03-28
私が書いたもののほとんどはうまく移植できないので、私はこれらを自分で使用しませんが、AppceleratorやRed Foundryなどを使用して、どちらのプラットフォームでもネイティブに作成できる基本的なアプリケーションを構築することをお勧めします。これらの場合、あなたはobjective-cやjavaを書いているのではなく、ある種の仲介者を使っています。彼らがあなたを閉じ込めていた箱の外に移動する場合、あなたは金属の近くにあなた自身のコードを書く必要があることに注意してください。