项目背景

IM聊天功能作为整个产品业务功能的补充和重要支撑，相信很多的App都会集成这么一个业务功能在，很多App的的IM功能相信都是集成的第三方提供的的SDK服务。

相信作为产品业务的有力支撑，IM的消息对于各个公司来说都有不同的业务需求，也就是说普通的图片、文字、红包甚至语音这种常用的消息类型并不能有力支撑起一个IM的业务，今天说的这个的IM业务功能正式在这种背景下。

曾经接手了一个IM模块业务功能，刚开始是起因于解决线上的一个bug，于是开始梳理了一下代码逻辑，于是。。。懵逼了好久好久好久。 虽然IM的代码已经在线上跑了很久了，在我开始解决bug之前貌似有大概有大半年将近一年的的时间少有人来维护，从架构设计上、业务代码实现等点来看，可维护性不高。

梳理代码

这个IM的架构设计大概是在几年以前，长连接协议使用的是WebSocket，业务逻辑有一些复杂，目测从数据逻辑到业务逻辑再到UI逻辑，代码量可能会接近5w这个量级，所以说一开始就一行一行的看代码逻辑显然是不太理智的。

梳理第一步

第一步的主要目的是熟悉代码的主要脉络，于是我开始有序的梳理沿着数据流向梳理主干，要点如下：

• 分析各个数据模型（model）。
• 整理各个HTTP请求的API。
• 整理并备注各个Notification的Key，并标记使用场景。
• 整理各个Delegate回调函数的使用场景。
• 整理并备注各个枚举值的含义以及使用场景。

因为此部分项目代码开发周期很久了且开发维护人员换了好几茬之后，代码量大且逻辑比较混乱，在一开始梳理的时候大部分时间都花在了备注各种代码上。

梳理第二步

第一步之后，我其实已经对于IM的架构逻辑开始有了一个初步的比较宽泛的了解。第二步的的主要目的是整理在使用的主要的几个组件：

• 数据库的初始化创建以及使用逻辑。
• HTTP代码的初始化创建以及使用逻辑。
• 长连接代码的初始化创建以及使用逻辑，特别是与服务端沟通和保活的部分。
• 针对以上基础控件的二次封装控件的整理。

梳理了上面几个之后，我陆续整理了如下：

• 数据库的表结构设计、初始化创建以及销毁等逻辑。
• 了解HTTP的接口功能，进一步了解了基础的业务设计。
• 通过和服务端的同事沟通，明确了在当前的长连接协议下，两端是如何保活、沟通数据以及沟通各种状态的。
• 各个API的使用场景以及使用逻辑。

梳理第三步

上面两步，基本上把最核心的工具整理完成，下面就开始将代码逻辑串起来，整理业务逻辑：

• 群聊的收发消息逻辑。
• 私聊的收发消息逻辑。
• 登录、退出登录、更换账号登录以及绑定账号之后的业务逻辑。
• 自后台唤醒之后重连以及获取最新消息等的业务逻辑。
• 收到推送消息之后的业务逻辑。

整理好了以上之后，我利用流程图工具ProcessOn创建了大概有10张左右的流程表，数据流向和业务逻辑一清二楚。

特别是聊天的数据流转逻辑，从HTTP请求、长连接推送以及数据库操作，无所不包。但是图整理完之后，对于主要流程几乎是掌握的比较清楚了，即使回头有忘记的，回头查看表之后就会一清二楚，不仅便于我熟悉逻辑，对以后的维护也很有益处。

维护

遇到的困境

虽然代码质量较差，但是代码中的bug还算比较少，所以在解决线上bug这个问题上，没有遇到过多的麻烦。但是其中也有几个bug十分麻烦，找了好久才找到问题的原因。

其中有一个，找原因大概找了一周多的时间，最后定位问题在我们的账号系统上。因为历史原因，我们的IM业务和其他业务是两套账号体系，中间经历过一次账号变更，但是由于某些奇葩的原因（有部分业务经历了hack），导致部分用户的账号没有成功的过渡账号变更，导致了一些问题。

表象原因是代码逻辑混乱，bug原因复杂，无法复现并难以定位问题。 但更深的原因是时间久远，我们对当时的代码设计以及业务逻辑变更没有记录，且逻辑上存在缺陷，导致无法快速定位到问题的原因。

思考

对于一个逻辑复杂的业务，首先要考虑的是易拓展、易维护和模块组件间的高度解耦。

对于一个成熟的业务来说，我认为易于维护性更为重要，因为业务已经进入成熟阶段的话就意味着大块功能增加的几率比较低，那么对于线上bug修复、小修小补的功能上的优化就是主要工作。

当前的这个IM业务就是这样的，大家看梳理的代码的第一步应该能看出来，我耗费了大量的时间去做各种备注，然而，这些重要节点的备注应该在开发阶段就应该写好了。包括对于之前两套账号系统存在的原因，包括变更一次账号的原因，是否需要有一个详细的记录？

那么对于这种这种有助于后期维护的记录，我认为我们需要对重要的业务变更以及业务设计要有一个详细的记录，无论是自己作为记录还是为后面接手的同学做个参考，我认为都是极为重要的。

重构

思索需求

经过最开始的了解和一段时间维护，我发现遇到的最大麻烦是数据逻辑、业务逻辑、和UI操作逻辑混到了一起，简直可以说是牵一发而动全身。特别是数据逻辑十分混乱，因为数据逻辑的混乱，导致我对于后面业务逻辑的变更十分费力，测试成本也是指数级上涨，另外UI逻辑杂乱，适配iPhone X的时候也遇到了一些小麻烦。

现在的架构设计的原因是什么？这样设计业务需求是否合理？是否有优化的空间？

分析现状与判断未来

无论是客户端还是服务端，亦或是两端数据交互上，IM业务的架构设计本身就存在很多问题。因为时间短暂，不太可能一次性解决所有的问题，特别是对于服务端来说，一次性的大规模重构可能性极低。

对于现在来说：

• UI重构是首当其冲的， 在保证现有逻辑的基础上，重新设计UI层的逻辑结构，保证代码的复用性和可扩展性，为了将来有可能的业务升级留足空间。
• 梳理基础组件，比如HTTP、长连接协议和数据库，还有其他的一些工具类，通过封装成组件和组件引用来是他们能从业务逻辑中独立出来。便于独立维护、升级甚至完整替换。
• 将原有的数据操作逻辑从UI逻辑中完整抽离出来，需要达到向下对基础组件要有封装和控制，向上对业务逻辑要有承接，而且依然要做到耦合度尽量的低。
• 因为IM业务在多个App中都存在，功能逻辑上也有非常多的代码重合，所有需要考虑多个项目通用兼容的问题。

架构设计

• 工厂模式
• 瘦Model
• 去model化的Cell
• 项目优先，分离核心业务模块组成pod
• 考虑业务变更可能性，尽可能向上保持API稳定性
• KVO进行反向传值

着手动工

UI层重构

UI层的重构是最先开始的，无论架构怎么变，UI层都是直接面向用户的，直接承载了产品的业务功能实现，所以为了灵活适应业务的升级或变化，给用户一个好用流畅的入口，UI层设计上要尽可能的灵活。耦合尽可能的小，流畅性上要有保证。

重构思路相对简单，重写View和Controller，去除冗余复杂的UI逻辑代码，规范并统一第三方框架使用，封装公用组件，隔离胶水代码，设计灵活的UI结构。

因为IM系统的最主要UI仍然是TableView，所以针对TableView的各种优化就是重中之重，我着重说一下我对于复杂Cell类型的设计方案。

1、共有的组件有很多，比如时间、头像、背景气泡等等，所以说子类继承父类是最基础的方案。

2、弃置Autolayout的UI书写方式，完全用Frame来写UI布局。Cell高度以及内部UI组件的布局和位置，通过异步计算并缓存为LayoutModel，通过这种方式降低计算的重复耗时操作。

3、有的消息类型只是负责展示，但是有的确有相对复杂的业务逻辑，但是为了防止Cell代码的膨胀，采用了瘦Cell的方式分离逻辑，力求使Cell尽量只负责UI的承载和展示，增加helper层处理相关逻辑。

