首先，对官方提供“默认集成、无需安装、不占包体积”这样的扩展方式表示100000个赞。这对有限包体积还要求快速启动的小程序来说无异于一种极大的便利。 然而，真正使用下来，略微失望。 官方的扩展从功能角度划分，两类。 Ui组件和框架类扩展/工具类。 [图片][图片] UI类的扩展，恕我直言，略显鸡肋。 WEUI扩展，出发点很好：和微信ui保持一致，提供较为全面的常见组件，补充内置组件的不足。 然而，真有公司或个人使用WEUI组件么？追求精美的话，必然会自己设计ui；图省事简单的话，大把的全套ui可选择，如taro-ui、minui、colorUi等等。而且无论从组件的ui设计、组件的全面性、社区的生态来说，都比weUI好的多。 扩展ui组件方面，上面的帖子都提到了很多。兼容性问题、适用场景问题，不一而足。个人使用的感受：这些组件真的都进行过详尽的测试么？拍手叫好的帖子真的有深入使用过吗？emoji、recycle-view、tabs等等组件，基本上是看似美好，拿过来问题多多，改造的工作量和时间，真的不如重新写一个。 UI组件库，在我看来，不应该是这样零零散散，不成体系和生态；也不应该是非要贴近流行趋势，什么流行提供什么，譬如上面有提到提供异性tabbar、日历，互动场景，抽奖，截屏，上传头像裁剪，其他营销级别的组件，完完全全没有必要。毕竟UI是一个仁者见仁智者见智的东西，真提供了，你也会发现，和我要的不一样啊！ 官方提供的ui框架，提供完备的定制、扩展接口才是ui组件的正确方向。纯靠官方提供的组件库，注定生命力不会太强。定制性强、扩展性强、社区生态化才是ui组件的可持续发展之路。 框架扩展/工具类组件是我非常支持的一类扩展。 小程序毕竟不是完全web环境，对于基于dom或者其他一些第三方库的兼容性或多或少会有一些问题。同时，小程序受限的包体积和无需下载、开箱即用的特性，决定了在开发过程中，我们对于第三方/扩展库的使用会比较慎重。 官方提供的一些库的扩展，譬如mobx-binding、lottie和threejs的小程序版本，很大程度上减少了开发者适配的工作量，然而这些工具类/框架扩展，除了kbone，没有一个进入微信内置库。而且，动作太慢....mobx的binding，自己改造的版本都用了很久，官方的版本才放出来；至于向官方建议的redux-binding官方版本，官方说评估，然后...然后就没有然后了。 如果官方能再提供或者引入一些常见js库的内置集成，譬如lodash、moment、redux的小程序binding等（当然这些是需要慎重考虑的，毕竟微信内置支持牵涉多多），那岂不美哉？ kbone只是稍作了尝试，并未深入使用。惭愧，官方力推的框架，还是需要深一步的了解和使用。 最后，请加强扩展组件的稳定性和可用性测试，完善文档和demo。 最后，请扩展组件支持分包。 最后，轮子不是造出来就行了的，是需要持续维护和优化的。

