[图片]右侧是一个scroll-view,里面的自定义组件中包含一个fixed弹框，但这个弹框无论怎么设置层级，只能显示在当前scroll-view的有效宽度内。安卓、开发工具都正常。ios不行、

设备型号：PC LinUI 版本：0.9.2 微信小程序基础库版本：2.14.3 问题描述及重现步骤： PC 微信：3.1.0.67(我试了其他版本也这样)， 只要引入LinUi哪怕不使用组件，上传为体验版后，PC小程序打开就是白屏！ 其他设备都正常，模拟器也正常！ 我试了手动复制LinUi，也是如此！ https://developers.weixin.qq.com/s/mQC7rxm27Xnc [图片] 已解决：https://github.com/TaleLin/lin-ui/issues/1277

appid: wxf02064882cb27687 微信版本[图片] 系统win10 如题，手机上能正常打开，电脑端打开就是白屏，日志不知道是没刷新还是啥原因，也看不到，求帮助

我司一直专注于微信小程序（以下简称小程序）开发，可以说是重仓押注在小程序上。 但由于小程序的大小有严格的限制(单个分包/主包大小不能超过2M)。 而我们的业务又相对比较复杂，因此常常会突破小程序的大小限制。因此，我们就不得不思考如何优化小程序的大小。 暴力方式 要优化小程序的大小，最好（最暴力）的方式就是删页面。 这样来，即高效执行起来也简单：统计下所有页面的PV、UV，将一些不活跃的页面移除就完事了。 但是，本文并不是要讲如何移除页面，因为这没什么好讲的。 分析 讲本文的优化方式之前，先分析一下小程序一般都由哪些文件组成的。 一般都是由以下几种文件组成： [代码].js[代码] 逻辑文件 [代码].wxml[代码] 页面结构文件 [代码].wxss[代码] 样式文件 [代码].json[代码] 配置文件 也许你会将一些image放在小程序里，一般建议放较小且少量的image，其他都使用网络图片 其中，由于[代码]JavaScript[代码]有一定的兼容问题需要处理，因此在打包和上传小程序时，开发者工具会对[代码]JavaScript[代码]进行[代码]babel[代码]编译处理，故这块可优化的空间比较有限。 而[代码]JSON[代码]的大小都比较小，且格式较为固定，也没什么可优化的地方。 接下来就是本文要重点说到的[代码]WXML[代码]了，一般[代码]WXSS[代码]都是和[代码]WXML[代码]配套使用的。这两者占小程序的大小比例也比较高，可优化空间非常大，可优化的思路也非常多。本文先讲一下[代码]WXML[代码]的一个优化技巧。 试验 其实，小程序最终的执行都是以WEB的形式完成的。因此[代码]WXML[代码]可以理解成类似于[代码]VUE[代码]的语法糖，最终都是要编译成[代码]HTML[代码]的。 所以，想要压缩[代码]WXML[代码]代码，就可以参考[代码]HTML[代码]的压缩方式。比如移除多余的空格。 我立马做了个试验，将[代码]WXML[代码]中的部分的空格移除之后，再使用开发者工具上传，发现小程序的大小真的发生了变化，变得更小了。因此可以得出结论，移除[代码]WXML[代码]中的空格是可行的压缩思路。 自动化 既然移除空格是可以减小小程序代码体积的，那么如何实现自动化移除的。 首先我想到的是，利用巨人的肩膀：[代码]htmlparser2[代码]。通过语法分析器，识别[代码]WXML[代码]的空格，并一举歼灭。 绝大多数情况下，这个做法是可行的。但是有一种情况，会导致[代码]parser[代码]识别出错：[代码]WXML[代码]中出现[代码]{{ }}[代码]，且使用了[代码]<[代码]。 因此需要特制一个识别[代码]WXML[代码]语法的[代码]parser[代码]。 由于这样的parser比较简单，因此我就自己上手写了一个：wxml-parser 实践 通过上述我写的parser，写了一个简单的minifier：wxml-minifier 安装 [代码]npm i -D wxml-minifier [代码] 使用 [代码]let minifier = require('wxml-minifier') let fs = require('fs') let resource = fs.readSync('./app.wxml') // 假设输入为：<view class="home" ></view> <!-- test --> let result = minifier(resource) console.log(result) // <view class="home"></view> [代码] 总结 通过将[代码]WXML[代码]中多余的空格移除，可以将小程序的代码减小大概10%。 其实，从这个角度可以发现，开发者工具在上传[代码]WXML[代码]时，是没有做任何处理的。因此对于HTML的任何压缩方式都可以在[代码]WXML[代码]上使用。当然这也是后续我的[代码]wxml-parser[代码]持续更新迭代的方向。 不知道为什么微信官方在开发者工具上传代码时，不进行简单的简化处理。如果你有答案的话，欢迎在评论中给我回复！ 如果觉得对你有用，希望给我一个star，感谢！

