传统的方式开发app：

首先需要1个把app的样子给你画出来的UI设计师。然后，你的app是跑在手机上的，主流的手机平台有安卓和苹果两种。一般这里会安排2个安卓，2个苹果，合计4名移动端软件开发工程师。

整个软件，不光是运行在我们手机上的那部分，他的数据是需要在服务器上存储和运算。这里就又需要1个服务端的软件开发工程师，1个维持服务器能够持续正常地运转的运维工程师。

其他呢，实际上还需要项目经理、产品经理等。这里假设我们用最简的结构，你自己来负责刚刚提到的一群人的协作和需求的传达，也就是自己兼任产品和项目经理。

那这里也需要用到4+2=6个程序员。这类高新技术人才的工资一般在1-3万元左右，我们取中间值也就是按1.5万来算，那么6个人就需要9万元/一个月。一款软件从开发、测试再到验收，怎么也需要2个月以上。那假设你只用了2个月，那这里一共需要程序员工资：18万元左右。
加上前面说的美工，一个公司还要场地租金，职工社保等成本。做这么一个原生app的开发最少得20万起步。
就这还只是比较顺利的理想情况，发布app的第一个版本的费用。后续，还要运维升级等。然后项目按照刚刚这个组织结构坚持个1年，光技术研发团队的成本就已经上百万了。假设此时，如果没有做出点业绩，小公司也就已经倒闭了。

但是，如果使用 uni-app + uniCloud 框架

用js一门语言，开发1套代码，然后通过免费的编译技术，一次性得到：安卓APP、苹果APP，H5手机端网页，各大小程序端，如：微信小程序、抖音小程序、快手小程序、支付宝小程序等。
并且uniCloud的底层是DCloud联合阿里云和腾讯云基于serverless研发的免运维的服务器。
这样原来需要安卓、苹果、服务端开发、服务端运维，4类工程师共同协作才能完成的工作，现在一个前端工程师就能胜任。独立完成，免去多人之间协作的沟通和管理成本。

另外这款框架，拥有强大的插件生态，让你大部分功能都无需自己开发，大到，视频通话、人脸识别，小到登陆注册、发送短信验证码等，直接导入自己的工程组装一下即可。
前面提到的6人3个月才能完成的工作，现在2个js工程师2个月即可完成。从项目的开发，到后期的更新升级一直受益。整体可节约了不止10倍的开发和运维成本。

行业认证服务商清单

经过评定，目前已经获得行业服务商资格的公司包括：

• 大连火石科技有限公司。网赚行业服务商。插件地址：https://ext.dcloud.net.cn/plugin?id=4095、https://ext.dcloud.net.cn/plugin?id=4826
• 广东优势智云信息科技股份有限公司。OA办公行业服务商。插件地址：https://ext.dcloud.net.cn/plugin?id=5038
• 郑州琼锦信息技术有限公司。教育行业服务商。插件地址：https://ext.dcloud.net.cn/plugin?id=4610
• 山东九将教育科技有限公司。CRM行业服务商。插件地址：https://ext.dcloud.net.cn/plugin?id=5510

DCloud行业认证服务商招标

“DCloud行业认证服务商”，是DCloud官方认可的在某行业的企业级合作伙伴。

“DCloud行业认证服务商”将享受：

1. DCloud官方背书，获得奖牌和电子证书，可在DCloud官网查询
2. DCloud为每个行业认证服务商提供10万元扶持金（不是插件包销，也不影响插件继续在插件市场定价销售）
3. DCloud在该行业所得的销售线索、外包订单将都交给行业认证服务商
4. DCloud产品的销售代理资质（uniCloud公用云返佣，同时今年会推出私有云，有更高的代理价差空间）
5. DCloud提供专属技术支持

如何成为“DCloud行业认证服务商”？

1. 向DCloud发邮件提交“DCloud行业认证服务商”申请表（见附件）
2. 在插件市场提交所擅长行业的云端一体项目模板。比如“企业办公”行业的服务商，就需要在插件市场提交一个办公OA类的项目模板。所有模板需基于uni-id，因为这将使需要数字应用的企业主方便的整合，选一个OA模板，再选一个CRM模板，快速组合成一个应用，天然打通账户。
3. DCloud会与申请者详细沟通，签署资金资助合同

