鸿蒙应用开发工作,鸿蒙 软件开发

华为鸿蒙手机应用开发上手体验

之前测试过使用华为DevEco开发智能电视应用。前几天华为发布了手机的测试版，不能免俗，抓紧尝试一下。

10年积累的成都网站设计、网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站策划后付款的网站建设流程，更有黄陵免费网站建设让你可以放心的选择与我们合作。

手头没有华为手机测试系统，现在试一下开发环境跑模拟器感受一下。

以前DevEco里是没有手机选项的，现在该选项可以看到了：

这里测试一下Business Card Ability(Java)开发。

DevEco和Android Studio一样基于开源的Idea版本开发的，其结构与安卓开发环境非常像，熟悉安卓的小伙伴应该能很快上手。

入口程序是一个MyApplication，从AbilityPackage继承。

它首先找到了连接的荣耀手机，但这个手机不是鸿蒙系统。

编译是成功了，但提示设备无法使用：

点击Tools - HVD Manager

首先提示登陆华为账号，登陆后，选择一个模拟器运行：

启动以后长这个样：

点击设置，先看看关于：

上面显示大大的HarmonyOS。但感觉画面很模糊，不知道模拟器到底是运行在本地的，还是云端的。但DevEco上显示是Remote Device字样。

鸿蒙OS版本号 2.0.0 Developer Beta1。

再点运行，在指定的模拟器上运行程序。

不过仍然运行失败：

鸿蒙OS版本与平板是一致的，

程序终于跑起来了：

看起来安卓程序好像真能在鸿蒙直接运行，安装一个快手试试：

还真能看：

我真分不清这是安卓还是鸿蒙了 。

鸿蒙应用开发之真机调试

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

华为将真机调试分成物理真机和远程真机。这里说的都是物理真机（手机、平板）。鸿蒙真机调试巨复杂，不像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等参数，运行鸿蒙应用到真机就行了

鸿蒙出世以后，Android开发工程师会失业吗？

一、在华为如日中天的时候，华为都没敢推鸿蒙系统，而是把鸿蒙系统当作“备胎”慢慢发展。现在，华为被制裁了，只能把鸿蒙系统紧急推出来了。至少，鸿蒙是仓促上马的系统，却要和一个已经发展许多年，非常成熟的安卓系统竞争，还能轻而易举地赢了！三星真要哭死在厕所里了。昔日三星联合了英特尔搞出来的Tizen系统，还是按部就班进行的研发，依旧是无法弄出自己的生态圈，最后只能沦落成家电的系统了。从这个角度来看，安卓工程师不用太担心安卓的生态系统被威胁，鸿蒙的生态圈很难发展到能够与安卓比较。

二、华为自己都说了，鸿蒙系统当初设计就是想做家电的系统，是与三星Tizen类似的东西，主要应用方向是家电和物联网。现在是因为制裁的原因，赶鸭子上架成为了手机系统。这种临时改变用途的系统需要大动干戈才能完善对手机的应用支持。可以想象，如果鸿蒙系统对手机的支持有缺陷的话，做手机应用就会非常困难。也因此有理由相信，现在鸿蒙手机如果对安卓应用的支持特别完美，就更说明鸿蒙的“拉皮”可能性了。如此一来，安卓工程师就安心开发安卓应用就好了，因为鸿蒙一定可以完美运行你的应用，这就没有放弃安卓开发的必要了嘛！

至此，我想现在考虑鸿蒙把安卓的阵地攻破了实在是太早了。所以，大概率，没有哪个安卓工程师会放弃安卓去弄鸿蒙，顶多是测试一下应用能不能在鸿蒙环境下运行罢了。还是把兼容性这件事儿交给鸿蒙去搞吧。

鸿蒙出来的话，安卓工程师并不会失业，取决于自己想不想在鸿蒙上开发软件。

鸿蒙的应用程序开发，主要是基于Java和NodeJS，基于Java的整体框架结构与安卓极其相似，加上其开发环境DevEco Studio与Android Studio同宗，安卓工程师可以极短的时间迅速上手鸿蒙应用程序的开发。当然，一些做前端开发的小伙伴也会进入鸿蒙平台进行开发，但这部分小伙伴往往是会用一套代码、同时适配多个应用平台（类似国产的uni-app），这些本身就在和安卓开发有一种竞争关系，并不会因为鸿蒙的生产而发生多大变化。

