CloudLink Kit_21.0.0.6_SDK包含私有api，不能上架App Store被拒原因如下：ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/tsdk_service.framework/tsdk_service: _rdft. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

有人反馈过好望APP一点都不要用吗，预览界面非常不实用。

前置条件iMaster NCE-Campus和短信服务器、短信平台能够实现三层路由互通。已在华为云创建短信应用并获取APP_Key，APP_Secret和华为云短信模板ID等信息。在华为云中申请短信模板的时候，注意变量是用来填写验证码的，建议采用验证码类，注意变量只能填一个，不支持多个。如下图所示，短信测试内容要按照如下格式["需要测试的内容"]添加，否则会测试失败。帐号在华为云短信应用中获取的App_KeyToken在华为云短信应用中获取的APP_SecrettemplateId在华为云中使用的短信模板ID短信签名在华为云短信应用中获取已添加的签名发送号码在华为云短信应用的签名管理中获取的通道号短信验证码也要按照如下配置：注意：如果APP的接入地址是如下的地址，则采用默认的华为云短信平台即可，如果不是的话，请联系小助手需要添加新的华为云短信平台：https://rtcsms.cn-north-1.myhuaweicloud.com:10743

# 开发者说 # 【开发者说】栏目是为HarmonyOS开发者提供的展示和分享平台，在这里，大家可以发表自己的技术洞察和见解，也可以展示自己的开发心得和成果。欢迎大家积极投稿，后台回复【投稿】，即可获得投稿渠道。期待你们的分享~本期我们给大家带来的是首都经济贸易大学的开发小队的分享，希望能给你的HarmonyOS开发之旅带来启发~ 团队介绍我们是来自首都经济贸易大学的开发小队，我们的项目“基于HarmonyOS开发的运动员智能训练系统” 在“华为中国大学生ICT大赛2021”创新赛全国总决赛荣获三等奖。今天就借这个机会和大家分享一下我们基于HarmonyOS的开发过程，希望能给大家也带来一些帮助和启发。首先介绍一下团队，我们团队共由2名本科生和1名研究生组成，负责整个项目的硬件开发、数据库搭建、软件开发等工作。01项目背景随着科技的快速发展和热爱运动人数的增多，市场上缺少一些针对半专业或专业化运动员的智能训练设备及管理系统。首先，对于像学校田径队中的这些半专业或专业化的运动员来说，经过高强度训练后，需要立刻监测心率，以得出“训练强度是否达到？”、“跑动能力和耐力如何？”等结论。但是，目前现状是教练用秒表计时，然后运动员自己掐脉搏测心率，导致测量不准等问题。 其次，训练数据无法实时传送给教练，不利于教练监测训练状况以及更好地为运动员制定下一步训练计划。 最后，当运动员或教练员信息、训练计划等出现错误或者其他意外情况时，管理员如何进行修改等。 对于以上问题和背景，我们基于HarmonyOS设计了适合于半专业化或专业化运动员的智能运动监测系统，不仅解决了运动后心率测量不准的问题；还可以让运动员随时查看以往数据，更好地了解自己的成绩；也让教练可以实时查看队员的训练数据和训练计划，帮助教练制定适合队员的训练方案；还实现了对训练团队、运动员以及教练的数据修改和维护功能。 02效果展示我们的项目包含硬件、软件和数据管理系统三部分（如下表所示）。基于HarmonyOS的运动员智能训练系统的使用方法： 首先依托训练监测手环收集运动员的心率数据并计算出距离。 然后训练监测手环会将数据实时发送到华为云的云设备接入平台中。云设备接入平台收到数据后，通过数据接入服务来收集和处理数据，并存储至华为云服务器的数据库中。 最后智能运动APP从华为云服务器的数据库中获取数据，展示在手机界面中。让运动员更好地了解自己的成绩；也让教练可以随时查看自己队员的成绩和发布训练计划，帮助教练为队员制定更好的训练方案。效果如图1所示：图 1  智能运动APP效果图（运动员）03开发分享我们开发的智能训练系统包括：训练监测手环、智能运动APP HarmonyOS版、数据管理系统三个模块，项目整体架构如图2所示：图 2 项目架构图训练监测手环：有计算距离、计时和检测心率三个功能。手环使用STM32 开发板进行开发，搭载STM32F103C8T6微控制器用于存储、调度、执行程序；使用三轴加速度传感器ADXL345[1]，用来获取三个方向上的加速度，用于计算距离与步数；使用心率血氧传感器MAX30102，用于在运动员结束动后检测心率[2]；使用Wi-Fi模块ESP8266，编写有在华为云设备接入平台中申请的设备编号、IoTDA域名以及MQTT协议端口号等能够保证数据进行传输的信息，使数据传输到华为云设备接入平台，并存储在产品属性中。 智能运动APP HarmonyOS版：分为教练员端和运动员端，运动员可以查看自己训练数据、查看教练安排的训练计划等；教练员可以查看队伍训练情况、编辑训练计划等。智能运动APP从华为云服务器中的数据库中获取数据，展示在手机界面中。 智能运动APP 使用了HUAWEI DevEco Studio 开发的，选择了JS语言进行编写，通过fetch方法请求华为云服务器中使用Spring Boot编写的数据接口，实现APP与华为云服务器数据库之间的数据传输；然后使用onchange事件，将界面展示数据与数据库中的数据进行双向绑定；最后使用storage方法，缓存用户信息等数据。 数据管理系统：主要面向对象为后台管理员，当出现因手环出现故障不能传输数据、因网络信号导致的上传数据错误等问题，需要管理员进行维护。 前端界面使用Vue的Element UI进行搭建，数据通过Ajax请求华为云服务器中使用Spring Boot编写的数据接口，实现平台与华为云服务器数据库之间的数据传输。 04心得感悟在学习HarmonyOS的过程中，我们也遇到很多问题。主要通过HarmonyOS官网文档学习、在华为开发者论坛提问、以及参考三方网站别人分享的帖子来解决。通过这次项目我们发现学习过程中最重要的一点就是要动手尝试，尝试的过程中会发现很多问题，然后有针对性地解决，这样就可以大大提高项目推进的效率。 第二点就是多多研究他人分享的优质代码，参考别人的代码来优化自己的代码，让自己的代码更实用。并且在研究优质代码时，最好留下自己的注释，便于后续回顾。 第三点就是要趁热打铁，即时做总结，这样不仅可以加深对所学知识或遇到的问题的理解，也为日后进一步开展项目打好基础。   未来展望  我们知道，体育运动可以陶冶情操，保持健康的心态，使个人在社会中实现健康和谐的发展。随着国家对体育的愈发重视，中学生以及大学生的训练也会逐渐趋于专业化，未来我们会跟着HarmonyOS技术的发展一起成长，不断完善我们的项目，让我们的运动员能够高效训练、让这个项目发挥出它的社会价值！参考文献：[1] 李易陆,陈洪波,蒋晓旭,李腾生,冯思浩. 基于三轴加速度传感器的人机交互智能手环[J]. 桂林电子科技大学学报,2015,35(05):412-415.[2] 段志杰. 基于Android传感器模块手机计步器的设计与实现[D].重庆邮电大学,2017.转载于微信HarmonyOS开发者微信公众号

