
使用ShopXO开源商城uniapp主题版打包教程
源代码地址
uniapp插件:https://ext.dcloud.net.cn/plugin?id=6380
1. 下载 HBuilderX 工具
> HBuilderX支持插件拓展功能。App开发版已集成相关插件、开箱即用
根据自身电脑系统选择对应软件下载,建议选择APP开发版
下载地址:https://www.dcloud.io/hbuilderx.html

2. 下载好软件安装后打开
> 建议直接在uniapp插件页面一键导入,正常情况下uniapp插件都是最新的,大家可以看git平台正式版本提交的记录日期在uniapp插件页面更新日期之前、就表示uniapp插件也是最新版本。如果不是最新的可自行到以上git地址平台下载包,解压后直接将源码目录拖入 HBuilderX 工具即可
一键导入方式、uniapp插件地址:https://ext.dcloud.net.cn/plugin?id=6380
3. 左侧选中 App.vue 文件
> 将该源码导入HBuilderX开发工具、顶部工具栏 运行->运行到小程序模拟器->(根据支持平台自行选择、如 微信开发者工具)
App.vue中修改 request_url 和 static_url 地址为自己的商城地址即可使用
主题默认为黄色(yellow),如更改主题 App.vue文件中 default_theme + 底部css引入,pages.json文件中 tabBar选中图标+selectedColor选中颜色
manifest.json 文件中修改对应终端配置,比如小程序appid(微信小程序直播、好物推荐配置都在这里面自行去掉注释、一定要先申请权限、不然小程序空白)
发布、HBuilderX开发工具、顶部工具栏 发行->(根据支持平台自行选择、如 微信开发者工具)
微信小程序:需要再下载微信小程序开发者工具,打开,在顶部设置-安全设置(打开安全)
源代码地址
uniapp插件:https://ext.dcloud.net.cn/plugin?id=6380
1. 下载 HBuilderX 工具
> HBuilderX支持插件拓展功能。App开发版已集成相关插件、开箱即用
根据自身电脑系统选择对应软件下载,建议选择APP开发版
下载地址:https://www.dcloud.io/hbuilderx.html
2. 下载好软件安装后打开
> 建议直接在uniapp插件页面一键导入,正常情况下uniapp插件都是最新的,大家可以看git平台正式版本提交的记录日期在uniapp插件页面更新日期之前、就表示uniapp插件也是最新版本。如果不是最新的可自行到以上git地址平台下载包,解压后直接将源码目录拖入 HBuilderX 工具即可
一键导入方式、uniapp插件地址:https://ext.dcloud.net.cn/plugin?id=6380
3. 左侧选中 App.vue 文件
> 将该源码导入HBuilderX开发工具、顶部工具栏 运行->运行到小程序模拟器->(根据支持平台自行选择、如 微信开发者工具)
App.vue中修改 request_url 和 static_url 地址为自己的商城地址即可使用
主题默认为黄色(yellow),如更改主题 App.vue文件中 default_theme + 底部css引入,pages.json文件中 tabBar选中图标+selectedColor选中颜色
manifest.json 文件中修改对应终端配置,比如小程序appid(微信小程序直播、好物推荐配置都在这里面自行去掉注释、一定要先申请权限、不然小程序空白)
发布、HBuilderX开发工具、顶部工具栏 发行->(根据支持平台自行选择、如 微信开发者工具)
微信小程序:需要再下载微信小程序开发者工具,打开,在顶部设置-安全设置(打开安全)
收起阅读 »
修改任何东西都会弹出控制台
现在是修改任何东西都会主动弹出控制台,能不能修改东西之后,只要用户不主动打开,就不要弹出控制台,或者有报错再主动弹出来
现在是修改任何东西都会主动弹出控制台,能不能修改东西之后,只要用户不主动打开,就不要弹出控制台,或者有报错再主动弹出来