另外鸿蒙的开发平台，也可以很轻松在智能屏、智能手表、车载智能设备等设备上调试开发，总体来说，如果鸿蒙火起来，就会有更多的软件开发需求了，安卓开发工程师会更吃香。建议大家多多接触鸿蒙生态，多学一点知识对自己是一个积累储备，总不会是坏事。

错，是谷歌、微软和苹果要倒闭了！

鸿蒙系统配备方舟编译器，兼容安卓应用，但运行效率……（此处省略1000字，翻2019年文章）……鸿蒙系统能在所有设备运行，支持手机、电脑、平板、物联网……（此处省略1000字，翻2019年文章）……

我想说的是你们太不懂华为了，其实鸿蒙早已开发完成并且随时可用！他一直在忍，在等一个机会……

非常肯定的说不会失业。我们知道鸿蒙OS有很多地方借鉴了Android，甚至是说底层有很多Android的代码，开发思维很多都跟Android相似。比如写UI有Java方式和JS方式，而Java方式的UI和Android如出一辙，在Xml里面写界面，在Java里面获取控件设置数据，处理逻辑等等。鸿蒙里面也有Intent来处理跳转传数据，而鸿蒙的Ability更是和Android里面的Context，Activity这一套很相似，分前台界面显示，后台不可以的服务，以及用来传数据的Ability，就像Android里的Content Provider。当然它们之前也有不同，但你在方方面面都能看见Android的影子，所以Android开发者转鸿蒙平台开发，相比于其它平台的开发者，是天然有优势的，只要企业有需要，几乎所有Android开发在适应一段时间后都能上手做项目了。

相反的是鸿蒙生态能不能发展起来，能不能解决Android，iOS生态的一些痛点。能否吸引企业去开发鸿蒙应用，开发时，能否降低成本。当企业花大量的人力，物力开发出来的应用，没用户使用，或者收益甚微，企业是不愿意去尝试的。要想发展鸿蒙生态，这方面不仅华为自己要努力，一些国企，知名大企些带头作用，像央视影音，新华网，京东等等已经发布鸿蒙平台的APP了。

如果鸿蒙生态发展的很好，有大量的用户大量的应用，挤占了Android和iOS的市场占有量，Android开发者能迅速转到鸿蒙平台上，iOS的开发者要怎么办呢。也许你会说iOS根本不需要考虑，Android的市场占有率这么高iOS还不是活的好好的，当年诺基亚也没想到自己会倒的这么快。

作为一名android开发工程师，我想说，失业是不可能的，这辈子都不可能失业！

也许身为移动端开发人员的我们，正处于一段乱流之中！

首先，来谈谈android的碎片化问题。

仅仅2014年，全球支持Android的机型为18796种，再来看看国内，华为、小米、oppo、vivo...，android手机厂商也很多，每个品牌都是基于android开源系统改造，android开发人员要在完成软件功能的同时，对不同品牌的手机做功能适配，非常麻烦。

除了手机品牌数量多，手机屏幕的尺寸适配问题也很麻烦，往往一个软件的开发，有60%的时间在适配工作上。

是的，现在鸿蒙来了，意味着什么？意味着android开发人员有必要或者就必须去学习一门新语言、一个新系统的开发、适配，对于一个企业来说，要么就增加人工成本请一个鸿蒙系统开发人员，要么就强制在职android开发人员重新开发一遍软件适配鸿蒙系统。

基于此，不知道有多少android开发人员会买账，不知道多少企业会加个鸿蒙系统平台，不知道鸿蒙系统能不能站住脚推广开来。

虽然现在鸿蒙系统可以兼容android应用，但以后必然会两级分化。

如果鸿蒙系统没有革命性的突破，如果美国不再卡脖子，如果没有国家的干预措施，只靠平民大众自觉爱国的方式支持鸿蒙系统，我看很悬啊，毕竟，苹果手机在国内的销量一如既往！！！

再者，在手机行业，小米、oppo等手机厂商和华为本是竞争关系，会放弃自己的系统换成鸿蒙系统吗？这样的话，其他手机厂商的生存空间会一天不如一天，就算鸿蒙开源使用，也只不过走android碎片化的老路！

系统之争本就不是一朝一夕，不用担心会不会失业，路，还很长！