首先，感谢官方对云开发现有特性的总结（把我想说的已经说完了，还能说些什么）。 [图片] 其实，Serverless从来都不是什么新概念。简而言之，Serverless 就是 FaaS（Function as a Service，函数即服务） 和 BaaS（Backend as a Service，后端即服务） 的结合。 简单来讲，小程序云开发就是使用了腾讯云的后端服务（比如云数据库、对象存储、消息队列等，这些云服务，可以极大简化我们的应用开发难度。），同时使用云函数空间中发布的函数。 阿里云、腾讯云包括较早针对小程序提供云服务的知晓云，都是Serverless的产物。 小程序云开发，基本的特点和优点： 1 无状态----因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。如果要共享数据，则只能通过第三方服务。这对于习惯了前后端分离开发的同学应该是再熟悉不过了。 2. 无运维、少维护----使用云开发我们不需要关心服务器，也只需要在运维商投入很少的精力，这也是云开发思想的核心； 3.成本可控--因为我们只需要为函数的运行、内容的存储、数据库付费。函数不运行，则不花钱，也不会浪费服务器资源。包年包月和按流量付费灵活可变，适用于流量渐进型项目上马。 4 免备案！这个省了多少麻烦就不说了。 使用云开发也做了项目，基本的api使用参见文档就好。 这里就说说官方大大没提到的，对一些项目结构、管理方式、功能拓展方面的思考和建议。 1 - 云函数依赖及层级划分。 每个云函数实际是一个独立的npm包，一个独立的容器，并不能看做是一个简单的函数。好处？彼此独立，便于平行分工。然而，项目中我们需要合理的进行层级规划。 这时候问题来了：公共的npm包怎么办？自己写的分层怎么办（譬如，数据层，服务层，db层）？ 不外乎以下几种解决方案： a. 独立开发出来，每个云函数里面扔一份拷贝（愚蠢，占空间，改动一点，全改一遍？pass!） b. 独立开发出来，以npm包的方式发布，在每个云函数的package.json中加入依赖（看似解耦了，然而一是本地开发不太好弄，二是依然会在每个云函数的node_module中占用空间，三是万一更新了，每个云函数的依赖需要 update... pass!） c. 为你的分层单独定义一个云函数，其他云函数以CAll function的方式调用（基本解决以上两者的问题，然而想想其他云函数中的一call function，不优雅！ pass！） d. 使用layer。这个在小程序云开发文档中并未提及，但是相信我，它真实存在。登陆腾讯云开发的pc后台： [图片] 看看文档说明： [图片] 比较好的方式，虽然需要独立开发、手动打包上传，但是相对于发布npm包，算是比较好的解决依赖的方案了。 我的建议：在云函数根目录中划分出common package，放置依赖、声明第三方npm包。供所有云函数使用和依赖。 2 - 权限管理。 在不使用云开发的时候，小程序的提审发布无外乎ide上传，mp后台提审（第三方服务商的api提审暂时不提）。相信很多公司小程序代码开发、小程序提审、小程序后台部署的权责应该是分开的吧（什么？你们公司就你一个人？当我没说），出了问题，权责到人。 那么使用云开发，问题来了。云函数几乎就相当于传统开发模式下的后台，任何一个开发人员都可以在ide中进行部署和发布、任何一个开发人员都可以看到数据库数据、运行脚本修改数据，这里的风险有多大就不用细说了。 我的建议：类似mp后台，划分出不同的人员权限，在ide的操作中直接体现！ 3 - 云函数环境。 优点：目前云函数空间对于小程序调用方来说基本是黑盒操作，可以在小程序中直接调用云函数，也可以暴露出http服务供网站、app进行调用，这是大杀器。从小程序角度来看，以前的拆包、抓包获取后台api接口数据的方式基本行不通了，数据安全方面得到了极大的保障；从http服务来看，可以进行鉴权，方便且贴心。 然而，云函数环境没有固定IP。 敲黑板，划重点。 在当前后端及服务的大环境下，很多公开的服务、接口为了安全性的保证，都需要在你申请服务的时候填入调用方的ip白名单。那么，设想一下，我的云函数中需要调用此种外部接口和服务，怎么办？ 当然，可以申请云函数域名白名单。 [图片] 然而实操后发现，对于从小程序IDE中创建的云函数空间中的云函数，无法设置公网IP； 从腾讯云管理后台云函数管理中创建的云函数空间中的云函数可以设置，然而此环境小程序又无法使用。 [图片] 死局。 难道再前置一个cvm网关调用么... 不过好消息是，工单及群中的官方人员确认不久会开放对小程序中创建的函数环境中的函数的固定出口ip支持。 4 - 其他服务。 小程序云开发既然是运行在腾讯云基础上的，当然可以无缝使用各种云服务，譬如： [图片] 文档和demo也对这些的使用有所提及。譬如如何调在云函数中使用mysql，如何进行图像安全监测、图像处理等等。 但是，目前的小程序云开发的函数服务，只是腾讯云的云函数的一个子集。 譬如，目前小程序云开发云函数环境只支持node，云函数支持的种类很多...... 譬如，目前小程序云开发只支持两个函数环境...... 譬如，上面提到的公网固定IP还未开放...... 等等。 我的建议：开放更多小程序云开发的功能，逐步向云函数靠拢。同时，丰富文档、demo、和一些架构实践。 譬如：小程序云函数环境能否和腾讯云上的cvm加入同一个私有网络（拿来做前置网关）？如何利用云函数和api网关搭建更强健的api服务？大公司对于云开发架构的一些具体实践？等等等等。 总结：  在我看来，任何一个新技术、新服务，吃透它的本质、摸清它的基本结构、提炼最佳实践，是重中之重。我相信，小程序云开发的api、db操作、各种文档，都会慢慢丰富和完善起来的。 云开发必然是未来的趋势，虽然现在小程序云开发尚有各位参与者包括我在内的各种抱怨，然而爱之深、恨之切，终将有一天，你我都会大声说出：“真香”！ 迎接云开发！ 拥抱云开发！ 善用云开发！

