当前位置:网站首页>Analysis on the adaptation layer of openharmony UI framework (I)

Analysis on the adaptation layer of openharmony UI framework (I)

2022-04-21 17:24:00 Openharmony technology community

author : Liu Yongbao

Preface

Ark development framework ( abbreviation :ArkUI), It's a set UI Development framework , Provide developers for application UI The ability to develop . Provide cross platform capabilities , Integrated classes Web Development paradigm and declarative development paradigm . The framework is divided into application layers 、 Frame layer 、 Rendering engine 、 Platform adaptation and bridging layer . This paper mainly introduces some core classes of the adaptation layer , Through the relationship diagram and process interaction description of these core classes, we can see some features of the adaptation layer .

Introduction to core classes

Class diagram

OpenHarmony-UI Analysis of frame adaptation layer ( One )_ Adaptive layer

  • AceEngine: Globally unique , Provide an instance of door dog registration 、 Garbage collection capacity , At the same time as AceContainer The container of .
  • AceContainer: seeing the name of a thing one thinks of its function , It's a container class , From the front end 、 Task executor 、 Explorer 、 Render pipeline 、 View, etc , Provides life cycle docking 、 Function scheduling interface and UI Rendering capabilities , It is a very important module in platform adaptation .
  • AceAbility: The corresponding is FA In the model PageAbility, It is visible and interactive to users Ability example .
  • Frontend: The abstraction of the front-end framework , from DeclarativeFrontend、JsFrontend and CardFrontend Inheritance to implement declarative 、 class WEB And Card The realization of the way .
  • PlatformEventCallback: Abstraction of platform event callback , Different ability Implement their respective callback interfaces . Currently only supported OnFinish and OnStatusBarBgColorChanged Callback of two events .
  • AssetManager: Abstract of resource manager , from FlutterAssetManager Realization , In the end by the FileAssetProvider Provide resource file loading .
  • AceView: Rendering generates view nodes .
  • TaskExecutor: Task manager .
  • PipelineContext: Render pipeline .
  • PlatformResRegister: Registration and management of platform resources , The rendering of platform layer is realized through interface callback .

Collaboration description

Here we take a typical APP The implementation process of window size changes to help you understand ACE How framework classes interact , See the sequence diagram :
OpenHarmony-UI Analysis of frame adaptation layer ( One )_ Kai Hong HarmonyOS_02

Step-by-step instructions :

  1. WindowImpl The window object perceives changes in the window , Call the listener's OnSizeChange Method ;
  2. according to ability ID Get the corresponding AceContainer;
  3. from AceContainer In order to get TaskExecutor Task manager ;
  4. Create tasks through task manager ;
  5. from AceContainer Get the current View;
  6. call FlutterAceView::SurfaceChanged Deal with changes in the interface ;
  7. FlutterAceView Callback AceContainer Registered viewChangeCallback Method ;
  8. viewChangeCallback from PipelineContext Render pipeline objects TaskExecutor Task manager ;
  9. Create tasks through task manager ;
  10. The task method calls the rendering pipeline PipelineContext::OnSurfaceChanged Method treatment ;
  11. The rendering pipeline finally calls the front-end framework OnSurfaceChanged Deal with changes in the interface .

Key code implementation :

AceAbility Inherited from OHOS::Rosen::IWindowChangeListener, As a listener in OnStart When starting up, ask windows Object is registered

void AceAbility::OnStart(const Want& want) {
    ...
	// register surface change callback
    OHOS::sptr<OHOS::Rosen::IWindowChangeListener> thisAbility(this);
    window->RegisterWindowChangeListener(thisAbility);
	...
}

When the interface changes ,WindowImpl::UpdateRect Call the listener's OnSizeChange Handle

