uniapp鸿蒙开发,鸿蒙应用开发ide

鸿蒙要出来了，Android开发工程师是不是要失业啦？

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

你所需要的网站建设服务，我们均能行业靠前的水平为你提供.标准是产品质量的保证，主要从事做网站、网站设计、企业网站建设、手机网站制作设计、网页设计、成都品牌网站建设、网页制作、做网站、建网站。创新互联公司拥有实力坚强的技术研发团队及素养的视觉设计专才。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

中国北斗早就出来了，GPS的工程师没失业吧！

不会，可以学习一下华为鸿蒙开发教程。

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

不会失业的，他们可以转鸿蒙开发，非常简单

uni-app 入门到精通 （二）

18 年时候有幸接触到 uniapp , 写了一篇 《uni-app 入门到精通》 ，由于一些原因，该方案并没有执行，该项目一系列文章也就没有再写下去，所以遭受到了许多人评论的吐槽，到如今公司项目的需求又要根据 uniapp 写 H5 嵌入到 app 中，所以想根据项目实际开发分享一下，有兴趣的伙伴可以参考和吐槽。

这一篇文章主要分享一下内容

uniapp 模板项目有两种初始化方式

由于无法舍弃 VSCode ，我们采用 vue-cli 来初始化项目， HBuilderX 大家可以参照官方文档

这种方式是可以通过 vue 脚手架命令指定模板，这个是 dcloudio 的官方提供模板

我们选择默认模板即可，

成功后我们执行

打开浏览器地址，直接运行即可。

一般刚接触前端的小伙伴可能会对 postcss 不太了解，这里简单介绍一下，

当然 PostCSS 具体使用是需要引入一些插件的，例如常用的是 autoprefixer postcss-preset-env 等, 具体如何使用大家可以自行参考资料，毕竟这块知识还是挺多的就不具体展开解释了。

通常我们在写移动端时候需要做的是页面适配方案的确定， uni-app 支持的通用 css 单位包括 px、rpx ， 之前的 upx 方案已经被废弃掉，官方解释是目前市面上已经基本上支持了微信的 rpx 方案，所以 upx 中转方案已经意义不大了，不过还可以继续使用，不过已经不再推荐。

rpx 之初是由微信小程序提出一种方案，即根据宽度来进行适配以 750 宽屏幕为基准， 750rpx 恰好为屏幕宽度, uni-app 规定屏幕基准宽度 750rpx 。所以说如果你们的UI 设计以 750*1334 iphone 6/6s 为基准设计的话，你只需要将屏幕上 px 写为 rpx 即可，不用做任何换算，如果不是的话，你就需要做如下换算：

uniapp 有自己一套路由管理机制，而未采用 vue-route 方案，个人认为这套方案还是比较成熟和好用的，以及可以满足我们日常的需求:

保留当前页面，跳转到应用内的某个页面，使用uni.navigateBack可以返回到原页面。

2.uni.redirectTo(OBJECT)

关闭当前页面，跳转到应用内的某个页面。

3.uni.reLaunch(OBJECT)

关闭所有页面，打开到应用内的某个页面。

注意： 如果调用了 uni.preloadPage(OBJECT)) 不会关闭，仅触发生命周期 onHide

4.uni.switchTab(OBJECT)

跳转到 tabBar 页面，并关闭其他所有非 tabBar 页面。

注意： 如果调用了 uni.preloadPage(OBJECT)不会关闭，仅触发生命周期 onHide

5.uni.navigateBack(OBJECT)

关闭当前页面，返回上一页面或多级页面。可通过 getCurrentPages() 获取当前的页面栈，决定需要返回几层。

5.uni.preloadPage(OBJECT)

预加载页面，是一种性能优化技术。被预载的页面，在打开时速度更快。

以上路由API 已经满足我们的需求，当然进行路由跳转的前提是我们需要在 pages.json 进行路由配置, 包括路由和具体的样式配置

而进行具体路由跳转我们需要如下，需要多加一个 /

需要特别注意的一点是, 利用浏览器 在 进行 移动H5页面调试时候，会出现页面刷新之后页面栈会消失，此时navigateBack不能返回，如果一定要返回可以使用history.back()导航到浏览器的其他历史记录。

uniapp 提供网络请求的 api 是 uni.request ，具体支持的请求方法可以参考官网 method 有效值

不过我们通常不会直接使用，而是进过一系列的封装以方便我们的使用，具体封装接口使用会在随根据页面数据请求一并展示。

怎样评价uni-app？