无

作为一个挺早就收到内测邀请的用户，简单说说自己的一些看法。 [图片] 小程序里面进行“测速”，之前无外乎几种办法： 1 - 小程序后台”开发“---“运维中心”---“性能监控”。这里能看到一些数据，包括首次打开、下载、渲染等等，但是不能定制，如果想看其他的一些“速度”，无能为力。 2 - 小程序后台“统计”---“自定义分析”中自己创建事件、完善事件字段，并通过api接口reportAnayasis上报分析数据。这种方式可以一用，然而自定义分析一般是用来进行用户行为分析或者结合api上报进行业务数据分析（包括后续的漏斗分析）。拿来做这样软件方面的基本分析似乎也不太合理和专业，查询的时候会麻烦死，而且对于“测速“而言，缺少了很多专业性的指标（譬如运营商-网络环境-等等，当然这些可以通过上报的自定义字段来处理，然而会增加不少小程序端的额外工作）。例如 [图片] 3 - 自己做一套”测速“统计后台....这个就不说了，麻烦，没必要。 小程序测速，应该说是对于”性能监控”和“自定义上报”的一个强有力的补充，真正做到了”术业有专攻“。 首先是维度比性能监控丰富了许多，地域、运营商、操作系统、网络类型、机型等都纳入了关键维度，可以进行更细粒度的交叉分析。其次，使用上面，比”自定义分析“不知道简单了多少，你唯一需要做的就是：1.定义监控指标，获得监控ID；2. 小程序内接口调用上报时间；3. 后台查看数据。 总体甚为满意，几个小的需求或者说是建议吧。 1 - 自定义维度功能。指南中的例子很简洁，可否更稍详细说明场景和用途，以及常见的一些自定义维度？ 2 - net测速和render测速中的默认维度，可否考虑加入”机型“分组（此机型非render测速中的“中高低”档位）。既然用户画像中可以分析出用户的机型（iphone 6，7，8，max、华为mate10、小米等），这里可否按此维度划分机型？不求所有，哪怕访问我小程序的前十机型也可以(这个“高中低”戳中了我的笑点，多高算高？多低算低？这个标准很不严谨。还好没放个“老人机”上来）。 [图片] 3 - net测速默认维度中是否可以加入地域维度？可以直观的看出server所在机房和不同区域人群速度的关系，便于优化。 4 - 最后，只有7天数据么？颗粒细度最大到60分钟，也就是一小时么？那如何进行直观的优化前后的周/月平均值的对比呢？小程序数据统计、性能监控里面，都有"最近7天、最近30天、自定义时间”这样的维度，以天、月为单位，查看方便，一目了然。

参加过一些，然而如果谈到印象最深的，恩，确实有。 来讲讲。 有一次参加校红十字的一个晚会，晚会上节目挺多，大都以普及知识为主，譬如各种情况下的急救等等，寓教于乐，气氛很欢乐。 最后一个，是一个类似于演讲或者说辩论的的节目。 主持人抛出了一个话题：如果，我是说如果，你是一名艾滋病患者，现在有一颗药丸，吃下去就能痊愈。请假想你的身份，并解释为什么这颗药要给你。获得票数最多的同学会有奖品哟。 我坐在前排，很幸运被点中参加这个比赛环节。 一共5位选手。 第一位：我是M国总统，维护世界和平，消灭人间暴政的任务落在我们的肩上。这颗药，应该给我，balabalabala..... 第二位：我是一名科学家，balabalabala.... 第三位：大家都看过汤姆汉克斯主演的《费城故事》吧，我是一位同性恋者，不幸染病，如果我痊愈后一定会致力于人权活动，让这个世界更美好。balabala... 第四位（我）：太紧张，忘记说啥了...... 第五位同学上场，其貌不扬。 他清清嗓子，开口道：”我是一名顶尖药理学专家，请把这颗药给我，痊愈后，我将倾尽一生、尽我所能研究这颗药的配方，造福人类。至于前四位同学，你们的遗愿，我会帮你们完成! ” 瞬间，掌声雷动，高票获胜！

2020年，恐怕是第一次，中国有如此多的人在家上岗。 当然也暴露了很多问题。首先给大部分的“线上”协作工具带来了前所未有的压力。 比如延长春节假期结束的第一天，企业微信和钉钉就崩到绝望，紧急扩容。 其次，大家纷纷发现，这线上办公不是我想象的那样子啊！ 有人发现在家办公比想象中更累，并不是效率更高，做完就能休息，而是工作多到做不完。 有人说在家办公需要随时待命，晚上十一点还要求进行视频会议。不是996，胜似996！ 不是想干就干，不想干就躺！ 不是一手拿鼠标，一手拿咖啡，惬意的指点江山！ 目前很多在线办公\协作\教育等相关行业人员都在惊呼，全民在线办公时代已经到来。 我不知道他们的“惊呼”是真的在为看到了宏伟的未来在惊呼，抑或只是自己的角度必须为自己的行业，为自己的产品“惊呼”。 抱歉，远远未达到你的预期。 硬件条件不允许。不说别人，单说我自己，家里的宽带情况，真心还不如我自己的手机4g开热点情况好。视频会议卡顿，访问代码仓库慢，5g的普及应该能解决很大的问题。 在线办公太分行业。能看到这篇讨论的同学，大部分都是开发人员或者互联网从业人员。应该来讲，对于在线办公并不陌生（怕是大部分都有在家紧急解决问题的经历吧）。参与讨论的，大都在说远程开发、流程图、看板等IT行业的流行协作方式。 然而，其他行业呢？ 我想恐怕其他行业很多人今年都是第一次接触在线会议、远程协作这一概念。 从行业的角度来看，很多行业，譬如第一产业的农林牧渔、第二产业的制造业、第三产业的服务业，这里面得有多少类目无法在线办公？除掉这些，国家行政机构、政府机构，又有多少不能在线办公（这里有很多涉及到信息保密的问题，是不可能让你在家进行处理的。譬如财务是需要硬件狗，银行、司法、甚至公安局都是有内部大专线）；从公司内部的分工角度来看，有些职位可以远程在线办公，有些职位是无法在线办公的，这个问题又怎么解决？须知“不患寡而患不均”，留守公司的人一定会有其他的一些想法。另外，在线办公的和留守公司办公的，合作协调也会出现一定的障碍。这都是需要考虑、需要解决的问题。 效率问题亟待解决。在线办公，效率能否比公司办公强呢？很难讲。大部分工作是需要协作的，环境的影响、沟通是否顺畅、工作流程的流转是否顺畅，在很大程度上都会影响到在线办公、在线协作的效率。很多事情，在公司办公，可能只是吼一嗓子的事情。拿到线上，那可就未必了。这一方面需要员工对于居家办公有极强的自律性，一方面需要公司对在线办公具有强大的约束力和协调能力。这些都需要公司和员工的摸索，需要时间去沉淀，无法一蹴而就。 最后是观念问题。中国人嘛，是讲究人情世故的，很多事情是当面谈出来的，一起“吃”出来的，甚至是“喝”出来的。光靠线上，那是不大可能的。业务转型到线上？那还需要整个社会用很长的时间去适应、去接受。 当然，线上办公是未来发展的必然趋势，这一点是毋庸置疑的。毕竟，科技进步的终极目的，就是在提高工作、社会效率的同时，让作为万物之灵的人类生活的更惬意，不是么（手动狗头）？ IM\邮件部署任务、在线会议沟通协调、足不出户解决问题，剩余时间自己支配。我想，这是绝大多数人梦寐以求的线上办公方式。 全民线上办公（当然，一些特定的职业依然是需要亲临现场的）？我想，这个术语不够准确。随着科技的进步，真正的办公方式应该是随时随地，借助便携设备和进步科技，完美的完成工作。 这样的时代最终一定会来到，这需要国家、社会、企业、个人诸多方面的共同努力-----加强硬件基础建设、改变传统观念、改变传统的工作处理方式、完善相关制度、加强个人约束。 努力！加油！

其实我很奇怪的是，至今都没有一个独立的、官方的bug板块，或者是说功能进度板块，或者说issue版块 确定的bug，功能修复，列出来，进度更新上 用户也能提issue，你们可以确认与否 就不至于现在社区里面什么东西都混一起 以下几种场景或者需求，恐怕是很常见吧： 1.发现一个bug，到社区一搜，我去，去年都有人提过了，官方还回复了”下个版本修复“，那么我现在复现了，到底是我人品不好呢，还是官方没修复呢？ 2.每周的公告里面会提到那些bug修复了，那些bug和功能支持中，然而被大家吐槽最多的恐怕就是”某些bug修复着修复着就没了”吧。 3.github上的issue多么的实用这个不用解释了吧，官方完全可以按照小程序、小游戏来做分版块issue，我只求发现了某个问题，在issue中先检索一下是否有，有的话岂不是皆大欢喜？我也不用多余再发个帖子，你们也不用再多余看下灌水的帖子？ 行了，就这么多 我字多，跟我混！

一开始是用丁香医生小程序....然而有时候数据稍微有些延迟。 其实这里就可以发现，其实纯资讯类小程序，在目前小程序的订阅消息体系下，实在有些缩手缩脚。重大的新闻无法推送提醒，偶发的（非固定时段的）直播要开始了无法提醒用户，等等等......在触达用户，召回用户方面，实在是一言难尽...然而这些对于资讯类，又很重要！ 后来发现微信看一看中直接就有置顶的疫情通报，自此就开始直接用微信查看了。这个必须赞一下！在重大事件的关键时刻，微信也不含糊，重要的新闻、消息第一时间就能从看一看中直接获取，方便多了。 身在疫区十堰，全城封闭，每天都很安静。 某天不得已有事情必须出门： 空荡荡的城市 [图片] 空荡荡的街道： [图片] [图片] 到处都是空荡荡。。。 现在几乎每天醒来第一件事情就是打开微信看一看，看看昨日的情况，每次都无比的盼望数字越变越少！ 各位朋友，各位开发者们，不管所在的城市是否有疫情，千万要严肃对待！ 保护自己，保护好家人的同时，也请善待身边的每一位疑似人员！ 万众一心，我们终将胜利！

这个问题真的很致命 横屏下需要渲染评论列表，只要是多条评论 设置的font-size不管你用rpx, px, rem, vw, vh, vmin 全部无效 各种黑科技全部试过了，无效

原来我不是一个人