作为线上零售，或者说任何行业达成交易不可或缺的最后一环，支付是海豚君研究和覆盖标的中长期缺失的一环。因此，为了补上这个空缺，也为跨市场比较国内可能上市的支付公司，海豚君在本文将以美国的支付行业为研究对象，为大家解读支付行业基本的商业逻辑，和盈利途径。并分析对比美国支付市场内的竞争格局，以及在不同支付场景下各公司的优劣势。从而最终尝试判断，在市场空间巨大的支付行业中，哪些公司最有可能脱颖而出成为赢家。同时也能通过跨市场比较，帮助理解国内支付行业的情况长桥海豚投研专注为用户跨市场解读全球核心资产，把握企业深度价值与投资机会。以下为正文一、美国数字支付方兴未艾，银行系“old money”仍是主导美国虽是科技领域的执牛耳者，全球市值最大的数家互联网公司基本都诞生自美国；然而如同美国在电商领域上落后于我国一般，美国在数字支付等fintech领域的发展相对中国也仍处于相对“原始”的程度。在国内，支付宝和等数字支付已基本可运用于任何支付场景，是中国居民支付首选；而在美国，银行卡的“老牌”支付手段仍是支付渠道的绝对主流。根据美联储数据，在2018年美国整体非现金支付笔数达1740亿比，总支付金额为94万亿美元。（下图中2019－2020的数据为推算值）。其中，按支付笔数来看，银行卡支付占比达75％以上，其次是 ACH（Automated Clearing House类似银行转账）和支票，通过移动钱包支付的占比仅为2．4％。而按支付金额比重来看，ACH和支票则合计占比93％，银行卡占约7％，移动钱包则可忽略不计。从上述数据我们可以构建出以下情景，美国居民在日常小额支付中，银行卡是绝对首选；而在进行大额支付时则以银行转账和支票为主。P2P和移动钱包仅在少数小额支付情境下被使用。那么在不同情景下，美国数字支付的使用率如何？在利于实体卡支付的线下场景中，美国电子钱包占比仅为11％，相比之下国内电子钱包占比已超过半数。即便在利于数字支付的线上场景，在美国银行卡支付仍是主流，信用卡＆借记卡合计占比51％，电子钱包支付占比仅30％。因此，无论线下还是线上，使用银行卡支付都是美国居民首选的支付途径，电子钱包的普及率和用户使用习惯远未成熟；相比之下，国内电子钱包不仅在线上场景占绝对主流，在线下场景中也已占比过半。与国内相比，美国数字支付产业仍处于方兴未艾的阶段，仍有很大的发展空间。那么细究中国的数字支付行业后来居上，发展程度远远领先美国背后的原因是什么？海豚君认为主要在两点：       1）在数字支付兴起前，美国的银行卡渗透率远超中国，线下银行卡支付已相当成熟。因此， 中国由现金支付跨越式迈向数字支付时，居民支付体验的改善是明显的。但数字支付相对银行卡支付的改善相对有限，因此美国居民广泛由银行卡转向数字支付的动力不足。2）电商特别是移动电商的发展程度对促进有重要推进作用，支付宝和微信支付成功的原因之一是两方旗下分别有京东、淘宝天猫等稳定的线上支付场景，进而逐渐渗透至线下场景。而美国线上销售的占比本就较低，移动电商渗透率更是仅有个位数，多数线上消费通过PC端，因此数字钱包的使用场景并不高。电商市占率40％以上的亚马逊在美国也并不支持PayPal等第三方公司，进一步减少了数字钱包的使用频率。因此，在电子钱包在线上支付都不能占据主导，就更难向线下渗透。虽然对于美国民众而言，银行卡仍是支付时的绝对主流，电子钱包占比较低；但这不意味着三方支付公司在美国支付流程中便无用武之地。除了银行和卡组织（Vise／银联等）外，三方支付机构（包括收单机构、支付服务提供商等）在支付全流程也各自扮演者不同角色。下文中，我们以三方支付机构的角度（Square、PayPal、支付宝），从基于银行卡的四分支付流程，和基于电子钱包的三方支付两种情景为例，简述下支付的流程，以及支付机构的商业模式。首先，在基于银行卡的四方C2B支付流程中，三方支付机构扮演的角色主要是收单方，即汇集终端消费者的支付请求，并通过卡组织／清算机构，将支付需求传送给银行后台完成支付的角色。一般情况下，支付所产生的费用都由商家承担。举例来说，若美国消费者通过信用卡支付＄100，收单方会整体向商家收取～2．5％的商户手续费（Merchant Discount Rate MDR），同时收单机构会分别向清算机构和银行支付～0．25％和～1．5％左右的分佣，收单方收取的净费用率在～1％左右。对比中国来看，由于国内监管更多将支付视作一种基础服务而非商业盈利行为，因此国内总的支付费率一般在～0．68％，剔除银行和清算机构的分佣后，收单方收取的净费用率约在～0．2％。横向对比来看，美国支付机构的变现率远高于中国，支付公司的盈利潜力更高，不过从收益分配的角度，无论在中美银行都占据了总支付手续费中的5到6成，三方支付则能分得3到4成。从商业逻辑角度，目前支付流程仍是基于银行卡or账户之上构建，因此银行就能在从中攫取最大部分的收益。而这也意味着，若是三方支付公司能绕过银行清算，其盈利能力将有巨大的提升。在上述支付流程外，还有三方支付机构获利更丰富的自清算模式。在这种模式下，资金直接由消费者的数字钱包账户经三方支付机构直接转移至商家的数字钱包账户，由于不再涉及消费者和商家的银行账户，以及银行间清算机构，因此数字钱包支付机构能够独占～2．6％－2．7％的支付费用，收益显著高于四方清算模式。不过自清算模式成立的前提是消费者和商家都使用同一品牌下的数字钱包。因此，只有当三方支付机构同时拥有大量C端和B端用户时才可能通过自清算模式攫取更大的收益，目前美国尚无三方支付机构能满足此要求。总的来说，在美国支付生态中，银行系统还是占据着主导地位，无论是数字支付的渗透率还是，三方支付公司的议价能力都不高。但美国支付行业接近百万亿的市场规模，以及接近3％的支付费率，表明美国的支付行业市场规模至少在数千亿美金（不考虑银行转账和支票部分），因此当前数字支付较低的渗透率和市场集中度，也意味着未来赢家能获得巨大的增长前景。二、入场玩家众多，Square特有线下2B＋2C业务双引擎驱动美国数字支付行业虽然并不成熟，但其巨大的潜在规模，以及较高的支付费率＆利润空间，吸引了众多背景优势各异的支付公司相互角力。根据背景的不同，支付行业玩家主要可分为四类：1）原生支付公司：以支付业务为主业的公司，例如PayPal，Square，Stripe等，此类公司的优势在于支付业务上的know－how，以及较多的商户端资源；2）2C互联网公司：通过2C业务切入支付领域公司，例如Apple Pay，Google Pay,Amazon Pay等，此类公司的优势在于大量的C端用户资源，以及集团公司巨大的资金＆技术优势；3）银行／卡组组织系公司：银行为防御三方支付公司竞争，联合或单独推出的支付品牌，例如Zelle（P2P支付），和Citi Moblie／Chase Mobile等银行App；此类公司的优势在已有大量适配商户和持卡人，但缺点在于技术和线上运营能力；4）消费借贷公司（BuyNow PayLater）：以线上购物分期付款、消费贷为主要切入口的支付公司，例如Afterpay，Affirm，Klarna等，因此缺点是适用场景较窄；在上述玩家中，海豚君将以原生支付公司中的Square（当前公司名已变更为Block）为重点研究对象，并通过与其他玩家的对比探讨Square在支付行业中的竞争格局与优势。首先，海豚君先简要介绍下Square的业务构成，以便更好的理解下文。简要来说，Square的业务线以两大板块构成：①是以线下商户收款POS机软硬件服务为核心的2B业务线，主要为美国中小商家提供线下收款服务，此外也衍生出客户管理、门店管理、线上预约等SaaS服务，以及商家短期经营贷等金融服务业；②是以Cash App一款个人电子钱包为核心的2C业务线，主打P2P转账功能，并衍生出股票／加密货币投资服务，线下付款等服务。1、Square 2B业务生态在众多第三方支付企业中，Square是少数以面向线下商家支付起家的公司。Square在2009年创立时，由于美国存在大量（超2000万）中小商家，因难以获批使用银行POS，或无力承担高额的使用，从而无法接受主流的刷卡支付。针对这些中小商家痛点和收款需求， Square便以低申请门槛、价格低廉、且易于使用的刷卡硬件切入了线下B端支付市场。据外行统计，95％的商家都可通过使用Square服务的申请，相比之下传统POS机服务方的通过率仅30－40％。此外Square商家的审批是由系统自动操做，仅需1－2天，而传统服务发则需要数周的审批和调试。在硬件段，以最初简易的耳机插孔读卡器为例，商家仅需将读卡器连接上手机或电脑，在配合设备上安装的Square Point of sales 软件，便能使商家轻松接受刷卡支付。随后Square也接连推出了功能更为齐全的，价格也更贵的刷卡终端，以提供更好的支付体验，也为公司创造更多的利润。由于在全美3000多万商家中仅有30％左右接受刷信用卡付款，因此通过填补小微商家支付收单服务市场的广大空白，Square成功在线下C2B支付积累了一定是市场份额和商户资源，据公司披露，到2017年使用Square的线下商户数量已超过200万。2． Cash App C端生态圈在围绕线下POS支付的2B业务体系外，自2013年Cash App上线起，Square围绕这款应用也逐步搭建起了起2C支付生态体系。在Cash App诞生之处，其功能主要为个人AA收款或P2P转账，功能相对单一。但随后，公司接连推出了① Cash Card（与银行联合发行的借记卡）添加了C2B支付的功能；② App内直接买卖股票和加密货币功能；③小额现金短贷功能，额度在20－200美元左右，无需审查。而通过2021年收购“BuyNow PayLater”服务商Afterpay，Cash App进一步整合了线上支付和分期消费功能。至此，围绕Cash App的C端支付生态也初步搭建完成。而随着Cash App功能的逐步丰富，用户使用App的频率和粘性也随之提高，公司的营收来源也不断拓展，Cash App用户人均贡献营收从18年的不到＄30增长到21年的＄280美元。三、与同行比较，Square的优缺点在哪通过上文的论述，可以看出美国的数字支付发展尚不成熟，且背景不一，侧重不同的三方支付公司数量众多，那么哪些公司更有可能从当前的“混战阶段”脱颖而出，支付公司的核心竞争点又在哪些方面？海豚君认为核心竞争点在于：支付场景，用户规模和习惯，产品线迭代速度，以及支付费率。首先，从用户感知最为直观的支付手续费率，横向对比来看各支付公司收取的费率基本相同，只有PayPal收取的费率稍稍略高。具体费率线上支付普遍在总支付金额的2．9％左右，线下支付则在2．7％左右。可见在支付手续费上打价格战并非各公司的主要竞争手段。而从用户规模的角度，可以看到目前两大P2P支付软件—Venmo和Cash App的用户规模领先，到2021年中皆为7000万左右，银行系App（以Chase Mobile 和 Zelle为例）的用户数和Apple Pay等2C互联网公司旗下支付品牌的用户数处于第二梯队，分别约有4000万用户。而“先买后付”公司的用户规模当前最少，头部公司大体在1000－2000万级别。因此，在用户广度上和使用习惯上，PayPal和Square这两家头部公司处于领先地位。就支付场景，大体上可分成3类，①线上支付：例如网上购物、订房、买票等；②线下支付：线下门店餐厅购物付款；③P2P支付：即个人之间的直接转账，如发红包、聚餐AA收费等。针对不同的场景，支付公司也都分别有推出对应的产品或服务（详见下图）。经过梳理后概括来说，PayPal的优势领域在于线上支付；Square强于线下2B业务；Apple／Google Pay等强在线下2C业务；银行系在传统支付领域稳稳占据领导地位，但在数字钱包领域显著落后。至于P2P领域则是PayPal和Square二分天下。      1）Square“独具慧眼”线下2B业务领先由于Square是少数专注于线下的数字支付公司，因此在该领域有明显的规模优势。据Nilson估计，相较传统线下收单公司，Square的市占率虽然仍相当低， 在2018年占约1．5％的份额，但也已是全美第八大服务商。虽然其他支付数字公司也先发布了自己的线下支付品牌和硬件，如PayPal旗下的Zettle（原品牌名为PayPal Here），但并未能动摇Square在线下支付领域的领先地位，Square市占率遥遥领先Zettle，Strip，Shopify等。2）线上支付，PayPal的基本盘      与Square侧重线下不同，PayPal的优势更多在线上支付。创立初期被头部电商平台ebay收购，给予了PayPal稳定的线上支付场景。但不局限于ebay，PayPal将其线上支付业务拓展至了全球。截至2021年，PayPal在全球有超过3．9亿C端用户和3400商家用户。据调研，全美头部1000家线上商户中约75％接受PayPal支付。而据海豚君调查，在头部平台中，全美电商市占率高达40％的最大龙头Amazon或出于竞争考虑，并不接受PayPal付款，但其余Walmart、ebay、Mercado Libre、Expedia，Airbnb等都接受PayPal。因此，在线上2B支付领域，PayPal毋庸置疑拥有最广的使用场景和用户规模。相比之下，Square的线上支付场景就相对匮乏，普遍需通过其Cash Card联名借记卡，经由卡组织渠道完成线上支付。不过，在收购afterpay后，其适用的线上门店也被整合进Square旗下Cash App内，部分弥补了线上支付场景缺乏的问题。目前，afterpay的适用场景主要为商品品牌的独立站，并不广泛。      3）P2P个人钱包，激烈竞争的最前线      在上述线上／线下C2B支付场景之外，P2P支付场景可谓是美国当前竞争最为激烈，增长潜力也最为可观的支付场景。Cash App，Venmo和银行系的Zelle都在该领域内的有力竞争者，且用户规模都在数千万以上。三个P2P钱包各有优势，其中Cash App在于功能更广，除了支付外，也还可用于投资；Venmo的优势则在于内嵌了社交功能，可与朋友直接沟通，此外作为PayPal旗下产品，Venmo也能在更多场景下直接用于线上支付；Zelle的优势则在于依托银行，因此对资金安全更为关注的用户更有吸引力，也更适用于较大额的P2P转账。不过从最近的下载量数据和日活用户数来看，诞生较晚的Cash App反而后方先至，目前的增长势头有甩开Venmo的趋势。海豚君认为其背后原因主要有3点：（1）是Cash App的目标用户群体更侧重于没有或缺乏银行服务的年轻人或低收入群体。对于该类用户群体，Cash App能起到主要支付、理财工具的地位，而Venmo和Zelle对其用户群体而言则更多是传统银行服务外的额外支付工具。（下图中Cash App的搜索热度与美国居民缺乏银行服务人口的密度基本对应）（2）Cash App更好的利用了Facebook，Tiktok，Twitter等社交平台进行宣传，因此在年轻人群体中传播更为广泛。（3）Cash App产品功能迭代速度更快，能更迅速的把握目标群体的需求，并提供更丰富的功能，从而使得用户的依赖程度更高。虽然Venmo也陆续推出了联名借记卡、虚拟货币买卖服务，但节奏始终落后于Cash App。四、结合国内先进经验，哪些支付玩家能够脱颖而出？参考国内数字支付领域支付宝和微信支付的胜出，海豚君认为数字支付工具能脱颖而出，甚至击败美国占据绝对主流的银行卡支付的路径主要有两条。①从控制支付场景出发，类似支付宝路径，即借助拥有大量流量和C端用户的生态内线上平台，确立起支付场景的基本盘，将电商平台内用户逐步向支付工具导流，再尝试向往外破圈，占据体系外的支付场景。而当体系外支付用户显著增长后，反向向体系内电商平台导流形成正向循环，并借助体系内支付渠道的排他性，进一步稳固支付场景的基本盘和消费者习惯。从这个角度上，PayPal曾通过这个逻辑发展成欧美最大的线上支付工具。但PayPal的核心缺陷是，在被ebay出售后PayPal并没有自身生态内的电商平台作为基本盘。而Amazon不接受PayPal付款，ebay将线上支付的主要服务提供商更改为Adyen，都能体现出PayPal在这条逻辑上的缺陷。由于缺乏体系内平台，PayPal还是需要依赖于第三方，因此谈判议价能力不会高，更别谈取代银行卡支付的地位。而对于电商平台而言，支付也是完成其交易闭环的重要组成部分。因此，当线上平台达到一定规模，有推出自有支付工具的动机，如Amazon Pay，京东白条，美团支付等。而在此情况下，PayPal此类第三方支付工具的地位势必受到影响。而对于Square，由于其在线下拥有体系内的商户支付资源，其对支付场景控制的力度相对更强。例如，对使用Square服务的商家，公司能够通过费率折扣等推广自有支付工具（Cash App），甚至有望取代银行卡成为主要支付渠道。但前提条件是Square必须覆盖足够多的B端和C端用户，才能保证自有支付工具的适用性。目前来看，还有较大距离。②第二条路线即通过C端用户规模上的巨大优势，以及对用户使用习惯和时常的控制，先培养出用户使用支付工具的习惯，再通过规模优势倒逼商家接受此类支付工具。微信支付即是通过这一逻辑成功。从这个角度出发，Cash App和Venmo这两大P2P支付工具都有可能通过这一逻辑脱颖而出。同时，Apple Pay和Google Pay等也可能凭借其巨大的手机等终端持有量脱颖而出。但截至目前，Apple Pay和Google Pay主要还是通过模拟银行卡完成支付，尚未建立起独立于银行卡的数字钱包。因此，Cash App和Venmo仍是最有希望获胜的选手。       小结：本篇我们主要梳理了支付行业的商业模式以及盈利途径，并以Square、PayPal为例，探讨了不同背景的支付公司当前的竞争格局；在不同支付场景下，各支付玩家的优劣势；以及当前来看哪些公司最有可能像支付宝，微信支付一样脱颖而出。下篇，我们将选取一家标的公司，更细致的分析起收入、成本来源与构成。以及在支付之外，商家SaaS服务、2B／2C金融服务能为支付公司带来哪些额外的增长空间。最后，我们会判断支付公司的TAM市场规模及成长空间，并基于当前市场环境给出我们的估值判断和建议。       原文标题 : 支付的“万亿选择”：Square 还是 PayPal？

