[图片]扫描页面没有拍摄确定的按钮，无法识别身份证

<swiper current="{{currentDateRateTab}}" class="swiper-box" bindchange="bindDateRateChange" indicator-dots="true">           <swiper-item>              <canvas class='canvas' canvas-id='lineCanvas' ></canvas>           </swiper-item>           <swiper-item>              <canvas class='canvas' canvas-id='lineCanvas2' ></canvas>           </swiper-item>           <swiper-item>              <canvas class='canvas' canvas-id='lineCanvas3' ></canvas>           </swiper-item>         </swiper> 画布中是统计图，在开发工具中模拟器操作完全没有问题，在真机（iphone6）上就出现左右滑动时，出现半页切换并且只能切换成半页，无法切换成整页 [图片]

存在图片的页面会频繁闪烁，去掉图片就不存在了。请问是什么问题，用户多次反馈问题，希望尽快解决。

1、输入框居然不支持双向绑定。 2、只有自定义组件支持observer,页面不支持。 3、必须通过setData来更改数据。不知设计时为什么不用Object.defineProperty来实现响应式数据。 4、客户端性能低下。同一个交互动画，在移动版的谷歌浏览器上丝滑顺畅，在小程序客户端上卡得如麻。 5、不支持层级路由，导致一个公共头组件，每个页面都要加上。 6、组件上事件监听只支持以函数名作为参数，不可以放参，不可以用js表达式，导致一个简单的加法还必须做个函数实现，非常不方便。 希望小程序未来能够解决以上问题。

