如何看待「谷歌醞釀將蘋果 Swift 作為安卓 APP 主要開發語言」？

01-01

今天早晨剛看到的騰訊新聞
Android 碎片化已經夠嚴重了，開發語言還要出來兩個版本，還能不能愉快地玩耍了
Google may be considering Swift for use on Android

這真的是想多了，使用swift開發Android App只是一個噱頭(?或者說玩笑)

現在Android開發社區中除了Java以外，最常使用的開發語言是Scala, Groovy 以及才出來的 Kotlin，他們之間有什麼相同點呢？他們都是JVM語言，因此他們可以被編譯成class文件，打包成為dex文件，進而運行在Android 虛擬機上。

而現在，假定我們使用Swift作為開發語言，會遇到哪些問題:

第一個問題就是已有的Android版本是不支持Swift編譯出的應用的，Swfit本身就不是作為一種JVM語言開發的，因此如果強行把他編譯成class文件，工作量很大。所以如果真有Swift應用，也只能在新版本的Android系統中運行，但是Android不比iOS，系統升級率那是相當的低，我想沒有任何一個開發者會願意拋棄老版本的Android用戶

第二個問題就是Android的生態環境，Android從09開始發布，到現在已經7年了，各種開源社區和開源項目都是圍繞著Java語言進行開發，就算是Scala，Groovy和Kotlin也是能夠直接調用Java代碼。如果選用了Swift，如果完全拋棄現有的開源項目框架，成本很高，但如果需要直接操作Java代碼，勢必多一層類似jni的東西，也會在一定程度上影響運行效率，得不償失。

基於以上兩點，與其等待swift，我覺得還是洗洗睡了比較靠譜。

目測假新聞，本身那篇文章來源就不可靠

放著Kotlin這個在Android開發方面差不多成熟的語言（包括IDE支持，和Java無縫對接）不用跑出搞Swift，看不出有這個必要性

重寫框架層？乾脆重新開發一個手機操作系統好嗎，還有AndroidN 剛剛改入openJDK和JACK編譯器，還有搞了半天的Java虛擬機，最後全部扔掉再另起爐灶是嗎，真的乾脆重新寫一套操作系統更方便。 Swift語法有多少優越性（和Kotlin比）而值得做出這麼多的犧牲和改變呢？並沒有吧？

當然啊，最省事的可以出一個Swift on JVM啊，和舊代碼互通兩不誤，其他東西也都不用重寫有木有！那麼問題又回來了，既然你要的是一個基於JVM的腳本語言（或語法類似腳本語言的語言），那麼為啥要捨近求遠？

唯一的理由大概就是所謂的跨平台開發能力了，但是實際能復用多少代碼真的存疑吧，畢竟iOS和Android是兩個幾乎完全不一樣的平台。不過Google真的不怕麻煩硬是要搞，那也算一件不錯的事情，畢竟語言這種東西還是越統一越好。

另外文章內提到的Kotlin現存的速度問題，Jetbrains已經在改進

Kotlin』s Android Roadmap

Development Workflow
To speed up the development workflow, incremental compilation is coming to Kotlin』s Gradle plugin. This will improve the build times considerably: when a source file is changed, we』ll only recompile this particular file and those files really depending on it, not the whole module.
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).
Last, but not least: Instant Run. Currently, Cold Swap works fine for Kotlin, but Warm and Hot Swap require some further investigation. We』ll do what we can to get them fixed ASAP. In the meantime, JRebel for Android works fine with Kotlin already.

有Jetbrains爸爸支持的語言，緊跟Android開發的最新動態，不知道比其他語言高到哪裡去了==

另外作者貌似對Kotlin有偏見

It would be much less work on Google』s end to get Kotlin up and running for Android, but could be a tedious transition for developers.

Tedious？各方面設計的也差不多，怎麼Swift就不tedious了而Kotlin就是Tedious了？呵呵

順便看了一眼作者的自我介紹

TNW"s West Coast writer in the PNW (Portland, Oregon). Nate loves amplifying developers, andcodes in Swift when he"s not writing. If you need to get in touch, Twitter or email are your best bets.

一個Swift死忠寫出來的文章，難怪，聽風就是雨，每天想搞一個關於Swift的大新聞不奇怪。。