void WindowImpl::UpdateRect(const struct Rect& rect, WindowSizeChangeReason reason)
{
	...
	for (auto& listener : windowChangeListeners_) {
    	if (listener != nullptr) {
        	listener->OnSizeChange(rect, reason);
    }
	...
}

AceAbility::OnSizeChange()

void AceAbility::OnSizeChange(OHOS::Rosen::Rect rect, OHOS::Rosen::WindowSizeChangeReason reason)
{
    auto container = Platform::AceContainer::GetContainer(abilityId_);
    ...
    auto taskExecutor = container->GetTaskExecutor();
    ...
    taskExecutor->PostTask([rect, abilityId = abilityId_, density = density_, reason]() {
        ...
        auto flutterAceView = static_cast<Platform::FlutterAceView*>(container->GetView());
        ...
        Platform::FlutterAceView::SurfaceChanged(
            flutterAceView, width, height, 0, static_cast<WindowSizeChangeReason>(reason));
    }, TaskExecutor::TaskType::PLATFORM);
}

Platform::FlutterAceView::SurfaceChanged()

void FlutterAceView::SurfaceChanged(
    FlutterAceView* view, int32_t width, int32_t height, int32_t orientation, WindowSizeChangeReason type)
{
    ...
    view->NotifySurfaceChanged(width, height, type);
    auto platformView = view->GetShellHolder()->GetPlatformView();
    if (platformView) {
        platformView->NotifyChanged(SkISize::Make(width, height));
    }
	...
}

viewChangeCallback() Callback function

auto&& viewChangeCallback = [context = pipelineContext_, id = instanceId_](
                                int32_t width, int32_t height, WindowSizeChangeReason type) {
    ContainerScope scope(id);
    ACE_SCOPED_TRACE("ViewChangeCallback(%d, %d)", width, height);
    context->GetTaskExecutor()->PostTask(
        [context, width, height, type]() { context->OnSurfaceChanged(width, height, type); },
        TaskExecutor::TaskType::UI);
};
aceView_->RegisterViewChangeCallback(viewChangeCallback);

PipelineContext::OnSurfaceChanged()

void PipelineContext::OnSurfaceChanged(int32_t width, int32_t height, WindowSizeChangeReason type)
{
	...
    auto frontend = weakFrontend_.Upgrade();
    if (frontend) {
        frontend->OnSurfaceChanged(width, height);
    }
	...
}

extend

OpenHarmony The development of user program is essentially the development of Ability.OpenHarmony The system is based on Ability Dispatch , Combined with the consistent scheduling contract provided by the system Ability Lifecycle management , So as to realize the scheduling of user programs .
Ability In the framework of API 8 And earlier versions FA Model .FA In the model Ability It is divided into PageAbility、ServiceAbility、DataAbility、FormAbility Several types . among :

  • PageAbility Is to have ArkUI Realized Ability, It is visible and interactive to users Ability example .
  • ServiceAbility It's also Ability A kind of , But no UI, Provide others Ability Call a custom service , Running in the background .
  • DataAbility Also no UI Of Ability, Provide others Ability Add, delete and query data , Running in the background .
  • FormAbility It's a card Ability, It is a form of interface display .

AceAbility The corresponding is FA In the model PageAbility, and AceContainer Container class collocation management . Others ability stay ACE The frame corresponds to AceDataAbility、AceFormAbility and AceServiceAbility, Use PaContainer Manage container classes , The relationship is as follows :
OpenHarmony-UI Analysis of frame adaptation layer ( One )_ Kai Hong HarmonyOS_03

Summary

  1. AceAbility It's with UI Interface Ability, Not UI Interface ability yes AceDataAbility、AceFormAbility and AceServiceAbility.
  2. AceContainer It's a container , Aggregate the front end 、 Core functions such as rendering pipeline and task executor , Equivalent to a big manager ,ability The key processes of the system must be scheduled through it .
  3. adopt Frontend、PlatformEventCallback、AssetManager and AceView And so on , Provides an abstraction of the platform , By extension , Meet the adaptation of different platforms .

Reference link

Overview of ark development framework :
 https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/ui/arkui-overview.md

Ability The framework outlined :
 https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/ability/ability-brief.md

FA Model review :
 https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/ability/fa-brief.md

OpenHarmony Source code analysis ACE:
 https://ost.51cto.com/posts/7908

For more original content, please pay attention to :  Shenkaihong technical team

Beginner to master 、 Skills to cases , Systematic sharing HarmonyOS Development technology , Welcome to contribute and subscribe , Let's move forward hand in hand to build Hongmeng ecology .

  Want to know more about Hongmeng , Please visit :

 51CTO Hongmeng technology community jointly built with Huawei officials

 https://ost.51cto.com/#bkwz

OpenHarmony-UI Analysis of frame adaptation layer ( One )_ACE_04

版权声明
本文为[Openharmony technology community]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/04/202204211631080006.html