DCloud计划招标的17个行业清单：

• 可视化拖拽、低代码
• 社区论坛（DCloud问答社区有意向改版为uniCloud模式，希望行业服务商提供方案，要求支持PC/H5/App/小程序，支持国际化）
• 电商（全端、裂变、拼团、促销，各种功能完善）
• 网赚游戏
• BPM流程管理
• 政企内部办公（可以基于钉钉、企业微信等平台）
• 电子政务（智慧城市、或工商、税务等各个委办局业务系统）
• 线下商户（社区团购、超市、KTV、饭店、饮品店、旅游景点等）
• 地方信息港
• 直播
• 企业自助建站
• 教育（学校、线上教育）
• 医疗（各种医院、相关机构普遍需求的应用）
• CRM
• 招聘
• 研发任务管理
• 研发质量管理

本次行业认证服务商招标预算170万。在电子政务和线下商户等范围较大的领域，可额外增加扶持资金。

若开发商属于其他行业，也可与DCloud沟通探讨扩展新行业。对于有意义的行业，DCloud可以继续追加预算。

“DCloud行业认证服务商”只面向企业。个人可以参加插件大赛，不能申报“DCloud行业认证服务商”。

“DCloud行业认证服务商”需要对所处行业有丰富经验。提交的行业应用项目插件，需在该行业的各种竞品应用中有足够的竞争力。并且有较为广泛的B端需求。

“DCloud行业认证服务商”长期招募，但给予扶持金的招标截止时间是2021年7月1日（与插件大赛截止时间不同）。每个行业只有第一家认证服务商可以拿到扶持金，先到先得，有意向请从速报名。

申请表见附件《DCloud行业认证服务商申请表.doc》

本活动解释权归DCloud.io所有

后记

不管插件大赛还是行业认证服务商招标，截止时间表面看似紧张，实则足够。因为DCloud的开发平台效率实在太高了。如果开发者真的掌握了 HBuilder + uni-app + uniCloud 三剑客，开发效率至少高出其他开发平台10倍。

中国的数字化，全球领先。其他国家生产数字应用的效率和成本远不如中国。而DCloud平台的800多万开发者，开发了十几亿月活的应用，为中国数字化做出了重要贡献。疫情期间，DCloud平台快速完成数百个抗疫项目的上线，这在任何其他国家都不可想象。

没有最好，只有更好。成功的插件大赛和优秀的行业应用，可以让中国的数字化进程继续加速。欢迎广大开发者参与到这一进程中，让应用开发变得更快更好。

HBuilderX和uni系列的文档，同时在紧锣密鼓的筹备多语言版本。接下里，欢迎开发者和我们一起，把中国高效的开发工具和生态输出到海外，为全球数字化贡献中国智慧！

主要原因 是参数的问题。orderInfo这个 参数中的 参数名 必须是小写 不能大写

不说什么其他的东西提示，就只说说uniapp代码提示

用IDEA系列做VUE 项目，编辑器可以自动识别相关的组件，而HBuilderX就是死板的代码提示，根本不灵活和深度

    1:比如vuex全局状态管理，this.$store.state每一步都能准确提示，甚至可以精确找到设置的每一个状态属性  

比如this.$store.state.user.isLogin ，当this.$store.commit()时还能自动分析提示命名空间和方法，而HBuilderX就是0，我现在测试第一步this.$store就完蛋了。

    2:mixins混入后idea自动分析mixins内容，并且在实例中也要提示，而HBuilderX引入mixins后在引入的文件中那是一点提示都没有，只有JS原生语法提示  

    3: 我在api目录下user.js定义导出了 getUserList接口，当我在页面直接输入使用getUserList方法时IDEA会自动import导入这个文件和相关方法  

目前HBuilderX的代码提示层面就停留在基本的VUE语法上，且标准的页面里有模板，样式，代码的单文件模板就还行，稍微结构动下，或其他页面的就基本等于没有，不要求面面俱到，但起码vue这一块得做好吧，还有我最无语的一点，每次配置了编辑器，一更新又要重新配置。

自身原因

