鸿蒙app网络开发,鸿蒙手机应用开发

华为鸿蒙系统摆脱“APP薄弱”局面！国内开发者：力挺

自鸿蒙系统问世后就一直处于一种尴尬的局面，安卓、iOS系统已经完善得尽善尽美，多数APP也是以这两个系统为基地开发的，这就让鸿蒙系统的APP生态环境极其薄弱，甚至还有人担心，更新了鸿蒙系统后，会不会手机上就不能用APP了。

成都创新互联-专业网站定制、快速模板网站建设、高性价比西城网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式西城网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖西城地区。费用合理售后完善，十载实体公司更值得信赖。

这些担心自然是多余的，OPPO、vivo、魅族等厂商都已经陆续适配鸿蒙OS系统，可见华为鸿蒙OS系统还是有着一定的优势，并且国内3100多支开发团队都报名参加了华为鸿蒙系统开发者创新大赛，并且有23支团队脱颖而出，已经进入了鸿蒙系统专属APP开发过程。

华为鸿蒙120万开发者做300多个APP 在玩文字游戏还是不怀好意捧杀

最近看到很多自媒体都在说：华为鸿蒙系统虽然号称有120万开发者，但鸿蒙原生APP到现在却只有300多个。所以华为自提供系统，至于软件，能用安卓的就用。

咋一看，这种说法好像也没有问题，因为系统最重要的就是生态，如果周边生态跟不上，哪怕是强如当年微软搞得WP也皎然于民。

所以当鸿蒙一发的时候，我们都期望它能够迅速占领市场，完善自己的生态圈，当我们看看有120万的开发者，只开发出320APP的时候，这个数字的背后确实让人困惑不已，也对鸿蒙的前景表示担忧也很正常。毕竟这个数量太少了，难道鸿蒙以后就靠安卓软件活下去吗。

关于鸿蒙的面世，这里不做更多详细探讨，总结起来就是一句，备胎的产物。如果漂亮国没有封禁华为的话，鸿蒙也许只会出现在物联网上应用，手机系统？也许后期会有，但至少不是现在这种情况面世。

但计划赶不上变化这句话很好描述了华为这几年的情况，鸿蒙的出现也许不是最正确合适的时候，但它也足够优异，因为它的发展确实比预料要快一些。根据华为官方说法，有300多家企业加入鸿蒙生态，已经有65款硬件设备可以升级到鸿蒙2.0版本，同时搭载鸿蒙系统的终端设备已经接近一个亿，对于一个新生的系统来说，这确实是个不小的成就。

但看似美丽数据背后却带着未知的危机，虽然数据来看，鸿蒙系统确实已经很好，看上去也不会担心它以后的发展之路。

但实际上鸿蒙现在面对最大的难题就是生态，这就是前面提到120万开发者只开发出300多个原生鸿蒙APP的说法。

鸿蒙系统现在最大的问题还是在生态不够健全，借鸡生蛋终究还是临时办法，加上谷歌现在把鸡也杀了，那么只会自己养鸡生蛋了。所以鸿蒙想要独立成第三大操作系统，不走微软和三星的老路，那么鸿蒙就是首先学会养鸡。

当华为称鸿蒙的生态的开发者有120万的时候，人们觉得华为的鸡已经养起来，但当宣称只开发了320个APP的时候，人们就怀疑华为养的是公鸡吗。因为按照这个算法，几千人才才开发一个APP 这显然不正常。

百万人开发几百个APP显然是不正常的，但在这百万人当中，首先我们要搞清楚有多少是鸿蒙系统的开发者，因为按照华为官方的说法，这120万的开发者是HMS的开发者，因为华为在被漂亮国禁用GSM以后，华为就自行建立了HMS服务。原则上来说，这些开发者都算是鸿蒙生态的开发者，根据华为官方的appgallery统计，支持HMS服务的软件有上百万个，所以如果按照这个算法，这些开发者开发的APP也不算少了。但如果是按照鸿蒙原生的APP计算，那么情况就是另外一种说法，这是计算和统计不一样引起的结果。

如果非要给出一个定义，那么只能说这120万是华为HMS生态的开发者，它还不完全算是鸿蒙系统的开发者，毕竟HMS发布要比鸿蒙早很多。因为这部分人大多是开发软件服务，而不是原生软件，所以120万对鸿蒙来说多少有点文字 游戏 数字。

每一个系统生态的建立都需要时间的沉淀，作为一个只发了几个月的系统，它原生APP少主要可能是两个方面原因造成一是它兼容谷歌安卓的应用，一般性的企业不会再独立开发鸿蒙APP。所以也许这120万里有鸿蒙系统的开发者，但他们还在观望当中，毕竟再搞一套，技术、时间、成本都是一个不可能不考虑的问题。

二就是鸿蒙系统硬件支持还不够，虽然前面说到有接近一亿用户，但在手机领域有多少我们没有准确数据。加上华为手机前景的未知性，这会让这120万当中的观望着更有耐心。毕竟做出来的软件它不是说说就可以，要人力时间精力还是后期维护等等，在鸿蒙现在的情况下，有着更多的观望者其实并不奇怪，因为不管从那个角度来说了，只要开发出安卓应用，同时兼容鸿蒙它已经足够应对目前的情况。

