OpenHarmony使用Stage模型和FA模型開發分布式應用時的差別
前言
筆者這兩個月一直在折騰分布式應用,并且分別基于API8的FA模型以及API9的Stage模型進行了開發,這兩天總算是基本開發完了,閑下來總結下這兩者的區別,順便跟大家嘮嘮開發時踩過的坑
請求權限
Stage模型中配置文件由FA模型的config.json改為module.json5,同時一些字段名也發生了改變,例如reqPermissions就改為requestPermissions(好像這個區別并不是很起眼,但就是因為之前我有一個朋友在使用Stage模型開發時直接復制了FA模型的請求權限代碼,而我一開始也沒看出來哪里有問題,因為只差了幾個字母,后來我手敲代碼才找到了問題所在??)。
FA
Stage
獲取Context
FA
Stage
Stage模型中包含多種Context,比較常用的有AbilityContext和在eTS頁面中訪問Context,更多詳見參考資料[1]。
- AbilityContext
Stage模型下,每個Ability中都包含了一個Context屬性。
在繼承Ability的類中通過this.context?就可以獲取AbilityContext,從而操作Ability的方法(如startAbility、connectAbility等)。
- 在eTS頁面中訪問Context。
接口名 | 描述 |
getContext(component: Object): Object | 獲取頁面中component所關聯的Context對象。 |
啟動Ability
FA
Stage
1.Stage模型不再使用featureAbility接口,而需要先獲取當前Ability的上下文,再由AbilityContext調用startAbility方法。
2.相比FA模型少了一對{}括號。
3.MainAbility改名為EntryAbility,且abilityName不再是由package + Ability name組成。
結語
由于開發時部分接口在API9以上才提供,所以需要將應用API升級到9。但其實API9也提供了FA模型,只需要在API8的基礎上進行小部分修改即可,那筆者為何還花費大量精力去折騰Stage模型呢?一個是想體驗一下這兩者在開發上的差別,另一個是未來將不再主推FA模型,現在學習的成本沒有以后的成本高。筆者在開發時還發現許多接口將被廢棄,例如Ability,將會用UIAbility代替,不過接口基本上不會有很大改變,都是改個名字、加個參數之類。