已经用 vscode 开发习惯了，原本对于 vue 的开发 Vetur 等插件可以很好的支持，将 nvue 文件直接关联 vue 并不理想，script 标签添加 lang="js" 可以去除下划线，但是 script 部分就没办法代码格式化（有可能只是我没找到办法）

想法

反正 nvue 和 vue 内容格式一模一样，只是我这 vscode 支持不好，那直接按 vue 开发，文件保存时复制一份 nvue 文件，反正打包时 vue 文件也不会打包进去，简单粗暴？

做法

1. 安装 vscode 插件 File Watcher
2. 项目根目录 .vscode/settings.json（没有新建）中配置如下（没有别的需求可以直接使用此配置）：

   {  
    "filewatcher.commands": [  
      {  
        "match": "\\.vue$", //匹配vue文件  
        "isAsync": true, //异步处理  
        "cmd": "cp -f ${file} ${fileDirname}/${fileBasenameNoExt}.nvue", //复制覆盖替换文件  
        "event": "onFileChange" //保存时触发  
      }  
    ]  
   }  

浏览器新加入了HSTS策略。使用该策略的网站，会强制浏览器使用HTTPS协议与该网站通信。从而造成证书不受信任。使用http访问（不要使用https）。
chrome的地址栏里输入 chrome://net-internals/#hsts，把localhost从HSTS中删除
如果是火狐浏览器，在地址栏中输入about:config。查找: security.enterprise_roots.enabled ,默认为false,改为true就可以了。没有此选项，添加一个即可。

盲盒交友 1元相亲

前端：uniapp
后台接口：java springboot
重点：暂无后台管理系统 稍后会完善 管理系统使用vue全家桶

加v zwb584223358 获取源码

扫码体验：

有时点击运行 运行到内置浏览器 没反应；需要运行到浏览器，把网址复制下来，粘贴到内置浏览器上，
新建一个目录，淦！！！！！！！！！！！！提示创建目录，服了，球球你们自己测一测！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！服了服了，要不是有个uniapp项目维护！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
我肯定不是第一个提出来这个问题的人， 点击运行到内置浏览器 上半年就有这个问题！！！！！！！！！！！！！！！！！！！！！！！！！

消息推送作为用户促活的有效利器，具有低成本、高效率的明显优势，已成为App运营中最重要的用户触达方式之一。为帮助开发者有策略地提升 消息推送的效果，增加消息的到达率和点击率，个推消息推送SDK于今年初重磅上线了后效分析功能，旨在为开发者和运营人员科学调整推送策略提供有效支撑。

后效分析功能上线后，我们结合产品目标和用户建议，进行了多次迭代。本文就开发和迭代过程中沉淀的经验与大家做分享，也欢迎感兴趣的开发者们通过企业微信和我们交流。

后效分析功能的开发背景

消息推送过程中，从服务端推送消息、消息到达客户端，到用户点击推送、打开应用的各阶段，都可能存在消息折损的情况。

以往，消息系统通过简单对比下发、到达、展示、点击等四个维度的数据，来计算消息的折损程度。但这样的消息折损计算方式不够准确，运营人员较难深入了解消息的折损原因，也就无法对推送参数、推送设置做出科学有效的改进。此外，以往客户遇到消息推送的问题时，会直接与技术支持人员联系解决，沟通和时间成本较高。

因此，我们需要设计出一种自动化方式，来帮助开发者清晰了解推送消息的各项后效数据，并能够自主、高效地找出消息折损的原因。

后效分析功能的开发思路

我们的解决思路是：

1.推出后效数据报表功能。通过将消息在服务端下发过程中的折损情况以及客户端回执数据进行梳理、统计，形成各环节后效数据的清晰报表，以帮助开发者和运营人员透过数据表象，快速定位出消息折损原因，找到提升推送效果的关键环节。

2.自动采集各推送模块日志并形成后效分析报告。通过不同模块获取推送日志：以类似人工查询日志的方式，将一些含有原因标识的日志进行统一存储和梳理，从而梳理出某条任务下发时产生的所有异常和折损原因。这其中就包含“目标正处于黑名单”“请求受到频控（或流控）限制”等原因。与人工技术支持相比，这样不仅能提高后效分析的效率，还能从一些以往可能被忽略的折损中自动提炼出问题，帮助用户自检并规避一些使用不当的情况。