最後非得要用一個競爭對手搞出來的語言（儘管開源了），從感情上來講難道Google不覺得有些奇怪嘛？

還有Android碎片化和開發語言是什麼根本就沒有關係的嘛

Kotlin官方打臉現場。

你說呢？

說到寫語言翻譯器，Google那個Java2Kotlin的翻譯器問題都一堆一堆的，你覺得把Swift翻譯成Kotlin成功率很高？

我上次親自試驗Java2Kotlin，位運算出車禍了，static方法出車禍了，companion object出車禍了。。。

不過順帶一提，那個翻譯器很好地理解了data class，讓我很愉快。

還有，都有Kotlin了，Swift一邊去~

碎片化是指第三方太多，和編程語言毛關係沒有。

Naive

只能說谷歌要放棄Java是真的。

另外安卓碎片化指的是解析度和os版本的碎片化，編程語言再怎麼多，編譯出來都是dalvik位元組碼。Naive。

現在android L的份額不過在1/4左右，兼容性表示日狗，一大票dever看著SDK manager表示日狗。不過好處是有足夠的緩衝時間，因為，用戶要跟著版本走太難了。

其次，輪子、框架的問題，dever表示在for循環里日狗。

採用swift等於放棄現在的FA層，還要改掉runtime，站在Google的立場，這跟新開發一個OS已經沒太大區別了。Swift如果要跟底層打交道（C/C++）還要oc做橋，dever再次表示日狗。。。。。。

綜上，幾年內是不可能了。

很多人都說這個是假新聞，我做為一個android程序員，後來又從事iOS開發的程序員。我說說這個事的可行性。swift為啥能替代objc，成為蘋果以後開發的首選語言，想想swift出來才多久，社區就已經這麼火爆，而且蘋果自己也不遺餘力的推，當然這裡面原因很多比如蘋果爸爸的版本控制，llvm的強大，比如蘋果用swift做了新的foundation並對uikit介面做了適配，允許swift和objc互調，於是swift替代objc水到渠成。再說Google就沒有那麼幸運，android先由java轉化成class再由class轉化成dex再由ART轉化成本地機器碼，自從android4.4開始ART就開始出現，5.0後成為了默認運行時替代dalvik。可以想像Google花了多少力氣來干這件事。

android面對上述這麼多的編碼轉化問題，如果能用一門可以直接生成二進位的語言來做，Google可以省去很多事情。ART本身有能力將dex變成本地機器碼，如果結合llvm是不是可以把swift也轉成android可以跑的，邏輯上是可行的。網上有demo

http://romain.goyet.com/articles/running_swift_code_on_android/ 我試過可以用ndk-r10d跑起來，最新的r11c裡面的沒有llc所以沒能編譯通過。

這個demo的特點是將swift通過so的方式給android用，本質上宿主還是java runtime。不過它給我們的啟示是可行的，只要我們把android的sdk以native的方式暴露並提供一套互調機制即可，同時讓android在安裝過程中可以直接裝本地機器指令的包，而不用dex來繞一圈。

當然實現起來難度咱不是磚家，不好給論斷。

更新

facebook工程師把swift的標準庫遷移到了android的armv7，也就是上面的demo可以使用swift的標準庫里的東西

具體參考：https://github.com/apple/swift/blob/master/docs/Android.md

Kotlin 才剛開始發力你和我說你選的是 Swift？！！

兩者間個人更支持 Kotlin，感覺新聞的可靠性也值得懷疑。Swift 無法像 Kotlin 一樣與原有的 Java 生態圈交融，而單純從語法上來講（Kotlin 和 Swift 的語法有很多相似點），Kotlin 已經足夠地解放了開發者的生產力，沒必要拋棄 Java/JVM 生態圈（各種 Android 類庫）投奔 Swift。

再者，將 Swift 作為 First class langue 的工作量應該挺大的，大概也要花上很長一段時間了。至於其他答主說的 Swift compile to Java Bytecode 是不大可能的。一方面是 Swift 語法上並沒有針對 JVM(/Dalvik/ART) 進行適配，可能會產生一些坑（例如泛型），再者就是如果真打算這樣做的話，Google 應該是腦進水才不直接選擇 Kotlin。。。

