
??想了解更多關(guān)于開源的內(nèi)容,請訪問:??
??51CTO 開源基礎(chǔ)軟件社區(qū)??
??https://ost.51cto.com??
前言
本文基于OpenHarmony源碼梳理應(yīng)用的啟動過程,介紹appspawn/ability_runtime/ace_engine/ets_runtime等重要模塊的初始化流程,以及它們之間的相互關(guān)系。
不同形態(tài)的hap應(yīng)用在具體細節(jié)上會有一些差異,但整體的流程上是一致的。本文基于OpenHarmoney 3.2標準系統(tǒng) FA模式的ets應(yīng)用進行闡述。
1、應(yīng)用啟動整體流程
查看各個進程的父子關(guān)系可知,OpenHarmony的系統(tǒng)應(yīng)用和用戶應(yīng)用進程,都是由應(yīng)用孵化器(appspawn)拉起的。

應(yīng)用啟動的整理流程如下圖所示:

說明: 應(yīng)用啟動時,appspawn進程會fork出一個應(yīng)用子進程,創(chuàng)建AceAbility實現(xiàn)類和AceContainer。AceContainer初始化過程中會在JS線程中創(chuàng)建JS運行環(huán)境,包括JsEngine、NativeEngin、ArkJSRuntime、JSThread、EcmaVM等重要組件。
2、啟動流程詳解
(1)appspawn 創(chuàng)建應(yīng)用進程