客观来说，目前鸿蒙距离安卓和IOS还有很大差距，也许它比当年的WP用户数量还要少。但鸿蒙作为一个挑战者，一个从零开始的挑战者，它开局的艰难是有预估的，存在的劣势也是必然的。要知道安卓和苹果有今天相当成熟的生态优势，他们是经过时间的沉淀才有这样的结果。当相对于安卓在中国就有500万开发者，苹果的440万开发者，鸿蒙全球才120万开发者，而且还是带着不少水货的情况，这显然还是不够的，想要做第三的市场份额，鸿蒙还是很长的时间和努力才会有机会实现。

目前我们对鸿蒙前景也不要太悲观，毕竟它才几个月大，它的潜力还在，而且目前看它还有它自身的优势。按照目前势头发展下去，当有足够的硬件支撑它的时候，相信很多的观望着会纷纷入局，到了那个时候，鸿蒙原生的APP自然就会丰富起来。

对此你有什么不同的看法，欢迎评论讨论！

鸿蒙应用开发之真机调试

参考 鸿蒙官方文档（点击传送门） ，做一下流程梳理简化，及踩坑记录

华为将真机调试分成物理真机和远程真机。这里说的都是物理真机（手机、平板）。鸿蒙真机调试巨复杂，不像Android那么容易方便。

贴一下官方的调试流程图：

总结一下：

上面这个流程可以忽略，没讲到重点。真机调试是需要在   AppGallery Connect 中创建应用的，调试应用需要的cer和p7b文件是从这里生成的。

先决条件：

1. 鸿蒙手机通过USB连接电脑，并开启USB调试。

2. 一个华为开发者账号，实名认证

3. APP开发工具DevEco-Studio

关键流程：

1. Studio创建应用

2. 如果未登录过，File Project Structure Project Signing Configs签名配置页，点击“Sign In”

3. AppGallery创建应用（包名和Studio创建的一样）

4. 官方文档到这在签名配置页就点Try Again可以自动签名，我试了不行，以下全是手动

5. Studio中Build Generate key and CSR   生成p12和csr文件

6. 获取手机udid，命令行hdc shell bm get -udid（下一步设备管理要用）

7. AppGallery主页 用户与访问 左侧设备管理添加udid的设备（生成p7b时要用）

8. AppGallery主页 用户与访问 左侧证书管理生成cer文件（生成p7b和签名配置要用）

9. AppGallery主页 我的项目 左侧HarmonyOS应用 HAP provision profile，生成p7b文件

10. 最后在签名配置页配好 p12、p7b、cer等参数，运行鸿蒙应用到真机就行了

AIDA64 官宣正在开发鸿蒙版本 App

IT之家 5 月 30 日消息 根据IT之家网友投稿，知名系统软硬件监测软件 AIDA64 于近日在推特中回复提问。表示正在研发华为鸿蒙 Harmony OS 版本的 App。这款软件除了提供电脑版本，还推出了 iOS、安卓、Linux 等平台的版本，用于详细显示硬件信息。

IT之家了解到，华为鸿蒙 OS 目前推出了 2.0 开发版，这一系统的安装包后缀名为 *.hap，目前配套的开发工具、方舟编译器已经就绪。

AIDA64 Extreme 桌面版于 5 月 21 日更新了最新测试版，新增了对于英伟达 CMP 50HX（TU102-100）、RTX 3060 Ti LHR 等显卡的支持，同时添加了英特尔 11 代移动处理器的相关信息。这一版本修复了对于 AMD Navi 22、Navi 23 核心显卡的检测。

IT之家此前报道，华为将于 6 月 2 日正式发布鸿蒙 HarmonyOS 手机操作系统，首批机型将有 Mate40 系列、Mate30 系列、P40 系列、MateX2 系列。

华为鸿蒙120万开发者只做出320APP？有人在玩文字游戏

搭载鸿蒙系统的终端设备已经达到了9000万 ，此前鸿蒙系统表现优异，很快地占领着市场。也因为鸿蒙系统的发展比预料中要快一些，华为也是将原本的目标往上提了一提。

看上去华为似乎已经不用担心鸿蒙会无法崛起了，毕竟在手机业务腰斩的背景之下，鸿蒙可以说是华为压箱底的救命之招了。但是呢，虽然从数据来看，鸿蒙系统好像确实发展得挺不错， 但是实际上鸿蒙系统正面临着其最大的问题，生态建立不起来！ 拿软件开发来说，近日有人表示：现在 鸿蒙系统虽然号称有120万开发者，但是鸿蒙原生APP到现在却只有320 。这个数量未免有点少的过头了！难道华为鸿蒙就只能提供一个操作系统，然后使用的全是安卓的APP吗？

120万相较于320 ，对比之下的数字差距能够让很多人困惑不已，同时也让我们对鸿蒙的处境表示担忧。对于一个操作系统来说，大量App开发可以说是其最关键的部分之一了，没有足够多的APP，鸿蒙系统等于是一个空屋，里面没有足够多的家具和日用品。而现在鸿蒙系统从严格意义上来说，也算不上是空屋，只是其还和安卓兼容，可以使用安卓的APP 。但这样一来，鸿蒙想要独立，变成第三大操作系统，就变得难上加难了。