愚人節也過去好些天了吧。。。swift 連 iOS 開發自己那一分三畝地都還遲遲不能包圓了谷歌會腦殘到用它嗎。。。

如果是真的，，

吼啊！！！

我就不明白多個語言有什麼問題。。

支持編譯成native code的語言也有那麼多，我怎麼沒見你們說Windows/OS X碎片化呢。。

丫還不如直接用C#呢…而且蘋果現在對Google的態度是寧可跟MS合作也不能讓丫得到好處…

假的。

我說中國即將使用美國法律判案，你信嗎？

不可能的，假新聞而已。

我覺得是有這樣的可能性的

1.java 上和oracle 的糾紛 google已經是看不下去了。迫切想找到一種新的東西去替代現在的java。golang 出現原來也有一部分這樣的動機。但是一個語言同時適配兩個平台，畢竟難度比一個語言適配一個平台要難。只有兩種方案 java 開發 ios ，swift 開發android 。我覺得第二種有可能。

2.java 在技術上比較老舊，起初是個小腳本的語言，後來發展成服務端語言，整個過程中語言特性有很多歷史負擔，非常不利於優化。在移動設備上問題更明顯，就是能耗（死穴）

3.android 要找一種語言去改變這個現狀,除swift 外c++是一個最可行的語言。重新做個android 表現層，提供出兩套介面一套 java 和一套 c++介面（java 在更上一個層次橋接c++介面）。這樣做同時可以兼容 java 的應用，另一方面可以使用c++ 開發高效的app。
為什麼不選除c++外的其他的語言？
*你們公司的HR，能不能找到人幫你做事情。人才市場上有充足的人
*c++開發出來的大部分邏輯代碼都可以和 ios,win 重用解決管理問題

4.swift 的出現，其實是更好地解決了上面兩個帶 *號的問題，而且可以兼顧了ios開發。人解決了而且可以招更少的人，管理起來項目風險更小。

如果要swift開發android.其實是在於google怎麼去看待控制權這個問題，swift 在android開發的可行性我覺得是很高的。

你們媒體千萬要記得，不要見的風就是雨。

等Swift可以編譯成JVM識別的位元組碼，或者可以和C/C++直接交互，讓C/C++做介面給安卓調用的時候，還真的有可能。

第一種可能性不大，蘋果肯定不願意這麼做。

第二種可能性也不大，工作量太大，而且現在用OC做中間層已經能解決部分問題了。

其實還有一種可能，就是谷歌重新開發一個Android平台，支持Swift，但是你覺得可能嗎？

這是有一定可信度的蘋果在去年年底就將swift開源了就此以吸引其他公司來支持swift 而Google uber Facebook這三家巨頭也曾在倫敦討論過這個新語言 Google考慮過將swift列為android首要語言 Facebook也打算將此作為運作核心對於Facebook而言 swift可以用在伺伺服器端也能面向前端一致性更高對於Facebook這種需要各種服務對介面的應用也比較適合而且 Facebook的工程師在Github開了Port to android 的pull request 雖然Facebook官方沒有回應但明顯是一個訊號

目前android的首要開發語言雖然是java 但由於Google與甲骨文之間的java編程語言上的爭議所以Google換用開發語言語言是一定的而 swift本來就是開源的所以android不必改變它開源的手機架構

與swift同樣注重安全性的jam語言Kotlin雖然已經支援Android整合開發環境Android Studio 但是Kotlin編寫程式較慢所以由此看Google可能會更偏向青睞Swift

但是swift不能被直接應用到其他系統上 Google必須為他開發一個Swift的運行時庫還要把app開發庫移植到swift上以及軟體開發結構和開發包同時Android的底層API是用C++編寫的所以swift目前是無法連接的一些高階的java API也需要重寫但是如果Google肯下苦功夫這並非難事知名的軟體開發者Romain Goyet就曾用Swift來開發Android軟體

就個人而言我認為swift還是比較親和的它沒有又臭又長的參數設定對於開發者而言能夠使用同一種語言為兩大移動平台編寫應用會節省大量的成本與精力

當然 swift暫時不會取代java的重要地位

絕逼假的，原因很簡單，代價太大

信仰感人。它自家都沒幾個人用，還指望別人用？開什麼玩喜。