應(yīng)用日志:
08-05 17:58:11.955 255-255/appspawn I C02c11/APPSPAWN: [appspawn_service.c:408]child process com.example.myapplication success pid 2345
關(guān)鍵代碼流程:
// base\startup\appspawn\standard\appspawn_service.c
APPSPAWN_STATIC void OnReceiveRequest(const TaskHandle taskHandle, const uint8_t *buffer, uint32_t buffLen)
AppSpawnProcessMsg(sandboxArg, &appProperty->pid);
// base/startup/appspawn/common/appspawn_server.c
int AppSpawnProcessMsg(AppSandboxArg *sandbox, pid_t *childPid)
if (client->cloneFlags & CLONE_NEWPID) {
pid = clone(AppSpawnChild, childStack + SANDBOX_STACK_SIZE, client->cloneFlags | SIGCHLD, (void *)sandbox);
pid = fork(); // fork出應(yīng)用進程
*childPid = pid;
if (pid == 0) { // 子進程流程執(zhí)行
AppSpawnChild((void *)sandbox);
int AppSpawnChild(void *arg)
struct AppSpawnContent_ *content = sandbox->content;
DoStartApp(content, client, content->longProcName, content->longProcNameLen);
// notify success to father process and start app process
NotifyResToParent(content, client, 0);
content->runChildProcessor(content, client); // 進入應(yīng)用主線程 (ability_runtime 的 MainThread)
}
(2)應(yīng)用主線程初始化Ability

應(yīng)用的整體狀態(tài)流轉(zhuǎn)是由Ability實例對象來控制完成的。因此應(yīng)用進程拉起時,會先創(chuàng)建出Ability。不同的應(yīng)用模型在這里會創(chuàng)建不同的實例類型:
// foundation\ability\ability_runtime\frameworks\native\ability\native\ability_impl_factory.cpp
// AbilityImplFactory::MakeAbilityImplObject() 方法:
switch (info->type) {
case AppExecFwk::AbilityType::PAGE:
if (info->isStageBasedModel) {
abilityImpl = std::make_shared<NewAbilityImpl>();
} else {
abilityImpl = std::make_shared<PageAbilityImpl>();
}
break;
case AppExecFwk::AbilityType::SERVICE:
abilityImpl = std::make_shared<ServiceAbilityImpl>();
break;
case AppExecFwk::AbilityType::DATA:
abilityImpl = std::make_shared<DataAbilityImpl>();
break;
AbilityImpl實例創(chuàng)建后,應(yīng)用開始進入Start狀態(tài),觸發(fā)AceAbility::OnStart()回調(diào)。在該回調(diào)中,會創(chuàng)建JS運行環(huán)境。
(3)AceContainer初始化
AceContainer初始化可分為兩個階段:
第一個階段創(chuàng)建JS運行時環(huán)境(js_engine, native_engine, ets_runtime);
第二個階段調(diào)度js_engine開始讀取js字節(jié)碼文件(xxx.abc)
階段一:創(chuàng)建JS運行時環(huán)境

這里的代碼流程比較長… 具體調(diào)用過程見上圖說明。講幾個主要的點:
- AceContianer初始化時會創(chuàng)建一個任務(wù)執(zhí)行線程 FlutterTaskExecutor,這就是后續(xù)js代碼的執(zhí)行線程。 應(yīng)用主線程把需要在js線程中執(zhí)行的代碼包裝成task,放到FlutterTaskExecutor中去執(zhí)行。
- 創(chuàng)建Js引擎時可以選擇不同的引擎類型,這是在源碼編譯階段由宏開關(guān)控制的。
\foundation\arkui\ace_engine\frameworks\bridge\declarative_frontend\engine\declarative_engine_loader.cpp
RefPtr<JsEngine> DeclarativeEngineLoader::CreateJsEngine(int32_t instanceId) const
{
#ifdef USE_V8_ENGINE
return AceType::MakeRefPtr<V8DeclarativeEngine>(instanceId);
#endif
#ifdef USE_QUICKJS_ENGINE
return AceType::MakeRefPtr<QJSDeclarativeEngine>(instanceId);
#endif
#ifdef USE_ARK_ENGINE
return AceType::MakeRefPtr<JsiDeclarativeEngine>(instanceId);
#endif
}
宏開關(guān)在如下配置文件中定義:
foundation/arkui/ace_engine/adapter/ohos/build/config.gni。
engine_defines = [ "USE_ARK_ENGINE" ]
- ArkNativeEngine初始化時創(chuàng)建了NAPI層的各個重要組件(moduleManager, scopeManager, referenceManager, loop…)
- ArkNativeEngine向js運行環(huán)境中注冊了一個"requireNapi()"方法,該方法是js應(yīng)用import各種NAPI庫的入口。
js代碼中的"import xxxx"在hap包編譯階段會改寫為“requireNapi(xxx)”,當(dāng)這行代碼被js引擎解釋執(zhí)行時,即會調(diào)用到 ArkNativeEngine 中注冊的requireNapi c++實現(xiàn)代碼,通過NAPI的ModuleManager 模塊完成 xxxNAPI模塊lib庫的加載。
階段二:讀取并執(zhí)行js字節(jié)碼文件

在 AceContainer::RunPage() 流程中,會依次創(chuàng)建兩個js線程的task, 分別讀取 app.abc和index.abc文件。
細節(jié)1: JsiDeclarativeEngine::LoadJs()方法中是根據(jù)傳入的*.js文件名去讀取對應(yīng)的*.abc
// foundation\arkui\ace_engine\frameworks\bridge\declarative_frontend\engine\jsi\jsi_declarative_engine.cpp
void JsiDeclarativeEngine::LoadJs(const std::string& url, const RefPtr<JsAcePage>& page, bool isMainPage)
...
const char js_ext[] = ".js";
const char bin_ext[] = ".abc";
auto pos = url.rfind(js_ext);
std::string urlName = url.substr(0, pos) + bin_ext; // 將文件名 xxx.js 替換成 xxx.abc
細節(jié)2:EcmaVM::InvokeEcmaEntrypoint() 方法中會執(zhí)行index.abc中的入口函數(shù)func_main_0, 該函數(shù)在原始的index.js文件中并沒有,是hap包編譯后生成在index.abc文件中的。
??想了解更多關(guān)于開源的內(nèi)容,請訪問:??
??51CTO 開源基礎(chǔ)軟件社區(qū)??
??https://ost.51cto.com??