4、因为虽然是相同的一个数据，但是呈现的方式会存才差异化，所以采用瘦Model的形式，通过创建Helper对取到的原始数据进行相对应的加工，直接提供给业务逻辑处理好的数据。在AFNetworking给的Demo中，是一个典型的胖Model的例子，倒不是说他的例子不好，只是随着业务逻辑的复杂以及生数据和熟数据的差异越来越大的时候，胖Mode的代码量会几何级数般的膨胀，所以还是要因地制宜，具体情况具体分析。

5、利用Factory模式分离出关于复杂Cell类型的判断，包括初始化、赋值等。

6、使用KVO取代delegate进行反向传值，用以减少代码耦合。

关于如何保证UI性能以及优化ViewController，可参考我的其他几篇Blog，iOS 性能优化的探索，复杂业务下UIViewController的减负工作

最终结果，第一个完整case的UI层Controller代码，从3000行直接缩减到了1200行，Controller中没有复杂的多方数据处理逻辑，复杂的逻辑判断。只作为UI展示以及接口调用，完全剥离了数据逻辑的处理，所有的处理逻辑由下面的数据逻辑层处理。

数据逻辑层重构

我在分析了业务需求并设计了架构之后，决定重构以自下而上的顺序来进行，于是第一部分就是对于数据逻辑层的重构。步骤如下： 此部分，分为以下三层结构：

1、业务数据逻辑层

2、适配器层（adapter）

3、基础组件服务层（server）

1、业务数据逻辑层

这部分的主要作用是直接受到UI层的调用，负责长连接以及短连接的建立，数据库的初始化操作等。 向上直接承接UI逻辑和业务逻辑，是高度面向业务封装的接口。比如在发送照片消息的时候，只需要将调用API传入Image对象，其他的流程比如说是上传资源以及组成message对象等，则不需要上一层调用和考虑。

所以这一层尽可能的会很薄，不会有特别多的逻辑代码。

2、适配器层（adapter）

这部分的主要工作是承上启下，承接上一层的面向业务的封装，调用下一层基础组件服务层的接口，可以说绝大多数的接口封装都集中在这一层。因为我们有些业务的长连接和短连接的使用上不是很合理，所以我将长短连接都封装到了一个网络服务的类中，此后假如长短连接的业务产生了变化，但仍可以保持向上的接口稳定性。

举个例子说，当推送来一条消息之后，是通过长连接，但是需要收到数据之后在进行AFN的操作完成消息体完整数据的获取，之后要存入数据库并且将是否读取状态设置为NO，当用户读取当前消息之后，将这部分消息还要更新为已读状态。

这部分操作涉及到了所有的组件的操作，但是反馈到最上面一层的时候，大概只是新的消息，并且是完整的消息，然后再刷新UI。所以说，这一层的业务量比较大，几乎是要按照各种标准操作，完整的处理好所有组件的接口。

3、基础组件服务层（server）

这部分基本可以说是基于IM本身的业务特点，对于基础组件的调用封装。 包括：

1、数据库部分，对于IM消息的数据结构，封装的对于数据库的创建，以及增删改查等接口。以及基于业务的一些接口，例如一次性设置当前聊天的所有消息为已读状态等接口。

2、AFN部分，这部分相对来说就很简单了，基本上是依赖于AFN封装的接口，比如获取当前User的详细信息等。

3、长连接部分，包括对于长连接协议的创建连接、断连以及心跳超时上报等操作，也包括了发送消息和收到消息回调等底层操作。

复制代码

拆分之后的Manager层代码量所见到原来的40%左右，于是改名为Session层。

基础组件层的重构以及封装

这部分因为属于公用的基础组件，所以相对来说只是基础组件的比如说AFN以及数据库（FMDB）是整个App的组成，所以没什么其他的操作，只是单纯做了一层逻辑上分层。

但是对于长连接我们做了一些定制，比如：

1、增加了重连的逻辑机制。

2、增加创建连接以及断掉连接时候各种状态的判断等。

复制代码

主要任务还是集中在对于协议库本身的逻辑补充和健壮性优化等。

其他操作

1、创建枚举文件，扩展标准化的枚举变量。

2、合并以及分割Model，随着业务的扩展，原来的Model设计已经不符合当下的业务发展，根据现在固定的业务，重新设计了Model的集成关系，对于分化严重的也做了重新分割。

3、分离并封装了胶水代码到一个大的工具类，便于调用和调试。

走过的弯路

1、过度思考代码解耦合而忽略了业务逻辑复杂性，错将组件化各组件的解耦合的逻辑应用在了本来就是高耦合的MVC架构上。尝试使用去model化的Cell，但是实际操作环节发现增加了大量的逻辑判断，无形中将Model本该处理的业务逻辑转接到Controller和View上，表面上看上去API简洁到家，但是上手代码量并不算小，不利于维护。

2、在一开始采用了MVCS的设计重构UI层，简化Controller中对于Model的处理，在Store中进行了主动和被动网络逻辑、本地数据库调用等。但事实上最后通过封装统一入口的方式将数据处理的逻辑全部从UI逻辑层剥离开，下沉到了数据逻辑层，对于UI层来说只需要考虑的是进行了调用获取数据的API操作或者是被动受到了新的数据，不需要考虑数据来自于服务端、Cache还是本地数据库，也不需要考虑后面的逻辑，当然，从另一个角度说仍然是MVCS，只不过Store相对复杂且庞大。

3、对于UI层和下一层的数据沟通，虽然采用了KVO的方式回调，降低了耦合性，但是仍然存在参数复杂的情况下，传递过多的Key的情况，导致解析稍显困难和复杂。

4、Cell的继承，看上去是一个很直观的设计，但是随着重构代码量的增加以及业务变化发现继承过程中会存在很多问题，通过面向协议等方式或许可以解决继承中庞大Api的问题。

总结以及思考

架构设计的时候，一定要预判用户的使用习惯，判断未来的业务导向，尽可能的降低代码侵入性和耦合性。对于性能产生的影响的地方，通过以上几点来设计架构，模块健壮性以及可扩展性是设计之初就要优先考虑到的。

架构设计分层要清晰，API设计要尽可能简洁，避免暴露过多的接口和参数，避免模块之间的紧耦合，UI设计要尽可能灵活。 重构前，需要思考切入点，是从上值下、从下至上，还是模块化抽离。

另

已不再维护这部分业务，部分逻辑全凭记忆整理，如果有疏漏或错误，还请大家海涵。

Refrence

• iOS应用架构谈 开篇
• iOS应用架构谈 view层的组织和调用方案
• 去model化和数据对象

问题

• 碰到一个问题，就是做一个点击后添加动画效果，连续点击则有多个动画效果按顺序执行，通过自定Operation,以队列实现，但是发现每次点击玩上次动画效果还没完全执行完点击之后的动画就出来，不符合需求。


• 后来查资料得知自定义Operation中有两个属性分别表示任务是否在执行以及是否执行完毕，如下

@property (readonly, getter=isExecuting) BOOL executing;

@property (readonly, getter=isFinished) BOOL finished;

复制代码

因此在自定义Operation时设置这两个属性，同时在完全当前队列中任务时给予标识表明任务完成，具体代码如下

• CustomOperation 类

@interface CustomOperation : NSOperation



@end

#import "CustomOperation.h"



@interface CustomOperation ()



@property(nonatomic,readwrite,getter=isExecuting)BOOL executing; // 表示任务是否正在执行

@property(nonatomic,readwrite,getter=isFinished)BOOL finished; // 表示任务是否结束



@end



@implementation CustomOperation



@synthesize executing = _executing;

@synthesize finished = _finished;



- (void)start

{

    @autoreleasepool {

        self.executing = YES;

        if (self.cancelled) {

            [self done];

            return;

        }

        // 执行任务

        __weak typeof(self) weakSelf = self;

        dispatch_time_t delayTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3.0 * NSEC_PER_SEC));

        dispatch_after(delayTime, dispatch_get_main_queue(), ^{

            NSLog(@"动画完毕");

            // 任务执行完毕手动关闭

            [weakSelf done];

        });

    }

}



-(void)done

{

    self.finished = YES;

    self.executing = NO;

}



#pragma mark - setter -- getter

// 监听并设置executing

- (void)setExecuting:(BOOL)executing

{

    [self willChangeValueForKey:@"isExecuting"];

    _executing = executing;

    [self didChangeValueForKey:@"isExecuting"];

}



- (BOOL)isExecuting

{

    return _executing;

}



// 监听并设置finished

- (void)setFinished:(BOOL)finished