文/陈根受益全球智能化浪潮,、、云服务赛道上的独角兽们,在聚光灯下吸睛无数,尤其登陆资本市场初期受到热捧,但不久后便陷入困境。比如,身处热门的物联网赛道上,做着生意的。虽然亏损日益扩大,但依旧以21美元的发行价在2021年进行IPO,市值高达117．6亿美元,首日更是大涨19%,市值高达140亿美元。遗憾的是,涂鸦智能没能逃过“上市即高峰”的命运,首日大涨后就长时间震荡走低。6月15日,涂鸦智能公布2022财年一季度财报,营收、净亏损、毛利率等多项数据表现均不理想。直到今天,涂鸦智能股价已经经历三连跌,市值较高位跌去近百亿美元。而日前,涂鸦智能还在通过港交所上市聆讯,2022年6月22日至6月27日开启招股,预计7月5日在港交所上市。回归香港上市的涂鸦智能还能如何挽救自己的黯淡的现状?又该拿什么来许诺资本市场一个美好的前景?风光已是往事涂鸦智能也曾风光过。成立于2014年6月的涂鸦智能,是一家“赋能产品智能化”的技术使能公司。尤其是在智能家居方面,比如,一个灯泡最简单的智能化实现就是通过一个app控制开关,而这个智能化的实现,则涉及到灯泡能联网、灯泡管理,同时有个App进行控制。不仅如此,涂鸦智能还可以为人们提供包含硬件联网模块、物联网()云服务和App全链路的智能化能力。作为技术使能的平台型公司,涂鸦智能聚合了OEM制造商、品牌商、集成商、行业方案商和运营商,以及最终用户,为不同类型的客户提供产品服务(PaaS),并将不同客户的产品进行整合,面向不同场景提供标准的方案(SaaS),打造一个闭环的生态系统。涂鸦智能则基于这个生态系统实现获利。以“涂鸦智能锁解决方案”为例,涂鸦智能提供通信模组、云服务、App等一站式智能化能力,采用该方案的智能锁还可以无缝与涂鸦智慧安防、智慧公寓、智慧酒店、智慧商业照明等商业SaaS场景互联,借助帮忙客户拉动智能锁产品的销售。看上去,做着智能家居生意的涂鸦智能的却有区别于小米、海尔、华为等厂商的中立性,打着物联网的旗号,也让它有了一些独特的行业参考价值。于是,在物联网风生水起的背景下,涂鸦智能也一路向上,2021年3月,涂鸦智能在美国纽交所上市,募资9．15亿美元。遗憾的是,涂鸦智能虽然在聚光灯下吸睛无数,尤其登陆资本市场初期更是受到热捧,但依然没逃过“上市即巅峰”的窘境,涂鸦智能在首日大涨后就长时间震荡走低。北京时间6月15日美股盘后,涂鸦智能公布了2022财年一季度财报。数据显示,涂鸦智能该季度营收同比出现下滑,净亏损则进一步放大,且毛利率、运营利润率等多项数据表现都没有太多亮点。首先,涂鸦智能的亏损仍在扩大。2020年,涂鸦智能亏损6690万美元,2021年亏损增加了1．085亿美元,净亏损达到1．754亿美元。2022年Q1净亏损为5500万美元,而2021年同期为4050万美元;非公认会计原则净亏损为3730万美元,而2021年同期为2380万美元。其次,涂鸦智能的营收还显示出了增长的乏力,尤其是物联网板块的营收表现低迷。涂鸦智能一季度营收为5532．4万美元,同比下跌2．7%,这是其上市后首次出现营收负增长。与此同时,其一季度营收环比跌幅也从四季度的12%放大至26%。对比之下,去年同期涂鸦智能的营收达到5686万美元,同比增幅高达200%。其中,IoT PaaS是涂鸦智能营收核心来源,2021年占总营收比重逾九成。但在2022年,来自IoT PaaS收入却低至4180万美元,同比下降16%。SaaS和其他业务收入为580万美元,同比增长146．7%;智能设备分销业务收入则录得780万美元,同比增长63．9%。虽然SaaS、智能设备分销两项业务的营收仍保持较高增速,但其体量实在太小,对涂鸦智能的贡献相当有限。最后,虽然涂鸦智能的用户规模得以增长,但销售效率则不高低。截至2022年第一季度,IoT PaaS客户为2600家,同比增长21%,IoT PaaS优质客户303个,他们为IoT PaaS合计贡献了约85．6%的收入。然而,与客户稳步增长不同的是营收低迷,这意味着无效用户居多,未能创造价值。截至22日,涂鸦智能股价为2．46美元,市值为13．77亿美元,也就是说,涂鸦智能上市一年多时间,股价已经蒸发90%,市值蒸发超过120亿美元。缺乏核心技术的窘境显然,涂鸦智能的物联网之路并不好过。要知道,物联网平台市场也是个巨头林立的市场,在商业落地场景中,涂鸦智能定位IoT云平台厂商,要想在巨头手中抢夺市场异常艰难,因为这需要的是核心技术。不可否认,尽管涂鸦智能的IoT PaaS整合了以云为基础设施的连接、基础IOT服务、边缘拓展、APP开发和设备最优化解决方案等功能,能够使得一个硬件变得智能,按照部署的数量来收费。其中,涂鸦给设备商提供内置芯片的物联网模块,然后帮助设备厂商把设备连接到IOT平台。但涂鸦智能的基础设施却依然建立在其他的巨头上——涂鸦智能目前的IT基础设施来自于微软Azure、亚马逊AWS和腾讯云,主要是基于微软,腾讯云则主要是在国内。要知道,目前物联网平台当中,几乎所有云巨头均有物联网平台服务。根据IoT Analytics的报告显示,微软Azure、亚马逊AWS、谷歌云三大云巨头共同拥有全球物联网云市场的80%市场份额。根据对Microsoft Azure对167个公开可用的物联网案例研究分析,IoT Hub是使用最广泛的Azure IoT服务,其次是Azure IoT Edge。微软首席执行官纳德拉曾指出,“从智能工厂到再到智能城市,我们正在帮助组织使用Azure物联网、数字双胞胎和网格的组合来帮助将人、地点和事物数字化,以便可视化、模拟和分析任何业务流程。”亚马逊AWS是全球云服务领导厂商,IoT Core是最受欢迎的AWS物联网服务。在2021年12月re:Invent全球大会上还推出了两项新的物联网服务:AWS IoT TwinMaker和AWS IoT FleetWise。以Amazon IoT TwinMake物联网服务,能让开发人员轻松、快捷地创建现实世界的数字孪生,如楼宇、工厂、工业设备和生产线。还有Amazon IoT FleetWise物联网,让汽车制造商更轻松、经济地收集、管理车辆数据,同时几乎实时上传到云端。以至于涂鸦智能都需要借助亚马逊AWS、微软Azure构建IoT平台。也就是说,涂鸦智能IoT云平台是部署在云巨头的云计算基础设施之上的,比如,涂鸦智能采用亚马逊云科技云服务,Amazon Aurora Serverless v2可在几分之一秒内自动将数据库工作负载扩展到数十万个事务,支持最严苛的应用程序。不仅如此,在物联网的赛道上,涂鸦智能还需要面对国内的一众科技巨头。尽管更早以前,在物联网赛道还不那么拥挤的时候,涂鸦智能确实是一块资本所喜欢的“香饽饽”。但现在,随着国内互联网巨头大力发展云服务,并逐渐从IaaS基础云向PaaS过渡,涂鸦智能的优势也日渐失去。其中,阿里的IoT云服务业务布局最早,当前竞争力也最为强大。早在2020年,阿里就以天猫精灵为核心,对消费物联网事业群进行全新升级,将人工智能实验室天猫精灵业务升级为独立事业部,由阿里云IoT业务负责人库伟挂帅。与此同时,阿里云智能也开始转舵,发展B端业务,首推的就是产品解决方案和大网站服务,瞄准PaaS赛道。和涂鸦智能相比,阿里云IoT的优势简直不要太明显:天猫精灵的海量用户数据以及阿里云强大基础算力,这都是涂鸦智能这种几乎不涉及硬件业务第三方服务商无法比拟的优势。这个时候,主营PaaS和SaaS业务,不具独自开发基础云的能力,所以只能在底层技术依赖IaaS公有云供应商的涂鸦智能,可以说从根源上就受制于人。涂鸦智能时日无多核心技术都尚且难以具备,在这样的情况下,再去做智能家居生意,涂鸦智能只能说是心有余而力不足。在物联网的发展下,当前,智能家居正处于一个高速发展的阶段,以至于有网友用“光速”来形容智能家居市场的爆发力和技术的日新月异。2016年,国内智能家居市场规模仅为620亿元,2020年整体市场规模已提升至1705亿元,CAGR接近30%,行业规模近年均保持双位数高增势头。根据IDC报告显示,未来五年中国智能家居设备市场出货量将以 21．4% 的复合增长率持续增长,2025 年市场出货量将接近 5．4 亿台。天眼查显示,2021年,国内存在近16万家智能家居相关企业。除了批发、零售型企业,从事智能家居方面的信息传输、软件和信息技术服务企业,超过2．5万,为智能家居提供科学研究、技术服务的企业,也有近2万家。可以说,智能家居的研发、设计、生产、销售等上下游行业,已经吸引了众多玩家入场,从而支撑了一条完整的产业链,让智能家居产业得以大规模、快速发展。而当前的智能家居行业代表厂商则是包括海尔智家、美的两大传统白电厂商,以及小米、TCL等消费电子企业。而不论是海尔智家、美的,还是小米、TCL,哪一家对涂鸦智能的威胁都不算小,因为它们本就同属于智能家居赛道。比如,目前,海尔智家重点打造的三翼鸟,则走全屋智能定制路线。从去年的年报来看,为了构建三翼鸟的“1+N”服务体系,海尔智家耗费了大量资金。其中,上一财年的销售费用率同比增长8．66%至365．5亿元,很大一部分就流向了三翼鸟业务。美的美居和小米米家则已经打通软硬件生态,除了提供开发平台之外,还有一条包含产品研发销售、售后服务和场景搭建等环节在内的生态闭环。而涂鸦智能目前还定位在辅助性、工具平台,缺乏对产业链上下游的掌控能力。可以说,和海尔、美的、小米相比,涂鸦智能既没有技术优势也没有资金优势,前路的黯淡几乎是可见的艰难。当然,涂鸦智能也有其优势。虽然小米、美的也有引进第三方客户提供外部设备服务的计划,但其IoT智能生态相较于涂鸦智能还是太过封闭。这也是智能家居当前的硬伤,一个家庭中,用户选择的往往并不是同一个品牌的智能家电产品,如何让不同品牌之间的家电产品之间可以实现较为畅通、快速的互联互通,依然是今天智能家居没能解决的问题。品牌壁垒的存在,让智能家居没办法融进同一个操控逻辑中,消费者在选购时,又往往会选该品类产品中性能表现比较好的品牌,而这样就很难真正组合成完整的智能家居产品。而作为第三方平台的涂鸦智能,开放性是其最大优点,这也就是涂鸦智能在智能家居行业做出的最大贡献——连接标准的统一。但除此之外,更多的也无从谈起。但更重要的是,物联不代表智能,今天的人工智能虽然已经进入了技术产品化、商业化的阶段,但由于部分人工智能企业及媒体传播的夸大,导致了人工智能仍然青涩的能力在某些领域存在被夸大的情况。市场对人工智能寄予过高的期望,而实际的产品体验却往往欠佳。人们对人工智能能力、易用性、可靠性、体验等方面的要求都给当前的人工智能技术带来了更多挑战。可以说,当前的人工智能高度依赖数据,但数据积累、共享和应用的生态仍然比较初级,这直接阻碍着人工智能部分应用的实现。人工智能的“不够智能”成为了智能家居的破绽,也让人们对智能家居的期望落了空。换言之,物联网的核心其实并不是硬件,而是基于人工智能的智能控制系统。因为基于这个系统,包括亚马逊、谷歌、苹果等,只要开放端口就可以将相关的智能硬件接入进来。那么面对这些科技具有,这些真正掌握着人工智能控制系统核心技术的这些巨头们,涂鸦智能还剩下什么呢?可能最形象的就是小米的米U系统,不论怎么样包装,最终都只是依赖于谷歌的操作系统上。那么涂鸦智能显然也是如此,最终只是一个换了一个表面交互设计的其他平台的操作系统。如今,股价骨折再骨折的智能家居通过港交所上市聆讯,但几乎可以预见的是,涂鸦智能的智能家居之路仍将持续艰难,毕竟缺乏核心的技术竞争力,智能家居也难以智能,资本市场留给涂鸦智能的时间已经时日无多。而匆忙回到香港上市的涂鸦智能,背后真实的目的则是公司大幅亏损下难以为继的经营困境。因此,希望借助于香港的二次上市能够尽快的在圈一笔钱,好让公司能够维持下去。但是如今香港的资本市场会相信涂鸦智能的这个智能家居故事吗?很显然,小米的物联网故事在香港的资本市场已经失去了故事的真实性,而没有任何核心要素支撑的涂鸦智能的物联网故事,可能在二次上市之后所带给投资者的不是故事,而是一场股价的事故。       原文标题 : 陈根：持续亏损的涂鸦智能，讲不好智能家居的故事