后效分析功能的开发难点

在开发后效分析功能的过程中，我们也遇到了如下一些技术上的难点：

难点一：日志的聚合归类和后效原因提炼

在通过日志进行消息折损原因排查和分析的过程中，我们首先需要从海量日志数据中筛选出有效的部分，并对该部分日志数据进行归纳，根据我们预先设置的日志解析策略，对全链路的日志数据打上对应标记，以帮助我们分析消息在各阶段的折损原因。

为此，我们对消息推送的整个链路做了一次大梳理，从推送阶段入手，将推送模块区分为入口层、处理层、下发层、客户端等四层，然后对各层可能存在的消息折损原因进行了提炼：

✦在入口层，我们主要关注服务端收到的请求内容是否通过格式校验，以及各类目标参数是否设置无误，比如“CID是否有效”“鉴权信息是否异常”等。

✦在处理层，我们关注目标客户端是否符合下发条件，例如可能因为推送策略限制，导致服务端无法给部分客户端进行后续推送。

✦在下发层，我们关注客户端与服务端的网络连接是否正常，比如，在线通道是否有效等。

✦最终在客户端收到推送、用户点击消息时，客户端也会将回执汇报到服务端模块。这一阶段的消息折损原因可能是“通知开关没有打开”等。

基于以上业务层次区分，我们可以更清晰地看到消息推送的整体业务流程。我们将各阶段可能存在的异常关注点提炼出来，以便于我们梳理相对应的日志模块。最终我们将后效异常原因总结为12类，分别对应消息推送各阶段中可能遇到的折损情况。

难点二：TB级别日志数据的处理和准确计算

基于上述各场景，我们筛选出相关日志，通过前期的标记来提炼消息折损原因。

在一条消息的下发过程中，服务端会产生大量日志，单个功能节点一天的日志量就能达到TB级别。如何对亿级别的日志进行过滤和计算，成为我们进行后效数据分析的第一个难题.

我们通过Flume传输日志，将日志数据写入到HDFS，采用Spark作为计算引擎，HDFS存储原始日志数据和维度数据，最后的报表数据存放在ElasticSearch、Hbase和Mysql中。

海量日志数据的清洗和计算

根据对推送业务特性的了解，我们总结出推送日志数据可能存在的问题如下：

✦ 日志重复。例如，用户不断地登录和登出服务，从而产生大量的重复日志。
✦ 请求重复。例如，用户多次发起相同请求，对某个客户端发送同一条消息。客户端最终只会收到一次消息并展示，但服务器会产生多条重复的客户端/消息关联日志。
✦ 回执重复。下游回执中，由于客户端的网络环境复杂，有时会出现重复回执的情况，从而导致服务器重复打印回执日志。
✦ 日志不足。比如，一般情况下，关闭通知、设备活跃等客户端信息，在推送流程中不会有日志产生，这就必须依赖相关数据作为补充，才能综合评估出客户端的状态信息。

针对以上问题，我们提出的解决办法是“人群打标”。我们按照推送流程对日志数据进行划分，将推送任务影响到的人群分为到达人群、下发人群、请求人群等三类。我们根据消息与客户端的关联情况，对客户端进行打标。例如当采集到“在线下发模块”日志时，如果其中包含某消息与客户端的关联信息，那么我们就会给该推送任务下的客户端打上成功下发标记。每个标记只有0或1，不同日志不会重复打标，如此就避免了日志重复统计的情况。

结合上述人群打标逻辑，我们将四个维度的打标数据汇总，最终得到单个推送任务的原始数据。这份数据内，一个客户端会有多个标记，我们只需要按过滤逻辑将这些标记整理并归纳出最终状态，就可区分该条消息对这个客户端的下发流程最终到了哪一阶段，或是在哪一阶段因何种原因折损。

解决数据倾斜问题

在日志数据的计算过程中，我们还遇到了数据倾斜的问题。

我们按照消息下发阶段将整个日志计算任务拆分成四个。根据推送漏斗，这四个任务之间存在上下游关系。在对指标维度进行聚合的时候，会出现维度聚合体量差异过大导致数据倾斜的情况，甚至因为个别任务计算时间过久拖慢整体的计算进度。

