3DOとAndroid NDKおよび関与しない方法...

大規模なソースコードベースC ++またはパフォーマンス要件のために、Javaではほとんど不可能なアプリケーションがかなりあるでしょう。 そして、これらのアプリケーションの1つ、つまり3DOゲームコンソールエミュレーターReal3DOPlayerを開発していることがわかりました 。 私の場合、コードベースとパフォーマンスの両方の要件が役割を果たしました。 コードはフェニックスのデスクトッププロジェクトに基づいており、組み込みプロセッサとは異なり、中規模のデスクトップでも速度が低下しました。 Gooogleでのろいの数を覚えていませんが、受けた経験は非常に貴重でした。ここで共有したいと思います。

壁に額を叩いている初心者が......

私は経験豊富なプログラマー（15年以上）であるにもかかわらず、NDKを取り上げるとすぐに、初心者のように感じました。



最初のバンプ。 Android StudioをWindowsにインストールしたので、JNI呼び出しで最も単純な「Hello、world！」の概要を説明することにしました。 すべてが非常に簡単です：

JNIEXPORT jstring JNICALL Java_ru_arts_union_real3doplayer_NativeCore_stringFromJNI(JNIEnv* env, jclass clazz) { return env->NewStringUTF("Hello, World!"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイルエラー。 ただコンパイルエラー。 ご覧のとおり、コードはコンパイルされません。 問題を積極的にグーグルで調べてコードをコンパイルしようとしたが、1日後にコードを収集できませんでした。 翌日、Linuxを搭載したラップトップを持ち、これら2つのラインを苦しめ続けることに決めました。驚いたことに、すべてがすぐに集まりました。 フォーラムを読み始めましたが、Windowsでコードをコンパイルできないのはなぜですか？ それは判明しました-1つのC / CPPファイルはプロジェクトを構築するのに十分ではありません、少なくとも2かかります！



バンプは2番目です。 アプリケーションを起動するとクラッシュし、stringFromJNIメソッドが見つからなかったことが報告されます。 どうして見つかりませんか？！ ここにあり、ここと逆アセンブラーに表示されています！ パニックにならないでください。私はコード全体を見て行きます。神に感謝します。それほど多くはありません。 関数ru_arts_union_real3doplayerの名前のプレフィックスを見ると、何かがここで間違っていることがわかります...結局、私のパッケージの名前は次のようになりました。 、および環境自体がパッケージにそのような名前を許可しているのは奇妙です。 ダッシュを削除して、パッケージとメソッドの名前を変更します。 やった！ メソッドが表示され、2日後に「Hello、world！」



バンプは3番目です。 問題はありません。多くのファイルが存在し、名前が修正されました。最悪の事態が遅れていると考えて先に進みます。 Linux / Windowsでさまざまなプロセッサ（ARMを含む）でテストされたソースを追加します。 すべてが完全にコンパイルされ、エラーは1つもありません。 警告なしで起動時にアプリケーションがクラッシュします。 コードの瞑想を続け、長い二重の通過線を観察し、NEONが最大の倍を保持していることを思い出しますが、このコードは呼び出されず、ただ存在し、タイプヘッダーにreal80を削除しました。 そして、コードはエラーなしでコンパイルされました！ うーん..タンバリンをノックするよりも、私はこのコードを飲みたいです...起動して、ビンゴ！ ワイルドブレーキがかかっていても、コードは機能し、ゲームが始まります！



また、一見当たり前のように見えるもの-標準Cライブラリ、注意してください。あるバージョンに存在する一部のメソッドが別のバージョンに存在せず、目的のメソッドをロードできないためにアプリケーションがクラッシュすることがよくあります。 ここで役立つのは、静的リンクを使用したSTLを支持する広範なテストまたは拒否のみです。 そのため、たとえば、数値を文字列に、またはその逆に変換する機能がないため、かなり多数のデバイスでTinyXMLがクラッシュします。



経験が少ないほど、より多くのコーンが得られます-精神的に準備してください、おそらくすべてを覚えていませんでした...

パフォーマンスを追求する、または一度急落した...

エミュレータのパフォーマンスを向上させる方法は、一部の場所ではi7にも負担をかけましたか？ 非常に簡単で、自分をコンピューティングリソースに制限する必要があります。これは、Androidに移植しようとしたときに発生しました。



このような困難な状況では、コンソールのグラフィックプロセッサによって事前または部分的に処理されたピクセルでテクスチャキャッシングを実装する必要がありました。 正方形ポリゴンの三角形分割（3DOには非線形テクスチャマッピングがあります）; 静的コードの再コンパイル、頻繁に使用されるコンソールOSのライブラリ。 コンソールのサブシステムのエミュレーションの並列化。 これにより、ハードウェア要件を3倍以上削減できました。 古典的なテクニック、アセンブリの最適化、プロファイラーに長時間座っていることを考慮せずに、他にどこで時計を節約できますか？ 明らかに、ほとんどのユーザーは違いに気付かないでしょう。 そのため、たとえば、フレームを塗りつぶすときに、24ビットではなく16ビットラスタで多くを保存しました。



最適化プロセス自体は非常に面白く、別の記事に基づいていますが、上記のすべてはAndroid自体には適用されません。 しかし、プラットフォーム自体とその機能から何が得られますか？ ほとんどのデバイスがモバイルプラットフォームのCPUとGPUを共有しているため、明らかにテクスチャメモリに直接記録します。 しかし、残念ながら、GraphicBufferとして知られるこのメカニズムは、一般的な使用を目的としていません！ 何も、dlopenを介して取得することはできません。 ただし、このハックはどこでも機能しない可能性があるため、これはオプションで行う必要があります。 ここで実装を見ることができます（検索で見つけるのはかなり困難です）： android.googlesource.com/platform/external/deqp / + / deqp-dev / framework / platform / android / tcuAndroidInternals.cpp



そして、Androidは本当に私たちに何を提供したいのですが、本当に必要ですか？ もちろん、アプリケーションサイクルを制御してください！ しかし、本当に必要な場合は、NativeActivityが役立ちます。または、シンプルで便利なこの小さな例： github.com/tsaarni/android-native-egl-exampleが役立ちます。 通常のアクティビティからの操作方法が不明なNativeActivityとは異なり、このアプローチでは、Javaが決定したときではなく、必要なときにウィンドウコンテキストをキャプチャして別のストリームに描画できます。 そして、ここで私は自分でそれを知らずに混乱していた。



実際、このメカニズムはすべてのバージョンのAndroidで機能するわけではありません（少なくとも私のテストでは、バージョン4.1-4.3はサポートしていません）。これは、Googleの統計によると、アプリケーションのターゲットデバイスの約40％です。 40％の利益。 そして、これについては非常に遅いことがわかります。通常、ユーザーはアプリケーションを置いて、それが機能しないことを確認し、すぐに取り壊し、レビューを書かないためです。 アプリケーションの間違ったサイクルを修正するのは楽しいことではありません。動作するデバイスと動作しないデバイスを判断することは不可能であるため、デフォルトでより遅いソリューションを設定できますが、より互換性のあるものを設定できますが、カルマを台無しにすることはできません設定を確認します。「何かを締めて、以前のように遅くなりませんか？」すぐにオークバージョンを作成してからオプションを追加する方が良いですが、私の場合は遅すぎます。

エンティティの切断または2つの周りの混乱...

Javaには膨大なライブラリがあるため、多くの場合、SDKには、たとえば、フォントや画像の操作など、ネイティブコードで複製したくない機能が既にあります。 そして、C ++からJavaメソッドを呼び出したいという自然な欲求があります。 私はそのような欲求を抱いていたので、ネイティブコードからの要求に応じてフォントをテクスチャにレンダリングし、すべてのデバイスと多数の仮想デバイスをテストしました。 すべてが正常に動作し、再び混乱に陥りました-リリースを行いました...ユーザーの約1％（すでにアプリケーションを購入した）に対して、プログラムはクラッシュし始めました。 控えめに言っても、非常に悪い、ネガティブなレビュー、そして状況そのもの-人は支払いをし、それからバム-それは彼にとってはうまくいきません。 理由が何であるかを言うのは難しいです、私はいくつかのメーカーが変更された軸または他のものを使用していると思います。 もちろん、自分から間違いを排除するわけではありませんが、そのようなレポートを見て、私はそれを強く疑います（もちろん、この方法は白黒でした）：

 java.lang.NoSuchMethodError: no method with name='loadConfig' signature='(Ljava/lang/String;)Ljava/lang/String;' in class Lru/vastness/altmer/real3doplayer/MainActivity; at dalvik.system.NativeStart.run(Native Method)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このソリューションを非常に迅速に切り取り、別のソリューションに置き換える必要がありました。 少し血がかかりました。 ソリューション自体は非常に優れています（1％の非互換性は許容できますが、通過するだけで購入しません）が、アプリケーションが起動するまでは、多くのコピーが既に販売されている場合にのみ、それに対して強くアドバイスします。

武器庫を更新するか、トラブルに巻き込まれる3 ...

システムを再配置し、SDKを下位にインストールしたため、targetSdkVersionも変更されました。 迷惑がありました。 SDドライブが表示されなくなりました。これは、アクセス権を使用したGoogleの奇妙な詐欺が原因です。 同時に、古いバージョンのSDKでAPKをダウンロードすることもできました！ 無理です！ しかし、私はわずかな恐怖で降りました、問題は許可を要求することで解決しました。 そして、問題がそれほど簡単に解決されない場合はどうなりますか？ 次に何をしますか？ 質問はとても興味深いです...



更新に伴う最も不快なことは、今日まで取り除けませんが、ネイティブライブラリの変更でAPKを更新する環境の不本意です。LinuxおよびWindowsで問題が発生します。 これは面倒なので、新しく収集された最新のAPKのデバッグ中のデバイスで、次の操作を行う必要があります（Android Studio 2.1.1）：



1.プロジェクトを再構築します。

2.プロジェクトを実行します（同時に、最初の手順をスキップすると再アセンブルされず、再構築されます）。

3.アプリケーションを停止します。

4. APKをビルドします。

5.アプリケーションを実行します。



また、再構築を行った場合、アプリケーションを起動すると、デバイス上で新しく収集されたAPKを受け取ると思いましたか？ そこにはありませんでした。確認してください。代わりに、ポップアップウィンドウまたはログのメッセージに変更のバージョンを記載してください。 そうしないと、作業コードをチェックするのに多くの時間を失う危険があります。 そして、2回目または3回目の打ち上げからうまくいくことを期待しないでください。



同様の問題を抱えている人のために、時間を補うために、もしそうしていなければ、ネイティブコードの並列アセンブリのためにジョブNを指定することをお勧めします。

一番下の行...

一般に、私はこのプラットフォームの開発ツールに没頭しており、このような湾曲は10年間見ていませんが、比較するものがあります。 もちろん、Javaが優先事項であることは理解していますが、それでも...変数でゼロにシフトするときに、インテルコンパイラで何年も前に見つけたバグだけが、これに遭遇する可能性があります。

  if(shift)return x>>shift; return x;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでも、Googleに敬意を表する価値はあります。Androidのネイティブ開発者の給与が高くなるように、彼らはすべてを行いました。



私にとって、C ++開発者として、Android用のアプリケーションの状況は逆説的に見えますが、一方で必要なメカニズムがありますが、プラットフォームの問題の合計量は、改善を試みるとき、評判を失うか開発するかを選択する必要があるということですアプリケーション。 そのような選択の前に私を置いたプラットフォームは一つもありません。



意図せずに、このプラットフォームで何も改善しない方が良いかもしれないと考えている自分をキャッチします。そうでなければ、何が起こるかは関係ありません...



PS。 考えないでください-エミュレーターは開発を続けます、それはちょうど沸騰します。