直播链接：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=163377观后感一、ADC服务描述ADC（Application Development Center）是一个低代码、多体验的开发平台，提供面向业务开发者的全场景开发平台，以及完整的资产生命周期工具链，解决传统开发门槛高、周期长的问题，形成以业务资产为核心的高效开发和复用的新开发模式。二、产生背景低代码开发平台：由简单易用的可视化设计器和部署灵活的服务器构成，能帮助开发者快速构建美观易用、架构专业、安全可控的多终端应用，并随需而变。多体验开发平台：提供跨平台 APP，支持与多开放平台的深度集成，帮助开发者快速构建跨平台应用，实现一站式完成系统开发工作。三、服务价值（1）面向运营商，ADC作为一个低代码、多体验的全场景开发平台，集成数据、AI、API Fabric等服务编排能力，面向运营商多类业务软件开发诉求，提供一体化编排能力，以快速实现新特性开发与上市。1、支持无开发技术背景的运维人员，快速完成业务应用的配置和上线为目标。2、提供使能系统，助力OSS数字化转型。3、帮助运营商缩短TTM，加速新业务创新。（2）面向开发者，低门槛易上手。1、提供图形化开发Studio，以拖拽和类自然语言的方式，快速构造应用服务。2、开放流程、界面、数据、AI等编排能力，所见即所得。（3）开发效率提升1、多领域资产可快速复用。2、平台封装充分考虑基础设施的兼容支持。3、提供APP质量评估系统，高效APP交付质量把控。4、可信工具链，提供APP端到端丰富工具支持，轻松构建APP可信能力。