前端最火热的话题无法就是flutter,不管是刷哪个论坛，必定有探讨flutter的文章。没用过flutter，但是对于跨平台的技术，我一直都在研究。

为什么是uni-app

之前一直在找解决跨平台的方案，尝试了很多方案，比如滴滴的变色龙，但是最终还是选择了uni-app，这里附上uni-app的官网。为什么会选择它呢，第一，vue语法，学习成本低，上手速度快，只要之前你做过vue的项目，那么就能很快上手，其实是vue和微信小程序的结合体，一半vue，一半微信小程序。第二，长期维护，之前做微信小程序的时候，选择了美团的mpvue，但是后面发现长期不维护了，提了Issues也没人理，随之就放弃了，而uni-app长期在维护，这样看出了开发团队的用心。第三，跨平台的能力，uni-app能够跨多个终端，H5，安卓，Ios，微信小程序，百度小程序，头条小程序，支付宝小程序，真正实现了一套代码，多端运行，而且很好适应了我国的市场。第四，日益丰富的插件市场，uni的插件市场也在日益强大，能够基本上满足我们平时的开发需求。

uni-app的组件有原生调用能力，第三方的vue库在调原生接口时跟 5+runtime 不兼容。就像nativescript 有vue版和angular版，类似于react native , 都是起源于phonegap/cordova

实际开发效果遵义小红椒 做了一款app，打包了安卓，Ios,微信小程序3个平台，产出的效果都还是不错，总体还是比较满意。而且打包过程也很方便简单，配套的HBuilderX自动内置了打包功能，所以也省去了打包的烦恼。

遵义小红椒 建议

如果你现在想做一款跨平台的产品，而且有vue和微信小程序的经验，最重要的，你不想学习一门新语言，那么uni-app也许是你的一个选择。

uni-app小程序开发踩坑记录

最近要从零开发一个跟后台管理系统对接的小程序，因为功能比较复杂，时间短，选择了比较火的uni-app，因为小程序出现的时间较短，各方面并不完善，开发过程中就是不断踩坑的过程，特此记录一小下。

uni-app虽然功能还不完善，但是插件市场里东西还是不少的，在搭建框架中因为需求要求借鉴了之前开发的PC端，所以有一些跟之前开发VUE相关的插件 ，可以提高开发效率，

插件：

坑：

1.覆盖原生组件，需要用cover-view容器，但是cover-view里可包含的标签有限，类似view等在真机调试时不显示，需全部替换成cover-view，且icon无法显示，可以用cover-imaga代替。

2.小程序和小程序之间的跳转（如腾讯云的人机滑动验证），跳转回来时需要进行操作，此时可以判断app.vue中的options，如果按小程序文档中来说当options.scene === 1038时是小程序跳回来的场景，但是部分手机跳回来是options.scene为1001，只能将这2种都作为跳转判断的条件。

3.小程序跳转回来app中的onshow有时不执行，这个原因暂未找到

4.在uniapp的H5版本 ，接入 腾讯云滑动验证 ，示例的点击滑动验证元素是通过dom操作的，但是无效，可能跟uniAPP不支持dom操作有关系，采用定制接入方法一，手动调用。

uniapp会取代原生开发吗

取代说不上，但是相对来说uniapp开发比原生开发好很多。

作为前端工程师，除了微信小程序，还要开发web、其他小程序甚至App，人们不喜欢来回切换开发工具和变更语法思考方式。

uni-app自然可以解决这些问题，但开发者又经常有些顾虑：

怕使用uni-app后，微信小程序里有的功能无法实现，受制于uni-app的更新。怕性能不如原生WXML。怕框架不成熟，跳到坑里。担心社区生态不完善。

uin-app 和原生开发是有很大差别的，至少在性能和需求覆盖度上会差很多。uin-app 框架使用的其实是 cordova 的进阶版，也就是把 web 代码打包到本地，本地实质上还是通过 WebView 运行，那性能的瓶颈不言而喻。

另外 uni-app 支持使用 Weex 框架拓展性能，本质上是通过桥的功能把 Vue 控件映射为原生控件进行渲染，效果和 react-native 差不多，虽然性能有所提升，但是和原生相比差距还是有的。

另外 uni-app 在设计到手机的硬件调用，通信和多线程问题上还是得回归到原生平台，一般 200 多个页面业务的 App 不大可能都只是纯 UI 展示。

具体数据对比我这里没有，不过可以总结下就是：uni-app 特别实用 vue 的开发人员，并且在业务逻辑并不复杂的场景是很实用的跨平台开发工具，但是面对 100-200 个页面的需求肯定是不行的。