98

更新 3. KOTLIN は、Android開発向けに公式にサポートされるようになりました。グーグルによる。やあああああ！

更新 2 : JetBrains は、長期的には Kotlin for Android のサポートに真剣に取り組んでいるようです。私は幸せなkotlinユーザーです:)。

更新: JetBrains の Hadi Hariri は、このトピックに関する情報を公開する予定であると述べました。更新したら、この投稿を更新します。


=== 非推奨のもの 次へ ===

Google は、いくつかの興味深い機能を備えた次期 Android N のプレビューをリリースしました。最も注目すべき機能は、Java 8 言語の部分的なサポートです。これは、Google が取り組んでいる新しいJack ツールチェーンによって可能になります。

javacまたはkotlincを使用する現在のツールチェーン:
javac ( .java--> .class) --> dx ( .class--> .dex)
kotlinc ( .kt--> .class) --> dx ( .class--> .dex)

新しい Jack ツールチェーン:
Jack ( .java--> .jack--> .dex)

私は、Google がJackを Android 開発のデフォルトのツールチェーンにする方向で前進していると思います。更新: Jackは非推奨になりました。ヤス。

私の質問は、Android 開発のkotlinユーザーとして、この新しいツールチェーンが将来どのような影響を与えるかということです。「過去にとらわれる」のでしょうか？

4

8 に答える 8

63

免責事項：私はジャックに取り組んでいます

これはあなたには影響しません。Kotlin のコンパイラは Java 6 バイトコードを生成し、Jack/Jill はこれを問題なくインポートできます。

于 2016-03-11T01:10:09.480 に答える
15

@パベル・ドゥッカ

Jack - コンパイラです。javac に似ていますが、少し異なることを行います。

ここに画像の説明を入力

ご覧のとおり、Jack は Java ソース コードを直接 Dex ファイルにコンパイルします。中間の *.class ファイルはもうないので、dx ツールは必要ありません。

ちょっと待って！自分のプロジェクト (.class ファイルのコレクションとして提供される) にサードパーティ ライブラリを含めるとどうなりますか?

そして、それがジルの出番です：

ここに画像の説明を入力

Jill はクラス ファイルを処理し、Jack コンパイラの入力として使用できる特別な Jayce 形式に変換できます。

それでは、ちょっと脇に置いて考えてみましょう... 私たちが夢中になったすべてのクールなプラグインに何が起こるのでしょうか? それらはすべて.classファイルを必要とし、Jackコンパイラにはそれらがありません...

幸いなことに、ジャックは私たちにとって重要な機能のいくつかをすぐに提供してくれます。

  • Retrolambda - 必要ありません。ジャックはラムダを適切に処理できます
  • Proguard - 現在は Jack に組み込まれているため、難読化と最小化を引き続き使用できます

利点:

Jack は Java プログラミング言語 1.7 をサポートし、以下に説明する追加機能を統合します。

  • プレデクシング

    JACK ライブラリ ファイルを生成すると、ライブラリの .dex が生成され、プレデックスとして .jack ライブラリ ファイル内に保存されます。コンパイル時に、JACK は各ライブラリの pre-dex を再利用します。すべてのライブラリは事前にデキシングされています。

  • 増分コンパイル

    インクリメンタル コンパイルとは、前回のコンパイル以降に変更されたコンポーネントとその依存関係のみが再コンパイルされることを意味します。インクリメンタル コンパイルは、変更がコンポーネントの限られたセットのみに制限されている場合、フル コンパイルよりも大幅に高速になる可能性があります。

  • 再梱包

    JACK は jarjar 構成ファイルを使用して再パッケージ化を行います。

  • マルチデックスのサポート

    dex ファイルは 65K メソッドに制限されているため、65K を超えるメソッドを含むアプリは複数の dex ファイルに分割する必要があります。(multidex の詳細については、「65,000 を超えるメソッドを使用したアプリのビルド」を参照してください。)

短所:

  • Jack は Transform API をサポートしていません - 変更できる中間の Java バイトコードがないため、ここで言及していないプラグインの一部は機能しなくなります。
  • アノテーション処理は現在 Jack ではサポートされていないため、Dagger、AutoValue などのライブラリに大きく依存している場合は、Jack に切り替える前によく考えてください。編集: Jake Wharton が指摘したように、Jack in N Preview は注釈処理をサポートしていますが、Gradle を通じてまだ公開されていません。
  • Java バイトコード レベルで動作するリント ディテクターはサポートされていません。
  • Jacoco はサポートされていません。個人的に Jacoco は疑わしいと思います (実際に見たいものが表示されません)。
  • Dexguard - Proguard のエンタープライズ バージョンは現在サポートされていません
于 2016-05-02T14:15:23.117 に答える
7

更新 (2017 年 3 月 16 日)

幸い、Jack は亡くなっているため、Kotlin 開発者には影響しません。

ジャックが未来なら、Kotlin で過去に行き詰まるでしょう。現在、Jack は Java 以外のソースを Dalvik バイトコードにコンパイルできるプラグインをサポートしていません。たとえそれができたとしても、JetBrains は Kotlin コンパイラに新しいバックエンドを追加する必要がありますが、これは簡単な作業ではありません。そのため、Jill で Kotlin を使用する必要があり、現在使用しているツールチェーンと非常によく似たものになります。

下の画像でわかるように、Jack を明示的にオフにすることが不可能な場合でも、プロジェクトをライブラリ プロジェクトに変換して Jill を使用することができます。アプリケーション プロジェクトは、このライブラリ プロジェクトを参照するだけです。

ジャックとジルのアプリケーション ビルド

おそらく実装されないだろうが、Kotlin が Jack とどのように連携できるかを知る唯一の方法は、Java バックエンドを Kotlin コンパイラに追加することです。つまり、Xtendのような Java コードを生成するバックエンドです。この場合、Kotlin コンパイラによって生成されたコードは、Jack によって他の Java コードと同様に処理できます。

しかし現時点では、Jack がリリースされたときに何をサポートするのか正確にはわかりません。何かが劇的に変化し、Jack に Kotlin サポートを追加できるようになるかもしれません。

于 2016-03-10T18:28:15.510 に答える
5

本日公開されたブログ投稿 ( Kotlin の Android ロードマップ) で述べたように:

現在、Jack が Kotlin で生成されたバイトコードを正しく処理できない問題がいくつかあります ( 196084および203531 ) が、Google チームと協力して問題を解決するか、回避策を提供する予定です。これが完了すると、毎回すべてのクラス ファイルを変換するのではなく、増分コンパイル中にJill を使用して変更されたクラス ファイルのみを変換できるようになります(古い Android ツールではこれが唯一可能な動作でした)。

そのため、Kotlin は最終的に Jack & Jill をサポートし、そこから利益を得るでしょう。

于 2016-03-30T12:50:42.437 に答える
1

I've already found this blog post from the official Kotlin's blog: : Kotlin’s Android Roadmap

There you would find a part which tells that:

The next thing we plan to do to improve Android build performance is providing an integration with Android’s new Jack and Jill toolchain. Right now there are some issues that prevent Jack from handling Kotlin-generated bytecode correctly (196084 and 203531), but we plan to work together with the Google team to either resolve the issues or provide workarounds on our side. Once this is done, we’ll be able to translate only changed class files using Jill during incremental compilation, as opposed to translating all class files every time (which is the only possible behavior in the old Android tooling).

So as @LukasBergstrom said, there won't be any problem with "stucking in the past" ;-)

You can also check Reddit discussion linked with this topic: What is the status of Kotlin with Jack and Jill?

Happy coding.

于 2016-08-17T11:31:16.557 に答える