直播链接 https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=166374    观后感：ADC（Application Development Center）是一个低代码、多体验的开发平台，提供面向业务开发者的全场景开发平台，以及完整的资产生命周期工具链，解决传统开发门槛高、周期长的问题，形成以业务资产为核心的高效开发和复用的新开发模式。GDE.ADC作为低代码、多体验开发平台，主打特点是低门槛、高效率、一体化、安全可信低代码开发平台：由简单易用的可视化设计器和部署灵活的服务器构成，能帮助开发者快速构建美观易用、架构专业、安全可控的多终端应用，并随需而变。多体验开发平台：提供跨平台 APP，支持与多开放平台的深度集成，帮助开发者快速构建跨平台应用，实现一站式完成系统开发工作。面向运营商，ADC作为一个低代码、多体验的全场景开发平台，集成数据、AI、API Fabric等服务编排能力，面向运营商多类业务软件开发诉求，提供一体化编排能力，以快速实现新特性开发与上市。支持无开发技术背景的运维人员，快速完成业务应用的配置和上线为目标。提供使能系统，助力OSS数字化转型。帮助运营商缩短TTM，加速新业务创新面向开发者低门槛易上手提供图形化开发Studio，以拖拽和类自然语言的方式，快速构造应用服务开放流程、界面、数据、AI等编排能力，所见即所得开发效率提升多领域资产可快速复用平台封装充分考虑基础设施的兼容支持提供APP质量评估系统，高效APP交付质量把控可信工具链，提供APP端到端丰富工具支持，轻松构建APP可信能力快速业务创新交付多终端在线开发环境，支持开发者随时随地敏捷开发基于平台自定义扩展能力，轻松应对现网复杂业务特点，快速业务定制