实际上安卓系统的成功起初很大得益于中国市场，可以说中国市场选择谁，成功的几率非常大， 鸿蒙系统出世以后，安卓开发工程师会失业吗？ 暂时不会的，毕竟有一个过程，也是一种博弈过程，实际上安卓系统与鸿蒙系统现在没必要刻意追求细小细节的优劣，前提是由于美国对中国的打压，谷歌断供服务华为，别看只是说切断了华为的服务，但是这种破坏性本身就是让各国包括中国对美国不可能再信任，今天是华为，明天有可能是另一家企业，无论美国怎么说，谷歌再会解释，实际上这种行为已经打破了行业规则，后期效应就是不可能再一味的依靠美国，各国发展自己的系统，中国也必须的推出自己的系统，大势所趋，安卓体系以后会慢慢萎缩，安卓开发工程师失业不失业就凭他们个人能力了，肯定减员，估计未来的鸿蒙系统会越来越强大，市场份额是固定的，就看谁的市场大了，也不排除安卓开发工程师跳槽来鸿蒙。

开发鸿蒙只能在华为支持的鸿蒙设备上运行，开发android，可以在所有安卓设备包括鸿蒙设备上也兼容运行，何来失业

做安卓的一天不用就能写鸿蒙。可以忽悠甲方加钱了[泪奔]

不会，确切的说鸿蒙的出世，给Android工程师提供了更多的机会。鸿蒙生态的建设，安卓工程师会贡献绝对的力量。

另外，从技术上讲，安卓开发的应用完全兼容鸿蒙，安卓工程师开发安卓应用的时候，可能会针对鸿蒙系统做适配工作，工作量的增加，工程师的价值也会增长。

是得我就是干这个 但是我都计划改行了

2021-01-25鸿蒙开发（五）

Ability

Ability是应用所具备能力的抽象

2.onActive()

Page会在进入INACTIVE状态后来到前台，然后系统调用此回调。Page在此之后进入ACTIVE状态，该状态是应用与用户交互的状态。Page将保持在此状态，除非某类事件发生导致Page失去焦点，比如用户点击返回键或导航到其他Page。当此类事件发生时，会触发Page回到INACTIVE状态，系统将调用onInactive()回调。此后，Page可能重新回到ACTIVE状态，系统将再次调用onActive()回调。因此，开发者通常需要成对实现onActive()和onInactive()，并在onActive()中获取在onInactive()中被释放的资源。

3.onInactive()

当Page失去焦点时，系统将调用此回调，此后Page进入INACTIVE状态。开发者可以在此回调中实现Page失去焦点时应表现的恰当行为。

4.onBackground()

如果Page不再对用户可见，系统将调用此回调通知开发者用户进行相应的资源释放，此后Page进入BACKGROUND状态。开发者应该在此回调中释放Page不可见时无用的资源，或在此回调中执行较为耗时的状态保存操作。

5.onForeground()

处于BACKGROUND状态的Page仍然驻留在内存中，当重新回到前台时（比如用户重新导航到此Page），系统将先调用onForeground()回调通知开发者，而后Page的生命周期状态回到INACTIVE状态。开发者应当在此回调中重新申请在onBackground()中释放的资源，最后Page的生命周期状态进一步回到ACTIVE状态，系统将通过onActive()回调通知开发者用户。

6.onStop()

系统将要销毁Page时，将会触发此回调函数，通知用户进行系统资源的释放。销毁Page的可能原因包括以下几个方面：

用户通过系统管理能力关闭指定Page，例如使用任务管理器关闭Page。

用户行为触发Page的terminateAbility()方法调用，例如使用应用的退出功能。

配置变更导致系统暂时销毁Page并重建。

系统出于资源管理目的，自动触发对处于BACKGROUND状态Page的销毁。

AbilitySlice生命周期

AbilitySlice生命周期回调与Page的相应回调类似，因此不再赘述。由于AbilitySlice承载具体的页面，开发者必须重写AbilitySlice的onStart()回调，并在此方法中通过setUIContent()方法设置页面。

Page与AbilitySlice生命周期关联

当AbilitySlice处于前台且具有焦点时，其生命周期状态随着所属Page的生命周期状态的变化而变化。当一个Page拥有多个AbilitySlice时，例如：MyAbility下有FooAbilitySlice和BarAbilitySlice，当前FooAbilitySlice处于前台并获得焦点，并即将导航到BarAbilitySlice，在此期间的生命周期状态变化顺序为：

对应两个slice的生命周期方法回调顺序为：

FooAbilitySlice.onInactive() -- BarAbilitySlice.onStart() -- BarAbilitySlice.onActive() -- FooAbilitySlice.onBackground()

在整个流程中，MyAbility始终处于ACTIVE状态。但是，当Page被系统销毁时，其所有已实例化的AbilitySlice将联动销毁，而不仅是处于前台的AbilitySlice。