{

    if (_finished != finished) {

        [self willChangeValueForKey:@"isFinished"];

        _finished = finished;

        [self didChangeValueForKey:@"isFinished"];

    }

}



- (BOOL)isFinished

{

    return _finished;

}



// 返回YES 标识并发Operation

- (BOOL)isAsynchronous

{

    return YES;

}



@end

• swift版

class AnimationOperation: Operation {



    var animationView:AnimationView? // 动画view

    var superView:UIView? // 父视图

    var finishCallBack:(()->())? // 完成动画的回调



    override var isExecuting: Bool {

        return operationExecuting

    }



    override var isFinished: Bool {

        return operationFinished

    }



    override var isAsynchronous: Bool {

        return true

    }

    // 监听

    private var operationFinished:Bool = false {

        willSet {

            willChangeValue(forKey: "isFinished")

        }

        didSet {

            didChangeValue(forKey: "isFinished")

        }

    }



    private var operationExecuting:Bool = false {

        willSet {

            willChangeValue(forKey: "isExecuting")

        }

        didSet {

            didChangeValue(forKey: "isExecuting")

        }

    }

    

    // 每次点击添加动画队列

    class func addOperationShowAnimationView(animationView:AnimationView,superView:UIView) -> AnimationOperation {



        let operation = AnimationOperation()

        operation.animationView = animationView

        operation.superView = superView

        return operation

    }



    override func start() {

        self.operationExecuting = true

        if isCancelled == true {

            self.done()

            return

        }



        guard let superView = self.superView,

              let subView = self.animationView,

              let callback = self.finishCallBack else {

            print("superView == nil")

            return

        }

        

        OperationQueue.main.addOperation {[weak self] in

            superView.addSubview(subView)

            subView.finishCallBack = {

                self?.done()

                callback()

            }

            subView.showAnimation()

        }

    }



    



    private func done() {

        self.operationFinished = true

        self.operationExecuting = false

    }



}

在进入正题之前, 让我们先回顾下前端模块从无到有的一个简短历史

如果你有一定的工作经验, 并且经历过 jQuery 那样的年代, 应该了解早期的前端模块, 只是 window 上的一个局部变量.

在最初的时候前端工程师为了分享自己的代码, 往往会通过 window 来建立联系, 这种古老的做法至今还被很多人使用, 因为简单. 例如我们编写了一个脚本, 通常我们并不认为这是个模块, 但我们会习惯于将这个脚本包装成一个对象. 例如

window.myModule = {

    getName(name){

        return `hello ${name}`

    }

}

当其他人加载这个脚本后, 就可以便捷的通过 window.myModule 来调用 getName 方法.

早期的 JavaScript 脚本主要用于开发一些简单的表单和网页的交互功能, 那个年代的前端工程师数量也极少, 通过 window 来实现模块化并没有什么太大的问题.

直到 ajax 的出现, 将 web 逐步推动到了富客户端的阶段, 随着 spa 的兴起, 前端工程师发现使用 window 模块化代码越来越难以维护, 主要原因有 2 个

1. 大量的模块加载污染了 window, 导致各种命名冲突和意外覆盖, 这些问题还很难定位.


2. 模块和模块之间的交互越来越多, 为了保证调用顺序, 需要人为保障 script 标签的加载顺序

为了解决这个问题, 类似 require seajs 这样的模块 loader 被创造出来, 通过模块 loader, 大大缓解了上述的两个问题.

但前端技术和互联网发展的速度远超我们的想象, 随着网页越来越像一个真实的客户端, 这对前端的工程能力提出了极大的挑战, 仅靠单纯的脚本开发已经难以满足项目的需要, 于是 gulp 等用于前端工程管理的脚手架开始进入我们的视野, 不过在这个阶段, 模块 loader 和前端工程流之间尚未有机的结合.

直到 nodejs 问世, 前端拥有了自己的包管理工具 npm, 在此基础上 Webpack 进一步推动了前端工程流和模块之间的整合, 随后前端模块化的进程开始稳固下来, 一直保持至今.

从这个历史上去回顾, 前端模块化的整个进程包括 es6 关于 module 的标准都是一直围绕这个一个核心命题存在的.

无论是 require 还是 Webpack 在这个核心命题上并没有区别, 即前端模块遵循

加载 → 调用 → 执行 这样的一个逻辑关系. 因为模块必须先加载才能调用并执行, 模块加载器和构建工具就必须管理和分析应用中所有模块的依赖关系, 从而确定哪些模块可以拆分哪些可以合并, 以及模块的加载顺序.

但是随着时间的推移, 前端应用的模块越来越多, 应用越来越庞大, 我们的本地的 node_modules 几百兆起步, Webpack 虽然做了很多优化, 但是 rebuild 的时间在大型应用面前依然显得很慢.

今年 2 月份, Webpack 5 发布了他们的模块拆解方案, 模块联邦, 这个插件解决了 Webpack 构建的模块无法在多个工程中复用的问题.

早些时间 yarn 2.0 采用共享 node_moudles 的方法来解决本地模块大量冗余导致的性能问题.
包括 nodejs 作者在 deno 中放弃了 npm 改用网络化加载模块的方式等等.

可以看到社区已经意识到了先行的前端模块化机制再次面临瓶颈, 无论是性能还是维护成本都面临诸多挑战, 各个团队都在想办法开辟一个新的方向.

不过这些努力依然没有超越先行模块化机制中的核心命题, 即模块必须先加载, 后调用执行.

只要这个核心命题不变, 模块的依赖问题依然是无解的. 为此我们尝试提出了一种新的思路

模块为什么不能先调用, 后加载执行呢?

如果 A 模块调用 B 模块, 但并不需要 B 模块立即就绪, 这就意味着, 模块加载器可以不关心模块的依赖关系, 而致力于只解决模块加载的效率和性能问题.

同时对于构建工具来说, 如果 A 模块的执行并不基于 B 模块立即就绪这件事, 那么构建工具可以放心的将 A 和 B 模块拆成两个文件, 如果模块有很多, 就可以利用 http2 的并行加载能力, 大大提升模块的加载性能.

在我们的设想中, 一种新的模块加载方式是这样的

// remoteModule.js 这是一个发布到 cdn 的远程模块, 内部代码是这样



widnow.rdeco.create({

    name:'remote-module',

    exports:{

        getName(name, next){

            next(`hello ${name}`)

        }

    }

})

让我们先不加载这个模块, 而是直接先执行调用端的代码例如这样

window.rdeco 可以理解成类似 Webpack runtime 一样的存在, 不过 rdeco 是一个独立的库, 其功能远不止于此

// localModule.js 这个是本地的模块

window.rdeco.inject('remote-module').getName('world').then(fullName=>{

    console.log(fullName)

})

然后我们在 html 中先加载 localModule.js 后加载 remoteModule.js

<scirpt src="localModule.js"></script>

<scirpt src="remoteModule.js"></script>

正常理解, localModule.js 加载完之后会试图去调用 remote-module 的 getName 方法, 但此时 remoteModule 尚未加载, 按照先行的模块化机制, 这种调用会抛出异常. 为了避免这个问题

模块构建工具需要分析两个文件的代码, 从而发现 localModule.js 依赖 remoteModule.js, 然后保存这个依赖顺序, 同时通知模块加载器, 为了让代码正常执行, 必须先加载 remoteModule.js.

但如果模块可以先调用后加载, 那么这个复杂的过程就可以完全避免. 目前我们实现了这一机制, 可以看下这个 demo: codesandbox.io/s/tender-ar…

你可试着先点击 Call remote module's getName method 按钮,

此时文案不会变化只是显示 hello, 但代码并不会抛出异常, 然后你再点击 Load remote module 按钮, 开始加载 remoteModule, 等待加载完成, getName 才会真实执行, 此时文案变成了 hello world

 前言

最近真是彻底爱上了 CSS ，我又又又被 CSS 惊艳到了，明明是简单的属性，为啥大佬们稍微一组合，就能形成如此好看的效果啊。本文

给大家带来的是随机不规则圆角头像效果，我们可以把这个效果用于一些人物的展示页面

学习本文章,你可以学到:

• border-radius 实现椭圆效果
• border-radius 实现不规则圆角头像
• animation-delay 设置负值
• 实现随机不规则圆角

📃 预备知识

🎨 border-radius

border-radius 可以设置外边框的圆角。比如我们经常使用的 border-radius: 50% 可以得到一个圆形头像。

