HarmonyOS 鸿蒙Next中Ability到底是什么用途
HarmonyOS 鸿蒙Next中Ability到底是什么用途
比如EntryAbility 默认生成的，也一直说是程序入口。我以前开发安卓的，我寻思他是安卓的那种activity呢。但是后面边学边写，我发现有
@Entry
的index.ets就是入口啊，生命周期也很齐全，各种界面和逻辑也能实现，所以我现在有点搞不懂了，到底这个Ability是什么东西。看名字明明EntryAbility确实是入口啊。可我却用不到他。
还有就是鸿蒙开发是不区分逻辑和layout吗。
我跟着教学敲了一个简单的东西。但是吧，感觉界面和逻辑怎么在一起呢。不像安卓那种有个layout文件，后面再加到逻辑界面里。进行数据填充。好像鸿蒙的开发全是类似安卓自定义控件那种。所有界面都属于自定义，然后代码动态addView进去。不知道这么理解对不对，还是我开发的东西太简单。没看到他的全貌。对就这意思。我有点不懂他的全貌了，毕竟我学的可能还是太皮毛。有没有大佬可以稍微给我补充一下全貌。细节我可以查。这个全貌站的太低，有点看不到。更多关于HarmonyOS 鸿蒙Next中Ability到底是什么用途的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
你可以理解为Android中的MainActivity，界面的入口，严格来说不能算程序的入口，因为Android里面程序的入口是application。鸿蒙里面也有application的概念，但不对外开放，对应的有个AbilityStage，它是模块单例对象，在EntryAbility前初始化。EntryAbility主要作用是与系统交互，比如系统怎么管理window，window怎么加载布局。有个ability，开发时就不用关心这些细节了，这跟Android中的activity类似。EntryAbility会去加载带有@Entry标签的index.ets布局，这个@Entry的作用你可以理解为Android中的Fragrant，Ability必须加载带有@Entry标签的布局，相当于单activity加载多个Fragrant模式。所以你会看到@Entry标记的布局会提供一起生命周期回调。
至于你所说的界面和逻辑在一起，这是因为目前鸿蒙处于初期阶段，还没有探索出一个比较好的开发模式，跟Android早期所有代码都写在Activity中一样。不过鸿蒙也有自己的优势，一上来就使用声明式UI，界面写起来还算容易，所以你可以将布局无关的数据业务处理逻辑封装到一个单独的类中，这样界面和逻辑更清晰些。你后面说的所有界面都属于自定义，动态addView，这样的理解是对的。声明式UI提倡所见即所得，加上高效的预览器，无论是开发还是运行效率，都有很大的提升。
像Android里面将UI写在xml里面业务逻辑写在java或kotlin中，这是出于历史原因所决定的。Android早期流行xml写界面，java的跨平台写逻辑。这种模式也有它自己的弊端，涉及到跨语言在java中解析xml布局有性能损耗，所以官方提供了异步解析的方式，但是加载还是耗时，只是不占用主线程。所以Android现在也在推compose写布局，这种声明式写布局加上单语言处理，还是比较不错的处理方式。
更多关于HarmonyOS 鸿蒙Next中Ability到底是什么用途的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
大佬耐心回复，打了这么多字非常非常感谢。我认真看了一下，还有点疑问。按您说的，那是否一个鸿蒙应用只需要这一个ability，因为我看@Entry规定上是一个项目里面只能有一个，那就意味着ability去加载@Entry修饰的类也只有一个。虽然这块的代码我没找到。比如安卓那么多个activity是因为很多页面都是在这个里面创建的，然后又互相跳转有一些逻辑才创建那么多。再加上有些页面有自己的生命周期，都用fragment不好处理。那如果是这样的话正式的项目是不是ability里面也不需要做什么多余的操作呢。就自动创建了就不用管了，然后从入口的index开始写第一页面逻辑巴拉巴拉的往后写。然后布局文件这块我倒是完全没疑问，因为我写了一些程序发现因为这里面基本都是自定义view，那完全都可以拆出去是单独的类，所以倒也不是很臃肿，逻辑那个类只进行拼装调用，管理路由跳转。好像也不是很复杂，目前我是这样写的。
这里还有个比较好奇的事情。仓颉您肯定知道的。我看了一些语法规则，又看了一些别人的理解。加上我自己的思考，相当于是他才是能把鸿蒙系统发挥到最好性能的语言。那我就有点不理解了。比如java和kotlin。我都会，但他们也只是语法啊什么的有些不同，肯定后者更简洁，再加上lambda表达式，更简洁了。性能倒没什么。怎么到了arkts和仓颉。就涉及到性能更好了呢。明明都运行在一套系统中的呀。
找HarmonyOS工作还需要会Flutter的哦，有需要Flutter教程的可以学学大地老师的教程，很不错，B站免费学的哦：https://www.bilibili.com/video/BV1S4411E7LY/?p=17
一个ability中可以有多个@Entry标记的组件，当你使用navigation来做路由时，就不需要写多个@Entry组件了。一个应用也可以有多个ability，只有特定场景下才推荐使用多个ability，比如你做一个旅游应用，当显示景点时，需要做一个导航功能，而地图导航在应用中的使用场景不多，由其它团队来开发，此时这两个场景交互相对独立，此时可以用两个ability来实现。当使用多个ability时，不做额外处理的话，在最近任务中会出现两个ability，且在跳转时，感觉像是跳到另一个APP，从Android的使用习惯，用户会误认为2个应用，所以一般推荐使用单ability模式。在ability中也会处理少量的逻辑，比如设置应用是否全屏，设置状态栏颜色等等，这些是针对应用全局行为，一般会在ability中处理，其它跟页面相关的逻辑，页面自己处理。最后提到的仓颉，仓颉的目标是应用在全场景，开发鸿蒙只是其中一个场景。你提到的相比于ArkTS性能更好，个人理解，不一定对。仓颉是静态强类型语言，而且会将代码编译成机器码，性能比较好，而ArkTS是基于TS进行了扩展，官方说是静态语言，其实只是编译期间的静态，运行时还是动态的，而且ArkTS也可以引入TS，所以在运行期间还是会做很多额外的检验，尽管鸿蒙有方舟编译器，会将ArkTS编译成字节码，跟仓颉真正的静态语言编译成机器码，性能还是不一样的。
再次感谢大佬回复我。
我刚才试了一下，写多个@Entry确实也不报错，直接能运行起来，给我整懵了。那么多官方文档还有那个AI回复都是说一个应用只能用一个@Entry。我就当真了，一直没敢写第二个。。。一直以为是这个标记才让EntryAbility知道哪个是入口呢。
我刚才从项目里面找了一下，好像找到了到底怎么确定的入口的链路，跟您说一下，您看是不是这么个事。首先这个项目模块的module.json5配置文件里面有个"type": “entry”。这个东西来确定你这个模块是不是入口。然后下面又有"pages": “$profile:main_pages”,属性，直接进他的main_pages.json配置文件。这里面有
确定具体的页面入口，我试了下在同样目录下新建新的文件也不会被注册进来。那应该就是这套链路来确定应用真实入口就是这个Index。即使有多个@Entry也不会进错。不过这样@Entry的作用就又不那么精确了。
然后您说的那个多个ability，居然会在任务管理器里生成多个，有点像多个进程了似的。
最后那个仓颉，我也懂了。之前还在想要不要一开始就不学ArkTS，直接用这个仓颉呢。但是还是ArkTS更似曾相识一些其实。还是自然过渡吧。就像Java过度到Kotlin似的。经历的项目没有一个是纯种的。都是两掺的。
在HarmonyOS（鸿蒙）系统中，Ability是一个核心概念，它代表了应用程序中可执行的基本单元。与传统操作系统中的应用程序（App）或进程概念有所不同，Ability更加模块化和灵活。
HarmonyOS设计Ability的目的是为了实现应用的组件化和服务的原子化。这意味着一个应用可以由多个Ability组成，每个Ability承担不同的功能或服务。用户可以根据需要启动或访问特定的Ability，而无需启动整个应用，从而提高了系统的资源利用率和响应速度。
Ability主要分为两大类：Service Ability和Entry Ability。Service Ability主要用于在后台执行任务或提供服务，不直接与用户交互。而Entry Ability则是用户可以直接访问的入口点，如应用的启动界面或某个功能模块。
通过Ability的组件化设计，HarmonyOS实现了应用间的解耦和高效协作。开发者可以更加灵活地组合和重用代码，同时用户也能获得更加流畅和个性化的使用体验。
简而言之，Ability在HarmonyOS中扮演着应用基本构建块的角色，它使得应用开发更加模块化、服务化，并提升了系统的整体性能和用户体验。
如果问题依旧没法解决请联系官网客服,官网地址是：
