Author: admin

flutter、rn、uni-app比较

转自:DCloud社区 uni-app频道的文章Flutter、RN、uni-app比较

前言

每当我们评估新技术时要问的第一个问题就是“它会给我们的业务和客户带来哪些价值?”,工程师们很容易对闪闪发光的新事物着迷,却经常会忽略这些新事物其实可能对我们的客户没有任何好处,反而只会让现有的工作流程更加复杂。

flutter最近比较热闹,毕竟是Google出品。

但我们不是炒作热点的媒体,也不是忽悠你交学费的培训机构,我们作为实际的跨平台开发者,冷静的分析下这个东东。

flutter是Google为Fuchsia操作系统设计的应用开发方式。

Fuchsia OS要兼容廉价物联网设备,要求对硬件的消耗降低,并且为了避免与oracle的java打官司,Fuchsia 使用了dart语言+flutter界面库的方式。

从设计上来看,这套方案的性能确实够高。dart虽然属于大前端范畴,但dart是和java一样的强类型语言,这让dart虚拟机可以做很多优化,性能方面超出了js。

dart曾经与typescript竞争,谁才是更好的js?但不幸输给了typescript,chrome也放弃了内置dart虚拟机的计划。

不过dart团队没有解散,几年后,他们借助flutter,再次出现在公众面前。

性能分析和写法的对比

flutter作为界面库(注意它只是界面库,dart语言是另一个项目),它唯一要干的事情就是渲染界面。不像HTML5,flutter界面库连视频、定位等都没有,就是一个纯排版引擎,绘制文字、按钮、图片等常用界面控件。

这个排版引擎的特点是简单、高性能。

在3大主流渲染引擎里,webview、react native/weex、flutter,复杂度依次降低,渲染性能依次上升。(uni-app是双渲染引擎,webview和weex都内置了,随便开发者使用切换)

所以我们要清楚,提升性能是有代价的,你究竟想要灵活丰富的css3,还是想要固定flex模式排版,抑或是最简单但高性能的flutter排版?开发便利性和运行性能不可兼得。

同时我们要明白,性能的差别,并不是因为Google的chrome团队、Android团队的技术比同公司的flutter团队差。而是flutter提供的布局写法是被限制过的,解析快,所以渲染快。别忘了webview的排版引擎也是世界级工程师用c写的。

但通过这种方式提升性能的代价,就是布局复杂的界面时,flutter的代码嵌套的让人崩溃。

我们先举个例子,同样的界面,用HTML和flutter如何实现:

<div class="greybox">  
  <div class=

四个决策树让你彻底掌握 HTTP 状态码

你好,我是看山。

众所周知,每一个 HTTP 响应都会带有一个 HTTP 状态码(HTTP Status Code),是用来表示 HTTP 服务器响应状态的代码。它由 RFC 2616 规范定义的,并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918 等规范扩展。作为 web 开发者,平时经常 200、301、302、404、500、503 等。最近正在开发一些对外的接口(公司内部各系统间互相调用的接口,也算是内部 Open API 吧),接口调用失败时需要返回一些状态码,考虑借用 HTTP 状态码的含义,可以让调用方通过状态码就能够大体知道出了什么问题,不用彼此重新约定不熟悉的编码规则,方便沟通及错误定位。自认为想法不错,但是在实际编写中遇到了问题,这个多的状态码该怎么用?就用这个机会好好学习下什么场景用什么状态码,也通过本文记录一下 HTTP 状态码的内容。在本文中借 Michael Kropat 的 《Choosing an HTTP Status Code —

深入理解单例设计模式

一、概述

单例模式是面试中经常会被问到的一个问题,网上有大量的文章介绍单例模式的实现,本文也是参考那些优秀的文章来做一个总结,通过自己在学习过程中的理解进行记录,并补充完善一些内容,一方面巩固自己所学的内容,另一方面希望能对其他同学提供一些帮助。

本文主要从以下几个方面介绍单例模式:

  1. 单例模式是什么
  2. 单例模式的使用场景
  3. 单例模式的优缺点
  4. 单例模式的实现(重点)
  5. 总结

二、单例模式是什么