但 border-radius 就只能实现圆形效果吗？当然不是，当使用一个半径是确定圆形，两个半径时则会确定椭圆形。

光说不练假把式，接下来一起试试

1. 设置 border-radius: 30% 70%，就可以得到椭圆效果

上面的设置都是针对于四个方向的，也可以只设置一个方向的圆角

2. 设置 border-top-left-radius: 30% 70%

从上图其实可以得出，两个值分别设置水平半径和垂直半径的半径，为了更准确我们验证一下

但为啥设置的圆角与 border-radius: 30% 70% 设置有这么大的差距。别急，下面慢慢道来。

3. 设置 border-radius: 30%/70%，/ 前后的值分别为水平半径和垂直半径

border-radius: 30%/70% 相当于给四个方向都设置 30%/70%，而 border-radius: 30% 70% 是给左上右下设置 30% ，左下右上设置 70%

4. 设置四个方向为四种椭圆角: border-radius: 40% 60% 60% 40% / 60% 30% 70% 40% ，就可以实现简单的不规则圆角效果，小改改的头像是不是看起来舒服了好多。

💞 animation-delay

animation-delay: 可以定义动画播放的延迟时间。

但如果给 animation-delay 设置负值会发生什么那？

MDN 中指出: 定义一个负值会让动画立即开始。但是动画会从它的动画序列中某位置开始。例如，如果设定值为 -1s ，动画会从它的动画序列的第 1 秒位置处立即开始。

那个，乍看上去，我好像懂了，又好像没懂，咱们还是来自己试一下吧。

• 创建 div 块，宽高都为 0 ，背景设置为 #000


• 添加 keyframe 动画，100% 状态宽高都扩展为 1000px

@keyframes extend {

    0% {

        width: 0;

        height: 0;

    }

    100% {

        width: 1000px;

        height: 1000px;

    }

}

• 给 div 添加 animation 和 animation-delay

/* 设置 paused 可以使动画暂停 */

animation: extend 10s linear paused;

animation-delay: -3s;

当我打开浏览器时，浏览器出现 300*300 的黑色块，修改 animation-delay 为 -4s ，浏览器出现 400*400 的黑块。我们使用 linear 匀速作为动画播放函数，10s 后 div 会变为 1000px，设置 -3s 起始为 300px，-4s 起始为 400px。

这样一对比，我们来把 MDN 的描述翻译一下:
+ animation-delay 设置负值的动画会立即执行
+ 动画起始位置是动画中的一阶段，比如上述案例，定义 10s 的动画，设置 -3s 动画就从 3s 开始执行

🌊 radius 配合 delay 实现

有了上面基础知识的配合，不规则圆角的实现就变得很简单了。

设置 keyframe ，keyframe 的开始与结束为两种不规则圆角，再使用 :nth-child 进行自然随机设置 animation-delay 的负值延迟时间，就可以得到一组风格各异的不规则圆角效果

自然随机的算法非常有意思，效果开创者为了更好、更自然的随机性，选取序列为 2n+1 3n+2 5n+3 7n+4 11+5 ...

1. 设置 keyframe 动画

@keyframes morph {

    0% {

        border-radius: 40% 60% 60% 40% / 60% 30% 70% 40%;

        transform: rotate(-5deg);

    }

    100% {

        border-radius: 40% 60%;

        transform: rotate(5deg);

    }

}

2. 自然随机设置每个头像的 delay

.avatar:nth-child(n) {

    animation-delay: -3.5s;

}

.avatar:nth-child(2n + 1) {

    animation-delay: -1s;

}

.avatar:nth-child(3n + 2) {

    animation-delay: -2s;

}

.avatar:nth-child(5n + 3) {

    animation-delay: -3s;

}

.avatar:nth-child(7n + 5) {

    animation-delay: -4s;

}

.avatar:nth-child(11n + 7) {

    animation-delay: -5s;

}

当当当当~~~ 效果就实现了! 看着下面这些风格各异的小改改，瞬间心情舒畅了好多。

不规则圆角头像的功能实现了，但总感觉缺点什么？如果头像能有点动态效果就更好了。

例如 hover 时，头像圆角会发生变化，用户的体验会更好。

我首先的想法还是在上面的代码基础上面更改，但由于 @keyframe 定义好了终点时的状态，能变化的效果并不多，而且看起来很单调，显得很呆 🤣。

那有没有好的实现方案那？有，最终我找到了张鑫旭大佬的实现方案，大佬还是大佬啊。

🌟 radius 配合 transition 实现

参考博客: “蝉原则”与CSS3随机多背景随机圆角等效果

1. 按照自然随机给每个头像赋予不同的不规则圆角

/* 举两个例子 */

.list:hover {

  border-radius: 95% 70% 100% 80%;

  transform: rotate(-2deg);

}

.list:nth-child(2n+1) {

  border-radius: 59% 52% 56% 59%;

  transform: rotate(-6deg);

}

2. 设置 hover 时新的不规则圆角

.list:nth-child(2n+1):hover {

  border-radius: 51% 67% 56% 64%;

  transform: rotate(-4deg);

}



.list:nth-child(3n+2):hover {

  border-radius: 69% 64% 53% 70%;

  transform: rotate(0deg);

}

3. 给 list 元素配置 transition

完成上面的步骤，我们就可以得到更灵动的小改改头像了。

但这种实现方法相比较于 radius 配合 animation-delay 实现具备一定的难点，需要设计多种好看的不规则圆角效果

🛕 源码仓库

传送门: 随机不规则圆角

Promise 提供了一种优雅的方法来处理 JS 中的异步操作。这也是避免“回调地狱”的解决方案。然而，并没有多少开发人员了解其中的内容。因此，许多人在实践中往往会犯错误。

在本文中，介绍一下使用 promise 时的五个常见错误，希望大家能够避免这些错误。

1.避免 Promise 地狱

通常，Promise是用来避免回调地狱。但滥用它们也会导致 Promise是地狱。

userLogin('user').then(function(user){

    getArticle(user).then(function(articles){

        showArticle(articles).then(function(){

            //Your code goes here...

        });

    });

});

在上面的例子中，我们对 userLogin、getararticle 和 showararticle 嵌套了三个promise。这样复杂性将按代码行比例增长，它可能变得不可读。

为了避免这种情况，我们需要解除代码的嵌套，从第一个 then 中返回 getArticle，然后在第二个 then 中处理它。

userLogin('user')

  .then(getArticle)

  .then(showArticle)

  .then(function(){

       //Your code goes here...

});

2. 在 Promise 中使用 try/catch 块

通常情况下，我们使用 try/catch 块来处理错误。然而，不建议在 Promise 对象中使用try/catch 。

这是因为如果有任何错误，Promise对象会在 catch 内自动处理。

ew Promise((resolve, reject) => {

  try {

    const data = doThis();

    // do something

    resolve();

  } catch (e) {

    reject(e);

  }

})

  .then(data => console.log(data))

  .catch(error => console.log(error));

在上面的例子中，我们在Promise 内使用了 try/catch 块。

但是，Promise本身会在其作用域内捕捉所有的错误（甚至是打字错误），而不需要 try/catch块。它确保在执行过程中抛出的所有异常都被获取并转换为被拒绝的 Promise。

new Promise((resolve, reject) => {

  const data = doThis();

  // do something

  resolve()

})

  .then(data => console.log(data))

  .catch(error => console.log(error));

**注意：**在 Promise 块中使用 .catch() 块是至关重要的。否则，你的测试案例可能会失败，而且应用程序在生产阶段可能会崩溃。

3. 在 Promise 块内使用异步函数

Async/Await 是一种更高级的语法，用于处理同步代码中的多个Promise。当我们在一个函数声明前使用 async 关键字时，它会返回一个 Promise，我们可以使用 await 关键字来停止代码，直到我们正在等待的Promise解决或拒绝。

但是，当你把一个 Async 函数放在一个 Promise 块里面时，会有一些副作用。

假设我们想在Promise 块中做一个异步操作，所以使用了 async 关键字，但，不巧的是我们的代码抛出了一个错误。

这样，即使使用 catch() 块或在 try/catch 块内等待你的Promise，我们也不能立即处理这个错误。请看下面的例子。

// 此代码无法处理错误

new Promise(async () => {

  throw new Error('message');

}).catch(e => console.log(e.message));



(async () => {

  try {

    await new Promise(async () => {

      throw new Error('message');

    });

  } catch (e) {

    console.log(e.message);

  }

})();