正文从下面开始。 今天的小技巧是使用纯 CSS 生成火焰，逼真一点的火焰。 嗯，长什么样子？在 CodePen 上输入关键字 [代码]CSS Fire[代码]，能找到这样的： [图片] 或者这样的： [图片] 我们希望，仅仅使用 CSS ，效果能再更进一步吗？能不能是这样子： [图片] 如何实现 嗯，我们需要使用 [代码]filter[代码] + [代码]mix-blend-mode[代码] 的组合来完成。 很多 CSS 华而不实的效果都是 [代码]filter[代码] + [代码]mix-blend-mode[代码]，很有意思，但是业务中根本用不上，当然多了解了解总没坏处。 如上图，整个蜡烛的骨架， 除去火焰的部分很简单，掠过不讲。主要来看看火焰这一块如何生成，并且如何赋予动画效果。 Step 1: filter blur && filter contrast 模糊滤镜叠加对比度滤镜产生的融合效果。 单独将两个滤镜拿出来，它们的作用分别是： [代码]filter: blur()[代码]： 给图像设置高斯模糊效果。 [代码]filter: contrast()[代码]： 调整图像的对比度。 但是，当他们“合体”的时候，产生了奇妙的融合现象。 先来看一个简单的例子： [图片] 仔细看两圆相交的过程，在边与边接触的时候，会产生一种边界融合的效果，通过对比度滤镜把高斯模糊的模糊边缘给干掉，利用高斯模糊实现融合效果。 利用上述 [代码]filter blur & filter contrast[代码]，我们要先生成一个类似火焰形状的三角形。（略去过程） 这里类似火焰形状的三角形的具体实现过程，在这篇文章有详细的讲解：你所不知道的 CSS 滤镜技巧与细节 [图片] 父元素添加 [代码]filter: blur(5px) contrast(20)[代码]，会变成这样： [图片] Step 2: 火焰粒子动画 看着已经有点样子了，接下来是火焰动画，我们先去掉父元素的 [代码]filter: blur(5px) contrast(20)[代码] ，然后继续 。 这里也是利用了 [代码]filter[代码] 的融合效果，我们在上述火焰中，利用 SASS 随机均匀分布大量大小不一的圆形棕色 div ，隐匿在火焰三角内部，大概是这样： [图片] 接下来，我们再利用 SASS，给中间每个小圆赋予一个从下往上逐渐消失的动画，并且均匀赋予不同的 [代码]animation-delay[代码]，看起来会是这样： [图片] OK，最重要的一步，我们再把父元素的 [代码]filter: blur(5px) contrast(20)[代码] 打开，神奇的火焰效果就出来了： [图片] Step 3: mix-blend-mode 润色 当然，上述效果已经很不错了。经过各种尝试，调整参数，最后我发现加上 [代码]mix-blend-mode: screen[代码] 混合模式，效果更好，得到头图上面的最终效果如下： [图片] 完整源码在我的 CodePen 上：CodePen Demo – CSS Fire 另外一些效果 当然，掌握了这种方法后，这种生成火焰的技巧也可以迁移到其他效果去。下图是我鼓捣到另外一个小 Demo，当 hover 到元素的时候，产生火焰效果： [图片] CodePen Demo – Hover Fire 嗯，这些其实都是对滤镜及混合模式的一些搭配运用。按照惯例，肯定有人会留言喷了，整这些花里胡哨的有什么用，性能又不好，业务中敢上不把你的腿给打骨折。 [图片] 于我而言，虚心接受各种批评质疑及各种不同的观点，当然我是觉得搞技术一方面是实用，另一方面是兴趣使然，自娱自乐。希望喷子绕道~ 回到正题，了解了这种黏糊糊湿答答的技巧后，还可以折腾出其他很多有意思的效果，当然可能需要更多的去尝试，如下面使用一个标签实现的滴水效果： [图片] CodePen Demo – 单标签实现滴水效果 值得注意的细节点 动画虽然美好，但是具体使用的过程中，仍然有一些需要注意的地方： CSS 滤镜可以给同个元素同时定义多个，例如 [代码]filter: blur(5px) contrast(150%) brightness(1.5)[代码] ，但是滤镜的先后顺序不同产生的效果也是不一样的； 也就是说，使用 [代码]filter: blur(5px) contrast(150%) brightness(1.5)[代码] 和 [代码]filter: brightness(1.5) contrast(150%) blur(5px)[代码] 处理同一张图片，得到的效果是不一样的，原因在于滤镜的色值处理算法对图片处理的先后顺序。 滤镜动画需要大量的计算，不断的重绘页面，属于非常消耗性能的动画，使用时要注意使用场景。记得开启硬件加速及合理使用分层技术； [代码]blur()[代码] 混合 [代码]contrast()[代码] 滤镜效果，设置不同的颜色会产生不同的效果，这个颜色叠加的具体算法暂时没有找到很具体的规则细则，使用时比较好的方法是多尝试不同颜色，观察取最好的效果； 细心的读者会发现上述效果都是基于黑色底色进行的，动手尝试将底色改为白色，效果会大打折扣。 最后 本文只是简单的介绍了整个思路过程，许多 CSS 代码细节，调试过程没有展现出来。主要几个 CSS 属性默认大家已经掌握了大概，阅读后可以自行去了解补充更多细节： [代码]filter[代码] [代码]mix-blend-mode[代码] 更多精彩 CSS 技术文章汇总在我的 Github – iCSS ，持续更新，欢迎点个 star 订阅收藏。 好了，本文到此结束，希望对你有帮助 😃 如果还有什么疑问或者建议，可以多多交流，原创文章，文笔有限，才疏学浅，文中若有不正之处，万望告知。 最后，新开通的公众号求关注，形式希望是更短的篇幅，质量更高一些的技巧类文章，包括但不局限于 CSS： [图片]