[技术干货] [技术干货] 云管理解密系列汇总 乾坤云地址：cid:link_13南向ip 139.9.137.139 device.qiankun-saas.huawei.com文件服务器：121.36.7.20乾坤云资料：cid:link_4乾坤云存量上云相关信息采集cid:link_6【乾坤云】乾坤云管理界面系列之常用菜单和页面 [技术干货] 乾坤云解密之账号注册云管理解密之对接华为云短信服务器配置案例如何进入旧版云管理网络【WLAN】乾坤云管理解密之AP设备即插即用:管理SSID（无线）乾坤云管理解密之FIT AP切换到云AP[技术干货] 乾坤云解密之批量FitAP切云[技术干货] 【功能特性】乾坤云管理解密之AP设备即插即用:web网管（有线） [技术干货] 乾坤云管理解密之AP设备即插即用:命令行（串口） 胖AP、瘦AP、云AP的前世今生[技术干货] 乾坤云管理解密之WAC监控上云 （存量WAC场景）[技术干货] WAC配置HACA认证乾坤云管理解密之如何诊断云AP无法上线问题【LSW】【功能特性】乾坤云管理解密之基于配置文件模式的随板WAC纯监控上云 （存量随板WAC场景）[技术干货] 乾坤云管理解密之通过命令行手动配置交换机（R19C00及之后版本）上线及debug云管理解密系列之交换机极简架构配置（小行星方案）乾坤云管理解密之基于默认模式的交换机上云 （存量交换机场景，R19及之后版本）乾坤云管理解密之基于配置文件模式的交换机纯监控上云 （存量交换机场景，R19及之后版本）【功能特性】乾坤云管理解密之如何诊断交换机无法上线问题 乾坤云管理解密之上云后，无法telnet到设备上【认证】云管理解密之公共二维码认证，通过微信扫码方式配置方法【AR】乾坤云管理解密之AR上云常用的命令【APP】【CloudCampus APP】设备咋离线了？诊断日志一键采集 【CloudCampus APP】账号又登不上？看看是不是这些原因【CloudCampus APP】设备停用猝不及防，License到底怎么管？CloudCampus APP，企业网络全生命周期云化管理助手！[技术干货] 【单AP上云指南】CloudCampus APP快速开局【单AP上云指南】CloudCampus APP扫码录入

MessageFlow是一个低代码开发平台，面向边端终端提供物联APP编排服务。MessageFlow由部署在云端的设计态和部署在边侧设备的运行态组成。开发者可以在云上采用可视化编排的方式开发物联APP，然后一键批量部署到边侧设备上，所编排的APP支持跨平台运行。同时，MessageFlow对部署在边侧的运行态和运行态上运行的APP有高效的运维能力，能极大提高运维效率，降低运维成本。 # 产品价值 1. 开发门槛低，业务人员可编程：提供可视化、低代码的快速App应用开发技术，降低App开发门槛 2. 效率高，比传统模式提升10倍：乐高积木式开发，组件可沉淀复用 3. 高效运维：云上App开发，一键部署到物联终端运行，实现规模化远程部署，避免耗时耗力的现场运维 4. 集中管控：构建统一标准开发框架，实现开发资源、开发过程、App部署的集中管控 5. App安全可信： 基于统一的开发平台，可规避App的安全风险。通过一次开发反复使用，提升App的健壮性 

不知道指的是哪个网站，我也没有苹果手机。