小程序和小游戏内的用户登录，我们推荐使用以下两种方式获取用户信息： ▷ 按钮组件的登录方式，用户主动点击按钮可以拉起用户授权弹框，获取用户头像、昵称等信息； ▷ 在不获取用户信息的情况下，可展示用户头像昵称。 用户在没有任何操作的情况直接弹出授权的登录方式将逐渐不再支持，受影响的有 wx.getUserInfo 接口，以及 wx.authorize 接口传入 scope="scope.userInfo" 的情况。 1 为什么平台要做接口调整？ 我们提供了 wx.login 和 wx.getUserInfo 接口，用于获取用户的 openID 和基本信息。 推出这两个接口的初衷是希望：当用户使用小程序时，只有访问到真正需要登录的页面，才需要授权并登录。 但在实际应用中，我们发现很多开发者在打开小程序时直接弹出授权框，如果用户点击拒绝授权，无法使用小程序。 在没有任何提示和背景的情况下，直接弹框想要获得用户信息授权，用户脑子里可能会闪过几个哲学问题： 你是谁？ 我在哪里？ 我为什么要同意？ …… 相当一部分用户下意识会点击“拒绝“授权——这样不合理的登录流程既造成了用户的困扰，还使得用户流失。 用户通过小程序可以快速获取服务，因此在访问小程序的第一个页面非常重要。 对于一个互联网产品而言，第一个页面决定了用户对这个产品的认知，用户会选择是否继续使用这个产品。 一个优秀的互联网产品，能够给用户留下一个好的第一印象，用户可以快速了解你的产品，接收到你想要传递的服务信息，从而产生相应的操作行为。 一个优秀的小程序会吸引用户在小程序里进行探索，完成你期望他们去做的事，比如会员注册、商品购买等。 试想一下如果一个品牌的商品官网，一进入要求用户登录才能查看产品信息是什么感觉呢？ 因此良好的用户登录体验非常重要。 2 如何设计登录流程？ 用户打开小程序时，看第一眼的时候，开发者需要专注以下两个目标： ▷ 精准快速地传达产品理念，开发者要让用户能够快速了解自己的产品和服务； ▷ 将用户流量进行转化，让用户能方便操作或者交易。 一般而言，用户打开小程序后看到的第一个页面，先不要直接弹出授权框，第一个页面可以包含以下内容： ▷ 展示你的小程序功能（如产品、服务、活动等） ，让用户清晰地知道小程序是做什么用的，这些内容可以是你的精选内容； ▷ 激发用户的探索欲，通过描述或者图片吸引用户注意力； ▷ 按照自己的产品目标，给用户提供清晰明确的下一步操作（查看详情、购买等）。 如果某些特殊小程序在使用前一定需要用户登录，或者已经进行到需要用户登录的操作时，可以将 button 组件（其中 open-type 属性指定为 getUserInfo）放置到页面中，页面上可以大致说明以下要点： 为什么需要我授权？ 需要我什么信息？ 授权后我得到什么好处呢？ 接下来在页面上放置一个明显的登录按钮， 建议这个页面上不要有额外的点击区域，以免分散用户注意力，让用户专注于登录这件事情。 3 简单的开发建议 1 当用户打开小程序时访问第一个页面时，先通过 wx.login，获取用户 openID 。这时无需弹框授权，开发者拿到 openID 可以建立自身的帐号 ID。 2 在第一步中，拿到 openID 后，判断是新用户还是老用户。如果是老用户，可以直接登录；如果是新用户，可先在小程序首页展示你的信息服务，让用户对这个小程序有大概的了解，再引导用户进行下一步的操作。 3 当需要获取用户头像昵称的时候，对用户展示一个登录页面，这个页面只有一个最重要的操作，引导用户进行登录。 小程序中，在页面中加入一个 button 按钮，并将 open-type 属性设置为 getUserInfo 。 以小程序为例： 微信登录 对于功能较简单的小程序或者小游戏而言，如果不是必须要获得用户的头像昵称，建议可先通过wx.login 拿到 openID 后，使用 open-data 方式或者开放数据域的方式展示用户信息，整个过程都无需用户授权。 Tips： 1、在用户登录后，开发者需要存储用户的 unionID，而且建议只把 unionID 作为互通的用户标识，不要直接使用 unionID 作为用户 ID。因为一旦小程序迁移到其他的开放平台下，unionID 是会改变的，而 openID 是不变的。 2、用 button 组件的方式获得用户授权后，调用 wx.getUserInfo 就可以直接获取用户信息。这个的意义在于获取过一次之后，用户有可能改昵称头像，因此为了及时同步，最好是定期获取用户信息。 这里两个小提示： ▷ 定期使用 wx.getUserInfo 获取并更新用户的信息； ▷ 如果用户授权过一次之后，又在设置中关掉了授权（或者本地删除了小程序），那这时再调用 wx.getUserInfo 也是不会成功的，需要重新获得授权。 相关开发文档参考： ▷ 小程序 1、小程序 wx.login 2、button 组件，并将 open-type 指定为 getUserInfo 类型，获取用户基本信息 3、open-data 展示用户基本信息 ▷ 小游戏 1、小游戏 wx.login 2、用户信息按钮 UserInfoButton 3、开放数据域下的展示用户信息

