昨日、私はparse.comライブラリに関するたくさんの警告を認識しました。
緊急: '[path] /Parse.framework/Parse(PFAnalytics.o)'がビットコードなしで作成されたため、すべてのビットコードが削除されます。ビットコードを有効にして(Xcode設定ENABLE_BITCODE)再構築するか、ベンダから最新のライブラリを入手するか、このターゲットのビットコードを無効にする必要があります。注:これは将来エラーになります。
この答え でこれらの警告を削除できるという事実を私は認識していますが、AppStoreの送信やアプリケーションの実際のパフォーマンスに関して悪影響があるのではないかと考えています。
Xcodeはビットコードに関してあなたに知らせます
この設定を有効にすると、ターゲットまたはプロジェクトは、それをサポートするプラットフォームおよびアーキテクチャのコンパイル中にビットコードを生成するようになります。アーカイブビルドの場合、アプリストアに送信するために、リンクされたバイナリでビットコードが生成されます。他のビルドでは、コンパイラとリンカは、コードがビットコード生成の要件を満たしているかどうかをチェックしますが、実際のビットコードは生成しません。 [ENABLE_BITCODE]
しかし、私はこのテキストから本当に有用な情報を得ていません。
ENABLE_BITCODE
は実際には何をしているのでしょうか。将来的にはオプションではなくなるでしょうか?
- ENABLE_BITCODEは実際には何をするのでしょうか。将来的にはオプションではなくなりますか?
どのレベルで答えを探しているのかよくわかりませんので、ちょっとした旅に出ましょう。これのいくつかはあなたがすでに知っているかもしれません。
プロジェクトをビルドすると、XcodeはObjective-Cターゲットにはclang
を、SwiftターゲットにはSwift
/swiftc
を呼び出します。これらのコンパイラは両方ともアプリを 中間表現 (IR)にコンパイルします。これらのIRの1つはビットコードです。このIRから、LLVMと呼ばれるプログラムが引き継ぎ、x86 32および64ビットモード(シミュレータ用)およびarm6/arm7/arm7s/arm64(デバイス用)に必要なバイナリを作成します。通常、これらの異なるバイナリはすべて、 fatバイナリ と呼ばれる単一のファイルにまとめられています。
ENABLE_BITCODEオプションはこの最後のステップを省略します。それはIRビットコードバイナリでアプリのバージョンを作成します。これにはたくさんの素晴らしい機能がありますが、1つの大きな欠点があります。ビットコードバイナリを含むアプリを実行するには、ビットコードをx86またはARMに再コンパイルする必要があります( アセンブリまたはトランスコードされる可能性があります。は不明)。バイナリ。
ビットコードアプリがApp Storeに送信されると、Appleはこの最後のステップを実行し、完成したバイナリを作成します。
今のところ、ビットコードアプリケーションはオプションですが、歴史上、Appleはオプションのものを要件に変えています(64ビットサポートなど)。これには通常数年かかるので、サードパーティの開発者(Parseなど)は更新する時間があります。
- 悪影響を与えることなく、また将来のappstoreへの送信を犠牲にすることなく上記の方法を使用できますか?
はい、あなたはENABLE_BITCODEをオフにすることができ、すべてが以前と同じように動作します。 AppleがビットコードアプリケーションをApp Storeの要件にするまでは、問題ないでしょう。
- 有効/無効にした場合、パフォーマンスへの影響はありますか?
有効にしてもパフォーマンスに悪影響が出ることはありませんが、テスト用のアプリの内部配布はより複雑になる可能性があります。
プラスの影響に関しては…それは複雑です。
App Storeで配布するために、Appleはファットバイナリを含む1つのアプリケーションではなく、マシンアーキテクチャ(arm6/arm7/arm7s/arm64)ごとに別々のバージョンのアプリを作成します。これは、iOSデバイスにインストールされているアプリが小さくなることを意味します。
さらに、ビットコードが再コンパイルされると( アセンブルまたはトランスコードされることもありますが、正しい動詞 がわからない場合)、最適化されます。 LLVMは常に新しい、より良い最適化の作成に取り組んでいます。理論的には、App Storeは、LLVMの新しいリリースごとにApp Store内に別々のバージョンのアプリを再作成できるため、最新のLLVMテクノロジを使用してアプリを再最適化することができます。
ビットコードは iOS 9 の新機能です。
ビットコードはコンパイルされたプログラムの中間表現です。 iTunes Connectにアップロードしたビットコードを含むアプリは、App Storeでコンパイルおよびリンクされます。ビットコードを含めると、Appleは新しいバージョンのアプリをストアに送信しなくても、将来的にアプリのバイナリを再最適化できるようになります。
注:iOSアプリの場合、ビットコードがデフォルトですが、オプションです。ビットコードを提供する場合は、アプリバンドル内のすべてのアプリとフレームワークにビットコードを含める必要があります。 watchOSアプリの場合、ビットコードが必要です
したがって、アプリのすべてのフレームワークでビットコードが有効になるまで、ビットコードを無効にする必要があります。
ビットコードはクラッシュレポートを難しくします 。これは HockeyApp からの引用です(これはany other _クラッシュ報告ソリューションにも当てはまります)。
App Storeにアプリをアップロードし、「Bitcode」チェックボックスを有効にしたままにしておくと、AppleはそのBitcodeビルドを使用してデバイスに配布する前に再コンパイルします。これにより、バイナリは新しいUUIDを取得し、Xcodeを介して対応するdSYMをダウンロードするオプションがあります。
注:最新の変更を反映するために、回答は2016年1月に編集されました
ここでは、Bitcodeに関するすべての解決策を見つけることができます。
Apple Docによると
ビットコードはコンパイルされたプログラムの中間表現です。 iTunes Connectにアップロードしたビットコードを含むアプリは、コンパイルされてストアにリンクされます。ビットコードを含めると、Appleは新しいバージョンのアプリをストアに送信しなくても、将来的にアプリのバイナリを再最適化できるようになります。
Xcodeは、デフォルトではビルド時に生成されたシンボルを隠します。そのため、それらはAppleには読めません。アプリをiTunes Connectにアップロードするときにシンボルを含めることを選択した場合にのみ、シンボルがAppleに送信されます。アップルからクラッシュレポートを受け取るにはシンボルを含める必要があります。
注: iOSアプリの場合、ビットコードがデフォルトですが、オプションです。 watchOSおよびtvOSアプリの場合、ビットコードが必要です。ビットコードを提供する場合は、アプリバンドル内のすべてのアプリとフレームワーク(プロジェクト内のすべてのターゲット)にビットコードを含める必要があります。 iTunes Connectを使ってアプリを配布した後は、 [デバイス]ウィンドウでのクラッシュの表示とインポート で説明されているビルド用のdSYMファイルをダウンロードできます。
ある種類のハードウェアから別の種類のハードウェアにアップグレードする際の問題で正しいバージョンのバイナリが復元されなかったため、Appleによるビットコードとアプリの間引きサービスの最初のロールアウトは保留になりました。この問題はiOS 9.0.2で修正され、機能は再び有効になりました。
ビットコードは常にLLVMのコンパイルおよび最適化フェーズの一部でしたが、バックエンドロジックをAppleサーバーに移動することによって、最適化およびアセンブルフェーズを開発者のコンパイル時からApp Storeへの展開に移しました。これにより、将来のより新しくより高速なプロセッサをサポートするための将来の再最適化または再変換の可能性が解放されます。 watchOSとtvOSのデプロメントにはビットコード展開が必要であり、プロジェクト設定の「ビットコードを有効にする」オプションを使用して、既存のiOS展開に対して条件付きで有効にすることができます。これにより、デバッグビルド用のフラグembed-bitcode-marker、およびアーカイブ/デバイスビルド用のembed-bitcodeが追加されます。これらは、-embed-bitcodeを使用して、または-fembed-bitcodeを使用してclangを使用して、Swiftコンパイラに渡すことができます。
ビットコードにもいくつかの欠点があります。 開発者は、アップルに出荷されたバイナリに対応するデバッグシンボルのコピーを保存することで、アプリケーションからのクラッシュレポートをデバッグできます。特定のスタックでクラッシュが発生した場合、開発者はこれらのデバッグシンボルを使用してクラッシュレポートを表すことで元のスタックトレースを復元できます。ただし、シンボルは中間形式をバイナリに変換した副産物です。しかし、その手順がサーバー上で行われると、この情報は失われます。アップルは、アプリケーションの公開時に開発者がデバッグシンボルをアップロードした場合に限り、デバッガの役割を果たすことができるクラッシュレポートサービスを提供しています。開発者が正確なバイナリを見たことがないということは、新しいハードウェアが進化するにつれて、特定の問題をテストできない可能性があることを意味します。追加のルーチンやコードスニペットを挿入する機能など、コンパイルを実行するためのAppleへの移行力についても懸念がありますが、Appleはパブリケーションプロセスを完全に制御しているため、開発者がビットコードまたはコンパイル済みバイナリを使用するかどうかは現在可能です。 。
最後に、サーバー上のビットコード は、新しいアーキテクチャや命令セットが進化するにつれてサポートされるように変換できます。それらが呼び出し規約とアラインメントとワードのサイズを維持するならば、ビットコードアプリケーションは異なるアーキテクチャタイプに翻訳されて、そして新しいプロセッサのために特に最適化されるかもしれません。数学およびベクトルルーチン用の標準ライブラリを使用する場合は、これらをプロセッサ固有のベクトル命令に最適化して、特定のアプリケーションに対して最高の性能を引き出すことができます。最適化プログラムは、複数の異なるエンコーディングを生成し、サイズや実行速度に基づいて判断することもできます。
docs から
ビットコードを使用すると、別のビルドを送信しなくても、アップルはアプリを最適化できます。ただし、この機能を有効にできるのは、アプリバンドル内のすべてのフレームワークとアプリでこの機能が有効になっている場合だけです。それを持っていることは助けになりますが、持っていなくても悪い影響を与えるべきではありません。
IOSアプリの場合、ビットコードがデフォルトですが、オプションです。ビットコードを提供する場合は、アプリバンドル内のすべてのアプリとフレームワークにビットコードを含める必要があります。 watchOSアプリの場合、ビットコードが必要です。
App Storeとオペレーティングシステムは、最小限の設置面積で、ユーザーの特定のデバイスの機能に合わせてアプリの配信を調整することで、iOSおよびwatchOSアプリのインストールを最適化します。アプリの間引きと呼ばれるこの最適化を使用すると、ほとんどのデバイス機能を使用し、最小限のディスク容量を占有し、Appleが適用できる将来のアップデートに対応するアプリを作成できます。より速いダウンロードと他のアプリやコンテンツのためのより多くのスペースはより良いユーザーエクスペリエンスを提供します。
パフォーマンスへの影響はありません。