一、 从前端技术演进看前端发展野心 前端的技术近几年发展非常迅速，各种框架也如同雨后春笋。 从两个维度去分析前端的技术发展，一个维度是前端复杂度，具体来讲就是前端在解决创建应用复杂度方面做的一些事情；另一个是从广度层面看前端做的事情， 这两个维度构成了一个类似于二维平面的时间事件平面。 [图片] 1. 逐渐降低创建应用复杂度 单看复杂度，前端最开始的阶段只有HTML、JS、CSS，应用虽然是非常简单的，开发起来却是非常复杂的，因此，单单只是DOM操作方面就有大量的DOM操作API。为了降低操作成本，就出现了DOM操作框架，比如jquery。这个阶段类似于从原始的刀耕火种进入石器时代。对dom的操作带来了很大的便利性。尽管如此，真正在构建一个复杂应用的时候，因为业务逻辑和手动操作dom逻辑交织在一起，应用维护变得越来越难。 下一个阶段，引入了MVC分层思想，比如backbone,这能够将逻辑梳理的更加清晰一些。不过，MVC还是需要去关注视图层的。 接着，就出现了mvvm框架，开发者不需要再关注视图层的更新，只需要关注逻辑层、数据层。这一点为构建复杂大型app提供了极大的便利性。mvvm从Angular到现在react、vue的广泛应用，前端在逻辑构建层面发展已经到了一个新的阶段。 在构建大型应用的时候，仅有逻辑层是不行的，还缺乏工程性的思想。因此，出现了打包的模式，帮助我们构建更复杂的应用。这样我们所能做的APP复杂度是一个指数型的增长。 为了进一步提高可构建应用的复杂度、增强前端的性能，assembly技术标准出现，提供了前端字节码的标准，为创建更加复杂的应用打好了坚实的基础。 2. 一直在扩展的前端广度 刚开始只能在浏览器上运行，后来有了node代码，可以让我们的代码扩展到服务器端。紧接着PC端有electron。再到移动端有RN框架，支持我们向移动端进展。 现在出现了小程序，小程序框架能够让前端继续在移动端轻应用做探索。 这里没有讲到的嵌入式开发，这方面也有相应的解决方案。 前端不断扩展广度，把前面的边界不断扩大。 最终前端想一统天下，把前端全栈化。 二、 同时满足技术需求和商业需求的前端全栈 所有的技术在发展时期都有两条线去支撑着它发展，一条线是技术需求，即技术层面的技术创意和技术诉求；另外一条线是商业需求，即技术要满足对应的商业诉求。 [图片] 一个解决方案只有同时满足商业诉求和技术需求，才能蓬勃的发展。如果偏离这两条线，就很难发展起来。举个例子，比如Symbian，有些人有想尝试这个技术诉求，但是因为它已经脱离商业需求的层面，所以这个技术会慢慢被淘汰掉。 那么，如果仅有商业需求又会出现怎样的情况呢？ 比如，2000年的时候对AI有商业上的需求，但是技术需求并满足，当时AI就是一个要被搁置的东西。 前端全栈，是怎样在满足技术需求的同时满足商业需求的呢？ 我们回归到移动端APP的开发实际场景，只有两个层面：一个是UI交互界面的开发，这个是可以被用户感知到的，另外一个是用户感受不到的服务逻辑层面。如果来看现有的开发模式，单单从UI交互界面上来看，就有不同的平台端android、ios、h5，对应的语言有Java、OC、swift、js等几种语言，后端的语言和技术实现是更多的。在现在的模式下，一个小型公司如果需要开发一个完整的APP项目，就需要六种技术！ [图片] 每一种技术如果需要找一个专门的人来做，这就需要6个人。那么反映到公司企业运营上面，人力成本是比较高的，除了人力成本还有同样非常高的沟通成本。从沟通的角度上来看，全栈式开发模式的出现，能够让一个人负责更多的业务开发，降低沟通成本。 由此可见，前端全栈既满足技术需求，也满足商业需求的，所以我相信未来前端全栈一定会蓬勃发展。 三、 打破物理隔离，实现真全栈 再回过头看前端散落的各种技术，在这个发展的过程中，有一个很深的隔离，这个隔离本质上就是物理隔离，比如前端和后端，存在手机和服务器之间的物理隔离。 [图片] **因为各种端是实体端，每个端之间都存在物理隔离。**就比如前端和后端，存在手机和服务器之间的物理隔离。如果能解决这些隔离，就可以把前端的技术做到真正的统一开发模式，才能做到真全栈开发。 [图片] 其实后端的物理隔离，比如每台服务器之间的物理隔离，可以通过云端化，我们把代码上传到云端平台，云端平台会屏蔽机器之间的物理隔离，暴露给开发者的只有一个集群的概念，而不是一台机器一台机器管理部署。云端化之后，后端的物理隔离被消除了。 我们现在的前端代码和服务器之间终存在一个物理隔离，目前的解决方案是通过中间的协议打破物理隔离，比如http协议，但http协议毕竟是中间协议。 而serverless的理念就能完完全全解决掉这层物理隔离，因为代码即服务，serverless能打破这层隔离实现前端的真全栈。 Serverless中的FaaS，函数即服务，我在使用后端服务的时候，不再关心后端的ip地址，后端的域名是什么样的，直接调用函数即可，对前端来说，后端服务是一个函数，函数就是前端的代码的一部分，后端服务和前端完全的融合在一种代码体系里去了，这样后端的服务即是一个函数，至于这个函数是在前端实现，或者是在后端很远的地方实现，开发者都可以不用关心。所以说，severless打破了物理隔离。开发者不再去做任何隔离中间层的事前，我只需要关心函数的实现就可以了，函数也是用我的前端代码来写，所以达到了充分融合的定义。 回过来看具体的实现场景，比如云开发，整个小程序的前后端逻辑都能在一个IDE里面完成，用户其实完全不用担心哪些是服务器的逻辑，他们都去向了哪里，只需要像前端函数一样去理解就可以了。云函数现在也支持了本地调试，就像前端代码一样调试，所以可以做真正的前端全栈技术开发，这对现有的开发模式是一个很大的革新。 四、 小程序云服务的发展优化 那么，在大前端技术发展的这波浪潮里面，小程序云服务又有什么样的发展呢？ 早在2017年初小程序正式发布的时候，第一代腾讯云小程序云服务就已经诞生了，但随着8月份全面向个人开发者开放，我们发现这套支服务还是有一定门槛的。于是就开始着手去做更深度的云服务整合和优化，才有了后来的wafer2 和现在的云开发。 [图片] 早期第一代产品 Wafer 的整个开发部署流程，统计了一下大概需要十几步，对许多中长尾的客户来说并不是那么友好。于是我们开始着手优化。 **通过整个优化，可以简略成四步。**第一步是通过一键的配置购买就能把云开发产品开通起来，第二步是工程师进行小程序的前后台开发，第三步进行代码的预览上传，测试体验完，最后便是发布。经过我们这一两年的努力，小程序开发的流程已经由十几步简化到四步了。目前如果从市面上来看，我们这个产品在用户体验以及流程简化度上，在行业内是较为领先的。 [图片] [图片] [图片] 那么，我们腾讯云团队和微信团队如何一步一步优化我们的产品，将产品的接入门槛降低、流程变简的呢？ [图片] 最初我们看到的是可以将 devops 的部份环节给优化一下，包括代码上传部署。这就催生了后来的Wafer 2，亦即第二代的小程序云服务产品。 另外开通购买步骤也是比较繁琐的。将腾讯云和小程序的账号打通后，可以做到一键授权并且开通环境与服务，并且我们提供了一个免费的开发环境，这样可以让更多开发者在进来发布小程序之前，可以以更低的成本门槛用上云开发。 剩下还可以优化的就只有 SDK 引入和填写配置的环节了。 SDK 其实可以采用内置的方式，毕竟小程序的前端接口也是直接内置到运行环境的 webview里面的。但是配置这块并不太好做了。因为一直以来，小程序前端和后台的开发都是割裂的，因此整个用户的鉴权机制都是交由小程序开发者自己去处理。但为什么小程序与云服务一定是要割裂的呢，为什么不能整合到一起呢？而 Serverless 这种开发模式是前后端紧密结合的最佳粘合剂。 一般而言，请求从小程序侧发起，到云服务的后台逻辑进行鉴权处理，如果鉴权成功再调用微信公开发 API，然后再把数据返回到小程序。 [图片] 但我们稍微将整个请求链路改变一下，小程序侧的请求先通过微信的服务，认证并鉴权成功之后，再到腾讯云这边的 Serverless 服务进行逻辑的处理，处理完毕后再返回到小程序侧。这样，我们把整个配置和鉴权服务都帮用户完成了，这又大大减轻了开发者的负担。 [图片] 通过介绍整个小程序云服务的优化历程，相信大家能感悟到整个产品的理念，就是希望一方面云能力逐步成为小程序开发的基础能力，另一方面也希望尽量减少开发者需要理解的概念。 五、 从前端开发到全栈开发 在云开发模式的推动下，我们开发模式是怎么一步步走到现在的开发模式的？ 在Web刚出现的时候，后台开发本就是大包大揽，后台逻辑完成后，再把模板和数据吐出来到浏览器渲染。当时基本上都是做一些比较简单的Web应用。但是当时没有人会吐槽你的后台工程师只有一个人，怎么都把后台和前端服务都干完了，可能当时的业务逻辑并不是很复杂，前端技术也不是那么的规范化，应用场景不是那么多，所以才出现这样的情况。 可是到后来，随着浏览器逐步发展，JS、CSS、HTML有一个规范委员会帮它每年制定一些新的特性。而且随着业务场景越来越复杂，这种情况下开始提出前后端分离，开始要求后台和前端是分开两个人做事情，前后两端是通过API的请求和返回去做一个数据交互。 再到了2008年的时候，乔老爷子凭一己之力开启了移动端的开发生态。到了2017年张小龙大神也跟微信团队推出了小程序且打造了小程序生态。这个时候很多专家提出了“大前端”的概念，希望只写一份代码，就是编译并完成不同客户端的业务，这些端只需要共享一个后台服务就可以了。 这个时代国外出现了一些跨端方案，比如React Native，国内也涌现了 Taro， Omi 等优秀的跨端方案。这几个时期的前端职能是有明显扩张的。 [图片] 只做了大前端完全满足不了前端的野心，随着Node.js的发展，有一些中台的服务，比如同构渲染和业务接口但逐步转给Node.js 来做。后台的同事开始专注于去写一些后台的调度服务或者优化整个数据的读取性能。这个时期，前端开发者也开始从前端逐步往后台做一个拓展。 [图片] 但大前端的步伐远远不只于此，在很多业务场景里面，前端工程师比较贴近客户，所以他更能够去理解到一些业务逻辑，无论是业务的前台或是后台，交给前端工程师来做是更好的。举个例子，云开发的其中一个客户是唯品会的前端团队。他们其中有个业务需要依靠后台来支持，但他们的后台人力很紧缺没有办法马上投入支持。于是他们的前端就借助云开发，投入1个前端工程师就迅速把这个业务给做完上线了。其实许多公司的业务都有类似的情况，公司业务发展非常快，但有的时候要前端等待后台的人力，这样就影响到整个公司的业务发展。 [图片] 可是前端的全栈开发的模式，从前端到后台，把所有的业务全都写完了，其实你会发现又回到我们最初的一个工程师大包大揽的做事情。可是这个业务是复杂的，如果没有一个工具或者一个云的基建设施去支撑这个梦想的话，其实是完全不能实现的。 面对这样的挑战，我们应该怎么答复我们的老板呢？ 腾讯云目前提供的解决方案就是云开发。 [图片] 传统开发模式会让前端变成大包大揽地做业务，其实是相当困难的，因为一方面要开发前端和后端的逻辑，还要处理所有的运维的事情，靠一个人是不可能的，所以才有了现在这样的传统分工模式，就是前端、后台、运维。如果把这个业务用上云开发的话，我们主要关心的只有一小部分，主要都是我们的业务逻辑。至少只要这个工程师能够懂Node.js，基本上就可以把服务稳定、性能卓越和有一定安全性的小程序应用独立开发出来。 云开发的开发模式真正可以实现前端工程师全栈开发的理想模式。