[图片]                                            大家好，我是小打卡的前端负责人金轩正，今天分享的主题是如何基于微信原生构建应用级小程序底层架构，这个命题看上去好像有些大，不过不要紧，这次分享我把它拆一下，大致从 小程序原生开发面临的问题 小打卡整体架构演进 开发中摸索与实践 这三个方面来看这个讲一下 [图片]                                            小程序原生开发面临的问题[图片]                                            ok，首先第一个方面原生开发遇到的问题 小程序从17年诞生2年来一直处于互联网风口，不过对于开发者而言的整个开发体验不是特别友好，在17-18年之间我和很多开发小程序的小伙伴们聊过，大多数的反馈可能分为下面大致几类，当然还有更多: 没有父类，无法使用继承挂载全局方法，扩展生命周期没有父类，无法使用继承挂载全局方法，扩展生命周期 不支持跨页面/多页面通讯 setData的性能瓶颈 代码包大小限制 1/2/4/8 M，没有npm包 代码发布流程繁琐 其根本原因是将刚刚诞生的小程序与已经非常成熟的React，vue，angular作对比，而没有将小程序作为一个新的生态来看待，当然这个是一种看待事物的进步，并不是倒退，我在这里说这句话的意思是有更多的问题需要我们开发者主动去解决问题，推动整个生态的前进与发展 [图片]                                            其实这里可能有些朋友会问，已经有很多优秀的框架已经解决了这些问题，那么为什么还要使用原生开发？ 确实在这段时间内出现了很多优秀的解决方案，我们不用并不是因为情怀哈（当然还是有那么一丢丢） 更多的是下面几点： 历史包袱，改造成本过高  小打卡在小程序刚出现的时候就进入开发了，当时框架还不成熟，而且对创业公司来说时间和迭代效率高于一切，在人手不足，业务模式尚未形成，还处于探索阶段的情况下花费大量时间去做对产品影响较小, 甚至delay迭代速度事情不是很赚 减少与第三方沟通成本 高速迭代的情况下，将时间尽可能的覆盖于业务上，避免在整个开发-上线闭环上增加节点 避免开发黑盒，控制风险 虽然整个社区是非常活跃的，fixed一个问题同样是需要花费一定时间，但是很多时候需求是不会等你bug fixed 如非必要，勿增实体 即“简单有效原理”，这句话还是我去年刚来公司的时候和阿赖聊他所说过的 放在项目开发上我的理解是在架构层面要做的尽可能的薄，避免过度设计 这样才有足够的扩展性，灵活性，容错性 这些框架虽好，但是对我们当前业务来说可能过于复杂，比如跨端在之前的阶段还没有这方面需求，而像组件化小程序已经支持，自动化构建我们自己也是可以搭建的并不复杂 相信微信小程序团队 是真正的想把这件事情做好，而且做的是一个生态，不论是小程序对于反馈响应速度，和迭代速度非常给力，还是对开发者社区运营，比如是社区活跃与审核速度挂钩，社区周刊，优质个人和优质企业 对齐web标准，并且更加开放 [图片]                                            小打卡整体架构演进其实小打卡整个架构并非一蹴而就的，就像前面所说的如非必要，勿增实体，而是大量的实际开发中遇到的共同问题解决方案的集合题 [图片]                                            常规架构这个是微信小程序给出的快速开发模版的一个开发模式： server模块提供数据，App作为全局对象直连所有的业务模块，工具函数提供api处理业务模块的需求 优点： 整个模型非常简单，上手快，学习成本 低结构清晰，在业务不复杂的情况下可以快速开发 不瞒大家其实小打卡在最初的半年内基本都是这套模式。 当然是在业务不复杂的情况下，复杂情况下会出现哪些问题呢？ App作为全局对象在有大量业务模块连接的情况下，代码很容易膨胀，在多人开发的时候问题非常明显，无论是fixed bug还是正常的业务开发都会造成麻烦 页面之间独立，缺少公共模块，唯一的工具函数又要尽可能保持单一职责来提供服务（小打卡当时就是因为这个问题导致很多工具函数内部存储直接修改外部状态，导致大量强耦函数合无法拆分） 业务层直连server层，未拆分数据层的情况下，基本不存在复用性 上面所述的问题，从我接手这个项目到真正的调整持续了挺长一段时间，主要是缺乏一个契机来进行优化 优化的转折点 [图片]                                            然后突然有一天产品同学跑过来说： 我们要有自己的核心数据仓库，我们要看实时数据 ok，涉及到数据采集的问题了，我这边从浅到深大概列了几项： 最基础的多个页面pv，uv如何监控，不可能每个页面都要手动收集  为了统计页面和事件的分享和回流的数据，需要在分享事件携带大量的参数 微信的wx.previewImage, wx.chooseImage 等api对于用户session的收集造成很大麻烦 我们先解决第一个问题，如何收集页面pv，uv 容易陷入的误区 [图片]                                            在解决问题之前，我们先说一下开发小程序容易进入的误区 App 和 Page 等函数工厂是微信原生提供，不可修改 小程序项目结构是基于App, Page, 工具函数三个模块构建的 小程序的全局存储只有globalData和本地缓存 其实产生这些误区最根本的原因是小程序没有提供在复杂业务逻辑下的开发范式，比如vue，react有自己的通用开发模版 如果保持这些观念来进行开发的话，很容易将路子走窄，并且难以解决一些实际上的问题， 其实不论小程序和传统web有多少不同， 本质上还是在js环境下开发 小打卡架构图解 [图片]                                            为了更好的方便理解后面的具体实现，我提前放了一张目前小打卡的架构图 首先很熟悉的server这一边垫了一个数据层，主要将数据层和业务层解耦，提高复用性，并且提供一些通用功能，比如返回格式化数据问题，参数校验，日志监控... 在App对象和业务层同样增加了一个全局模块，提供独立于业务和工具类，只提供api之间双向通讯的渠道 工具模块的话其实就是对业务层的增强，比如常见的请求模块，上传模块，路由拦截等等 业务模块的话基本除了增加Component和中间层外没有太大变化 这个图上可能有两块可能大家觉得比较怪异，一个是global里面的函数重载，还有一个是业务模块的中间层是什么？ 函数重载其实就是修改微信提供的App, Page, Component函数，使其更符合我们的业务场景， 业务模块的中间层就是依赖于函数重载的扩展 其实小打卡的整套架构都是基于这两个模块，这两个模块赋予了更多的可能性，然而实现却十分的简单 点击查看：小打卡 | 如何基于微信原生构建应用级小程序底层架构（下）