当我在Promise块内遇到 async 函数时，我试图将 async 逻辑保持在 Promise 块之外，以保持其同步性。10次中有9次都能成功。

然而，在某些情况下，可能需要一个 async 函数。在这种情况下，也别无选择，只能用try/catch 块来手动管理。

new Promise(async (resolve, reject) => {

  try {

    throw new Error('message');

  } catch (error) {

    reject(error);

  }

}).catch(e => console.log(e.message));





//using async/await

(async () => {

  try {

    await new Promise(async (resolve, reject) => {

      try {

        throw new Error('message');

      } catch (error) {

        reject(error);

      }

    });

  } catch (e) {

    console.log(e.message);

  }

})();

4.在创建 Promise 后立即执行 Promise 块

至于下面的代码片断，如果我们把代码片断放在调用HTTP请求的地方，它就会被立即执行。

const myPromise = new Promise(resolve => {

  // code to make HTTP request

  resolve(result);

});

原因是这段代码被包裹在一个Promise构造函数中。然而，有些人可能会认为只有在执行myPromise 的then方法之后才被触发。

然而，真相并非如此。相反，当一个Promise被创建时，回调被立即执行。

这意味着在建立 myPromise 之后到达下面一行时，HTTP请求很可能已经在运行，或者至少处于调度状态。

Promises 总是急于执行过程。

但是，如果希望以后再执行 Promises，应该怎么做？如果现在不想发出HTTP请求怎么办？是否有什么神奇的机制内置于 Promises 中，使我们能够做到这一点？

答案就是使用函数。函数是一种耗时的机制。只有当开发者明确地用 () 来调用它们时，它们才会执行。简单地定义一个函数还不能让我们得到什么。所以，让 Promise 变得懒惰的最有效方法是将其包裹在一个函数中!

const createMyPromise = () => new Promise(resolve => {

  // HTTP request

  resolve(result);

});

对于HTTP请求，Promise 构造函数和回调函数只有在函数被执行时才会被调用。所以现在我们有一个懒惰的Promise，只有在我们需要的时候才会执行。

5. 不一定使用 Promise.all() 方法

如果你已经工作多年，应该已经知道我在说什么了。如果有许多彼此不相关的 Promise，我们可以同时处理它们。

Promise 是并发的，但如你一个一个地等待它们，会太费时间，Promise.all()可以节省很多时间。

记住，Promise.all() 是我们的朋友

const { promisify } = require('util');

const sleep = promisify(setTimeout);



async function f1() {

  await sleep(1000);

}



async function f2() {

  await sleep(2000);

}



async function f3() {

  await sleep(3000);

}





(async () => {

  console.time('sequential');

  await f1();

  await f2();

  await f3();

  console.timeEnd('sequential');  

})();

上述代码的执行时间约为 6 秒。但如果我们用 Promise.all() 代替它，将减少执行时间。

(async () => {

    console.time('concurrent');

    await Promise.all([f1(), f2(), f3()]);

    console.timeEnd('concurrent'); 

  })();

总结

在这篇文章中，我们讨论了使用 Promise 时常犯的五个错误。然而，可能还有很多简单的问题需要仔细解决。

前言

echarts是一个很强大的图表库，除了我们常见的图表功能，echarts有一个自定义图形的功能，这个功能可以让我们很简单地在画布上绘制一些非常规的图形，基于此，我们来玩一些花哨的。

下面我们来一步步实现他。

1 在坐标系中画一只会动的小鸟

首先实例化一个echart容器，再从网上找一个像素小鸟的图片，将散点图的散点形状，用自定义图片的方式改为小鸟。

const myChart = echarts.init(document.getElementById('main'));

option = {

  series: [

    {

      name: 'bird',

      type: 'scatter',

      symbolSize: 50,

      symbol: 'image://bird.png',

      data: [

        [50, 80]

      ],

      animation: false

    },

  ]

};



myChart.setOption(option);

要让小鸟动起来，就需要给一个向右的速度和向下的加速度，并在每一帧的场景中刷新小鸟的位置。而小鸟向上飞的动作，则可以靠角度的旋转来实现，向上飞的触发条件设置为空格事件。

option = {

  series: [

    {

      xAxis: {

        show: false,

        type: 'value',

        min: 0,

        max: 200,

      },

      yAxis: {

        show: false,

        min: 0,

        max: 100

      },

      name: 'bird',

      type: 'scatter',

      symbolSize: 50,

      symbol: 'image://bird.png',

      data: [

        [50, 80]

      ],

      animation: false

    },

  ]

};



// 设置速度和加速度

let a = 0.05;

let vh = 0;

let vw = 0.5



timer = setInterval(() => {

  // 小鸟位置和仰角调整

  vh = vh - a;

  option.series[0].data[0][1] += vh;

  option.series[0].data[0][0] += vw;

  option.series[0].symbolRotate = option.series[0].symbolRotate ? option.series[0].symbolRotate - 5 : 0;



  // 坐标系范围调整

  option.xAxis.min += vw;

  option.xAxis.max += vw;



  myChart.setOption(option);

}, 25);

效果如下

2 用自定义图形绘制障碍物

echarts自定义系列，渲染逻辑由开发者通过renderItem函数实现。该函数接收两个参数params和api，params包含了当前数据信息和坐标系的信息，api是一些开发者可调用的方法集合，常用的方法有：

• 
  

  api.value(...)，意思是取出 dataItem 中的数值。例如 api.value(0) 表示取出当前 dataItem 中第一个维度的数值。

  
  


• 
  

  api.coord(...)，意思是进行坐标转换计算。例如 var point = api.coord([api.value(0), api.value(1)]) 表示 dataItem 中的数值转换成坐标系上的点。

  
  


• 
  

  api.size(...)， 可以得到坐标系上一段数值范围对应的长度。

  
  


• 
  

  api.style(...)，可以获取到series.itemStyle 中定义的样式信息。

  
  

灵活使用上述api，就可以将用户传入的Data数据转换为自己想要的坐标系上的像素位置。

renderItem函数返回一个echarts中的graphic类，可以多种图形组合成你需要的形状，graphic类型。对于我们游戏中的障碍物只需要使用矩形即可绘制出来，我们使用到下面两个类。

• 
  

  type: group, 组合类，可以将多个图形类组合成一个图形，子类放在children中。

  
  


• 
  

  type: rect， 矩形类，通过定义矩形左上角坐标点，和矩形宽高确定图形。

  
  

// 数据项定义为[x坐标，下方水管上侧y坐标， 上方水管下侧y坐标]

data: [

  [150, 50, 80],

  ...

]



renderItem: function (params, api) {

    // 获取每个水管主体矩形的起始坐标点

    let start1 = api.coord([api.value(0) - 10, api.value(1)]);

    let start2 = api.coord([api.value(0) - 10, 100]);

    // 获取两个水管头矩形的起始坐标点

    let startHead1 = api.coord([api.value(0) - 12, api.value(1)]);

    let startHead2 = api.coord([api.value(0) - 12, api.value(2) + 8])

    // 水管头矩形的宽高

    let headSize = api.size([24, 8])

    // 水管头矩形的宽高

    let rect = api.size([20, api.value(1)]);

    let rect2 = api.size([20, 100 - api.value(2)]);

    // 坐标系配置

    const common = {

        x: params.coordSys.x,

        y: params.coordSys.y,

        width: params.coordSys.width,

        height: params.coordSys.height

    }

    // 水管形状

    const rectShape = echarts.graphic.clipRectByRect(

      {

        x: start1[0],

        y: start1[1],

        width: rect[0],

        height: rect[1]

      },common

    );

    const rectShape2 = echarts.graphic.clipRectByRect(

      {

        x: start2[0],

        y: start2[1],

        width: rect2[0],

        height: rect2[1]

      },

      common

    )



    // 水管头形状

    const rectHeadShape = echarts.graphic.clipRectByRect(

      {

        x: startHead1[0],

        y: startHead1[1],

        width: headSize[0],

        height: headSize[1]

      },common

    );



    const rectHeadShape2 = echarts.graphic.clipRectByRect(

      {

        x: startHead2[0],

        y: startHead2[1],

        width: headSize[0],

        height: headSize[1]

      },common

    );



    // 返回一个group类，由四个矩形组成

    return {

        type: 'group',

        children: [{

            type: 'rect',

            shape: rectShape,

            style: {

              ...api.style(),

              lineWidth: 1,

              stroke: '#000'

            }

        }, {

            type: 'rect',

            shape: rectShape2,

            style: {

              ...api.style(),

              lineWidth: 1,

              stroke: '#000'

            }

        },

        {

            type: 'rect',

            shape: rectHeadShape,

            style: {

              ...api.style(),

              lineWidth: 1,

              stroke: '#000'

            }

        },

        {

            type: 'rect',

            shape: rectHeadShape2,

            style: {

              ...api.style(),

              lineWidth: 1,

              stroke: '#000'

            }

        }]

    };

  },

