作者 | Jeremy Rempel
譯者 | 蘇本如
責編 | 屠敏
出品 | CSDN(ID:CSDNNews)
以下為譯文:
基於歷史原因,移動應用一直以來都要求在2個或更多不同的平臺和工具包上進行開發。包括但不限於:
邏輯抽象和公共代碼共享以便在不同的功能上重用並不是一個新概念,在現代計算的起步階段就有了。相比之下,iOS和Android的出現才剛過10年,還處於起步階段。
為什麼我們需要跨平臺解決方案?
iOS和Android平臺都非常複雜,開發者要在某一個平臺上成為專家需要數年的時間。掌握每個平臺需要懂得兩種官方支持的程式語言、硬體知識、平臺SDK和各種各樣的支持庫。希望同時支持iOS和Android應用程式的組織和公司必須至少要維持兩個開發團隊,因為同時擁有兩個平臺的豐富經驗的開發人員是非常罕見的。兩個開發團隊都試圖保持應用程式在兩個平臺的功能對等,在修補缺陷的同時仍然能夠利用每個平臺的優勢,這就導致開發團隊的進一步的碎片化。而具備平衡各個平臺的複雜性,降低平臺的衝突,有選擇性地跨平臺共享公共邏輯的能力,就能夠使團隊集中精力,為真正重要的用戶提供所需的功能和價值。
用戶體驗
從用戶的角度來看,移動體驗是他們在移動應用上能夠看到和交互的一切。用戶並不知道或並不關心應用程式使用的語言、框架或者使用了何種web服務。用戶與應用程式的交互是通過屏幕、通知、平臺以及與藍牙、傳感器和攝像頭等硬體的交互來進行的。蘋果和谷歌都在各自的平臺上進行了大量投資,並使其各具特色。每一次年度更新都會帶給我們新的功能、新的API以及諸如手錶、可彎曲電話、電視等等目標設備。
用戶體驗主要指的是UI和它與原生系統SDK的集成、以及性能和其他能力(如離線支持)。任何有使用限制,和在原生平臺上需要額外抽象的移動框架都會阻礙開發人員充分利用整個平臺的優勢,從而導致用戶體驗受損或額外的開發開銷。能夠使一個應用程式別具特色並為用戶帶來價值的是用戶與之交互的方面,如UI、Notification(通知)以及和系統其它部分的集成。而UI後面的應用層(如業務邏輯、REST端點、緩存、JSON序列化和依賴注入)則與平臺的相關性並不大。
理想平臺
一個理想的平臺應該具備如下特點:
應該能夠集成到現有平臺構建工具鏈和持續集成的基礎架構中
應該能夠以最小的代價,充分利用底層平臺API和語言,尤其是面向用戶的組件,如UI和Notification(通知)
應該能夠無縫集成,而不引入額外runtime的開銷
在IDE支持、編譯器和lint代碼檢查方面提供一流的工具支持
有成熟社區和第三方庫的支持
Flutter(註:谷歌的移動UI框架)
Flutter之於移動應用就像Silverlight之於Web應用一樣。它整合了自己的庫、語言和頁面渲染。Flutter是由谷歌的一個獨立於Android的團隊開發的,它使用DART程式語言,目標是通過直接寫入視圖層,並提供自己的SDK,UI widget(小部件),runtime和編程環境,來開發出一個通用的開發平臺和SDK。Flutter的主要目的是取代而不是擴充Android和SDK框架。它的主要應用場景是希望以一致的UI界面運行在多個平臺上的新的待開發的項目。雖然Flutter可以提供高性能體驗,但是對於期望使用每個平臺獨特功能的複雜應用,跨平臺提供一致的外觀和體驗是很有挑戰性的。巧合的是,最受歡迎和討論最多的Flutter應用程式之一,Hamilton並沒有使用Material或Cupertino組件。
Dart:谷歌之外很少見到的小眾程式語言。現有開發人員需要重新培訓,招募新人不容樂觀。
Flutter SDK:目標是替換而不是補充原生SDK。
React Native
React是一個由Facebook開發的Javascript UI框架,用於開發現代單頁web應用(SPA)。React使用聲明性的方式描述UI。由於更新DOM樹的成本很高,框架將接收到所需的UI作為輸入,而React框架將比較新舊DOM之間的差異,並且只執行所需的更新。
React Native使用React框架。但是它的目標不再是HTML,而是原生Android和iOS平臺的SDK。React Native Javascript的runtime將通過bridge(橋接器)與原生框架異步通信。雖然它的目標是給兩個平臺提供最好的框架,但結果是喜憂參半的。React Native的最大貢獻是它充分利用並增強了底層移動平臺,而沒有取代它們。
React Native的主要缺點
Javascript:不管你是愛它還是恨它,Javascript已經成為最流行的語言之一,但它會引入第三方語言生態系統。要想在iOS和Android上成功部署或調試一個複雜功能,開發人員必須了解第三方語言和runtime。這種級別的抽象還引入了另一個要調試和支持的層。
Bridge(橋接器):原生模塊和本機代碼之間的任何通信都是通過橋接器完成的。這可能導致複雜的集成,並帶來性能損失。
依賴項:React Native引入了許多依賴項,導致無法在Android上支持X64等問題。詳見 https://stackoverflow.com/questions/48732351/react-native-app-64-bit-version 。React Native是一個大型平臺,它在原生平臺上引入了許多限制,從而導致安全性和可維護性問題。
Kotlin Native
Kotlin Native是由Kotlin程式語言的創建者Jetbrains開發的一個編譯器和一組庫。Kotlin Native旨在通過將代碼編譯成原生二進位文件並儘可能與原生平臺緊密集成來解決代碼共享問題,減少衝突,它並不是引入另一個runtime、語言或工具鏈。谷歌已經宣布將Kotlin作為Android開發的官方語言,因此大多數Android團隊都公開接受它。不過,Kotlin對iOS開發來說顯然是一門外語,但它與Swift、JavaScript和DART語言的相似性增加了它的內聚力。
與其他競爭框架相比,Kotlin Native的主要優勢在於GUI、傳感器、Notification以及每種設備獨特的內容都能以原生語言開發和無限制的運行平臺。與Flutter和React Native的解決方案相比,Kotlin Native解決方案減少了障礙並避免了損害。
在Android上,公共模塊使用原生構建工具組裝到最終的APK中。在iOS上,公共模塊被編譯到單個原生庫中,並使用原生構建工具鏈和原生IDE組裝到應用程式中。與React Native類似,Kotlin Native將嘗試利用底層平臺,並使開發人員能夠基於特性或組件定義Seam,以及決定哪些特性應在特定平臺或者在Kotlin Native上開發。Kotlin Native提供一個選項但並不強迫跨平臺共享代碼。
總結
移動計算的歷史是一個代碼分享和站在巨人肩膀上的歷史。隨著手機在我們的日常生活中變得越來越強大和無處不在,我們構建的移動應用將會越來越多,越來越複雜。能夠跨平臺共享代碼在未來將變得更加重要。Kotlin Native仍然是早期的測試版,並非沒有問題和挑戰,但無論如何,它都將成為未來跨平臺開發最實用的解決方案。
原文:https://medium.com/android-things/why-we-need-kotlin-native-adacc03e988c
本文為 CSDN 翻譯,如需轉載,請註明來源出處。作者獨立觀點,不代表 CSDN 立場。
熱 文 推 薦
☞當我們談資料庫時,是在談什麼?
☞Windows 7,難說再見
☞@程式設計師,Web 開源神器了解一下? | 程式設計師硬核評測
☞日本高中生開發酷炫「扔瓶子」機器人,想砸誰就砸誰
☞蘋果春季發布會:庫克絕不玩別人玩剩下的!
☞在線公開課 | 從理論走向實踐,多角度詳解Cloud Native
☞中國區塊鏈職業發展現狀: 30歲前不做開發; 平均薪資僅38.4萬; 跳槽薪資漲三成 (附完整報告下載資源)
☞上海交大CV博導微信群辱罵學生,已停止教學
☞現實!程式設計師只有跳槽才能漲薪嗎?
System.out.println("點個在看吧!");
console.log("點個在看吧!");
print("點個在看吧!");
printf("點個在看吧!\n");
cout << "點個在看吧!" << endl;
Console.WriteLine("點個在看吧!");
Response.Write("點個在看吧!");
alert("點個在看吧!")
echo "點個在好看吧!"
點擊閱讀原文,輸入關鍵詞,即可搜索您想要的 CSDN 文章。