为了解决该问题，我们需要在计算前和计算时对Spark任务进行处理，以减少数据倾斜。

我们采取的处理方式有：1.将大文件分割成小文件，或将小文件合并成大文件，以此保证每个任务处理的日志数据量均匀；2.优化分区策略，防止某个较大推送请求下的所有数据全部汇聚到同一节点，使节点计算压力更均衡；3.优化任务的计算链路，保证以最优的计算链路完成数据处理。

至此，基于如上所述的日志数据处理和计算逻辑，我们就可以在HBase中存储每条任务的后效数据，从而供业务层查询、调用。

总结

近期，我们还引入了Flink流式计算引擎来提升后效数据计算的实时性；我们也结合了更多的消息细则日志进一步完善数据，将后效数据报表升级，推出了消息链路查询功能，借此来帮助开发者更好地了解推送消息下发情况，并根据对应建议来快速提升消息的整体到达率。

“码”上注册和登录个推开发者中心（https://dev.getui.com/），体验个推后效分析功能和最新推出的消息链路查询功能吧！

个推消息中心从解决一个用户痛点需求为起点，经过不断地打磨，已经成为了一款热销的系统平台产品。尤其是在金融行业，个推消息中心帮助银行APP对海量、多渠道的推送消息进行数字化运营管理。前不久，个推消息中心还荣获了“2021中国金融数字科技创新大赛”综合智能平台类银奖。那么，个推消息中心为什么能快速获得客户和行业的认可？在产品设计和架构过程中又有哪些妙思？就让我们通过这份产品经理的独白来了解产品背后的故事。

消息统一管理和运营是未来的趋势

APP想要与用户产生互动就需要消息推送，这是刚需。然而，随着技术的发展，APP对于消息推送也提出了越来越高的要求。消息推送已经不仅仅是用户收到一条信息那么简单，在消息推送之前会有更多连接业务场景的前置需求，因此需要有一个运营和管理系统平台去实现消息的精细化推送。

我们早期合作的一家证券机构，他们的股票交易APP一直使用个推消息推送SDK，每天都要下发海量的用户交易信息、行情信息、服务信息等。然而，随着微信服务号、小程序风口的到来，市场上信息触达的渠道变得越来越多，单一的APP推送通道已经不能满足APP用户触达的需求。此外，随着APP与业务紧密度的加深，APP消息推送的下发条件越来越复杂，下发场景也越来越多样化。为了帮助这家证券机构更好地运营和管理需要下发给用户的消息，我们设想搭建一套消息下发系统平台，对消息进行统一接入、统一管理以及多策略消息智能下发。这就是个推消息中心诞生的初衷。

调研数十家客户，提升产品的应用性

个推消息中心之所以能快速部署，快速应用，且出错率低、兼容性强，是因为在产品架构之初，我们做了充分的调研，从提升应用性的角度出发，梳理出产品的核心需求点。

首先，我们基于对消息中心需求的理解，基于APP对多渠道接入和业务需求的发展方向考虑，制定了个推消息中心最初的核心需求点:

· 统一接口、统一调度、统一对接、统一下发

· 覆盖当时市面上最常用的触达渠道，包括但不限于APP推送、微信、短信、智能外呼等

· 支持自定义策略，配置业务策略实现智能下发

之后，我们细化整理出了一套比较详细的个推消息中心行业解决方案，然后拿着这份方案去找不同的APP客户开展调研。每完成一个APP客户的调研，我们会将该APP客户对个推消息中心的理解，以及提出的实际应用上的新需求进行梳理，对方案进行优化调整，结合其他行业客户的需求点，进行综合考量，并持续调研了十几家APP客户，才最终确认了个推消息中心的实际用户需求，形成了产品雏形。

从消息推送小闭环到智能触达大闭环

从确认需求到形成产品，最大的难题是在各类功能中做出抉择，既能满足用户需求又能体现自身产品的优势。最终经过反复推敲，我们确定了两个核心能力：

· 统一管理消息下发渠道系统

· 智能消息下发策略系统

个推消息中心将上述这两个能力融合在一起，帮助APP快速架构消息推送小闭环，智能升级消息运营大闭环。

