HarmonyOS到底是不是Android套皮？
某人曾說「沒有調(diào)查就沒有發(fā)言權(quán)」 最近鴻蒙系統(tǒng)關(guān)注度好高，支持與反對、看好和看衰、「自主的全場景分布式系統(tǒng)」和「Android套殼」各執(zhí)一詞，吵的不可開交。 作為十八流碼農(nóng)，本著了解行業(yè)動態(tài)、體驗HarmonyOS開發(fā)流程、找出HarmonyOS的特性與不足、看看是否有新的機會，也為了看看吵得不可開交的諸位誰說得對，特地在這個鴻蒙系統(tǒng)馬上正式開放升級的時間點，開發(fā)體驗了一番。 HarmonyOS到底怎么實現(xiàn)的——扒皮HarmonyOS
了解一個軟件怎么實現(xiàn)的，最好還是查看源代碼。 但是承諾2020年開源的OpenHarmony項目到現(xiàn)在只開源到嵌入式設(shè)備，這條路自然走不通。 只好退而求其次，看看已經(jīng)開放的SDK、IDE、開發(fā)示例、編譯產(chǎn)物，管中窺豹一下HarmonyOS到底怎么實現(xiàn)的。
00 安裝IDE-配置環(huán)境-編譯運行
這部分很簡單，下載DevEco Studio，然后照著文檔一步步操作就好了。 模板選擇了唯二的JS模板：Phone > Refresh Feature Ability。 然后一直下一步，申請下虛擬機，編譯運行就成功了。
01 分析編譯產(chǎn)物
運行成功后，先大致分析一下編譯產(chǎn)物，找一下程序入口，看看代碼到底怎么運行的。 點開build文件夾，打開一看，喔噢！！！這目錄結(jié)構(gòu)和Android的太相似了，于是我熟練的點開outputs文件夾找apk文件。 .hap？？？怎么和預(yù)想的不一樣？不過侵淫Linux多年的經(jīng)驗告訴我，后綴都是浮云，于是果斷把.hap改成.apk，然后用Android Studio打開，果然：
對比官方給出的App邏輯視圖： 我們發(fā)現(xiàn)： 估計是因為工程只定義了一個Entry，沒有定義Feature，于是只生成了Entry的安裝包，但是按照官方文檔給的說法
Entry可以獨立安裝運行，在只定義一個Entry的情況下，編譯出這種包也說得通
3、App邏輯視圖中的abilities竟然編譯成Android包的.dex執(zhí)行文件，而用js定義的界面、視圖、邏輯竟然歸入assets中，這里面就有點貓膩了
4、編譯的可執(zhí)行文件中竟然包含一個.apk文件，這個不速之客可在App邏輯視圖中完全沒體現(xiàn)，值得懷疑
于是接下來，我們就先重點分析這個entry_signed_entry.apk，分析一下這個不速之客在App安裝包里有什么作用
02 分析entry_signed_entry.apk
繼續(xù)用Android Studio打開這個文件 是一個標(biāo)準(zhǔn)的Android App！！于是熟練的點開Android應(yīng)用描述文件：AndroidManifest.xml 通過描述文件可以發(fā)現(xiàn)，整個apk只做了兩件事： emmmmm……這名字起得真直白 按照Android開發(fā)的慣例，從build文件夾中找這兩個類的相關(guān)文件。 果然不費吹灰之力，接著分析源代碼： 先分析一下Application的定義文件ShellMyApplication： ShellMyApplication繼承自HarmonyOS SDK的AceHarmonyApplication，不過啥事都沒干，接著看AceHarmonyApplication： emmmmm……俄羅斯套娃嗎？照樣啥事也沒干，那就接著找它的父類： HarmonyApplication： 看這么大段的引用和變量定義，應(yīng)該是正主沒錯了，不過HarmonyOS的HarmonyApplication竟然繼承自Android的Application，這件事就得說道說道了HarmonyApplication整個文件很長，就不貼代碼了，這個類主要做了如下幾個工作： 1、初始化HarmonyOS應(yīng)用... 2、輸出HarmonyOS應(yīng)用開始初始化的日志...... 3、加載HarmonyOS的Ability到Android的Application的HashMap中.........
4、接收系統(tǒng)產(chǎn)生的各種事件然后轉(zhuǎn)發(fā)給鴻蒙應(yīng)用............
5、初始化一個EventRunner，結(jié)合ohos包的代碼來看，估計就是官方文檔提到的「分布式軟總線」，是HarmonyOS所謂的「分布式設(shè)計」的相關(guān)實現(xiàn)，這部分后面分析
碼農(nóng)果然都是老實人，起名都這么實誠又恰如其分： ShellApplication的作用就是Android的Application提供一個Shell（殼），讓HarmonyOS的Application寄生其中 接著來看看MainAbilityShellActivity，依舊是套娃設(shè)計，直接看具體的實現(xiàn)： MainAbilityShellActivity依舊繼承自Android的Activity，整個文件依舊很長，但是邏輯很簡單，就一個作用： 將Android的MainActivity的生命周期、Intent、觸摸事件、按鍵時間、權(quán)限申請結(jié)果……通過AbilityShellActivityDelegate（代理）轉(zhuǎn)發(fā)給HarmonyOS的Ability 果然不負Shell之名。本來想打開Androi……HarmonyOS的應(yīng)用布局調(diào)試界面，但是設(shè)置里找不到了，233333…… 不過根據(jù)我的第一個鴻蒙app，以及所見內(nèi)容,得知 這篇文章2020年末寫的，到如今只過去五個月，估計具體實現(xiàn)沒有改變。 03 分布式軟總線
HarmonyOS最大的賣點是其宣稱的「面向萬物互聯(lián)時代的全場景分布式操作系統(tǒng)」，也是其最大的特性。 從官方文檔來看，不管是開發(fā)層面所謂的「分布式設(shè)備虛擬化」、「分布式數(shù)據(jù)管理」、「分布式任務(wù)調(diào)度」，還是目前官方演示的「無縫流轉(zhuǎn)」、「多屏協(xié)同」都是以「分布式軟總線」為通訊基座，因此我們重點來找找它是怎么實現(xiàn)的。 具體到開發(fā)文檔中，沒有發(fā)現(xiàn)關(guān)于「分布式軟總線」的API，只找到三個與其「分布式技術(shù)」所描述的特性相似的三個功能： 分別是：
不過我們只是為了看一下HarmonyOS的設(shè)計思想，又不研究它具體實現(xiàn)，所有也用不著源代碼，直接看類名、函數(shù)名、依賴關(guān)系，大膽猜測、小心驗證一下就好了
ohos.rpc.*
04 「分布式軟總線」具體設(shè)計
05 其他
https://gitee.com/openharmony/ace_engine_lite
01 華為到底在HarmonyOS上做了哪些工作
具體到示意圖，估計就是：
隨時換掉AOSP，這里的「隨時」，估計在近五年內(nèi)不會實現(xiàn)，在此之前，去掉Android虛擬機，HarmonyOS能不能正常運行，我是持懷疑的態(tài)度的 「全場景分布式操作系統(tǒng)」，根據(jù)「分布式軟總線」相關(guān)代碼，這里的「全場景」，估計是同一個局域網(wǎng)內(nèi)的「全場景」、同一個局域網(wǎng)內(nèi)的萬物互聯(lián)
02 HarmonyOS到底是不是Android套皮
特修斯之船（The Ship of Theseus）亦稱為忒修斯悖論，是一種有關(guān)身份更替的悖論。假定某物體的構(gòu)成要素被置換后，但它依舊是原來的物體嗎？說是一艘可以在海上航行幾百年的船，歸功于不間斷的維修和替換部件。只要一塊木板腐爛了，它就會被替換掉，以此類推，直到所有的功能部件都不是最開始的那些了。問題是，最終產(chǎn)生的這艘船是否還是原來的那艘特修斯之船，還是一艘完全不同的船？如果不是原來的船，那么在什么時候它不再是原來的船了？
03 HarmonyOS能實現(xiàn)華為的目標(biāo)嗎？
00 系統(tǒng)優(yōu)勢
1). HarmonyOS雖然號稱可以使用Java、JavaScript、C寫UI界面且UI界面可以跨設(shè)備，但目前在實際開發(fā)中，不同設(shè)備支持的語言是不同的：
在手機設(shè)備上，只能使用Java、JavaScript寫界面（相關(guān)文檔 ：Java UI框架、JS UI框架 兩部分） 在嵌入式設(shè)備上，只能使用C、JavaScript寫界面（相關(guān)文檔 ：JS應(yīng)用開發(fā)、系統(tǒng)基礎(chǔ)子系統(tǒng)集>圖形及UI子系統(tǒng) 兩部分） 只有JavaScript寫的界面可以跨設(shè)備使用
https://gitee.com/openharmony/ace_engine_lite
JS引擎（JS runtime）是三星開源的IoT JavaScript引擎：JerryScript
除JS引擎外，其他應(yīng)該都是華為自己寫的 JS應(yīng)用框架只負責(zé)解析JS Bundle（我們用JS寫的界面編譯后的產(chǎn)物），渲染交給了有C寫的原生框架 因此C原生框架不可能跨設(shè)備，只能在LiteOS中使用 手機端能不能使用這個C原生UI框架未知，但是開發(fā)文檔上沒有提及，應(yīng)該是還沒有開放或?qū)崿F(xiàn)（是哪一個不太清楚，但是嵌入式設(shè)備與手機UI框架的實現(xiàn)難度不是一個數(shù)量級，LiteOS上的C語言UI框架應(yīng)該滿足不了手機上的復(fù)雜且苛刻的要求，所有不可能直接使用）
JS Bundle由JS Framework解析后將數(shù)據(jù)交給了Android，由Android的負責(zé)將其渲染在SurfaceView上
User Native Ability在LiteOS中指的就是C語言實現(xiàn)的Ability；在HarmonyOS中就是Java實現(xiàn)的Ability AbilityKit在LiteOS中應(yīng)該是用C語言自己實現(xiàn)的，但在HarmonyOS中，是基于Android的Activity實現(xiàn)的 圖中的藍色部分在LiteOS中很明確，但在HarmonyOS中怎么實現(xiàn)目前沒有相關(guān)代碼，不得而知（個人猜測，根據(jù)上面代碼分析，有部分在ShellApplication（應(yīng)用內(nèi)）實現(xiàn)，有部分為系統(tǒng)服務(wù)，也有部分在內(nèi)核中實現(xiàn)）
Linux Kernel（在內(nèi)核層中） AOSP（大致對應(yīng)圖中的UI框架+用戶程序框架+Ability框架）
在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，可以支持更多的平臺（HarmonyOS vs Android+IOS） 在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，開發(fā)成本更低（小程序 vs App） 在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，推廣成本更低（微信小程序生態(tài) vs 華為App生態(tài)） 在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，獲客成本更低（即開即用 vs 下載、安裝App） ……
01 商業(yè)運作
02 生態(tài)建設(shè)
華為終端能否活到那個時候。這方面要看華為芯片問題能否解決、HMS在缺少關(guān)鍵應(yīng)用的時候是否有人依舊選擇華為 華為如何說服中國互聯(lián)網(wǎng)廠商拋棄GMS擁抱HMS。因為兩個生態(tài)都支持的話HMS對GMS依舊沒有話語權(quán)與競爭力
https://developer.huawei.com/consumer/cn/ https://dev.mi.com/console/ https://open.oppomobile.com/ https://dev.vivo.com.cn/home?cid=w-2-baidu-sem-kfpt-qt
對于絕大多數(shù)物聯(lián)網(wǎng)設(shè)備，沒有這么奢侈的硬件去運行HarmonyOS的物聯(lián)網(wǎng)系統(tǒng)，也并沒有這么多交互需要界面去實現(xiàn)，那么采用LiteOS，就意味著對其沒有什么幫助還徒增成本（其他物聯(lián)網(wǎng)系統(tǒng)有更通用的解決方案，成本也更低） HarmonyOS更加私有化的封裝也意味著與其他的物聯(lián)網(wǎng)系統(tǒng)打通更加的困難，華為估計沒有能力做的所有物聯(lián)網(wǎng)設(shè)備都采用鴻蒙系統(tǒng)，那么HarmonyOS與為鴻蒙系統(tǒng)物聯(lián)網(wǎng)設(shè)備的交互也更加困難 個人認為物聯(lián)網(wǎng)設(shè)備的互聯(lián)互通與相互控制并不是解決目前物聯(lián)網(wǎng)產(chǎn)業(yè)困境的關(guān)鍵。目前，物聯(lián)網(wǎng)產(chǎn)品的解決方案大多都是講控制權(quán)交給手機App或者語音，但這些并沒有多少方便我們的生活，有點食之無味、棄之可惜的味道
（這個問題太大了，需要考慮的問題太多，能力有限，既考慮不全，也表達不太清楚，不往下寫了）
來源：21ic電子網(wǎng)，頭條@我的小號等，本文作者觀點不代表本網(wǎng)觀點
PS：歡迎在留言區(qū)留下你的觀點，一起討論提高。如果今天的文章讓你有新的啟發(fā)，歡迎轉(zhuǎn)發(fā)分享給更多人。
評論
圖片
表情