颜色定义, 我们为了让水管具有光泽使用了echarts的线性渐变色对象。

itemStyle: {

  // 渐变色对象

  color: {

    type: 'linear',

    x: 0,

    y: 0,

    x2: 1,

    y2: 0,

    colorStops: [{

        offset: 0, color: '#ddf38c' // 0% 处的颜色

    }, {

        offset: 1, color: '#587d2a' // 100% 处的颜色

    }],

    global: false // 缺省为 false

  },

  borderWidth: 3

},

另外，用一个for循环一次性随机出多个柱子的数据

function initObstacleData() {

    // 添加minHeight防止空隙太小

    let minHeight = 20;

    let start = 150;

    obstacleData = [];

    for (let index = 0; index < 50; index++) {

      const height = Math.random() * 30 + minHeight;

      const obstacleStart = Math.random() * (90 - minHeight);

      obstacleData.push(

        [

          start + 50 * index,

          obstacleStart,

          obstacleStart + height > 100 ? 100 : obstacleStart + height

        ]

      )

    }

  }

再将背景用游戏图片填充，我们就将整个游戏场景，绘制完成:

3 进行碰撞检测

由于飞行轨迹和障碍物数据都很简单，所以我们可以将碰撞逻辑简化为小鸟图片的正方形中，我们判断右上和右下角是否进入了自定义图形的范围内。

对于特定坐标下的碰撞范围，因为柱子固定每格50坐标值一个，宽度也是固定的，所以，可碰撞的横坐标范围就可以简化为 (x / 50 % 1) < 0.6

在特定范围内，依据Math.floor(x / 50)获取到对应的数据，即可判断出两个边角坐标是否和柱子区域有重叠了。在动画帧中判断，如果重叠了，就停止动画播放，游戏结束。

// centerCoord为散点坐标点

function judgeCollision(centerCoord) {

  if (centerCoord[1] < 0 || centerCoord[1] > 100) {

    return false;

  }

  let coordList = [

    [centerCoord[0] + 15, centerCoord[1] + 1],

    [centerCoord[0] + 15, centerCoord[1] - 1],

  ]



  for (let i = 0; i < 2; i++) {

    const coord = coordList[i];

    const index = coord[0] / 50;

    if (index % 1 < 0.6 && obstacleData[Math.floor(index) - 3]) {

      if (obstacleData[Math.floor(index) - 3][1] > coord[1] || obstacleData[Math.floor(index) - 3][2] < coord[1]) {

        return false;

      }

    }

  }

  return false

}



function initAnimation() {

  // 动画设置

  timer = setInterval(() => {

    // 小鸟速度和仰角调整

    vh = vh - a;

    option.series[0].data[0][1] += vh;

    option.series[0].data[0][0] += vw;

    option.series[0].symbolRotate = option.series[0].symbolRotate ? option.series[0].symbolRotate - 5 : 0;



    // 坐标系范围调整

    option.xAxis.min += vw;

    option.xAxis.max += vw;



    // 碰撞判断

    const result = judgeCollision(option.series[0].data[0])



    if(result) { // 产生碰撞后结束动画

      endAnimation();

    }



    myChart.setOption(option);

  }, 25);

}

总结

echarts提供了强大的图形绘制自定义能力，要使用好这种能力，一定要理解好数据坐标点和像素坐标点之间的转换逻辑，这是将数据具象到画布上的重要一步。

运用好这个功能，再也不怕产品提出奇奇怪怪的图表需求。

介绍

本期将带给大家一个简单的创意加载效果——彩条起伏加载。顾名思义，我们会通过scss来完成，将会制作做7个不同颜色的矩形，按不同的延迟不断的递减然后再反弹，循环往复。寓意是希望各位同学像这个加载动画一样，生活过的多姿多彩。

接下来，我们先来一睹为快吧：

感觉如何，其实这个动画的实现方案有很多，今天就用障眼法去实现它，希望给你打开书写css的新思路。

正文

1.彩条绘制

<div id="app">

    <div class="loading">

        <span>l</span>

        <span>o</span>

        <span>a</span>

        <span>d</span>

        <span>i</span>

        <span>n</span>

        <span>g</span>

    </div>

</div>

结构非常的简单，我们将会在div#app让div.loading居中显示，然后在loading中平分各个距离，渲染不同的颜色。

@import url("https://fonts.googleapis.com/css?family=Baloo+Bhaijaan&display=swap");



#app{

    width: 100%;

    height: 100vh;

    background-color: #fff;

    overflow: hidden;

    display: flex;

    justify-content: center;

    align-items: center;

}



.loading{

    width: 350px;

    height: 120px;

    display: flex;

    overflow: hidden;

    span{

        flex:1;

        height: 100%;

        display: flex;

        align-items: center;

        justify-content: center;

        font-family: cursive;

        font-weight: bold;

        text-transform: uppercase;

        font-family: "Baloo Bhaijaan", cursive;

        color: white;

        font-size: 48px;

        position: relative;

        box-sizing: border-box;

        padding-top: 50px;

        @for $i from 1 through 7 {

            &:nth-child(#{$i}) {

                background: linear-gradient(180deg, hsl($i * 20 , 60%, 50%) 0, hsl($i * 20 , 60%, 90%) 100%);

                box-shadow: inset 0 15px 30px hsl($i * 20 , 60%, 50%);

                text-shadow: 12px 12px 12px hsl($i * 20 , 60%, 30%);

                border-left: 1px solid hsl($i * 20 , 60%, 80%);;

                border-right: 1px solid hsl($i * 20 , 60%, 60%);;

            }

        }

    }

}

为了，美观我们还引入了谷歌的一个字体，居中显示是在div#app用了弹性布局。

#app{

	display: flex;

    justify-content: center;

    align-items: center;

}

这三句话目的就是完成元素在上下左右居中。

另外，我们用scss的一大好处就是体现了出来，遍历十分的方便，即**@for $i from 1 through 7** 这一句就是遍历了七遍，通过$ifrom1through7∗∗这一句就是遍历了七遍，通过i就可以拿到下标，还可以参与运算，我们的颜色值就是通过他配合hsl色盘（HSL即色相、饱和度、亮度）去完成的。当然，色盘有360度，我们只取一部分形成清新的渐变，如果整个色盘都平分的话这几个色值出入还是太大会感觉很脏。

我们发现文字被设置了padding-top: 50px，原因就是一会要完成起伏的动画，上面的部分最先消失，我们为了保证这些字母能显示时间更长一些，就往下移了一些距离。

2.起伏动画

一开始我们说过这个要用障眼法去实现，所以我们这里不改变span的高度或者裁切他。

.loading{

    span{

       	//...

        &::after{

            content: "";

            display: block;

            box-sizing: border-box;

            position: absolute;

            height: 100%;

            top: 0;

            left: -1px;

            right: -1px;

            background: linear-gradient(180deg, white 0, rgb(249, 249, 249) 100%);

            animation: shorten 2.1s infinite ease-out;

        }

        @for $i from 1 through 7 {

                // ...

                &::after{

                    animation-delay: #{ $i * 0.08s};

                }    

            }

        }

    }

}

@keyframes shorten {

    12%  { height: 10px; }

}

看了刚才的scss代码可以发现，我们其实是通过一个绝对定位的伪类去遮挡了他，做了一个障眼法让人感觉他高度改变了，其实不然。

至于动画，就更容易了就只有一句，就是在初期某个阶段让他变化高度到10px，也就是遮挡块变小了，显示的高度就就多了，然后缓缓增大至整块，来完成起伏效果。另外，我依然通过遍历在其伪类中，给他们不同的延迟显得更有层次感。

讲到这里，我们的这个案例就书写完成了

结语