23 种设计模式可以分为三大类:创建型模式、行为型模式、结构型模式。单例模式属于创建型模式的一种,单例模式是最简单的设计模式之一:单例模式只涉及一个类,确保在系统中一个类只有一个实例,并提供一个全局访问入口。许多时候整个系统只需要拥有一个全局对象,这样有利于我们协调系统整体的行为。

三、单例模式的使用场景

1、 日志类

日志类通常作为单例实现,并在所有应用程序组件中提供全局日志访问点,而无需在每次执行日志操作时创建对象。

2、 配置类

将配置类设计为单例实现,比如在某个服务器程序中,该服务器的配置信息存放在一个文件中,这些配置数据由一个单例对象统一读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息,这种方式简化了在复杂环境下的配置管理。

3、工厂类

假设我们设计了一个带有工厂的应用程序,以在多线程环境中生成带有 ID 的新对象(Acount、Customer、Site、Address 对象)。如果工厂在 2 个不同的线程中被实例化两次,那么 2 个不同的对象可能有 2 个重叠的 id。如果我们将工厂实现为单例,我们就可以避免这个问题,结合抽象工厂或工厂方法和单例设计模式是一种常见的做法。

4、以共享模式访问资源的类

比如网站的计数器,一般也是采用单例模式实现,如果你存在多个计数器,每一个用户的访问都刷新计数器的值,这样的话你的实计数的值是难以同步的。但是如果采用单例模式实现就不会存在这样的问题,而且还可以避免线程安全问题。

5、在Spring中创建的Bean实例默认都是单例模式存在的。

适用场景:

  • 需要生成唯一序列的环境
  • 需要频繁实例化然后销毁的对象。
  • 创建对象时耗时过多或者耗资源过多,但又经常用到的对象。
  • 方便资源相互通信的环境

postman中 form-data、x-www-form-urlencoded、raw、binary的区别

原文地址:http://blog.csdn.net/wangjun5159/article/details/47781443

1、form-data: 

就是http请求中的multipart/form-data,它会将表单的数据处理为一条消息,以标签为单元,用分隔符分开。既可以上传键值对,也可以上传文件。当上传的字段是文件时,会有Content-Type来说明文件类型;content-disposition,用来说明字段的一些信息;

由于有boundary隔离,所以multipart/form-data既可以上传文件,也可以上传键值对,它采用了键值对的方式,所以可以上传多个文件,在springmvc中可以使用MultipartHttpServletRequest接收通过api根据"name"获取不同的键值,也可以通过MulTipartFile数组接收多个文件。

 

 

2、x-www-form-urlencoded:

就是application/x-www-from-urlencoded,会将表单内的数据转换为键值对,&分隔。
当form的action为get时,浏览器用x-www-form-urlencoded的编码方式,将表单数据编码为
(name1=value1&name2=value2…),然后把这个字符串append到url后面,用?分隔,跳转
到这个新的url。
当form的action为post时,浏览器将form数据封装到http body中,然后发送到server。
这个格式不能提交文件。

 

3、raw

可以上传任意格式的文本,可以上传text、json、xml、html等

4、binary

相当于Content-Type:application/octet-stream,从字面意思得知,只可以上传二进制数据,通常用来上传文件,由于没有键值,所以,一次只能上传一个文件。

 

 

multipart/form-data与x-www-form-urlencoded区别

multipart/form-data:既可以上传文件等二进制数据,也可以上传表单键值对,只是最后会转化为一条信息;

x-www-form-urlencoded:只能上传键值对,并且键值对都是间隔分开的。

Laravel框架中使用 Repository 模式

若将数据库逻辑都写在model,会造成model的肥大而难以维护,基于SOLID原则,我们应该使用Repository模式辅助model,将相关的数据库逻辑封装在不同的repository,方便中大型项目的维护。

Version:Laravel 5.1.22


数据库逻辑

在CRUD中,CUD比较稳定,但R的部分则千变万化,大部分的数据库逻辑都在描述R的部分,若将数据库逻辑写在controller或model都不适当,会造成controller与model肥大,造成日后难以维护。

Model