查看详情>>  新增01    支持通过app方式开发新的编排能力并接入一体化框架：TOO技术作业接入一体化编排框架。02    流程设计器支持提供扩展支撑业务实现自定义编排元素1） 流程设计器支持提供扩展支撑业务实现自定义编排元素，如通过定制实现针对活动的编排2） 支持业务自定义扩展流程设计器中可编排的元素列表，如增加一列名为活动的元素列表3） 支持 业务自定义编排元素在画布中编排时参数详情展示样式03    提供技术作业APP运行所需的相关接口和组件1）  提供流程执行画布、流程设计器等页面组件2）  流程设计器支持基于活动的编排，支持提供扩展3）  平台提供支撑业务APP运行的相关接口，包括MCP指令执行相关接口、流程运行相关接口、流程定义/流程导入导出相关接口等04    Python能力补齐1） GDE数据域开发态页面中，新增“函数依赖包管理”供系统管理员用户来上传和管理函数依赖包。2） 对函数服务资产进行打包时，系统会自动调用ADC Mate接口来进行打包操作，并对资产进行扫描。若该资产存在对应的函数依赖包，则ADC Mate会从公司可信仓库中获取管理员已上传的依赖包。  修改01   ※将TOO在BPM后台微服务代码中针对技术作业任务导入导出的实现迁移到Python资产中实现   1.  bpmruntime.api.bpm.scenarioService.importScenario接口㕜导入任务的实现代码从BPM迁移到Python资产中   2. bpmruntime/processs/exportScenario.action接口中导出任务实现的代码从BPM迁移到Python资产中   3. 剥离too_runtime微服务，版本中不再提供该微服务02    SLM模块功能增强&优化：1.新增SLA 暂停和恢复功能，将SLA和工单 暂停和恢复分开；2.增加SLA事件级别，方便下游根据事件级别发送不同告警；3.增加里程碑后置活动-执行服务；4.SLA DFX优化：a、里程碑活动改为异步；b、增强导入SLA规则校验等；03    Tosca支持异步执行：1．异步Driver、CSE(Groovy)节点支持调用异步回调机制；2．服务间查询任务进度模式从轮询改为回调通知；04    SLA模板功能增强1．SLA指标参数管理；2．指标库管理：“监控指标”和“签约指标”管理；3．场景化模板管理：“S-NSSAAI切片SLA场景化模版”和“业务SLA场景化模版”管理；4．SLA资产导入导出；5．行业应用资产关联SLA资产变更；05    ADC-NSO进行业务解耦NSO依赖ADC相关的接口、SDK、和运行态adc-app-mgt的能力。NSO移交NOE后，NSO可以不随ADC发布，NOE可以做深度定制。