本次通过一个做加载创意动画的案例，向各位同学讲到了css如何弹性居中，scss的遍历，hsl色盘改变色值的方便之处以及障眼法的一种方式，希望大家会喜欢，多多支持哦~

emas_tlog

ali emas tlog

阿里巴巴flutter版本 远程日志 TLog

介绍

远程日志服务提供远程手机日志拉取功能，解决移动App线上异常排查困难的问题。
远程日志服务支持Android/iOS应用类型。

产品架构

1.移动App集成SDK。
2.远程日志服务通过心跳探测识别已安装App的移动终端，并进行日志拉取配置。
3.远程日志服务拉取指定移动终端App的用户日志，并对拉取任务进行管理。
4.远程日志服务查看已从终端设备拉取至控制台的用户日志。

官网地址：官网地址

本项目是根据官方来制作的flutter版本

快速开始

#####flutter配置：

  emas_tlog: ^0.0.1

初始化：

方法的声明：

static void init(String appKey,String appSecret,String rsaPublicKey,

      String appKeyIos,String appSecretIos,String rsaPublicKeyIos,

      {String androidChannel = "line",String userNick = "NoLogin",ApmLogType? type,bool debug = true}){

// xxxxxx

}

方法的调用：

EmasTlog.init("**", "**", "**",

        "**","**","**",

        androidChannel :"HEHE",userNick: "lalala2");

参数说明：
appKey
appSecret
rsaPublicKey
appKeyIos：iOS的emas.appKey
appSecretIos：iOS的emas.appSecret
rsaPublicKeyIos：iOS的appmonitor.tlog.rsaSecret
androidChannel: 渠道 （iOS指定 App Store）
userNick: 用户昵称说明: 默认值NoLogin
type（*日志上传类型，注：iOS若不传，默认是I）
debug（底层运行日志答应）true测试环境开启 false正式环境 关闭(iOS可不传)

*星号标记说明

V：可拉取所有级别的日志。(iOS无此类型)

D：可拉取DEBUG/INFO/WARN/ERROR级别的日志。

I：可拉取INFO/WARN/ERROR级别的日志。

W：可拉取WARN/ERROR级别的日志。

E：可拉取ERROR级别的日志。

日常使用：

方法的声明：

static void init(String appKey,String appSecret,String rsaPublicKey,

      String appKeyIos,String appSecretIos,String rsaPublicKeyIos,

      {String androidChannel = "line",String userNick = "NoLogin",ApmLogType? type,bool debug = true}){

// xxxxx

}



方法的调用：

EmasTlog.log(ApmLogType.I, "tag2_1231231",module: "hehe2_flutter",tag: "tag_hehe2");

EmasTlog.log(ApmLogType.V, "tag2_1231231",module: "hehe2_flutter",tag: "tag_hehe2");

EmasTlog.log(ApmLogType.W, "tag2_1231231",module: "hehe2_flutter",tag: "tag_hehe2");

EmasTlog.log(ApmLogType.E, "tag2_1231231",module: "hehe2_flutter",tag: "tag_hehe2");

EmasTlog.log(ApmLogType.D, "tag2_1231231",module: "hehe2_flutter",tag: "tag_hehe2");

EmasTlog.log(ApmLogType.I, "tag2_1231231",module: "hehe2_flutter",tag: "tag_hehe2");

说明：
module为模块业务，可以为空

    EmasTlog.comment(); 主动上传日志

    EmasTlog.updateNickName(name) 修改用户名（用于登录切换用户）

#####Android配置：
1、在根项目Android目录build.gradle配置如下代码

ext {

    tlog = [

            openUtdid     : true

    ]

}

说明：
如果项目编译期报类似如下错误

Duplicate class com.ta.utdid2.a.a.a found in modules jetified-alicloud-android-utdid-2.5.1-proguard (com.aliyun.ams:alicloud-android-utdid:2.5.1-proguard) and jetified-utdid-1.5.2.1 (com.umeng.umsdk:utdid:1.5.2.1)

则代码需要调整为

ext {

    tlog = [

            openUtdid     : false

    ]

}

配置展示：

ext {

    tlog = [

            openUtdid     : true

    ]

}



buildscript {

    ext.kotlin_version = '1.3.50'

    repositories {

        google()

        jcenter()

    }



    dependencies {

        classpath 'com.android.tools.build:gradle:4.1.0'

        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"

    }

}



allprojects {

    repositories {

        google()

        jcenter()

    }

}

根app AndroidManifest配置：

<manifest **

    xmlns:tools="http://schemas.android.com/tools"

    ** >



   <application

   **

       tools:replace="android:label">

说明需要 配置 tools:replace="android:label"
#####iOS 的配置说明
1、在Flutter项目的iOS端的Podfile中添加如下索引库地址：

# alicloud

source "https://github.com/CocoaPods/Specs.git"

source "https://github.com/aliyun/aliyun-specs.git"

2、在Flutter项目的iOS端的info.plist文件中添加如下代码：

<key>NSAppTransportSecurity</key>

	<dict>

		<key>NSAllowsArbitraryLoads</key>

		<true/>

	</dict>

<key>NSBonjourServices</key>

	<array>

		<string>_dartobservatory._tcp</string>

	</array>

<key>NSLocalNetworkUsageDescription</key>

<string>Main</string>

3、在iOS端项目Build Setting中，将Allow Non-modular Includes In Framework Modules设置为YES

很长一段时间，我都使用Eric Meyer著名的CSS Reset。这是CSS的一个坚实的块，但是在这一点上它有点长。它已经十多年没有更新了，从那时起发生了很多变化！

最近，我一直在使用我自己的自定义CSS重置。它包括我发现的所有小技巧，以改善用户体验和CSS创作体验。

像其他CSS重置一样，在设计/化妆品方面，它是不赞成的。您可以将此重置用于任何项目，无论您想要哪种美学。

在本教程中，我们将介绍我的自定义 CSS 重置。我们将深入研究每个规则，您将了解它的作用以及您可能想要使用它的原因！

CSS 重置

事不宜迟，这里是：

/*

  1. Use a more-intuitive box-sizing model.

*/

*, *::before, *::after {

  box-sizing: border-box;

}

/*

  2. Remove default margin

*/

* {

  margin: 0;

}

/*

  3. Allow percentage-based heights in the application

*/

html, body {

  height: 100%;

}

/*

  Typographic tweaks!

  4. Add accessible line-height

  5. Improve text rendering

*/

body {

  line-height: 1.5;

  -webkit-font-smoothing: antialiased;

}

/*

  6. Improve media defaults

*/

img, picture, video, canvas, svg {

  display: block;

  max-width: 100%;

}

/*

  7. Remove built-in form typography styles

*/

input, button, textarea, select {

  font: inherit;

}

/*

  8. Avoid text overflows

*/

p, h1, h2, h3, h4, h5, h6 {

  overflow-wrap: break-word;

}

/*

  9. Create a root stacking context

*/

#root, #__next {

  isolation: isolate;

}

它相对较短，但是这个小样式表中包含了很多东西。让我们开始吧！

从历史上看，CSS重置的主要目标是确保浏览器之间的一致性，并撤消所有默认样式，从而创建一个空白的石板。我的CSS重置并没有真正做这些事情。

如今，浏览器在布局或间距方面没有巨大的差异。总的来说，浏览器忠实地实现了CSS规范，并且事情的行为符合您的预期。因此，它不再是必要的了。

我也不认为有必要剥离所有浏览器默认值。例如，我可能确实想要设置标签！我总是可以在各个项目风格中做出不同的设计决策，但我认为剥离常识性默认值是没有意义的。<em>``font-style: italic

我的CSS重置可能不符合"CSS重置"的经典定义，但我正在采取这种创造性的自由。

CSS盒子模型

测验！通过可见的粉红色边框进行测量，假设未应用其他 CSS，则在以下方案中元素的宽度是多少？.box

<style>

  .parent {

    width: 200px;

  }

  .box {

    width: 100%;

    border: 2px solid hotpink;

    padding: 20px;

  }

</style>

<div>

  <div></div>

</div>

我们的元素有.因为它的父级是200px宽，所以100%将解析为200px。.box``width: 100%

但是它在哪里应用200px宽度？ 默认情况下，它会将该大小应用于内容框。

如果您不熟悉，"内容框"是框模型中实际保存内容的矩形，位于边框和填充内：

该声明会将 的内容框设置为 200px。填充将添加额外的40px（每侧20px）。边框添加最后一个 4px（每侧 2px）。当我们进行数学计算时，可见的粉红色矩形将是244px宽。width: 100%``.box