纯nvue开发安卓端APP演示项目
nvue开发APP具有性能好的优势,空闲之余,遂采用nvue开发前端,uniCloud开发后端的方式,开发了一款功能较为简单的社交类安卓端APP演示应用,功能较为简单,但开发过程中涉及到的技术点较为全面,相信大部分开发同行都会遇到,开发过程中也踩过不少坑,在此发帖,以期和有兴趣的朋友交流学习,也可以代为开发APP项目。尽管这是非商业项目,目的用于交流学习,该演示项目也已取得软件著作权证书,还希望各位朋友尊重劳动成果,不要反编译和破解,有想技术和知识交流的尽管提问,一定知无不言。
前端部分:
页面全部是采用nvue,布局推荐使用flex布局,css写法较为受限,但uniapp对nvue样式的支持是绝对能满足开发所需的,要比weex的支持更加友好。组件推荐使用uni-ui,实在没有合适的自己也可以写组件
后端部分:
采用的是uniCloud,主要是对数据的增删改查,事务的运用,用户的注册登陆和token的维护等等。存储使用云存储即可。
涉及到的知识点如下:
1、flex布局,自定义顶部导航,nvue简单过渡动画、swiper加list、cell、refresh等组件的配合使用;长列表数据推荐使用list组件,实机体验起来还是不错的;
2、返回顶部操作,nvue返回页面顶部需要用到uni.requireNativePlugin(),且在list组件内第一个子组件要设置ref,类似于锚点的位置;
3、层级的实现,nvue的层级不是靠z-index来实现的,是写在容器越里面,则显示在最上面来实现的;
4、背景图的实现;
5、app启动隐私政策和用户协议的配置;
6、第三方登陆的配置,此演示项目使用了QQ登陆;
7、分享功能的实现,自己有注册第三方分享的话用自定义分享,若没有,可以使用系统级分享;
8、开屏广告的配置和内容联盟的配置;
9、实现随机获取不重复的后端数据;
10、事务在uniCloud中的运用,例如点赞操作,必须是点赞成功、点赞量加1、给对应用户发送消息等等一些列操作全部成功,方能提交对数据库数据的更改,否则事务需要回滚,保证操作的合理。在电商项目里经常会用到事务;
11、邮件的发送;
12、用户信息的维护使用uni-id即可,注册、登陆、token的维护官方都已经封装好了;
13、版本更新的实现;
14、项目配置文件的管理;
15、云函数中开发过程中错误信息的调试;
16、数据库的建表、增删改查的实现、联表查询等;
.............................................................................
细节上的知识点待后面陆续更新
效果图如下:
nvue开发APP具有性能好的优势,空闲之余,遂采用nvue开发前端,uniCloud开发后端的方式,开发了一款功能较为简单的社交类安卓端APP演示应用,功能较为简单,但开发过程中涉及到的技术点较为全面,相信大部分开发同行都会遇到,开发过程中也踩过不少坑,在此发帖,以期和有兴趣的朋友交流学习,也可以代为开发APP项目。尽管这是非商业项目,目的用于交流学习,该演示项目也已取得软件著作权证书,还希望各位朋友尊重劳动成果,不要反编译和破解,有想技术和知识交流的尽管提问,一定知无不言。
前端部分:
页面全部是采用nvue,布局推荐使用flex布局,css写法较为受限,但uniapp对nvue样式的支持是绝对能满足开发所需的,要比weex的支持更加友好。组件推荐使用uni-ui,实在没有合适的自己也可以写组件
后端部分:
采用的是uniCloud,主要是对数据的增删改查,事务的运用,用户的注册登陆和token的维护等等。存储使用云存储即可。
涉及到的知识点如下:
1、flex布局,自定义顶部导航,nvue简单过渡动画、swiper加list、cell、refresh等组件的配合使用;长列表数据推荐使用list组件,实机体验起来还是不错的;
2、返回顶部操作,nvue返回页面顶部需要用到uni.requireNativePlugin(),且在list组件内第一个子组件要设置ref,类似于锚点的位置;
3、层级的实现,nvue的层级不是靠z-index来实现的,是写在容器越里面,则显示在最上面来实现的;
4、背景图的实现;
5、app启动隐私政策和用户协议的配置;
6、第三方登陆的配置,此演示项目使用了QQ登陆;
7、分享功能的实现,自己有注册第三方分享的话用自定义分享,若没有,可以使用系统级分享;
8、开屏广告的配置和内容联盟的配置;
9、实现随机获取不重复的后端数据;
10、事务在uniCloud中的运用,例如点赞操作,必须是点赞成功、点赞量加1、给对应用户发送消息等等一些列操作全部成功,方能提交对数据库数据的更改,否则事务需要回滚,保证操作的合理。在电商项目里经常会用到事务;
11、邮件的发送;
12、用户信息的维护使用uni-id即可,注册、登陆、token的维护官方都已经封装好了;
13、版本更新的实现;
14、项目配置文件的管理;
15、云函数中开发过程中错误信息的调试;
16、数据库的建表、增删改查的实现、联表查询等;
.............................................................................
细节上的知识点待后面陆续更新
效果图如下:
收起阅读 »
济南专业竞拍商城APP小程序定制开发公司
济南专业竞拍商城APP小程序定制开发公司,咨询(张13O微66O电29294)
一、竞拍商城逻辑:
城市,只需开通了拍卖的城市,订单才有可能转变成拍卖订单;
用户在请求借款时的请求金额,必须要大于必定的金额;
订单评分,这是咱们自己的评分体系,也是要求某个订单大于某个评分,才干转变成拍卖订单。
二、操控拍卖订单的参数
拍卖体系开发,开发拍卖体系,广州拍卖体系开发,专ye拍卖体系开发
生成了拍卖订单,还得对拍卖订单进行有用的操控,因而需要对以下参数进行操控:
拍卖时长,这是一个具有争议的参数,有人觉得15分钟都太长,有人觉得30分钟都不算短,并且其时没有数据表明到底多长时间比较合适,由于也得做成操控项;
拍卖延倒ji时,即在延倒ji时内假如还有人出价,拍卖主动延,延伸=延周期+拍卖剩下时长;
拍卖延周期,即假如在延倒ji时内有人出价,应该再添加的拍卖时长;
拍卖一口价系数,这个系数决定了拍卖的高价,对,你没有看错,咱们为了避免某些订单价格被拉得太高,对高价也进行了必定程度的操控;
加价起伏,即每一次点击可以在当前价格的基础上的加价金额;
体系定价(+起拍加价),即咱们对订单有个体系定价,次出价不是体系定价,而是体系定价+起拍加价,即起拍价=体系定价+起拍加价。
济南专业竞拍商城APP小程序定制开发公司,咨询(张13O微66O电29294)
一、竞拍商城逻辑:
城市,只需开通了拍卖的城市,订单才有可能转变成拍卖订单;
用户在请求借款时的请求金额,必须要大于必定的金额;
订单评分,这是咱们自己的评分体系,也是要求某个订单大于某个评分,才干转变成拍卖订单。
二、操控拍卖订单的参数
拍卖体系开发,开发拍卖体系,广州拍卖体系开发,专ye拍卖体系开发
生成了拍卖订单,还得对拍卖订单进行有用的操控,因而需要对以下参数进行操控:
拍卖时长,这是一个具有争议的参数,有人觉得15分钟都太长,有人觉得30分钟都不算短,并且其时没有数据表明到底多长时间比较合适,由于也得做成操控项;
拍卖延倒ji时,即在延倒ji时内假如还有人出价,拍卖主动延,延伸=延周期+拍卖剩下时长;
拍卖延周期,即假如在延倒ji时内有人出价,应该再添加的拍卖时长;
拍卖一口价系数,这个系数决定了拍卖的高价,对,你没有看错,咱们为了避免某些订单价格被拉得太高,对高价也进行了必定程度的操控;
加价起伏,即每一次点击可以在当前价格的基础上的加价金额;
体系定价(+起拍加价),即咱们对订单有个体系定价,次出价不是体系定价,而是体系定价+起拍加价,即起拍价=体系定价+起拍加价。
收起阅读 »
常规智能代还APP开发公司
常规智能代还APP开发公司,咨询(张13O微66O电29294)智能管家APP开发定制结合于市场趋势,要开发成功的智能管家APP软件需要对市场有敏锐的触觉,开发者需要把握市场动态,做到发展趋势的标记引导。这样对你的智能管家APP开发设计、市场营销、智能管家APP推广运营等方面都有帮助。
智能管家APP开发定制结合于市场趋势,要开发成功的xyk智能管家APP软件需要对市场有敏锐的触觉,开发者需要把握市场动态,做到发展趋势的标记引导。这样对你的xyk智能管家APP开发设计、市场营销、智能管家APP推广运营等方面都有帮助。
今天我来为大家分析一下市面上常见的几种代还模式:
- 自助养卡:用5%的余e全自动还清剩余账单。
2.收kuan:内置聚合支付,八通道24小时刷卡秒到账。
3.分享:-分销系统,无限裂变。
4.增值:功能和信卡申请增值业务。
5.收益:无限开商户/,分润实时秒结。
xyk空卡代还智能管家APP开发系统
6.网申信卡kuan集成分销返佣系统(11家银行15家公司无限裂变)
- 平台(自动秒回kuan无线连刷)
8.智能卡系统(完美账单落地商户,预留5-10%
xyk余e代偿实际上为消费者提供了资金的中短期活动性,消费者经过低利率的代偿借kuan交流了高利率信誉卡存kuan余e。这样一来,既可以降低还kuan付息的压力,又能提升消费e度。
常规智能代还APP开发公司,咨询(张13O微66O电29294)智能管家APP开发定制结合于市场趋势,要开发成功的智能管家APP软件需要对市场有敏锐的触觉,开发者需要把握市场动态,做到发展趋势的标记引导。这样对你的智能管家APP开发设计、市场营销、智能管家APP推广运营等方面都有帮助。
智能管家APP开发定制结合于市场趋势,要开发成功的xyk智能管家APP软件需要对市场有敏锐的触觉,开发者需要把握市场动态,做到发展趋势的标记引导。这样对你的xyk智能管家APP开发设计、市场营销、智能管家APP推广运营等方面都有帮助。
今天我来为大家分析一下市面上常见的几种代还模式:
- 自助养卡:用5%的余e全自动还清剩余账单。
2.收kuan:内置聚合支付,八通道24小时刷卡秒到账。
3.分享:-分销系统,无限裂变。
4.增值:功能和信卡申请增值业务。
5.收益:无限开商户/,分润实时秒结。
xyk空卡代还智能管家APP开发系统
6.网申信卡kuan集成分销返佣系统(11家银行15家公司无限裂变)
- 平台(自动秒回kuan无线连刷)
8.智能卡系统(完美账单落地商户,预留5-10%
xyk余e代偿实际上为消费者提供了资金的中短期活动性,消费者经过低利率的代偿借kuan交流了高利率信誉卡存kuan余e。这样一来,既可以降低还kuan付息的压力,又能提升消费e度。
收起阅读 »
专业分销制度拓客商城APP开发公司
专业分销制度拓客商城APP开发公司,咨询(张13O微66O电29294)
分销商城系统是指将单个结合为群体,大家一起进行推广的一种模式。这样的方式是属于分销商城系统中的一种。与微商分销 是属于包含与被包含的关系。
换句话说,是分销商城系统的一种细化。
并且,基于平台,我们可以进行多层分销。从而真正实 现线上线下的整合。 分销商城系统模式有什么功能?
1、拓展企业销售渠道:为企业搭建只属于自己的产品分销渠道;
2、加快企业分销速度,提升企业度、树立品牌形象,增加用户信赖;
3、分销商城系统有助于企业快速招募众多优质的分销商和代理商;
4、加快资金回流速度,分销商城系统可以缩短货款账期,使货款尽快回流;
5、解决企业库存积压问题,由于加快了产品分销速度,解决了很多传统中小企业长期以来面临的库存积压问题。
专业分销制度拓客商城APP开发公司,咨询(张13O微66O电29294)
分销商城系统是指将单个结合为群体,大家一起进行推广的一种模式。这样的方式是属于分销商城系统中的一种。与微商分销 是属于包含与被包含的关系。
换句话说,是分销商城系统的一种细化。
并且,基于平台,我们可以进行多层分销。从而真正实 现线上线下的整合。 分销商城系统模式有什么功能?
1、拓展企业销售渠道:为企业搭建只属于自己的产品分销渠道;
2、加快企业分销速度,提升企业度、树立品牌形象,增加用户信赖;
3、分销商城系统有助于企业快速招募众多优质的分销商和代理商;
4、加快资金回流速度,分销商城系统可以缩短货款账期,使货款尽快回流;
5、解决企业库存积压问题,由于加快了产品分销速度,解决了很多传统中小企业长期以来面临的库存积压问题。
收起阅读 »
二、组件开发兼容性测试之获取$parent,$children
上一篇我们文章测试了created,mounted,watch,computed的执行顺序。
这篇文章我们来测试不同平台,在子组件中获取$parent,在父组件中获取$children。因为这种操作,在组件库中出现的频率非常之高。
话不多说,我们的测试依然在这几个平台中进行。
这次我们分别在父组件和子组件中的created,mounted,computed,watch中获取parent和children。
H5:
微信小程序:
百度小程序:
支付宝小程序:
字节小程序:
QQ小程序:
飞书小程序:
快应用:
总结:
H5:
one组件的computed,watch,created无法获取子组件实例,但是mounted可以获取到。
two组件的created,mounted,computed,watch都可以获取到父组件的实例。
微信小程序:
和H5一致。
百度小程序:
可以看到,由于执行顺序原因,父组件全部无法获取到子组件的实例,这里的解决办法我们后续再说。
而子组件全部可以获取到父组件实例。
支付宝小程序:
与H5,微信小程序一致。
字节小程序:
字节小程序在父组件中全部无法获取子组件实例。值得一提的是,在子组件中,computed,watch也无法获取到父组件,只能在created和mounted中获取。
QQ小程序:
与H5,微信小程序,支付宝小程序一致。
飞书小程序:
与字节小程序完全一致。
快应用
与字节小程序,飞书小程序完全一致。
可以看到,在不同平台中获取parent,children都不一致。那么,我们如何在编写组件时合理的规避不同平台的差异呢?
首先,我们在子组件获取富足监事,保险起见,我们应该在mounted中来获取父组件实例。
那么,在父组件中获取子组件时,我们又该怎么做呢?
当然,我们首先想到的是,用refs。但是在组件库中,我们应该考虑用户的体验。而子组件又是通过插槽的形式注入到父组件中,所以,refs显然不能出现在组件库中,只能由用户主动去编写。许多vue大型组件库中,也是使用parent和children的操作。难道真的没有办法了吗?
这里我的解决办法是,子组件渲染完成后去通知父组件,并且带上该子组件的实例。也就是在子组件的mounted中,通过emit通知父组件,父组件on监听,然后就可以获取到了。
uni.$on("childrenReady", (children) => {
console.log("============监听子组件加载完成=============", children);
})
uni.$emit("childrenReady", this);
最后我们看一下执行结果:
H5:
微信小程序:
百度小程序:
支付宝小程序:
字节小程序:
QQ小程序:
飞书小程序:
快应用:
可以看到,这种方法兼容全端。
那这次的测试就告一段落了,接下来我们测试组件开发的必备,也就是组件样式穿透。
上一篇我们文章测试了created,mounted,watch,computed的执行顺序。
这篇文章我们来测试不同平台,在子组件中获取$parent,在父组件中获取$children。因为这种操作,在组件库中出现的频率非常之高。
话不多说,我们的测试依然在这几个平台中进行。
这次我们分别在父组件和子组件中的created,mounted,computed,watch中获取parent和children。
H5:
微信小程序:
百度小程序:
支付宝小程序:
字节小程序:
QQ小程序:
飞书小程序:
快应用:
总结:
H5:
one组件的computed,watch,created无法获取子组件实例,但是mounted可以获取到。
two组件的created,mounted,computed,watch都可以获取到父组件的实例。
微信小程序:
和H5一致。
百度小程序:
可以看到,由于执行顺序原因,父组件全部无法获取到子组件的实例,这里的解决办法我们后续再说。
而子组件全部可以获取到父组件实例。
支付宝小程序:
与H5,微信小程序一致。
字节小程序:
字节小程序在父组件中全部无法获取子组件实例。值得一提的是,在子组件中,computed,watch也无法获取到父组件,只能在created和mounted中获取。
QQ小程序:
与H5,微信小程序,支付宝小程序一致。
飞书小程序:
与字节小程序完全一致。
快应用
与字节小程序,飞书小程序完全一致。
可以看到,在不同平台中获取parent,children都不一致。那么,我们如何在编写组件时合理的规避不同平台的差异呢?
首先,我们在子组件获取富足监事,保险起见,我们应该在mounted中来获取父组件实例。
那么,在父组件中获取子组件时,我们又该怎么做呢?
当然,我们首先想到的是,用refs。但是在组件库中,我们应该考虑用户的体验。而子组件又是通过插槽的形式注入到父组件中,所以,refs显然不能出现在组件库中,只能由用户主动去编写。许多vue大型组件库中,也是使用parent和children的操作。难道真的没有办法了吗?
这里我的解决办法是,子组件渲染完成后去通知父组件,并且带上该子组件的实例。也就是在子组件的mounted中,通过emit通知父组件,父组件on监听,然后就可以获取到了。
uni.$on("childrenReady", (children) => {
console.log("============监听子组件加载完成=============", children);
})
uni.$emit("childrenReady", this);
最后我们看一下执行结果:
H5:
微信小程序:
百度小程序:
支付宝小程序:
字节小程序:
QQ小程序:
飞书小程序:
快应用:
可以看到,这种方法兼容全端。
那这次的测试就告一段落了,接下来我们测试组件开发的必备,也就是组件样式穿透。
收起阅读 »
一、组件开发兼容性测试之created,mounted,watch,computed执行顺序
写在前面:
在一个组件开发之前,我们通常会考虑其兼容性,尤其是像uniapp跨多端开发。很可能会出现不同平台执行顺序不一致的问题,这就导致了我们在某个品台会产生不一样的结果,甚至影响整个程序的执行。于是,我对多家不同的平台进行了常用的生命周期以及watch监听和computed计算属性的测试。 (电脑承受了莫大的压力)
本次测试我们在如下平台进行:
测试中我们将采用组件库常用开发模式的页面>parent>child,注意这里的parent和child是通过插槽注入页面的。测试模拟了常用的 check-box-group
check-box
,radio-box-group
radio-box
,tabs
,tab
等需要同时存在于页面的测试方法。这些大多出现于组件库。
<test-one>
<test-two></test-two>
</test-one>
以下是测试结果:
H5:
微信小程序
百度小程序
支付宝小程序
字节小程序
QQ小程序
快手小程序
(不支持个人,暂时略过)
飞书小程序
快应用
总结:
我们在页面和组件中都有四个console,分别是created,mounted,watch(第一次就监听),computed
各平台执行顺序如下:
h5::
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > two-mounted > one-mounted > 页面-mounted
微信小程序:
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > one-mounted > two-mounted > 页面-mounted (与h5不同的仅仅是one的mounted和two的mounted的执行顺序不同)
百度小程序:
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > one-mounted > two-computed > two-watch > two-created > two-mounted > 页面-mounted (与h5,微信不同的是,百度小程序的组件会完全根据顺序执行所有的,而h5,微信无论页面还是组件,mounted始终会最后执行)
支付宝小程序:
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > two-mounted > one-mounted > 页面-mounted (竟然和h5完全一致,点赞!!!)
字节小程序 (不测不知道,一测吓一跳。我说之前checkbox,radio,tab...怎么老是字节有问题!!!)
页面-computed > 页面-watch > one-computed > one-watch > two-computed > two-watch > 页面-created > 页面-mounted > one-created > one-mounted > two-created > two-mounted (可以看到,字节的执行顺序与其他小程序的差异性十分大,完全是按照 computed > watch > created > mounted顺序执行,而无视了组件和页面层级。)
QQ小程序
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > one-mounted > two-mounted > 页面-mounted (不愧是腾讯,QQ的执行顺序与微信完全一样)
快手小程序
(不支持个人,暂时略过)
飞书小程序
页面-computed > 页面-watch > one-computed > one-watch > two-computed > two-watch > 页面-created > 页面-mounted > one-created > one-mounted > two-created > two-mounted (好吧,和字节小程序的完全一样。。。)
快应用
页面-computed > 页面-watch > one-computed > one-watch > two-computed > two-watch > 页面-created > 页面-mounted > one-created > one-mounted > two-created > two-mounted (和字节,飞书一致。这是个值得深思的问题。)。
测试告一段落,之后我们会测试获取$parent,$children的操作。
写在前面:
在一个组件开发之前,我们通常会考虑其兼容性,尤其是像uniapp跨多端开发。很可能会出现不同平台执行顺序不一致的问题,这就导致了我们在某个品台会产生不一样的结果,甚至影响整个程序的执行。于是,我对多家不同的平台进行了常用的生命周期以及watch监听和computed计算属性的测试。 (电脑承受了莫大的压力)
本次测试我们在如下平台进行:
测试中我们将采用组件库常用开发模式的页面>parent>child,注意这里的parent和child是通过插槽注入页面的。测试模拟了常用的 check-box-group
check-box
,radio-box-group
radio-box
,tabs
,tab
等需要同时存在于页面的测试方法。这些大多出现于组件库。
<test-one>
<test-two></test-two>
</test-one>
以下是测试结果:
H5:
微信小程序
百度小程序
支付宝小程序
字节小程序
QQ小程序
快手小程序
(不支持个人,暂时略过)
飞书小程序
快应用
总结:
我们在页面和组件中都有四个console,分别是created,mounted,watch(第一次就监听),computed
各平台执行顺序如下:
h5::
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > two-mounted > one-mounted > 页面-mounted
微信小程序:
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > one-mounted > two-mounted > 页面-mounted (与h5不同的仅仅是one的mounted和two的mounted的执行顺序不同)
百度小程序:
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > one-mounted > two-computed > two-watch > two-created > two-mounted > 页面-mounted (与h5,微信不同的是,百度小程序的组件会完全根据顺序执行所有的,而h5,微信无论页面还是组件,mounted始终会最后执行)
支付宝小程序:
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > two-mounted > one-mounted > 页面-mounted (竟然和h5完全一致,点赞!!!)
字节小程序 (不测不知道,一测吓一跳。我说之前checkbox,radio,tab...怎么老是字节有问题!!!)
页面-computed > 页面-watch > one-computed > one-watch > two-computed > two-watch > 页面-created > 页面-mounted > one-created > one-mounted > two-created > two-mounted (可以看到,字节的执行顺序与其他小程序的差异性十分大,完全是按照 computed > watch > created > mounted顺序执行,而无视了组件和页面层级。)
QQ小程序
页面-computed > 页面-watch > 页面-created > one-computed > one-watch > one-created > two-computed > two-watch > two-created > one-mounted > two-mounted > 页面-mounted (不愧是腾讯,QQ的执行顺序与微信完全一样)
快手小程序
(不支持个人,暂时略过)
飞书小程序
页面-computed > 页面-watch > one-computed > one-watch > two-computed > two-watch > 页面-created > 页面-mounted > one-created > one-mounted > two-created > two-mounted (好吧,和字节小程序的完全一样。。。)
快应用
页面-computed > 页面-watch > one-computed > one-watch > two-computed > two-watch > 页面-created > 页面-mounted > one-created > one-mounted > two-created > two-mounted (和字节,飞书一致。这是个值得深思的问题。)。
测试告一段落,之后我们会测试获取$parent,$children的操作。
收起阅读 »
山东消防应急设备巡检系统APP定制开发公司
山东消防应急设备巡检系统APP定制开发公司,咨询(邵137微93I6电I229)消防应急设备巡检系统APP定制开发公司,应急救援智慧消防APP开发山东抖米信息科技有限公司,是一家专业互联网+系统整体解决方案提供商。2018年被认定为高新技术企业,双软企业,国际质量管理体系认证。公司秉承“技术驱动商业未来”的发展理念,在技术研发、产品质量上精益求精。
专业人找专业公司做专业软件,安全的用单设备,实时监控
通过“智慧消防APP”的消防巡查功能,用户可以在巡查过程中,直观的看到单位中那些地方是应该检查的,并且通过扫描这种身份标识的同时将检查信息记录。个人与领导都可以对检查工作情况一目了然。“智慧消防APP”为了应对不同行业、社会单位、检查人员的不同需求,还针对消防法规中规定的每个消防设施或重点部位,都对应了相应的的检查标准,巡查人员通过下载智慧消防APP,即可扫描消防设备处张贴的NFC身份标签,查看相应的检查标准,通过“智慧消防APP”这一智慧型软件进行对应位置的检查。
山东消防应急设备巡检系统APP定制开发公司,咨询(邵137微93I6电I229)消防应急设备巡检系统APP定制开发公司,应急救援智慧消防APP开发山东抖米信息科技有限公司,是一家专业互联网+系统整体解决方案提供商。2018年被认定为高新技术企业,双软企业,国际质量管理体系认证。公司秉承“技术驱动商业未来”的发展理念,在技术研发、产品质量上精益求精。
专业人找专业公司做专业软件,安全的用单设备,实时监控
通过“智慧消防APP”的消防巡查功能,用户可以在巡查过程中,直观的看到单位中那些地方是应该检查的,并且通过扫描这种身份标识的同时将检查信息记录。个人与领导都可以对检查工作情况一目了然。“智慧消防APP”为了应对不同行业、社会单位、检查人员的不同需求,还针对消防法规中规定的每个消防设施或重点部位,都对应了相应的的检查标准,巡查人员通过下载智慧消防APP,即可扫描消防设备处张贴的NFC身份标签,查看相应的检查标准,通过“智慧消防APP”这一智慧型软件进行对应位置的检查。
收起阅读 »
关于上周五部分iOS设备上App引擎崩溃的公告
各位开发者,
很遗憾的告知大家,DCloud服务在2021年11月19日下午遭遇大流量网络攻击,触发了iOS客户端的一个隐藏Bug,导致部分iOS设备上App引擎崩溃。
故障发生后,DCloud的工程师高度紧张,全力投入,在20分钟内将DCloud服务恢复正常,开发者的iOS App也随即恢复正常。
DCloud并非不负责任,也并非无能的公司。众多工程师仔细讨论,如何彻底杜绝将来再次发生类似故障,我们采取了如下完善措施:
- 服务器端技术专家组紧急集合,逐条确认服务器端的安全防控措施;补充说明:DCloud开发者服务已通过国家信息安全等级保护三级,证书编号:11010813802-20001;
- iOS App引擎当晚发布紧急更新,解决该隐藏漏洞。并检查了所有服务器返回数据的代码,确保以后即便服务器异常也不会造成App引擎崩溃;建议开发者尽快升级HBuilderX或离线打包SDK。
原因详细解释
- DCloud数据采集的目的
为了持续优化应用性能、质量及提供统计报表,基于DCloud引擎开发的App,在运行过程中会采集应用启动时间、异常错误日志这两方面的数据。
因为开发者的js代码无法正常采集到这些信息,比如启动时间,开发者的js代码能打点的第一行代码,已经是app运行了一会后才发生的事情了;崩溃更是如此,app崩溃时js也无法运行和打点数据。但这些信息又对于优化应用有重要参考意义。
另外其他适配原生应用的统计sdk也不能正常统计到这2个信息,它们无法准确记录从app启动到首屏webview渲染的启动时间。
这些数据,一方面用于DCloud优化产品,比如查看在哪些设备上启动慢或崩溃率高;另一方面,DCloud也给开发者提供了web界面自助查看这些数据,帮助开发者了解运营情况,详见dev.dcloud.net.cn。 - DCloud数据采集的合规性
DCloud数据采集内容在HBuilder用户许可协议(菜单帮助-许可协议)和DCloud引擎隐私文档(Android平台、iOS平台)中均有明确说明。
这些数据的采集规则和脱敏策略符合中国各大应用商店规范和个人信息保护法,基于DCloud引擎开发的合法App,均可正常上线应用商店。
DCloud通过了国家信息安全等级保护三级,证书编号:11010813802-20001,相关数据的保护措施完备。
DCloud并非大数据公司,对采集用户个人隐私、开发者代码都没有兴趣。 - 如果仅是采集数据,没有返回内容,怎么会导致闪退?
DCloud服务器会返回deviceID,因为现在手机上获取imei等唯一标记越来越困难,手机端app权限设置变化一次都可能导致设备id变化。为了尽可能保持标记统一性,由DCloud服务器计算一个更准确的deviceID。
19日下午DCloud服务遭受恶意攻击后,无法给客户端返回预期格式的deviceID,iOS相关代码容错不合理造成了闪退。 - 影响面
11月19日下午,iOS引擎,在异常的那20分钟内启动iOS app无法成功。之前启动,在那20分钟内使用的客户不会受影响。对开发者的波及面是比较有限的。
解决方案
在事故发生后,DCloud成立了专案组,首先应急解决了服务端故障,然后周五下午开会讨论治根方案,周六日与受影响的开发者主动打电话沟通,周一再次开了一天复盘总结会。
累计执行了众多方案:
- 采集服务器与客户端零信任机制,各自根治隐患
- 服务器强化拨测报警机制,对会造成重大故障的系统进行每分钟一次的拨测,在最短时间内发送告警
- 客户端排查所有请求代码,填补所有涉及服务器返回的容错代码,一处不漏(已于19日当晚加班发版)
以后即便网络服务再被攻击,也100%确保不会闪退。 - 与受影响的开发者主动沟通
此次故障给开发者造成的损失,我们感同身受。大家都是写代码的,都会被客户和领导责问。虽然故障时间只有20分钟,但发生这样的事情,肯定会给一些开发者造成损失,并破坏开发者对DCloud的信心。
DCloud工程师主动联系了受影响的开发者,有些开发者电话或论坛私信未回,除了回复我们电话或私信外,也可以主动加QQ:154419462。
我们会尽所能帮助开发者减少事故的影响,磋商令开发者可持续信任的方案。
针对本帖中开发者的热点评论,答复如下:
-
关于源码:uni小程序sdk,面向大开发商,一直都有签署保密协议后获取源码的机制。如果你是政府机构或知名企业,可以发送邮件到bd@dcloud.io申请。
-
关于后续App启动时间采集,也会改进策略,新增打点转向uniCloud版本和私有化版本,uni统计会开源并提供uni-admin插件,具体方案稍后公布。
-
云打包和离线打包没有本质区别。云打包使用安心打包时,不会向DCloud服务器发送代码;即便不用安心打包,使用普通云打包,发送的仅是uni-app编译后的wgt,也不是源码,而且DCloud服务器不保存这些wgt。这些都在用户协议里明确说明了,DCloud不会违反用户协议,而且对这些wgt包也没有兴趣。
多年来,DCloud一直坚持为开发者提供免费、高效的开发工具
的初心和使命,持续为开发者赋能。
DCloud初心不变,也希望大家继续信任DCloud!
各位开发者,
很遗憾的告知大家,DCloud服务在2021年11月19日下午遭遇大流量网络攻击,触发了iOS客户端的一个隐藏Bug,导致部分iOS设备上App引擎崩溃。
故障发生后,DCloud的工程师高度紧张,全力投入,在20分钟内将DCloud服务恢复正常,开发者的iOS App也随即恢复正常。
DCloud并非不负责任,也并非无能的公司。众多工程师仔细讨论,如何彻底杜绝将来再次发生类似故障,我们采取了如下完善措施:
- 服务器端技术专家组紧急集合,逐条确认服务器端的安全防控措施;补充说明:DCloud开发者服务已通过国家信息安全等级保护三级,证书编号:11010813802-20001;
- iOS App引擎当晚发布紧急更新,解决该隐藏漏洞。并检查了所有服务器返回数据的代码,确保以后即便服务器异常也不会造成App引擎崩溃;建议开发者尽快升级HBuilderX或离线打包SDK。
原因详细解释
- DCloud数据采集的目的
为了持续优化应用性能、质量及提供统计报表,基于DCloud引擎开发的App,在运行过程中会采集应用启动时间、异常错误日志这两方面的数据。
因为开发者的js代码无法正常采集到这些信息,比如启动时间,开发者的js代码能打点的第一行代码,已经是app运行了一会后才发生的事情了;崩溃更是如此,app崩溃时js也无法运行和打点数据。但这些信息又对于优化应用有重要参考意义。
另外其他适配原生应用的统计sdk也不能正常统计到这2个信息,它们无法准确记录从app启动到首屏webview渲染的启动时间。
这些数据,一方面用于DCloud优化产品,比如查看在哪些设备上启动慢或崩溃率高;另一方面,DCloud也给开发者提供了web界面自助查看这些数据,帮助开发者了解运营情况,详见dev.dcloud.net.cn。 - DCloud数据采集的合规性
DCloud数据采集内容在HBuilder用户许可协议(菜单帮助-许可协议)和DCloud引擎隐私文档(Android平台、iOS平台)中均有明确说明。
这些数据的采集规则和脱敏策略符合中国各大应用商店规范和个人信息保护法,基于DCloud引擎开发的合法App,均可正常上线应用商店。
DCloud通过了国家信息安全等级保护三级,证书编号:11010813802-20001,相关数据的保护措施完备。
DCloud并非大数据公司,对采集用户个人隐私、开发者代码都没有兴趣。 - 如果仅是采集数据,没有返回内容,怎么会导致闪退?
DCloud服务器会返回deviceID,因为现在手机上获取imei等唯一标记越来越困难,手机端app权限设置变化一次都可能导致设备id变化。为了尽可能保持标记统一性,由DCloud服务器计算一个更准确的deviceID。
19日下午DCloud服务遭受恶意攻击后,无法给客户端返回预期格式的deviceID,iOS相关代码容错不合理造成了闪退。 - 影响面
11月19日下午,iOS引擎,在异常的那20分钟内启动iOS app无法成功。之前启动,在那20分钟内使用的客户不会受影响。对开发者的波及面是比较有限的。
解决方案
在事故发生后,DCloud成立了专案组,首先应急解决了服务端故障,然后周五下午开会讨论治根方案,周六日与受影响的开发者主动打电话沟通,周一再次开了一天复盘总结会。
累计执行了众多方案:
- 采集服务器与客户端零信任机制,各自根治隐患
- 服务器强化拨测报警机制,对会造成重大故障的系统进行每分钟一次的拨测,在最短时间内发送告警
- 客户端排查所有请求代码,填补所有涉及服务器返回的容错代码,一处不漏(已于19日当晚加班发版)
以后即便网络服务再被攻击,也100%确保不会闪退。 - 与受影响的开发者主动沟通
此次故障给开发者造成的损失,我们感同身受。大家都是写代码的,都会被客户和领导责问。虽然故障时间只有20分钟,但发生这样的事情,肯定会给一些开发者造成损失,并破坏开发者对DCloud的信心。
DCloud工程师主动联系了受影响的开发者,有些开发者电话或论坛私信未回,除了回复我们电话或私信外,也可以主动加QQ:154419462。
我们会尽所能帮助开发者减少事故的影响,磋商令开发者可持续信任的方案。
针对本帖中开发者的热点评论,答复如下:
-
关于源码:uni小程序sdk,面向大开发商,一直都有签署保密协议后获取源码的机制。如果你是政府机构或知名企业,可以发送邮件到bd@dcloud.io申请。
-
关于后续App启动时间采集,也会改进策略,新增打点转向uniCloud版本和私有化版本,uni统计会开源并提供uni-admin插件,具体方案稍后公布。
-
云打包和离线打包没有本质区别。云打包使用安心打包时,不会向DCloud服务器发送代码;即便不用安心打包,使用普通云打包,发送的仅是uni-app编译后的wgt,也不是源码,而且DCloud服务器不保存这些wgt。这些都在用户协议里明确说明了,DCloud不会违反用户协议,而且对这些wgt包也没有兴趣。
多年来,DCloud一直坚持为开发者提供免费、高效的开发工具
的初心和使命,持续为开发者赋能。
DCloud初心不变,也希望大家继续信任DCloud!
收起阅读 »
竞拍商城抢购商品系统APP定制开发公司
竞拍商城抢购商品系统APP定制开发公司,咨询(张13O微66O电29294)
一、邀请好友
邀请守友或其他用户参与拍卖出价成功并被其他用户加价超越的,邀清请人可以获得加价阶梯3%的返利红包,若越清的用户终竞拍成功,遨请人可获得终成交价1%的返利红包,返利红包即时到达用户的账户余额中,可随时。
二、赠送积分
竞拍成功用户在支付拍品尾款后,可以获得平台赠送的积分,用户积分可在拍卖竞拍[我的]页面中查询。
三、竞拍声明
拄卖竞柏坚持公开、公平、公正原则,禁止用户使用一切非本人点击出价的一切手段和方法,禁止使用外挂接口或一切破环公平出价的手段和方法。一经发现,拍卖竞拍将会立即把涉事用户拉入黑名
单,情节严重的,平台将采取包括但不限于查封账户、停止、**出价红包等保护措施,直至报送馨方追究刑事责任。
四、竞拍保证金
用户参与竞拍时,需冻结当前出价价格20%的保证金,当用户出价被其他用户超越时,保证金立即实时解冻。保证金不足的,无法获得竞拍贲格。
五、积分使用
用户积分可在积分商斯中的“寄拍区”和“兑换区”里换购商品。在“寄拍区中换陶的客拍商品可以委托拍卖竞拍进行拍卖在“兑换区”里换吭的商品将免费0元获得,并在用户换购商品后的5个工
日内发货。
参与竞拍
用户在拍卖竞拍平台参与竞拍,表示用户已充分了解并接受拍卖竞拍平台的拍卖规则和拍品的详细情况。用户出价成功表示用户在所出价格下接受拍品的一切现状。
六、出价红包
用户每次出价成功并被其他用户加价超越时,可以获得加价阶梯10%的出价红包,该红包即时到达用户的账户余额中,可随时可以再次参与竞拍活动。
七.拍卖竞拍拍卖采用英格兰式拍卖模式,所有拍品均从起拍价起拍,竞价按约定的增幅进行,逐次由低至高出价。拍卖出价时,的出价者不可以继续出价。拍卖结束时,出价高者竞价成功。
八、交易判定
拍卖结束时,用户须在拍卖结束后的24小时内支付拍品成交价80%的尾款,逾期未支付的,冻结的保证金将作为违约金被扣除。九、拍品交割
用户竞拍成功购得的拍品,平台于收到用户支付尾款后的5个工作日内发货,用户可在拍卖竞拍[我的]页面查询拍品物流信息。
十、拍品披露
拍卖竞拍所有拍品在平台预展2天,平台尽大可能披露拍品详细信息,闲户在预展期间应认真阅读和审核拍品信息。用户参与竞拍即表明用户已充分了解并接受拍品的一切现状。十一、参与竞拍
竞拍商城抢购商品系统APP定制开发公司,咨询(张13O微66O电29294)
一、邀请好友
邀请守友或其他用户参与拍卖出价成功并被其他用户加价超越的,邀清请人可以获得加价阶梯3%的返利红包,若越清的用户终竞拍成功,遨请人可获得终成交价1%的返利红包,返利红包即时到达用户的账户余额中,可随时。
二、赠送积分
竞拍成功用户在支付拍品尾款后,可以获得平台赠送的积分,用户积分可在拍卖竞拍[我的]页面中查询。
三、竞拍声明
拄卖竞柏坚持公开、公平、公正原则,禁止用户使用一切非本人点击出价的一切手段和方法,禁止使用外挂接口或一切破环公平出价的手段和方法。一经发现,拍卖竞拍将会立即把涉事用户拉入黑名
单,情节严重的,平台将采取包括但不限于查封账户、停止、**出价红包等保护措施,直至报送馨方追究刑事责任。
四、竞拍保证金
用户参与竞拍时,需冻结当前出价价格20%的保证金,当用户出价被其他用户超越时,保证金立即实时解冻。保证金不足的,无法获得竞拍贲格。
五、积分使用
用户积分可在积分商斯中的“寄拍区”和“兑换区”里换购商品。在“寄拍区中换陶的客拍商品可以委托拍卖竞拍进行拍卖在“兑换区”里换吭的商品将免费0元获得,并在用户换购商品后的5个工
日内发货。
参与竞拍
用户在拍卖竞拍平台参与竞拍,表示用户已充分了解并接受拍卖竞拍平台的拍卖规则和拍品的详细情况。用户出价成功表示用户在所出价格下接受拍品的一切现状。
六、出价红包
用户每次出价成功并被其他用户加价超越时,可以获得加价阶梯10%的出价红包,该红包即时到达用户的账户余额中,可随时可以再次参与竞拍活动。
七.拍卖竞拍拍卖采用英格兰式拍卖模式,所有拍品均从起拍价起拍,竞价按约定的增幅进行,逐次由低至高出价。拍卖出价时,的出价者不可以继续出价。拍卖结束时,出价高者竞价成功。
八、交易判定
拍卖结束时,用户须在拍卖结束后的24小时内支付拍品成交价80%的尾款,逾期未支付的,冻结的保证金将作为违约金被扣除。九、拍品交割
用户竞拍成功购得的拍品,平台于收到用户支付尾款后的5个工作日内发货,用户可在拍卖竞拍[我的]页面查询拍品物流信息。
十、拍品披露
拍卖竞拍所有拍品在平台预展2天,平台尽大可能披露拍品详细信息,闲户在预展期间应认真阅读和审核拍品信息。用户参与竞拍即表明用户已充分了解并接受拍品的一切现状。十一、参与竞拍