使用repository之后,model仅当成Eloquent class即可,不要包含数据库逻辑,仅保留以下部分:

  • Property:如$table,$fillable…等。
  • Mutator:包括mutator与accessor。
  • Method:relation类的method,如使用hasMany()与belongsTo()。
  • 注释:因为Eloquent会根据数据库字段动态产生property与method,等。若使用Laravel IDE Helper,会直接在model加上@property@method描述model的动态property与method。

User.php

  1. app/User.php
  2. namespace MyBlog;
  3. use Illuminate\Auth\Authenticatable;
  4. use Illuminate\Database\

漫画图解JWT设计单点登录系统

JSON Web Token(JWT)是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。

让我们来假想一下一个场景。在A用户关注了B用户的时候,系统发邮件给B用户,并且附有一个链接“点此关注A用户”。链接的地址可以是这样的

1
https://your.awesome-app.com/make-friend/?from_user=B&target_user=A

上面的URL主要通过URL来描述这个当然这样做有一个弊端,那就是要求用户B用户是一定要先登录的。可不可以简化这个流程,让B用户不用登录就可以完成这个操作。JWT就允许我们做到这点。

JWT的组成

一个JWT实际上就是一个字符串,它由三部分组成,头部载荷签名

载荷(Payload)

我们先将上面的添加好友的操作描述成一个JSON对象。其中添加了一些其他的信息,帮助今后收到这个JWT的服务器理解这个JWT。

1
2
3
4
5
6
7
8
9
{
    "iss": "John Wu JWT",
    "iat": 1441593502

11s到⚡1s,性能优化之首屏加载

全文共6511字/词,阅读大概需要13分钟,太长不看党请直接移步「开始优化」部分直接查看优化手段

背景

前段时间公司服务器网络波动,网站访问变慢,一些性能问题也随之暴露了出来。纷纷反馈在这样的弱网条件下,访问新项目时,加载了近1分钟都没加载出来,而访问其他页面顶多也就30-40s。

在网络恢复后,尝试访问了下页面,无缓存首次打开需要等待近11s的时间,最大的资源达到了3.7M...

在对项目做了一些优化处理后,再次无缓存打开可以发现网页几乎是秒开,平均耗时在1s以内

在这里总结记录一下,基本上都是一些常规可复制的优化手段,希望能为同样想优化网页性能的你提供思路~

优化效果

Network

Slow3G条件下22-25s加载完成

lighthouse

hiper

关于性能优化

在开始之前,我们需要明白一个原则:性能优化的最终目的是提升用户体验
简而言之就是让用户感觉这个网站很「快」(至少不慢hh),这里的「快」有两种,一种是「真的快」一种是「觉得快」

  • 「真的快」:可以客观衡量的指标,像网页访问时间、交互响应时间、跳转页面时间
  • 「觉得快」:用户主观感知的性能,通过视觉引导等手段转移用户对等待时间的关注

做好这两方面都能提升用户对网站的性能评价。

权衡取舍

另外就是软件工程没有银弹,一种优化方案可能适用于大多数项目,但是某些特殊情况下很可能会起反效果。

举个,由于浏览器有单域名下并发请求限制,通常我们会将依赖统一打成一个vendor包(vue-cli默认策略),减少首屏请求数,且依赖不变动的情况下文件指纹不变,可以有效利用304缓存。在依赖不多的情况这么处理确实有助于提升加载速度,但一旦依赖多起来,vendor就会特别的大,在弱网条件下,会严重拖慢页面显示。这显然不是我们想要的,所以我们根据情况会对vendor进行拆分,比如拆分到CDN,或者直接拆分到页面中

因此,我们在做性能优化过程中,必须根据最终能给用户体验带来的提升权衡后做出适合当前项目的选择

指标和目标

目标会影响我们在过程中的决策
指标则用来度量我们的目标

目标

首先我们需要确定目标,根据场景和项目复杂度不同,制定的目标也不同,比如希望比竞品快20%,或者符合标准的"2-5-10"原则等等

这里我定下的目标是

  • 正常网速下,2s内加载完成
  • 弱网下,30s内加载完成

指标

关于指标这块,简单介绍下常见指标

  • FCP(First