个人案例
PoemInHole
杀马特少年专属小程序
文艺复兴扫码体验
1
什么是时政新闻,我们的内容仅是财会资讯,选择了资讯类为什么还识别为时政。什么是属于时政新闻呢?我们的内容仅是财会知识点,选择了资讯类为什么还识别为时政! 我们的资讯都是自己的工作人员整理的财会知识点,和时政无关的,求审核大佬, [图片] [图片]
2018-10-251
小程序虚拟支付申诉我们的小程序ios版本现在不含任何付费内容,所有内容均可以免费获取。 烦请审核人员审核一下我们的代码,解除我们的支付封禁,不胜感激,期待您的回复,谢谢!
2018-10-251
小程序审核提示需要选择游戏类目,但我这是小程序项目,选择游戏类目后,就无法运行了1:小程序内容不符合规则: (1):你好,贵方小程序提供内容为在线游戏,请注册一个新账号,同时选择游戏类目 如有疑问,请查看详情与反馈。 这是用小程序格式(app.js)写的项目,如果选择“游戏”类目的话,要求的格式是小游戏格式(game.js),这样就无法运行我的项目了,这只是一个简单的种树养殖 ,无法通过小游戏的格式来开发,所以麻烦管理员看到后,回复一下,我能不能选择休闲娱乐类目通过审核?
2018-10-251
只提供拼车信息,不支持发布行程,求审核通过- 需求的场景描述(希望解决的问题) 小程序核心功能已变更,不再支持发布行程,只提供拼车信息展示(数据来源于拼车群) - 希望提供的能力 新版即将提交,请问官方是否能审核通过。
2018-10-251
小程序附近类目提交审核已经第六天了,还是提示在审核中。也没收到审核反馈我们小程序位置类目提交时间:2018.10.19 到今天,也就是2018.10.25已经第六天了,还是提示在审核中。 小程序的appid信息如下: AppID(小程序ID) wx06af06e84a19a015 (m18252972501@163.com) AppID(小程序ID) wxa3c2a442528a54f7 (m18259321625@163.com) 都是提示如下,也没有收到审核信息。请官方处理下 [图片]
2018-10-25😄
自选股-微信小程序深度漫游指南相信最近几天,大家都被微信小程序(MINA)内测开始的新闻引爆了朋友圈,甚至因此引发了js的学习狂潮(笑)。有幸作为早期参与进来的自选股攻关小分队的我们,内心也是激动不已,希望可以尽早给大家分享一些开发经验和踩过的坑。不过呢,由于MINA的开发权限还没有完全放开,有一些具体的内容还在保密阶段,我们在征求了微信开平同事的同意后,将开发过程中的一些经验和改进方案整理出来,希望可以对其他开发者提供一些参考。 [图片] 引用一段官方介绍: MINA是微信提供的一套应用框架,通过封装微信客户端提供的文件系统、网络通信、任务管理、数据安全等基础功能,对上层提供了一套完整的Javascript Api,使得开发者能够非常方便的使用到微信客户端提供的各种基础功能,快速构建一个应用。 在页面视图层,我们使用wxml搭建页面的基本视图框架,使用css控制页面的视图样式。wxml是MINA提供的一套类似html的标签语言,同时也提供了一系列的基础组件,帮助我们快速构建视图。在页面中不能使用脚本代码,页面渲染所需要的数据,以及页面的交互处理逻辑都是在AppService中。我们提供了很方法将AppService中的数据与页面进行单向绑定,当AppService中的数据变更时,会主动触发对应的页面组件的重新渲染,这里使用virtual-dom的技术,加快页面的渲染效率。同时我们为页面组件提供了bindtap、bindtouchstart等事件监听相关的属性,可以与AppService中的提供的事件处理函数绑定在一起。实现页面向AppService层同步用户的交互数据。 AppService是每个MINA的服务中心,由微信客户端在页面视图层外启用异步线程单独加载运行,MINA中所有使用javascript编写的交互逻辑、网络请求、数据处理都必须在AppService中实现,且AppService中不能使用DOM操作相关的脚本代码。应用中的各个页面可以通过AppService实现数据管理、网络通讯、应用生命周期管理和页面路由管理。 所以有了这么棒的底层框架,我们才更有信心把自选股这么重的应用搬到小程序里。 -从零开始推动Canvas Native(iOS图形库)支持 微信小程序除了在底层架构的运行机制做了大量的优化,还对重功能(page切换、tab切换、多媒体、网络连接等)实际上是更倾向于使用native组件承载。而对于自选股来说,除了大量的数据,行情图的展示也是不可缺少的一环。而如果没有原生绘图组件的支持,那么这样的重功能一定会影响到速度,从而降低用户体验。 由于自选股的行情图是自研的前端模块,里面涉及到坐标系、几何图形、技术指标等大量模块,我们希望能够在尽可能少的修改代码就可以平滑的在小程序环境下完美运行。因此我们主动与微信开平团队交流,推动了Canvas Native的组件化流程,并共同构思了Canvas Native的语法、图形API的支持。 做过H5的前端开发一定对截图的Canvas语法不陌生。 [图片] (canvas原生写法) [图片] (协商讨论后的支持写法) 可以看到,绘图语法基本没有变化,其中wx.createContent()是创建并返回绘图上下文context对象。 其中,context只是一个记录方法调用的容器,用于生成记录绘制行为的actions数组。context跟canvas不存在对应关系,一个context生成画布的绘制动作数组可以应用于多个canvas。而context.getActions()是获取当前context上存储的绘图动作。输出结果如下: [图片] 最后一步,使用wx.drawCanvas()进行绘图。 [图片] -配合微信小程序的改进 MINA的定位是轻量的、用完即走的,我们也配合着微信贯彻这一理念。随着MINA版本的更迭,自选股小程序也及时调整着自身的方向,越来越凸显出其不同于App的特性。 一方面,尽量减少需要多屏互动的场景出现,这也就是说,很多情况下我们需要在一屏上呈现更多的数据,针对大量数据我们做出了如下优化: 数据层优化: 自选股产品本来就是数据驱动的产品,而且要求数据实时性很高,在开盘的时候页面股票数据实时更新 优化 1:setData 函数用于将数据从逻辑层发送到视图层,同时改变对应的 this.data 的值 改变String [代码]this.setData({ text: '自选股'})[代码]改变Array [代码]var changeData = {};var index = 0;changeData['array[' + index + '].text'] = '自选股';this.setData(changeData);[代码]改变Object [代码]this.setData({ 'object.text': '自选股'})[代码]这里需要注意的是: 1、直接修改 this.data 无效,无法改变页面的状态,还会造成数据不一致 2、单次设置的数据不能超过1024kB,请尽量避免一次设置过多的数据 对于以上情况,我们的处理与优化方法是: 1、减少setData的数据量 2、对setData数据分段处理 优化 2:本地缓存,即每个微信小程序可以有自己的本地缓存 对于缓存的获取、设置、清除,小程序分别提供了同步与异步的方法。 [图片] 为了增强体验,我们在Page的生命周期 onLoad(页面加载) onHide(页面隐藏) onUnload(页面卸载)函数里面添加缓存载入、设置,提高应用首次展示速度,加快页面与页面之间数据的通用性,提升用户在弱网络环境下体验。 后端优化: 另一方面,鉴于MINA本身微信场景的限制,很多native app可以使用的特性在MINA这里并不支持,针对这样的实际情况,我们暂时做了如下的兼容方式。 优化1:小程序对网络请求接口域名有明确要求。针对4种服务器域名(request、socket、uploadfile、downloadfile)每种只能指定一个合法域名。自选股后台业务十分复杂,使用了不同域名对业务进行划分。应对这个限制,自选股通过统一代理方式将域名收敛为一个域名,由代理层将请求转发。 优化2:微信小程序文档中要求wx.request网络请求发起的是https请求,自选股在统一代理层部署证书支持https请求,后端RS机器无需改动。 优化3:小程序并发请求数不超过5,自选股使用动态接口将页面需要的数据进行合并,通过一个接口获取页面所需数据。 优化4:小程序关于登录态与移动应用和网页应用的不同之处是抛弃了access_token的验证方式,而是采用session_key加签名的方式,为小程序与服务器交换敏感数据提供了对称加密方法。签名方法对小程序透明,后端服务实现相应的解密程序以及登录态验证和控制能力。 -极致体验、极速开发 综上所述,微信小程序MINA有着接近原生app的运行速度,做了大量的框架层面的优化设计,对android端和iOS端做出了高度一致的呈现,并且准备了完备的开发和调试工具。感谢微信开平的同事,他们的不懈努力为众多开发者们打开了一扇新世界的大门。也很佩服开平的同学们,我们在开发沟通过程中提出来的多数建议都能够快速的响应并支持,给了我们非常大的成就感! 而对于更多的开发者来说,JS语言的低入门门槛、迅速的调试发布流程、完备的API文档和微信强大的平台能力更是让人欲罢不能。我们从MINA诞生至今跟随其一同演化发展,互相促进支撑,过程中MINA框架结构几经山崩地裂的调整,所有页面在前一秒还是好好的,更新开发工具后面目全非。但,很幸运的是,现在工具已经趋于完善稳定,大家可以尽情地“玩耍”啦~~~最后还是要说,我们的开发过程尽管荆棘满布,我们仍紧追不舍,在短短的两个月时间内,不断推翻、不断重构、不断打磨体验细节,终于完成了自选股小程序的基本核心需求,初步形成了一个闭环。 我们还在不断的优化,你看到的只是冰山一角,敬请期待自选股小程序的正式亮相!
2018-10-25?
微信小程序开发之尝试 UI 逻辑分离在大概 8 月底,有幸参与了企鹅 FM 和微云的微信小程序开发,这篇文章是我对 UI 逻辑分离的思考总结,另由于微云的业务逻辑代码实在太复杂勒……所以文章中将主要以 FM 为例。 UI 分离 在微云和企鹅 FM 项目中我们都是采用 UI 工程师+前台工程师的模式,所以必然出现了我们(总是吐槽的)在日常页面开发中会采用的方式: [图片] 在 html/wxml 结构中用注释的方式,告诉开发 GG:“当出现 XXX 情况的时候,加上 YYY class”,于是业务逻辑代码中,就一定会掺杂着 UI 逻辑,甚至 hard code 的地方: [图片] FM 中不止一种场景会触发“播放”/”暂停”逻辑的应用,也就是有多种可能会触发 UI 的变化,那么 UI 逻辑还会有重复的地方。万一有一天需要更换或新增或删除 class 名,就很有可能出错。 如果可以把 UI 逻辑独立处理就好了,这是当时我的想法。经过合作的开发 GG 提点之后,由于很多 UI 层的逻辑是跟着业务逻辑走的,所以完全剥离 UI 逻辑是不现实的。强行分离就需要把[代码]this[代码] 传来传去,在我看来也不是回事儿。所以 UI 逻辑采用的还是单纯的“变量分离”,可以粗暴理解为,把当时写在注释里的内容,写到独立的 js 文件中。 下面以 FM 为例,来看看我是怎么做的吧~ FM 中 UI 会出现变化的是以下几种场景: [图片] 播放器有两种显示模式:mini 播放器和全屏播放器 这两种模式是通过在播放器上切换 [代码].mini[代码] class(mini 状态需要 [代码].mini[代码] )实现 全屏播放器的播放按钮有“播放”和“暂停”两种状态(图片)切换 因为小程序不支持 [代码]background-image[代码] ,所有图片需要通过 [代码]<image>[代码] 组件现实,图片的切换可以通过换不同的 [代码]src[代码] 值实现。 当播放器进入全屏模式后,节目列表将被隐藏;而到 mini 播放器时,节目列表将重新显示出来 列表中的节目,播放按钮有“播放”和“暂停”两种状态切换 同 2,通过切换 [代码]src[代码] 值实现(这里应该也可以用 [代码]wx:if[代码] 来实现)。 项目结构如下,其中在 [代码]utils[代码] 目录中的 [代码]view.js[代码] 是 UI 逻辑部分的代码: [图片] [代码]pages[代码] 目录中的 js 文件将通过 [代码]require[代码] 引用 [代码]view.js[代码],[代码]view.js[代码] 中的接口分为“通用”和“页面使用”这两个类型。 [代码]module.exports = {[代码][代码] [代码][代码]// 通用[代码][代码] [代码][代码]general: {[代码][代码] [代码][代码]hide: [代码][代码]'hide'[代码][代码],[代码][代码] [代码][代码]show: [代码][代码]'show'[代码][代码],[代码][代码] [代码][代码]getScreenHeight: getScreenHeight[代码][代码] [代码][代码]},[代码][代码] [代码][代码]// 播放器页面[代码][代码] [代码][代码]playerView : {[代码][代码] [代码][代码]class: {[代码][代码] [代码][代码]mini: [代码][代码]'mini'[代码][代码], [代码][代码]// 小播放器模式要有这个 class[代码][代码] [代码][代码]listItemPlaying: [代码][代码]'playing'[代码][代码] [代码][代码]},[代码][代码] [代码][代码]images: {[代码][代码] [代码][代码]listPlayBtn: [代码][代码]'../../images/play/play-list.png'[代码][代码],[代码][代码] [代码][代码]listPauseBtn: [代码][代码]'../../images/play/pause-list.png'[代码][代码],[代码][代码] [代码][代码]playerPlayBtn: [代码][代码]'../../images/play/play-player.png'[代码][代码],[代码][代码] [代码][代码]playerPauseBtn: [代码][代码]'../../images/play/pause-player.png'[代码][代码] [代码][代码]}[代码][代码] [代码][代码]}[代码][代码] [代码][代码]// 其他页面如果也有需要,以页面为单位添加...[代码][代码]}[代码] 在上面的代码中,可以看到 [代码]general[代码] 里暴露了一个 [代码]getScreenHeight[代码] 方法,它用于获取屏幕高度,我们在 [代码]onLoad[代码] 的时候通过它,将设置了背景色的结构的 [代码]min-height[代码] 属性值设为屏幕高。用 js 的原因是,开发者工具 0.10 把 [代码]<page>[代码] 的高度 100% 去掉了,所以在 wxss 中就不能设置 [代码]height: 100%[代码] 把屏幕高度继承下来,但我们又要保证在页面资源加载出来以前,用户看到的就是全屏的暗色背景。 在页面使用的接口里就分成了 [代码]class[代码] 和 [代码]images[代码],如果未来出现更多 UI 变化的场景,可以再通过变量添加上去,比如 [代码]pageView.id[代码]。 举个超级简单的例子(如下),模拟工作流程: [图片] 在 wxss 中定义好控制不同样式的 class 将需要变化的 class 写到 [代码]view.js[代码] 中,并暴露接口 在 wxml 中的对应结构中绑定 event handler 在对应的 [代码]page.js[代码] 里实现 event handler 的具体内容,也就是切换 class 的触发条件 [图片] 结论 老司机一看就知道是 MVVM 模式。 这样分离也就是为了 UI 有独立的控制器,不至于和业务逻辑耦合严重,在页面开发的阶段就可以完成 UI 上的变化。之前写网页的时候,当需要 UI 变化的时候,我们常常会在页面上绑定事件,示意前台GG 逻辑是怎么样的,但是那部分代码可能并不能直接放入他们的业务逻辑中(可能是规范、逻辑没有考虑完整……原因)。从这个角度上看,小程序反而能给 UI 工程师更多控制 UI 逻辑的能力,确定好代码规范和接口,也能方便前台 GG 直接使用 UI 代码,专心业务逻辑~
2018-10-25OK!
自定义组件初始化时因为默认值不同导致 prop 的 observer 被调用- 当前 Bug 的表现(可附上截图) 在自定义组件 Component 的 properties 中定义 prop 的缺省值以及 observer 函数。 当使用该组件需要初始化该组件时,若 prop 接收外部传入的实参与该 prop 的默认值不相等时,会导致 observer 被立即调用一次。 - 预期表现 prop 的缺省值应该是组件未接收到外部传参时,使用的缺省值作为默认值,这属于组件初始化工作,不应该视为 prop 发生了变化。 所以当组件初始化时,如果 prop 接收的外部传参与缺省值不相等时,不触发 observer 调用是不是更合理一点? - 提供一个最简复现 Demo 代码片段:wechatide://minicode/8SCwknmx7D3z
2018-10-25😄
关于腾讯视频插件问题- 当前 Bug 的表现(可附上截图) 使用腾讯视频插件播放视频 视频已经播放了, 但bindplay绑定的回调没有执行 - 预期表现 执行bindplay回调函数,修改视频的播放状态 - 复现路径 - 提供一个最简复现 Demo
2018-10-25这个二维码有坑建议不要使用。虽然你在代码里面判断了,但是用户长按扫码的时候场景就变成了 [图片] 你在开发工具里能调吗
关于小程序二维码问题getwxacodeunlimit这个接口目前我已经成功的生成了二维码, 并且通过扫一扫是能够得到值的, 但是我通过微信的长按识别图中二维码, 不管怎么样,得到的值就是不对!!!!是什么原因?我前端是通过 decodeURIComponent(options.scene) 获取值的..由于这个接口每次测试需发布, 测试太慢了。 望大哥指点一二
2018-10-24