十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
之前测试过使用华为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等参数,运行鸿蒙应用到真机就行了
一、在华为如日中天的时候,华为都没敢推鸿蒙系统,而是把鸿蒙系统当作“备胎”慢慢发展。现在,华为被制裁了,只能把鸿蒙系统紧急推出来了。至少,鸿蒙是仓促上马的系统,却要和一个已经发展许多年,非常成熟的安卓系统竞争,还能轻而易举地赢了!三星真要哭死在厕所里了。昔日三星联合了英特尔搞出来的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工程师提供了更多的机会。鸿蒙生态的建设,安卓工程师会贡献绝对的力量。
另外,从技术上讲,安卓开发的应用完全兼容鸿蒙,安卓工程师开发安卓应用的时候,可能会针对鸿蒙系统做适配工作,工作量的增加,工程师的价值也会增长。
是得我就是干这个 但是我都计划改行了
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。