当我们尝试将一个 244px 的框塞入一个 200px 宽的父级中时，它会溢出：

这种行为很奇怪，对吧？幸运的是，我们可以通过设置以下规则来更改它：

*, *::before, *::after {

  box-sizing: border-box;

}

应用此规则后，百分比将基于边框进行解析。在上面的示例中，我们的粉红色框将为 200px，内部内容框将缩小到 156px（200px - 40px - 4px）。

在我看来，这是一个必须的规则。 它使CSS更适合使用。

我们使用通配符选择器 （） 将其应用于所有元素和伪元素。与普遍的看法相反，这对性能来说并不坏。*

我在网上看到了一些建议，可以代替这样做：

html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}

 删除默认间距

* {

  margin: 0;

}

浏览器围绕保证金做出常识性的假设。例如，默认情况下，将包含比段落更多的边距。h1

这些假设在文字处理文档的上下文中是合理的，但对于现代 Web 应用程序而言，它们可能不准确。

Margin是一个棘手的魔鬼，而且我经常发现自己希望元素默认情况下没有任何元素。所以我决定全部删除它。🔥

如果/当我确实想为特定标签添加一些边距时，我可以在我的自定义项目样式中执行此操作。通配符选择器 （） 具有极低的特异性，因此很容易覆盖此规则。*

基于百分比的高度

html, body {

  height: 100%;

}

你有没有试过在CSS中使用基于百分比的高度，却发现它似乎没有效果？

下面是一个示例：

元素有，但元素根本不会增长！main``height: 100%

这不起作用，因为在 Flow 布局（CSS 中的主要布局模式）中，并且操作的原则根本不同。元素的宽度是根据其父级计算的，但元素的高度是根据其子元素计算的。height``width

这是一个复杂的主题，远远超出了本文的范围。我计划写一篇关于它的博客文章，但与此同时，你可以在我的CSS课程中了解它，CSS for JavaScript Developers。

作为一个快速演示，在这里我们看到，当我们应用此规则时，我们的元素可以增长：main

如果你使用的是像 React 这样的 JS 框架，你可能还希望向这个规则添加第三个选择器：框架使用的根级元素。

例如，在我的 Next.js 项目中，我按如下方式更新规则：

html, body, #__next {

  height: 100%;

}

为什么不使用vh？

您可能想知道：为什么要在基于百分比的高度上大惊小怪？为什么不改用该装置呢？vh

问题是该单元在移动设备上无法正常工作; 将占用超过100%的屏幕空间，因为移动浏览器在浏览器UI来来去去的地方做那件事。vh``100vh

将来，新的CSS单元将解决这个问题。在此之前，我继续使用基于百分比的高度。

调整行高

body {

  line-height: 1.5;

}

line-height控制段落中每行文本之间的垂直间距。默认值因浏览器而异，但往往在 1.2 左右。

此无单位数字是基于字体大小的比率。它的功能就像设备一样。如果为 1.2，则每行将比元素的字体大小大 20%。em``line-height

问题是：对于那些有阅读障碍的人来说，这些行挤得太紧，使得阅读起来更加困难。WCAG标准规定行高应至少为1.5。

现在，这个数字确实倾向于在标题和其他具有大类型的元素上产生相当大的行：

您可能希望在标题上覆盖此值。我的理解是，WCAG标准适用于"正文"文本，而不是标题。

使用"计算"实现更智能的线高

我一直在尝试一种管理行高的替代方法。在这里：

* {

  line-height: calc(1em + 0.5rem);

}

这是一个非常高级的小片段，它超出了这篇博客文章的范围，但这里有一个快速的解释。

字体平滑，抗锯齿

body {

  -webkit-font-smoothing: antialiased;

}

好吧，所以这个有点争议。

在 MacOS 电脑上，浏览器将默认使用"子像素抗锯齿"。这是一种旨在通过利用每个像素内的 R/G/B 灯使文本更易于阅读的技术。

过去，这被视为可访问性的胜利，因为它提高了文本对比度。您可能已经读过一篇流行的博客文章停止"修复"字体平滑，该帖子主张反对切换到"抗锯齿"。

问题是：那篇文章写于2012年，在高DPI"视网膜"显示时代之前。今天的像素要小得多，肉眼看不见。

像素 LED 的物理排列也发生了变化。如果你在显微镜下看一台现代显示器，你不会再看到R/G/B线的有序网格了。

在2018年发布的MacOS Mojave中 ，Apple在整个操作系统中禁用了子像素抗锯齿。我猜他们意识到它在现代硬件上弊大于利。

令人困惑的是，像Chrome和Safari这样的MacOS浏览器仍然默认使用子像素抗锯齿。我们需要通过设置为 来显式关闭它。-webkit-font-smoothing``antialiased

区别如下：

MacOS 是唯一使用子像素抗锯齿的操作系统，因此此规则对 Windows、Linux 或移动设备没有影响。如果您使用的是 MacOS 电脑，则可以尝试实时渲染：

合理的媒体默认值

img, picture, video, canvas, svg {

  display: block;

  max-width: 100%;

}

所以这里有一件奇怪的事情：图像被认为是"内联"元素。这意味着它们应该在段落的中间使用，例如 或 。<em>``<strong>

这与我大多数时候使用图像的方式不符。通常，我对待图像的方式与处理段落或标题或侧边栏的方式相同;它们是布局元素。

但是，如果我们尝试在布局中使用内联元素，则会发生奇怪的事情。如果您曾经有过一个神秘的4px间隙，不是边距，填充或边框，那么它可能是浏览器添加的"内联魔术空间"。line-height

通过默认设置所有图像，我们回避了整个类别的时髦问题。display: block

我也设置了.这样做是为了防止大图像溢出，如果它们放置在不够宽而无法容纳它们的容器中。max-width: 100%

大多数块级元素会自动增大/缩小以适应其父元素，但媒体元素是特殊的：它们被称为替换元素，并且它们不遵循相同的规则。<img>

如果图像的"本机"大小为 800×600，则该元素的宽度也将为 800px，即使我们将其放入 500px 宽的父级中也是如此。<img>

此规则将防止该图像超出其容器，这对我来说更像是更明智的默认行为。

继承窗体控件的字体

input, button, textarea, select {

  font: inherit;

}

如果我们想避免这种自动缩放行为，输入的字体大小需要至少为1rem / 16px。以下是解决此问题的一种方法：

CSS

input, button, textarea, select {

  font-size: 1rem;

}

这解决了自动变焦问题，但它是创可贴。让我们解决根本原因：表单输入不应该有自己的印刷风格！

CSS

input, button, textarea, select {

  font: inherit;

}

font是一种很少使用的速记，它设置了一堆与字体相关的属性，如 、 和 。通过将其设置为 ，我们指示这些元素与其周围环境中的排版相匹配。font-size``font-weight``font-family``inherit

只要我们不为正文文本选择令人讨厌的小字体大小，就可以同时解决我们所有的问题。🎉

自动换行

CSS

p, h1, h2, h3, h4, h5, h6 {

  overflow-wrap: break-word;

}

在 CSS 中，如果没有足够的空间来容纳一行上的所有字符，文本将自动换行。

默认情况下，该算法将寻找"软包装"机会;这些是算法可以拆分的字符。在英语中，唯一的软包装机会是空格和连字符，但这因语言而异。

如果某行没有任何软换行机会，并且它不合适，则会导致文本溢出：

这可能会导致一些令人讨厌的布局问题。在这里，它添加了一个水平滚动条。在其他情况下，它可能会导致文本与其他元素重叠，或滑到图像/视频后面。

该属性允许我们调整换行算法，并允许它在找不到软换行机会时使用硬换行：overflow-wrap

这两种解决方案都不完美，但至少硬包装不会弄乱布局！

感谢Sophie Alpert提出类似的规则！她建议将其应用于所有元素，这可能是一个好主意，但不是我个人测试过的东西。

您也可以尝试添加属性：hyphens

p {

  overflow-wrap: break-word;

  hyphens: auto;

}

hyphens: auto使用连字符（在支持连字符的语言中）来指示硬换行。这也使得硬包装更加普遍。

如果您有非常窄的文本列，这可能是值得的，但它也可能有点分散注意力。我选择不将其包含在重置中，但值得尝试！

根堆叠上下文