新增01    自定自定义组件&自定义页面&三 方库提供三方件免责声明02    支持ColorPickerColumn组件      新增“颜色选择列”组件，主要用于在可编辑数据表格中增加颜色值的输入。页面编排时，可将该组件拖拽至可编辑数据表格中，并根据实际场景需要，配置组件的宽度、数据索引、标题、对齐方式等，详细的操作方法请参考对应的组件在线帮助文档。03    支持Report组件       新增“报表展示组件”，主要用于展示通过报表设计器设计的报表。页面编排时，可将该组件拖拽至页面中，并根据实际场景需要，配置组件的ID、报表名称、最大页签数量等，详细的操作方法请参考对应的组件在线帮助文档。04    支持ReportDesigner组件      新增“报表设计器组件”，主要用于自定义设计报表的展示内容。页面编排时，可将该组件拖拽至页面中，并根据实际场景需要，配置组件的ID、报表名称、最大页签数量等，详细的操作方法请参考对应的组件在线帮助文档。05    支持ChartTemplateNav组件      兼容ADC1.0版本的“图表导航”组件，当用户在ADC1.0中的页面设计器中使用该组件，并将该App打包导入到ADC2.0中时，ADC2.0的页面编排中会展示该组件的相关配置信息供用户修改。在ADC2.0中新增的页面中无法直接使用该组件。06    提供JSLib系统级的多版本下载能力07    列表组件支持对每行记录分别自定义颜色08    Visual Script 透视图和表格 修改01    ADC UI编排，自定义组件属性栏支持业务自定义       1）自定义组件的脚手架支持生成自定义属性编辑器的模版。2）支持两种自定义属性编辑器类型的开发,类型包括：默认自定义属性编辑(直接编辑修改的这种）或者弹框类型自定义属性编辑器。3）开发者基于开发指南完成自定义属性编辑器的代码开发，打包上传到环境上。4）自定义组件在编排过程中，页面设计器根据属性的配置展示对应的属性编辑器。02    NIS资产兼容-UI服务   用户体验组 支持Markdown编辑器组件、代码编辑器组件、百分比列组件兼容ADC1.0版本03    页面编排时支持快速复用页面模版04    脚本模版优化       1）页面编排中，修改右侧的“脚本”页签中脚本列表的展示方式。       2）页面编排中，修改了编辑脚本时“选择脚本”的展示样式。05    页面设计态提供自定义样式配置组件   配置组件包括可以配置边距、边框、背景、字体、宽度&高度&阴影、自定义样式代码。06    容器类组件支持配置自定义样式，例如：尺寸、间距、字体等。07    TextArea支持内容换行08    支持CheckFieldColumn组件       新增“检查字段列”组件，主要用于在可编辑数据表格中增加复选框的输入。页面编排时，可将该组件拖拽至页面中，并根据实际场景需要，配置组件的宽度、列内容对齐方式、列标题等，详细的操作方法请参考对应的组件在线帮助文档。09    支持ModelColumns组件       兼容ADC1.0版本的“模型列”组件，当用户在ADC1.0中的页面设计器中使用该组件，并将该App打包导入到ADC2.0中时，ADC2.0的页面编排中会展示该组件的相关配置信息供用户修改。在ADC2.0中新增的页面中无法直接使用该组件。10    页面组件、组件样例、模板优化      1）组件示例的中英文内容保持一致。      2）组件示例支持国际化。      3）“进度条”组件支持绑定动态数据。      4）“列动态”组件示例中补充详细的功能描述。 

查看详情>> 新增 开发态通用能力01    支持保存模型画布的模型隐藏和显示状态按租户级保存模型画布的模型隐藏和显示状态，并随资产包导入/导出。02    支持ADC打包页面被Mate集成，并传递打包参数到引擎里03    [ADC配合租户资产库]支持资产分类标签标注及管理04    资产服务过期数据清理批量任务支持速度控制和调整，避免冲击主业务1、 提供控制清理速度的调节参数，如：任务并发数、每批次归档清理的条数、每批清理后的sleep时间。2、 提供合理的归档默认值，并提供现网调整指导05    逻辑流画布和模型画布一样，添加自动排版功能06    开发态开源免责声明-procode07    ADC支持提供资产开发免责声明，开发者在进入设计态开始开发时，点击确认免责声明后，才可以启动开发。08    一体化编排框架增强1、 一体化编排菜单分组注册支持排序2、 支持App级预览3、 支持App开发启用默认热部署4、 ADC引擎支持卸载时保留数据(框架层面)5、 支持编排菜单按照场景进行动态展现6、 工程模块变更支持把工程详情回调出去7、 支持AppManager和引擎运行时解耦，包含App参数和App领域信息8、 Example App支持在开发态自动导入，管理面初始化消息增加平面信息。9、 一体化编排支持引擎注册元素信息，并注册元素的locationUrl10、工程删除，关联菜单避免模型数据残留09    AppManager提供上报日志的接口，引擎可以上报安装日志，App安装完成后，将引擎上报的安装日志写入csv文件，并可以在“操作记录”页面下载该文件。10    AppManager支持在安装&升级&卸载等高危操作时进行二次认证11    APP重试安装：对安装失败的IMC、CAU引擎，用户点击“重试安装”，可以选择只重试安装失败的实例。12    支持在Store页面上架生态资产。13    RAM支持需求导入功能。14    Mate支持ADC在资产打包上架时，选择对应的业务领域15    服务支持API目录接口兼容。16    ADC设计器管理同步，增加自定义标签筛选，资产类型及业务领域分表处理。17    支持可引用的服务组件并能随App打包部署18    ※平台支持公安色风格1、  基于SPL配置的页面支持换肤2、  ADC平台菜单支持换肤19    GDE LINK 模型服务支持根据模型生成终端页面，方便开发20    模型ES同步支持分库21    App开发支持分权分域1、  ADC设计器支持团队管理、团队与工程关联管理、个人级工程管理、团队人员管理2、  ADC工程管理及设计器支持在展现工程的时候按照权限进行工程级过滤，并提供接口供引擎测过滤以及在打包时设置资产权限3、  ADC应用管理支持分权分域22    模型归档支持分库23    模型ES同步支持分库24    服务编排支持服务脚本管理25    恶意代码检测模型集成到ADC质量评估工具Python：Python恶意命令检测、Python后门代码检测、Python Pip恶意库检测JS：JavaScript挖矿代码检测、Javascript网页木马检测、XSS漏洞检测技术26    ADC设计态登录后的首页支持配置超链接         运行态通用能力01    ※支持一键式从开发环境部署APP到测试环境02    UI引擎/ ADC AppM支持低版本APP导入03    集成服务/编排服务/ BPM组/ MISC/体验组引擎/模型引擎支持App卸载时保留数据，回滚以及重新安装时用04    设计态查询App以及模块列表变更兼容05    rbac相关的excel权限随app导入兼容，包括permission/button/url/service/resource/Permission Management06    邮件接收能力(ADC功能兼容)1、Notice提供邮件接收能力；2、提供回调接口注册能力，收到邮件后回调对应接口；3、邮件接收支持附件；4、支持在ADC的事件编排中，订阅邮件接收事件，并获取到邮件内容和附件内容5、OP/OC场景通用07    ADC Studio首页提供自定扩展模块能力，可配置需求，重复，跟踪用。  08    在SDM系统中增加用户默认群组属性1、  维护用户默认群组。2、  流程模板修改。3、  已开发流程(没默认群组)的升级指导：提供指导文档，支撑业务完成改造09    工单列表按工单类型、父工单类型用颜色区分10    支持批量配置BARS/OLT等用户名和密码等认证信息1、  MCPBroker、MCP探针适配采集精简SDK2、  采集机进行主备切换时，采集探针需跟着做主备切换，避免主备切换后，采集探针不可用11    GDELINK支持应用快捷访问发布应用时支持发布预下载应用，当用户连上环境后，提示用户后，自动下载（更新）应用租户管理员可以配置只打开一个应用，手机端进入单应用模式支持应用内检测是否升级功能12    GDELINK支持原生导航栏13    GDELINK轻应用卸载时支持开发者清理资源14    GDELINK支持“游客”模式15    GDELINK终端补齐IOS版本能力，提供ipa包供安装使用16    工单支持分域管理能力1、  支持维护项目数据、用户与项目关系数据，一个用户可以有多个项目；2、  支持工单查询/待办查询/关联工单查询，按当前用户有权限项目进行过滤，不提供项目选择   针对创建工单，如果当前用户有多个项目，需要提供选择，如果当前用户只有一个项目，则不需要进行选择；3、  针对工单操作，不考虑项目过滤，有流程操作权限即可操作；4、  业务基于模型自定义的查询界面，需要业务自行控制过滤；17    API Fabric支持北向上下文动态配置，通过配置端点公共参数从北向获取相应信息应用至南向端点。18    支撑自定义portal中菜单搜索及分组收藏功能19    自定义菜单管理页面支持过滤已勾选项20    运行态AppManager支持App分组管理功能通过开关控制，当功能打开时，管理的App按组织进行可见性控制，可感知DIM创建的组织和角色（通过GAM上的数据对象）。App导入时与组织绑定，App列表界面，根据用户->角色所在组织过滤筛选App，并在App安装的时候下发组织信息给OWS引擎。21    App试运行分析支持PT模块资源评估22    APP操作优化和数据回退对于批量处理的最后一个梯队中的APP，如果该APP没有被其他APP依赖（包括dolas分析出的元数据依赖和用户自定义的安装依赖），元数据预抽取、APP预操作任务执行该APP失败时，允许用户跳过该APP，继续执行其他APP的元数据预抽取、APP预操作。23    AppManager支持割接场景引擎预安装AppManager在割接场景，设置场景化参数，标示是否割接场景。如果是割接场景，执行的“APP预操作”时，只执行声明在“割接场景”下执行的引擎预安装。24    RAM增加需求导入功能。25    支持标准资产API上架功能。26    租户资产管理服务支持分权分域。27    第三方用户管理优化：管理员批量导入账号和Maxis绑定,并支持用户管理页面显示关联关系28    第三方用户管理优化：管理员批量导入账号和Maxis绑定,并支持用户管理页面显示关联关系29    GAM支持对接第三方免审批30    GDE支持通用短信网关协议:SGIP、SMGP协议31    Notice功能优化。1、  Notice发送邮件和短信接口中的请求参数增加Trigger By字段。2、  GDE数据域的“通知服务管理 ”的查询邮件和短信发送日志界面，增加了导出日志的功能，并且增加了过滤条件：发送者名称。32    GAM风格统一。33    支撑自定义portal中菜单搜索及分组收藏功能。34    自定义菜单管理页面支持过滤已勾选项。35    GAM支持配置三方同步用户默认拥有产品卡片权限36    GAM用户同步能力增强支持批量同步三方用户能力，使用LDAP协议对接三方时支持自动同步用户能力，级联场景主从GAM间支持自动同步用户能力37    Portal 体验优化“产品与服务 > 管理员配置 > Portal配置 > Portal公共配置 > 公共参数配置”页面，增加“Portal菜单展示模式”参数用于设置Portal菜单的展示方式。38    Notice支持发送Restful短信。39    GAM支持用户名和角色的导出能力。   修改开发态通用能力01    设计态领域管理增强，预留ADC、Default等关键字名单，不可用于创建领域。02    分库能力优化，支持隐藏平台的业务领域，防止客户误选择。03    大数据模型支持5000个属性04    支持兼容流程修改，支持环节调整、表单调整05    流程模型支持app分库06    流程引擎支持分表07    模型数据行级访问控制及兼容08     质量评估继承完善1、  支持跨环境继承质量评估屏蔽记录；2、  集成修改指导联机帮助；3、  配合模型预估检查大表性能问题；4、  将误报率高的规则优化TQL注入、敏感日志      09    模型画布渲染优化模型表单热部署优化，模型编排数据源模型支持属性配置运行态通用能力01    模型归档任务切换为基础服务归档框架02    基础服务归档框架优化03    APP功能优化1、  轻应用列表自动刷新、轻应用版本升级强制升级的场景,用户点击进入时提示2、  使用照片场景,提供接口由开发可选:拍照或选择图片3、  图片预览功能增加图片总数以及当前位置4、  提供轻应用启动时接口回调(只执行一次：业务完成初始化数据库操作)5、  支持默认登录页面可配置04    APP（UI)灰度发布1、  安装APP时，选择是否灰度，如果选择是，则需要选择使用的角色；2、  界面上查看APP对应的所有版本，以及是否是灰度版本，以及灰度使用的角色；3、  支持对UI页面进行灰度发布，只有灰度用户可以访问灰度版本的页面，其他用户继续访问原版本的页面；05    管理面资产初始化支持初始化消息中带平面以及同一微服务不同类型间配置依赖06    App升级支持并行导入07    Excel支持单条批量并行导入08    过期数据清理批量任务支持速度控制和调整09    移除ES强依赖资产组配套10   支持平台预置App不能被删除11    RPA管理中心助手易用性优化1、  助手支持本地离线执行日志查看2、  助手连接管理中心易用性优化3、  支持人机协同任务的分配，即支持将协同任务分配给指定的人审核  查看全部>>

【功能模块】我们的App接入了华为会议功能，在线上发现了App崩溃，引起原因是华为会议SDK内部有空指针问题，引起整个App崩溃。而我也不知道具体是哪一步错了，才会导致的崩溃。【操作步骤&问题现象】暂时无法复现，因为是线上的崩溃。有大佬知道这个问题吗？谢谢了【日志信息】RuntimeExceptionUnable to start activity ComponentInfo{com.xxx.xxx/com.huawei.contact.ContactDetailActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String com.huawei.contact.model.ContactDetailModel.getAccount()' on a null object reference