为何会出现这么大的落差，平均换算下来，几千个开发者才能开发出一个APP？这当然是不可能的。关键的地方在于鸿蒙虽然有着大量的开发者， 但是这其中很多开发者都算不得上鸿蒙的“新加入者”，而是华为HMS的开发者。

还记得一开始针对华为的时候，是从移动服务系统开始的。手机的移动服务系统，主要提供一些基础的服务。比如说GPS、应用商场、支付等。现在使用最多的移动服务系统是谷歌的GMS。华为若是在国内发展，根本没必要担心移动服务的事情，因为在国内是不需要GMS的。但是华为做的高端品牌，市场目标放在了全球，肯定是要在国外销售的，这时候就不免受到老美的制裁。因为在国外，智能手机没有GMS就很难受用，最基础的功能都要受到限制。 所以华为也是因为被禁用GMS导致国外市场下滑严重，直到华为出了自己的HMS，这种问题才得以解决。

HMS比鸿蒙出来要早不少时间，所以其生态已经建立了很多，与HMS合作的开发者也不在少数。在计算鸿蒙系统的开发者数量的时候，将很多这部分的人算到了里面。 这多少有文字 游戏 的意思，因为这些人很多是不为鸿蒙开发APP的。

另一方面，就算这些人也有为鸿蒙生态出力的计划，但这不代表着这些开发者就会立马为鸿蒙开发APP。 要知道开发者们并不是免费开发的，大多数开发者至少要通过开发获得足够的回报才愿意去做这个事。 而现在鸿蒙虽然在快速发展之中，但是距离安卓和苹果那样的系统有很大的差距，开发者们从性价比的角度来考虑，多半还是会选择开发安卓和苹果的软件。至少风险不高，回报也客观。

更重要的是，鸿蒙是兼容安卓的，这就意味着开发安卓的APP，就有部分是相当在开发鸿蒙的APP， 有的时候，一份力打了两份工，何乐而不为呢？

客观来说，我们必须要认清现实， 因为现在的鸿蒙和安卓，IOS的差距还很大！ 想要追赶需要很长的时间和努力！我们说120万看起来已经很多了，但是以苹果为例就知道差距了。苹果的开发者数量在2300万左右，是鸿蒙的20倍，而且苹果的开发者又不像鸿蒙的开发者有不少的“水货”，还有不少在观望。 再者，另外两大操作系统都经过很长时间的积累，生态已经相当成熟，鸿蒙现在不仅是从零开始，还是从零开始挑战，劣势是必然的！

但是也不必太灰心，鸿蒙的潜力很好，毕竟其实力不亚于其他两大操作系统的，甚至还要优秀很多。现在这个发展劲头也很强劲。如果保持现在这个趋势发展下去，相信会有越来越多的开发者能够看到足够的回报在向他们招手，到时候，鸿蒙的开发者自然就多了，鸿蒙的原生APP自然也会慢慢变多了。

从客观角度来说，我们要理性看待鸿蒙现在的发展现状，不要动不动就把它吹上天。同样的，我们也不要太悲观，鸿蒙有实力，是金子在哪都发光。相信鸿蒙系统会慢慢变好，最终成为茁壮的大树。我们只需要慢慢等待时间就好了。

2021-02-05鸿蒙开发（二.五）

Intent

Intent是对象之间传递信息的载体。当一个Ability需要启动另一个Ability时，或者一个AbilitySlice需要导航到另一个AbilitySlice时，可以通过Intent指定启动的目标同时携带相关数据。Intent的构成元素包括Operation与Parameters。

Intent的构成元素

Operation

Action： 表示动作，通常使用系统预置Action，应用也可以自定义Action。例如IntentConstants.ACTION_HOME表示返回桌面动作。

Entity：表示类别，通常使用系统预置Entity，应用也可以自定义Entity。例如Intent.ENTITY_HOME表示在桌面显示图标。

Uri：表示Uri描述。如果在Intent中指定了Uri，则Intent将匹配指定的Uri信息，包括scheme, schemeSpecificPart, authority和path信息。

Flags：表示处理Intent的方式。例如Intent.FLAG_ABILITY_CONTINUATION标记在本地的一个Ability是否可以迁移到远端设备继续运行。

BundleName：表示包描述。如果在Intent中同时指定了BundleName和AbilityName，则Intent可以直接匹配到指定的Ability。

AbilityName： 表示待启动的Ability名称。如果在Intent中同时指定了BundleName和AbilityName，则Intent可以直接匹配到指定的Ability。

DeviceId： 表示运行指定Ability的设备ID。

当Intent用于发起请求时，根据指定元素的不同，分为两种类型：

如果同时指定了BundleName与AbilityName，则根据Ability的全称（例如，“com.demoapp.FooAbility”）来直接启动应用。

如果未同时指定BundleName和AbilityName，则根据Operation中的其他属性来启动应用。