小闭环是指消息推送对接、下发、回执的全过程。个推消息中心是以个推消息推送为基础搭建的上层系统，与个推消息推送算是“同胞兄弟”，能够自动对接个推消息推送的所有功能，这样就免去了中间的各种适配和对接流程，甚至包括推送回执、推送数据、后效分析报表等数据的交互都十分顺畅。此外，个推消息中心对下发通道做了全面提升，在保证下发效果的同时，对上游业务层提供统一的调用接口，同时打通下游各渠道的识别ID，协助客户建立统一的用户运营ID，最大限度方便APP做消息对接。

图：消息推送系统图

大闭环指的是与业务端相匹配的消息运营的全生命周期，帮助APP解决消息生成，消息发送，提升下发效果等问题。因此，个推消息中心在设计产品时，在“智能推送”这个功能上花了很多心思，涵盖行业各种经典推送场景，包括并发、补发、分发策略，以实现各种策略灵活可配置，让APP可以多维度地制定下发策略，一站式完成多渠道多用户群的消息下发，清晰呈现完整的业务流程，助力APP开展精细化用户运营。

图：消息运营全生命周期

满足每条消息背后独特的触发条件

智能推送规则引擎是个推消息中心最核心的功能，其包含用户分级规则，通道分级规则，业务场景规则等，最终它将跟APP的精细化运营深度结合。

个推消息中心的规则引擎不仅解决了智能推送和高并发兼容的问题，将智能推送策略对消息下发的影响降到了最低；最重要的是，个推消息中心的规则引擎里，更新上线的每一条策略都经过无数的实战检验，与业务场景匹配度极高。

智能推送的整体逻辑，主要是并发、补发、分发，但是设置并发、补发、分发的事件触发规则往往各不相同。因此，在设计规则引擎的时候，我们对个推消息推送历史样例做了深度分析，总结出公共范式，提取出独立的规则引擎模块，通过规则引擎计算消息应该走哪个渠道，用什么消息模板。

图：规则引擎示意图

在技术上，我们把高频事件触发的逻辑写在了业务代码中，这样就能有效提高业务耦合性。此外，我们还在规则引擎框架、通信层面、线程池、JVM（虚拟机）等方面进行了全面的优化，使规则引擎对业务性能的影响降到了最低，即使面对上亿的下发量需求，也能秒级下发。

规则引擎里的应用场景模板是需要不断迭代优化的，我们在规则引擎中引入了机器学习模型，会对每一次推送的数据进行归集分析、学习优化，不断沉淀和优化下发策略，不断优化各个应用场景模板，提升消息下发的效果。

图：场景模板

深耕金融行业赋能数字化升级

金融行业是个推消息中心率先沉浸的行业。金融行业正处于数字化升级的爆发期，用户体量大，消息推送场景多元化，下发量大，对消息运营整体系统建设的需求十分强烈。个推消息中心的出现不仅能解决金融机构对通道集成、统一推送的诉求，还能轻松对接智能运营中心，满足金融行业数字化升级中的精细化运营诉求。

金融类APP服务多元，为增强这类APP用户的粘性，个推消息中心能够提供一套用户触达的全流程闭环方案。把消息触发生成、消息组装、消息分发、消息触达、消息展示以及后效分析这些环节整合起来，不仅能更清晰地看到消息的整个生命周期，还能提高营销、运营活动的效果，让整个运营流程更加高效。

持续的精心规划、多方实践，为个推消息中心积累了丰富的成功案例和深厚的行业经验。未来，我们将朝着消息运营的整体解决方案持续前进，为各类APP提供更灵活、更高效的服务。APP可根据目前实际业务需求来选择不同等级的服务，从简单的建立推送通道，到无缝升级为消息中心，最终建立起完整的消息运营平台，全面助力APP精细化运营。

扫描二维码，立即咨询

现在官方的tabbar无法满足根据身份切换tabbar数量的需求，自定义tabbar需要写在一个界面用来避免tababr闪烁的问题。

我的实现思路是这样的：

首先home.vue里面写一个自定义的tabbar

把tabbar的界面分开单独写成组件，放到components里面

然后根据v-if去动态显示封装成组件的界面，这样就避免了tabbar的闪烁，也不需要很复杂的把逻辑写到一个界面

但是组件里面的页面跳转可能需要根据相对路径去跳转