本文主要介紹看了就會的Harmony APP開發。 java
openharmony.gitee.com/openharmonygit
華爲鴻蒙系統,Harmony OS,是能夠在不一樣類型的終端設備上部署的分佈式操做系統。 19年華爲開發者大會正式公佈,20年華爲開發者大會發布2.0版本並開源。編程
部署於手機的鴻蒙系統應該明年初正式面世。ubuntu
「考慮到開發效率、編譯效率、運行效率、學習成本、編譯後包體積,華爲想要追求一個平衡,咱們也是在探索中。」——華爲專家windows
對於開發者而言,Harmony應用開發和Android應用開發區別不大,甚至能夠說是看了就會。安全
IDE:DevEco Studio,基於IntelliJ IDEA,目前僅有Windows版本。markdown
開發語言:Java、JS、C++!框架
具體如何進行鴻蒙應用開發,能夠參考論壇當天的截圖。mvvm
工程目錄結構能夠說和Android一模一樣: 一樣採用配置清單+java+xml的模板: xml佈局實現: 生命週期: 觸摸事件: 跨設備流轉: 項目目錄結構: 編程語言
相信在座各位Android開發者們已經大概知道如何進行Harmony APP開發了。能夠說幾乎和Android開發一致,我的認爲華爲這樣設計是共贏的:
與咱們平常接觸的Android App開發不一樣的是,Harmony App開發多了一個「跨設備流轉」——其實基本上能夠把HarmonyOS當作一個物聯網操做系統,因此華爲在論壇上花了很大篇幅介紹軟總線,較詳細地介紹了Harmony APP在多設備之間通訊的協議模型和開發方式,並展現了部分API,反覆強調「一行代碼」搞定設備無縫通訊。
協議模型: 開發模型: API示例:
這三種市面上很是主流的編程語言在安卓也是佔據了最重要的位置:
而根據華爲專家的介紹,在HarmonyOS中,這三種語言在應用開發過程當中的使用場景和Android相似,但也有所區別:
華爲以前就推出了方舟編譯器,提供了全新的系統及應用的編譯和運行機制,從動態編譯變爲靜態編譯,將Java直接編譯成機器碼,完全消除了虛擬機動態編譯的額外開銷,實現了開發和運行效率的兼容並舉。
根據專家介紹,方舟編譯器將來會支持編譯JS代碼,因此在Harmony應用開發中,JS既不是用於H5,也不一樣於React-Native這種JS調原生的機制,JS會被編譯成字節碼運行在華爲自行研發的VM上。
有點矛盾,明明說方舟編譯器將高級語言直接編譯成機器碼,爲何又說JS會編譯成字節碼運行在VM上,華爲專家的說法是兩者結合起來:
兩種編譯流派的優缺點基本互補,方舟編譯器可能採用」結合式「的編譯方案。
現場也有同窗問及華爲是否考慮在鴻蒙上提供自研的新編程語言,專家的說法是目前用於Harmony應用開發的Java+JS都更像是現有編程語言的一種子集加強版本,而不是一種新語言。
關於自研新編程語言,華爲須要基於HarmonyOS的發展狀況再做考慮:編程語言須要考慮開發效率、編譯效率、運行效率、學習成本、編譯後包體積等等,而華爲想要追求一個平衡,目前也是在探索中。
在自研操做系統、編譯器的過程當中,華爲老是強調」結合「、」平衡「,感受也是比較有野心,想要創造出比現有技術更牛逼的一套體系。
HarmonyOS能夠兼容Android App的運行,專家說是兩個操做系統並在一塊兒運行,我的推測就是在鴻蒙下面開個模擬器,相似於windows電腦也能夠開個ubuntu。
但純鴻蒙應用是確定沒法運行在Android系統上的。
但考慮到HarmonyOS在多設備上的各類頗具吸引力的新特性(暫時只在PPT裏看到效果),假如往後HarmonyOS有至關的市場佔有率,那麼部分APP確定會有遷移至鴻蒙的必要性,華爲提供了兩種移植思路:
部分改造:將已有的某個模塊功能 基於鴻蒙上從新實現,從而可讓用戶體驗到APP在HarmonyOS的新特性。
增量改造:新增一些基於HarmonyOS實現的功能模塊,好比提供手錶等其餘設備版本的應用等。
以上就是上週五週六參加華爲開發者大會的HarmonyOS應用開發論壇的所見所聞,但願能夠幫助你們初步瞭解鴻蒙是怎麼樣的一個操做系統以及鴻蒙應用開發的方式。