注册
环信即时通讯云

环信即时通讯云

单聊、群聊、聊天室...
环信开发文档

环信开发文档

Demo体验

Demo体验

场景Demo,开箱即用
RTE开发者社区

RTE开发者社区

汇聚音视频领域技术干货,分享行业资讯
技术讨论区

技术讨论区

技术交流、答疑
资源下载

资源下载

收集了海量宝藏开发资源
iOS Library

iOS Library

不需要辛辛苦苦的去找轮子, 这里都有
Android Library

Android Library

不需要辛辛苦苦的去找轮子, 这里都有

Android asm加注解实现自动Log打印

Android asm加注解实现自动Log打印前言在Android开发中有时候调试问题要给方法加很多的log,很麻烦,所以结合asm用注解的方式来自动在方法中插入log,这样方便开发时候调试。当然通过asm插入的log应该需要包含方法的参数,方法的返回值,有时...
继续阅读 »

Android asm加注解实现自动Log打印

前言

在Android开发中有时候调试问题要给方法加很多的log,很麻烦,所以结合asm用注解的方式来自动在方法中插入log,这样方便开发时候调试。当然通过asm插入的log应该需要包含方法的参数,方法的返回值,有时候也需要获取对象里面的变量值等。

hanno

_    _
| | | |
| |__| | __ _ _ __ _ __ ___
| __ |/ _` | '_ \| '_ \ / _ \
| | | | (_| | | | | | | | (_) |
|_| |_|\__,_|_| |_|_| |_|\___/
复制代码

通过字节码插件实现注解打印log,注解可以加在类上面,也可以加在方法上面,当加在类上面时会打印全部方法的log,当加在方法上面时打印当前方法的log

使用方法

1、类中全部方法打印log

@HannoLog
class MainActivity : AppCompatActivity() {
// ...
}
复制代码

只要在类上面加上@HannoLog注解就可以在编译的时候给这个类中所有的方法插入log,运行时输出log。

2、给类中的某些方法加log

class MainActivity : AppCompatActivity() {
@HannoLog(level = Log.INFO, enableTime = false,watchField=true)
private fun test(a: Int = 3, b: String = "good"): Int {
return a + 1
}
}
复制代码

通过在方法上面添加注解可以在当前方法中插入log。 3、打印的log

//D/MainActivity: ┌───────────────────────────────────------───────────────────────────────────------
//D/MainActivity: │ method: onCreate(android.os.Bundle)
//D/MainActivity: │ params: [{name='savedInstanceState', value=null}]
//D/MainActivity: │ time: 22ms
//D/MainActivity: │ fields: {name='a', value=3}{name='b', value=false}{name='c', value=ccc}
//D/MainActivity: │ thread: main
//D/MainActivity: └───────────────────────────────────------───────────────────────────────────------
复制代码

其中method是当前方法名,params是方法的参数名和值,time方法的执行时间,fields是当前对象的fields值,thread当前方法执行的线程。

HannoLog参数解释

可以通过level来设置log的级别,level的设置可以调用Log里面的INFO,DEBUG,ERROR等。enableTime用来设置是否打印方法执行的时间,默认是false,如果要打印设置enableTime=true. tagName用于设置log的名称,默认是当前类名,也可以通过这个方法进行设置。

1、level控制log打印的等级,默认是log.d,可以通过@HannoLog(level = Log.INFO)来设置等级,支持Log.DEBUG,Log.ERROR等。

2、enableTime控制是否输出方法的执行时间,默认是false,如果要打印可以通过@HannoLog(enableTime=true)来设置。

3、tagName设置tag的名称,默认是当前类名,也可以通过 @HannoLog(tagName = "test")来设置。

4、watchField用于观察对象中的field值,通过@HannoLog(watchField = true)设置,由于静态方法中不能调用非静态的field所以这个参数在静态方法上统一不生效。

重要的类

1、HannoLog HannoLog是注解类,里面提供了控制参数。对应上面的HannoLog参数解释

/**
*
*
*
* create by 胡汉君
* date 2021/11/10 17:38
* 定义一个注解,用于标注当前方法需要打印log
*/

@Retention(RetentionPolicy.CLASS)
@Target({ElementType.METHOD, ElementType.CONSTRUCTOR, ElementType.TYPE})
public @interface HannoLog {
//定义一下log的级别,默认是3,debug级别
int level() default Log.DEBUG;
/**
* @return 打印方法的运行时间
*/

boolean enableTime() default false;

/**
* @return tag的名称,默认是类名,也可以设置
*/

String tagName() default "";

/**
* @return 是否观察field的值,如果观察就会就拿到对象里面全部的field值
*/

boolean watchField() default false;
}
复制代码

2、HannoExtension

public class HannoExtension {
//控制是否使用Hanno
boolean enable;
//控制是否打印log
boolean openLog = true;

public boolean isEnableModule() {
return enableModule;
}

public void setEnableModule(boolean enableModule) {
this.enableModule = enableModule;
}

//设置这个值为true可以给整个module的方法增加log
boolean enableModule = false;

public boolean isEnable() {
return enable;
}

public boolean isOpenLog() {
return openLog;
}

public void setOpenLog(boolean openLog) {
this.openLog = openLog;
}

public void setEnable(boolean enable) {
this.enable = enable;
}
}
复制代码

HannoExtension提供gradle.build文件是否开启plugin 和打印执行plugin的log 默认情况下添加HannoLog之后会进行asm插装,也可以通过在module的build.gradle文件中添加以下配置使在编译时不执行字节码插装提高编译速度

apply plugin: 'com.hanking.hanno'
hannoExtension{
enable=false
openLog=false
}
复制代码

实现原理

hanno是通过asm字节码插桩方式来实现的。Android项目的编译过程如下图: 在这里插入图片描述 java编译器会将.java类编译生成.class类,asm可以用来修改.class类,通过对.class类的修改就可以达到往已有的类中加入代码的目的。一个.java文件经过Java编译器(javac)编译之后会生成一个.class文件。 在.class文件中,存储的是字节码(ByteCode)数据,如下图所示。 在这里插入图片描述 ASM所的操作对象是是字节码(ByteCode)的类库。ASM处理字节码(ByteCode)数据的流程是这样的:

第一步,将.class文件拆分成多个部分;

第二步,对某一个部分的信息进行修改;

第三步,将多个部分重新组织成一个新的.class文件。

ClassFile

.class文件中,存储的是ByteCode数据。但是,这些ByteCode数据并不是杂乱无章的,而是遵循一定的数据结构。

ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
复制代码

字节码的类库和ClassFile之间关系 在这里插入图片描述

asm的组成

从组成结构上来说,ASM分成两部分,一部分为Core API,另一部分为Tree API。

  • 其中,Core API包括asm.jar、asm-util.jar和asm-commons.jar;
  • 其中,Tree API包括asm-tree.jar和asm-analysis.jar。

在这里插入图片描述

asm中重要的类

  • ClassReader类,负责读取.class文件里的内容,然后拆分成各个不同的部分。
  • ClassVisitor类,负责对.class文件中某一部分里的信息进行修改。
  • ClassWriter类,负责将各个不同的部分重新组合成一个完整的.class文件。

在这里插入图片描述

.class文件 --> ClassReader --> byte[] --> 经过各种转换 --> ClassWriter --> byte[] --> .class文件
复制代码

ClassVisitor类

ClassVisitor是一个抽象类,实现类有ClassWriter类(Core API)和ClassNode类(Tree API)。

public abstract class ClassVisitor {
protected final int api;
protected ClassVisitor cv;
}
复制代码
  • api字段:int类型的数据,指出了当前使用的ASM API版本。
  • cv字段:ClassVisitor类型的数据,它的作用是将多个ClassVisitor串连起来

在这里插入图片描述

classVisitor的方法

visit()、visitField()、visitMethod()和visitEnd()。

visitXxx()方法与ClassFile ClassVisitor的visitXxx()方法与ClassFile之间存在对应关系。在ClassVisitor中定义的visitXxx()方法,并不是凭空产生的,这些方法存在的目的就是为了生成一个合法的.class文件,而这个.class文件要符合ClassFile的结构,所以这些visitXxx()方法与ClassFile的结构密切相关。 1、visit()方法 用于生成类或者接口的定义,如下生成一个为printField的类,因为如果类默认继承的父类是Object类,所以superName是” java/lang/Object “。

cw.visit(52, ACC_PUBLIC + ACC_SUPER, "com/hank/test/PrintField", null, "java/lang/Object", null);
复制代码

2、visitField()方法 对应classFile中的field_info,用于生成对象里面的属性值。通过visitField生成一个属性,如下:

FieldVisitor fv;
{
fv = cw.visitField(ACC_PRIVATE + ACC_FINAL + ACC_STATIC, "a", "I", null, new Integer(2));
fv.visitEnd();
}
复制代码

3、visitMethod()方法 用于生成一个方法,对应classFile中的method_info

ClassWriter类

ClassWriter的父类是ClassVisitor,因此ClassWriter类继承了visit()、visitField()、visitMethod()和visitEnd()等方法。 toByteArray方法 在ClassWriter类当中,提供了一个toByteArray()方法。这个方法的作用是将对visitXxx()的调用转换成byte[],而这些byte[]的内容就遵循ClassFile结构。 在toByteArray()方法的代码当中,通过三个步骤来得到byte[]:

  • 第一步,计算size大小。这个size就是表示byte[]的最终的长度是多少。
  • 第二步,将数据填充到byte[]当中。
  • 第三步,将byte[]数据返回。

3、使用ClassWriter类 使用ClassWriter生成一个Class文件,可以大致分成三个步骤:

  • 第一步,创建ClassWriter对象。
  • 第二步,调用ClassWriter对象的visitXxx()方法。
  • 第三步,调用ClassWriter对象的toByteArray()方法。
import org.objectweb.asm.ClassWriter;

import static org.objectweb.asm.Opcodes.*;

public class GenerateCore {
public static byte[] dump () throws Exception {
// (1) 创建ClassWriter对象
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES);
// (2) 调用visitXxx()方法
cw.visit();
cw.visitField();
cw.visitMethod();
cw.visitEnd(); // 注意,最后要调用visitEnd()方法

// (3) 调用toByteArray()方法
byte[] bytes = cw.toByteArray();
return bytes;
}
}
复制代码

Hanno源码分析

上面已经先回顾一下asm相关的基础知识,下面对hanno源码进行分析。主要针对三个方面:

1、如何在方法中插入Log语句。

2、如何获取对象中的field值。

3、如何获取到方法的参数


原文链接:https://juejin.cn/post/7037369790100406309?utm_source=gold_browser_extension

收起阅读 »

Android - 依赖统一管理

#前言 前段时间自己在搭建组件化框架时候遇到了多人协作 Moudle 版本依赖冲突以及重复导包和同一个包导入不同版本的情况,针对这个问题对依赖统一这块做了一次比较详细的学习和总结 目前Android依赖统一管理的方式有以下几种方式,接下来我们一起慢慢分析一下各...
继续阅读 »

#前言


前段时间自己在搭建组件化框架时候遇到了多人协作 Moudle 版本依赖冲突以及重复导包和同一个包导入不同版本的情况,针对这个问题对依赖统一这块做了一次比较详细的学习和总结


目前Android依赖统一管理的方式有以下几种方式,接下来我们一起慢慢分析一下各种方式优缺点



  1. groovy ext扩展函数(也有称之为:"循环优化")

  2. kotlin+buildSrc

  3. composing builds

  4. catalog

  5. 自定义插件+includeBuild


Groovy ext扩展函数


这种方式可能是大家最开始或者说是比较常见的一种依赖配置方式:
iShot2021-12-02 15.17.09.png


示例代码


然后在项目根build.gradle(即root路径下)


apply from:"config.gradle"


引入的方式有两种一种是循环遍历:


iShot2021-12-03 10.26.55.png


iShot2021-12-03 10.32.12.png


总结:


优点:


1:后续添加依赖不需要改动build.gradle,直接在config.gradle


2:精简了build.gradle的长度


缺点:


1:不支持代码提醒


2:不支持点击跳转


3:多moudle 开发时,不同module的依赖需要ctrl+c/v 导致开发的效率降低


kotlin+buildSrc


buildSrc


The directory buildSrc is treated as an included build. Upon discovery of the directory, Gradle automatically compiles and tests this code and puts it in the classpath of your build script. For multi-project builds there can be only one buildSrc directory, which has to sit in the root project directory. buildSrc should be preferred over script plugins as it is easier to maintain, refactor and test the code.


这是来自gradle官方文档对buildSrc的解释:


当运行 Gradle 时会检查项目中是否存在一个名为 buildSrc 的目录。然后 Gradle 会自动编译并测试这段代码,并将其放入构建脚本的类路径中, 对于多项目构建,只能有一个 buildSrc 目录,该目录必须位于根项目目录中, buildSrc 是 Gradle 项目根目录下的一个目录,它可以包含我们的构建逻辑,与脚本插件相比,buildSrc 应该是首选,因为它更易于维护、重构和测试代码


通过上面的介绍,大家或许对buildsrc 有一定理解了,那么我们就看下他怎么和kotlin一起使用达到项目统一依赖管理的


iShot2021-12-03 13.44.50.png


如上图所示我们首先创建一个名为buildSrc的module,gradle 构建的时候会先检查工程中是否有buildSrc命名的目录然后会自动编译和测试这段代码并写入到构建脚本的类路径中,所以无需在setting.gradle 做任何配置有关buildSrc的配置信息


官方的配置信息


iShot2021-12-03 14.19.27.png


iShot2021-12-03 14.21.33.png


这是我的项目中配置信息


这种方式管理依赖优点和缺点如下:


优点:


1:但这种方式支持IDE,输入代码会有提示,会自动完成,所以非常推荐使用这种方式来管理项目中的依赖包


2:支持 AndroidStudio 单击跳转


缺点:


来自gradle文档


A change in buildSrc causes the whole project to become out-of-date. Thus, when making small incremental changes, the --no-rebuild command-line option is often helpful to get faster feedback. Remember to run a full build regularly or at least when you’re done, though.


更改buildSrc会导致整个项目过时。因此,在进行小的增量更改时,--no-rebuild命令行选项通常有助于获得更快的反馈。不过,请记住定期或至少在完成后运行完整构建。


从官网的解释我们可以得出结论:


buildSrc 是对全局的所有 module 的配置依赖更新会重新构建整个项目,项目越大,重新构建的时间就越长,造成不必要的时间浪费。


阅读到这里我们可能会思考那么有没有一种方式是在部分module 需要修改依赖版本的时候而不会重新构建整个项目的方式呢,探索极致是每一个研发人员毕生所追求的,那么***"includeBuild"***这种方式应运而生


composing builds


那么我们开始一步一步实现这种方式:


1:首先创建一个library 的module <对于使用kotlin 或者 java>就要看自己的比较中意哪种语言喽


iShot2021-12-03 14.46.44.png


2:就是在library 配置插件等信息


apply plugin: 'kotlin'
apply plugin: 'java-gradle-plugin'

buildscript {
repositories {
// https://developer.aliyun.com/mvn/guide
//todo error:"Using insecure protocols with repositories, without explicit opt-in,"
google()
mavenCentral()
maven { url 'https://maven.aliyun.com/repository/public' }
maven { url 'https://maven.aliyun.com/repository/google' }
maven { url 'https://maven.aliyun.com/repository/gradle-plugin' }
}

dependencies {
// 因为使用的 Kotlin 需要需要添加 Kotlin 插件
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.21"
}
}




repositories {
// 需要添加 jcenter 否则会提示找不到 gradlePlugin
repositories {
google()
mavenCentral()
maven { url 'https://maven.aliyun.com/repository/public' }
maven { url 'https://maven.aliyun.com/repository/google' }
maven { url 'https://maven.aliyun.com/repository/gradle-plugin' }
}

}

dependencies {
implementation gradleApi()
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
}


compileKotlin {
kotlinOptions {
jvmTarget = "1.8"
}
}

compileTestKotlin {
kotlinOptions {
jvmTarget = "1.8"
}
}

gradlePlugin{
plugins {
version{
// 在 app 模块需要通过 id 引用这个插件
id = 'com.bimromatic.version.plugin'
// 实现这个插件的类的路径
implementationClass = 'com.bimromatic.plugin.VersionPlugin'
}
}
}
复制代码

3:在项目路径下建立一个在.gradle 配置的类名实现Plugin 这个接口


/*
* Copyright 2009 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.gradle.api;

/**
* <p>A <code>Plugin</code> represents an extension to Gradle. A plugin applies some configuration to a target object.
* Usually, this target object is a {@link org.gradle.api.Project}, but plugins can be applied to any type of
* objects.</p>
*
* @param <T> The type of object which this plugin can configure.
*/
public interface Plugin<T> {
/**
* Apply this plugin to the given target object.
*
* @param target The target object
*/
void apply(T target);
}
复制代码

4:在settings.gradle添加


iShot2021-12-03 15.01.56.png


5:在需要用的地方添加插件名


iShot2021-12-03 15.03.33.png


详细配置请移步我们的项目查看


因为时间的原因,这次项目管理依赖就讲到这里,后续会把google在孵化器期 Catalog统一配置依赖版本 讲解一下,然后我们再把各种依赖管理方式用在编辑器跑一下试试看看那种方式构建速度最快。


如果你们觉得写得不错的随手给我点个关注,后期会持续做移动端技术文章的分享,或者给我的github 点个start 后期会上传一些干货。


对了如果文章中有讲的什么不对的地方咱们评论区见,或者提上你们宝贵的issue

作者:bimromatic
链接:https://juejin.cn/post/7037371592816459806
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

Android实战——RecyclerView条目曝光埋点

一、概要 100行代码实现recyclerview条目曝光埋点设计 二、设计思路 条目露出来一半以上视为该条目曝光。 在rv滚动过程中或者数据变更回调OnGlobalLayoutListener时,将符合条件1的条目记录在曝光列表、上传埋点集合里。 滚动状态...
继续阅读 »

一、概要


100行代码实现recyclerview条目曝光埋点设计


二、设计思路



  1. 条目露出来一半以上视为该条目曝光。

  2. 在rv滚动过程中或者数据变更回调OnGlobalLayoutListener时,将符合条件1的条目记录在曝光列表、上传埋点集合里。

  3. 滚动状态变更和OnGlobalLayoutListener回调时,且列表状态为idle状态,触发上报埋点。


三、容错性



  1. 滑动过快时,视为未曝光

  2. 数据变更时,重新检测曝光

  3. 曝光过的条目,不会重复曝光


四、接入影响



  1. 对业务代码零侵入

  2. 对列表滑动体验无影响


五、代码实现


import android.graphics.Rect
import android.view.View
import androidx.recyclerview.widget.RecyclerView
import java.util.*

class RVItemExposureListener(
private val mRecyclerView: RecyclerView,
private val mExposureListener: IOnExposureListener?
) {
interface IOnExposureListener {
fun onExposure(position: Int)
fun onUpload(exposureList: List<Int>?): Boolean
}

private val mExposureList: MutableList<Int> = ArrayList()
private val mUploadList: MutableList<Int> = ArrayList()
private var mScrollState = 0

var isEnableExposure = true
private var mCheckChildViewExposure = true

private val mViewVisible = Rect()
fun checkChildExposeStatus() {
if (!isEnableExposure) {
return
}
val length = mRecyclerView.childCount
if (length != 0) {
var view: View?
for (i in 0 until length) {
view = mRecyclerView.getChildAt(i)
if (view != null) {
view.getLocalVisibleRect(mViewVisible)
if (mViewVisible.height() > view.height / 2 && mViewVisible.top < mRecyclerView.bottom) {
checkExposure(view)
}
}
}
}
}

private fun checkExposure(childView: View): Boolean {
val position = mRecyclerView.getChildAdapterPosition(childView)
if (position < 0 || mExposureList.contains(position)) {
return false
}
mExposureList.add(position)
mUploadList.add(position)
mExposureListener?.onExposure(position)
return true
}

private fun uploadList() {
if (mScrollState == RecyclerView.SCROLL_STATE_IDLE && mUploadList.size > 0 && mExposureListener != null) {
val success = mExposureListener.onUpload(mUploadList)
if (success) {
mUploadList.clear()
}
}
}

init {
mRecyclerView.viewTreeObserver.addOnGlobalLayoutListener {
if (mRecyclerView.childCount == 0 || !mCheckChildViewExposure) {
return@addOnGlobalLayoutListener
}
checkChildExposeStatus()
uploadList()
mCheckChildViewExposure = false
}
mRecyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
override fun onScrollStateChanged(
recyclerView: RecyclerView,
newState: Int
) {
super.onScrollStateChanged(recyclerView, newState)
mScrollState = newState
uploadList()
}

override fun onScrolled(
recyclerView: RecyclerView,
dx: Int,
dy: Int
) {
super.onScrolled(recyclerView, dx, dy)
if (!isEnableExposure) {
return
}

// 大于50视为滑动过快
if (mScrollState == RecyclerView.SCROLL_STATE_SETTLING && Math.abs(dy) > 50) {
return
}
checkChildExposeStatus()
}
})
}
}


六、使用


RVItemExposureListener(yourRecyclerView, object : RVItemExposureListener.IOnExposureListener {
override fun onExposure(position: Int) {
// 滑动过程中出现的条目
Log.d("exposure-curPosition:", position.toString())
}

override fun onUpload(exposureList: List<Int>?): Boolean {
Log.d("exposure-positionList", exposureList.toString())
// 上报成功后返回true
return true
}

})

作者:callme大帅
链接:https://juejin.cn/post/7037376260787404837
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

使用 Python 程序实现摩斯密码翻译器

算法加密解密执行摩斯密码对照表输出:.--- ..- . .--- .. -. -....- .... .- .. -.-- --- -. --.JUEJIN-HAIYONG.. .-.. --- ...- . -.-- --- ..-I LOVE YOU作...
继续阅读 »

摩斯密码是一种将文本信息作为一系列通断的音调、灯光或咔嗒声传输的方法,无需特殊设备,熟记的小伙伴即可直接翻译。它以电报发明者Samuel F. B. Morse的名字命名。

算法

算法非常简单。英语中的每个字符都被一系列“点”和“破折号”代替,或者有时只是单数的“点”或“破折号”,反之亦然。

加密

  1. 在加密的情况下,我们一次一个地从单词中提取每个字符(如果不是空格),并将其与存储在我们选择的任何数据结构中的相应摩斯密码匹配(如果您使用 python 编码,字典可以变成在这种情况下非常有用)

  2. 将摩斯密码存储在一个变量中,该变量将包含我们编码的字符串,然后我们在包含结果的字符串中添加一个空格。

  3. 在用摩斯密码编码时,我们需要在每个字符之间添加 1 个空格,在每个单词之间添加 2 个连续空格。

  4. 如果字符是空格,则向包含结果的变量添加另一个空格。我们重复这个过程,直到我们遍历整个字符串

解密

  1. 在解密的情况下,我们首先在要解码的字符串末尾添加一个空格(这将在后面解释)。

  2. 现在我们继续从字符串中提取字符,直到我们没有任何空间。

  3. 一旦我们得到一个空格,我们就会在提取的字符序列(或我们的莫尔斯电码)中查找相应的英语字符,并将其添加到将存储结果的变量中。

  4. 请记住,跟踪空间是此解密过程中最重要的部分。一旦我们得到 2 个连续的空格,我们就会向包含解码字符串的变量添加另一个空格。

  5. 字符串末尾的最后一个空格将帮助我们识别莫尔斯电码字符的最后一个序列(因为空格充当提取字符并开始解码它们的检查)。

执行

Python 提供了一种称为字典的数据结构,它以键值对的形式存储信息,这对于实现诸如摩尔斯电码之类的密码非常方便。我们可以将摩斯密码表保存在字典中,其中 (键值对)=>(英文字符-莫尔斯电码) 。明文(英文字符)代替密钥,密文(摩斯密码)形成相应密钥的值。键的值可以从字典中访问,就像我们通过索引访问数组的值一样,反之亦然。

摩斯密码对照表

# 实现摩斯密码翻译器的 Python 程序

'''
VARIABLE KEY
'cipher' -> '存储英文字符串的摩斯翻译形式'
'decipher' -> '存储摩斯字符串的英文翻译形式'
'citext' -> '存储单个字符的摩斯密码'
'i' -> '计算摩斯字符之间的空格'
'message' -> '存储要编码或解码的字符串
'''

# 表示摩斯密码图的字典
MORSE_CODE_DICT = { 'A':'.-', 'B':'-...',
'C':'-.-.', 'D':'-..', 'E':'.',
'F':'..-.', 'G':'--.', 'H':'....',
'I':'..', 'J':'.---', 'K':'-.-',
'L':'.-..', 'M':'--', 'N':'-.',
'O':'---', 'P':'.--.', 'Q':'--.-',
'R':'.-.', 'S':'...', 'T':'-',
'U':'..-', 'V':'...-', 'W':'.--',
'X':'-..-', 'Y':'-.--', 'Z':'--..',
'1':'.----', '2':'..---', '3':'...--',
'4':'....-', '5':'.....', '6':'-....',
'7':'--...', '8':'---..', '9':'----.',
'0':'-----', ', ':'--..--', '.':'.-.-.-',
'?':'..--..', '/':'-..-.', '-':'-....-',
'(':'-.--.', ')':'-.--.-'}

# 根据摩斯密码图对字符串进行加密的函数
def encrypt(message):
cipher = ''
for letter in message:
if letter != ' ':

# 查字典并添加对应的摩斯密码
# 用空格分隔不同字符的摩斯密码
cipher += MORSE_CODE_DICT[letter] + ' '
else:
# 1个空格表示不同的字符
# 2表示不同的词
cipher += ' '

return cipher

# 将字符串从摩斯解密为英文的函数
def decrypt(message):

# 在末尾添加额外空间以访问最后一个摩斯密码
message += ' '

decipher = ''
citext = ''
for letter in message:

# 检查空间
if (letter != ' '):

# 计数器来跟踪空间
i = 0

# 在空格的情况下
citext += letter

# 在空间的情况下
else:
# 如果 i = 1 表示一个新字符
i += 1

# 如果 i = 2 表示一个新词
if i == 2 :

# 添加空格来分隔单词
decipher += ' '
else:

# 使用它们的值访问密钥(加密的反向)
decipher += list(MORSE_CODE_DICT.keys())[list(MORSE_CODE_DICT
.values()).index(citext)]
citext = ''

return decipher

# 硬编码驱动函数来运行程序
def main():
message = "JUEJIN-HAIYONG"
result = encrypt(message.upper())
print (result)

message = ".--- ..- . .--- .. -. -....- .... .- .. -.-- --- -. --."
result = decrypt(message)
print (result)

message = "I LOVE YOU"
result = encrypt(message.upper())
print (result)

message = ".. .-.. --- ...- . -.-- --- ..-"
result = decrypt(message)
print (result)

# 执行主函数
if __name__ == '__main__':
main()

输出:

.--- ..- . .--- .. -. -....- .... .- .. -.-- --- -. --.
JUEJIN-HAIYONG
.. .-.. --- ...- . -.-- --- ..-
I LOVE YOU

作者:海拥
来源:https://juejin.cn/post/6990223674758397960

收起阅读 »

手写一个 ts-node 来深入理解它的原理

当我们用 Typesript 来写 Node.js 的代码,写完代码之后要用 tsc 作编译,之后再用 Node.js 来跑,这样比较麻烦,所以我们会用 ts-node 来直接跑 ts 代码,省去了编译阶段。 有没有觉得很神奇,ts-node 怎么做到的直接跑...
继续阅读 »

当我们用 Typesript 来写 Node.js 的代码,写完代码之后要用 tsc 作编译,之后再用 Node.js 来跑,这样比较麻烦,所以我们会用 ts-node 来直接跑 ts 代码,省去了编译阶段。


有没有觉得很神奇,ts-node 怎么做到的直接跑 ts 代码的?


其实原理并不难,今天我们来实现一个 ts-node 吧。


相关基础

实现 ts-node 需要 3 方面的基础知识:



  • require hook
  • repl 模块、vm 模块
  • ts compiler api

我们先学下这些基础


require hook

Node.js 当 require 一个 js 模块的时候,内部会分别调用 Module.load、 Module._extensions[‘.js’],Module._compile 这三个方法,然后才是执行。


img

同理,ts 模块、json 模块等也是一样的流程,那么我们只需要修改 Module._extensions[扩展名] 的方法,就能达到 hook 的目的:


require.extensions['.ts'] = function(module, filename) {
// 修改代码
module._compile(修改后的代码, filename);
}

比如上面我们注册了 ts 的处理函数,这样当处理 ts 模块时就会调用这个方法,所以我们在这里面做编译就可以了,这就是 ts-node 能够直接执行 ts 的原理。


repl 模块

Node.js 提供了 repl 模块可以创建 Read、Evaluate、Print、Loop 的命令行交互环境,就是那种一问一答的方式。ts-node 也支持 repl 的模式,可以直接写 ts 代码然后执行,原理就是基于 repl 模块做的扩展。


repl 的 api 是这样的: 通过 start 方法来创建一个 repl 的交互,可以指定提示符 prompt,可以自己实现 eval 的处理逻辑:


const repl = require('repl');

const r = repl.start({
prompt: '- . - > ',
eval: myEval
});

function myEval(cmd, context, filename, callback) {
// 对输入的命令做处理
callback(null, 处理后的内容);
}

repl 的执行时有一个上下文的,在这里就是 r.context,我们在这个上下文里执行代码要使用 vm 模块:


const vm = require('vm');

const res = vm.runInContext(要执行的代码, r.context);

这两个模块结合,就可以实现一问一答的命令行交互,而且 ts 的编译也可以放在 eval 的时候做,这样就实现了直接执行 ts 代码。


ts compiler api

ts 的编译我们主要是使用 tsc 的命令行工具,但其实它同样也提供了编译的 api,叫做 ts compiler api。我们做工具的时候就需要直接调用 compiler api 来做编译。


转换 ts 代码为 js 代码的 api 是这个:


const { outputText } = ts.transpileModule(ts代码, {
compilerOptions: {
strict: false,
sourceMap: false,
// 其他编译选项
}
});

当然,ts 也提供了类型检查的 api,因为参数比较多,我们后面一篇文章再做展开,这里只了解 transpileModule 的 api 就够了。


了解了 require hook、repl 和 vm、ts compiler api 这三方面的知识之后,ts-node 的实现原理就呼之欲出了,接下来我们就来实现一下。


实现 ts-node

直接执行的模式

我们可以使用 ts-node + 某个 ts 文件,来直接执行这个 ts 文件,它的原理就是修改了 require hook,也就是 Module._extensions['.ts'] 来实现的。


在 require hook 里面做 ts 的编译,然后后面直接执行编译后的 js,这样就能达到直接执行 ts 文件的效果。


所以我们重写 Module._extensions['.ts'] 方法,在里面读取文件内容,然后调用 ts.transpileModule 来把 ts 转成 js,之后调用 Module._compile 来处理编译后的 js。


这样,我们就可以直接执行 ts 模块了,具体的模块路径是通过命令行参数执行的,可以用 process.argv 来取。


const path = require('path');
const ts = require('typescript');
const fs = require('fs');

const filePath = process.argv[2];

require.extensions['.ts'] = function(module, filename) {
const fileFullPath = path.resolve(__dirname, filename);
const content = fs.readFileSync(fileFullPath, 'utf-8');

const { outputText } = ts.transpileModule(content, {
compilerOptions: require('./tsconfig.json')
});

module._compile(outputText, filename);
}

require(filePath);

我们准备一个这样的 ts 文件 test.ts:


const a = 1;
const b = 2;

function add(a: number, b: number): number {
return a + b;
}

console.log(add(a, b));

然后用这个工具 hook.js 来跑:


img

可以看到,成功的执行了 ts,这就是 ts-node 的原理。


当然,细节的逻辑还有很多,但是最主要的原理就是 require hook + ts compiler api。


repl 模式

ts-node 支持启动一个 repl 的环境,交互式的输入 ts 代码然后执行,它的原理就是基于 Node.js 提供的 repl 模块做的扩展,在自定义的 eval 函数里面做了 ts 的编译,然后使用 vm.runInContext 的 api 在 repl 的上下文中执行 js 代码。


我们也启动一个 repl 的环境,设置提示符和自定义的 eval 实现。


const repl = require('repl');

const r = repl.start({
prompt: '- . - > ',
eval: myEval
});

function myEval(cmd, context, filename, callback) {

}

eval 的实现就是编译 ts 代码为 js,然后用 vm.runInContext 来执行编译后的 js 代码,执行的 context 指定为 repl 的 context:


function myEval(cmd, context, filename, callback) {
const { outputText } = ts.transpileModule(cmd, {
compilerOptions: {
strict: false,
sourceMap: false
}
});
const res = vm.runInContext(outputText, r.context);
callback(null, res);
}

同时,我们还可以对 repl 的 context 做一些扩展,比如注入一个 who 的环境变量:


Object.defineProperty(r.context, 'who', {
configurable: false,
enumerable: true,
value: '神说要有光'
});

我们来测试下效果:


img

可以看到,执行后启动了一个 repl 环境,提示符修改成了 -.- >,可以直接执行 ts 代码,还可以访问全局变量 who。


这就是 ts-node 的 repl 模式的大概原理: repl + vm + ts compiler api。


全部代码如下:


const repl = require('repl');
const ts = require('typescript');
const vm = require('vm');

const r = repl.start({
prompt: '- . - > ',
eval: myEval
});

Object.defineProperty(r.context, 'who', {
configurable: false,
enumerable: true,
value: '神说要有光'
});

function myEval(cmd, context, filename, callback) {
const { outputText } = ts.transpileModule(cmd, {
compilerOptions: {
strict: false,
sourceMap: false
}
});
const res = vm.runInContext(outputText, r.context);
callback(null, res);
}

总结

ts-node 可以直接执行 ts 代码,不需要手动编译,为了深入理解它,我们我们实现了一个简易 ts-node,支持了直接执行和 repl 模式。


直接执行的原理是通过 require hook,也就是 Module._extensions[ext] 里通过 ts compiler api 对代码做转换,之后再执行,这样的效果就是可以直接执行 ts 代码。


repl 的原理是基于 Node.js 的 repl 模块做的扩展,可以定制提示符、上下文、eval 逻辑等,我们在 eval 里用 ts compiler api 做了编译,然后通过 vm.runInContext 在 repl 的 context 中执行编译后的 js。这样的效果就是可以在 repl 里直接执行 ts 代码。


当然,完整的 ts-node 还有很多细节,但是大概的原理我们已经懂了,而且还学到了 require hook、repl 和 vm 模块、 ts compiler api 等知识。


题外话

其实 ts-node 的原理是应一个同学的要求写的,大家有想读的 nodejs 工具的源码也可以告诉我呀(可以加我微信),无偿提供源码带读 + 简易实现的服务,不过会做一些筛选。


img
作者:zxg_神说要有光
来源:https://juejin.cn/post/7036688014206042143

收起阅读 »

前端自动化部署:借助Gitlab CI/CD实现

🛫 前端自动化部署:借助Gitlab CI/CD实现🌏 概论传统的前端部署往往都要经历:本地代码更新 => 本地打包项目 => 清空服务器相应目录 => 上传项目包至相应目录几个阶段,这些都是机械重复的步骤。对于这一过程我们往往可以通过CI/...
继续阅读 »

🛫 前端自动化部署:借助Gitlab CI/CD实现

🌏 概论

传统的前端部署往往都要经历:本地代码更新 => 本地打包项目 => 清空服务器相应目录 => 上传项目包至相应目录几个阶段,这些都是机械重复的步骤。对于这一过程我们往往可以通过CI/CD方法进行优化。所谓CI/CD,即持续集成/持续部署,以上我们所说的步骤便可以看作是持续部署的一种形态,其更详细的解释大家可以自行了解。


JenkinsTravis CI这些都是可以完成持续部署的工具。除此之外,Gitlab CI/CD也能很好的完成这一需求。下面就来详细介绍下。


🌏 核心工具

GitLab Runner

GitLab Runner是配合GitLab CI/CD完成工作的核心程序,出于性能考虑,GitLab Runner应该与Gitlab部署在不同的服务器上(Gitlab在单独的仓库服务器上,GitLab Runner在部署web应用的服务器上)。GitLab Runner在与GitLab关联后,可以在服务器上完成诸如项目拉取、文件打包、资源复制等各种命令操作。


Git

web服务器上需要安装Git来进行远程仓库的获取工作。


Node

用于在web服务器上完成打包工作。


NPM or Yarn or pnpm

用于在web服务器上完成依赖下载等工作(用yarn,pnpm亦可)。


web服务器上的所需程序

🌏 流程

这里我自己用的是centOS环境:


1. 在web服务器上安装所需工具

(1)安装Node


# 下载node包
wget https://nodejs.org/dist/v16.13.0/node-v16.13.0-linux-x64.tar.xz

# 解压Node包
tar -xf node-v16.13.0-linux-x64.tar.xz

# 在配置文件(位置多在/etc/profile)末尾添加:
export PATH=$PATH:/root/node-v16.13.0-linux-x64/bin

# 刷新shell环境:
source /etc/profile

# 查看版本(输出版本号则安装成功):
node -v

#后续安装操作,都可通过-v或者--version来查看是否成功

npm已内置在node中,如要使用yarn或,则可通过npm进行全局安装,命令与我们本地环境下的使用命令是一样的:


npm i yarn -g
#or
npm i pnpm -g

(2)安装Git


# 利用yum安装git
yum -y install git

# 查看git版本
git --version

(3)安装Gitlab Runner


# 安装程序
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# 等待下载完成后分配权限
chmod +x /usr/local/bin/gitlab-runner

# 创建runner用户
useradd --comment 'test' --create-home gitlab-runner --shell /bin/bash

# 安装程序
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

# 启动程序
gitlab-runner start

# 安装完成后可使用gitlab-runner --version查看是否成功

2. 配置Runner及CI/CD

基本的安装操作完成后,就是最核心的阶段:Runner与CI/CD的配置。


(1)配置Gitlab Runner


首先打开待添加自动部署功能的gitlab仓库,在其中设置 > CI/CD > Runner中找到runner配置信息备用:


image.png

在web服务器中配置runner:


gitlab-runner register

>> Enter the GitLab instance URL (for example, https://gitlab.com/):
# 输入刚才获取到的gitlab仓库地址
>> Enter the registration token:
# 输入刚才获取到的token
>> Enter a description for the runner:
# 自定runner描述
>> Enter tags for the runner (comma-separated):
# 自定runner标签
>> Enter an executor: docker-ssh, docker+machine, docker-ssh+machine, docker, parallels, shell, ssh, virtualbox, kubernetes, custom:
# 选择执行器,此处我们输入shell

完整示例:image.png

(2)配置.gitlab-ci.yml


.gitlab-ci.yml文件是流水线执行的流程文件,Runner会据此完成规定的一系列流程。


我们在项目根目录中创建.gitlab-ci.yml文件,然后在其中编写内容:


# 阶段
stages:
- install
- build
- deploy

cache:
paths:
- node_modules/

# 安装依赖
install:
stage: install
# 此处的tags必须填入之前注册时自定的tag
tags:
- deploy
# 规定仅在package.json提交时才触发此阶段
only:
changes:
- package.json
# 执行脚本
script:
yarn

# 打包项目
build:
stage: build
tags:
- deploy
script:
- yarn build
# 将此阶段产物传递至下一阶段
artifacts:
paths:
- dist/

# 部署项目
deploy:
stage: deploy
tags:
- deploy
script:
# 清空网站根目录,目录请根据服务器实际情况填写
- rm -rf /www/wwwroot/stjerne/salary/*
# 复制打包后的文件至网站根目录,目录请根据服务器实际情况填写
- cp -rf ${CI_PROJECT_DIR}/dist/* /www/wwwroot/stjerne/salary/

保存并推送至gitlab后即可自动开始构建部署。


构建中可在gitlab CI/CD面板查看构建进程:


image.png

待流水线JOB完成后可前往页面查看🛫🛫🛫🛫🛫


作者:星始流年
来源:https://juejin.cn/post/7037022688493338661

收起阅读 »

聊一聊线程池和Kotlin协程

目前很多开发组都用上协程来处理异步任务了,但是有的地方协程提供的原生API还是不足以应付,比方说一些SDK提供了传入Executor的接口(以便复用调用者的线程池来执行异步任务),这时候可以用JDK提供的线程池,或者封装一下协程也可以满足需求。 协程提供了Di...
继续阅读 »

目前很多开发组都用上协程来处理异步任务了,但是有的地方协程提供的原生API还是不足以应付,比方说一些SDK提供了传入Executor的接口(以便复用调用者的线程池来执行异步任务),这时候可以用JDK提供的线程池,或者封装一下协程也可以满足需求。


协程提供了Dispatchers.DefaultDispatchers.IO 分别用于 计算密集型 任务和 IO密集型 任务,类似于RxJava的 Schedulers.computation()Schedulers.io()

但两者有所差异,比如RxJava的 Schedulers.io() 不做并发限制,而 Dispatchers.io() 做了并发限制:



It defaults to the limit of 64 threads or the number of cores (whichever is larger)



考虑到当前移动设备的CPU核心数都不超过64,所以可以认为协程的 Dispatchers.IO 的最大并发为64。

Dispatchers.Default 的并发限制为:



By default, the maximal level of parallelism used by this dispatcher is equal to the number of CPU cores, but is at least two



考虑到目前Android设备核心数都在2个以上,所以可以认为 Dispatchers.Default 的最大并发为 CPU cores。

Dispatchers.DefaultDispatchers.IO 是共享协程自己的线程池的,二者可以复用线程。

不过目前这两个Dispatchers 并未完全满足项目中的需求,有时我们需要一些自定义的并发限制,其中最常见的是串行。


RxJava有Schedulers.single() ,但这个Schedulers.single()和AsyncTask的SERAIL_EXECOTOR一样,是全局串行,不同的任务处在同一个串行队列,会相互堵塞,因而可能会引发问题。


或许也是因为这个原因,kotlin协程没有定义“Dispatchers.Single"。

对于需要串行的场景,可以这样实现:


val coroutineContext: CoroutineContext =
Executors.newSingleThreadExecutor().asCoroutineDispatcher()

这样可以实现局部的串行,但和协程的线程池是相互独立的,不能复用线程。

线程池的好处:



  1. 提高响应速度:任务到达时,无需等待线程创建即可立即执行。

  2. 降低资源消耗:通过池化技术重复利用已创建的线程,降低线程创建和销毁造成的损耗。

  3. 提高线程的可管理性:线程是稀缺资源,如果无限制创建,不仅会消耗系统资源,还会因为线程的不合理分布导致资源调度失衡,降低系统的稳定性。使用线程池可以进行统一的分配、调优和监控。


然彼此独立创建线程池的话,会大打折扣。

如何既复用协程的线程池,又自主控制并发呢?

一个办法就是套队列来控制并发,然后还是任务还是执行在线程池之上。

AsyncTask 就是这样实现的:


private static class SerialExecutor implements Executor {
final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();
Runnable mActive;

public synchronized void execute(final Runnable r) {
mTasks.offer(new Runnable() {
public void run() {
try {
r.run();
} finally {
scheduleNext();
}
}
});
if (mActive == null) {
scheduleNext();
}
}

protected synchronized void scheduleNext() {
if ((mActive = mTasks.poll()) != null) {
THREAD_POOL_EXECUTOR.execute(mActive);
}
}
}


用SerialExecutor的execute的任务会先进入队列,当mActive为空时从队列获取任务赋值给mActive然后通过线程池 THREAD_POOL_EXECUTOR执行。

当然AsyncTask 的SerialExecutor是全局唯一的,所以会有上面提到的各种任务相互堵塞的问题。可以通过创建不同是的SerialExecutor实例来达到各业务各自串行。


在Kotlin环境下,我们可以利用协程和Channel来实现:


fun Channel<Any>.runBlock(block: suspend CoroutineScope.() -> Unit) {
CoroutineScope(Dispatchers.Unconfined).launch {
send(0)
CoroutineScope(Dispatchers.IO).launch {
block()
receive()
}
}
}

// 使用方法
private val serialChannel = Channel<Any>(1)
serialChannel.runBlock {
// do somthing
}


添加Log编写测试如下:


private val a = AtomicInteger(0)
private val b = AtomicInteger(0)
fun Channel<Any>.runBlock(block: suspend CoroutineScope.() -> Unit) {
CoroutineScope(Dispatchers.Unconfined).launch {
Log.d("MyTag", "before send " + a.getAndIncrement() + getTime())
send(0)
Log.i("MyTag", "after send " + b.getAndIncrement() + getTime())
CoroutineScope(Dispatchers.Default).launch {
block()
receive()
}
}
}

private fun test() {
// 并发限制为1,串行执行任务
val channel = Channel<Any>(1)
val t1 = System.currentTimeMillis()
repeat(4) { x ->
channel.runBlock {
Thread.sleep(1000L)
Log.w("MyTag", "$x done job" + getTime())
}
}

CoroutineScope(Dispatchers.Default).launch {
while (!channel.isEmpty) {
delay(200)
}
val t2 = System.currentTimeMillis()
Log.d("MyTag", "Jobs all done, use time:" + (t2 - t1))
}
}


执行结果:



第一个任务可以顺利通过send(), 而随后的任务被suspend, 直到前面的任务执行完(执行block),调用recevie(), 然后下一个任务通过send() ……依此类推。

最终,消耗4s完成任务。


如果Channel的参数改成2,则能有两个任务可以通过send() :



最终,消耗2s完成任务。


关于参数可以参考Channel的构造函数:


public fun <E> Channel(capacity: Int = RENDEZVOUS): Channel<E> =
when (capacity) {
RENDEZVOUS -> RendezvousChannel()
UNLIMITED -> LinkedListChannel()
CONFLATED -> ConflatedChannel()
BUFFERED -> ArrayChannel(CHANNEL_DEFAULT_CAPACITY)
else -> ArrayChannel(capacity)
}

在前面的实现中, 我们关注UNLIMITED, BUFFERED 以及 capacity > 0 的情况即可:



  • UNLIMITED: 不做限制;

  • BUFFERED: 并发数由 kotlin "kotlinx.coroutines.channels.defaultBuffer"决定,目前测试得到8;

  • capacity > 0, 则并发数由 capacity 决定;

  • 特别地,当capacity = 1,为串行调度。


不过,[Dispatchers.IO] 本身有并发限制(目前版本是64),

所有对于 Channel.UNLIMITED 和 capacity > 64 的情况,和capacity=64的情况是相同的。

我们可以为不同的业务创建不同的Channel实例,从而各自控制并发且最终在协程的线程池上执行任务。

简要示意图如下:



为了简化,我们假设Dispatchers的并发限制为4。



  • 不同Channel有各自的buffer, 当任务小于capacity时进入buffer, 大于capacity时新任务被suspend。

  • Dispatchers 不断地执行任务然后调用receive(), 上面的实现中,receive并非要取什么信息,仅仅是让channel空出buffer, 好让被suspend的任务可以通过send()然后进入Dispatchers的调度。

  • 极端情况下(进入Disptachers的任务大于并发限制时),任务进入Dispatchers也不会被立即执行,这个设定可以避免开启的线程太多而陷于线程上下文频繁切换的困境。


通过Channel可以实现并发的控制,但是日常开发中有的地方并不是简单地执行个任务,而是需要一个ExecutorService或者Executor。


为此,我们可以实现一个ExecutorService。

当然了,不是直接implement ExecutorService, 而是像ThreadPoolExecutor一样继承AbstractExecutorService, 这样只需要实现几个方法即可。



最终完整代码如下:


fun Channel<Any>.runBlock(block: suspend CoroutineScope.() -> Unit) {
CoroutineScope(Dispatchers.Unconfined).launch {
send(0)
CoroutineScope(Dispatchers.IO).launch {
block()
receive()
}
}
}

class ChannelExecutorService(capacity: Int) : AbstractExecutorService() {
private val channel = Channel<Any>(capacity)

override fun execute(command: Runnable) {
channel.runBlock {
command.run()
}
}

fun isEmpty(): Boolean {
return channel.isEmpty || channel.isClosedForReceive
}

override fun shutdown() {
channel.close()
}

override fun shutdownNow(): MutableList<Runnable> {
shutdown()
return mutableListOf()
}

@ExperimentalCoroutinesApi
override fun isShutdown(): Boolean {
return channel.isClosedForSend
}

@ExperimentalCoroutinesApi
override fun isTerminated(): Boolean {
return channel.isClosedForReceive
}

override fun awaitTermination(timeout: Long, unit: TimeUnit): Boolean {
var millis = unit.toMillis(timeout)
while (!isTerminated && millis > 0) {
try {
Thread.sleep(200L)
millis -= 200L
} catch (ignore: Exception) {
}
}
return isTerminated
}
}

需要简单地控制并发的地方,直接定义Channel然后调用runBlock即可;


作者:呼啸长风
链接:https://juejin.cn/post/7036766272712867854
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Android 编译速度提升黑科技 - RocketX

怎么做编译优化,当时说了个方案,就是编译时将所有的模块依赖修改为 aar,然后每次编译将变动的模块改成源码依赖,同时编译完成再将修改模块上传为 aar,这样可以始终做到仅有最少的模块参与源码编译,从而提升编译速度。 当然说起来轻松,做起来没有那么容易,终于有位...
继续阅读 »

怎么做编译优化,当时说了个方案,就是编译时将所有的模块依赖修改为 aar,然后每次编译将变动的模块改成源码依赖,同时编译完成再将修改模块上传为 aar,这样可以始终做到仅有最少的模块参与源码编译,从而提升编译速度。


当然说起来轻松,做起来没有那么容易,终于有位小伙伴将上述描述开发成一个开源方案了,非常值得大家学习和借鉴。


1.背景描述


在项目体量越来越大的情况下,编译速度也随着增长,有时候一个修改需要等待长达好几分钟的编译时间。


基于这种普遍的情况,推出了 RocketX ,通过在编译流程动态修改项目依赖关系, 动态 替换 module 为 aar,做到只编译改动模块,其他模块不参与编译,无需改动原有项目任何代码,提高全量编译的速度。


2.效果展示


2.1、测试项目介绍

目标项目一共 3W+ 个类与资源文件,全量编译 4min 左右(测试使用 18 年 mbp 8代i7 16g)。


通过 RocketX 全量增速之后的效果(每一个操作取 3 次平均值)。


image.png


项目依赖关系如下图,app 依赖 bm 业务模块,bm 业务模块依赖顶层 base/comm 模块。


image.png


依赖关系


• 当 base/comm 模块改动,底部的所有模块都必须参与编译。因为 app/bmxxx 模块可能使用了 base 模块中的接口或变量等,并且不知道是否有改动到。(那么速度就非常慢)


• 当 bmDiscover 做了改动,只需要 app 模块和 bmDiscover 两个模块参与编译。(速度较快)


• rx(RocketX) 在无论哪一个模块的编译速度基本都是在控制在 30s 左右,因为只编译 app 和 改动的模块,其他模块是 aar 包不参与编译。


顶层模块速度提升 300%+


3.思路问题分析与模块搭建


3.1、思路问题分析

需要通过 gradle plugin 的形式动态修改没有改动过的 module 依赖为 相对应的 aar 依赖,如果 module 改动,退化成 project 工程依赖,这样每次只有改动的 module 和 app 两个模块编译。


需要把 implement/api moduleB,修改为implement/api aarB。


需要构建 local maven 存储未被修改的 module 对应的 aar。(也可以通过 flatDir 代替速度更快)


编译流程启动,需要找到哪一个 module 做了修改。


需要遍历每一个 module 的依赖关系进行置换, module 依赖怎么获取?一次性能获取到所有模块依赖,还是分模块各自回调?修改其中一个模块依赖关系会阻断后面模块依赖回调?


每一个 module 换变成 aar 之后,自身依赖的 child 依赖 (网络依赖,aar),给到 parent module (如何找到所有 parent module) ? 还是直接给 app module ? 有没有 app 到 module 依赖断掉的风险?这里需要出一个技术方案。


需要hook 编译流程,完成后置换 loacal maven 中被修改的 aar。


提供 AS 状态栏 button, 实现开启关闭功能,加速编译还是让开发者使用已经习惯性的三角形 run 按钮。


3.2、模块搭建

依照上面的分析,虽然问题很多,但是大致可以把整个项目分成以下几块:


image.png


4.问题解决与实现


4.1、implement 源码实现入口在 DynamicAddDependencyMethods 中的 tryInvokeMethod 方法。他是一个动态语言的 methodMissing 功能。

tryInvokeMethod 代码分析:


 public DynamicInvokeResult tryInvokeMethod(String name, Object... arguments) {       //省略部分代码 ...       return DynamicInvokeResult.found(this.dependencyAdder.add(configuration, normalizedArgs.get(0), (Closure)null)); }
复制代码

dependencyAdder 实现是一个 DirectDependencyAdder。


private class DirectDependencyAdder implements DependencyAdder<Dependency> {    private DirectDependencyAdder() {    }    public Dependency add(Configuration configuration, Object dependencyNotation, @Nullable Closure configureAction) {        return DefaultDependencyHandler.this.doAdd(configuration, dependencyNotation, configureAction);    }}
复制代码

最后是在 DefaultDependencyHandler.this.doAdd 进行添加进去,而 DefaultDependencyHandler 在 project可以获取。


  DependencyHandler getDependencies(); 
复制代码

通过以上的分析,添加相对应的 aar/jar 可以通过以下代码实现。


fun addAarDependencyToProject(aarName: String, configName: String, project: Project) {    //添加 aar 依赖 以下代码等同于 api/implementation/xxx (name: 'libaccount-2.0.0', ext: 'aar'),源码使用 linkedMap    if (!File(FileUtil.getLocalMavenCacheDir() + aarName + ".aar").exists()) return    val map = linkedMapOf<String, String>()    map.put("name", aarName)    map.put("ext", "aar")    // TODO: 2021/11/5 改变依赖 这里后面需要修改成    //project.dependencies.add(configName, "com.${project.name}:${project.name}:1.0")    project.dependencies.add(configName, map)}
复制代码

4.2、localMave 优先使用 flatDir 实现通过指定一个缓存目录把生成 aar/jar 包丢进去,依赖修改时候通过找寻进行替换。

fun flatDirs() {    val map = mutableMapOf<String, File>()    map.put("dirs", File(getLocalMavenCacheDir()))    appProject.rootProject.allprojects {        it.repositories.flatDir(map)    }}
复制代码

4.3、编译流程启动,需要找到哪一个 module做了修改。

使用遍历整个项目的文件的 lastModifyTime 去做实现。


以每一个 module 为一个粒度,递归遍历当前 module 的文件,把每个文件的 lastModifyTime 整合计算得出一个唯一标识 countTime。


通过 countTime 与上一次的作对比,相同说明没改动,不同则改动. 并需要同步计算后的 countTime 到本地缓存中。


整体 3W 个文件耗时 1.2s 可以接受。


4.4、 module 依赖关系获取。

通过以下代码可以找到生成整个项目的依赖关系图时机,并在此处生成依赖图解析器。


 project.gradle.addListener(DependencyResolutionListener listener)
复制代码

4.5、 module 依赖关系 project 替换成 aar 技术方案

每一个 module 依赖关系替换的遍历顺序是无序的,所以技术方案需要支持无序的替换。


目前使用的方案是:如果当前模块 A 未改动,需要把 A 通过 localMaven 置换成 A.aar,并把 A.aar 以及 A 的 child 依赖,给到第一层的 parent module 即可。(可能会质疑如果 parent module 也是 aar 怎么办,其实这块也是没有问题的,这里就不展开说了,篇幅太长)


为什么要给到 parent 不能直接给到 app ,下图一个简单的示例如果 B.aar 不给 A 模块的话,A 使用 B 模块的接口不见了,会导致编译不过。


image.png


给出整体项目替换的技术方案演示:


image.png


4.5、hook 编译流程,完成后置换 loacal maven 中被修改的 aar。

点击三角形 run,执行的命令是 app:assembleDebug , 需要在 assembleDebug 后面补一个 uploadLocalMavenTask, 通过 finalizedBy 把我们的 task 运行起来去同步修改后的 aar


4.6、提供 AS 状态栏 button,小火箭按钮一个喷火一个没有喷火,代表 enable/disable , 一个 扫把clean rockectx 的缓存。

image.png


5一天一个小惊喜


5.1、发现点击 run 按钮 ,执行的命令是 app:assembleDebug ,各个子 module 在 output 并没有打包出 aar。

解决:通过研究 gradle 源码发现打包是由 bundleFlavor{Flavor}{BuildType}Aar 这个task执行出来,那么只需要将各个模块对应的 task 找到并注入到 app:assembleDebug 之后运行即可。


5.2、发现运行起来后存在多个 jar 包重复问题。

解决:implementation fileTree(dir: "libs", include: ["*.jar"]) jar 依赖不能交到 parent module,jar 包会打进 aar 中的lib 可直接剔除。通过以下代码可以判断:


// 这里的依赖是以下两种: 无需添加在 parent ,因为 jar 包直接进入 自身的 aar 中的libs 文件夹//    implementation rootProject.files("libs/xxx.jar")//    implementation fileTree(dir: "libs", include: ["*.jar"])childDepency.files is DefaultConfigurableFileCollection || childDepency.files is DefaultConfigurableFileTree
复制代码

5.3、发现 aar/jar 存在多种依赖方式。

implementation (name: 'libXXX', ext: 'aar')


implementation files("libXXX.aar")


解决:使用第一种,第二种会合并进aar,导致类重复问题.


5.4、发现 aar 新姿势依赖。

configurations.maybeCreate("default")artifacts.add("default", file('lib-xx.aar'))
复制代码

上面代码把 aar 做了一个单独的 module 给到其他 module 依赖,default config 其实是 module 最终输出 aar 的持有者,default config 可以持有一个 列表的aar ,所以把 aar 手动添加到 default config,也相当于当前 module 打包出来的产物。


解决:通过 childProject.configurations.maybeCreate("default").artifacts 找到所有添加进来的 aar ,单独发布 localmaven。


5.5、发现 android module 打包出来可以是 jar。

解决:通过找到名字叫做 jar 的task,并且在 jar task 后面注入 uploadLocalMaven task。


5.6、发现 arouter 有 bug,transform 没有通过 outputProvider.deleteAll() 清理旧的缓存。

解决:详情查看 issue,结果arouter 问题是解决了,代码也是合并了。但并没有发布新的插件版本到 mavenCentral,于是先自行帮 arouter 解决一下。


github.com/alibaba/ARo…



关注我,每天分享知识干货!

作者:Android_XG
链接:https://juejin.cn/post/7036913257768026125
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Android CameraX结合LibYUV和GPUImage自定义相机滤镜

前言 之前使用Camera实现了一个自定义相机滤镜(Android自定义相机滤镜 ),但是运行起来有点卡顿,这次用Camerax来实现一样的效果发现很流畅,在此记录一下,也希望能帮到有需要的同学。 实现效果 实现步骤 1.引入依赖库 这里我引入的依赖库有Ca...
继续阅读 »

前言


之前使用Camera实现了一个自定义相机滤镜(Android自定义相机滤镜 ),但是运行起来有点卡顿,这次用Camerax来实现一样的效果发现很流畅,在此记录一下,也希望能帮到有需要的同学。


实现效果



实现步骤


1.引入依赖库

这里我引入的依赖库有CameraXGPUImage(滤镜库)、Utilcodex(一款好用的工具类)


// CameraX core library using camera2 implementation
    implementation "androidx.camera:camera-camera2:1.0.1"
// CameraX Lifecycle Library
    implementation "androidx.camera:camera-lifecycle:1.0.1"
// CameraX View class
    implementation "androidx.camera:camera-view:1.0.0-alpha27"

    implementation'jp.co.cyberagent.android.gpuimage:gpuimage-library:1.4.1'
    implementation 'com.blankj:utilcodex:1.30.6'

2.引入libyuv

这里我用的是这个案例(github.com/theeasiestw…



3.编写CameraX预览代码

布局代码如下


<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">
    <androidx.camera.view.PreviewView
        android:id="@+id/viewFinder"
        android:layout_width="0dp"
        android:layout_height="0dp" />
</FrameLayout>

Activity中开启相机预览代码如下,基本都是Google官方提供的案例代码


class MainActivity : AppCompatActivity() {
    private lateinit var cameraExecutor: ExecutorService
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        cameraExecutor = Executors.newSingleThreadExecutor()
        // Request camera permissions
        if (allPermissionsGranted()) {
            startCamera()
        } else {
            ActivityCompat.requestPermissions(
                this, REQUIRED_PERMISSIONS, REQUEST_CODE_PERMISSIONS)
        }
    }

    private fun allPermissionsGranted() = REQUIRED_PERMISSIONS.all {
        ContextCompat.checkSelfPermission(
            baseContext, it) == PackageManager.PERMISSION_GRANTED
    }

    override fun onRequestPermissionsResult(
        requestCode: Int, permissions: Array<String>, grantResults:
        IntArray) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults)
        if (requestCode == REQUEST_CODE_PERMISSIONS) {
            if (allPermissionsGranted()) {
                startCamera()
            } else {
                Toast.makeText(this,
                    "Permissions not granted by the user.",
                    Toast.LENGTH_SHORT).show()
                finish()
            }
        }
    }
    private fun startCamera() {
        val cameraProviderFuture = ProcessCameraProvider.getInstance(this)
        cameraProviderFuture.addListener(Runnable {
            val cameraProvider: ProcessCameraProvider = cameraProviderFuture.get()
            val preview = Preview.Builder()
                .build()
                .also {
                    it.setSurfaceProvider(viewFinder.surfaceProvider)
                }
            val cameraSelector = CameraSelector.DEFAULT_BACK_CAMERA
            try {
                cameraProvider.unbindAll()
                cameraProvider.bindToLifecycle(
                    this, cameraSelector, preview)
            } catch(exc: Exception) {
                Log.e(TAG, "Use case binding failed", exc)
            }
        }, ContextCompat.getMainExecutor(this))
    }

    override fun onDestroy() {
        super.onDestroy()
        cameraExecutor.shutdown()
    }

    companion object {
        private const val TAG = "CameraXBasic"
        private const val REQUEST_CODE_PERMISSIONS = 10
        private val REQUIRED_PERMISSIONS = arrayOf(Manifest.permission.CAMERA)

    }
}

到这里就可以实现相机预览了



4.增加相机数据回调

我们要增加滤镜效果就必须对相机的数据进行操作,这里我们通过获取相机数据回调来获取可修改的数据


val imageAnalyzer = ImageAnalysis.Builder()
                //设置回调数据的比例为16:9
                .setTargetAspectRatio(AspectRatio.RATIO_16_9)
                .build()
                .also {
                    it.setAnalyzer(cameraExecutor,this@MainActivity)
                }

这里我们还需要进行绑定



除此之外我们还需要在Activity中实现ImageAnalysis.Analyzer接口,数据的获取就在此接口的回调方法中获取,如下所示,其中ImageProxy就包含了图像数据


override fun analyze(image: ImageProxy) {

}

5.对回调数据进行处理

我们在相机数据回调的方法中对图像进行处理并添加滤镜,当然在此之前我们还需要创建GPUImage对象并设置滤镜类型


private var bitmap:Bitmap? = null
private var gpuImage:GPUImage? = null
//创建GPUImage对象并设置滤镜类型,这里我使用的是素描滤镜
private fun initFilter() {
        gpuImage = GPUImage(this)
        gpuImage!!.setFilter(GPUImageSketchFilter())
    }
@SuppressLint("UnsafeOptInUsageError")
    override fun analyze(image: ImageProxy) {
        //将Android的YUV数据转为libYuv的数据
        var yuvFrame = yuvUtils.convertToI420(image.image!!)
        //对图像进行旋转(由于回调的相机数据是横着的因此需要旋转90度)
        yuvFrame = yuvUtils.rotate(yuvFrame, 90)
        //根据图像大小创建Bitmap
        bitmap = Bitmap.createBitmap(yuvFrame.width, yuvFrame.height, Bitmap.Config.ARGB_8888)
        //将图像转为Argb格式的并填充到Bitmap上
        yuvUtils.yuv420ToArgb(yuvFrame,bitmap!!)
        //利用GpuImage给图像添加滤镜
        bitmap = gpuImage!!.getBitmapWithFilterApplied(bitmap)
        //由于这不是UI线程因此需要在UI线程更新UI
        img.post {
            img.setImageBitmap(bitmap)
            //关闭ImageProxy,才会回调下一次的数据
            image.close()
        }

    }

6.拍摄照片

这里我们加一个拍照的按钮


<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">
    <androidx.camera.view.PreviewView
        android:id="@+id/viewFinder"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
    <ImageView
        android:id="@+id/img"
        android:scaleType="centerCrop"
        android:layout_width="match_parent"
        android:layout_height="match_parent"/>
    <Button
        android:id="@+id/bt_takepicture"
        android:layout_gravity="center_horizontal|bottom"
        android:layout_marginBottom="100dp"
        android:text="拍照"
        android:layout_width="70dp"
        android:layout_height="70dp"/>
</FrameLayout>

然后我们在Activity中添加拍照的逻辑,其实就是将Bitmap转为图片保存到SD卡,这里我们使用了之前引入的Utilcodex工具,当我们点击按钮的时候isTakePhoto 会变为true,然后在相机的回调中就会进行保存图片的处理


bt_takepicture.setOnClickListener {
            isTakePhoto = true
        }

并且我们加入变量控制,在拍照的时候不处理回调数据


@SuppressLint("UnsafeOptInUsageError")
    override fun analyze(image: ImageProxy) {
        if(!isTakePhoto){
            //将Android的YUV数据转为libYuv的数据
            var yuvFrame = yuvUtils.convertToI420(image.image!!)
            //对图像进行旋转(由于回调的相机数据是横着的因此需要旋转90度)
            yuvFrame = yuvUtils.rotate(yuvFrame, 90)
            //根据图像大小创建Bitmap
            bitmap = Bitmap.createBitmap(yuvFrame.width, yuvFrame.height, Bitmap.Config.ARGB_8888)
            //将图像转为Argb格式的并填充到Bitmap上
            yuvUtils.yuv420ToArgb(yuvFrame,bitmap!!)
            //利用GpuImage给图像添加滤镜
            bitmap = gpuImage!!.getBitmapWithFilterApplied(bitmap)
            //由于这不是UI线程因此需要在UI线程更新UI
            img.post {
                img.setImageBitmap(bitmap)
                if(isTakePhoto){
                    takePhoto()
                }
                //关闭ImageProxy,才会回调下一次的数据
                image.close()
            }
        }else{
            image.close()
        }
    }
 /**
     * 拍照
     */
    private fun takePhoto() {
        Thread{
            val filePath = File(getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS),"${System.currentTimeMillis()}save.png")
            ImageUtils.save(bitmap,filePath.absolutePath,Bitmap.CompressFormat.PNG)
            ToastUtils.showShort("拍摄成功")
            isTakePhoto = false
        }.start()
    }

效果如下



保存的图片在如下目录



保存的图片如下



只有不断的学习进步,才能不被时代淘汰。关注我,每天分享知识干货!


作者:Misdirection
链接:https://juejin.cn/post/7036924380613443621
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

探究Android属性动画执行过程

1.引言属性动画作为Android动画功能的一个重要组成部分,可以实现很多有趣的动画效果,理解属性动画的执行过程有助于我们更好地使用属性动画去实现需求。本文将从源码的角度去探索属性动画的实现过程,加深大家对其的认知和理解。2.属性动画相关的类2.1 Value...
继续阅读 »

1.引言

属性动画作为Android动画功能的一个重要组成部分,可以实现很多有趣的动画效果,理解属性动画的执行过程有助于我们更好地使用属性动画去实现需求。本文将从源码的角度去探索属性动画的实现过程,加深大家对其的认知和理解。

2.属性动画相关的类

2.1 ValueAnimator

这个类是实现属性动画的一个重要的类,通过ValueAnimator.ofFloat()、ValueAnimator.ofInt()、ValueAnimator.ofObject()、ValueAnimator.ofArgb()、ValueAnimator.ofPropertyValuesHolder()等方法可以获得ValueAnimator的对象,然后可以通过对这个对象的操作去实现动画。使用ValueAnimator实现属性动画,需要实现ValueAnimator.AnimatorUpdateListener()接口,并在onAnimationUpdate()方法内为要添加动画的对象设置属性值。

2.2 ObjectAnimator

ObjectAnimator是ValueAnimator的子类,可以操作目标对象的动画属性,这个类的构造函数支持采用参数的形式传入要使用动画的目标对象和属性名。

3.属性动画的实现过程

ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(iv, "alpha", 1.0f, 0f);
objectAnimator.setDuration(3000);
objectAnimator.start();

这是一段简单的代码,它使用属性动画实现了一张图片的透明度渐变的效果,我们从这一段代码入手,去分析属性动画的实现过程。

3.1 创建属性动画

/**
* target:添加动画效果的目标对象
* propertyName:动画效果的属性名
* values:动画将会在这个时间之间执行的数值集合
*/
public static ObjectAnimator ofFloat(Object target, String propertyName, float... values){
ObjectAnimator anim = new ObjectAnimator(target, propertyName);
anim.setFloatValues(values);
return anim;
}

这个方法返回了一个属性动画对象,第一个参数是产生动画效果的目标对象,第二个参数是属性名,目标对象的属性名应该有与之对应的set()方法,例如我们传入属性名"alpha",那么这个目标对象也应该有setAlpha()方法。参数values传一个值的时候,这个值是动画的结束值,传两个数值的时候,第一个值是开始值,第二个值是结束值,多于两个值的时候,第一个值是开始值,最后一个值是结束值。

private ObjectAnimator(Object target, String propertyName) {
setTarget(target);
setPropertyName(propertyName);
}

这个是属性动画的构造函数,里面执行了两个方法setTarget(target)和setPropertyName(propertyName)。

@Override
public void setTarget(@Nullable Object target) {
final Object oldTarget = getTarget();
if (oldTarget != target) {
if (isStarted()) {
cancel();
}
mTarget = target == null ? null : new WeakReference<Object>(target);
// New target should cause re-initialization prior to starting
mInitialized = false;
}
}
public void setPropertyName(@NonNull String propertyName) {
// mValues could be null if this is being constructed piecemeal. Just record the
// propertyName to be used later when setValues() is called if so.
if (mValues != null) {
PropertyValuesHolder valuesHolder = mValues[0];
String oldName = valuesHolder.getPropertyName();
valuesHolder.setPropertyName(propertyName);
mValuesMap.remove(oldName);
mValuesMap.put(propertyName, valuesHolder);
}
mPropertyName = propertyName;
// New property/values/target should cause re-initialization prior to starting
mInitialized = false;
}

mValues是一个PropertyValuesHolder数组,PropertyValuesHolder持有动画的属性名和属性值信息,mValuesMap是一个hashmap数组,用来管理PropertyValuesHolder对象,在调用getAnimatedValue(String)方法的时候,这个map通过属性名去查找动画执行的数值。当mValues不为空的时候,将属性名信息放入mValuesMap。

//ObjectAnimator
@Override
public void setFloatValues(float... values) {
if (mValues == null || mValues.length == 0) {
// No values yet - this animator is being constructed piecemeal. Init the values with
// whatever the current propertyName is
if (mProperty != null) {
setValues(PropertyValuesHolder.ofFloat(mProperty, values));
} else {
setValues(PropertyValuesHolder.ofFloat(mPropertyName, values));
}
} else {
super.setFloatValues(values);
}
}

mValues为null或者数组元素个数为0的时候,调用其父类ValueAnimator的setValues()方法,在setValues()内执行了初始化mValues和mValuesMap的操作,并将PropertyValuesHolder放入mValuesMap。当mValues不为null且元素个数不为0的时候,调用其父类ValueAnimator的setFloatValues()方法,在setFloatValues()方法内满足条件又会调用到PropertyValuesHolder的setFloatValues()方法。

//PropertyValuesHolder
public void setFloatValues(float... values) {
mValueType = float.class;
mKeyframes = KeyframeSet.ofFloat(values);
}

这里的mValueType指的是提供的值的类型,mKeyframes是定义这个动画的关键帧集合。

//KeyframeSet
public static KeyframeSet ofFloat(float... values) {
boolean badValue = false;
int numKeyframes = values.length;
FloatKeyframe keyframes[] = new FloatKeyframe[Math.max(numKeyframes,2)];
if (numKeyframes == 1) {
keyframes[0] = (FloatKeyframe) Keyframe.ofFloat(0f);
keyframes[1] = (FloatKeyframe) Keyframe.ofFloat(1f, values[0]);
if (Float.isNaN(values[0])) {
badValue = true;
}
} else {
keyframes[0] = (FloatKeyframe) Keyframe.ofFloat(0f, values[0]);
for (int i = 1; i < numKeyframes; ++i) {
keyframes[i] =
(FloatKeyframe) Keyframe.ofFloat((float) i / (numKeyframes - 1), values[i]);
if (Float.isNaN(values[i])) {
badValue = true;
}
}
}
if (badValue) {
Log.w("Animator", "Bad value (NaN) in float animator");
}
return new FloatKeyframeSet(keyframes);
}

在这个方法内新建了一个FloatKeyframe数组,数组的元素至少为2个,FloatKeyframe是Keyframe的内部子类,持有这个动画的时间值对,Keyframe类被ValueAnimator用来定义整个动画过程中动画目标的数值,当时间从一帧到另一帧,目标对象的值也会从上一帧的值运动到下一帧的值。

/**
* fraction:取值范围0到1之间,表示全部动画时长中已经执行的时间部分
* value:关键帧中与时间相对应的数值
*/
public static Keyframe ofFloat(float fraction, float value) {
return new FloatKeyframe(fraction, value);
}

此方法使用给定的时间和数值创建一个关键帧对象,到这里,属性动画的创建过程基本完成。

3.2 属性动画执行过程

//ObjectAnimator
@Override
public void start() {
AnimationHandler.getInstance().autoCancelBasedOn(this);
if (DBG) {
Log.d(LOG_TAG, "Anim target, duration: " + getTarget() + ", " + getDuration());
for (int i = 0; i < mValues.length; ++i) {
PropertyValuesHolder pvh = mValues[i];
Log.d(LOG_TAG, " Values[" + i + "]: " +
pvh.getPropertyName() + ", " + pvh.mKeyframes.getValue(0) + ", " +
pvh.mKeyframes.getValue(1));
}
}
super.start();
}

在代码中调用objectAnimator.start()的时候动画开始执行,内部调用了其父类ValueAnimator的start()方法。

//ValueAnimator
private void start(boolean playBackwards) {
if (Looper.myLooper() == null) {
throw new AndroidRuntimeException("Animators may only be run on Looper threads");
}
mReversing = playBackwards;
mSelfPulse = !mSuppressSelfPulseRequested;
// Special case: reversing from seek-to-0 should act as if not seeked at all.
if (playBackwards && mSeekFraction != -1 && mSeekFraction != 0) {
if (mRepeatCount == INFINITE) {
// Calculate the fraction of the current iteration.
float fraction = (float) (mSeekFraction - Math.floor(mSeekFraction));
mSeekFraction = 1 - fraction;
} else {
mSeekFraction = 1 + mRepeatCount - mSeekFraction;
}
}
mStarted = true;
mPaused = false;
mRunning = false;
mAnimationEndRequested = false;
// Resets mLastFrameTime when start() is called, so that if the animation was running,
// calling start() would put the animation in the
// started-but-not-yet-reached-the-first-frame phase.
mLastFrameTime = -1;
mFirstFrameTime = -1;
mStartTime = -1;
addAnimationCallback(0);

if (mStartDelay == 0 || mSeekFraction >= 0 || mReversing) {
// If there's no start delay, init the animation and notify start listeners right away
// to be consistent with the previous behavior. Otherwise, postpone this until the first
// frame after the start delay.
startAnimation();
if (mSeekFraction == -1) {
// No seek, start at play time 0. Note that the reason we are not using fraction 0
// is because for animations with 0 duration, we want to be consistent with pre-N
// behavior: skip to the final value immediately.
setCurrentPlayTime(0);
} else {
setCurrentFraction(mSeekFraction);
}
}
}

在这个方法内进行了一些赋值操作,addAnimationCallback(0)和startAnimation()是比较重要的操作。

//ValueAnimator
private void addAnimationCallback(long delay) {
if (!mSelfPulse) {
return;
}
getAnimationHandler().addAnimationFrameCallback(this, delay);
}

这个方法内执行了AnimationHandler的addAnimationFrameCallback()方法注册回调,我们继续看看addAnimationFrameCallback()方法。

//AnimationHandler
public void addAnimationFrameCallback(final AnimationFrameCallback callback, long delay) {
if (mAnimationCallbacks.size() == 0) {
getProvider().postFrameCallback(mFrameCallback);
}
if (!mAnimationCallbacks.contains(callback)) {
mAnimationCallbacks.add(callback);
}

if (delay > 0) {
mDelayedCallbackStartTime.put(callback, (SystemClock.uptimeMillis() + delay));
}
}

这个方法添加了一个AnimationFrameCallback回调,AnimationFrameCallback是AnimationHandler的一个内部接口,其中有两个重要的方法doAnimationFrame()和commitAnimationFrame()。

//AnimationHandler
interface AnimationFrameCallback {
boolean doAnimationFrame(long frameTime);

void commitAnimationFrame(long frameTime);
}

AnimationFrameCallback是可以收到动画执行时间和帧提交时间通知的回调,内有两个方法,doAnimationFrame()和commitAnimationFrame()。

//AnimationHandler
private class MyFrameCallbackProvider implements AnimationFrameCallbackProvider {

final Choreographer mChoreographer = Choreographer.getInstance();

@Override
public void postFrameCallback(Choreographer.FrameCallback callback) {
mChoreographer.postFrameCallback(callback);
}

@Override
public void postCommitCallback(Runnable runnable) {
mChoreographer.postCallback(Choreographer.CALLBACK_COMMIT, runnable, null);
}

@Override
public long getFrameTime() {
return mChoreographer.getFrameTime();
}

@Override
public long getFrameDelay() {
return Choreographer.getFrameDelay();
}

@Override
public void setFrameDelay(long delay) {
Choreographer.setFrameDelay(delay);
}
}

前面的getProvider()方法获得了MyFrameCallbackProvider的一个实例,MyFrameCallbackProvider是AnimationHandler的一个内部类,实现了AnimationFrameCallbackProvider接口,使用Choreographer作为计时脉冲的提供者,去发送帧回调。Choreographer从显示器子系统获得时间脉冲,postFrameCallback()方法发送帧回调。

//AnimationHandler
public interface AnimationFrameCallbackProvider {
void postFrameCallback(Choreographer.FrameCallback callback);
void postCommitCallback(Runnable runnable);
long getFrameTime();
long getFrameDelay();
void setFrameDelay(long delay);
}
//AnimationHandler
private final Choreographer.FrameCallback mFrameCallback = new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
doAnimationFrame(getProvider().getFrameTime());
if (mAnimationCallbacks.size() > 0) {
getProvider().postFrameCallback(this);
}
}
};

在这个回调内执行了doAnimationFrame()方法,如果mAnimationCallbacks的个数大于0,AnimationFrameCallbackProvider就继续发送帧回调,继续重复执行doAnimationFrame()。

//AnimationHandler   
private void doAnimationFrame(long frameTime) {
long currentTime = SystemClock.uptimeMillis();
final int size = mAnimationCallbacks.size();
for (int i = 0; i < size; i++) {
final AnimationFrameCallback callback = mAnimationCallbacks.get(i);
if (callback == null) {
continue;
}
if (isCallbackDue(callback, currentTime)) {
callback.doAnimationFrame(frameTime);
if (mCommitCallbacks.contains(callback)) {
getProvider().postCommitCallback(new Runnable() {
@Override
public void run() {
commitAnimationFrame(callback, getProvider().getFrameTime());
}
});
}
}
}
cleanUpList();
}

在这个方法内开启了一个循环,里面执行了callback.doAnimationFrame(),这个操作会触发ValueAnimator类中的doAnimationFrame()。

//ValueAnimator
private void startAnimation() {
if (Trace.isTagEnabled(Trace.TRACE_TAG_VIEW)) {
Trace.asyncTraceBegin(Trace.TRACE_TAG_VIEW, getNameForTrace(),
System.identityHashCode(this));
}

mAnimationEndRequested = false;
initAnimation();
mRunning = true;
if (mSeekFraction >= 0) {
mOverallFraction = mSeekFraction;
} else {
mOverallFraction = 0f;
}
if (mListeners != null) {
notifyStartListeners();
}
}

startAnimation()方法内调用了initAnimation()初始化动画。

//ValueAnimator
public final boolean doAnimationFrame(long frameTime) {
//省略部分代码
...
final long currentTime = Math.max(frameTime, mStartTime);
boolean finished = animateBasedOnTime(currentTime);

if (finished) {
endAnimation();
}
return finished;
}

这个方法在执行动画的过程中会被多次调用,其中重要的操作是animateBasedOnTime(currentTime)。

//ValueAnimator
boolean animateBasedOnTime(long currentTime) {
boolean done = false;
if (mRunning) {
final long scaledDuration = getScaledDuration();
final float fraction = scaledDuration > 0 ?
(float)(currentTime - mStartTime) / scaledDuration : 1f;
final float lastFraction = mOverallFraction;
final boolean newIteration = (int) fraction > (int) lastFraction;
final boolean lastIterationFinished = (fraction >= mRepeatCount + 1) &&
(mRepeatCount != INFINITE);
if (scaledDuration == 0) {
// 0 duration animator, ignore the repeat count and skip to the end
done = true;
} else if (newIteration && !lastIterationFinished) {
// Time to repeat
if (mListeners != null) {
int numListeners = mListeners.size();
for (int i = 0; i < numListeners; ++i) {
mListeners.get(i).onAnimationRepeat(this);
}
}
} else if (lastIterationFinished) {
done = true;
}
mOverallFraction = clampFraction(fraction);
float currentIterationFraction = getCurrentIterationFraction(
mOverallFraction, mReversing);
animateValue(currentIterationFraction);
}
return done;
}

animateBasedOnTime()方法计算了已经执行的动画时长和动画分数,并调用animateValue()方法计算动画值。

//ValueAnimator
void animateValue(float fraction) {
fraction = mInterpolator.getInterpolation(fraction);
mCurrentFraction = fraction;
int numValues = mValues.length;
for (int i = 0; i < numValues; ++i) {
mValues[i].calculateValue(fraction);
}
if (mUpdateListeners != null) {
int numListeners = mUpdateListeners.size();
for (int i = 0; i < numListeners; ++i) {
mUpdateListeners.get(i).onAnimationUpdate(this);
}
}
}

ValueAnimator的animateValue()方法内部首先根据动画分数得到插值分数,再根据插值分数计算动画值,并调用了AnimatorUpdateListener的onAnimationUpdate()方法通知更新。

//ObjectAnimator
@Override
void animateValue(float fraction) {
final Object target = getTarget();
if (mTarget != null && target == null) {
// We lost the target reference, cancel and clean up. Note: we allow null target if the
/// target has never been set.
cancel();
return;
}

super.animateValue(fraction);
int numValues = mValues.length;
for (int i = 0; i < numValues; ++i) {
mValues[i].setAnimatedValue(target);
}
}

ObjectAnimator的animateValue()方法不仅调用了父类的animateValue()方法,还在循环内调用了PropertyValuesHolder的setAnimatedValue()方法,传入的参数是产生动画效果的目标对象。

//PropertyValuesHolder
@Override
void setAnimatedValue(Object target) {
if (mFloatProperty != null) {
mFloatProperty.setValue(target, mFloatAnimatedValue);
return;
}
if (mProperty != null) {
mProperty.set(target, mFloatAnimatedValue);
return;
}
if (mJniSetter != 0) {
nCallFloatMethod(target, mJniSetter, mFloatAnimatedValue);
return;
}
if (mSetter != null) {
try {
mTmpValueArray[0] = mFloatAnimatedValue;
mSetter.invoke(target, mTmpValueArray);
} catch (InvocationTargetException e) {
Log.e("PropertyValuesHolder", e.toString());
} catch (IllegalAccessException e) {
Log.e("PropertyValuesHolder", e.toString());
}
}
}

在PropertyValuesHolder的setAnimatedValue()方法内部,先通过JNI去修改目标对象的属性值,如果通过JNI找不到对应的方法,则通过使用反射机制修改目标对象的属性值。

4.总结

属性动画的功能相当强大,可以为视图对象和非视图对象添加动画效果,属性动画是通过改变要添加动画的目标对象的属性值实现的,ValueAnimator基于动画时长和已经执行的时长计算得出动画分数,然后根据设置的时间插值器TimeInterpolator计算得出动画的插值分数,再调用对应的估值器TypeEvaluator根据插值分数、起始值和结束值计算得出对象的属性值,ObjectAnimator类在计算出动画的新值后自动地更新对象的属性值,ValueAnimator类则需要手动地去设置对象的属性值。


作者:QiShare
链接:https://juejin.cn/post/7036986935545430030
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

为什么我不用 Typescript

前言 我算是久仰 Typescript 的大名了,因而之前就想学习,但是一直没有抽出时间来看看它。直到最近有一天我在知乎上被邀请回答了 一个问题 —— 一个我以为的中学生问怎么样提升他的开源仓库。我点进去,先是被惊艳到了;然后发现,他用的是 Typescrip...
继续阅读 »

前言


我算是久仰 Typescript 的大名了,因而之前就想学习,但是一直没有抽出时间来看看它。直到最近有一天我在知乎上被邀请回答了 一个问题 —— 一个我以为的中学生问怎么样提升他的开源仓库。我点进去,先是被惊艳到了;然后发现,他用的是 Typescript。我顿时感觉我似乎落后了,于是鼓起劲,开始学起了 Typescript。


但是我学了下,再用了下,发现它没有像被吹的那么神。虽说是 Javascript 的超集,也的确有些地方挺好的,但是还是不足够改变我使用 Javascript 编程。就像虽然有 Deno,但是我还是用 Node.js 一样。


所以,我就写这篇文章,说下我个人感觉 Typescript 的缺点、为何它的优点无法打动我用它替代 Javascript,以及跟推荐我使用 Typescript 的大家讲一下我不用 Typescript 的逻辑。


各位想骂我心里骂骂就好了,我今天过个生日也不容易。


缺陷


1. 语法丑陋,代码臃肿


我写两段相同的代码,大家感受下:


// js
const multiply = (i, j) => i * j

// ts
function multiply(i: number, j: number) {
return i + j
}

你看这类型注释,把好好的一段代码弄得这么乱……反正我看这样的 Typescript,花的反应时间一定比看上面的 Javascript 代码长。——不过也有可能是我比较熟悉 Javascript 吧。


复杂一点的东西也是一个道理(Apollo GraphQL 的代码):


// js
import React from 'react';
import ApolloClient from 'apollo-client';

let apolloContext;

export function getApolloContext() {
if (!apolloContext) {
apolloContext = React.createContext({});
}
return apolloContext;
}

export function resetApolloContext() {
apolloContext = React.createContext({});
}

铁定要比这个好得多:


// ts
import React from 'react';
import ApolloClient from 'apollo-client';

export interface ApolloContextValue {
client?: ApolloClient<object>;
renderPromises?: Record<any, any>;
}

let apolloContext: React.Context<ApolloContextValue>;

export function getApolloContext() {
if (!apolloContext) {
apolloContext = React.createContext<ApolloContextValue>({});
}
return apolloContext;
}

export function resetApolloContext() {
apolloContext = React.createContext<ApolloContextValue>({});
}

甚至有人提了个 issue 就是抱怨 Type 让它变得难用。


这么看,实在是为了这个假静态类型语言牺牲太多了,毕竟代码可读性还是很重要的。——之所以说它是假静态语言,是因为在真正的静态类型语言中,如 C 和 C++,不同的变量类型在内存中的存储方式不同,而在 Typescript 中不是这样。


比如,缺了这个可读性,debug 会变得更难。你是不是没有注意到我上面 multiply 的 Typescript 代码其实有 bug——应该是 * 而不是 +


2. 麻烦


浏览器不能直接执行 Typescript,所以 Typescript 必须要被编译成 Javascript 才能执行,要花一段时间;项目越大,花的时间越长,所以 Deno 才要停用它。并且,使用 Typescript 要安装新的依赖,虽然的确不麻烦,但是不用 Typescript,就不用再多装一个依赖了是不是。


其实还有一点,但是放不上台面来讲,因为这是我自己的问题。


我一直不大喜欢给添花样的东西,比如 pugtypescriptdeno 等;虽然 scss 啥的我觉得还是不错的——没有它我就写不出 @knowscount/vue-lib 这个仓库。


3. 文件体积会变大


随随便便就能猜到,我写那么多额外的类型注释、代码变得那么臃肿肯定会让 Typescript 文件比用 Javascript 编写的文件更大。作为一个用 “tab 会让文件体积更小” 作为论据的 tab 党,我当然讨厌 Typescript 啦哈哈哈哈。


我理解在编译过后都是一样的,但是反正……我还是不爽。而且正是由于 TypeScript 会被编译到JavaScript 中,所以才会出现无论你的类型设计得多么仔细,还是有可能让不同的值类型潜入 JavaScript 变量中的问题。这是不可避免的,因为 JavaScript 仍然是没有类型的。


4. 报错使我老花


单纯吐槽一句,为什么它的报错那么丑,我就拼错了一个单词他给我又臭又长报一大段,还没有颜色。。


为何无法打动我


在讲为什么 Typescript 的优点无法打动我之前,我先来讲一讲 Typescript 有哪些优点吧:



  1. 大厂的产品

  2. 大厂在用

  3. 可以用未来的特性

  4. 降低出 bug 的可能性

  5. 面对对象编程(OOP)


对于它是微软的产品,我不能多说啥,毕竟我用 Visual Studio Code 用得很香;但是大厂在用这个论点,就不一样了。


有个逻辑谬误叫做「reductio ad absurdum」,也就是「归谬法」。什么意思呢:



大厂用 Typescript,所以我要用 Typescript。

大厂几百万改个 logo,我就借几百万改个 logo,因为大厂是大厂,肯定做得对。



这就很荒谬。


的确,大公司会采用 Typescript,必定有他的道理。但是,同样的论证思路也可以用于 FlowAngularVueEmberjQueryBootstrap 等等等等,几乎所有流行的库都是如此,那么它们一定都适合你吗?


关于它可以让你提前接触到未来的特性……大哥,babel 不香吗?


最后就是 OOP 以及降低出 bug 的可能性(Typesafe)。OOP 是 Typescript 的核心部分,而现在 OOP 已经不吃香了……例如 Ilya Suzdalnitski 就说过它是「万亿美元的灾难」。


v2-9cc25cb80ddc2df7ab06f0184e433790_1440w.jpg


至于为什么这么说,无非就两点——面向对象代码难以重构,也难以进行单元测试。重构时的抓狂不提,单元测试的重要性,大家都清楚吧。


而在 Javascript 这种非 OOP 语言里头,函数可以独立于对象存在。不用为了包含这些函数而去发明一些奇怪的概念真是一种解脱。


总之,TypeScript 的所谓优点(更好的错误处理、类型推理)都不是最佳方案。你还是得写测试,还是得好好命名你的函数和变量。个人觉得单单像 Typescript 一样添加一个接口或类型不能解决任何这些问题。


正好一千五百字。


作者:TurpinHero
链接:https://juejin.cn/post/6961012856573657095

收起阅读 »

我是如何把vue项目启动时间从70s优化到7秒的

可怕的启动时间 公司的产品是一个比较大的后台管理系统,而且使用的是webpack3的vue模板项目,单次项目启动时间达到了70s左右 启动个项目都够吃一碗豆腐脑了,可是没有豆腐脑怎么办,那就优化启动时间吧! 考虑到升级webpack版本的风险还是比较大的,出...
继续阅读 »

可怕的启动时间


公司的产品是一个比较大的后台管理系统,而且使用的是webpack3的vue模板项目,单次项目启动时间达到了70s左右


image.png


启动个项目都够吃一碗豆腐脑了,可是没有豆腐脑怎么办,那就优化启动时间吧!


考虑到升级webpack版本的风险还是比较大的,出了一点问题都得找我,想想还是先别冒险,稳妥为主,所以我选择了通过插件来优化构建时间。


通过查阅资料,提升webpack的构建时间有以下几个方向:



  • 多进程处理文件,同一时间处理多个文件

  • 预编译资源模块,比如把长时间不变的库提取出来做预编译,构建的时候直接取编译结果就好

  • 缓存,未修改的模块直接拿到处理结果,不必编译

  • 减少构建搜索和处理的文件数量


针对以上几种优化方向,给出以下几种优化方案。


多进程构建


happypack


happypack 的作用就是将文件解析任务分解成多个子进程并发执行。


子进程处理完任务后再将结果发送给主进程。所以可以大大提升 Webpack 的项目构件速度。


查看happypack的github,发现作者已经不再维护该插件,并且作者推荐使用webpack官方的多进程插件thread-loader,所以我放弃了happypacy,选择了thread-loader。


thread-loader


thread-loader是官方维护的多进程loader,功能类似于happypack,也是通过开启子任务来并行解析文件,从而提高构建速度。


把这个loader放在其他loader前面。不过该loader是有限制的。示例:



  • loader无法发出文件。

  • loader不能使用自定义加载器API。

  • loader无法访问网页包选项。


每个worker都是一个单独的node.js进程,其开销约为600毫秒。还有进程间通信的开销。在小型项目中使用thread-loader可能并不能优化项目的构建速度,反而会拖慢构建速度,所以使用该loader时需要明确项目构建构成中真正耗时的过程。


我的项目中我主要是用该loader用来解析vue和js文件,作用于vue-loaderbabel-loader,如下代码:


const threadLoader = {
loader: 'thread-loader',
options: {
workers: require('os').cpus().length - 1,
}
}

module.exports = {
module:{
rules: [
{
test: /\.vue$/,
use: [
threadLoader, // vue-loader前使用该loader
{
loader: 'vue-loader',
options: vueLoaderConfig
}
],
},
{
test: /\.js$/,
use: [
threadLoader, // babel-loader前使用该loader
{
loader: 'babel-loader',
options: {
cacheDirectory: true
}
}
]
}
]
}
}


配置了thread-loader后,重新构建试试,如下图所示,大概缩短了10秒的构建时间,还不错。


image.png


利用缓存提升二次构建的速度


虽然使用了多进程构建项目使构建时间缩短了10秒,但是一分钟的构建时间依然让人无法接受,这种挤牙膏似的优化方式多少让人有点不爽,有没有比较爽的方法来进一步缩短构建时间呢?


答案是有的,使用缓存。


缓存,不难理解就是第一次构建的时候将构建的结果缓存起来,当第二构建时,查看对应缓存是否修改,如果没有修改,直接使用缓存,由此,我们可以想象,当项目的变化不大时,大部分缓存都是可复用的,拿构建的速度岂不是会有质的飞跃。


cache-loader


说到缓存,当然百度一查,最先出现的就是cache-loader,github搜索下官方文档,得到如下结果:


该loader会缓存其他loader的处理结果,把该loader放到其他loader的前面,同时该loader保存和读取缓存文件也会有开销,所以建议在开销较大的loader前使用该loader。


文档很简单,考虑到项目中的vue-loaderbabel-loadercss-loader会有比较大的开销,所以为这些loader加上缓存,那么接下来就把cache-loader加到项目中吧:


const cacheLoader = {
loader: 'cache-loader'
}

const threadLoader = {
loader: 'thread-loader',
options: {
workers: require('os').cpus().length - 1,
}
}

module.exports = {
module:{
rules: [
{
test: /\.vue$/,
use: [
cacheLoader,
threadLoader, // vue-loader前使用该loader
{
loader: 'vue-loader',
options: vueLoaderConfig
}
],
},
{
test: /\.js$/,
use: [
cacheLoader,
threadLoader, // babel-loader前使用该loader
{
loader: 'babel-loader',
options: {
cacheDirectory: true
}
}
]
}
]
}
}


util.js文件中,该文件主要是生成css相关的webpack配置,找到generateLoaders函数,修改如下:


  const cacheLoader = {
loader: 'cache-loader'
}

function generateLoaders(loader, loaderOptions) {
// 在css-loader前增加cache-loader
const loaders = options.usePostCSS ? [cacheLoader, cssLoader, postcssLoader] : [cacheLoader, cssLoader]

if (loader) {
loaders.push({
loader: loader + '-loader',
options: Object.assign({}, loaderOptions, {
sourceMap: options.sourceMap
})
})
}

// Extract CSS when that option is specified
// (which is the case during production build)
if (options.extract) {
return ExtractTextPlugin.extract({
use: loaders,
fallback: 'vue-style-loader',
// 添加这句配置解决element-ui的图标路径问题
publicPath: '../../'
})
} else {
return ['vue-style-loader'].concat(loaders)
}
}

如上配置完成后,再次启动项目,可以发现,现在的启动时间没什么变化,然后我们二次启动项目,可以发现现在的启动时间来到了30s左右,前面我们已经说过了,cache-loader缓存只有在二次启动的时候才会生效。


image.png


虽然项目启动时间优化了一半还多,但是我们的欲望是无限大的,30秒的时间离我们的预期还是有点差距的,继续优化!


hard-source-webpack-plugin


HardSourceWebpackPlugin是一个webpack插件,为模块提供中间缓存步骤。为了查看结果,您需要使用此插件运行webpack两次:第一次构建将花费正常的时间。第二次建设将大大加快。


话不多说,直接配置到项目中:


const HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
//...
plugins: [
new HardSourceWebpackPlugin()
]
}

image.png


二次构建时,我们会发现构建时间来到了个位数,只有短短的7秒钟。


在二次构建中,我发现了一个现象,构建的进度会从10% 一下跳到 80%,甚至是一瞬间就完成了中间构建过程。这正验证了该插件为模块提供中间缓存的说法。


为模块提供中间缓存,我的理解是cache-loader缓存的是对应loader的处理结果 ,而这个插件甚至可以缓存整个项目全部的处理结果,直接引用最终输出的缓存文件,从而大大提高构建速度。


其他优化方法


babel-loader开启缓存


babel-loader自带缓存功能,开启cacheDirectory配置项即可,官网的说法是,开启缓存会提高大约两倍的转换时间。


module.exports = {
module: {
rules: [
{
test: /\.js$/,
use: [
...
{
loader: 'babel-loader',
options: {
cacheDirectory: true // 开启缓存
}
}
]
}
]
}
}

uglifyjs-webpack-plugin开启多进程压缩


uglifyjs-webpack-plugin或是其他的代码压缩工具都提供了多进程压缩代码的功能,开启可加速代码压缩。


动态polyfill


建议查看该篇文章


一文搞清楚前端 polyfill


总结


至此,我们完成了项目构建时间从70s到7s的优化过程,文中主要使用:





























一步步的将项目优化到几乎立马启动,哎,看来这下摸鱼的时间又少了,加油干吧,打工人!


作者:进击的小超人
链接:https://juejin.cn/post/6979879230297341989

收起阅读 »

桌面上的Flutter:Electron又多了个对手

从本质上看,Flutter 是一个独立的二进制可执行文件。它不仅改变了移动设备的玩法,在桌面设备上也同样不可小觑。一次编写,可在 Android、iOS、Windows、Mac 和 Linux 上进行原生部署,并通过 AngularDart 将所有的业务逻辑共...
继续阅读 »

从本质上看,Flutter 是一个独立的二进制可执行文件。它不仅改变了移动设备的玩法,在桌面设备上也同样不可小觑。一次编写,可在 Android、iOS、Windows、Mac 和 Linux 上进行原生部署,并通过 AngularDart 将所有的业务逻辑共享到 Web 上,这也是它的一大特点。


原生桌面客户端加速移动开发

在进入真实的原生桌面应用程序之前,先让我们看看在桌面上运行的 Flutter 可以为开发移动设备的人们带来哪些好处。


 启动时间


首先是启动 Android 模拟器和运行 Gradle。


下面的动图记录了模拟器冷启动并运行默认的 Flutter 应用程序。我只截取了其中的 2 分 40 秒,可以看出来在那段时间内可以发生很多事情。



但如果我告诉你,你可以在不到 10 秒的时间内启动并运行应用程序,你会怎么想?


运行原生应用程序可以省去启动 Android 模拟器和运行 Gradle 的全部开销。


看看这个:



请注意,你不必离开 IntelliJ。我们开发了将 Flutter 作为原生应用程序所需的工具,它适用于所有的 Flutter IDE。


 在运行时调整大小

与其他应用程序一样,你需要测试不同大小的布局,那么你需要做些什么?


你要求你的朋友使用不同的手机或者创建一组模拟器,以确保你的布局在每台设备上都是正常的。


这对我来说是个麻烦事。我们能更简单一点吗?


可以!



 使用 PC 上的资源

在开发和测试需要与手机上的资源发生交互的应用程序时,首先需要将所有测试文件移动到模拟器或设备上,这样可能会非常烦人。


如果只需要使用原生文件选择器来选择你想要的文件会不会更好?



 热重载和调试

热重载和调试功能是每个高效率工程师所必须的。



 内存占用

对于使用笔记本电脑或配置不太好的电脑的人来说,内存是非常重要的。


Android 模拟器占用大约 1GB 的内存。现在想象一下,为了测试一个聊天应用程序或类似的程序,需要启动 IntelliJ 和狂吃内存的 Chrome。



因为嵌入器是以原生的方式运行,所以不需要 Android 模拟器。这使它的内存占用变得更小。



原生桌面应用

只是在桌面上运行一个 Flutter 应用程序对于可立即发布的成熟桌面应用程序来说是远远不够的。这样做感觉上就像在桌面上运行移动应用程序。


少了什么东西?很多!


悬停、光标变化、滚轮交互,等等。


我们设法在不改变任何平台代码的情况下实现这些功能——它是一个独立的软件包,可以被包含在任何普通的 Flutter 应用程序中。但是,当与桌面嵌入器一起使用时,奇迹就发生了!



这是在 Android 模拟器运行完全相同的代码的结果。



同时开发 Android 和桌面应用程序。



桌面小部件展示

悬停:



光标:



开发一个真正的跨平台应用——包括桌面
 小部件

你创建的大多数小部件都是普遍可用的,如按钮、加载指标器等。


那些需要根据平台呈现不同外观的小部件可以通过 TargetPlatform 属性进行封装,非常容易。


像 CursorWidget 这样的小部件也可以被包含在 Android 版本中。


 页面

根据平台和屏幕尺寸的不同,页面也会有很大差异。不过它们大多只是布局不同,而不是功能差异。


使用 PageLayoutWidget 可以轻松地为每个平台创建准确的布局。



默认情况下对平板电脑也提供了很好的支持。


 插件

使用同时支持桌面嵌入器的插件时,不需要修改 Flutter 代码。


 代码什么时候发布?

很快。不过这个项目仍然处于测试阶段,在不久的将来很可能会发生一些变化。


我们的目标是在不久的将来发布易于安装、设置和使用的产品。


作者:Q小Y
链接:https://juejin.cn/post/6844903744056852487
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

高效开发:分享 `extension` 有趣的用法

前言 extension 可以在不更改类或创建子类的情况下,向类添加扩展功能的一种方式。灵活使用 extension 对基础类进行扩展,对开发效率有显著提升。 举个栗子🌰,对 int 类型扩展 小轰在开发项目中碰到需求:将单位为分的数值转换成单位为元的字符串 ...
继续阅读 »

前言


extension 可以在不更改类或创建子类的情况下,向类添加扩展功能的一种方式。灵活使用 extension 对基础类进行扩展,对开发效率有显著提升。


举个栗子🌰,对 int 类型扩展


小轰在开发项目中碰到需求:将单位为分的数值转换成单位为元的字符串


/// 通常的写法,封装转换方法

///封装方法:金额转字符串 保留两位小数
String convertPointToUnit(int num){
return (num.toDouble() / 100).toStringAsFixed(2);
}

///使用
void main(){
int num = 100;
var result = convertPointToUnit(num);
print(result); //打印结果为 1.00
}

同样的功能,使用 extension 进行开发,会更加简洁,如下:


/// 使用 extension 对 int 类进行扩展,添加方法 moneyString
extension ExInt on int {
/// 金额转字符串 保留两位小数
/// 100 => 1.00
String get moneyString => (this.toDouble() / 100).toStringAsFixed(2);
}

import ../ExInt.dart;
///使用
void main(){
int num = 100;
print(num.moneyString);
}

扩展后,直接作为该类型的成员方法来被使用。extension 就像是基因赋值,直接将能力(方法)对宿主进行赠与。


各种场景的扩展演示



  • 对枚举进行扩展实现


enum FruitEnum { apple, banana }

extension ExFruitEnum on FruitEnum {
String get name {
switch (this) {
case FruitEnum.apple:
return "apple";
case FruitEnum.banana:
return "banana";
}
}
}

///字符串匹配枚举
FruitEnum generateFruit (String fruitType){
if(fruitType == FruitEnum.apple.name){
return FruitEnum.apple;
} else if(fruitType == FruitEnum.banana.name){
return FruitEnum.banana;
}
}


  • 扩展作用于泛型:


//扩展list的方法
extension ExList<T> on List<T> {
//扩展操作符
List<T> operator -() => reversed.toList();
//一个链表分割成两个
List<List<T>> split(int at) => <List<T>>[sublist(0, at), sublist(at)];
}


  • 扩展在 Widget 控件中的应用


我们会有类似的控件


Column(
children: <Widget>[
Container(
paddint: const EdgeInsets.all(10)
child: AWidget(),
),
Container(
paddint: const EdgeInsets.all(10)
child: BWidget(),
),
Container(
paddint: const EdgeInsets.all(10)
child: CWidget(),
),
]
)

代码中有很多的冗余对吧?我们用 extension 进行扩展一下:


extension ExWidget on Widget {
Widget paddingAll(double padding) {
return Container(
paddint: const EdgeInsets.all(padding)
child: this,
);
}
}

之后我们就可以改成:


Column(
children: <Widget>[
AWidget().paddingAll(10),
BWidget().paddingAll(10),
CWidget().paddingAll(10),
]
)

作者:李小轰_rex
链接:https://juejin.cn/post/7034439067269857294
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Android程序员如何从设计角度思考HTTPS

typora-root-url: img typora-copy-images-to: img 从设计角度思考HTTPS 我们了解了HTTP协议的内容后,明白HTTP存在很多安全隐患,所以后来推出了安全协议-HTTPS,我们不妨站在设计角度来设计一个安全的HT...
继续阅读 »
typora-root-url: img
typora-copy-images-to: img

从设计角度思考HTTPS


我们了解了HTTP协议的内容后,明白HTTP存在很多安全隐患,所以后来推出了安全协议-HTTPS,我们不妨站在设计角度来设计一个安全的HTTP连接协议,看看HTTP存在哪些问题,我们该如何设计能保证安全性,从而了解HTTPS的安全协议是如何保障的HTTP安全

首先我们需要考虑一下,实现HTTPS所谓的安全,我们需要保证那些地方的安全:


1.首先我们需要保证服务端和客户端之间发送的消息是安全的


2.其次我们要保证服务端和客户端之间的连接是安全的


3.最后我们还要保证服务端不会被其他的伪造客户端连接,并且通过此方式破解加密方式


服务端/客户端信息交互的安全


首先我们先来考虑一下,有什么方法可以保证客户端发送的消息给服务端并且服务端返回结果,这个过程是安全的,大概的过程如下:


image.png


这个时候我们最先想到的方案--加密,我们使用加密算法给数据加密了不就行了吗,那么该选择什么加密算法呢?开发过程中最常见的加密算法如:MD5、SHA1这样的摘要算法或者aes、des这样的对称加密算法,又或者rsa这样的非对称算法,看起来每一种都可以实现数据加密传输,但是我们不要忘记了,第三点中我们希望能保证其他客户端连接不会破解此种加密方式,要知道在互联网中,不是仅仅一台客户端和一个服务端交互,可以有无数台客户端同时与服务端交互,这个时候我们如果要防止别的客户端破解加密,看起来摘要算法这种不可逆的算法刚好合适,但是我们不要忘记了,客户端和服务端需要完成交互的,那么也就是说这个加密不能为不可逆算法,否则客户端也无法对服务端数据进行处理,服务端也无法处理客户端数据,那么只能是对称加密算法或者非对称加密算法能满足了,我们继续思考,如果是多台客户端同时连接服务端,如下图:


image.png


那么似乎哪一种加密都能满足,那么我们不禁有个问题,万一有黑客(恶意机器)拦截了我们的请求,并且充当了中间的传输者,我们的这两种加密算法还安全吗?如下图:


image.png


可以看到,我们的客户端和服务端中间被未知的恶意机器拦截转发了请求,那么我们之前的加密方式如果是直接传递的加密方式和密钥,如果是对称加密那么结局可想而知,对于中间机器来说,依然可以解密出客户端和服务端的消息,对于黑客来说依然是透明的,安全性仅仅比不加密强上一点点,完全不可以称之为可信任的安全协议,那么使用非对称加密呢?我们都知道非对称加密是一堆密钥,每一端持有自己的私钥,对外公开公钥,而公钥加密仅仅使用私钥才可以解密,这样即使有中间机器拦截,也仅仅能拿到客户端和服务端的公钥,但是我们不要忘记了,客户端应该是持有服务端的公钥,用公钥加密传输给服务端,服务端私钥解密,响应的过程即是客户端的私钥解密服务端持有的客户端公钥,中间机器即使拦截了双方的公钥,也无法解密双方公钥自身加密的信息,这样的话,客户端和服务端数据传输安全的问题似乎完美解决了


新隐患-公钥传输方式


刚刚我们经过对比,确定了使用公私钥方式的非对称加密来作为客户端-服务端传输的加密方式,看起来应该高枕无忧了,那么事实真的如此吗?其实和对称加密一样,非对称加密这样直接传输加密,也仅仅是提高了一点点安全性而已,如果遇到的黑客在拦截到客户端的请求后,将自身的公钥传递给服务端以及客户端,而将客户端/服务端的公钥持有会如何?是的,细极思恐,那样中间机器将拥有解密双端消息的能力!为什么会这样?试想一下,客户端使用所谓服务端的公钥加密消息,发送,被中间机器拦截后,这所谓的服务端公钥是中间机器的,那么私钥岂不是可以解密拿到明文信息?然后再伪装使用拦截到的真实的客户端的公钥加密,转发给服务端,同理,服务端的所谓客户端公钥加密对于中间机器完全形同虚设,那么这种问题如何解决呢?我们可不可以更换一种公钥传输方式,尽量绕开中间机器的拦截,保证安全性呢?


我们可以想下,大概有如下两种方法传输公钥:


1.服务端把公钥发送给每一个连接进来的客户端


2.将公钥放到一个地方(比如独立的服务器,或者文件系统),客户端需要获取公钥的时候,访问这个地方的公钥来和服务端进行匹配


而第一个方案,即我们刚刚推翻的方案,很明显会存在被拦截调包的可能,那么似乎我们只能使用第二个方案来传输公钥?那么我们不禁有个问题,即客户端是如何知道存放公钥的远程服务器地址以及认证加密方式,而且每次建立连接都要来获取一次,对服务器的抗压能力也有一定的考验?还有如何保证黑客等恶意访问的用户不能通过此种方式拿到公钥,所以安全也是个比较麻烦的问题


引入第三方CA机构


由于上述提到的问题,所以对于个人而言,如果在开发网站的同时,还要再花费大量金钱和精力在开发公钥服务上,是很不合理的,那么有木有专门做这个的公司,我们托管给这个公司帮我们完成,只需要付出金钱的代价就能体验到服务不可以吗?于是,专门负责证书认证的第三方CA机构出现了,我们只需要提前申请好对应的服务端信息,并且提交对应资料,付出报酬,CA就会给我们提供对应的服务端认证服务,大大减少我们的操作和复杂度,但是这个时候我们不禁又有个问题,CA机构能保证只有客户端拿到认证的证书,并且认证通过,拦截对应的非正常客户端吗?如果不能的话,那岂不是黑客也可以拿到认证?现在的问题开始朝着如何认证用户真伪方向发展了


验证证书有效性


其实想要解决认证的问题,我们可以从生活中寻找一些灵感,我们每个人都有一个唯一的id,证明身份,这样可以保证识别出id和对应的人,也能识别不法分子,那么,既然计算机来源于生活,设计出来的东西也应该遵循正常的逻辑,我们何不给每个证书设置类似id的唯一编号呢?当然计算机是死的,没办法简单的将机器和证书编号进行绑定,那么就需要设计一个符合逻辑的证书验证过程。我们不妨思考下,平时开发的软件为了识别被人篡改的软件,我们是如何做的,相信大脑里有个词会一闪而过,MD5/SHA1(签名)?没错,那么我们证书的认证可否按照这个思路设计?


现在我们假设,客户端拿到证书后,能够从证书上拿到公钥信息、证书签名hash和有效期等信息,也就是说证书内置了计算整个证书的签名hash值,如果此时我们根据客户端的签名算法进行一次加签计算,和证书默认计算好的hash比较,发现不一致,那么就说明证书被修改了,肯定不是第三方发布的正式证书,如果一致,说明证书是真实的,没有被篡改,我们可以尝试与服务端连接了,因为证书拿到了,也有了公钥,后续的就是加密通信的过程了


至此,似乎一个安全的加密https简陋的设计出来了,也似乎解决了这些安全问题,但是不得不提的一点是,我们上面有个很重要的一点,即存放证书的服务器一定要保证安全性,第三方机构算不算绝对安全呢?答案是否定的,因为在https至今的历史上,发生过第三方机构被黑客攻击成功,黑客使用的也是正版的证书的事件,只能说计算机的世界不存在绝对安全,而是相对来说,安全系数提高了太多


HTTPS认证过程


前面我们设计了简陋版的HTTPS,那么,我们接下来看看,正版的HTTPS大体认证过程是如何的,首先我们从申请证书开始:


image.png


可以看到,申请证书的时候,需要提供很多内容,其中域名、签名hash算法、加密算法是最重要的,通过这三项计算生成证书以及确定加密认证算法,并且在这个过程中还需要提供服务端自己的公钥,用来生成证书,CA机构使用自己的私钥加密证书,生成证书传递给服务端


2.证书申请拿到以后,客户端tcp三次握手连接(会携带一个随机数client-random),这个时候服务端将证书信息(包含过期时间、签名算法、当前证书的hash签名、服务端公钥、颁发证书机构等信息)传递给客户端,并且传递一个random随机数


3.客户端收到证书后,使用浏览器内置的CA认证,对证书的颁发机构逐个/逐层校验,确定证书来源正常,并且校验证书过期时间,确定是否可用,最后根据证书的签名算法,计算出对应的签名hash,和证书内置的签名hash比较,确定是否是未篡改的证书,完全认证通过后,证书认证环节结束


4.客户端生成随机对称密钥( pre-master ),将双端随机数组合通过证书的公钥(服务端的公钥)加密后,发送给服务端,服务端收到后,根据双方生成的随机数组合验证击进行http通信


以上就是HTTPS认证的大体流程,另外需要注意的是,HTTPS使用了签名算法(MD5/SHA256等)、对称加密以及非对称加密完成了整个交互过程,在认证过程中仅仅使用了签名算法和非对称加密保证建立通道的安全稳定,在通道建立过程中,维持了一个sessionid,用来防止频繁创建通道大量消耗资源,尽可能保证通道长期连接复用,并且我们需要知道一点,非对称加密虽然安全,但是相比较对称加密,加密解密步骤复杂导致时间会更久,所以HTTPS在建立通道以后,会选择双端协议使用对称加密来完成后续的数据交互,而上述提到的双方的随机对称密钥组合是用来在建立连接后的第一次交互的过程中,二次确认握手过程是否被篡改(客户端把Client.random + sever.random + pre-master组合后使用公钥加密,并且把握手消息根据证书的签名算法计算hash,发送给服务端确认握手过程是否被窜改),完成校验后,确定当前是安全连接后,双端之间就会使用约定好的对称加密算法进行数据加密解密传输,至此一个完整的HTTPS协议完成


相关视频


Android程序员中高级进阶学习/OkHttp原理分析


作者:传道士
链接:https://juejin.cn/post/7036654686371315725
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

做一个短链接系统需要考虑这么多

什么是短链接短链接顾名思义,就是一个比较短的链接(我好像说了个废话),我们平时看到的链接可能长这样:mp.weixin.qq.com/s?biz=MzU5M…又臭又长有没有(没错,这是我的WX公众号链接,可以关注一下),那如果我们需要将某个链接发在某个文章或者...
继续阅读 »



什么是短链接

短链接顾名思义,就是一个比较短的链接(我好像说了个废话),我们平时看到的链接可能长这样:

mp.weixin.qq.com/s?biz=MzU5M…

又臭又长有没有(没错,这是我的WX公众号链接,可以关注一下),那如果我们需要将某个链接发在某个文章或者推广给别人的时候,这么长看着也太不爽了,而短链接的出现就是用一个很短的URL来替代这个很长的家伙,当用户访问短链接的时候,会重定向到原来的链接。比如长下面这样:

sourl.cn/CsTkky

你如果平时有注意的话,各种商业短信上的链接也是会转成特别短的:

img

这个特别短的URL就是短链接。

为什么需要URL短链接

URL短链接用于为长URL创建较短的别名,我们称这些缩短的别名为“短链接”;当用户点击这些短链接时,会被重定向到原始URL;短链接在显示、打印、发送消息时可节省大量空间。

例如,如果我们通过sourl缩短以下URL:

juejin.cn/user/211951…

我们可以得到一个短链接:

sourl.cn/R99fbj

缩短的URL几乎是实际URL大小的三分之一。

URL缩写经常用于优化设备之间的链接,跟踪单个链接以分析受众,衡量广告活动的表现,或隐藏关联的原始URL。

如果你以前没有使用过sourl,可以尝试创建一个新的URL短链接,并花一些时间浏览一下他们的服务提供的各种选项。可以让你更好的理解这篇文章。

系统的要求和目标

在完成一个功能或者开发一个系统时,先确定系统的定位和要达到的目标是一个好的习惯,这可以让你在设计和开发过程中有更清晰的思路。

我们的短链接系统应满足以下要求:

功能要求:

  • 给定一个URL,我们的服务应该为其生成一个较短且唯一的别名,这叫做短链接,此链接应足够短,以便于复制和粘贴到应用程序中;

  • 当用户访问短链接时,我们的服务应该将他们重定向到原始链接;

  • 用户应该能够选择性地为他们的URL选择一个自定义的短链接;

  • 链接可以在指定时间跨度之后过期,用户应该能够指定过期时间。

非功能要求:

  • 系统必须高度可用。如果我们的服务关闭,所有URL重定向都将开始失败。

  • URL重定向的延迟情况应该足够小;

  • 短链接应该是不可猜测的。

扩展要求:

  • 支持分析和统计,例如短链接的访问次数;

  • 其他服务也应该可以通过RESTAPI访问我们的服务。

容量要求和限制

我们的系统将会有很大的访问量。会有对短链接的读取请求和创建短链接的写入请求。假设读写比例为100:1。

访问量预估:

假设我们每个月有5亿个新增短链接,读写比为100:1,我们可以预计在同一时间内有500亿重定向:

100 * 5亿 => 500亿

我们系统的QPS(每秒查询数量)是多少?每秒的新短链接为:

5亿/ (30天 * 24小时 * 3600 秒) ≈ 200 URLs/s

考虑到100:1读写比,每秒URL重定向将为:

100 * 200 URLs/s = 20000/s

存储预估:

假设我们将每个URL缩短请求(以及相关的缩短链接)存储5年。由于我们预计每个月将有5亿个新URL,因此我们预计存储的对象总数将为300亿:

5亿 * 5 年 * 12 月 = 300亿 

假设每个存储的对象大约有500个字节(这只是一个估算值)。我们将需要15TB的总存储:

300亿*500bytes≈15TB

带宽预估:

对于写请求,由于我们预计每秒有200个新的短链接创建,因此我们服务的总传入数据为每秒100KB:

200*500bytes≈100KB/s

对于读请求,预计每秒约有20,000个URL重定向,因此我们服务的总传出数据将为每秒10MB:

20000 * 500 bytes ≈10 MB/s

内存预估:

对于一些热门访问的URL为了提高访问速率,我们需要进行缓存,需要多少内存来存储它们?如果我们遵循二八原则,即20%的URL产生80%的流量,我们希望缓存这20%的热门URL。

由于我们每秒有20,000个请求,因此我们每天将收到17亿个请求:

20000 * 24 * 3600 ≈ 17亿

要缓存这些请求中的20%,我们需要170 GB的内存:

17亿 * 0.2 * 500bytes ≈ 170GB

这里需要注意的一件事是,由于将会有许多来自相同URL的重复请求,因此我们的实际内存使用量可能达不到170 GB。

整体来说,假设每月新增5亿个URL,读写比为100:1,我们的预估数据大概是下面这样:

类型预估数值
新增短链接200/s
短链接重定向20000/s
传入数据100KB/s
传出数据10 MB/s
存储5年容量15 TB
内存缓存容量170 GB

系统API设计

一旦我们最终确定了需求,就可以定义系统的API了,这里则是要明确定义我们的系统能提供什么服务。

我们可以使用REST API来公开我们服务的功能。以下是用于创建和删除URL的API的定义:

创建短链接接口

String createURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)
复制代码

参数列表:

api_dev_key:分配给注册用户的开发者密钥,可以根据该值对用户的创建短链接数量进行限制;

original_url:需要生成短链接的原始URL;

custom_alias :用户对于URL自定义的名称;

user_name :可以用在编码中的用户名;

expire_date :短链接的过期时间;

返回值:

成功生成短链接将返回短链接URL;否则,将返回错误代码。

删除短链接接口

String deleteURL(api_dev_key, url_key)
复制代码

其中url_key是表示要删除的短链接字符串;成功删除将返回delete success

如何发现和防止短链接被滥用?

恶意用户可以通过使用当前设计中的所有URL密钥来对我们进行攻击。为了防止滥用,我们可以通过用户的api_dev_key来限制用户。每个api_dev_key可以限制为每段时间创建一定数量的URL和重定向(可以根据开发者密钥设置不同的持续时间)。

数据模型设计

在开发之前完成数据模型的设计将有助于理解各个组件之间的数据流。

在我们短链接服务系统中的数据,存在以下特点:

  • 需要存储十亿条数据记录;

  • 存储的每个对象都很小(小于1K);

  • 除了存储哪个用户创建了URL之外,记录之间没有任何关系;

  • 我们的服务会有大量的读取请求。

我们需要创建两张表,一张用于存储短链接数据,一张用于存储用户数据;

img

应该使用怎样的数据库?

因为我们预计要存储数十亿行,并且不需要使用对象之间的关系-所以像mongoDB、Cassandra这样的NoSQL存储是更好的选择。选择NoSQL也更容易扩展。

基本系统设计与算法

现在需要解决的问题是如何为给定的URL生成一个简短且唯一的密钥。主要有两种解决方案:

  • 对原URL进行编码

  • 提前离线生成秘钥

对原URL编码

可以计算给定URL的唯一HASH值(例如,MD5或SHA256等)。然后可以对HASH进行编码以供显示。该编码可以是base36([a-z,0-9])base62([A-Z,a-z,0-9]),如果我们加上+/,就可以使用Base64编码。需要考虑的一个问题是短链接的长度应该是多少?6个、8个或10个字符?

使用Base64编码,6个字母的长密钥将产生64^6≈687亿个可能的字符串; 使用Base64编码,8个字母长的密钥将产生64^8≈281万亿个可能的字符串。

按照我们预估的数据,687亿对于我们来说足够了,所以可以选择6个字母。

如果我们使用MD5算法作为我们的HASH函数,它将产生一个128位的HASH值。在Base64编码之后,我们将得到一个超过21个字符的字符串(因为每个Base64字符编码6位HASH值)。

现在我们每个短链接只有6(或8)个字符的空间,那么我们将如何选择我们的密钥呢?

我们可以取前6(或8)个字母作为密钥,但是这样导致链接重复;要解决这个问题,我们可以从编码字符串中选择一些其他字符或交换一些字符。

我们的解决方案有以下问题:

解决办法:

我们可以将递增的序列号附加到每个输入URL以使其唯一,然后生成其散列。不过,我们不需要将此序列号存储在数据库中。此方法可能存在的问题是序列号不断增加会导致溢出。添加递增的序列号也会影响服务的性能。

另一种解决方案可以是将用户ID附加到输入URL。但是,如果用户尚未登录,我们将不得不要求用户选择一个唯一的key。即使这样也有可能有冲突,需要不断生成直到得到唯一的密钥。

离线生成秘钥

可以有一个独立的密钥生成服务,我们就叫它KGS(Key Generation Service),它预先生成随机的六个字母的字符串,并将它们存储在数据库中。每当我们想要生成短链接时,都去KGS获取一个已经生成的密钥并使用。这种方法更简单快捷。我们不仅不需要对URL进行编码,而且也不必担心重复或冲突。KGS将确保插入到数据库中的所有密钥都是唯一的。

会存在并发问题吗?

密钥一旦使用,就应该在数据库中进行标记,以确保不会再次使用。如果有多个服务器同时读取密钥,我们可能会遇到两个或多个服务器尝试从数据库读取相同密钥的情况。如何解决这个并发问题呢?

KGS可以使用两个表来存储密钥:一个用于尚未使用的密钥,一个用于所有已使用的密钥。

一旦KGS将密钥提供给其中一个服务器,它就可以将它们移动到已使用的秘钥表中;可以始终在内存中保留一些密钥,以便在服务器需要时快速提供它们。

为简单起见,一旦KGS将一些密钥加载到内存中,它就可以将它们移动到Used Key表中。这可确保每台服务器都获得唯一的密钥。

如果在将所有加载的密钥分配给某个服务器之前KGS重启或死亡,我们将浪费这些密钥,考虑到我们拥有的秘钥很多,这种情况也可以接受。

还必须确保KGS不将相同的密钥提供给多个服务器,因此,KGS将秘钥加载到内存和将秘钥移动到已使用表的动作需要时同步的,或者加锁,然后才能将秘钥提供给服务器。

KGS是否存在单点故障?

要解决KGS单点故障问题,我们可以使用KGS的备用副本。当主服务器死机时,备用服务器可以接管以生成和提供密钥。

每个应用服务器是否可以换成一些Key?

可以,这样可以减少对KGS的访问,不过,在这种情况下,如果应用服务器在使用所有密钥之前死亡,我们最终将丢失这些密钥。但是因为我们的秘钥数量很多,这点可以接受。

如何完成秘钥查找?

我们可以在数据库中查找密钥以获得完整的URL。如果它存在于数据库中,则向浏览器发回一个“HTTP302 Redirect”状态,将存储的URL传递到请求的Location字段中。如果密钥不在我们系统中,则发出HTTP 404 Not Found状态或将用户重定向回主页。

数据分区和复制

因为我们要存储十亿个URL数据,那么一个数据库节点在存储上可能不满足要求,并且单节点也不能支撑我们读取的要求。

因此,我们需要开发一种分区方案,将数据划分并存储到不同的数据库服务中。

基于范围分区:

我们可以根据短链接的第一个字母将URL存储在不同的分区中。因此,我们将所有以字母'A/a'开头的URL保存在一个分区中,将以字母‘B/b’开头的URL保存在另一个分区中,以此类推。这种方法称为基于范围的分区。我们甚至可以将某些不太频繁出现的字母合并到一个数据库分区中。

基于hash值分区:

在此方案中,我们对要存储的对象进行Hash计算。然后,我们根据Hash结果计算使用哪个分区。在我们的例子中,我们可以使用短链接的Hash值来确定存储数据对象的分区。

Hash函数会将URL随机分配到不同的分区中(例如,Hash函数总是可以将任何‘键’映射到[1…256]之间的一个数字,这个数字将表示我们在其中存储对象的分区。

这种方式有可能导致有些分区数据超载,可以使用一致性哈希算法解决。

缓存

对于频繁访问的热点URL我们可以进行缓存。缓存的方案可以使用现成的解决方案,比如使用memcached,Redis等,因此,应用服务器在查找数据库之前可以快速检查高速缓存是否具有所需的URL。

如果确定缓存容量?

可以从每天20%的流量开始,并根据客户端的使用模式调整所需的缓存服务器数量。如上所述,我们需要170 GB内存来缓存20%的日常流量。可以使用几个较小的服务器来存储所有这些热门URL。

选择哪种淘汰策略?

淘汰策略是指当缓存已满时,如果我们想用更热点的URL替换链接,我们该如何选择?

对于我们的系统来说,最近最少使用(LRU)是一个合理的策略。在此策略下,我们首先丢弃最近最少使用的URL;我们可以使用一个短链接或短链接的HASH值作为key的Hash Map或类似的数据结构来存储URL和访问次数。

如何更新缓存?

每当出现缓存未命中时,我们的服务器都会命中后端数据库。每次发生这种情况,我们都可以更新缓存并将新条目传递给所有缓存副本。每个副本都可以通过添加新条目来更新其缓存。如果副本已经有该条目,它可以简单地忽略它。

负载均衡

可以在系统中的三个位置添加负载均衡层:

  • 在客户端和应用程序服务器之间;

  • 在应用程序服务器和数据库服务器之间;

  • 在应用程序服务器和缓存服务器之间。

可以使用简单的循环调度方法,在后端服务器之间平均分配传入的请求。这种负载均衡方式实现起来很简单,并且不会带来任何开销。此方法的另一个好处是,如果服务器死机,负载均衡可以让其退出轮换,并停止向其发送任何流量。

循环调度的一个问题是没有考虑服务器过载情况。因此,如果服务器过载或速度慢,不会停止向该服务器发送新请求。要处理此问题,可以放置一个更智能的解决方案,定期查询后端服务器的负载并基于此调整流量。

数据清除策略

数据应该永远保留,还是应该被清除?如果达到用户指定的过期时间,短链接应该如何处理?

  • 持续扫描数据库,清除过期数据。

  • 懒惰删除策略

如果我们选择持续查询过期链接来删除,将会给数据库带来很大的压力;可以慢慢删除过期的链接,并进行懒惰的方式清理。服务确保只有过期的链接将被删除,尽管一些过期的链接可以在数据库保存更长时间,但永远不会返回给用户。

  • 每当用户尝试访问过期链接时,我们都可以删除该链接并向用户返回错误;

  • 单独的清理服务可以定期运行,从存储和缓存中删除过期的链接;

  • 此服务应该非常轻量级,并计划仅在预期用户流量较低时运行;

  • 我们可以为每个短链接设置默认的到期时间(例如两年);

  • 删除过期链接后,我们可以将密钥放回KGS的数据库中重复使用。

结语

以上就是开发一个短链接服务系统要做的方方面面,可能还存在一些小黑没有考虑到的地方,欢迎留言区交流!如果对你有一点点帮助,点个赞鼓励一下。

作者:小黑说Java
来源:https://juejin.cn/post/7034325565431611406

收起阅读 »

Python编程需要遵循的一些规则v2

Python编程需要遵循的一些规则v2使用 pylintpylint 是一个在 Python 源代码中查找 bug 的工具. 对于 C 和 C++ 这样的强类型静态语言来说, 这些 bug 通常由编译器来捕获. 由于 Python 的动态特性, 有些警告可能不...
继续阅读 »



Python编程需要遵循的一些规则v2

使用 pylint

pylint 是一个在 Python 源代码中查找 bug 的工具. 对于 C 和 C++ 这样的强类型静态语言来说, 这些 bug 通常由编译器来捕获. 由于 Python 的动态特性, 有些警告可能不对. 不过虚报的情况应该比较少. 确保对你的代码运行 pylint. 在 CI 流程中加入 pylint 检查的步骤. 抑制不准确的警告, 以便其他正确的警告可以暴露出来。

自底向上编程

自底向上编程(bottom up): 从最底层,依赖最少的地方开始设计结构及编写代码, 再编写调用这些代码的逻辑, 自底向上构造程序.

  • 采取自底向上的设计方式会让代码更少以及开发过程更加敏捷.

  • 自底向上的设计更容易产生符合单一责任原则(SRP) 的代码.

  • 组件之间的调用关系清晰, 组件更易复用, 更易编写单元测试案例.

如:需要编写调用外部系统 API 获取数据来完成业务逻辑的代码.

  • 应该先编写一个独立的模块将调用外部系统 API 获取数据的接口封装在一些函数中, 然后再编写如何调用这些函数 来完成业务逻辑.

  • 不可以先写业务逻辑, 然后在需要调用外部 API 时再去实现相关代码, 这会产生调用 API 的代码直 接耦合在业务逻辑中的代码.

防御式编程

使用 assert 语句确保程序处于的正确状态 不要过度使用 assert, 应该只用于确保核心的部分.

注意 assert 不能代替运行时的异常, 不要忘记 assert 语句可能会被解析器忽略.

assert 语句通常可用于以下场景:

  • 确保公共类或者函数被正确地调用 例如一个公共函数可以处理 list 或 dict 类型参数, 在函数开头使用 assert isinstance(param, (list, dict))确保函数接受的参数是 list 或 dict

  • assert 用于确保不变量. 防止需求改变时引起代码行为的改变

if target == x:
  run_x_code()
elif target == y:
  run_y_code()
else:
  run_z_code()

假设该代码上线时是正确的, target 只会是 x, y, z 三种情况, 但是稍后如果需求改变了, target 允许 w 的 情况出现. 当 target 为 w 时该代码就会错误地调用 run_z_code, 这通常会引起糟糕的后果.

  • 使用 assert 来确保不变量

assert target in (x, y, z)
if target == x:
  run_x_code()
elif target == y:
  run_y_code()
else:
  assert target == z
  run_z_code()

不使用 assert 的场景:

  • 不使用 assert 在校验用户输入的数据, 需要校验的情况下应该抛出异常

  • 不将 assert 用于允许正常失败的情况, 将 assert 用于检查不允许失败的情况.

  • 用户不应该直接看到 AssertionError, 如果用户可以看到, 将这种情况视为一个 BUG

避免使用 magic number

赋予特殊的常量一个名字, 避免重复地直接使用它们的字面值. 合适的时候使用枚举值 Enum.

使用常量在重构时只需要修改一个地方, 如果直接使用字面值在重构时将修改所有使用到的地方.

  • 建议

GRAVITATIONAL_CONSTANT = 9.81

def get_potential_energy(mass, height):
  return mass * height * GRAVITATIONAL_CONSTANT

class ConfigStatus:
  ENABLED = 1
  DISABLED = 0

Config.objects.filter(enabled=ConfigStatus.ENABLED)
  • 不建议

def get_potential_energy(mass, height):
  return mass * height * 9.81

# Django ORM
Config.objects.filter(enabled=1)

处理字典 key 不存在时的默认值

使用 dict.setdefault 或者 defaultdict

# group words by frequency
words = [(1, 'apple'), (2, 'banana'), (1, 'cat')]
frequency = {}

dict.setdefault

  • 建议

for freq, word in words:
  frequency.setdefault(freq, []).append(word)

或者使用 defaultdict

from collections import defaultdict

frequency = defaultdict(list)

for freq, word in words:
  frequency[freq].append(word)
  • 不建议

for freq, word in words:
  if freq not in frequency:
      frequency[freq] = []
  frequency[freq].append(word)

注意在 Python 3 中 map filter 返回的是生成器而不是列表, 在隋性计算方面有所区别

禁止使用 import *

原则上禁止避免使用 import *, 应该显式地列出每一个需要导入的模块

使用 import * 会污染当前命名空间的变量, 无法找到变量的定义是来哪个模块, 在被 import 的模块上的改动可 能会在预期外地影响到其它模块, 可能会引起难以排查的问题.

在某些必须需要使用或者是惯用法 from foo import * 的场景下, 应该在模块 foo 的末尾使用 all 控制被导出的变量.

# foo.py
CONST_VALUE = 1
class Apple:
  ...

__all__ = ("CONST_VALUE", "Apple")

# bar.py
# noinspection PyUnresolvedReferences
from foo import *

作者:未来现相
来源:https://mp.weixin.qq.com/s/QinR-bHolVlr0z8IyhCqfg

收起阅读 »

从零到一编写 IOC 容器

前言本文的编写主要是最近在使用 midway 编写后端应用,midway 的 IOC 控制反转能力跟我们平时常写的前端应用,例如 react、vue 这些单应用还是有蛮大区别的,所以促使我想一探究竟,这种类 Spring IOC 容器是如何用 JavaScri...
继续阅读 »




前言

本文的编写主要是最近在使用 midway 编写后端应用,midway 的 IOC 控制反转能力跟我们平时常写的前端应用,例如 react、vue 这些单应用还是有蛮大区别的,所以促使我想一探究竟,这种类 Spring IOC 容器是如何用 JavaScript 来实现的。为方便读者阅读,本文的组织结构依次为 TS 装饰器、Reflect Metadata、IOC 容器源码简单解读、以及自定义实现 IOC 容器。阅读完本文后,我希望你能有这样的感悟:元数据(metadata)和 装饰器(Decorator) 本是 ES 中两个独立的部分,但是结合它们, 竟然能实现 控制反转 这样的能力。本文的所有演示实例都已经上传到 github 仓库 ioc-container ,读者可以克隆下来进行调试运行。

辛苦整理良久,还望手动点赞鼓励~ 博客 github地址为:github.com/fengshi123/… ,汇总了作者的所有博客,欢迎关注及 star ~

一、TS 装饰器

1、类装饰器

(1)类型声明

type ClassDecorator = <TFunction extends Function>
(target: TFunction) => TFunction | void;
  • 参数:

    target: 类的构造器。

  • 返回:

如果类装饰器返回了一个值,它将会被用来代替原有的类构造器的声明。因此,类装饰器适合用于继承一个现有类并添加一些属性和方法。例如我们可以添加一个 toString 方法给所有的类来覆盖它原有的 toString 方法,以及增加一个新的属性 school,如下所示

type Consturctor = { new (...args: any[]): any };

function School<T extends Consturctor>(BaseClass: T) {
 // 新构造器继承原有的构造器,并且返回
 return class extends BaseClass {  
   // 新增属性 school
   public school = 'qinghua'
   // 重写方法 toString
   toString() {
     return JSON.stringify(this);
  }
};
}

@School
class Student {
 public name = 'tom';
 public age = 14;
}

console.log(new Student().toString())
// {"name":"tom","age":14,"school":"qinghua"}

但是存在一个问题:装饰器并没有类型保护,这意味着在类装饰器的构造函数中新增的属性,通过原有的类实例将报无法找到的错误,如下所示

type Consturctor = { new (...args: any[]): any };

function School<T extends Consturctor>(BaseClass: T){
 return class extends BaseClass {
   // 新增属性 school
   public school = 'qinghua'
};
}


@School
class Student{
 getSchool() {
   return this.school; // Property 'school' does not exist on type 'Student'
}
}

new Student().school  // Property 'school' does not exist on type 'Student'

这是 一个TypeScript的已知的缺陷。 目前我们能做的可以额外提供一个类用于提供类型信息,如下所示

type Consturctor = { new (...args: any[]): any };

function School<T extends Consturctor>(BaseClass: T){
 return class extends BaseClass {
   // 新增属性 school
   public school = 'qinghua'
};
}

// 新增一个类用于提供类型信息
class Base {
 school: string;
}

@School
class Student extends Base{
 getSchool() {
   return this.school;
}
}

new Student().school)

2、属性装饰器

(1)类型声明

type PropertyDecorator = (
target: Object,
 propertyKey: string | symbol
) => void;
复制代码
  • 参数:

    1. target: 对于静态成员来说是类的构造器,对于实例成员来说是类的原型链。

    2. propertyKey: 属性的名称。

  • 返回:

返回的结果将被忽略。

我们可以通过属性装饰器给属性添加对应的验证判断,如下所示

function NameObserve(target: Object, property: string): void {
 console.log('target:', target)
 console.log('property:', property)
 let _property = Symbol(property)
 Object.defineProperty(target, property, {
   set(val){
     if(val.length > 4){
       throw new Error('名称不能超过4位!')
    }
     this[_property] = val;
  },
   get: function() {
     return this[_property];
}
})
}

class Student {
 @NameObserve
 public name: string;  // target: Student {}   key: 'name'
}

const stu = new Student();
stu.name = 'jack'
console.log(stu.name); // jack
// stu.name = 'jack1'; // Error: 名称不能超过4位!

export default Student;

3、方法装饰器

(1)类型声明:

type MethodDecorator = <T>(
 target: Object,
 propertyKey: string | symbol,
 descriptor: TypedPropertyDescriptor<T>
) => TypedPropertyDescriptor<T> | void;
  • 参数:

    1. target: 对于静态成员来说是类的构造器,对于实例成员来说是类的原型链;

    2. propertyKey: 属性的名称;

    3. descriptor: 属性的描述器;

  • 返回: 如果返回了值,它会被用于替代属性的描述器。

方法装饰器不同于属性装饰器的地方在于 descriptor 参数。 通过这个参数我们可以修改方法原本的实现,添加一些共用逻辑。 例如我们可以给一些方法添加打印输入与输出的能力

function logger(target: Object, property: string, 
   descriptor: PropertyDescriptor): PropertyDescriptor | void {
 const origin = descriptor.value;
 console.log(descriptor)
 descriptor.value = function(...args: number[]){
   console.log('params:', ...args)
   const result = origin.call(this, ...args);
   console.log('result:', result);
   return result;
}
}

class Person {
 @logger
 add(x: number, y: number){
   return x + y;
}
}

const person = new Person();
const result = person.add(1, 2);
console.log('查看 result:', result) // 3

4、访问器装饰器

访问器装饰器总体上讲和方法装饰器很接近,唯一的区别在于描述器中有的 key 不同: 方法装饰器的描述器的 key 为:

  • value

  • writable

  • enumerable

  • configurable

访问器装饰器的描述器的key为:

  • get

  • set

  • enumerable

  • configurable

例如,我们可以对访问器进行统一更改:

function descDecorator(target: Object, property: string, 
   descriptor: PropertyDescriptor): PropertyDescriptor | void {
 const originalSet = descriptor.set;
 const originalGet = descriptor.get;
 descriptor.set = function(value: any){
   return originalSet.call(this, value)
}
 descriptor.get = function(): string{
   return 'name:' + originalGet.call(this)
}
}

class Person {
 private _name = 'tom';

 @descDecorator
 set name(value: string){
   this._name = value;
}

 get name(){
   return this._name;
}
}

const person = new Person();
person.name = ('tom');
console.log('查看:', person.name) // name:'tom'

5、参数装饰器

类型声明:

type ParameterDecorator = (
 target: Object,
 propertyKey: string | symbol,
 parameterIndex: number
) => void;
  • 参数:

    1. target: 对于静态成员来说是类的构造器,对于实例成员来说是类的原型链。

    2. propertyKey: 属性的名称(注意是方法的名称,而不是参数的名称)。

    3. parameterIndex: 参数在方法中所处的位置的下标。

  • 返回:

返回的值将会被忽略。

单独的参数装饰器能做的事情很有限,它一般都被用于记录可被其它装饰器使用的信息。

function ParamDecorator(target: Object, property: string, 
   paramIndex: number): void {
 console.log(property);
 console.log(paramIndex);
}

class Person {
 private name: string;

 public setNmae(@ParamDecorator school: string, name: string){  // setNmae 0
   this.name = school + '_' + name
}
}

6、执行时机

装饰器只在解释执行时应用一次,如下所示,这里的代码会在终端中打印 apply decorator,即便我们其实并没有使用类 A。

function f(C) {
 console.log('apply decorator')
 return C
}

@f
class A {}

// output: apply decorator

7、执行顺序

不同类型的装饰器的执行顺序是明确定义的:

  • 实例成员:参数装饰器 -> 方法/访问器/属性 装饰器

  • 静态成员:参数装饰器 -> 方法/访问器/属性 装饰器

  • 构造器:参数装饰器

  • 类装饰器

示例如下所示

function f(key: string): any {
 console.log("evaluate: ", key);
 return function () {
   console.log("call: ", key);
};
}

@f("Class Decorator")
class C {
 @f("Static Property")
 static prop?: number;

 @f("Static Method")
 static method(@f("Static Method Parameter") foo:any) {}

 constructor(@f("Constructor Parameter") foo:any) {}

 @f("Instance Method")
 method(@f("Instance Method Parameter") foo:any) {}

 @f("Instance Property")
 prop?: number;
}

/* 输出顺序如下
evaluate: Instance Method
evaluate: Instance Method Parameter
call: Instance Method Parameter
call: Instance Method
evaluate: Instance Property
call: Instance Property
evaluate: Static Property
call: Static Property
evaluate: Static Method
evaluate: Static Method Parameter
call: Static Method Parameter
call: Static Method
evaluate: Class Decorator
evaluate: Constructor Parameter
call: Constructor Parameter
call: Class Decorator
*/

我们从上注意到执行实例属性 prop 晚于实例方法 method 然而执行静态属性 static prop 早于静态方法static method。 这是因为对于属性/方法/访问器装饰器而言,执行顺序取决于声明它们的顺序。 然而,同一方法中不同参数的装饰器的执行顺序是相反的, 最后一个参数的装饰器会最先被执行。

function f(key: string): any {
 console.log("evaluate: ", key);
 return function () {
   console.log("call: ", key);
};
}

class C {
 method(
   @f("Parameter Foo") foo,
   @f("Parameter Bar") bar
) {}
}

/* 输出顺序如下
evaluate: Parameter Foo
evaluate: Parameter Bar
call: Parameter Bar
call: Parameter Foo
*/

8、多个装饰器组合

我们可以对同一目标应用多个装饰器。它们的组合顺序为:

  • 求值外层装饰器

  • 求值内层装饰器

  • 调用内层装饰器

  • 调用外层装饰器

如下示例所示

function f(key: string) {
 console.log("evaluate: ", key);
 return function () {
   console.log("call: ", key);
};
}

class C {
 @f("Outer Method")
 @f("Inner Method")
 method() {}
}

/* 输出顺序如下
evaluate: Outer Method
evaluate: Inner Method
call: Inner Method
call: Outer Method
*/

二、Reflect Metadata

1、背景

在 ES6 的规范当中,ES6 支持元编程,核心是因为提供了对 Proxy 和 Reflect 对象的支持。简单来说这个 API 的作用就是可以实现对变量操作的函数化,也就是反射。然而 ES6 的 Reflect 规范里面还缺失一个规范,那就是 Reflect Metadata。这会造成什么样的情境呢? 由于 JS/TS 现有的 装饰器更多的是存在于对函数或者属性进行一些操作,比如修改他们的值,代理变量,自动绑定 this 等等功能。但是却无法实现通过反射来获取究竟有哪些装饰器添加到这个类/方法上... 这就限制了 JS 中元编程的能力。 此时 Relfect Metadata 就派上用场了,可以通过装饰器来给类添加一些自定义的信息。然后通过反射将这些信息提取出来(当然你也可以通过反射来添加这些信息)。 综合一下, JS 中对 Reflect Metadata 的诉求,简单概括就是:

  • 其他 C#、Java、Pythone 语言已经有的高级功能,我 JS 也应该要有(诸如C# 和 Java 之类的语言支持将元数据添加到类型的属性或注释,以及用于读取元数据的反射API,而目前 JS 缺少这种能力)

  • 许多用例(组合/依赖注入,运行时类型断言,反射/镜像,测试)都希望能够以一致的方式向类中添加其他元数据。

  • 为了使各种工具和库能够推理出元数据,需要一种标准一致的方法;

  • 元数据不仅可以用在对象上,也可以通过相关捕获器用在 Proxy 上;

  • 对开发人员来说,定义新的元数据生成装饰器应该简洁易用;

2、使用

TypeScript 在 1.5+ 的版本已经支持 reflect-metadata,但是我们在使用的时候还需要额外进行安装,如下所示

  • npm i reflect-metadata --save

  • 在 tsconfig.json 里配置选项 emitDecoratorMetadata: true

关于 reflect-metadata 的基本使用 api 可以阅读 reflect-metadata 文档,其包含常见的增删改查基本功能,我们来看下其基本的使用示例,其中 Reflect.metadata 当作 Decorator 使用,当修饰类时,在类上添加元数据,当修饰类属性时,在类原型的属性上添加元数据,如:

import "reflect-metadata";

@Reflect.metadata('classMetaData', 'A')
class SomeClass {
 @Reflect.metadata('methodMetaData', 'B')
 public someMethod(): string {
   return 'hello someMethod';
}
}

console.log(Reflect.getMetadata('classMetaData', SomeClass)); // 'A'
console.log(Reflect.getMetadata('methodMetaData', new SomeClass(), 'someMethod')); // 'B

当然跟我们平时看到的 IOC 不同,我们进一步结合装饰器,如下所示,与前面的功能是一样的

import "reflect-metadata";

function classDecorator(): ClassDecorator {
 return target => {
   // 在类上定义元数据,key 为 `classMetaData`,value 为 `a`
   Reflect.defineMetadata('classMetaData', 'A', target);
};
}

function methodDecorator(): MethodDecorator {
 return (target, key, descriptor) => {
   // 在类的原型属性 'someMethod' 上定义元数据,key 为 `methodMetaData`,value 为 `b`
   Reflect.defineMetadata('methodMetaData', 'B', target, key);
};
}

@classDecorator()
class SomeClass {
 @methodDecorator()
 someMethod() {}
}

console.log(Reflect.getMetadata('classMetaData', SomeClass)); // 'A'
console.log(Reflect.getMetadata('methodMetaData', new SomeClass(), 'someMethod')); // 'B'

3、design:类型元数据

在 TS 中的 reflect-metadata 的功能是经过增强的,其添加 "design:type"、"design:paramtypes" 和 "design:returntype" 这 3 个类型相关的元数据

  • design:type 表示被装饰的对象是什么类型, 比如是字符串、数字、还是函数等;

  • design:paramtypes 表示被装饰对象的参数类型, 是一个表示类型的数组, 如果不是函数, 则没有该 key;

  • design:returntype 表示被装饰对象的返回值属性, 比如字符串、数字或函数等;

示例如下所示

import "reflect-metadata";

@Reflect.metadata('type', 'class')
class A {  
 constructor(
   public name: string,
   public age: number
) { }  

 @Reflect.metadata(undefined, undefined)  
 method(name: string, age: number):boolean {    
   return true  
}
}

 const t1 = Reflect.getMetadata('design:type', A.prototype, 'method')
 const t2 = Reflect.getMetadata('design:paramtypes', A.prototype, 'method')
 const t3 = Reflect.getMetadata('design:returntype', A.prototype, 'method')
 
 console.log(t1)  // [Function: Function]
 console.log(...t2) // [Function: String] [Function: Number]
 console.log(t3) // [Function: Boolean]

三、IOC 容器实现

1、源码解读

我们可以从 github 上克隆 midway 仓库的代码到本地,然后进行代码阅读以及 debug 调试。本篇博文我们主要想探究下 midway 的依赖注入合控制反转是如何实现的,其主要源码存在于两个目录:packages/core 和 packages/decorator,其中 packages/core 包含依赖注入的核心实现,加载对象的class,同步、异步创建对象实例化,对象的属性绑定等。 IOC 容器就像是一个对象池,管理着每个对象实例的信息(Class Definition),所以用户无需关心什么时候创建,当用户希望拿到对象的实例 (Object Instance) 时,可以直接拿到依赖对象的实例,容器会 自动将所有依赖的对象都自动实例化。packages/core 中主要有以下几种,分别处理不同的逻辑:

  • AppliationContext 基础容器,提供了基础的增加定义和根据定义获取对象实例的能力;

  • MidwayContainer 用的最多的容器,做了上层封装,通过 bind 函数能够方便的生成类定义,midway 从此类开始扩展;

  • RequestContainer 用于请求链路上的容器,会自动销毁对象并依赖另一个容器创建实例;

packages/decorator 包含装饰器 provide.ts、inject.ts 的实现,在midwayjs中是有一个装饰器管理类DecoratorManager, 用来管理 midwayjs 的所有装饰器:

  • @provide() 的作用是简化绑定,能被 IOC 容器自动扫描,并绑定定义到容器上,对应的逻辑是绑定对象定义;

  • @inject() 的作用是将容器中的定义实例化成一个对象,并且绑定到属性中,这样,在调用的时候就可以访问到该属性。

2、简单实现

2.1、装饰器 Provider

实现装饰器 Provider 类,作用为将对应类注册到 IOC 容器中。

import 'reflect-metadata'
import * as camelcase from 'camelcase'
import { class_key } from './constant'

// Provider 装饰的类,表示要注册到 IOC 容器中
export function Provider (identifier?: string, args?: Array<any>) {
 return function (target: any) {
   // 类注册的唯一标识符
   identifier = identifier ?? camelcase(target.name)

   Reflect.defineMetadata(class_key, {
     id: identifier,  // 唯一标识符
     args: args || [] // 实例化所需参数
  }, target)
   return target
}
}

2.2、装饰器 Inject

实现装饰器 Inject 类,作用为将对应的类注入到对应的地方。

import 'reflect-metadata'
import { props_key } from './constant'

export function Inject () {
 return function (target: any, targetKey: string) {
   // 注入对象
   const annotationTarget = target.constructor
   let props = {}
   // 同一个类,多个属性注入类
   if (Reflect.hasOwnMetadata(props_key, annotationTarget)) {
     props = Reflect.getMetadata(props_key, annotationTarget)
  }

   //@ts-ignore
   props[targetKey] = {
     value: targetKey
  }

   Reflect.defineMetadata(props_key, props, annotationTarget)
}
}

2.3、管理容器 Container

管理容器 Container 的实现,用于绑定实例信息并且在对应的地方获取它们。

import 'reflect-metadata'
import { props_key } from './constant'

export class Container {
 bindMap = new Map()

 // 绑定类信息
 bind(identifier: string, registerClass: any, constructorArgs: any[]) {
   this.bindMap.set(identifier, {registerClass, constructorArgs})
}

 // 获取实例,将实例绑定到需要注入的对象上
 get<T>(identifier: string): T {
   const target = this.bindMap.get(identifier)
   if (target) {
     const { registerClass, constructorArgs } = target
     // 等价于 const instance = new registerClass([...constructorArgs])
     const instance = Reflect.construct(registerClass, constructorArgs)

     const props = Reflect.getMetadata(props_key, registerClass)
     for (let prop in props) {
       const identifier = props[prop].value
       // 递归进行实例化获取 injected object
       instance[prop] = this.get(identifier)
    }
     return instance
  }
}
}

2.4、加载类文件 load

启动时扫描所有文件,获取文件导出的所有类,然后根据元数据进行绑定。

import * as fs from 'fs'
import { resolve } from 'path'
import { class_key } from './constant'

// 启动时扫描所有文件,获取定义的类,根据元数据进行绑定
export function load(container: any, path: string) {
 const list = fs.readdirSync(path)
 for (const file of list) {
   if (/\.ts$/.test(file)) {
     const exports = require(resolve(path, file))

     for (const m in exports) {
       const module = exports[m]
       if (typeof module === 'function') {
         const metadata = Reflect.getMetadata(class_key, module)
         // register
         if (metadata) {
           container.bind(metadata.id, module, metadata.args)
        }
      }
    }
  }
}
}

2.5、示例类

三个示例类如下所示

// class A
import { Provider } from "../provide";
import { Inject } from "../inject";
import B from './classB'
import C from './classC'

@Provider('a')
export default class A {
 @Inject()
 private b: B

 @Inject()
 c: C

 print () {
   this.c.print()
}
}

// class B
import { Provider } from '../provide'

@Provider('b', [10])
export default class B {
 n: number
 constructor (n: number) {
   this.n = n
}
}

// class C
import { Provider } from '../provide'

@Provider()
export default class C {
 print () {
   console.log('hello')
}
}

2.6、初始化

我们能从以下示例结果中看到,我们已经实现了一个基本的 IOC 容器能力。

import { Container } from './container'
import { load } from './load'
import { class_path } from './constant'

const init =  function () {

 const container = new Container()
 // 通过加载,会先执行装饰器(设置元数据),
 // 再由 container 统一管理元数据中,供后续使用
 load(container, class_path)
 const a:any = container.get('a') // A { b: B { n: 10 }, c: C {} }
 console.log(a);
 a.c.print() // hello
}

init()

总结

本文的依次从 TS 装饰器、Reflect Metadata、IOC 容器源码简单解读、以及自定义实现 IOC 容器四个部分由零到一编写自定义 IOC 容器,希望对你有所启发。本文的所有演示实例都已经上传到 github 仓库 ioc-container ,读者可以克隆下来进行调试运行。

作者:我是你的超级英雄
来源:https://juejin.cn/post/7036895697865555982

收起阅读 »

300行代码实现循环滚动控件

序言在业务中需要显示一个循环滚动的控件,内容可以循环滚动,可以自动滚动,手指触摸的时候会暂停。 由于目前的方案都是基于ViewPager或者RecycleView的。还需要实现Adapter,需要拦截各种事件。使用成本比较高。于是我就自定义了一个控件实现该功能...
继续阅读 »

序言

在业务中需要显示一个循环滚动的控件,内容可以循环滚动,可以自动滚动,手指触摸的时候会暂停。 由于目前的方案都是基于ViewPager或者RecycleView的。还需要实现Adapter,需要拦截各种事件。使用成本比较高。于是我就自定义了一个控件实现该功能,

使用

使用起来很简单。把需要显示的控件放置在其中就行。就和普通的HorizontalScrollView用法一样。 不过子控件必须要LoopLinearLayout 在这里插入图片描述

效果

  • 1.支持左右循环滚动
  • 2.支持自动滚动
  • 3.支持点击事件
  • 4.触摸暂停
  • 5.支持惯性滚动
  • 6.一共不到300行代码,逻辑简单易于扩展

在这里插入图片描述

原理

通过继承自HorizontalScrollView实现,重新onOverScrolled 和 scrollTo 方法在调用supper方法之前,对是否到达边界进行判断,如果到达就调用LoopLinearLayout.changeItemsToRight() 方法对内容重新摆放。

摆放使用的是 child.layout() 的方法,没有性能问题。摆放完成以后,对scrollX进行重新赋值。

需要注意的是在HorizontalScrollView中有一个负责惯性滚动的OverScroller 在这里插入图片描述 但是在调用其fling方法之前会设置maxX这导致无法滚动到控件内容之外。所以使用反射修改了这个类。拦截了fling方法 在这里插入图片描述

而动画的时长设置的是滚动一个LoopScrollView宽度需要的时间。还有就是无限循环的动画需要在 onDetachedFromWindow中移除,避免内存泄漏

源码

LoopLinearLayout

package com.example.myapplication;

import android.content.Context;
import android.util.AttributeSet;
import android.view.View;
import android.view.ViewGroup;
import android.widget.LinearLayout;

import androidx.annotation.Nullable;

import java.util.List;

/**
* Created by zhuguohui
* Date: 2021/11/30
* Time: 10:46
* Desc:
*/
public class LoopLinearLayout extends LinearLayout {
public LoopLinearLayout(Context context) {
this(context, null);
}

public LoopLinearLayout(Context context, @Nullable AttributeSet attrs) {
super(context, attrs);
}


public void changeItemsToRight(List<View> moveItems, int offset) {

int offset2 = 0;
for (int i = 0; i < getChildCount(); i++) {
View childAt = getChildAt(i);
if (!moveItems.contains(childAt)) {
MarginLayoutParams layoutParams = (MarginLayoutParams) childAt.getLayoutParams();
offset2 += childAt.getWidth() + layoutParams.leftMargin + layoutParams.rightMargin;
childAt.layout(childAt.getLeft() - offset, childAt.getTop(), childAt.getRight() - offset, childAt.getBottom());
}
}
for(View view:moveItems){
view.layout(view.getLeft()+offset2,view.getTop(),view.getRight()+offset2,view.getBottom());
}
}
public void changeItemsToLeft(List<View> moveItems, int offset) {

int offset2 = 0;
for (int i = 0; i < getChildCount(); i++) {
View childAt = getChildAt(i);
if (!moveItems.contains(childAt)) {
MarginLayoutParams layoutParams = (MarginLayoutParams) childAt.getLayoutParams();
offset2 += childAt.getWidth() + layoutParams.leftMargin + layoutParams.rightMargin;
childAt.layout(childAt.getLeft() + offset, childAt.getTop(), childAt.getRight() + offset, childAt.getBottom());
}
}
for(View view:moveItems){
view.layout(view.getLeft()-offset2,view.getTop(),view.getRight()-offset2,view.getBottom());
}
}


}

LoopScrollView

package com.example.myapplication;

import android.animation.Animator;
import android.animation.AnimatorListenerAdapter;
import android.animation.ValueAnimator;
import android.annotation.SuppressLint;
import android.content.Context;
import android.util.AttributeSet;
import android.view.MotionEvent;
import android.view.View;
import android.view.animation.LinearInterpolator;
import android.widget.HorizontalScrollView;
import android.widget.OverScroller;

import java.lang.reflect.Field;
import java.util.ArrayList;
import java.util.List;

public class LoopScrollView extends HorizontalScrollView {

private LoopScroller loopScroller;
private ValueAnimator animator;

public LoopScrollView(Context context) {
this(context, null);
}

public LoopScrollView(Context context, AttributeSet attrs) {
super(context, attrs);
setOverScrollMode(OVER_SCROLL_ALWAYS);
try {
@SuppressLint("DiscouragedPrivateApi")
Field field =HorizontalScrollView.class.getDeclaredField("mScroller");
field.setAccessible(true);
loopScroller = new LoopScroller(getContext());
field.set(this, loopScroller);

} catch (Exception e) {
e.printStackTrace();
}

}

@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
super.onLayout(changed, l, t, r, b);
if(changed||animator==null){
buildAnimation();
}
}

private void buildAnimation() {
if(animator!=null){
animator.cancel();
animator=null;
}
animator = ValueAnimator.ofInt(getWidth() - getPaddingRight() - getPaddingLeft());
animator.setDuration(5*1000);
animator.setRepeatCount(-1);
animator.setInterpolator(new LinearInterpolator());
animator.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
int lastValue;
@Override
public void onAnimationUpdate(ValueAnimator animation) {
int value= (int) animation.getAnimatedValue();
int scrollByX=value-lastValue;
// Log.i("zzz","scroll by x="+scrollByX);
scrollByX=Math.max(0,scrollByX);
if(userUp) {
scrollBy(scrollByX, 0);
}
lastValue=value;
}
});
animator.addListener(new AnimatorListenerAdapter() {
@Override
public void onAnimationEnd(Animator animation) {
super.onAnimationEnd(animation);
}

@Override
public void onAnimationStart(Animator animation) {
super.onAnimationStart(animation);
}

});
animator.start();
}

static class LoopScroller extends OverScroller{
public LoopScroller(Context context) {
super(context);
}

@Override
public void fling(int startX, int startY, int velocityX, int velocityY, int minX, int maxX, int minY, int maxY, int overX, int overY) {
super.fling(startX, startY, velocityX, velocityY, Integer.MIN_VALUE,Integer.MAX_VALUE, minY, maxY, 0, overY);
}
}




@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
if(animator!=null){
animator.cancel();
animator.removeAllListeners();
animator = null;
}
}

@Override
protected void onOverScrolled(int scrollX, int scrollY, boolean clampedX, boolean clampedY) {
if (userUp) {
//scroller再滚动
scrollX=loopScroller.getCurrX();
int detailX = scrollX - lastScrollX;
lastScrollX = scrollX;
if(detailX==0){
return;
}
scrollX = detailX + getScrollX();

}
int moveTo = moveItem(scrollX,clampedX);

super.onOverScrolled(moveTo, scrollY, false, clampedY);
}

boolean userUp = true;
int lastScrollX = 0;

@Override
public boolean onTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_UP) {
userUp = true;
lastScrollX = getScrollX();
} else {
userUp = false;
}
return super.onTouchEvent(ev);
}
@Override
public void scrollTo(int x, int y) {
int scrollTo = moveItem(x, false);
super.scrollTo(scrollTo, y);
}


private int moveItem(int scrollX, boolean clampedX) {

int toScrollX = scrollX;

if (getChildCount() > 0) {
if (!canScroll(scrollX,clampedX)) {
boolean toLeft=scrollX<=0;
int mWidth=getWidth()-getPaddingLeft()-getPaddingRight();
//无法向右滚动了,将屏幕外的item,移动到后面
List<View> needRemoveViewList = new ArrayList<>();
LoopLinearLayout group = (LoopLinearLayout) getChildAt(0);
int removeItemsWidth = 0;
boolean needRemove = false;
for (int i = group.getChildCount() - 1; i >= 0; i--) {
View itemView = group.getChildAt(i);
MarginLayoutParams params = (MarginLayoutParams) itemView.getLayoutParams();
if(toLeft){
int itemLeft = itemView.getLeft() - params.leftMargin;
if (itemLeft >= mWidth) {
//表示之后的控件都需要移除
needRemove = true;
}
}else{
int itemRight = itemView.getRight() + params.rightMargin;
if (itemRight <= scrollX) {
//表示之后的控件都需要移除
needRemove = true;
}
}

if (needRemove) {
int itemWidth = itemView.getWidth() + params.rightMargin + params.leftMargin;
removeItemsWidth += itemWidth;
needRemoveViewList.add(0,itemView);
}
needRemove=false;
}
if(!toLeft){
group.changeItemsToRight(needRemoveViewList,removeItemsWidth);
toScrollX -=removeItemsWidth;
}else{
group.changeItemsToLeft(needRemoveViewList,removeItemsWidth);
toScrollX +=removeItemsWidth;
}

}

}
return Math.max(0, toScrollX);
}

private boolean canScroll(int scrollX, boolean clampedX) {
if(scrollX<0){
return false;
}
if(scrollX==0&&clampedX){
//表示向左划不动了
return false;
}
View child = getChildAt(0);
if (child != null) {
int childWidth = child.getWidth();
return getWidth() + scrollX < childWidth + getPaddingLeft() + getPaddingRight();
}
return false;
}
}

最后所有的功能只依赖上述两个类,关于动画的时长写死在类中的,没有抽成方法。有需要的自己去改吧。


作者:solo_99
链接:https://juejin.cn/post/7036262704482353160
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

synchronized 的实现原理

synchronized 的使用 锁代码块(锁对象可指定,可为this、XXX.class、全局变量) 锁普通方法(锁对象是this,即该类实例本身) 锁静态方法(锁对象是该类,即XXX.class) 锁代码块 public class Sync { ...
继续阅读 »

synchronized 的使用



  • 锁代码块(锁对象可指定,可为this、XXX.class、全局变量)

  • 锁普通方法(锁对象是this,即该类实例本身)

  • 锁静态方法(锁对象是该类,即XXX.class)


锁代码块


public class Sync {

private int a = 0;

public void add(){
synchronized (this){
System.out.println("a values "+ ++a);
}
}

}

反编译之后的


public add()V
TRYCATCHBLOCK L0 L1 L2 null
TRYCATCHBLOCK L2 L3 L2 null
ALOAD 0
DUP
ASTORE 1
MONITORENTER
L0
GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
LDC "a values "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 0
DUP
GETFIELD com/arrom/webview/Sync.a : I
ICONST_1
IADD
DUP_X1
PUTFIELD com/arrom/webview/Sync.a : I
INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V
ALOAD 1
MONITOREXIT
L1
GOTO L4
L2
ASTORE 2
ALOAD 1
MONITOREXIT
L3
ALOAD 2
ATHROW
L4
RETURN
MAXSTACK = 5
MAXLOCALS = 3
}

由反编译结果可以看出:synchronized代码块主要是靠MONITORENTERMONITOREXIT这两个原语来实现同步的。当线程进入MONITORENTER获得执行代码的权利时,其他线程就不能执行里面的代码,直到锁Owner线程执行MONITOREXIT释放锁后,其他线程才可以竞争获取锁。


MONITORENTER

每个对象有一个监视器锁(monitor)。当monitor被占用时就会处于锁定状态,线程执行monitorenter指令时尝试获取monitor的所有权.



  1. 如果monitor的进入数为0,则该线程进入monitor,然后将进入数设置为1,该线程即为monitor的所有者。

  2. 如果线程已经占有该monitor,只是重新进入,则进入monitor的进入数加1.

  3. 如果其他线程已经占用了monitor,则该线程进入阻塞状态,直到monitor的进入数为0,再重新尝试获取monitor的所有权。


第2点就涉及到了可重入锁,意思就是说当一个线程已经获取一个锁时,它可以再获取无数次,从代码的角度上将就是有无数个相同的synchronized语句块嵌套在一起。在进入时,monitor的进入数+1;退出时就-1,直到为0的时候才可以被其他线程竞争获取。


MONITOREXIT

执行MONITOREXIT的线程必须是objectref所对应的monitor的所有者。


指令执行时,monitor的进入数减1,如果减1后进入数为0,那线程退出monitor,不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。


锁普通方法


public class Sync {

private int a = 0;

public synchronized void add(){
System.out.println("a values "+ ++a);
}

}

反编译之后并没有monitorenter和monitorexit,但是常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的:


当方法调用时会检查方法的ACC_SYNCHRONIZED之后才能执行方法体,方法执行完后再释放monitor。


在方法执行期间,其他任何线程都无法再获得同一个monitor对象。这种方式与语句块没什么本质区别,都是通过竞争monitor的方式实现的。只不过这种方式是隐式的实现方法。


MONITORENTER和ACC_SYNCHRONIZED只是起标志作用,并无实质操作。


锁静态方法



private static int a = 0;

public synchronized static void add(){
System.out.println("a values "+ ++a);
}

常量池中用ACC_STATIC标志了这是一个静态方法,然后用ACC_SYNCHRONIZED标志位提醒线程去竞争monitor。由于静态方法是属于类级别的方法(即不用创建对象就可以被调用),所以这是一个类级别(XXX.class)的锁,即竞争某个类的monitor。


锁的竞争过程


image.png



  • (1)、多个线程请求锁,首先进入Contention List,它可以接纳所有请求线程,而且是一个后进先出(LIFO)的虚拟队列,通过结点Node和next指针构造。

  • (2)(3)、ContentionList会被线程并发访问,EntryList为了降低线程对ContentionList队尾的争用而构造出来。当Owner释放锁时,会从ContentionList中迁移线程到EntryList,并会指定EntryList中的某个线程(一般为Head结点)为Ready Thread,也就是说某个时刻最多只有一个线程正在竞争锁。

  • (4)、Owner并不是直接把锁交给OnDeck线程,而是将竞争锁的权利交给OnDeck(将锁释放了),然后让OnDeck自己去竞争。竞争成功后,OnDeck线程就变成Owner;否则继续留在EntryList的队头。

  • (5)(6)、当线程调用wait方法被阻塞时,进入WaitSet;当其他线程调用notifyAll()(notify())方法后,阻塞队列的(某个)线程就会进入EntryList中。


      处于ContetionList、EntryList、WaitSet的线程均处于阻塞状态。而线程被阻塞涉及到用户态与内核态的切换(Liunx),系统切换严重影响锁的性能。解决这个问题的办法就是自旋。自旋就是线程不断进行内部循环,即for循环什么也不做,防止线程wait()阻塞,在自旋过程中不断尝试获取锁,如果自旋期间,Owner刚好释放锁,此时自旋线程就可以去竞争锁。如果自旋了一段时间还没获取到锁,那没办法,只能调用wait()阻塞了。 

为什么自旋了一段时间后又调用wait()方法呢?因为自旋是要消耗CPU的,而且还有线程上下文切换,因为CPU还可以调度线程,只不过执行的是空的for循环罢了。 

对自旋锁周期的选择上,HotSpot认为最佳时间应是一个线程上下文切换的时间,但目前并没有做到。 

所以,synchronized是什么时候进行自旋的?答案是在进入ContetionList之前,因为它自旋一定时间后还没获取锁,最后它只好在ContetionList中阻塞等待了。


对象头


对象头(Object Header)包括两部分信息。


一部分用于存储对象自身的运行时数据, 如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等,这部分数据的长度在32位和64位的虚拟机(暂 不考虑开启压缩指针的场景)中分别为32个和64个Bits,官方称它为“Mark Word”。


对象需要存储的运行时数据很多,其实已经超出了32、64位Bitmap结构所能记录的限度,但是对象头信息是与对象自身定义的数据无关的额 外存储成本,考虑到虚拟机的空间效率,Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息,它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机 中对象未被锁定的状态下,Mark Word的32个Bits空间中的25Bits用于存储对象哈希码(HashCode),4Bits用于存储对象分代年龄,2Bits用于存储锁标志 位,1Bit固定为0,在其他状态(轻量级锁定、重量级锁定、GC标记、可偏向)下对象的存储内容如下表所示。


image.png


另外一部分是类型指针,即是对象指向它的类的元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针,换句话说查找对象的元数据信息并不一定要经过对象本身。另外,如果对象是一个Java数组,那在对象头中还必须有一块用于记录数组长度的数据,因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小,但是从数组的元数据中无法确定数组的大小。


为了减少锁释放带来的消耗,锁有一个升级的机制,从轻到重依次是:无锁状态 ——> 偏向锁 ——> 轻量级锁 ——>重量级锁。


偏向锁


在无其它线程与它竞争的情况下,持有偏向锁的线程永远也不需要同步。


它的加锁过程很简单:线程访问同步代码块时检查偏向锁中线程ID是否指向自己,如果是表明该线程已获得锁;否则,检测偏向锁标记是否为1,不是的话则CAS竞争锁,如果是就将对象头中线程ID指向自己。


当存在线程竞争锁时,偏向锁才会撤销,转而升级为轻量级锁。而这个撤销过程则需要有一个全局安全点(即这个时间点上没有正在执行的字节码)


image.png


在撤销锁的时候,栈中对象头的Mark Word要么偏向于其他线程,要么恢复到无锁或者轻量级锁。



  • 优点:加锁和解锁无需额外消耗

  • 缺点:锁进化时会带来额外锁撤销的消耗

  • 适用场景:只有一个线程访问同步代码块


轻量级锁


image.png



  • 优点:竞争的线程不阻塞,也就是不涉及到用户态与内核态的切换(Liunx),减少系统切换锁带来的开销

  • 缺点:如果长时间竞争不到锁,自旋会消耗CPU

  • 适用场景:追求响应时间、同步块执行速度非常快


重量级锁


它是传统意义上的锁,通过互斥量来实现同步,线程阻塞,等待Owner释放锁唤醒。




  • 优点:线程竞争不自旋,不消耗CPU




  • 缺点:线程阻塞,响应时间慢




  • 适用场景:追求吞吐量、同步块执行时间较长


作者:深圳_Arrom
链接:https://juejin.cn/post/7036354740342489118
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Jetpack-Lifecycle

1.AndroidX 的ComponentActivity 实现了LifecycleOwner接口,ComponentActivity 的子类会重写LifecycleOwner的接口方法,以便得到我们使用的lifecycle对象,lifecycle 是在Com...
继续阅读 »

图片.png


1.AndroidX 的ComponentActivity 实现了LifecycleOwner接口,ComponentActivity 的子类会重写LifecycleOwner的接口方法,以便得到我们使用的lifecycle对象,lifecycle 是在ComponentActivity 中创建的lifecycleRegistry对象;


2.使用的时候,通过lifecycleRegistry对象addObserver的方式注册LifecycleObserver,当生命周期变化的时候,会回调LifecycleObserver的onStateChanged, 里面的Lifecycle.Event能监听到当前Activity不同生命周期的变化


原理:


1.lifecycle注册的时候,会初始化observer的状态State,初始状态是 initial或者destroy, 将observer和state封装成一个类作为map的value值, observer作为key;


2.addObserver还有一个状态对齐,等会讲


3.当宿主activity或者fragment生命周期发生变化的时候,会分发当前的生命周期事件,转换成对应的mState,


3.1 和当前map中最早添加的observer的state进行比较,如果mState小于 state的值, 说明当前执行的是OnResume->onPause->onStop->onDestroy中的某一个环节, 遍历当前的map,将map的state向下更新为当前的生命周期状态,并调用observer的onStateChange方法;


3.2 和当前map中最后添加的observer的state进行比较,如果mState大于 state的值, 说明当前执行的是onCreate->onStart->onResume中的某一个环节, 遍历当前的map,将map的state向上更新为当前的生命周期状态,并调用observer的onStateChange方法;


3.3 状态对齐, 比如:当我们在生命周期的onStop方法中去addObserver时,此时添加到map中的state是inital状态, 实际上当前的生命周期是onStop,对应的是Created状态, 此时需要将map中小于Created的状态更新成Created状态,因为是upEvent, 所以回调的event会有onCreate


小结: 1.创建一个state保存到map; 2.等生命周期变化时,更新state的值,回调onStateChanged方法,达到监控生命周期的作用


作者:朱络嗒
链接:https://juejin.cn/post/7036552818668339208
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Glide数据输入输出

基础概念 在正式开始之前先明确一些概念 Glide输入: 我们日常在使用Glide的时候,通过load可以加载不同的资源类型例如文件,字符串等待。 我们把load的不同类型称为不同的输入。 Glide输出: Glide RequestManager提供了许多...
继续阅读 »

基础概念


在正式开始之前先明确一些概念


Glide输入: 我们日常在使用Glide的时候,通过load可以加载不同的资源类型例如文件,字符串等待。


requestManager多个load重载.png


我们把load的不同类型称为不同的输入。


Glide输出: Glide RequestManager提供了许多的as重载方法,


GlideAs方法.png


通过不同的as我们可以指定不同的输出类型。


ModelLoader: 是一个泛型接口,最直观的翻译是模型加载器。ModelLoader标记了它能够加载什么类型的数据,以及加载后返回什么样的数据类型。注意这里说说的返回的数据类型并不是我们想要的输出。ModelLoader定义如下


public interface ModelLoader<Model, Data> {
 class LoadData<Data> {
     //数据加载的key
   public final Key sourceKey;
   public final List<Key> alternateKeys;
     //获取数据的接口,对应获取不同类型的数据实现
   public final DataFetcher<Data> fetcher;

   public LoadData(@NonNull Key sourceKey, @NonNull DataFetcher<Data> fetcher) {
     this(sourceKey, Collections.<Key>emptyList(), fetcher);
  }

   public LoadData(@NonNull Key sourceKey, @NonNull List<Key> alternateKeys,
       @NonNull DataFetcher<Data> fetcher) {
     this.sourceKey = Preconditions.checkNotNull(sourceKey);
     this.alternateKeys = Preconditions.checkNotNull(alternateKeys);
     this.fetcher = Preconditions.checkNotNull(fetcher);
  }
}

   //创建LoadData 对象
 @Nullable
 LoadData<Data> buildLoadData(@NonNull Model model, int width, int height,
     @NonNull Options options);
   //判断当前的ModelLoader是否能够处理这个model
 boolean handles(@NonNull Model model);
}

DataFetcher: 用于进行数据加载,不同的类型有不同的DataFetcher


SourceGenerator远程数据加载过程


@Override
public boolean startNext() {
 //...
 boolean started = false;
 while (!started && hasNextModelLoader()) {
   loadData = helper.getLoadData().get(loadDataListIndex++);
   if (loadData != null
       && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
       || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
     started = true;
     loadData.fetcher.loadData(helper.getPriority(), this);
  }
}
 return started;
}

代码流程:


通过DecodeHelper获取LoadData,遍历每一个LoadData;


查看当前LoadData加载出来的数据能不能,转换成我们想要的输出数据,如果可以的话就是用当前loadData进行数据加载。


DecodeHelpe#getLoadData()


List<LoadData<?>> getLoadData() {
 if (!isLoadDataSet) {
   isLoadDataSet = true;
   loadData.clear();
     //此处的model就是我们 通过调用load传递进来的参数 即输入
   List<ModelLoader<Object, ?>> modelLoaders = glideContext.getRegistry().getModelLoaders(model);
   //noinspection ForLoopReplaceableByForEach to improve perf
   for (int i = 0, size = modelLoaders.size(); i < size; i++) {
     ModelLoader<Object, ?> modelLoader = modelLoaders.get(i);
     //通过modelLoader 构建loadData
     LoadData<?> current =
         modelLoader.buildLoadData(model, width, height, options);
     if (current != null) {
       loadData.add(current);
    }
  }
}
 return loadData;
}

ModelLoaderRegistry#getModelLoaders


getModelLoaders()实现的位置在ModelLoaderRegistry#getModelLoaders


public <A> List<ModelLoader<A, ?>> getModelLoaders(@NonNull A model) {
   //获取对应的modelLoader
 List<ModelLoader<A, ?>> modelLoaders = getModelLoadersForClass(getClass(model));
 int size = modelLoaders.size();
 boolean isEmpty = true;
 List<ModelLoader<A, ?>> filteredLoaders = Collections.emptyList();
 //noinspection ForLoopReplaceableByForEach to improve perf
 for (int i = 0; i < size; i++) {
   ModelLoader<A, ?> loader = modelLoaders.get(i);
     //判断对应的modelLoader是否有能力处理对应的model
   if (loader.handles(model)) {
     if (isEmpty) {
       filteredLoaders = new ArrayList<>(size - i);
       isEmpty = false;
    }
     filteredLoaders.add(loader);
  }
}
 return filteredLoaders;
}

getModelLoadersForClass主要是通过MultiModelLoaderFactory#build。然后MultiModelLoaderFactory会遍历所有已经注册的ModelLoader,只要当前的model是已经注册model的子类或者对应的实现,那么就会把对应的ModelLoader添加到待返回的集合中。


DecodeHelper#hasLoadPath


boolean hasLoadPath(Class<?> dataClass) {
   return getLoadPath(dataClass) != null;
}

<Data> LoadPath<Data, ?, Transcode> getLoadPath(Class<Data> dataClass) {
 return glideContext.getRegistry().getLoadPath(dataClass, resourceClass, transcodeClass);
}

可以看到hasLoadPath代码其实非常简单,就是获取一个LoadPath集合。获取的时候传递了三个参数 DataFetcher加载出来的数据类型dataClass,resourceClass ,transcodeClass


getLoadPath参数


对于resourceClass ,transcodeClass在DecodeHelper定义如下:


private Class<?> resourceClass;
private Class<Transcode> transcodeClass;

他们在init方法中进行初始化,经过层层代码的流转我们发现最终的参数初始化来自于RequestBuilder#obtainRequest


private Request obtainRequest(
     Target<TranscodeType> target,
     RequestListener<TranscodeType> targetListener,
     BaseRequestOptions<?> requestOptions,
     RequestCoordinator requestCoordinator,
     TransitionOptions<?, ? super TranscodeType> transitionOptions,
     Priority priority,
     int overrideWidth,
     int overrideHeight,
     Executor callbackExecutor) {
   return SingleRequest.obtain(
       context,
       glideContext,
       model,
       //该参数会在调用as系列方法后初始化,指向的是我们想要的输出类型。
       transcodeClass,
       //指向的是RequestBuilder 自身
       requestOptions,
       overrideWidth,
       overrideHeight,
       priority,
       target,
       targetListener,
       requestListeners,
       requestCoordinator,
       glideContext.getEngine(),
       transitionOptions.getTransitionFactory(),
       callbackExecutor);
}

而RequestOptions#getResourceClass返回的resourceClass默认情况下返回的是Object,而在asBitmap和asGifDrawable会做其它的转换。


private static final RequestOptions DECODE_TYPE_BITMAP = decodeTypeOf(Bitmap.class).lock();
private static final RequestOptions DECODE_TYPE_GIF = decodeTypeOf(GifDrawable.class).lock();

@NonNull
 @CheckResult
 public RequestBuilder<Bitmap> asBitmap() {
   return as(Bitmap.class).apply(DECODE_TYPE_BITMAP);
}
 public RequestBuilder<GifDrawable> asGif() {
   return as(GifDrawable.class).apply(DECODE_TYPE_GIF);
}

getLoadPath执行过程


getLoadPath最终会调用Registry#getLoadPath


@Nullable
public <Data, TResource, Transcode> LoadPath<Data, TResource, Transcode> getLoadPath(
   @NonNull Class<Data> dataClass, @NonNull Class<TResource> resourceClass,
   @NonNull Class<Transcode> transcodeClass) {
   //先获取DecodePath  
 List<DecodePath<Data, TResource, Transcode>> decodePaths =
       getDecodePaths(dataClass, resourceClass, transcodeClass);
   if (decodePaths.isEmpty()) {
     result = null;
  } else {
     result =
         new LoadPath<>(
             dataClass, resourceClass, transcodeClass, decodePaths, throwableListPool);
  }
   loadPathCache.put(dataClass, resourceClass, transcodeClass, result);
 return result;
}

private <Data, TResource, Transcode> List<DecodePath<Data, TResource, Transcode>> getDecodePaths(
     @NonNull Class<Data> dataClass, @NonNull Class<TResource> resourceClass,
     @NonNull Class<Transcode> transcodeClass) {
   List<DecodePath<Data, TResource, Transcode>> decodePaths = new ArrayList<>();
   //遍历所有资源解码器,获取能够解析当前输入dataClass的解码器
   List<Class<TResource>> registeredResourceClasses =
       decoderRegistry.getResourceClasses(dataClass, resourceClass);
   for (Class<TResource> registeredResourceClass : registeredResourceClasses) {
       //获取能够解析当前输入dataClass且将数据转变成我们想要的transcodeClass类型的转换类
     List<Class<Transcode>> registeredTranscodeClasses =
         transcoderRegistry.getTranscodeClasses(registeredResourceClass, transcodeClass);

     for (Class<Transcode> registeredTranscodeClass : registeredTranscodeClasses) {
//获取对应的所有解码器
       List<ResourceDecoder<Data, TResource>> decoders =
           decoderRegistry.getDecoders(dataClass, registeredResourceClass);
       //转换类
       ResourceTranscoder<TResource, Transcode> transcoder =
           transcoderRegistry.get(registeredResourceClass, registeredTranscodeClass);
       @SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")
       DecodePath<Data, TResource, Transcode> path =
           new DecodePath<>(dataClass, registeredResourceClass, registeredTranscodeClass,
               decoders, transcoder, throwableListPool);
       decodePaths.add(path);
    }
  }
   return decodePaths;
}

整个过程涉及到两个关键类LoadPath DecodePath。


LoadPath 由数据类型datacalss 和 DecodePath组成


DecodePath 由数据类型dataclass 解码器 ResourceDecoder 集合 和资源转换 ResourceTranscoder 构成。总体上而言 一个LoadPath的存在代表着可能存在一条路径能够将ModelLoader加载出来的data解码转换成我们指定的数据类型。


DocodeJob数据解码的过程


Glide DecodeJob 的工作过程我们知道SourceGenerator在数据加载完成之后如果允许缓存原始数据会再次执行SourceGenerator#startNext将加载的数据进行缓存,然后通过DataCacheGenerator从缓存文件中获取。最终获取数据成功后会调用DocodeJob#onDataFetcherReady


作者:小小小小小鹿
链接:https://juejin.cn/post/7036389645168410655
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

大厂面试Kafka,一定会问到的幂等性

01 幂等性如此重要 Kafka作为分布式MQ,大量用于分布式系统中,如消息推送系统、业务平台系统(如结算平台),就拿结算来说,业务方作为上游把数据打到结算平台,如果一份数据被计算、处理了多次,产生的后果将会特别严重。 02 哪些因素影响幂等性...
继续阅读 »

01 幂等性如此重要


Kafka作为分布式MQ,大量用于分布式系统中,如消息推送系统、业务平台系统(如结算平台),就拿结算来说,业务方作为上游把数据打到结算平台,如果一份数据被计算、处理了多次,产生的后果将会特别严重。

02 哪些因素影响幂等性


使用Kafka时,需要保证exactly-once语义。要知道在分布式系统中,出现网络分区是不可避免的,如果kafka broker 在回复ack时,出现网络故障或者是full gc导致ack timeout,producer将会重发,如何保证producer重试时不造成重复or乱序?又或者producer 挂了,新的producer并没有old producer的状态数据,这个时候如何保证幂等?即使Kafka 发送消息满足了幂等,consumer拉取到消息后,把消息交给线程池workers,workers线程对message的处理可能包含异步操作,又会出现以下情况:


  • 先commit,再执行业务逻辑:提交成功,处理失败 。造成丢失




  • 先执行业务逻辑,再commit:提交失败,执行成功。造成重复执行




  • 先执行业务逻辑,再commit:提交成功,异步执行fail。造成丢失




本文将针对以上问题作出讨论


03 Kafka保证发送幂等性


       针对以上的问题,kafka在0.11版新增了幂等型producer和事务型producer。前者解决了单会话幂等性等问题,后者解决了多会话幂等性。


单会话幂等性


为解决producer重试引起的乱序和重复。Kafka增加了pid和seq。Producer中每个RecordBatch都有一个单调递增的seq; Broker上每个tp也会维护pid-seq的映射,并且每Commit都会更新lastSeq。这样recordBatch到来时,broker会先检查RecordBatch再保存数据:如果batch中 baseSeq(第一条消息的seq)比Broker维护的序号(lastSeq)大1,则保存数据,否则不保存(inSequence方法)。

ProducerStateManager.scala


    private def maybeValidateAppend(producerEpoch: Short, firstSeq: Int, offset: Long): Unit = {

    validationType match {

    case ValidationType.None =>

    case ValidationType.EpochOnly =>

    checkProducerEpoch(producerEpoch, offset)

    case ValidationType.Full =>

    checkProducerEpoch(producerEpoch, offset)

    checkSequence(producerEpoch, firstSeq, offset)

    }

    }

    private def checkSequence(producerEpoch: Short, appendFirstSeq: Int, offset: Long): Unit = {

    if (producerEpoch != updatedEntry.producerEpoch) {

    if (appendFirstSeq != 0) {

    if (updatedEntry.producerEpoch != RecordBatch.NO_PRODUCER_EPOCH) {

    throw new OutOfOrderSequenceException(s"Invalid sequence number for new epoch at offset $offset in " +

    s"partition $topicPartition: $producerEpoch (request epoch), $appendFirstSeq (seq. number)")

    } else {

    throw new UnknownProducerIdException(s"Found no record of producerId=$producerId on the broker at offset $offset" +

    s"in partition $topicPartition. It is possible that the last message with the producerId=$producerId has " +

    "been removed due to hitting the retention limit.")

    }

    }

    } else {

    val currentLastSeq = if (!updatedEntry.isEmpty)

    updatedEntry.lastSeq

    else if (producerEpoch == currentEntry.producerEpoch)

    currentEntry.lastSeq

    else

    RecordBatch.NO_SEQUENCE

    if (currentLastSeq == RecordBatch.NO_SEQUENCE && appendFirstSeq != 0) {

ne throw mew UnknownProducerIdException(s"Local producer state matches expected epoch $producerEpoch " +

    s"for producerId=$producerId at offset $offset in partition $topicPartition, but the next expected " +

    "sequence number is not known.")

    } else if (!inSequence(currentLastSeq, appendFirstSeq)) {

    throw new OutOfOrderSequenceException(s"Out of order sequence number for producerId $producerId at " +

    s"offset $offset in partition $topicPartition: $appendFirstSeq (incoming seq. number), " +

    s"$currentLastSeq (current end sequence number)")

    }

    }

    }

    private def inSequence(lastSeq: Int, nextSeq: Int): Boolean = {

    nextSeq == lastSeq + 1L || (nextSeq == 0 && lastSeq == Int.MaxValue)

    }



引申:Kafka producer 对有序性做了哪些处理


假设我们有5个请求,batch1、batch2、batch3、batch4、batch5;如果只有batch2 ack failed,3、4、5都保存了,那2将会随下次batch重发而造成重复。我们可以设置max.in.flight.requests.per.connection=1(客户端在单个连接上能够发送的未响应请求的个数)来解决乱序,但降低了系统吞吐。
新版本kafka设置enable.idempotence=true后能够动态调整max-in-flight-request。正常情况下max.in.flight.requests.per.connection 大于1。当重试请求到来且时,batch 会根据 seq重新添加到队列的合适位置,并把max.in.flight.requests.per.connection设为1, 这样它 前面的 batch序号都比它小,只有前面的都发完了,它才能发。

    private void insertInSequenceOrder(Deque<ProducerBatch> deque, ProducerBatch batch) {

    // When we are requeing and have enabled idempotence, the reenqueued batch must always have a sequence.

    if (batch.baseSequence() == RecordBatch.NO_SEQUENCE)

    throw new IllegalStateException("Trying to re-enqueue a batch which doesn't have a sequence even " +

    "though idempotency is enabled.");

    if (transactionManager.nextBatchBySequence(batch.topicPartition) == null)

    throw new IllegalStateException("We are re-enqueueing a batch which is not tracked as part of the in flight " +

    "requests. batch.topicPartition: " + batch.topicPartition + "; batch.baseSequence: " + batch.baseSequence());

    ProducerBatch firstBatchInQueue = deque.peekFirst();

    if (firstBatchInQueue != null && firstBatchInQueue.hasSequence() && firstBatchInQueue.baseSequence() < batch.baseSequence()) {

    List<ProducerBatch> orderedBatches = new ArrayList<>();

    while (deque.peekFirst() != null && deque.peekFirst().hasSequence() && deque.peekFirst().baseSequence() < batch.baseSequence())

    orderedBatches.add(deque.pollFirst());

    log.debug("Reordered incoming batch with sequence {} for partition {}. It was placed in the queue at " +

    "position {}", batch.baseSequence(), batch.topicPartition, orderedBatches.size())

    deque.addFirst(batch);

    // Now we have to re insert the previously queued batches in the right order.

    for (int i = orderedBatches.size() - 1; i >= 0; --i) {

    deque.addFirst(orderedBatches.get(i));

    }

    // At this point, the incoming batch has been queued in the correct place according to its sequence.

    } else {

    deque.addFirst(batch);

    }

    }


多会话幂等性


在单会话幂等性中介绍,kafka通过引入pid和seq来实现单会话幂等性,但正是引入了pid,当应用重启时,新的producer并没有old producer的状态数据。可能重复保存。

Kafka事务通过隔离机制来实现多会话幂等性


kafka事务引入了transactionId 和Epoch,设置transactional.id后,一个transactionId只对应一个pid, 且Server 端会记录最新的 Epoch 值。这样有新的producer初始化时,会向TransactionCoordinator发送InitPIDRequest请求, TransactionCoordinator 已经有了这个 transactionId对应的 meta,会返回之前分配的 PID,并把 Epoch 自增 1 返回,这样当old
producer恢复过来请求操作时,将被认为是无效producer抛出异常。     如果没有开启事务,TransactionCoordinator会为新的producer返回new pid,这样就起不到隔离效果,因此无法实现多会话幂等。

    private def maybeValidateAppend(producerEpoch: Short, firstSeq: Int, offset: Long): Unit = {

    validationType match {

    case ValidationType.None =>

    case ValidationType.EpochOnly =>

    checkProducerEpoch(producerEpoch, offset)

    case ValidationType.Full => //开始事务,执行这个判断

    checkProducerEpoch(producerEpoch, offset)

    checkSequence(producerEpoch, firstSeq, offset)

    }

    }

    private def checkProducerEpoch(producerEpoch: Short, offset: Long): Unit = {

    if (producerEpoch < updatedEntry.producerEpoch) {

    throw new ProducerFencedException(s"Producer's epoch at offset $offset is no longer valid in " +

    s"partition $topicPartition: $producerEpoch (request epoch), ${updatedEntry.producerEpoch} (current epoch)")

    }

    }


04 Consumer端幂等性


如上所述,consumer拉取到消息后,把消息交给线程池workers,workers对message的handle可能包含异步操作,又会出现以下情况:


  • 先commit,再执行业务逻辑:提交成功,处理失败 。造成丢失




  • 先执行业务逻辑,再commit:提交失败,执行成功。造成重复执行




  • 先执行业务逻辑,再commit:提交成功,异步执行fail。造成丢失




对此我们常用的方法时,works取到消息后先执行如下code:


    if(cache.contain(msgId)){

    // cache中包含msgId,已经处理过

    continue;

    }else {

    lock.lock();

    cache.put(msgId,timeout);

    commitSync();

    lock.unLock();

    }

    // 后续完成所有操作后,删除cache中的msgId,只要msgId存在cache中,就认为已经处理过。Note:需要给cache设置有消息


作者:WeCoding
链接:https://juejin.cn/post/6844903909153062926
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Toast必须在UI(主)线程使用?

背景 依稀记得,从最开始干Android这一行就经常听到有人说:toast(吐司)不能在子线程调用显示,只能在UI(主)线程调用展示。 非常惭愧的是,我之前也这么认为,并且这个问题也一直没有深究。 直至前两天我的朋友 “林小海” 同学说toast不能在子线程中...
继续阅读 »

背景


依稀记得,从最开始干Android这一行就经常听到有人说:toast(吐司)不能在子线程调用显示,只能在UI(主)线程调用展示。


非常惭愧的是,我之前也这么认为,并且这个问题也一直没有深究。


直至前两天我的朋友 “林小海” 同学说toast不能在子线程中显示,这句话使我突然想起了点什么。


我觉得我有必要证明、并且纠正一下。


toast不能在子线程调用展示的结论真的是谬论~


疑点


前两天在说到这个toast的时候一瞬间对于只能在UI线程中调用展示的说法产生了两个疑点:




  1. 在子线程更新UI一般都会有以下报错提示:


    Only the original thread that created a view hierarchy can touch its views.


    但是,我们在子线程直接toast的话,报错的提示如下:


    Can't toast on a thread that has not called Looper.prepare()


    明显,两个报错信息是不一样的,从toast这条来看的话是指不能在一个没有调用Looper.prepare()的线程里面进行toast,字面意思上有说是不能在子线程更新UI吗?No,没有!这也就有了下面第2点的写法。




  2. 曾见过一种在子线程使用toast的用法如下(正是那时候没去深究这个问题):




        new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
Toast.makeText(MainActivity.this.getApplicationContext(),"SHOW",Toast.LENGTH_SHORT).show();
Looper.loop();
}
}).start();

关于Looper这个东西,我想大家都很熟悉了,我就不多说looper这块了,下面主要分析一下为什么这样的写法就可以在子线程进行toast了呢?


并且Looper.loop()这个函数调用后是会阻塞轮循的,这种写法是会导致线程没有及时销毁,在toast完之后我特意给大家用如下代码展示一下这个线程的状态:


    Log.d("Wepon", "isAlive:"+t[0].isAlive());
Log.d("Wepon", "state:" + t[0].getState());

D/Wepon: isAlive:true
D/Wepon: state:RUNNABLE

可以看到,线程还活着,没有销毁掉。当然,这种代码里面如果想要退出looper的循环以达到线程可以正常销毁的话是可以使用looper.quit相关的函数的,但是这个调用quit的时机却是不好把握的。


下面将通过Toast相关的源码来分析一下为什么会出现上面的情况?


源码分析


Read the fuck source code.


1.分析Toast.makeText()方法


首先看我们的调用Toast.makeText,makeText这个函数的源码:


    // 这里一般是我们外部调用Toast.makeText(this, "xxxxx", Toast.LENGTH_SHORT)会进入的方法。
// 然后会调用下面的函数。
public static Toast makeText(Context context, CharSequence text, @Duration int duration) {
return makeText(context, null, text, duration);
}

/**
* Make a standard toast to display using the specified looper.
* If looper is null, Looper.myLooper() is used. // 1. 注意这一句话
* @hide
*/
public static Toast makeText(@NonNull Context context, @Nullable Looper looper,
@NonNull CharSequence text, @Duration int duration) {

// 2. 构造toast实例,有传入looper,此处looper为null
Toast result = new Toast(context, looper);

LayoutInflater inflate = (LayoutInflater)
context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);
TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);
tv.setText(text);

result.mNextView = v;
result.mDuration = duration;

return result;
}

从上面的源码中看第1点注释,looper为null的时候会调用Looper.myLooper(),这个方法的作用是取我们线程里面的looper对象,这个调用是在Toast的构造函数里面发生的,看我们的Toast构造函数:


2.分析Toast构造函数


    /**
* Constructs an empty Toast object. If looper is null, Looper.myLooper() is used.
* @hide
*/
public Toast(@NonNull Context context, @Nullable Looper looper) {
mContext = context;
// 1.此处创建一个TN的实例,传入looper,接下来主要分析一下这个TN类
mTN = new TN(context.getPackageName(), looper);
mTN.mY = context.getResources().getDimensionPixelSize(
com.android.internal.R.dimen.toast_y_offset);
mTN.mGravity = context.getResources().getInteger(
com.android.internal.R.integer.config_toastDefaultGravity);
}

TN的构造函数如下,删除了一部分不重要代码:


TN(String packageName, @Nullable Looper looper) {
// .....
// ..... 省略部分源码,这
// .....

// 重点
// 2.判断looper == null,这里我们从上面传入的时候就是null,所以会进到里面去。
if (looper == null) {
// Use Looper.myLooper() if looper is not specified.
// 3.然后会调用Looper.myLooper这个函数,也就是会从ThreadLocal<Looper> sThreadLocal 去获取当前线程的looper。
// 如果ThreadLocal这个不太清楚的可以先去看看handler源码分析相关的内容了解一下。
looper = Looper.myLooper();
if (looper == null) {
// 4.这就是报错信息的根源点了!!
// 没有获取到当前线程的looper的话,就会抛出这个异常。
// 所以分析到这里,就可以明白为什么在子线程直接toast会抛出这个异常
// 而在子线程中创建了looper就不会抛出异常了。
throw new RuntimeException(
"Can't toast on a thread that has not called Looper.prepare()");
}
}
// 5.这里不重点讲toast是如何展示出来的源码了,主要都在TN这个类里面,
// Toast与TN中间有涉及aidl跨进程的调用,这些可以看看源码。
// 大致就是:我们的show方法实际是会往这个looper里面放入message的,
// looper.loop()会阻塞、轮循,
// 当looper里面有Message的时候会将message取出来,
// 然后会通过handler的handleMessage来处理。
mHandler = new Handler(looper, null) {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
// .... 省略代码
case SHOW: // 显示,与WindowManager有关,这部分源码不做说明了,可以自己看看,就在TN类里面。
case HIDE: // 隐藏
case CANCEL: // 取消
}
}
};
}

总结


从第1点可以看到会创建TN的实例,并传入looper,此时的looper还是null。


进入TN的构造函数可以看到会有looper是否为null的判断,并且在当looper为null时,会从当前线程去获取looper(第3点,Looper.myLooper()),如果还是获取不到,刚会抛出我们开头说的这个异常信息:Can't toast on a thread that has not called Looper.prepare()。


而有同学会误会只能在UI线程toast的原因是:UI(主)线程在刚创建的时候就有创建looper的实例了,在主线程toast的话,会通过Looper.myLooper()获取到对应的looper,所以不会抛出异常信息。


而不能直接在子线程程中toast的原因是:子线程中没有创建looper的话,去通过Looper.myLooper()获取到的为null,就会throw new RuntimeException(
"Can't toast on a thread that has not called Looper.prepare()");


另外,两个点说明一下:



  1. Looper.prepare() 是创建一个looper并通过ThreadLocal跟当前线程关联上,也就是通过sThreadLocal.set(new Looper(quitAllowed));

  2. Looper.loop()是开启轮循,有消息就会处理,没有的话就会阻塞。


综上,“Toast必须在UI(主)线程使用”这个说法是不对滴!,以后千万不要再说toast只能在UI线程显示啦.....


作者:ywp0919
链接:https://juejin.cn/post/6844904103538065422
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

手把手教你用Flutter搭建属于自己的个人博客

Flutter 2.0以来已经稳定支持web的开发,现在来教大家使用Flutter搭建一个个人的博客网站,使用Github提供的Actions、gh-pages服务,毕竟一时白票一时爽,一直白嫖一直爽。 1. 使用AndoridStuido创建一个Flutte...
继续阅读 »

Flutter 2.0以来已经稳定支持web的开发,现在来教大家使用Flutter搭建一个个人的博客网站,使用Github提供的Actions、gh-pages服务,毕竟一时白票一时爽,一直白嫖一直爽。


1. 使用AndoridStuido创建一个Flutter项目


Dingtalk_20210512195651.jpg


2. Github注册一个账号,并且创建一个Repository


Dingtalk_20210512195915.jpg


3. 上传创建的Flutter项目到这个Repository的master分支中


4. 获取Github的access token


新建一个access token
Dingtalk_20210512200242.jpg
保存token,等下要用


Dingtalk_20210512200516.jpg


5. 配置Actions secrets,name随便填写,value填入刚刚获取的token


Dingtalk_20210512200640.jpg


6.配置Actions


Dingtalk_20210512200843.jpg


Dingtalk_20210512201013.jpg


需要填写的规则


name: Flutter Web
on:
push:
branches:
- master
jobs:
build:
name: Build Web
env:
my_secret: ${{secrets.commit_secret}}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: subosito/flutter-action@v1
with:
channel: 'dev'
- run: flutter pub get
- run: flutter build web --release
- run: |
cd build/web
git init
git config --global user.email aaa
git config --global user.name bbb
git status
git remote add origin https://${{secrets.commit_secret}}@github.com/xxx/yyy.git
git checkout -b gh-pages
git add --all
git commit -m "update"
git push origin gh-pages -f

aaa-你的邮箱 bbb替-你的名称 xxx-你的git名字 yyy为-Repository名字


然后我们每次提交修改到master上时,Actions都会自动帮我们打包web到gh-pages分支上,完成Actions后,我们可以查看flutter构建的博客网站,一般网址为https://你的git名字.github.io/Repository名字/。


这里记得注意的是需要修改web目录下index.html中


<base href="/">
修改为Repository的名字
<base href="/flutter_blog/">

不然在打开网页的时候会找不到资源。


作者:gstory
链接:https://juejin.cn/post/6961399282872107015
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Python对象的浅拷贝与深拷贝

在讲我们深浅拷贝之前,我们需要先区分一下拷贝和赋值的概念。看下面的例子a = [1,2,3]赋值:b = a拷贝:b = a.copy()上面的两行代码究竟有什么不同呢?带着这个问题,继续 看了上面这张图,相信大家已经对直接赋值和拷贝有了一个比较清楚的认识...
继续阅读 »

在讲我们深浅拷贝之前,我们需要先区分一下拷贝和赋值的概念。看下面的例子

a = [1,2,3]

赋值:

b = a

拷贝:

b = a.copy()

上面的两行代码究竟有什么不同呢?带着这个问题,继续

Python对象的浅拷贝与深拷贝_递归



看了上面这张图,相信大家已经对直接赋值和拷贝有了一个比较清楚的认识。

直接赋值:复制一个对象的引用给新变量
拷贝:复制一个对象到新的内存地址空间,并且将新变量引用到复制后的对象

我们的深浅拷贝只是对于可变对象来讨论的。 不熟悉的朋友需要自己去了解可变对象与不可变对象哦。

1 对象的嵌套引用

a = { "list": [1,2,3] }

上面的代码,在内存中是什么样子的呢?请看下图:

Python对象的浅拷贝与深拷贝_递归_02



原来,在我们的嵌套对象中,子对象也是一个引用。

2 浅拷贝

Python对象的浅拷贝与深拷贝_python_03



如上图所示,我们就可以很好的理解什么叫做浅拷贝了。

浅拷贝:只拷贝父对象,不会拷贝对象的内部的子对象。内部的子对象指向的还是同一个引用

上面 的 a 和 c 是一个独立的对象,但他们的子对象还是指向统一对象

2.1 浅拷贝的方法

  • .copy()

a = {"list": [1,2,3] }
b = a.copy()
  • copy模块

import copy
a = {"list": [1,2,3] }
b = copy.copy(a)
  • 列表切片[:]

a = [1,2,3,[1,2,3]]
b = a[1:]
  • for循环

a = [1,2,3,[1,2,3]]
b = []
for i in a:
  b.append(i)

2.2 浅拷贝的影响

a = {"list":[1,2,3]}
b = a.copy()
a["list"].append(4)

print(a)
# {'list': [1, 2, 3, 4]}

print(b)
# {'list': [1, 2, 3, 4]}

在上面的例子中,我们明明只改变 a 的子对象,却发现 b 的子对象也跟着改变了。这样在我们的程序中也许会引发很多的BUG。

3 深拷贝

上面我们知道了什么是浅拷贝,那我们的深拷贝就更好理解了。

Python对象的浅拷贝与深拷贝_python_04



深拷贝:完全拷贝了父对象及其子对象,两者已经完成没有任何关联,是完全独立的。

import copy
a = {"list":[1,2,3]}
b = copy.deepcopy(a)
a["list"].append(4)

print(a)
# {'list': [1, 2, 3, 4]}

print(b)
# {'list': [1, 2, 3,]}

上面的例子中,我们再次修改 a 的子对象对 b 已经没有任何影响

4 手动实现一个深拷贝

主要采用递归的方法解决问题。判断拷贝的每一项子对象是否为引用对象。如果是就采用递归的方式将子对象进行复制。

def deepcopy(instance):
  if isinstance(instance, dict):
      return {k:deepcopy(v) for k,v in instance.items() }
   
  elif isinstance(instance, list):
      return [deepcopy(x) for x in instance]
   
  else:
      return instance

a = {"list": [1,2,3]}
b = deepcopy(a)

print(a)
# {'list': [1, 2, 3]}

print(b)
# {'list': [1, 2, 3]}

a["list"].append(4)
print(a)
# {'list': [1, 2, 3, 4]}

print(b)
# {'list': [1, 2, 3]}

创作不易,且读且珍惜。如有错漏还请海涵并联系作者修改,内容有参考,如有侵权,请联系作者删除。如果文章对您有帮助,还请动动小手,您的支持是我最大的动力。

作者:趣玩Python
来源:https://blog.51cto.com/u_14666251/4716452 收起阅读 »

手写迷你版Vue

手写迷你版Vue参考代码:github.com/57code/vue-…Vue响应式设计思路Vue响应式主要包含:数据响应式监听数据变化,并在视图中更新Vue2使用Object.defineProperty实现数据劫持Vu3使用Proxy实现数据劫持模板引擎提...
继续阅读 »




手写迷你版Vue

参考代码:github.com/57code/vue-…

Vue响应式设计思路

Vue响应式主要包含:

  • 数据响应式

  • 监听数据变化,并在视图中更新

  • Vue2使用Object.defineProperty实现数据劫持

  • Vu3使用Proxy实现数据劫持

  • 模板引擎

  • 提供描述视图的模板语法

  • 插值表达式{{}}

  • 指令 v-bind, v-on, v-model, v-for,v-if

  • 渲染

  • 将模板转换为html

  • 解析模板,生成vdom,把vdom渲染为普通dom

数据响应式原理

image.png

数据变化时能自动更新视图,就是数据响应式 Vue2使用Object.defineProperty实现数据变化的检测

原理解析

  • new Vue()⾸先执⾏初始化,对data执⾏响应化处理,这个过程发⽣在Observer

  • 同时对模板执⾏编译,找到其中动态绑定的数据,从data中获取并初始化视图,这个过程发⽣在

Compile

  • 同时定义⼀个更新函数和Watcher实例,将来对应数据变化时,Watcher会调⽤更新函数

  • 由于data的某个key在⼀个视图中可能出现多次,所以每个key都需要⼀个管家Dep来管理多个

Watcher

  • 将来data中数据⼀旦发⽣变化,会⾸先找到对应的Dep,通知所有Watcher执⾏更新函数

image.png

一些关键类说明

CVue:自定义Vue类 Observer:执⾏数据响应化(分辨数据是对象还是数组) Compile:编译模板,初始化视图,收集依赖(更新函数、 watcher创建) Watcher:执⾏更新函数(更新dom) Dep:管理多个Watcher实例,批量更新

涉及关键方法说明

observe: 遍历vm.data的所有属性,对其所有属性做响应式,会做简易判断,创建Observer实例进行真正响应式处理

html页面

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>cvue</title>
<script src="./cvue.js"></script>
</head>
<body>
<div id="app">
  <p>{{ count }}</p>
</div>

<script>
  const app = new CVue({
    el: '#app',
    data: {
      count: 0
    }
  })
  setInterval(() => {
    app.count +=1
  }, 1000);
</script>
</body>
</html>

CVue

  • 创建基本CVue构造函数:

  • 执⾏初始化,对data执⾏响应化处理

// 自定义Vue类
class CVue {
constructor(options) {
  this.$options = options
  this.$data = options.data

  // 响应化处理
  observe(this.$data)
}
}

// 数据响应式, 修改对象的getter,setter
function defineReactive(obj, key, val) {
// 递归处理,处理val是嵌套对象情况
observe(val)
Object.defineProperty(obj, key, {
  get() {
    return val
  },
  set(newVal) {
    if(val !== newVal) {
      console.log(`set ${key}:${newVal}, old is ${val}`)

      val = newVal
      // 继续进行响应式处理,处理newVal是对象情况
      observe(val)
    }
  }
})
}

// 遍历obj,对其所有属性做响应式
function observe(obj) {
// 只处理对象类型的
if(typeof obj !== 'object' || obj == null) {
  return
}
// 实例化Observe实例
new Observe(obj)
}

// 根据传入value的类型做相应的响应式处理
class Observe {
constructor(obj) {
  if(Array.isArray(obj)) {
    // TODO
  } else {
    // 对象
    this.walk(obj)
  }
}
walk(obj) {
  // 遍历obj所有属性,调用defineReactive进行响应化
  Object.keys(obj).forEach(key => defineReactive(obj, key, obj[key]))
}
}

为vm.$data做代理

方便实例上设置和获取数据

例如

原本应该是

vm.$data.count
vm.$data.count = 233

代理之后后,可以使用如下方式

vm.count
vm.count = 233

给vm.$data做代理

class CVue {
constructor(options) {
  // 省略
  // 响应化处理
  observe(this.$data)

  // 代理data上属性到实例上
  proxy(this)
}
}

// 把CVue实例上data对象的属性到代理到实例上
function proxy(vm) {
Object.keys(vm.$data).forEach(key => {
  Object.defineProperty(vm, key, {
    get() {
      // 实现 vm.count 取值
      return vm.$data[key]
    },
    set(newVal) {
      // 实现 vm.count = 123赋值
      vm.$data[key] = newVal
    }
  })
})
}

编译

image.png

初始化视图

根据节点类型进行编译
class CVue {
constructor(options) {
  // 省略。。
  // 2 代理data上属性到实例上
  proxy(this)

  // 3 编译
  new Compile(this, this.$options.el)
}
}

// 编译模板中vue语法,初始化视图,更新视图
class Compile {
constructor(vm, el) {
  this.$vm = vm
  this.$el = document.querySelector(el)

  if(this.$el) {
    this.complie(this.$el)
  }
}
// 编译
complie(el) {
  // 取出所有子节点
  const childNodes = el.childNodes
  // 遍历节点,进行初始化视图
  Array.from(childNodes).forEach(node => {
    if(this.isElement(node)) {
      // TODO
      console.log(`编译元素 ${node.nodeName}`)
    } else if(this.isInterpolation(node)) {
      console.log(`编译插值文本 ${node.nodeName}`)
    }
    // 递归编译,处理嵌套情况
    if(node.childNodes) {
      this.complie(node)
    }
  })
}
// 是元素节点
isElement(node) {
  return node.nodeType === 1
}
// 是插值表达式
isInterpolation(node) {
  return node.nodeType === 3
    && /\{\{(.*)\}\}/.test(node.textContent)
}
}
编译插值表达式
// 编译模板中vue语法,初始化视图,更新视图
class Compile {
complie(el) {
  Array.from(childNodes).forEach(node => {
    if(this.isElement(node)) {
      console.log(`编译元素 ${node.nodeName}`)
    } else if(this.isInterpolation(node)) {
      // console.log(`编译插值文本 ${node.textContent}`)
      this.complieText(node)
    }
    // 省略
  })
}
// 是插值表达式
isInterpolation(node) {
  return node.nodeType === 3
    && /\{\{(.*)\}\}/.test(node.textContent)
}
// 编译插值
complieText(node) {
  // RegExp.$1是isInterpolation()中/\{\{(.*)\}\}/匹配出来的组内容
  // 相等于{{ count }}中的count
  const exp = String(RegExp.$1).trim()
  node.textContent = this.$vm[exp]
}
}
编译元素节点和指令

需要取出指令和指令绑定值 使用数据更新视图

// 编译模板中vue语法,初始化视图,更新视图
class Compile {
complie(el) {
  Array.from(childNodes).forEach(node => {
    if(this.isElement(node)) {
      console.log(`编译元素 ${node.nodeName}`)
      this.complieElement(node)
    }
    // 省略
  })
}
// 是元素节点
isElement(node) {
  return node.nodeType === 1
}
// 编译元素
complieElement(node) {
  // 取出元素上属性
  const attrs = node.attributes
  Array.from(attrs).forEach(attr => {
    // c-text="count"中c-text是attr.name,count是attr.value
    const { name: attrName, value: exp } = attr
    if(this.isDirective(attrName)) {
      // 取出指令
      const dir = attrName.substring(2)
      this[dir] && this[dir](node, exp)
    }
  })
}
// 是指令
isDirective(attrName) {
  return attrName.startsWith('')
}
// 处理c-text文本指令
text(node, exp) {
  node.textContent = this.$vm[exp]
}
// 处理c-html指令
html(node, exp) {
  node.innerHTML = this.$vm[exp]
}
}

以上完成初次渲染,但是数据变化后,不会触发页面更新

依赖收集

视图中会⽤到data中某key,这称为依赖。 同⼀个key可能出现多次,每次出现都需要收集(⽤⼀个Watcher来维护维护他们的关系),此过程称为依赖收集。 多个Watcher需要⼀个Dep来管理,需要更新时由Dep统⼀通知。

image.png

  • data中的key和dep是一对一关系

  • 视图中key出现和Watcher关系,key出现一次就对应一个Watcher

  • dep和Watcher是一对多关系

实现思路

  • defineReactive中为每个key定义一个Dep实例

  • 编译阶段,初始化视图时读取key, 会创建Watcher实例

  • 由于读取过程中会触发key的getter方法,便可以把Watcher实例存储到key对应的Dep实例

  • 当key更新时,触发setter方法,取出对应的Dep实例Dep实例调用notiy方法通知所有Watcher更新

定义Watcher类

监听器,数据变化更新对应节点视图

// 创建Watcher监听器,负责更新视图
class Watcher {
// vm vue实例,依赖key,updateFn更新函数(编译阶段传递进来)
constructor(vm, key, updateFn) {
  this.$vm = vm
  this.$key = key
  this.$updateFn = updateFn
}
update() {
  // 调用更新函数,获取最新值传递进去
  this.$updateFn.call(this.$vm, this.$vm[this.$key])
}
}
修改Compile类中的更新函数,创建Watcher实例
class Complie {
// 省略。。。
// 编译插值
complieText(node) {
  // RegExp.$1是isInterpolation()中/\{\{(.*)\}\}/匹配出来的组内容
  // 相等于{{ count }}中的count
  const exp = String(RegExp.$1).trim()
  // node.textContent = this.$vm[exp]
  this.update(node, exp, 'text')
}
// 处理c-text文本指令
text(node, exp) {
  // node.textContent = this.$vm[exp]
  this.update(node, exp, 'text')
}
// 处理c-html指令
html(node, exp) {
  // node.innerHTML = this.$vm[exp]
  this.update(node, exp, 'html')
}
// 更新函数
update(node, exp, dir) {
  const fn = this[`${dir}Updater`]
  fn && fn(node, this.$vm[exp])

  // 创建监听器
  new Watcher(this.$vm, exp, function(newVal) {
    fn && fn(node, newVal)
  })
}
// 文本更新器
textUpdater(node, value) {
  node.textContent = value
}
// html更新器
htmlUpdater(node, value) {
  node.innerHTML = value
}
}
定义Dep类
  • data的一个属性对应一个Dep实例

  • 管理多个Watcher实例,通知所有Watcher实例更新

// 创建订阅器,每个Dep实例对应data中的一个属性
class Dep {
constructor() {
  this.deps = []
}
// 添加Watcher实例
addDep(dep) {
  this.deps.push(dep)
}
notify() {
  // 通知所有Wather更新视图
  this.deps.forEach(dep => dep.update())
}
}
创建Watcher时触发getter
class Watcher {
// vm vue实例,依赖key,updateFn更新函数(编译阶段传递进来)
constructor(vm, key, updateFn) {
  // 省略
  // 把Wather实例临时挂载在Dep.target上
  Dep.target = this
  // 获取一次属性,触发getter, 从Dep.target上获取Wather实例存放到Dep实例中
  this.$vm[key]
  // 添加后,重置Dep.target
  Dep.target = null
}
}
defineReactive中作依赖收集,创建Dep实例
function defineReactive(obj, key, val) {
// 递归处理,处理val是嵌套对象情况
observe(val)

const dep = new Dep()
Object.defineProperty(obj, key, {
  get() {
    Dep.target && dep.addDep(Dep.target)
    return val
  },
  set(newVal) {
    if(val !== newVal) {
      val = newVal
      // 继续进行响应式处理,处理newVal是对象情况
      observe(val)
      // 更新视图
      dep.notify()
    }
  }
})
}

监听事件指令@xxx

  • 在创建vue实例时,需要缓存methods到vue实例上

  • 编译阶段取出methods挂载到Compile实例上

  • 编译元素时

  • 识别出v-on指令时,进行事件的绑定

  • 识别出@属性时,进行事件绑定

  • 事件绑定:通过指令或者属性获取对应的函数,给元素新增事件监听,使用bind修改监听函数的this指向为组件实例

// 自定义Vue类
class CVue {
constructor(options) {
  this.$methods = options.methods
}
}

// 编译模板中vue语法,初始化视图,更新视图
class Compile {
constructor(vm, el) {
  this.$vm = vm
  this.$el = document.querySelector(el)
  this.$methods = vm.$methods
}

// 编译元素
complieElement(node) {
  // 取出元素上属性
  const attrs = node.attributes
  Array.from(attrs).forEach(attr => {
    // c-text="count"中c-text是attr.name,count是attr.value
    const { name: attrName, value: exp } = attr
    if(this.isDirective(attrName)) {
      // 省略。。。
      if(this.isEventListener(attrName)) {
        // v-on:click, subStr(5)即可截取到click
        const eventType = attrName.substring(5)
        this.bindEvent(eventType, node, exp)
      }
    } else if(this.isEventListener(attrName)) {
      // @click, subStr(1)即可截取到click
      const eventType = attrName.substring(1)
      this.bindEvent(eventType, node, exp)
    }
  })
}
// 是事件监听
isEventListener(attrName) {
  return attrName.startsWith('@') || attrName.startsWith('c-on')
}
// 绑定事件
bindEvent(eventType, node, exp) {
  // 取出表达式对应函数
  const method = this.$methods[exp]
  // 增加监听并修改this指向当前组件实例
  node.addEventListener(eventType, method.bind(this.$vm))
}
}

v-model双向绑定

实现v-model绑定input元素时的双向绑定功能

// 编译模板中vue语法,初始化视图,更新视图
class Compile {
// 省略...
// 处理c-model指令
model(node, exp) {
  // 渲染视图
  this.update(node, exp, 'model')
  // 监听input变化
  node.addEventListener('input', (e) => {
    const { value } = e.target
    // 更新数据,相当于this.username = 'mio'
    this.$vm[exp] = value
  })
}
// model更新器
modelUpdater(node, value) {
  node.value = value
}
}

数组响应式

  • 获取数组原型

  • 数组原型创建对象作为数组拦截器

  • 重写数组的7个方法

// 数组响应式
// 获取数组原型, 后面修改7个方法
const originProto = Array.prototype
// 创建对象做备份,修改响应式都是在备份的上进行,不影响原始数组方法
const arrayProto = Object.create(originProto)
// 拦截数组方法,在变更时发出通知
;['push', 'pop', 'shift', 'unshift', 'splice', 'sort', 'reverse'].forEach(method => {
// 在备份的原型上做修改
arrayProto[method] = function() {
  // 调用原始操作
  originProto[method].apply(this, arguments)
  // 发出变更通知
  console.log(`method:${method} value:${Array.from(arguments)}`)
}
})

class Observe {
constructor(obj) {
  if(Array.isArray(obj)) {
    // 修改数组原型为自定义的
    obj.__proto__ = arrayProto
    this.observeArray(obj)
  } else {
    // 对象
    this.walk(obj)
  }
}
observeArray(items) {
  // 如果数组内部元素时对象,继续做响应化处理
  items.forEach(item => observe(item))
}
}

作者:LastStarDust
来源:https://juejin.cn/post/7036291383153393701

收起阅读 »

LRU缓存-keep-alive实现原理

相信大部分同学在日常需求开发中或多或少的会有需要一个组件状态被持久化、不被重新渲染的场景,熟悉 vue 的同学一定会想到 keep-alive 这个内置组件。 keep-alive 是 Vue.js 的一个 内置组件。它能够将不活动的组件实例保存在内存中,而不...
继续阅读 »



前言

相信大部分同学在日常需求开发中或多或少的会有需要一个组件状态被持久化、不被重新渲染的场景,熟悉 vue 的同学一定会想到 keep-alive 这个内置组件。

那么什么是 keep-alive 呢?

keep-alive 是 Vue.js 的一个 内置组件。它能够将不活动的组件实例保存在内存中,而不是直接将其销毁,它是一个抽象组件,不会被渲染到真实 DOM 中,也不会出现在父组件链中。简单的说,keep-alive用于保存组件的渲染状态,避免组件反复创建和渲染,有效提升系统性能。 keep-alivemax 属性,用于限制可以缓存多少组件实例,一旦这个数字达到了上限,在新实例被创建之前,已缓存组件中最久没有被访问的实例会被销毁掉,而这里所运用到的缓存机制就是 LRU 算法

LRU 缓存淘汰算法

LRU( least recently used)根据数据的历史记录来淘汰数据,重点在于保护最近被访问/使用过的数据,淘汰现阶段最久未被访问的数据

LRU的主体思想在于:如果数据最近被访问过,那么将来被访问的几率也更高

fifo对比lru原理

  1. 新数据插入到链表尾部;

  2. 每当缓存命中(即缓存数据被访问),则将数据移到链表尾部

  3. 当链表满的时候,将链表头部的数据丢弃。

实现LRU的数据结构

经典的 LRU 一般都使用 hashMap + 双向链表。考虑可能需要频繁删除一个元素,并将这个元素的前一个节点指向下一个节点,所以使用双链接最合适。并且它是按照结点最近被使用的时间顺序来存储的。 如果一个结点被访问了, 我们有理由相信它在接下来的一段时间被访问的概率要大于其它结点。

map.keys()

不过既然已经在 js 里都已经使用 Map 了,何不直接取用现成的迭代器获取下一个结点的 key 值(keys().next( )

// ./LRU.ts
export class LRUCache {
capacity: number; // 容量
cache: Map; // 缓存
constructor(capacity: number) {
  this.capacity = capacity;
  this.cache = new Map();
}
get(key: number): number {
  if (this.cache.has(key)) {
    let temp = this.cache.get(key) as number;
    //访问到的 key 若在缓存中,将其提前
    this.cache.delete(key);
    this.cache.set(key, temp);
    return temp;
  }
  return -1;
}
put(key: number, value: number): void {
  if (this.cache.has(key)) {
    this.cache.delete(key);
    //存在则删除,if 结束再提前
  } else if (this.cache.size >= this.capacity) {
    // 超过缓存长度,淘汰最近没使用的
    this.cache.delete(this.cache.keys().next().value);
    console.log(`refresh: key:${key} , value:${value}`)
  }
  this.cache.set(key, value);
}
toString(){
  console.log('capacity',this.capacity)
  console.table(this.cache)
}
}
// ./index.ts
import {LRUCache} from './lru'
const list = new LRUCache(4)
list.put(2,2)   // 2,剩余容量3
list.put(3,3)   // 3,剩余容量2
list.put(4,4)   // 4,剩余容量1
list.put(5,5)   // 5,已满   从头至尾         2-3-4-5
list.put(4,4)   // 入4,已存在 ——> 置队尾         2-3-5-4
list.put(1,1)   // 入1,不存在 ——> 删除队首 插入1 3-5-4-1
list.get(3)     // 获取3,刷新3——> 置队尾         5-4-1-3
list.toString()
// ./index.ts
import {LRUCache} from './lru'
const list = new LRUCache(4)

list.put(2,2)   // 2,剩余容量3
list.put(3,3)   // 3,剩余容量2
list.put(4,4)   // 4,剩余容量1
list.put(5,5)   // 5,已满   从头至尾 2-3-4-5
list.put(4,4)   // 入4,已存在 ——> 置队尾 2-3-5-4
list.put(1,1)   // 入1,不存在 ——> 删除队首 插入1 3-5-4-1
list.get(3)     // 获取3,刷新3——> 置队尾 5-4-1-3
list.toString()

结果如下: lru打印结果.jpg

vue 中 Keep-Alive

原理

  1. 使用 LRU 缓存机制进行缓存,max 限制缓存表的最大容量

  2. 根据设定的 include/exclude(如果有)进行条件匹配,决定是否缓存。不匹配,直接返回组件实例

  3. 根据组件 ID 和 tag 生成缓存 Key ,并在缓存对象中查找是否已缓存过该组件实例。如果存在,直接取出缓存值并更新该 key 在 this.keys 中的位置(更新 key 的位置是实现 LRU 置换策略的关键)

  4. 获取节点名称,或者根据节点 cid 等信息拼出当前 组件名称

  5. 获取 keep-alive 包裹着的第一个子组件对象及其组件名

源码分析

初始化 keepAlive 组件
const KeepAliveImpl: ComponentOptions = {
 name: `KeepAlive`,
 props: {
   include: [String, RegExp, Array],
   exclude: [String, RegExp, Array],
   max: [String, Number],
},
 setup(props: KeepAliveProps, { slots }: SetupContext) {
   // 初始化数据
   const cache: Cache = new Map();
   const keys: Keys = new Set();
   let current: VNode | null = null;
   // 当 props 上的 include 或者 exclude 变化时移除缓存
   watch(
    () => [props.include, props.exclude],
    ([include, exclude]) => {
     include && pruneCache((name) => matches(include, name));
     exclude && pruneCache((name) => !matches(exclude, name));
    },
    { flush: "post", deep: true }
  );
   // 缓存组件的子树 subTree
   let pendingCacheKey: CacheKey | null = null;
   const cacheSubtree = () => {
     // fix #1621, the pendingCacheKey could be 0
     if (pendingCacheKey != null) {
       cache.set(pendingCacheKey, getInnerChild(instance.subTree));
    }
  };
   // KeepAlive 组件的设计,本质上就是空间换时间。
   // 在 KeepAlive 组件内部,
   // 当组件渲染挂载和更新前都会缓存组件的渲染子树 subTree
   onMounted(cacheSubtree);
   onUpdated(cacheSubtree);
   onBeforeUnmount(() => {
   // 卸载缓存表里的所有组件和其中的子树...
  }
   return ()=>{
     // 返回 keepAlive 实例
  }
}
}

return ()=>{
 // 省略部分代码,以下是缓存逻辑
 pendingCacheKey = null
 const children = slots.default()
 let vnode = children[0]
 const comp = vnode.type as Component
 const name = getName(comp)
 const { include, exclude, max } = props
 // key 值是 KeepAlive 子节点创建时添加的,作为缓存节点的唯一标识
 const key = vnode.key == null ? comp : vnode.key
 // 通过 key 值获取缓存节点
 const cachedVNode = cache.get(key)
 if (cachedVNode) {
   // 缓存存在,则使用缓存装载数据
   vnode.el = cachedVNode.el
   vnode.component = cachedVNode.component
   if (vnode.transition) {
     // 递归更新子树上的 transition hooks
     setTransitionHooks(vnode, vnode.transition!)
  }
     // 阻止 vNode 节点作为新节点被挂载
     vnode.shapeFlag |= ShapeFlags.COMPONENT_KEPT_ALIVE
     // 刷新key的优先级
     keys.delete(key)
     keys.add(key)
} else {
     keys.add(key)
     // 属性配置 max 值,删除最久不用的 key ,这很符合 LRU 的思想
     if (max && keys.size > parseInt(max as string, 10)) {
       pruneCacheEntry(keys.values().next().value)
    }
  }
   // 避免 vNode 被卸载
   vnode.shapeFlag |= ShapeFlags.COMPONENT_SHOULD_KEEP_ALIVE
   current = vnode
   return vnode;
}
将组件移出缓存表
// 遍历缓存表
function pruneCache(filter?: (name: string) => boolean) {
 cache.forEach((vnode, key) => {
   const name = getComponentName(vnode.type as ConcreteComponent);
   if (name && (!filter || !filter(name))) {
     // !filter(name) 即 name 在 includes 或不在 excludes 中
     pruneCacheEntry(key);
  }
});
}
// 依据 key 值从缓存表中移除对应组件
function pruneCacheEntry(key: CacheKey) {
 const cached = cache.get(key) as VNode;
 if (!current || cached.type !== current.type) {
   /* 当前没有处在 activated 状态的组件
    * 或者当前处在 activated 组件不是要删除的 key 时
    * 卸载这个组件
  */
   unmount(cached); // unmount方法里同样包含了 resetShapeFlag
} else if (current) {
   // 当前组件在未来应该不再被 keepAlive 缓存
   // 虽然仍在 keepAlive 的容量中但是需要刷新当前组件的优先级
   resetShapeFlag(current);
   // resetShapeFlag
}
 cache.delete(key);
 keys.delete(key);
}
function resetShapeFlag(vnode: VNode) {
 let shapeFlag = vnode.shapeFlag; // shapeFlag 是 VNode 的标识
  // ... 清除组件的 shapeFlag
}

keep-alive案例

本部分将使用 vue 3.x 的新特性来模拟 keep-alive 的具体应用场景

在 index.vue 里我们引入了 CountUp 、timer 和 ColorRandom 三个带有状态的组件 在容量为 2 的 中包裹了一个动态组件

// index.vue
<script setup>
import { ref } from "vue"
import CountUp from '../components/CountUp.vue'
import ColorRandom from '../components/ColorRandom.vue'
import Timer from '../components/Timer.vue'
const tabs = ref([    // 组件列表
{
   title: "ColorPicker",
   comp: ColorRandom,
},
{
   title: "timer1",
   comp: Timer,
},
{
   title: "timer2",
   comp: Timer,
},
{
   title: "CountUp",
   comp: CountUp,
},
])
const currentTab = ref(tabs.value[0]) // tab 默认展示第一个组件
const tabSwitch = (tab) => {
 currentTab.value = tab
}
script>
<template>
 <div id="main-page">keep-alive demo belowdiv>
 <div class="tab-group">
   <button
   v-for="tab in tabs"
   :key="tab"
   :class="['tab-button', { active: currentTab === tab }]"
   @click="tabSwitch(tab)"
 >
   {{ tab.title }}
 button>
 div>
 <keep-alive max="2">
   
   <component
     v-if="currentTab"
     :is="currentTab.comp"
     :key="currentTab.title"
     :name="currentTab.title"
   />
 keep-alive>
template>

缓存状态

缓存流程如下:

缓存流程图

可以看到被包裹在 keep-alive 的动态组件缓存了前一个组件的状态。

通过观察 vue devtools 里节点的变化,可以看到此时 keepAlive 中包含了 ColorRandomTimer 两个组件,当前展示的组件会处在 activated 的状态,而其他被缓存的组件则处在 inactivated 的状态

如果我们注释了两个 keep-alive 会发现不管怎么切换组件,都只会重新渲染,并不会保留前次的状态
keepAlive-cache.gif

移除组件

移除流程如下:

移除流程图

为了验证组件是否在切换tab时能被成功卸载,在每个组件的 onUnmounted 中加上了 log

onUnmounted(()=>{
 console.log(`${props.name} 组件被卸载`)
})
  • 当缓存数据长度小于等于 max ,切换组件并不会卸载其他组件,就像上面在 vue devtools 里展示的一样,只会触发组件的 activateddeactivated 两个生命周期

  • 若此时缓存数据长度大于 max ,则会从缓存列表中删除优先级较低的,优先被淘汰的组件,对应的可以看到该组件 umounted 生命周期触发。

性能优化

使用 KeepAlive 后,被 KeepAlive 包裹的组件在经过第一次渲染后,的 vnode 以及 DOM 都会被缓存起来,然后再下一次再次渲染该组件的时候,直接从缓存中拿到对应的 vnode 和 DOM,然后渲染,并不需要再走一次组件初始化,render 和 patch 等一系列流程,减少了 script 的执行时间,性能更好。

总结

Vue 内部将 DOM 节点抽象成了一个个的 VNode 节点,keep-alive 组件的缓存也是基于 VNode 节点的而不是直接存储 DOM 结构。它将满足条件( include 与 exclude )的组件在 cache 对象中缓存起来,在需要重新渲染的时候再将 vnode 节点从 cache 对象中取出并渲染。

具体缓存过程如下:

  1. 声明有序集合 keys 作为缓存容器,存入组件的唯一 key 值

  2. 在缓存容器 keys 中,越靠前的 key 值意味着被访问的越少也越优先被淘汰

  3. 渲染函数执行时,若命中缓存时,则从 keys 中删除当前命中的 key,并往 keys 末尾追加 key 值,刷新该 key 的优先级

  4. 未命中缓存时,则 keys 追加缓存数据 key 值,若此时缓存数据长度大于 max 最大值,则删除最旧的数据

  5. 当触发 beforeMount/update 生命周期,缓存当前 activated 组件的子树的数据


参考

作者:政采云前端团队
来源:https://juejin.cn/post/7036483610920091656

收起阅读 »

Android 关键字高亮

前言项目中经常会遇到需要对关键字加特殊色值显示,不管是搜索内容还是列表关键字展示,对于特殊文字或者词组高亮是一种很常见的需求,Android 没有自带这样的工具或者组件提供,但是我们可以自己实现一个这样的工具类,用到的地方直接调用就好了。文字高亮所谓文字高亮,...
继续阅读 »

前言

项目中经常会遇到需要对关键字加特殊色值显示,不管是搜索内容还是列表关键字展示,对于特殊文字或者词组高亮是一种很常见的需求,Android 没有自带这样的工具或者组件提供,但是我们可以自己实现一个这样的工具类,用到的地方直接调用就好了。

文字高亮

所谓文字高亮,其实就是针对某个字符做特殊颜色显示,下面列举几种常见的实现方式

一、通过加载Html标签,显示高亮

Android 的TextView 可以加载带Html标签的段落,方法:

textView.setText(Html.fromHtml("<font color='red' size='24'>Hello World</font>"));

那么要高亮显示关键字,就可以这样实现,把需要高亮显示的关键字,通过这样的方式,组合起来就好了,例如:

textView.setText(“这是我的第一个安卓项目” + Html.fromHtml("<font color='red' size='24'>Hello World</font>"));

二、通过SpannableString来实现文本高亮

先来简单了解下SpannableString

SpannableString的基本使用代码示例:

//设置Url地址连接
private void addUrlSpan() {
SpannableString spanString = new SpannableString("超链接");
URLSpan span = new URLSpan("tel:0123456789");
spanString.setSpan(span, 0, 3, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
tv.append(spanString);
}

//设置字体背景的颜色
private void addBackColorSpan() {
SpannableString spanString = new SpannableString("文字背景颜色");
BackgroundColorSpan span = new BackgroundColorSpan(Color.YELLOW);
spanString.setSpan(span, 0, 3, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
tv.append(spanString);
}
//设置字体的颜色
private void addForeColorSpan() {
SpannableString spanString = new SpannableString("文字前景颜色");
ForegroundColorSpan span = new ForegroundColorSpan(Color.BLUE);
spanString.setSpan(span, 0, 3, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
tv.append(spanString);
}
//设置字体的大小
private void addFontSpan() {
SpannableString spanString = new SpannableString("36号字体");
AbsoluteSizeSpan span = new AbsoluteSizeSpan(36);
spanString.setSpan(span, 0, 5, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
tv.append(spanString);
}

以上是比较常用的,还有其他例如设置字体加粗,下划线,删除线等,都可以实现

我们这里主要用到给字体设置背景色,通过正则表达式匹配关键字,设置段落中匹配到的关键字高亮

/***
* 指定关键字高亮 字符串整体高亮
* @param originString 原字符串
* @param keyWords 高亮字符串
* @param highLightColor 高亮色值
* @return 高亮后的字符串
*/
public static SpannableString getHighLightWord(String originString, String keyWords, int highLightColor) {
SpannableString originSpannableString = new SpannableString(originString);
if (!TextUtils.isEmpty(keyWords)) {
Pattern pattern = Pattern.compile(keyWords);
Matcher matcher = pattern.matcher(originSpannableString);
while (matcher.find()) {
int startIndex = matcher.start();
int endIndex = matcher.end();
originSpannableString.setSpan(new ForegroundColorSpan(highLightColor), startIndex, endIndex, Spanned.SPAN_EXCLUSIVE_EXCLUSIVE);
}
}
return originSpannableString;
}

在扩展一下,可以支持关键字,关键词拆分显示

类似:测试1234测1234试(测试为高亮字,实现测试/测/试分别高亮)

/***
* 指定关键字高亮 支持分段高亮
* @param originString
* @param keyWords
* @param highLightColor
* @return
*/
public static SpannableString getHighLightWords(String originString, String keyWords, int highLightColor) {
SpannableString originSpannableString = new SpannableString(originString);
if (!TextUtils.isEmpty(keyWords)) {
for (int i = 0; i < keyWords.length(); i++) {
Pattern p = Pattern.compile(String.valueOf(keyWords.charAt(i)));
Matcher m = p.matcher(originSpannableString);
while (m.find()) {
int start = m.start();
int end = m.end();
originSpannableString.setSpan(new ForegroundColorSpan(highLightColor), start, end,
Spanned.SPAN_EXCLUSIVE_EXCLUSIVE);
}
}
}
return originSpannableString;
}

字符可以,那么数组呢,是不是也可以实现了?

/***
* 指定关键字数组高亮
* @param originString 原字符串
* @param keyWords 高亮字符串数组
* @param highLightColor 高亮色值
* @return 高亮后的字符串
*/
public static SpannableString getHighLightWordsArray(String originString, String[] keyWords, int highLightColor) {
SpannableString originSpannableString = new SpannableString(originString);
if (keyWords != null && keyWords.length > 0) {
for (int i = 0; i < keyWords.length; i++) {
Pattern p = Pattern.compile(keyWords[i]);
Matcher m = p.matcher(originSpannableString);
while (m.find()) {
int start = m.start();
int end = m.end();
originSpannableString.setSpan(new ForegroundColorSpan(highLightColor), start, end,
Spanned.SPAN_EXCLUSIVE_EXCLUSIVE);
}
}
}
return originSpannableString;
}

总结

这样不管来什么需求,是不是都可以满足了,随便产品经理提,要什么给什么

收起阅读 »

聊一聊Android开发利器之adb

学无止境,有一技旁身,至少不至于孤陋寡闻。adb的全称为Android Debug Bridge,通过adb可以方便我们调试Android程序。作为移动端开发相关的同学,掌握所需要的adb操作命令是非常必须的,就把平时工作中用得相对比较多的adb命令做个梳理。...
继续阅读 »

学无止境,有一技旁身,至少不至于孤陋寡闻。

adb的全称为Android Debug Bridge,通过adb可以方便我们调试Android程序。作为移动端开发相关的同学,掌握所需要的adb操作命令是非常必须的,就把平时工作中用得相对比较多的adb命令做个梳理。(日常中把adb操作命令搭配shell alias使用起来更方便)

ADB常用命令

1.启动/停止adb server命令

adb start-server  //启动命令
adb kill-server //停止命令

2. 通过adb查看设备相关信息

  1. 查询已连接设备/模拟器
    adb devices
  2. 查看手机型号
    adb shell getprop ro.product.model
  3. 查看电池状况
    adb shell dumpsys battery
  4. 查看屏幕分辨率
    adb shell wm size
  5. 查看屏幕密度
    adb shell wm density
  6. 查看显示屏参数
    adb shell dumpsys window displays
  7. 查看Android系统版本
    adb shell getprop ro.build.version.release
  8. 查看CPU信息
    adb shell cat /proc/cpuinfo
  9. 查看手机CPU架构
    adb shell getprop ro.product.cpu.abi
  10. 查看内存信息
    adb shell cat /proc/meminfo

3. 通过adb连接设备命令

adb [-d|-e|-s ]
如果只有一个设备/模拟器连接时,可以省略掉 [-d|-e|-s ] 这一部分,直接使用 adb即可 。 如果有多个设备/模拟器连接,则需要为命令指定目标设备。

参数含义
-d指定当前唯一通过 USB 连接的 Android 设备为命令目标
-e指定当前唯一运行的模拟器为命令目标
-s <serialNumber>指定相应 serialNumber 号的设备/模拟器为命令目标
在多个设备/模拟器连接的情况下较常用的是-s参数,serialNumber 可以通过adb devices命令获取。如:
$ adb devices
List of devices attached
cfxxxxxx device
emulator-5554 device
10.xxx.xxx.x:5555 device

输出里的 cfxxxxxxemulator-5554 和 10.xxx.xxx.x:5555 即为 serialNumber。 比如这时想指定 cfxxxxxx 这个设备来运行 adb 命令 获取屏幕分辨率:

adb -s cfxxxxxx shell wm size

安装应用:

adb -s cfxxxxxx install hello.apk

遇到多设备/模拟器的情况均使用这几个参数为命令指定目标设备。

4. 通过adb在设备上操作应用相关

  1. 安装 APK

    adb install [-rtsdg] <apk_path>

    参数:
    adb install 后面可以跟一些可选参数来控制安装 APK 的行为,可用参数及含义如下:

    参数含义
    -r允许覆盖安装
    -t允许安装 AndroidManifest.xml 里 application 指定 android:testOnly="true" 的应用
    -s将应用安装到 sdcard
    -d允许降级覆盖安装
    -g授予所有运行时权限
  2. 卸载应用

    adb uninstall [-k] <packagename>

    <packagename> 表示应用的包名,-k 参数可选,表示卸载应用但保留数据和缓存目录。

    adb uninstall com.vic.dynamicview
  3. 强制停止应用

    adb shell am force-stop <packagename>

    命令示例:

    adb shell am force-stop com.vic.dynamicview
  4. 调起对应的Activity

    adb shell am start [options] <INTENT>

    例如:

    adb shell am start -n com.vic.dynamicview/.MainActivity --es "params" "hello, world"

    表示调起 com.vic.dynamicview/.MainActivity 并传给它 string 数据键值对 params - hello, world。

  5. 查看前台 Activity

    adb shell dumpsys activity activities | grep ResumedActivity

    查看activity堆栈信息: adb shell dumpsys activity

    ACTIVITY MANAGER PENDING INTENTS (adb shell dumpsys activity intents)
    ...
    ACTIVITY MANAGER BROADCAST STATE (adb shell dumpsys activity broadcasts)
    ...
    ACTIVITY MANAGER CONTENT PROVIDERS (adb shell dumpsys activity providers)
    ...
    ACTIVITY MANAGER SERVICES (adb shell dumpsys activity services)
    ...
    ACTIVITY MANAGER ACTIVITIES (adb shell dumpsys activity activities)
    ...
    ACTIVITY MANAGER RUNNING PROCESSES (adb shell dumpsys activity processes)
    ...
  6. 打开系统设置:
    adb shell am start -n com.android.settings/com.android.settings.Settings

  7. 打开开发者选项:
    adb shell am start -a com.android.settings.APPLICATION_DEVELOPMENT_SETTINGS

  8. 进入WiFi设置
    adb shell am start -a android.settings.WIRELESS_SETTINGS

  9. 重启系统
    adb reboot

5. 通过adb操作日志相关

  1. logcathelp帮助信息
    adb logcat --help 可以查看logcat帮助信息
    adb logcat 命令格式: adb logcat [选项] [过滤项], 其中 选项 和 过滤项 在 中括号 [] 中, 说明这是可选的;

  2. 输出日志信息到文件:
    ">"输出 :
    ">" 后面跟着要输出的日志文件, 可以将 logcat 日志输出到文件中, 使用 adb logcat > log 命令, 使用 more log 命令查看日志信息;
    如:adb logcat > ~/logdebug.log

  3. 输出指定标签内容:
    "-s"选项 : 设置默认的过滤器, 如 我们想要输出 "System.out" 标签的信息, 就可以使用 adb logcat -s System.out 命令;

  4. 清空日志缓存信息:
    使用 adb logcat -c 命令, 可以将之前的日志信息清空, 重新开始输出日志信息;

  5. 输出缓存日志:
    使用 adb logcat -d 命令, 输出命令, 之后退出命令, 不会进行阻塞;

  6. 输出最近的日志:
    使用 adb logcat -t 5 命令, 可以输出最近的5行日志, 并且不会阻塞;

  7. 日志过滤:
    注意:在windows上不能使用grep关键字,可以用findstr代替grep.

    • 过滤固定字符串:
      adb logcat | grep logtag
      adb logcat | grep -i logtag #忽略大小写。
      adb logcat | grep logtag > ~/result.log #将过滤后的日志输出到文件
      adb logcat | grep --color=auto -i logtag #设置匹配字符串颜色。

    • 使用正则表达式匹配
      adb logcat | grep "^..Activity"

ADB其他命令

1. 清除应用数据与缓存

adb shell pm clear <packagename>

<packagename> 表示应用名包,这条命令的效果相当于在设置里的应用信息界面点击了「清除缓存」和「清除数据」。

adb shell pm clear com.xxx.xxx

2. 与应用交互操作

主要是使用 am <command> 命令,常用的 <command> 如下:

command用途
start [options] <INTENT>启动 <INTENT> 指定的 Activity
startservice [options] <INTENT>启动 <INTENT> 指定的 Service
broadcast [options] <INTENT>发送 <INTENT> 指定的广播
force-stop <packagename>停止 <packagename> 相关的进程

<INTENT> 参数很灵活,和写 Android 程序时代码里的 Intent 相对应。

用于决定 intent 对象的选项如下:

参数含义
-a <ACTION>指定 action,比如 android.intent.action.VIEW
-c <CATEGORY>指定 category,比如 android.intent.category.APP_CONTACTS
-n <COMPONENT>指定完整 component 名,用于明确指定启动哪个 Activity,如 com.example.app/.ExampleActivity

<INTENT> 里还能带数据,就像写代码时的 Bundle 一样:

参数含义
--esn <EXTRA_KEY>null 值(只有 key 名)
-e--es <EXTRA_KEY> <EXTRA_STRING_VALUE>`
--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE>boolean 值
--ei <EXTRA_KEY> <EXTRA_INT_VALUE>integer 值
--el <EXTRA_KEY> <EXTRA_LONG_VALUE>long 值
--ef <EXTRA_KEY> <EXTRA_FLOAT_VALUE>float 值
--eu <EXTRA_KEY> <EXTRA_URI_VALUE>URI
--ecn <EXTRA_KEY> <EXTRA_COMPONENT_NAME_VALUE>component name
--eia <EXTRA_KEY> <EXTRA_INT_VALUE>[,<EXTRA_INT_VALUE...]integer 数组
--ela <EXTRA_KEY> <EXTRA_LONG_VALUE>[,<EXTRA_LONG_VALUE...]long 数组
  1. 调起Activity

    adb shell am start [options] <INTENT>

    例如:

    adb shell am start -n com.cc.test/.MainActivity --es "params" "hello, world"

    表示调起 com.cc.test/.MainActivity 并传给它 string 数据键值对 params - hello, world。

  2. 调起Service

    adb shell am startservice [options] <INTENT>

    例如:

    adb shell am startservice -n com.tencent.mm/.plugin.accountsync.model.AccountAuthenticatorService
  3. 发送广播

    adb shell am broadcast [options] <INTENT>

    可以向所有组件广播,也可以只向指定组件广播。 例如,向所有组件广播 BOOT_COMPLETED:

    adb shell am broadcast -a android.intent.action.BOOT_COMPLETED

    又例如,只向 com.cc.test/.BootCompletedReceiver 广播 BOOT_COMPLETED:

    adb shell am broadcast -a android.intent.action.BOOT_COMPLETED -n com.cc.test/.BootCompletedReceiver
  4. 撤销应用程序的权限

    1. 向应用授予权限。只能授予应用程序声明的可选权限
    adb shell pm grant <packagename> <PACKAGE_PERMISSION>

    例如:adb -d shell pm grant packageName android.permission.BATTERY_STATS

    1. 取消应用授权
    adb shell pm revoke <packagename> <PACKAGE_PERMISSION>

3. 模拟按键/输入

Usage: input [<source>] <command> [<arg>...]

The sources are:
mouse
keyboard
joystick
touchnavigation
touchpad
trackball
stylus
dpad
gesture
touchscreen
gamepad

The commands and default sources are:
text <string> (Default: touchscreen)
keyevent [--longpress] <key code number or name> ... (Default: keyboard)
tap <x> <y> (Default: touchscreen)
swipe <x1> <y1> <x2> <y2> [duration(ms)] (Default: touchscreen)
press (Default: trackball)
roll <dx> <dy> (Default: trackball)

比如模拟点击://在屏幕上点击坐标点x=50 y=250的位置。

adb shell input tap 50 250

结合shell alias使用adb

shell终端的别名只是命令的简写,有类似键盘快捷键的效果。如果你经常执行某个长长的命令,可以给它起一个简短的化名。使用alias命令列出所有定义的别名。
你可以在~/.bashrc(.zshrc)文件中直接定义别名如alias logRunActivity="adb shell dumpsys activity activities | grep 'Run*'",也可以新创建一个文件如.byterc, 然后在当前shell对应的文件中.bashrc或者.zshrc 中增加source ~/.byterc,重新source配置,使得配置生效,即可使别名全局生效。使用别名可以节省时间、提高工作效率。

如何添加别名alias

下面在MAC环境采用新建文件形式添加别名,步骤如下:

  1. 新建.byterc 文件
    • 如果已经新建,直接打开
      open ~/.byterc
    • 没有新建,则新建后打开
      新建: touch ~/.byterc
      打开:open ~/.byterc
  2. 在.zshrc中添加source ~/.byterc
  3. 在打开的.byterc文件中定义别名
    alias logRunActivity="adb shell dumpsys activity activities | grep 'Run*'"
    Android同学应该知道作用就是查看当前设备运行的Activity信息
  4. 重新source配置,使得配置生效
    $ source ~/.byterc
    如果不是新建文件,直接使用.bashrc或者.zshrc ,直接source对应的配置即可,如:$ source ~/.zshrc .
  5. 此时在命令行中直接执行logRunActivity 即可查看当前设备运行的Activity信息。

注意: 可使用$ alias查看当前有设置哪些别名操作。


收起阅读 »

Swift 中的 Self & Self.Type & self

iOS
Swift 中的 Self & Self.Type & self这是我参与11月更文挑战的第13天,活动详情查看:2021最后一次更文挑战你可能在写代码的时候已经用过很多次 self 这个关键词了,但是你有没有想过什么是 self 呢?今天我们...
继续阅读 »

Swift 中的 Self & Self.Type & self

这是我参与11月更文挑战的第13天,活动详情查看:2021最后一次更文挑战


你可能在写代码的时候已经用过很多次 self 这个关键词了,但是你有没有想过什么是 self 呢?今天我们就来看看:

  • 什么是 self、Self 和 Self.Type?
  • 都在什么情况下使用?

self

这个大家用的比较多了,self 通常用于当你需要引用你当前所在范围内的对象时。所以,例如,如果在 Rocket 的实例方法中使用 self,在这种情况下,self 将是该 Rocket 的实例。这个很好理解~

struct Rocket {
    func launch() {
        print("10 秒内发射 \(self)")
    }
}

let rocket = Rocket()
rocket.launch() //10 秒内发射 Rocket()

但是,如果要在类方法或静态方法中使用 self,该怎么办?在这种情况下,self 不能作为对实例的引用,因为没有实例,而 self 具有当前类型的值。这是因为静态方法和类方法存在于类型本身而不是实例上。

class Dog {
    class func bark() {
        print("\(self) 汪汪汪!")
    }
}

Dog.bark() //Dog 汪汪汪!


struct Cat {
    static func meow() {
        print("\(self) 喵喵喵!")
    }
}

Cat.meow() // Cat 喵喵喵!


元类型

还有个需要注意的地方。所有的值都应该有一个类型,包括 self。就像上面提到的,静态和类方法存在于类型上,所以在这种情况下,self 就拥有了一种类型:Self.Type。比如:Dog.Type 就保存所有 Dog 的类型值。

包含其他类型的类型称为元类型

有点绕哈,简单来说,元类型 Dog.Type 不仅可以保存 Dog 类型的值,还可以保存它的所有子类的值。比如下面这个例子,其中 Labrador 是 Dog 的一个子类。

class Dog {
    class func bark() {
        print("\(self) 汪汪汪!")
    }
}

class Labrador: Dog {

}

Labrador.bark() //Labrador 汪汪汪!

如果你想将 type 本身当做一个属性,或者将其传递到函数中,那么你也可以将 type 本身作为值使用。这时候,就可以这样用:Type.self。

let dogType: Dog.Type = Labrador.self

func saySomething(dog: Dog.Type) {
    print("\(dog) 汪汪汪!")
}

saySomething(dog: dogType) // Labrador 汪汪汪!


Self

最后,就是大写 s 开头的 Self。在创建工厂方法或从协议方法返回具体类型时,非常的有用:

struct Rocket {
    func launch() {
        print("10 秒内发射 \(self)")
    }
}

extension Rocket {
    static func makeRocket() -> Self {
        return Rocket()
    }
}

protocol Factory {
    func make() -> Self
}

extension Rocket: Factory {
    func make() -> Rocket {
        return Rocket()
    }
}

收起阅读 »

iOS小技能:快速创建OEM项目app

iOS
iOS小技能:快速创建OEM项目app这是我参与11月更文挑战的第29天,活动详情查看:2021最后一次更文挑战。引言贴牌生产(英语:Original Equipment Manufacturer, OEM)因采购方可提供品牌和授权,允许制造方生产贴有该品牌的...
继续阅读 »

iOS小技能:快速创建OEM项目app

这是我参与11月更文挑战的第29天,活动详情查看:2021最后一次更文挑战

引言

贴牌生产(英语:Original Equipment Manufacturer, OEM)

因采购方可提供品牌和授权,允许制造方生产贴有该品牌的产品,所以俗称“贴牌生产”。

需求背景: SAAS平台级应用系统为一个特大商户,提供专属OEM项目,在原有通用app的基础上进行定制化开发

例如去掉开屏广告,删除部分模块,保留核心模块。更换专属app icon以及主题色

I 上架资料

  1. 用户协议及隐私政策
  2. App版本、 审核测试账号信息
  3. icon、名称、套装 ID(bundle identifier)
  4. 关键词:
  5. app描述:
  6. 技术支持网址使用:

kunnan.blog.csdn.net/article/det…

II 开发小细节

  1. 更换基础配置信息,比如消息推送证书、第三方SDK的ApiKey、启动图、用户协议及隐私政策。
  2. 接口修改:比如登录接口新增SysId请求字段用于区分新旧版、修改域名(备案信息)
  3. 废弃开屏广告pod 'GDTMobSDK' ,'4.13.26'

1.1 更换高德定位SDK的apiKey

    NSString *AMapKey = @"";
[AMapServices sharedServices].apiKey = AMapKey;


1.2 更新消息推送证书和极光的appKey

  1. Mac 上的“钥匙串访问”创建证书签名请求 (CSR)

a. 启动位于 /Applications/Utilities 中的“钥匙串访问”。

b. 选取“钥匙串访问”>“证书助理”>“从证书颁发机构请求证书”。

c. 在“证书助理”对话框中,在“用户电子邮件地址”栏位中输入电子邮件地址。

d. 在“常用名称”栏位中,输入密钥的名称 (例如,Gita Kumar Dev Key)。

e. 将“CA 电子邮件地址”栏位留空。

f. 选取“存储到磁盘”,然后点按“继续”。

help.apple.com/developer-a…

在这里插入图片描述

  1. 从developer.apple.com 后台找到对应的Identifiers创建消息推送证书,并双击aps.cer安装到本地Mac,然后从钥匙串导出P12的正式上传到极光后台。

docs.jiguang.cn//jpush/clie…在这里插入图片描述

  1. 更换appKey(极光平台应用的唯一标识)
        [JPUSHService setupWithOption:launchOptions appKey:@""
channel:@"App Store"
apsForProduction:YES
advertisingIdentifier:nil];


http://www.jiguang.cn/accounts/lo…

1.3 更换Bugly的APPId

    [Bugly startWithAppId:@""];//异常上报


1.4 app启动的新版本提示

更换appid

    [self checkTheVersionWithappid:@""];


检查版本

在这里插入图片描述


- (void)checkTheVersionWithappid:(NSString*)appid{


[QCTNetworkHelper getWithUrl:[NSString stringWithFormat:@"http://itunes.apple.com/cn/lookup?id=%@",appid] params:nil successBlock:^(NSDictionary *result) {
if ([[result objectForKey:@"results"] isKindOfClass:[NSArray class]]) {
NSArray *tempArr = [result objectForKey:@"results"];
if (tempArr.count) {


NSString *versionStr =[[tempArr objectAtIndex:0] valueForKey:@"version"];
NSString *appStoreVersion = [versionStr stringByReplacingOccurrencesOfString:@"." withString:@""] ;
if (appStoreVersion.length==2) {
appStoreVersion = [appStoreVersion stringByAppendingString:@"0"];
}else if (appStoreVersion.length==1){
appStoreVersion = [appStoreVersion stringByAppendingString:@"00"];
}

NSDictionary *infoDic=[[NSBundle mainBundle] infoDictionary];
NSString* currentVersion = [[infoDic valueForKey:@"CFBundleShortVersionString"] stringByReplacingOccurrencesOfString:@"." withString:@""];

currentVersion = [currentVersion stringByReplacingOccurrencesOfString:@"." withString:@""];
if (currentVersion.length==2) {
currentVersion = [currentVersion stringByAppendingString:@"0"];
}else if (currentVersion.length==1){
currentVersion = [currentVersion stringByAppendingString:@"00"];
}



NSLog(@"currentVersion: %@",currentVersion);


if([self compareVesionWithServerVersion:versionStr]){



UIAlertController *alertController = [UIAlertController alertControllerWithTitle:[NSString stringWithFormat:@"%@%@",QCTLocal(@"Discover_a_new_version"),versionStr] message:QCTLocal(@"Whethertoupdate") preferredStyle:UIAlertControllerStyleAlert];
// "Illtalkaboutitlater"= "稍后再说";
// "Update now" = "立即去更新";
// "Unupdate"= "取消更新";

[alertController addAction:[UIAlertAction actionWithTitle:QCTLocal(@"Illtalkaboutitlater") style:UIAlertActionStyleCancel handler:^(UIAlertAction * _Nonnull action) {
NSLog(@"取消更新");
}]];
[alertController addAction:[UIAlertAction actionWithTitle:QCTLocal(@"Updatenow") style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:@"itms-apps://itunes.apple.com/app/id%@",appid]];
if (@available(iOS 10.0, *)) {
[[UIApplication sharedApplication] openURL:url options:@{} completionHandler:^(BOOL success) {
}];
} else {
// Fallback on earlier vesions
[[UIApplication sharedApplication] openURL:url];
}
}]];
[[QCT_Common getCurrentVC] presentViewController:alertController animated:YES completion:nil];
}
}
}
} failureBlock:^(NSError *error) {
NSLog(@"检查版本错误: %@",error);
}];
}


see also

更多内容请关注 #小程序:iOS逆向,只为你呈现有价值的信息,专注于移动端技术研究领域;更多服务和咨询请关注#公众号:iOS逆向

链接:https://juejin.cn/post/7035926626366029837

收起阅读 »

objc_msgsend(中)方法动态决议

iOS
引入在学习本文之前我们应该了解objc_msgsend消息快速查找(上) objc_msgsend(中)消息慢速查找 当快速消息查找和消息慢速查找都也找不到imp时,苹果系统后续是怎么处理的我们一起来学习! 方法动态决议主要做了哪些事情?准...
继续阅读 »


引入

在学习本文之前我们应该了解

当快速消息查找和消息慢速查找都也找不到imp时,苹果系统后续是怎么处理的我们一起来学习! 方法动态决议主要做了哪些事情?

准备工作

resolveMethod_locked动态方法决议

1.png

  • 赋值imp = forward_imp

  • 做了个单例判断动态控制执行流程根据behavior方法只执行一次。

2.png

对象方法的动态决议

3.png

类方法的动态决议

3.png

lookUpImpOrForwardTryCache

4.png

cache_getImp

5.png

  • 苹果给与一次动态方法决议的机会来挽救APP
  • 如果是类请用resolveInstanceMethod
  • 如果是元类请用resolveClassMethod

如果都没有处理那么imp = forward_imp ,const IMP forward_imp = (IMP)_objc_msgForward_impcache;

_objc_msgForward_impcache探究

6.png

  • __objc_forward_handler主要看这个函数处理

__objc_forward_handler

7.png

代码案例分析

   int main(int argc, const char * argv[]) {
    @autoreleasepool {
        LGTeacher *p = [LGTeacher alloc];
        [t sayHappy];
[LGTeacher saygood];
    }
    return 0;
}


崩溃信息

2021-11-28 22:36:39.223567+0800 KCObjcBuild[12626:762145] +[LGTeacher sayHappy]: unrecognized selector sent to class 0x100008310

2021-11-28 22:36:39.226012+0800 KCObjcBuild[12626:762145] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[LGTeacher sayHappy]: unrecognized selector sent to class 0x100008310'

复制代码

动态方法决议处理对象方法找不到

代码动态决议处理imp修复崩溃

@implementation LGTeacher

-(void)text{
    NSLog(@"%s", __func__ );
}

+(void)say777{

    NSLog(@"%s", __func__ );
}

// 对象方法动态决议

+(BOOL**)resolveInstanceMethod:(SEL)sel{

    if (sel == @selector(sayHappy)) {

        IMP imp =class_getMethodImplementation(self, @selector(text));
        Method m = class_getInstanceMethod(self, @selector(text));
        const char * type = method_getTypeEncoding(m);
        return** class_addMethod(self, sel, imp, type);
    }
    return [super resolveInstanceMethod:sel];

}

//类方法动态决议

+ (BOOL)resolveClassMethod:(SEL)sel{
    if (sel == @selector(saygood)) {
        IMP  imp7 = class_getMethodImplementation(objc_getMetaClass("LGTeacher"), @selector(say777));
        Method m  = class_getInstanceMethod(objc_getMetaClass("LGTeacher"), @selector(say777));
        const char type = method_getTypeEncoding(m);
        return class_addMethod(objc_getMetaClass("LGTeacher"), sel, imp7, type);
    }

    return [super resolveClassMethod:sel];

}

@end


运行打印信息

2021-11-29 16:30:46.403671+0800 KCObjcBuild[27071:213498] -[LGTeacher text]

2021-11-29 16:30:46.404186+0800 KCObjcBuild[27071:213498] +[LGTeacher say777]

  • 找不到imp我们动态添加一个imp ,但这样处理太麻烦了。
  • 实例方法方法查找流程 类->父类->NSObject->nil
  • 类方法查找流程 元类->父类->根元类-NsObject->nil

最终都会找到NSobject.我们可以在NSObject统一处理 所以我们可以给NSObject创建个分类

@implementation NSObject (Xu)
+(BOOL)resolveInstanceMethod:(SEL)sel{
if (@selector(sayHello) == sel) {
NSLog(@"--进入%@--",NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(self , @selector(sayHello2));
Method meth = class_getInstanceMethod(self , @selector(sayHello2));
const char * type = method_getTypeEncoding(meth);
return class_addMethod(self ,sel, imp, type);;

}else if (@selector(test) == sel){
NSLog(@"--进入%@--",NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(object_getClass([self class]), @selector(newTest));
Method meth = class_getClassMethod(object_getClass([self class]) , @selector(newTest));
const char * type = method_getTypeEncoding(meth);
return class_addMethod(object_getClass([self class]) ,sel, imp, type);;
}
return NO;
}

- (void)sayHello2{
NSLog(@"--%s---",__func__);
}

+(void)newTest{
NSLog(@"--%s---",__func__);
}

@end


实例方法是类方法调用,系统都自动调用了resolveInstanceMethod方法,和上面探究的吻合。 动态方法决议优点

  • 可以统一处理方法崩溃的问题,出现方法崩溃可以上报服务器,或者跳转到首页
  • 如果项目中是不同的模块你可以根据命名不同,进行业务的区别
  • 这种方式叫切面编程熟成AOP

方法动态决议流程图

9.png

问题

  • resolveInstanceMethod为什么调用两次?
  • 统一处理方案怎么处理判断问题,可能是对象方法崩溃也可能是类方法崩溃,怎么处理?
  • 动态方法决议后苹果后续就没有处理了吗?

链接:https://juejin.cn/post/7035965819955707935
收起阅读 »

Android静态代码扫描效率优化与实践(下)

前面分析了如何获取差异文件以及增量扫描的原理,分析的重点还是侧重在Lint工具本身的实现机制上。接下来分析,在Gradle中如何实现一个增量扫描任务。大家知道,通过执行./gradlew lint命令来执行Lint静态代码检测任务。创建一个新的Android工...
继续阅读 »


Android静态代码扫描效率优化与实践(下)
Lint增量扫描Gradle任务实现

前面分析了如何获取差异文件以及增量扫描的原理,分析的重点还是侧重在Lint工具本身的实现机制上。接下来分析,在Gradle中如何实现一个增量扫描任务。大家知道,通过执行./gradlew lint命令来执行Lint静态代码检测任务。创建一个新的Android工程,在Gradle任务列表中可以在Verification这个组下面找到几个Lint任务,如下所示:

Android静态代码扫描效率优化与实践_美团_12

这几个任务就是 Android Gradle插件在加载的时候默认创建的。分别对应于以下几个Task:

  • lint->LintGlobalTask:由TaskManager创建;

  • lintDebug、lintRelease、lintVitalRelease->LintPerVariantTask:由ApplicationTaskManager或者LibraryTaskManager创建,其中lintVitalRelease只在release下生成。

所以,在Android Gradle 插件中,应用于Lint的任务分别为LintGlobalTask和LintPerVariantTask。他们的区别是前者执行的是扫描所有Variant,后者执行只针对单独的Variant。而我们的增量扫描任务其实是跟Variant无关的,因为我们会把所有差异文件都收集到。无论是LintGlobalTask或者是LintPerVariantTask,都继承自LintBaseTask。最终的扫描任务在LintGradleExecution的runLint方法中执行,这个类位于lint-gradle-26.1.1中,前面提到这个库是基于Lint的API针对Gradle任务做的一些封装。

/** Runs lint on the given variant and returns the set of warnings */
  private Pair, LintBaseline> runLint(
          @Nullable Variant variant,
          @NonNull VariantInputs variantInputs,
          boolean report, boolean isAndroid) {
      IssueRegistry registry = createIssueRegistry(isAndroid);
      LintCliFlags flags = new LintCliFlags();
      LintGradleClient client =
              new LintGradleClient(
                      descriptor.getGradlePluginVersion(),
                      registry,
                      flags,
                      descriptor.getProject(),
                      descriptor.getSdkHome(),
                      variant,
                      variantInputs,
                      descriptor.getBuildTools(),
                      isAndroid);
      boolean fatalOnly = descriptor.isFatalOnly();
      if (fatalOnly) {
          flags.setFatalOnly(true);
      }
      LintOptions lintOptions = descriptor.getLintOptions();
      if (lintOptions != null) {
          syncOptions(
                  lintOptions,
                  client,
                  flags,
                  variant,
                  descriptor.getProject(),
                  descriptor.getReportsDir(),
                  report,
                  fatalOnly);
      } else {
          // Set up some default reporters
          flags.getReporters().add(Reporter.createTextReporter(client, flags, null,
                  new PrintWriter(System.out, true), false));
          File html = validateOutputFile(createOutputPath(descriptor.getProject(), null, ".html",
                  null, flags.isFatalOnly()));
          File xml = validateOutputFile(createOutputPath(descriptor.getProject(), null, DOT_XML,
                  null, flags.isFatalOnly()));
          try {
              flags.getReporters().add(Reporter.createHtmlReporter(client, html, flags));
              flags.getReporters().add(Reporter.createXmlReporter(client, xml, false));
          } catch (IOException e) {
              throw new GradleException(e.getMessage(), e);
          }
      }
      if (!report || fatalOnly) {
          flags.setQuiet(true);
      }
      flags.setWriteBaselineIfMissing(report && !fatalOnly);

      Pair, LintBaseline> warnings;
      try {
          warnings = client.run(registry);
      } catch (IOException e) {
          throw new GradleException("Invalid arguments.", e);
      }

      if (report && client.haveErrors() && flags.isSetExitCode()) {
          abort(client, warnings.getFirst(), isAndroid);
      }

      return warnings;
  }

我们在这个方法中看到了warnings = client.run(registry),这就是Lint扫描得到的结果集。总结一下这个方法中做了哪些准备工作用于Lint扫描:

  1. 创建IssueRegistry,包含了Lint内建的BuiltinIssueRegistry;

  2. 创建LintCliFlags;

  3. 创建LintGradleClient,这里面传入了一大堆参数,都是从Gradle Android 插件的运行环境中获得;

  4. 同步LintOptions,这一步是将我们在build.gralde中配置的一些Lint相关的DSL属性,同步设置给LintCliFlags,给真正的Lint 扫描核心库使用;

  5. 执行Client的Run方法,开始扫描。

扫描的过程上面的原理部分已经分析了,现在我们思考一下如何构造增量扫描的任务。我们已经分析到扫描的关键点是client.run(registry),所以我们需要构造一个Client来执行扫描。一个想法是通过反射来获取Client的各个参数,当然这个思路是可行的,我们也验证过实现了一个用反射方式构造的Client。但是反射这种方式有个问题是丢失了从Gradle任务执行到调用Lint API开始扫描这一过程中做的其他事情,侵入性比较高,所以我们最终采用继承LintBaseTask自行实现增量扫描任务的方式。

FindBugs扫描简介

FindBugs是一个静态分析工具,它检查类或者JAR 文件,通过Apache的 BCEL 库来分析Class,将字节码与一组缺陷模式进行对比以发现问题。FindBugs自身定义了一套缺陷模式,目前的版本3.0.1内置了总计300多种缺陷,详细可参考 官方文档 。FindBugs作为一个扫描的工具集,可以非常灵活的集成在各种编译工具中。接下来,我们主要分析在Gradle中FindBugs的相关内容。

Gradle FindBugs任务属性分析

在Gradle的内置任务中,有一个FindBugs的Task,我们看一下 官方文档 对Gradle属性的描述。

选几个比较重要的属性介绍:

  • Classes

该属性表示我们要分析的Class文件集合,通常我们会把编译结果的Class目录用于扫描。
  • Classpath

分析目标集合中的Class需要用到的所有相关的Classes路径,但是并不会分析它们自身,只用于扫描。
  • Effort

包含MIN,Default,MAX,级别越高,分析得越严谨越耗时。
  • findbugsClasspath

Finbugs库相关的依赖路径,用于配置扫描的引擎库。
  • reportLevel

报告级别,分为Low,Medium,High。如果为Low,所有Bug都报告,如果为High,仅报告High优先级。
  • Reports

扫描结果存放路径。

通过以上属性解释,不难发现要FindBugs增量扫描,只需要指定Classes的文件集合就可以了。

FindBugs任务增量扫描分析

在做增量扫描任务之前,我们先来看一下FindBugs IDEA插件是如何进行单个文件扫描的。

Android静态代码扫描效率优化与实践_Android教程_13

我们选择Analyze Current File对当前文件进行扫描,扫描结果如下所示:

Android静态代码扫描效率优化与实践_Android教程_14

可以看到确实只扫描了一个文件。那么扫描到底使用了哪些输入数据呢,我们可以通过扫描结果的提示清楚看到:

Android静态代码扫描效率优化与实践_美团_15

这里我们能看到很多有用的信息:

  • 源码目录列表,包含了工程中的Java目录,res目录,以及编译过程中生成的一些类目录;

  • 需要分析的目标Class集合,为编译后的Build目录下的当前Java文件对应的Class文件;

  • Aux Classpath Entries,表示分析上面的目标文件需要用到的类路径。

所以,根据IDEA的扫描结果来看,我们在做增量扫描的时候需要解决上面这几个属性的获取。在前面我们分析的属性是Gradle在FindBugs lib的基础上,定义的一套对应的Task属性。真正的Finbugs属性我们可以通过 官方文档 或者源码中查到。

配置AuxClasspath

前文提到,ClassPath是用来分析目标文件需要用到的相关依赖Class,但本身并不会被分析,所以我们需要尽可能全的找到所有的依赖库,否则在扫描的时候会报依赖的类库找不到。

FileCollection buildClasses = project.fileTree(dir: "${project.buildDir}/intermediates/classes/${variant.flavorName}/${variant.buildType.name}",includes: classIncludes)

FileCollection targetClasspath = project.files()
GradleUtils.collectDepProject(project, variant).each { targetProject ->
  GradleUtils.getAndroidVariants(targetProject).each { targetVariant ->
      if (targetVariant.name.capitalize().equalsIgnoreCase(variant.name.capitalize())) {
          targetClasspath += targetVariant.javaCompile.classpath
      }
  }
}

classpath = variant.javaCompile.classpath + targetClasspath + buildClasses
FindBugs增量扫描误报优化

对于增量文件扫描,参与的少数文件扫描在某些模式规则上可能会出现误判,但是全量扫描不会有问题,因为参与分析的目标文件是全集。举一个例子:

class A {
public static String buildTime = "";
....
}

静态变量buildTime会被认为应该加上Final,但是其实其他类会对这个变量赋值。如果单独扫描类A文件,就会报缺陷BUG_TYPE_MS_SHOULD_BE_FINAL。我们通过FindBugs-IDEA插件来扫描验证,也同样会有一样的问题。要解决此类问题,需要找到谁依赖了类A,并且一同参与扫描,同时也需要找出类A依赖了哪些文件,简单来说:需要找出与类A有直接关联的类。为了解决这个问题,我们通过ASM来找出相关的依赖,具体如下:

void findAllScanClasses(ConfigurableFileTree allClass) {
  allScanFiles = [] as HashSet
  String buildClassDir = "${project.buildDir}/$FINDBUGS_ANALYSIS_DIR/$FINDBUGS_ANALYSIS_DIR_ORIGIN"

  Set moduleClassFiles = allClass.files
  for (File file : moduleClassFiles) {
      String[] splitPath = file.absolutePath.split("$FINDBUGS_ANALYSIS_DIR/$FINDBUGS_ANALYSIS_DIR_ORIGIN/")
      if (splitPath.length > 1) {
          String className = getFileNameNoFlag(splitPath[1],'.')
          String innerClassPrefix = ""
          if (className.contains('$')) {
              innerClassPrefix = className.split('\\$')[0]
          }
          if (diffClassNamePath.contains(className) || diffClassNamePath.contains(innerClassPrefix)) {
              allScanFiles.add(file)
          } else {
              Iterable classToResolve = new ArrayList()
              classToResolve.add(file.absolutePath)
              Set dependencyClasses = Dependencies.findClassDependencies(project, new ClassAcceptor(), buildClassDir, classToResolve)
              for (File dependencyClass : dependencyClasses) {
                  if (diffClassNamePath.contains(getPackagePathName(dependencyClass))) {
                      allScanFiles.add(file)
                      break
                  }
              }
          }
      }
  }
}

通过以上方式,我们可以解决一些增量扫描时出现的误报情况,相比IDEA工具,我们更进一步降低了扫描部分文件的误报率。

CheckStyle增量扫描

相比而言,CheckStyle的增量扫描就比较简单了。CheckStyle对源码扫描,根据[ 官方文档]各个属性的描述,我们发现只要指定Source属性的值就可以指定扫描的目标文件。

void configureIncrementScanSource() {
  boolean isCheckPR = false
  DiffFileFinder diffFileFinder

  if (project.hasProperty(CodeDetectorExtension.CHECK_PR)) {
      isCheckPR = project.getProperties().get(CodeDetectorExtension.CHECK_PR)
  }

  if (isCheckPR) {
      diffFileFinder = new DiffFileFinderHelper.PRDiffFileFinder()
  } else {
      diffFileFinder = new DiffFileFinderHelper.LocalDiffFileFinder()
  }

  source diffFileFinder.findDiffFiles(project)

  if (getSource().isEmpty()) {
      println '没有找到差异java文件,跳过checkStyle检测'
  }
}

优化结果数据

经过全量扫描和增量扫描的优化,我们整个扫描效率得到了很大提升,一次PR构建扫描效率整体提升50%+。优化数据如下:

Android静态代码扫描效率优化与实践_Android教程_16

落地与沉淀

扫描工具通用性

解决了扫描效率问题,我们想怎么让更多的工程能低成本的使用这个扫描插件。对于一个已经存在的工程,如果没有使用过静态代码扫描,我们希望在接入扫描插件后续新增的代码能够保证其经过增量扫描没有问题。而老的存量代码,由于代码量过大增量扫描并没有效率上的优势,我们希望可以使用全量扫描逐步解决存量代码存在的问题。同时,为了配置工具的灵活,也提供配置来让接入方自己决定选择接入哪些工具。这样可以让扫描工具同时覆盖到新老项目,保证其通用。所以,要同时支持配置使用增量或者全量扫描任务,并且提供灵活的选择接入哪些扫描工具

扫描完整性保证

前面提到过,在FindBugs增量扫描可能会出现因为参与分析的目标文件集不全导致的某类匹配规则误报,所以在保证扫描效率的同时,也要保证扫描的完整性和准确性。我们的策略是以增量扫描为主,全量扫描为辅,PR提交使用增量扫描提高效率,在CI配置Daily Build使用全量扫描保证扫描完整和不遗漏

我们在自己的项目中实践配置如下:

apply plugin: 'code-detector'

codeDetector {
  // 配置静态代码检测报告的存放位置
  reportRelativePath = rootProject.file('reports')

  /**
    * 远程仓库地址,用于配置提交pr时增量检测
    */
  upstreamGitUrl = "ssh://git@xxxxxxxx.git"

  checkStyleConfig {
      /**
        * 开启或关闭 CheckStyle 检测
        * 开启:true
        * 关闭:false
        */
      enable = true
      /**
        * 出错后是否要终止检查
        * 终止:false
        * 不终止:true。配置成不终止的话 CheckStyleTask 不会失败,也不会拷贝错误报告
        */
      ignoreFailures = false
      /**
        * 是否在日志中展示违规信息
        * 显示:true
        * 不显示:false
        */
      showViolations = true
      /**
        * 统一配置自定义的 checkstyle.xml 和 checkstyle.xsl 的 uri
        * 配置路径为:
        *     "${checkStyleUri}/checkstyle.xml"
        *     "${checkStyleUri}/checkstyle.xsl"
        *
        * 默认为 null,使用 CodeDetector 中的默认配置
        */
      checkStyleUri = rootProject.file('codequality/checkstyle')
  }

  findBugsConfig {
      /**
        * 开启或关闭 Findbugs 检测
        * 开启:true
        * 关闭:false
        */
      enable = true
      /**
        * 可选项,设置分析工作的等级,默认值为 max
        * min, default, or max. max 分析更严谨,报告的 bug 更多. min 略微少些
        */
      effort = "max"
      /**
        * 可选项,默认值为 high
        * low, medium, high. 如果是 low 的话,那么报告所有的 bug
        */
      reportLevel = "high"
      /**
        * 统一配置自定义的 findbugs_include.xml 和 findbugs_exclude.xml 的 uri
        * 配置路径为:
        *     "${findBugsUri}/findbugs_include.xml"
        *     "${findBugsUri}/findbugs_exclude.xml"
        * 默认为 null,使用 CodeDetector 中的默认配置
        */
      findBugsUri = rootProject.file('codequality/findbugs')
  }

  lintConfig {

      /**
        * 开启或关闭 lint 检测
        * 开启:true
        * 关闭:false
        */
      enable = true

      /**
        * 统一配置自定义的 lint.xml 和 retrolambda_lint.xml 的 uri
        * 配置路径为:
        *     "${lintConfigUri}/lint.xml"
        *     "${lintConfigUri}/retrolambda_lint.xml"
        * 默认为 null,使用 CodeDetector 中的默认配置
        */
      lintConfigUri = rootProject.file('codequality/lint')
  }
}

我们希望扫描插件可以灵活指定增量扫描还是全量扫描以应对不同的使用场景,比如已存在项目的接入、新项目的接入、打包时的检测等。

执行脚本示例:

./gradlew ":${appModuleName}:assemble${ultimateVariantName}" -PdetectorEnable=true -PcheckStyleIncrement=true -PlintIncrement=true -PfindBugsIncrement=true -PcheckPR=${checkPR} -PsourceCommitHash=${sourceCommitHash} -PtargetBranch=${targetBranch} --stacktrace

希望一次任务可以暴露所有扫描工具发现的问题,当某一个工具扫描到问题后不终止任务,如果是本地运行在发现问题后可以自动打开浏览器方便查看问题原因。

def finalizedTaskArray = [lintTask,checkStyleTask,findbugsTask]
checkCodeTask.finalizedBy finalizedTaskArray

"open ${reportPath}".execute()

为了保证提交的PR不会引起打包问题影响包的交付,在PR时触发的任务实际为打包任务,我们将静态代码扫描任务挂接在打包任务中。由于我们的项目是多Flavor构建,在CI上我们将触发多个Job同时执行对应Flavor的增量扫描和打包任务。同时为了保证代码扫描的完整性,我们在真正的打包Job上执行全量扫描。

总结与展望

本文主要介绍了在静态代码扫描优化方面的一些思路与实践,并重点探讨了对Lint、FindBugs、CheckStyle增量扫描的一些尝试。通过对扫描插件的优化,我们在代码扫描的效率上得到了提升,同时在实践过程中我们也积累了自定义Lint检测规则的方案,未来我们将配合基础设施标准化建设,结合静态扫描插件制定一些标准化检测规则来更好的保证我们的代码规范以及质量。

参考资料

作者简介

鸿耀,美团餐饮生态技术团队研发工程师。

作者:美团技术团队 · 鸿耀
来源:https://blog.51cto.com/u_15197658/2768467

收起阅读 »

Android静态代码扫描效率优化与实践(上)

背景与问题思考与策略思考一:现有插件包含的扫描工具是否都是必需的?为了验证扫描工具的必要性,我们关心以下一些维度:经过以上的对比分析我们发现,工具的诞生都能针对性解决某一领域问题。CheckStyle的扫描速度快效率高,对代码风格和圈复杂度支持友好;FindB...
继续阅读 »



小伙伴们,美美又来推荐干货文章啦~本文为美团研发同学实战经验,主要介绍Android静态扫描工具Lint、CheckStyle、FindBugs在扫描效率优化上的一些探索和实践,希望大家喜欢鸭。

背景与问题

DevOps实践中,我们在CI(Continuous Integration)持续集成过程主要包含了代码提交、静态检测、单元测试、编译打包环节。其中静态代码检测可以在编码规范,代码缺陷,性能等问题上提前预知,从而保证项目的交付质量。Android项目常用的静态扫描工具包括CheckStyle、Lint、FindBugs等,为降低接入成本,美团内部孵化了静态代码扫描插件,集合了以上常用的扫描工具。项目初期引入集团内部基建时我们接入了代码扫描插件,在PR(Pull Request)流程中借助Jenkins插件来触发自动化构建,从而达到监控代码质量的目的。初期单次构建耗时平均在1~2min左右,对研发效率影响甚少。但是随着时间推移,代码量随业务倍增,项目也开始使用Flavor来满足复杂的需求,这使得我们的单次PR构建达到了8~9min左右,其中静态代码扫描的时长约占50%,持续集成效率不高,对我们的研发效率带来了挑战。

思考与策略

针对以上的背景和问题,我们思考以下几个问题:

思考一:现有插件包含的扫描工具是否都是必需的?

扫描工具对比

为了验证扫描工具的必要性,我们关心以下一些维度:

  • 扫码侧重点,对比各个工具分别能针对解决什么类型的问题;

  • 内置规则种类,列举各个工具提供的能力覆盖范围;

  • 扫描对象,对比各个工具针对什么样的文件类型扫描;

  • 原理简介,简单介绍各个工具的扫描原理;

  • 优缺点,简单对比各个工具扫描效率、扩展性、定制性、全面性上的表现。

Android静态代码扫描效率优化与实践_美团_03

注:FindBugs只支持Java1.0~1.8,已经被SpotBugs替代。鉴于部分老项目并没有迁移到Java8,目前我们并没有使用SpotBugs代替FindBugs的原因如下,详情参考 官方文档
Android静态代码扫描效率优化与实践_美团_04
同时,SpotBugs的作者也在 讨论是否让SpotBugs支持老的Java版本,结论是不提供支持。

经过以上的对比分析我们发现,工具的诞生都能针对性解决某一领域问题。CheckStyle的扫描速度快效率高,对代码风格和圈复杂度支持友好;FindBugs针对Java代码潜在问题,能帮助我们发现编码上的一些错误实践以及部分安全问题和性能问题;Lint是官方深度定制,功能极其强大,且可定制性和扩展性以及全面性都表现良好。所以综合考虑,针对思考一,我们的结论是整合三种扫描工具,充分利用每一个工具的领域特性。

思考二:是否可以优化扫描过程?

既然选择了整合这几种工具,我们面临的挑战是整合工具后扫描效率的问题,首先来分析目前的插件到底耗时在哪里。

静态代码扫描耗时分析

Android项目的构建依赖Gradle工具,一次构建过程实际上是执行所有的Gradle Task。由于Gradle的特性,在构建时各个Module都需要执行CheckStyle、FindBugs、Lint相关的Task。对于Android来说,Task的数量还与其构建变体Variant有关,其中Variant = Flavor * BuildType。所以一个Module执行的相关任务可以由以下公式来描述:Flavor * BuildType (Lint,CheckStyle,Findbugs),其中为笛卡尔积。如下图所示:

Android静态代码扫描效率优化与实践_美团_05

可以看到,一次构建全量扫描执行的Task跟Varint个数正相关。对于现有工程的任务,我们可以看一下目前各个任务的耗时情况:(以实际开发中某一次扫描为例)

Android静态代码扫描效率优化与实践_Android开发_06

通过对Task耗时排序,主要的耗时体现在FindBugs和Lint对每一个Module的扫描任务上,CheckStyle任务并不占主要影响。整体来看,除了工具本身的扫描时间外,耗时主要分为多Module多Variant带来的任务数量耗时。

优化思路分析

对于工具本身的扫描时间,一方面受工具自身扫描算法和检测规则的影响,另一方面也跟扫描的文件数量相关。针对源码类型的工具比如CheckStyle和Lint,需要经过词法分析、语法分析生成抽象语法树,再遍历抽象语法树跟定义的检测规则去匹配;而针对字节码文件的工具FindBugs,需要先编译源码成Class文件,再通过BCEL分析字节码指令并与探测器规则匹配。如果要在工具本身算法上去寻找优化点,代价比较大也不一定能找到有效思路,投入产出比不高,所以我们把精力放在减少Module和Variant带来的影响上。

从上面的耗时分析可以知道,Module和Variant数直接影响任务数量, 一次PR提交的场景是多样的,比如多Module多Variant都有修改,所以要考虑这些都修改的场景。先分析一个Module多Variant的场景,考虑到不同的Variant下源代码有一定差异,并且FindBugs扫描针对的是Class文件,不同的Variant都需要编译后才能扫描,直接对多Variant做处理比较复杂。我们可以简化问题,用以空间换时间的方式,在提交PR的时候根据Variant用不同的Jenkins Job来执行每一个Variant的扫描任务。所以接下来的问题就转变为如何优化在扫描单个Variant的时候多Module任务带来的耗时。

对于Module数而言,我们可以将其抽取成组件,拆分到独立仓库,将扫描任务拆分到各自仓库的变动时期,以aar的形式集成到主项目来减少Module带来的任务数。那对于剩下的Module如何优化呢?无论是哪一种工具,都是对其输入文件进行处理,CheckStyle对Java源代码文件处理,FindBugs对Java字节码文件处理,如果我们可以通过一次任务收集到所有Module的源码文件和编译后的字节码文件,我们就可以减少多Module的任务了。所以对于全量扫描,我们的主要目标是来解决如何一次性收集所有Module的目标文件

思考三:是否支持增量扫描?

上面的优化思路都是基于全量扫描的,解决的是多Module多Variant带来的任务数量耗时。前面提到,工具本身的扫描时间也跟扫描的文件数量有关,那么是否可以从扫描的文件数量来入手呢?考虑平时的开发场景,提交PR时只是部分文件修改,我们没必要把那些没修改过的存量文件再参与扫描,而只针对修改的增量文件扫描,这样能很大程度降低无效扫描带来的效率问题。有了思路,那么我们考虑以下几个问题:

  • 如何收集增量文件,包括源码文件和Class文件?

  • 现在业界是否有增量扫描的方案,可行性如何,是否适用我们现状?

  • 各个扫描工具如何来支持增量文件的扫描?

根据上面的分析与思考路径,接下来我们详细介绍如何解决上述问题。

优化探索与实践

全量扫描优化

搜集所有Module目标文件集

获取所有Module目标文件集,首先要找出哪些Module参与了扫描。一个Module工程在Gradle构建系统中被描述为一个“Project”,那么我们只需要找出主工程依赖的所有Project即可。由于依赖配置的多样性,我们可以选择在某些Variant下依赖不同的Module,所以获取参与一次构建时与当前Variant相关的Project对象,我们可以用如下方式:

static Set collectDepProject(Project project, BaseVariant variant, Set result = null) {
if (result == null) {
  result = new HashSet<>()
}
Set taskSet = variant.javaCompiler.taskDependencies.getDependencies(variant.javaCompiler)
taskSet.each { Task task ->
  if (task.project != project && hasAndroidPlugin(task.project)) {
    result.add(task.project)
    BaseVariant childVariant = getVariant(task.project)
    if (childVariant.name == variant.name || "${variant.flavorName}${childVariant.buildType.name}".toLowerCase() == variant.name.toLowerCase()) {
      collectDepProject(task.project, childVariant, result)
    }
  }
}
return result
}

目前文件集分为两类,一类是源码文件,另一类是字节码文件,分别可以如下处理:

projectSet.each { targetProject ->
if (targetProject.plugins.hasPlugin(CodeDetectorPlugin) && GradleUtils.hasAndroidPlugin(targetProject)) {
  GradleUtils.getAndroidExtension(targetProject).sourceSets.all { AndroidSourceSet sourceSet ->
    if (!sourceSet.name.startsWith("test") && !sourceSet.name.startsWith(SdkConstants.FD_TEST)) {
      source sourceSet.java.srcDirs
    }
  }
}
}

注:上面的Source是CheckStyle Task的属性,用其来指定扫描的文件集合;

// 排除掉一些模板代码class文件
static final Collection defaultExcludes = (androidDataBindingExcludes + androidExcludes + butterKnifeExcludes + dagger2Excludes).asImmutable()

List allClassesFileTree = new ArrayList<>()
ConfigurableFileTree currentProjectClassesDir = project.fileTree(dir: variant.javaCompile.destinationDir, excludes: defaultExcludes)
allClassesFileTree.add(currentProjectClassesDir)
GradleUtils.collectDepProject(project, variant).each { targetProject ->
if (targetProject.plugins.hasPlugin(CodeDetectorPlugin) && GradleUtils.hasAndroidPlugin(targetProject)) {
  // 可能有的工程没有Flavor只有buildType
    GradleUtils.getAndroidVariants(targetProject).each { BaseVariant targetProjectVariant ->
    if (targetProjectVariant.name == variant.name || "${targetProjectVariant.name}".toLowerCase() == variant.buildType.name.toLowerCase()) {
        allClassesFileTree.add(targetProject.fileTree(dir: targetProjectVariant.javaCompile.destinationDir, excludes: defaultExcludes))
    }
  }
}
}

注:收集到字节码文件集后,可以用通过FindBugsTask 的 Class 属性指定扫描,后文会详细介绍FindBugs Task相关属性。

对于Lint工具而言,相应的Lint Task并没有相关属性可以指定扫描文件,所以在全量扫描上,我们暂时没有针对Lint做优化。

全量扫描优化数据

通过对CheckStyle和FindBugs全量扫描的优化,我们将整体扫描时间由原来的9min降低到了5min左右。

Android静态代码扫描效率优化与实践_美团_07

增量扫描优化

由前面的思考分析我们知道,并不是所有的文件每次都需要参与扫描,所以我们可以通过增量扫描的方式来提高扫描效率。

增量扫描技术调研

在做具体技术方案之前,我们先调研一下业界的现有方案,调研如下:

Android静态代码扫描效率优化与实践_Android教程_08

针对Lint,我们可以借鉴现有实现思路,同时深入分析扫描原理,在3.x版本上寻找出增量扫描的解决方案。对于CheckStyle和FindBugs,我们需要了解工具的相关配置参数,为其指定特定的差异文件集合。

注:业界有一些增量扫描的案例,例如 diff_cover,此工具主要是对单元测试整体覆盖率的检测,以增量代码覆盖率作为一个指标来衡量项目的质量,但是这跟我们的静态代码分析的需求不太符合。它有一个比较好的思路是找出差异的代码行来分析覆盖率,粒度比较细。但是对于静态代码扫描,仅仅的差异行不足以完成上下文的语义分析,尤其是针对FindBugs这类需要分析字节码的工具,获取的差异行还需要经过编译成Class文件才能进行分析,方案并不可取。

寻找增量修改文件

增量扫描的第一步是获取待扫描的目标文件。我们可以通过git diff命令来获取差异文件,值得注意的是对于删除的文件和重命名的文件需要忽略,我们更关心新增和修改的文件,并且只需要获取差异文件的路径就好了。举个例子:git diff --name-only --diff-filter=dr commitHash1 commitHash2,以上命令意思是对比两次提交记录的差异文件并获取路径,过滤删除和重命名的文件。对于寻找本地仓库的差异文件上面的命令已经足够了,但是对于PR的情况还有一些复杂,需要对比本地代码与远程仓库目标分支的差异。集团的代码管理工具在Jenkins上有相应的插件,该插件默认提供了几个参数,我们需要用到以下两个:

  • ${targetBranch}:需要合入代码的目标分支地址;

  • ${sourceCommitHash}:需要提交的代码hash值。

通过这两个参数执行以下一系列命令来获取与远程目标分支的差异文件。

git remote add upstream ${upstreamGitUrl}
git fetch upstream ${targetBranch}
git diff --name-only --diff-filter=dr $sourceCommitHash upstream/$targetBranch
  1. 配置远程分支别名为UpStream,其中upstreamGitUrl可以在插件提供的配置属性中设置;

  2. 获取远程目标分支的更新;

  3. 比较分支差异获取文件路径。

通过以上方式,我们找到了增量修改文件集。

Lint扫描原理分析

在分析Lint增量扫描原理之前,先介绍一下Lint扫描的工作流程:

Android静态代码扫描效率优化与实践_Android教程_09

App Source Files

项目中的源文件,包括Java、XML、资源文件、proGuard等。

lint.xml

用于配置希望排除的任何 Lint 检查以及自定义问题严重级别,一般各个项目都会根据自身项目情况自定义的lint.xml来排除一些检查项。

lint Tool

一套完整的扫描工具用于对Android的代码结构进行分析,可以通过命令行、IDEA、Gradle命令三种方式运行lint工具。

lint Output

Lint扫描的输出结果。

从上面可以看出,Lint Tool就像一个加工厂,对投入进来的原料(源代码)进行加工处理(各种检测器分析),得到最终的产品(扫描结果)。Lint Tool作为一个扫描工具集,有多种使用方式。Android为我们提供了三种运行方式,分别是命令行、IDEA、Gradle任务。这三种方式最终都殊途同归,通过LintDriver来实现扫描。如下图所示:

Android静态代码扫描效率优化与实践_美团_10

为了方便查看源码,新建一个工程,在build.gradle脚本中,添加如下依赖:

compile 'com.android.tools.build:gradle:3.1.1'
compile 'com.android.tools.lint:lint-gradle:26.1.1'

我们可以得到如下所示的依赖:

Android静态代码扫描效率优化与实践_Android教程_11

lint-api-26.1.1

Lint工具集的一个封装,实现了一组API接口,用于启动Lint。

lint-checks-26.1.1

一组内建的检测器,用于对这种描述好Issue进行分析处理。

lint-26.1.1

可以看做是依赖上面两个jar形成的一个基于命令行的封装接口形成的脚手架工程,我们的命令行、Gradle任务都是继承自这个jar包中相关类来做的实现。

lint-gradle-26.1.1

可以看做是针对Gradle任务这种运行方式,基于lint-26.1.1做了一些封装类。

lint-gradle-api-26.1.1

真正Gradle Lint任务在执行时调用的入口。

在理解清楚了以上几个jar的关系和作用之后,我们可以发现Lint的核心库其实是前三个依赖。后面两个其实是基于脚手架,对Gradle这种运行方式做的封装。最核心的逻辑在LintDriver的Analyze方法中。

fun analyze() {

  ...省略部分代码...

   for (project in projects) {
       fireEvent(EventType.REGISTERED_PROJECT, project = project)
  }
   registerCustomDetectors(projects)

  ...省略部分代码...

   try {
       for (project in projects) {
           phase = 1

           val main = request.getMainProject(project)

           // The set of available detectors varies between projects
           computeDetectors(project)

           if (applicableDetectors.isEmpty()) {
               // No detectors enabled in this project: skip it
               continue
          }

           checkProject(project, main)
           if (isCanceled) {
               break
          }

           runExtraPhases(project, main)
      }
  } catch (throwable: Throwable) {
       // Process canceled etc
       if (!handleDetectorError(null, this, throwable)) {
           cancel()
      }
  }
  ...省略部分代码...
}

主要是以下三个重要步骤:

registerCustomDetectors(projects)

Lint为我们提供了许多内建的检测器,除此之外我们还可以自定义一些检测器,这些都需要注册进Lint工具用于对目标文件进行扫描。这个方法主要做以下几件事情:

  1. 遍历每一个Project和它的依赖Library工程,通过client.findRuleJars来找出自定义的jar包;

  2. 通过client.findGlobalRuleJars找出全局的自定义jar包,可以作用于每一个Android工程;

  3. 从找到的jarFiles列表中,解析出自定义的规则,并与内建的Registry一起合并为CompositeIssueRegistry;需要注意的是,自定义的Lint的jar包存放位置是build/intermediaters/lint目录,如果是需要每一个工程都生效,则存放位置为~/.android/lint/

computeDetectors(project)

这一步主要用来收集当前工程所有可用的检测器。

checkProject(project, main)

接下来这一步是最为关键的一步。在此方法中,调用runFileDetectors来进行文件扫描。Lint支持的扫描文件类型很多,因为是官方支持,所以针对Android工程支持的比较友好。一次Lint任务运行时,Lint的扫描范围主要由Scope来描述。具体表现在:

fun infer(projects: Collection?): EnumSet {
          if (projects == null || projects.isEmpty()) {
              return Scope.ALL
          }

          // Infer the scope
          var scope = EnumSet.noneOf(Scope::class.java)
          for (project in projects) {
              val subset = project.subset
              if (subset != null) {
                  for (file in subset) {
                      val name = file.name
                      if (name == ANDROID_MANIFEST_XML) {
                          scope.add(MANIFEST)
                      } else if (name.endsWith(DOT_XML)) {
                          scope.add(RESOURCE_FILE)
                      } else if (name.endsWith(DOT_JAVA) || name.endsWith(DOT_KT)) {
                          scope.add(JAVA_FILE)
                      } else if (name.endsWith(DOT_CLASS)) {
                          scope.add(CLASS_FILE)
                      } else if (name.endsWith(DOT_GRADLE)) {
                          scope.add(GRADLE_FILE)
                      } else if (name == OLD_PROGUARD_FILE || name == FN_PROJECT_PROGUARD_FILE) {
                          scope.add(PROGUARD_FILE)
                      } else if (name.endsWith(DOT_PROPERTIES)) {
                          scope.add(PROPERTY_FILE)
                      } else if (name.endsWith(DOT_PNG)) {
                          scope.add(BINARY_RESOURCE_FILE)
                      } else if (name == RES_FOLDER || file.parent == RES_FOLDER) {
                          scope.add(ALL_RESOURCE_FILES)
                          scope.add(RESOURCE_FILE)
                          scope.add(BINARY_RESOURCE_FILE)
                          scope.add(RESOURCE_FOLDER)
                      }
                  }
              } else {
                  // Specified a full project: just use the full project scope
                  scope = Scope.ALL
                  break
              }
          }
}

可以看到,如果Project的Subset为Null,Scope就为Scope.ALL,表示本次扫描会针对能检测的所有范围,相应地在扫描时也会用到所有全部的Detector来扫描文件;

如果Project的Subset不为Null,就遍历Subset的集合,找出Subset中的文件分别对应哪些范围。其实到这里我们已经可以知道,Subset就是我们增量扫描的突破点。接下来我们看一下runFileDetectors:

if(scope.contains(Scope.JAVA_FILE)||scope.contains(Scope.ALL_JAVA_FILES)){
val checks = union(scopeDetectors[Scope.JAVA_FILE],scopeDetectors[Scope.ALL_JAVA_FILES])
if (checks != null && !checks.isEmpty()) {
  val files = project.subset
  if (files != null) {
    checkIndividualJavaFiles(project, main, checks, files)
  } else {
    val sourceFolders = project.javaSourceFolders
    val testFolders = if (scope.contains(Scope.TEST_SOURCES))
    project.testSourceFolders
    else
    emptyList ()
    val generatedFolders = if (isCheckGeneratedSources)
    project.generatedSourceFolders
    else
    emptyList ()
    checkJava(project, main, sourceFolders, testFolders, generatedFolders, checks)
  }
}
}

这里更加明确,如果project.subset不为空,就对单独的Java文件扫描,否则,就对源码文件和测试目录以及自动生成的代码目录进行扫描。整个runFileDetectors的扫描顺序入下:

  1. Scope.MANIFEST

  2. Scope.ALL_RESOURCE_FILES)|| scope.contains(Scope.RESOURCE_FILE) ||

    scope.contains(Scope.RESOURCE_FOLDER) || scope.contains(Scope.BINARY_RESOURCE_FILE)

  3. scope.contains(Scope.JAVA_FILE) || scope.contains(Scope.ALL_JAVA_FILES)

  4. scope.contains(Scope.CLASS_FILE) || scope.contains(Scope.ALL_CLASS_FILES) ||

    scope.contains(Scope.JAVA_LIBRARIES)

  5. scope.contains(Scope.GRADLE_FILE)

  6. scope.contains(Scope.OTHER)

  7. scope.contains(Scope.PROGUARD_FILE)

  8. scope.contains(Scope.PROPERTY_FILE)

官方文档的描述顺序一致。

现在我们已经知道,增量扫描的突破点其实是需要构造project.subset对象。

    /**
    * Adds the given file to the list of files which should be checked in this
    * project. If no files are added, the whole project will be checked.
    *
    * @param file the file to be checked
    */
  public void addFile(@NonNull File file) {
      if (files == null) {
          files = new ArrayList<>();
      }
      files.add(file);
  }

  /**
    * The list of files to be checked in this project. If null, the whole
    * project should be checked.
    *
    * @return the subset of files to be checked, or null for the whole project
    */
  @Nullable
  public List getSubset() {
      return files;
  }

注释也很明确的说明了只要Files不为Null,就会扫描指定文件,否则扫描整个工程。

Android静态代码扫描效率优化与实践(下)

作者:美团技术团队 · 鸿耀
来源:https://blog.51cto.com/u_15197658/2768467

收起阅读 »

Python内存驻留机制

驻留下面举例介绍python中的驻留机制。 python内存驻留知道结果是什么吗?下面是执行结果:TrueFalseTrueTrue整型驻留执行结果:FalseTrueTrueTrue因为启动时,Python 将一个 -5~256 之间整数列表预加载(缓存)到...
继续阅读 »



字符串驻留机制在许多面向对象编程语言中都支持,比如Java、python、Ruby、PHP等,它是一种数据缓存机制,对不可变数据类型使用同一个内存地址,有效的节省了空间,本文主要介绍Python的内存驻留机制。

驻留

字符串驻留就是每个字符串只有一个副本,多个对象共享该副本,驻留只针对不可变数据类型,比如字符串,布尔值,数字等。在这些固定数据类型处理中,使用驻留可以有效节省时间和空间,当然在驻留池中创建或者插入新的内容会消耗一定的时间。

下面举例介绍python中的驻留机制。
python内存驻留

在Python对象及内存管理机制一文中介绍了python的参数传递以及以及内存管理机制,来看下面一段代码:

l1 = [1, 2, 3, 4]
l2 = [1, 2, 3, 4]
l3 = l2
print(l1 == l2)
print(l1 is l2)
print(l2 == l3)
print(l2 is l3)

知道结果是什么吗?下面是执行结果:

True
False
True
True

l1和l2内容相同,却指向了不同的内存地址,l2和l3之间使用等号赋值,所以指向了同一个对象。因为列表是可变对象,每创建一个列表,都会重新分配内存,列表对象是没有“内存驻留”机制的。下面来看不可变数据类型的驻留机制。

整型驻留

Jupyter或者控制台交互环境中执行下面代码:

a1 = 300
b1 = 300
c1 = b1
print(a1 is b1)
print(c1 is b1)

a2 = 200
b2 = 200
c2 = b2
print(a2 is b2)
print(c2 is b2)

执行结果:

False
True
True
True

可以发现a1和b1指向了不同的地址,a2和b2指向了相同的地址,这是为什么呢?

因为启动时,Python 将一个 -5~256 之间整数列表预加载(缓存)到内存中,我们在这个范围内创建一个整数对象时,python会自动引用缓存的对象,不会创建新的整数对象。

浮点型不支持:

a = 1.0
b = 1.0
print(a is b)
print(a == b)

# 结果
# False
# True

如果上面的代码在非交互环境,也就是将代码作为python脚本运行的结果是什么呢?(运行环境为python3.7)

True
True
True
True
True
True

全为True,没有明确的限定临界值,都进行了驻留操作。这是因为使用不同的环境时,代码的优化方式不同。

字符串驻留

Jupyter或者控制台交互环境中:

  • 满足标识符命名规范的字符串都会被驻留,长度不限。

  • 空字符串会驻留

  • 使用乘法得到的字符串且满足标识符命名规范的字符串:长度小于等于20会驻留(peephole优化),Python 3.7改为4096(AST优化器)。

  • 长度为1的特殊字符(ASCII 字符中的)会驻留

  • 空元组或者只有一个元素且元素范围为-5~256的元组会驻留

满足标识符命名规范的字符:

a = 'Hello World'
b = 'Hello World'
print(a is b)

a = 'Hello_World'
b = 'Hello_World'
print(a is b)

结果:

False
True

乘法获取字符串(运行环境为python3.7)

a = 'aa'*50
b = 'aa'*50
print(a is b)

a = 'aa'*5000
b = 'aa'*5000
print(a is b)

结果:

True
False

在非交互环境中:

  • 默认字符串都会驻留

  • 使用乘法运算得到的字符串与在控制台相同

  • 元组类型(元组内数据为不可变数据类型)会驻留

  • 函数、类、变量、参数等的名称以及关键字都会驻留

注意:字符串是在编译时进行驻留,也就是说,如果字符串的值不能在编译时进行计算,将不会驻留。比如下面的例子:

letter = 'd'
a = 'Hello World'
b = 'Hello World'
c = 'Hello Worl' + 'd'
d = 'Hello Worl' + letter
e = " ".join(['Hello','World'])

print(id(a))
print(id(b))
print(id(c))
print(id(d))
print(id(e))

在交互环境执行结果如下:

1696903309168
1696903310128
1696903269296
1696902074160
1696903282800

都指向不同的内存。

python 3.7 非交互环境执行结果:

1426394439728
1426394439728
1426394439728
1426394571504
1426394571440

发现d和e指向不同的内存,因为d和e不是在编译时计算的,而是在运行时计算的。前面的a = 'aa'*50是在编译时计算的。

强行驻留

除了上面介绍的python默认的驻留外,可以使用sys模块中的intern()函数来指定驻留内容

import sys
letter_d = 'd'
a = sys.intern('Hello World')
b = sys.intern('Hello World')
c = sys.intern('Hello Worl' + 'd')
d = sys.intern('Hello Worl' + letter)
e = sys.intern(" ".join(['Hello','World']))

print(id(a))
print(id(b))
print(id(c))
print(id(d))
print(id(e))

结果:

1940593568304
1940593568304
1940593568304
1940593568304
1940593568304

使用intern()后,都指向了相同的地址。

总结

本文主要介绍了python的内存驻留,内存驻留是python优化的一种策略,注意不同运行环境下优化策略不一样,不同的python版本也不相同。注意字符串是在编译时进行驻留。

作者:测试开发小记
来源:https://blog.51cto.com/u_15441270/4714515

收起阅读 »

安卓客服云集成机器人欢迎语

1.会话分配 给APP渠道指定全天机器人2.机器人欢迎语打开,并指定一个菜单3.代码部分/** * 保存欢迎语到本地 */ public void saveMessage(){ Message message = Messa...
继续阅读 »
1.会话分配 给APP渠道指定全天机器人


2.机器人欢迎语打开,并指定一个菜单


3.代码部分

/**
* 保存欢迎语到本地
*/
public void saveMessage(){
Message message = Message.createReceiveMessage(Message.Type.TXT);
String str = Preferences.getInstance().getRobotWelcome();
EMTextMessageBody body = null;
if(!isRobotMenu(str)){
body = new EMTextMessageBody(str);
}else{
try{
body = new EMTextMessageBody("");
JSONObject msgtype = new JSONObject(str);
message.setAttribute("msgtype",msgtype);
}catch (Exception e){
Log.e("RobotMenu","onError:"+e.getMessage());
}
}
message.setFrom(toChatUsername);
message.addBody(body);
message.setMsgTime(System.currentTimeMillis());
message.setStatus(Message.Status.SUCCESS);
message.setMsgId(UUID.randomUUID().toString());

ChatClient.getInstance().chatManager().saveMessage(message);
messageList.refresh();
}

/**
* 判断机器人欢迎语是否是菜单类型
*
* @return
*/
private boolean isRobotMenu(String str) {
try {
JSONObject json = new JSONObject(str);
JSONObject obj = json.getJSONObject("choice");
} catch (Exception e) {
return false;
}
return true;
}

public void getNewRobotWelcome(String toChatUsername, MessageList messageList) {
this.toChatUsername=toChatUsername;
new Thread(new Runnable() {
@Override
public void run() {
OkHttpClient okHttpClient = new OkHttpClient();
//需要替换为自己的参数
String tenantid = "67386";//需要替换为自己的tenantid(管理员模式->账户->账户信息->租户ID一栏)
String orgname = "1473190314068186";//appkey # 前半部分
String appname = "kefuchannelapp67386";//appkey # 后半部分
String username = toChatUsername;//IM 服务号
String token = ChatClient.getInstance().accessToken();//用户token
// String url = "http://kefu.easemob.com/v1/webimplugin/tenants/robots/welcome?channelType=easemob&originType=app&tenantId=" + tenantid + "&orgName=" + orgname + "&appName=" + appname + "&userName=" + username + "&token=" + token;
String url = "https://kefu.easemob.com/v1/webimplugin/tenants/robots/welcome?channelType=easemob&originType=app&tenantId=95739&orgName=1404210708092119&appName=kefuchannelapp95739&userName=kefuchannelimid_548067&token=YWMtamWiyuByEeuml5FFEs_ewo740PDfnhHrjuLfDWx-sxgBU8F64G8R65kl_RFfGcMJAwMAAAF6iaJgxwBPGgDFrFY27hqYUwtUP5mDC0wRg1jcOkfkyEVs38cgDdmEQw";
Request request = new Request.Builder().url(url).get().build();
try {
Response response = okHttpClient.newCall(request).execute();
String result = response.body().string();
JSONObject obj = new JSONObject(result);
Log.e("newwelcome----", obj.getJSONObject("entity").getString("greetingText"));
int type = obj.getJSONObject("entity").getInt("greetingTextType");
final String rob_welcome = obj.getJSONObject("entity").getString("greetingText");
//type0代表是文字消息的机器人欢迎语
//type1代表是菜单消息的机器人欢迎语
if (type == 0) {
//把解析拿到的string保存在本地
Preferences.getInstance().setRobotWelcome(rob_welcome);

} else if (type == 1) {
final String str = rob_welcome.replaceAll("&amp;quot;", "\"");
JSONObject json = new JSONObject(str);
JSONObject ext = json.getJSONObject("ext");
final JSONObject msgtype = ext.getJSONObject("msgtype");
//把解析拿到的string保存在本地
Preferences.getInstance().setRobotWelcome(msgtype.toString());
}
} catch (JSONException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
}).start();

ChatClient.getInstance().chatManager().getCurrentSessionId(toChatUsername, new ValueCallBack() {
@Override
public void onSuccess(String value) {
Log.e("TAG value:", value);
//当返回value不为空时,则返回的当前会话的会话ID,也就是说会话正在咨询中,不需要发送欢迎语
if (value.isEmpty()) {//
saveMessage();
}
}

@Override
public void onError(int error, String errorMsg) {

}
});
}





收起阅读 »

统一路由,让小程序跳转更智能

我们在小程序开发及运营过程中,不可避免的需要进行页面之间的跳转。如果使用小程序自带的路由功能来实现这个功能,是非常简单的,如: // 根据不同的场景选择 navigateTo、redirectTo、switchTab 等 wx.navigateTo({ u...
继续阅读 »

我们在小程序开发及运营过程中,不可避免的需要进行页面之间的跳转。如果使用小程序自带的路由功能来实现这个功能,是非常简单的,如:


// 根据不同的场景选择 navigateTo、redirectTo、switchTab 等
wx.navigateTo({
url: "pages/somepage?id=1",
success: function (res) {},
});

但这里面存在几个问题:



  • 需要代码里面写死或者运营人员维护小程序页面的长长的具体路径,这显然是很不友好的

  • 需要知道页面是否为 tabbar 页面(switchTab)

  • 如果某个页面在 tabbar 和非 tabbar 页面之间发生了变化,或路径因为重构、主包瘦身等各种原因发生变化,原来的代码就会报错导致无法运行

  • navigateBack 不支持传参


为了解决以上问题,我们在项目中实现了一套基于命令别名(cmd)的统一路由跳转方式(以下称为统一路由),很好解决了遇到的实际问题,统一路由特点如下:



  • 页面别名声明使用注释方式,不侵入业务代码

  • 页面可以存在多个别名,方便新老版本页面的流量切换

  • 路由内自动判断是否 tabbar 页面,自行处理跳转及传参,业务代码无需关心

  • 支持纯 js api 的页面跳转及需要用户点击的任意类型跳转(如联系客服、打开小程序等等)

  • 对于页面栈中存在相同页面时,可以自动返回并根据参数是否相同决定是否需要刷新页面,可有效减少页面栈层级,规避小程序 10 层限制


实现思路


step1. 资源描述约定


小程序内的跳转类操作存在以下几种



  1. js api 直接可以操作的内部页面间跳转(wx.navigateTo、wx.navigateBack、wx.redirectTo、wx.reLaunch、wx.switchTab)

  2. js api 直接可以操作的打开微信原生功能的跳转(扫码、拨打电话等)

  3. 需要借助点击操作的跳转(如打开小程序及客服等需要 open-type 配合的场景 )


针对这三类操作,我们使用常见的 URL(统一资源定位系统)方式描述不同的待跳转资源



  1. 内部页面


https://host?cmd=${pagename}&param1=a  // 打开普通页面并传参,标准的H5容器也算在普通页面内


  1. 微信原生 API


https://host?cmd=nativeAPI&API=makePhoneCall&phoneNumber=123456  // 拨打电话
https://host?cmd=nativeAPI&API=scanCode&callback=scanCallback // 扫码并执行回调


  1. 需要借助按钮 open-type 的微信原生能力


https://host?cmd=nativeButtonAPI&openType=contact  // 在线客服


  1. 打开另一个小程序


https://host?cmd=miniProgram&appId=wx637bb****&path=pages/order/index&version=trial&uid=${uid} 


小程序跳转需要携带更多的参数,所以做了cmd的区分,这里实际会解析成 nativeButtonAPI 运行



step2. 在页面内定义需要的数据


在每个页面的顶部添加注释,注意 cmd 不能重复,支持多个 cmd。为了方便后续解析,我们的注释大体上遵循 JSDoc 注释规范


// pages/detail/index.tsx

/**
* @cmd detail, newdetail
* @description 详情
* @param skuid {number} skuid
*/

step3. 在编译阶段扫描并生成配置文件


根据入口文件的页面定义,匹配出需要的注释部分,使用 doctrine 解析需要的数据,解析后的数据如下:


// config/router.config.ts
export default {
index: {
description: "首页", // 页面描述
path: "/pages/index/index", // 真实路径
isTabbar: true, // 是否tabbar页面
ensureLogin: false, // 是否需要强制登录
},
detail: {
description: "详情",
path: "/pages/detail/index",
isTabbar: false,
ensureLogin: true,
},
};

这里顺便可以使用 param 等生成详细的页面名称及入参文档,提供给其他研发或运营同学使用。


step4. 资源描述解析为标准数据


根据上面的资源描述约定及扫描得到的配置文件,我们可以将其转换为方便在小程序内解析的数据定义,基本格式如下


{
origin: 'https://host?cmd=detail&skuid=1', // 原始数据
parsed: {
type: 'PAGE', // 类型,PAGE,NATIVE_API,NATIVE_BUTTON_API,UNKNOW
data: {
path: 'pages/detail/index', // 实际的页面路径,如果type是PAGE则会解析出此字段
action: undefined, // 动作,scanCode,makePhoneCall,openType,miniprogram ……。如果type是NATIVE_API,NATIVE_BUTTON_API,则会解析出此字段
params: {
skuid: '1' // 需要携带的参数
}
}
}
}

step5. 根据标准数据执行对应逻辑


由于我们的项目使用的是 Taro 框架,以下伪代码都是以 Taro 为例。


// utils/router.ts

// 用于解析原始链接为标准数据
const parseURL = (origin) => {
// balabala,一顿操作格式化成上文的数据
const data = {
...
};
return data;
};

// 执行除 NATIVE_BUTTON_API 之外的跳转
const routeURL = (origin) => {
const parsedData = parseURL(origin)
const {parsed: {type, data}} = parsedData

switch(type){
case 'PAGE':
...
break;
case 'NATIVE_API':
...
break;
case 'UNKNOW':
...
break;
}
};

export default {
parseURL,
routeURL,
};

对于需要点击的类型,我们需要借助 UI 组件实现


// components/router.tsx

import router from "/utils/router";
import { Button } from "@tarojs/components";
import Taro, { Component, eventCenter } from "@tarojs/taro";

export default class Router extends Component {
componentWillMount() {
const { path } = this.props;
const data = router.parseURL(path);
const { parsed, origin } = data;
const openType =
(parsed &&
parsed.data &&
parsed.data.params &&
parsed.data.params.openType) ||
false;
this.setState({
parsed,
openType,
});
}

// 点击事件
async handleClick(parsed, origin) {
// 点击执行动作
let {
type,
data: { action, params },
} = parsed;
if (!type) {
return;
}

// 内部页面
if (["PAGE", "CMD_UNKNOW"].includes(type)) {
console.log(`CMD_NATIVE_PAGE 参数:`, origin, options);
router.routeURL(origin);
return;
}

// 拨打电话、扫码等原生API
if (["NATIVE_API"].includes(type) && action) {
if (action === "makePhoneCall") {
let { phoneNumber = "" } = params;
if (!phoneNumber || phoneNumber.replace(/\s/g, "") == "") {
Taro.showToast({
icon: "none",
title: "未查询到号码,无法呼叫哦~",
});
return;
}
}

let res = await Taro[action]({ ...params });

// 扫码事件,需要在扫码完成后发送全局广播,业务内自行处理
if (action === "scanCode" && params.callback) {
let eventName = `${params.callback}_event`;
eventCenter.trigger(eventName, res);
}
}

// 打开小程序
if (
["NATIVE_BUTTON_API"].includes(type) &&
["miniprogram"].includes(action)
) {
await Taro.navigateToMiniProgram({
...params,
});
}
}

render() {
const { parsed, openType, origin } = this.state;

return (
<Button
onClick={this.handleClick.bind(this, parsed, origin)}
hoverClass="none"
openType={openType}
>
{this.props.children}
</Button>
);
}
}

在具体业务中使用


// pages/index/index.tsx
import router from "/utils/router";
import Router from "/components/router";

// js方式直接跳转
router.routeURL('https://host?cmd=detail&skuid=1')

// UI组件方式
...
render(){
return <Router path='https://host?cmd=detail&skuid=1'></Router>
}
...

当然这里面可以附加你自己需要的功能,比如:增加跳转方式控制、数据处理、埋点、加锁防连续点击,相对来说并不复杂。甚至你还可以顺手实现一下上面提到的 navigateBack 传参。


结语


上文的思考及实现过程比较简单,纯属抛砖引玉,欢迎大家交流互动。


作者:胖纳特
链接:https://juejin.cn/post/6930899487250448398

收起阅读 »

系统学习iOS动画 —— 渐变动画

iOS
系统学习iOS动画 —— 渐变动画这是我参与11月更文挑战的第22天,活动详情查看:2021最后一次更文挑战这个是希望达成的效果,主要就是下面字体的渐变动画以及右拉手势动画:先创建需要的控件:class ViewController: UIViewContro...
继续阅读 »

系统学习iOS动画 —— 渐变动画

这是我参与11月更文挑战的第22天,活动详情查看:2021最后一次更文挑战

这个是希望达成的效果,主要就是下面字体的渐变动画以及右拉手势动画:

请添加图片描述

先创建需要的控件:

class ViewController: UIViewController {
let timeLabel = UILabel()

override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
view.addSubview(timeLabel)
view.backgroundColor = .gray
timeLabel.text = "9:42"
timeLabel.font = UIFont.systemFont(ofSize: 72)
timeLabel.textColor = .white
timeLabel.frame = CGRect(x: 0, y: 100, width: timeLabel.intrinsicContentSize.width, height: timeLabel.intrinsicContentSize.height)
timeLabel.center.x = view.center.x

}


}

然后创建一个文件,然后写一个继承自UIView的类来编写动画的界面。

import UIKit
import QuartzCore

class AnimatedMaskLabel: UIView {

}

CAGradientLayer是CALayer的另一个子类,专门用于渐变的图层。这里创建一个CAGradientLayer来做渐变。这里

  • startPoint和endPoint定义了渐变的方向及其起点和终点
  • Colors是渐变的颜色数组
  • location: 每个渐变点的位置,范围 0 - 1 ,默认为0。

let gradientLayer: CAGradientLayer = {
let gradientLayer = CAGradientLayer()

// Configure the gradient here
gradientLayer.startPoint = CGPoint(x: 0.0, y: 0.5)
gradientLayer.endPoint = CGPoint(x: 1.0, y: 0.5)
let colors = [
UIColor.yellow.cgColor,
UIColor.green.cgColor,
UIColor.orange.cgColor,
UIColor.cyan.cgColor,
UIColor.red.cgColor,
UIColor.yellow.cgColor
]
gradientLayer.colors = colors

let locations: [NSNumber] = [
0.0, 0.0, 0.0, 0.0, 0.0, 0.25
]
gradientLayer.locations = locations

return gradientLayer
}()


在layoutSubviews里面为gradient设置frame,这里设置宽度为三个屏幕宽度大小来让动画看起来更加顺滑。

 override func layoutSubviews() {
gradientLayer.frame = CGRect(
x: -bounds.size.width,
y: bounds.origin.y,
width: 3 * bounds.size.width,
height: bounds.size.height)
}

接着需要声明一个text,当text被赋值的时候,将文本渲染为图像,然后使用该图像在渐变图层上创建蒙版。

 var text: String! {
didSet {
setNeedsDisplay()

let image = UIGraphicsImageRenderer(size: bounds.size)
.image { _ in
text.draw(in: bounds, withAttributes: textAttributes)
}

let maskLayer = CALayer()
maskLayer.backgroundColor = UIColor.clear.cgColor
maskLayer.frame = bounds.offsetBy(dx: bounds.size.width, dy: 0)
maskLayer.contents = image.cgImage

gradientLayer.mask = maskLayer
}
}

这里还需要为文本创建一个文本属性

  let textAttributes: [NSAttributedString.Key: Any] = {
let style = NSMutableParagraphStyle()
style.alignment = .center
return [
.font: UIFont(
name: "HelveticaNeue-Thin",
size: 28.0)!,
.paragraphStyle: style
]
}()

最后在didMoveToWindow中添加gradientLayer为自身子view并且为gradientLayer添加动画。

  override func didMoveToWindow() {
super.didMoveToWindow()
layer.addSublayer(gradientLayer)

let gradientAnimation = CABasicAnimation(keyPath: "locations")
gradientAnimation.fromValue = [0.0, 0.0, 0.0, 0.0, 0.0, 0.25]
gradientAnimation.toValue = [0.65, 0.8, 0.85, 0.9, 0.95, 1.0]
gradientAnimation.duration = 3.0
gradientAnimation.repeatCount = Float.infinity

gradientLayer.add(gradientAnimation, forKey: nil)
}

接下来在viewController中添加这个view。 声明一个animateLabel

    let animateLabel = AnimatedMaskLabel()

之后在viewDidLoad里面添加animateLabel在子view并且设置好各属性,这样animateLabel就有一个渐变动画了。

view.addSubview(animateLabel)
animateLabel.frame = CGRect(x: 0, y: UIScreen.main.bounds.size.height - 200, width: 200, height: 40)
animateLabel.center.x = view.center.x
animateLabel.backgroundColor = .clear
animateLabel.text = "Slide to reveal"

接下来为animateLabel添加滑动手势,这里设置滑动方向为向右滑动。

   let swipeGesture = UISwipeGestureRecognizer(target: self, action: #selector(handleSlide))
swipeGesture.direction = .right
animateLabel.addGestureRecognizer(swipeGesture)


然后在响应方法里面添加动画,这里先创建一个临时变量并且让其在屏幕外面,然后第一次动画的时候让timeLabel上移,animateLabel下移,然后让image跑到屏幕中间。完了之后在创建一个动画让timeLabel和animateLabel复原,把image移动到屏幕外,然后把image移除掉。

  @objc func handleSlide() {
// reveal the meme upon successful slide
let image = UIImageView(image: UIImage(named: "meme"))
image.center = view.center
image.center.x += view.bounds.size.width
view.addSubview(image)

UIView.animate(withDuration: 0.33, delay: 0.0,
animations: {
self.timeLabel.center.y -= 200.0
self.animateLabel.center.y += 200.0
image.center.x -= self.view.bounds.size.width
},
completion: nil
)

UIView.animate(withDuration: 0.33, delay: 1.0,
animations: {
self.timeLabel.center.y += 200.0
self.animateLabel.center.y -= 200.0
image.center.x += self.view.bounds.size.width
},
completion: {_ in
image.removeFromSuperview()
}
)
}

这样动画就完成了,完整代码:

import UIKit

class ViewController: UIViewController {
let timeLabel = UILabel()
let animateLabel = AnimatedMaskLabel()

override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
view.addSubview(timeLabel)
view.addSubview(animateLabel)

view.backgroundColor = .gray
timeLabel.text = "9:42"
timeLabel.font = UIFont.systemFont(ofSize: 72)
timeLabel.textColor = .white
timeLabel.frame = CGRect(x: 0, y: 100, width: timeLabel.intrinsicContentSize.width, height: timeLabel.intrinsicContentSize.height)
timeLabel.center.x = view.center.x


animateLabel.frame = CGRect(x: 0, y: UIScreen.main.bounds.size.height - 200, width: 200, height: 40)
animateLabel.center.x = view.center.x
animateLabel.backgroundColor = .clear
animateLabel.text = "Slide to reveal"
let swipeGesture = UISwipeGestureRecognizer(target: self, action: #selector(handleSlide))
swipeGesture.direction = .right
animateLabel.addGestureRecognizer(swipeGesture)

}

@objc func handleSlide() {
// reveal the meme upon successful slide
let image = UIImageView(image: UIImage(named: "meme"))
image.center = view.center
image.center.x += view.bounds.size.width
view.addSubview(image)

UIView.animate(withDuration: 0.33, delay: 0.0,
animations: {
self.timeLabel.center.y -= 200.0
self.animateLabel.center.y += 200.0
image.center.x -= self.view.bounds.size.width
},
completion: nil
)

UIView.animate(withDuration: 0.33, delay: 1.0,
animations: {
self.timeLabel.center.y += 200.0
self.animateLabel.center.y -= 200.0
image.center.x += self.view.bounds.size.width
},
completion: {_ in
image.removeFromSuperview()
}
)
}

}


import UIKit
import QuartzCore


class AnimatedMaskLabel: UIView {

let gradientLayer: CAGradientLayer = {
let gradientLayer = CAGradientLayer()

// Configure the gradient here
gradientLayer.startPoint = CGPoint(x: 0.0, y: 0.5)
gradientLayer.endPoint = CGPoint(x: 1.0, y: 0.5)
let colors = [
UIColor.yellow.cgColor,
UIColor.green.cgColor,
UIColor.orange.cgColor,
UIColor.cyan.cgColor,
UIColor.red.cgColor,
UIColor.yellow.cgColor
]
gradientLayer.colors = colors

let locations: [NSNumber] = [
0.0, 0.0, 0.0, 0.0, 0.0, 0.25
]
gradientLayer.locations = locations

return gradientLayer
}()

var text: String! {
didSet {
setNeedsDisplay()

let image = UIGraphicsImageRenderer(size: bounds.size)
.image { _ in
text.draw(in: bounds, withAttributes: textAttributes)
}

let maskLayer = CALayer()
maskLayer.backgroundColor = UIColor.clear.cgColor
maskLayer.frame = bounds.offsetBy(dx: bounds.size.width, dy: 0)
maskLayer.contents = image.cgImage

gradientLayer.mask = maskLayer
}
}

let textAttributes: [NSAttributedString.Key: Any] = {
let style = NSMutableParagraphStyle()
style.alignment = .center
return [
.font: UIFont(
name: "HelveticaNeue-Thin",
size: 28.0)!,
.paragraphStyle: style
]
}()

override func layoutSubviews() {
layer.borderColor = UIColor.green.cgColor
gradientLayer.frame = CGRect(
x: -bounds.size.width,
y: bounds.origin.y,
width: 3 * bounds.size.width,
height: bounds.size.height)
}

override func didMoveToWindow() {
super.didMoveToWindow()
layer.addSublayer(gradientLayer)

let gradientAnimation = CABasicAnimation(keyPath: "locations")
gradientAnimation.fromValue = [0.0, 0.0, 0.0, 0.0, 0.0, 0.25]
gradientAnimation.toValue = [0.65, 0.8, 0.85, 0.9, 0.95, 1.0]
gradientAnimation.duration = 3.0
gradientAnimation.repeatCount = Float.infinity

gradientLayer.add(gradientAnimation, forKey: nil)
}
}



收起阅读 »

iOS中加载xib

iOS
iOS中加载xib「这是我参与11月更文挑战的第27天,活动详情查看:2021最后一次更文挑战」关于 xib 或 storyboard共同点都用来描述软件界面都用 interface builder 工具来编辑本质都是转换成代码去创建控件不同点xib是轻量级的...
继续阅读 »

iOS中加载xib

「这是我参与11月更文挑战的第27天,活动详情查看:2021最后一次更文挑战

关于 xib 或 storyboard

  • 共同点
    • 都用来描述软件界面
    • 都用 interface builder 工具来编辑
    • 本质都是转换成代码去创建控件
  • 不同点
    • xib是轻量级的,用来描述局部UI界面
    • storyboard是重量级的,用来描述整个软件的多个界面,并且能够展示多个界面的跳转关系

加载xib

xib 文件在编译的后会变成 nib 文件

11975486-4f7dfbf345c0bff5.png

  • 第一种加载方式
    NSArray * xibArray = [[NSBundle mainBundle]loadNibNamed:NSStringFromClass(self) owner:nil options:nil] ;
    return xibArray[0];

  • 第二种加载方式
    UINib *nib = [UINib nibWithNibName:NSStringFromClass(self) bundle:nil];
    NSArray *xibArray = [nib instantiateWithOwner:nil options:nil];
    return xibArray[0];

    xibArray中log打印 log.png

控制器加载xib

  1. 首先需要对 xib 文件进行一些处理,打开 xib 文件

  2. 点击 "File‘s Owner",设置 Class 为 xxxViewControler 点击

  3. 右键 "Files‘s Owner",里面有个默认的IBOutlet变量view,看一下后面有没有做关联,如果没有就拉到下面的View和视图做个关联

    Files‘s Owner与View做关联

  • 第一种加载方式,传入指定的 xib(如CustomViewController)

    CustomViewController *custom = [[CustomViewController alloc]initWithNibName:@"CustomViewController" bundle:nil];

  • 第二种加载方式,不指定 xib

    CustomViewController *custom = [[CustomViewController alloc]initWithNibName:nil bundle:nil];

    • 第一步:寻找有没有和控制器类名同名的xib,如果有就去加载(XXViewController.xib)

      控制器类名同名的xib.png

    • 第二步:寻找有没有和控制器类名同名但是不带Controller的xib,如果有就去加载(XXView.xib)

      11975486-e40e19dd11cafbc5.png

    • 第三步:如果没有找到合适的 xib,就会创建一个 view(白色View,为系统自己创建的)


xib自定义控件与代码自定义的区别

这是自定义的一个 view,我们通过不同的初始化方式去判断它的执行方法

#import "CustomViw.h"
@implementation CustomViw
- (instancetype)init{
self = [super init];
if (self) {
NSLog(@"%s",__func__);
}
return self;
}

- (instancetype)initWithFrame:(CGRect)frame{
if (self = [super initWithFrame:frame]) {
NSLog(@"%s",__func__);
}
return self;
}

- (instancetype)initWithCoder:(NSCoder *)aDecoder{

if (self = [super initWithCoder:aDecoder]) {
}
NSLog(@"%s",__func__);
return self;
}

- (void)awakeFromNib{
[super awakeFromNib];
NSLog(@"%s",__func__);
}
@end

  • 通过 init 方法初始化自定义控件

    @implementation ViewController
    - (void)viewDidLoad {
    [super viewDidLoad];
    CustomViw *customView = [[CustomViw alloc] init];
    }
    @end

    log:

    通过init方法初始化自定义控件log打印.png

  • 通过加载 xib 方法初始化自定义控件

    @implementation ViewController
    - (void)viewDidLoad {
    [super viewDidLoad];
    CustomViw *customView = [[[NSBundle mainBundle]loadNibNamed:NSStringFromClass([CustomViw class]) owner:nil options:nil] lastObject];
    }
    @end

    log(打印三次是因为CustomViw的xib文件里有三个View) 通过加载xib方法初始化自定义控件log打印.png

小结:

  • 通过代码初始化自定义控件是不会自动加载xib的,它会执行 initWithFrame 和 init
  • 通过加载 xib 初始化自定义控件,仅仅执行 initWithCoder 和 awakeFromNib,如果要通过代码修改 xib 的内容,一般建议放在 awakeFromNib 方法内

控件封装

一般封装一个控件,为了让开发者方便使用,通常会在自定义的控件中编写俩个方法初始化方法,这样不管是通过 init 还是加载xib都可以实现相同的效果

#import "CustomViw.h"
@implementation CustomViw

- (instancetype)initWithFrame:(CGRect)frame{
if (self = [super initWithFrame:frame]) {
[self setup];
}
return self;
}

- (void)awakeFromNib{
[super awakeFromNib];
[self setup];
}

- (void)setup{
[self setBackgroundColor:[UIColor redColor]];
}
@end

收起阅读 »

iOS中的Storyboard

iOS
iOS中的Storyboard「这是我参与11月更文挑战的第28天,活动详情查看:2021最后一次更文挑战」关于StoryboardStoryboard 是最先在 iOS5 中引入的一项新特性,它的出现使得开发人员大幅缩减构建App用户界面所需的时间关于Sto...
继续阅读 »


iOS中的Storyboard

「这是我参与11月更文挑战的第28天,活动详情查看:2021最后一次更文挑战

关于Storyboard

Storyboard 是最先在 iOS5 中引入的一项新特性,它的出现使得开发人员大幅缩减构建App用户界面所需的时间

关于Storyboard的加载方式

  • 一般在新建工程后,我们便可以看到Xcode会默认加载 Storyboard,但是在实际开发中,我们更常用的是自己新建 Storyboard,所以,这里主要讲手动创建控制器时,加载 Storyboard 的方式

  • 通常在新建的项目中,我们首先要将Xcode加载 Storyboard 去掉

    这里写图片描述

  • 关于 Storyboard 创建控制器

    第一种:

    这里写图片描述

    self.window = [[UIWindow alloc]initWithFrame:[UIScreen mainScreen].bounds];
    UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
    UIViewController *vc = [sb instantiateInitialViewController];
    self.window.rootViewController = vc;
    [self.window makeKeyAndVisible];

    第二种:

    这里写图片描述

    self.window = [[UIWindow alloc]initWithFrame:[UIScreen mainScreen].bounds];
    UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
    UIViewController *vc = [sb instantiateViewControllerWithIdentifier:@"WAKAKA"];
    self.window.rootViewController = vc;
    [self.window makeKeyAndVisible];


关于UIStoryboardSegue

在 Storyboard 中,用来描述界面跳转的线,都属于 UIStoryboardSegue 的对象(简称:Segue

这里写图片描述

Segue的属性

  • 唯一标识(identifier
  • 来源控制器(sourceViewController
  • 目标控制器(destinationViewController

Segue的类型

  • 自动型(点击某控件,不需要进行某些判断可直接跳转的)

    这里写图片描述

  • 手动型(点击某控件,需要进行某些判断才跳转的) 这里写图片描述

  • 手动设置 Segue 需要设置

    这里写图片描述

    使用 perform 方法执行对应的 Segue

    //根据Identifier去storyboard中找到对应的线,之后建立一个storyboard的对象
    [self performSegueWithIdentifier:@"showinfo" sender:nil];

    如果需要做传值或跳转到不同的UI,需要在这个方法里代码实现

    - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender{
    //比较唯一标识
    if ([segue.identifier isEqualToString:@"showInfo"]) {
    //来源控制器
    UINavigationController *nvc = segue.sourceViewController;
    //目的控制器
    ListViewController *vc = segue.destinationViewController;
    vc.info = @
    "show";
    }
    }

    链接:https://juejin.cn/post/7035408728509644814
收起阅读 »

iOS小技能: 图片的平铺和拉伸、图片的加载方式、内容模式

iOS
iOS小技能: 图片的平铺和拉伸、图片的加载方式、内容模式这是我参与11月更文挑战的第28天,活动详情查看:2021最后一次更文挑战。引言例子:按照比例显示图片全部内容,并自动适应高度I 图片的平铺和拉伸 #import "UIImage+ResizableI...
继续阅读 »

iOS小技能: 图片的平铺和拉伸、图片的加载方式、内容模式

这是我参与11月更文挑战的第28天,活动详情查看:2021最后一次更文挑战

引言

例子:按照比例显示图片全部内容,并自动适应高度

I 图片的平铺和拉伸


#import "UIImage+ResizableImage.h"

@implementation UIImage (ResizableImage)


+ (UIImage*)resizableImageWithName:(NSString *)name {
NSLog(@"%s--%@",__func__,name);
UIImage *image = [UIImage imageNamed:name];
//裁剪图片方式一:
//Creates and returns a new image object with the specified cap values.
/*right cap is calculated as width - leftCapWidth - 1
bottom cap is calculated as height - topCapWidth - 1
*/

return [image stretchableImageWithLeftCapWidth:image.size.width*0.5 topCapHeight:image.size.height*0.5];
//方式二:
// CGFloat top = image.size.width*0.5f-1;
// CGFloat left = image.size.height*0.5f-1;
// UIEdgeInsets insets = UIEdgeInsetsMake(top, left, top, left);
// UIImage *capImage = [image resizableImageWithCapInsets:insets resizingMode:UIImageResizingModeTile];
//
}




/**
CGFloat top = 0; // 顶端盖高度
CGFloat bottom = 0 ; // 底端盖高度
CGFloat left = 0; // 左端盖宽度
CGFloat right = 0; // 右端盖宽度

// UIImageResizingModeStretch:拉伸模式,通过拉伸UIEdgeInsets指定的矩形区域来填充图片
// UIImageResizingModeTile:平铺模式,通过重复显示UIEdgeInsets指定的矩形区域来填充图片


@param img <#img description#>
@param top <#top description#>
@param left <#left description#>
@param bottom <#bottom description#>
@param right <#right description#>
@return <#return value description#>
*/

- (UIImage *) resizeImage:(UIImage *) img WithTop:(CGFloat) top WithLeft:(CGFloat) left WithBottom:(CGFloat) bottom WithRight:(CGFloat) right
{
UIImage * resizeImg = [img resizableImageWithCapInsets:UIEdgeInsetsMake(self.size.height * top, self.size.width * left, self.size.height * bottom, self.size.width * right) resizingMode:UIImageResizingModeStretch];

return resizeImg;
}



//返回一个可拉伸的图片
- (UIImage *)resizeWithImageName:(NSString *)name
{
UIImage *normal = [UIImage imageNamed:name];

// CGFloat w = normal.size.width * 0.5f ;
// CGFloat h = normal.size.height *0.5f ;

CGFloat w = normal.size.width*0.8;
CGFloat h = normal.size.height*0.8;
//传入上下左右不需要拉升的编剧,只拉伸中间部分
return [normal resizableImageWithCapInsets:UIEdgeInsetsMake(h, w, h, w)];

// [normal resizableImageWithCapInsets:UIEdgeInsetsMake(<#CGFloat top#>, <#CGFloat left#>, <#CGFloat bottom#>, <#CGFloat right#>)]

// 1 = width - leftCapWidth - right
// 1 = height - topCapHeight - bottom

//传入上下左右不需要拉升的编剧,只拉伸中间部分,并且传入模式(平铺/拉伸)
// [normal :<#(UIEdgeInsets)#> resizingMode:<#(UIImageResizingMode)#>]

//只用传入左边和顶部不需要拉伸的位置,系统会算出右边和底部不需要拉升的位置。并且中间有1X1的点用于拉伸或者平铺
// 1 = width - leftCapWidth - right
// 1 = height - topCapHeight - bottom
// return [normal stretchableImageWithLeftCapWidth:w topCapHeight:h];
}




@end


II 图片的加载方式

优先选择3x图像,而不是2x图像时使用initWithContentsOfFile

 NSString *path = [[NSBundle mainBundle] pathForResource:@"smallcat" ofType:@"png"];
UIImage *image = [[UIImage alloc]initWithContentsOfFile:path];
// 在ipone5 s、iphone6和iphone6 plus都是优先加载@3x的图片,如果没有@3x的图片,就优先加载@2x的图片



  • 优先加载@2x的图片
  • [UIImage imageNamed:@"smallcat"]

iphone5s和iphone6优先加载@2x的图片,iphone6 plus是加载@3x的图片。

加载图片注意点:如果图片比较小,并且使用非常频繁,可以使用imageName:(eg icon),如果图片比较大,并且使用比较少,可以使用imageWithContentsOfFile:(eg 引导页 相册)。 imageName:

  • 1、当对象销毁的时候,图片占用的内存不会随着一起销毁,内存由系统来管理,程序员不可控制
  • 2、加载的图片,占用的内存非常大
  • 3、相同的图片不会被重复加载到内存

imageWithContentsOfFile:

  • 1、当对象销毁的时候,图片占用的内存会随着一起销毁
  • 2、加载的图片占用的内存较小

3、相同的图片如果被多次加载就会占据多个内存空间

III 内容模式

首先了解下图片的内容模式

3.1 内容模式

  • UIViewContentModeScaleToFill

拉伸图片至填充整个UIImageView,图片的显示尺寸会和imageVew的尺寸一样 。

This will scale the image inside the image view to fill the entire boundaries of the image view.

  • UIViewContentModeScaleAspectFit

图片的显示尺寸不能超过imageView尺寸大小

This will make sure the image inside the image view will have the right aspect ratio and fits inside the image view’s boundaries.

  • UIViewContentModeScaleAspectFill

按照图片的原来宽高比进行缩放(展示图片最中间的内容),配合使用 tmpView.layer.masksToBounds = YES;

This will makes sure the image inside the image view will have the right aspect ratio and fills the entire boundaries of the image view. For this value to work properly, make sure that you have set the clipsToBounds property of the image view to YES.

  • UIViewContentModeScaleToFill : 直接拉伸图片至填充整个imageView

划重点:

  1. UIViewContentModeScaleAspectFit : 按照图片的原来宽高比进行缩放(一定要看到整张图片)

使用场景:信用卡图片的展示

在这里插入图片描述

  1. UIViewContentModeScaleAspectFill : 按照图片的原来宽高比进行缩放(只能图片最中间的内容)

引导页通常采用UIViewContentModeScaleAspectFill


// 内容模式
self.contentMode = UIViewContentModeScaleAspectFill;
// 超出边框的内容都剪掉
self.clipsToBounds = YES;




3.2 例子:商品详情页的实现

  • [商品详情页(按照图片原宽高比例显示图片全部内容,并自动适应高度)

](kunnan.blog.csdn.net/article/det…)

  • 背景图片的拉伸(中间空白的小矩形设置为可拉伸,保证有形状的地方不进行缩放)
- (void)awakeFromNib
{
[super awakeFromNib];
// 拉伸
// self.backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"bg_dealcell"]];
// 平铺
// self.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"bg_dealcell"]];


[self setAutoresizingMask:UIViewAutoresizingNone];



}




- (void)drawRect:(CGRect)rect
{
// 平铺
// [[UIImage imageNamed:@"bg_dealcell"] drawAsPatternInRect:rect];
// 拉伸
[[UIImage imageNamed:@"bg_dealcell"] drawInRect:rect];
}



背景图片的拉伸(中间空白的小矩形设置为可拉伸,保证有形状的地方不进行缩放)
UIImage *resizableImage = [image resizableImageWithCapInsets:UIEdgeInsetsMake(heightForLeftORRight, widthForTopORBottom, heightForLeftORRight, widthForTopORBottom)];

see also

只为你呈现有价值的信息,专注于移动端技术研究领域;更多服务和咨询请关注#公众号:iOS逆向

链接:https://juejin.cn/post/7035421386168336398

收起阅读 »

图解-元宇宙(MetaVerse)

目录 1、前言 2、元宇宙是什么 3、生态技术图谱 1、前言 近日,全球互联网巨头Facebook宣布改名为Meta(Meta为元宇宙MetaVerse的前缀),一时间,基于技术创新且未来空间广阔的“元宇宙”再次成为科技界最关心的话题。 2、元宇宙是什么 元...
继续阅读 »

目录


1、前言


2、元宇宙是什么


3、生态技术图谱




1、前言


近日,全球互联网巨头Facebook宣布改名为Meta(Meta为元宇宙MetaVerse的前缀),一时间,基于技术创新且未来空间广阔的“元宇宙”再次成为科技界最关心的话题。


2、元宇宙是什么


元宇宙(Metaverse)一词,诞生于1992年的科幻小说《雪崩》,小说描绘了一个庞大的虚拟现实世界,在这里,人们用数字化身来控制,并相互竞争以提高自己的地位,到现在看来,描述的还是超前的未来世界。


Metaverse是由Meta和Verse组成,Meta表示超越,verse是宇宙universe的意思,合起来通常表示,互联网的下一个阶段,由AR,VR,3D等技术支持的虚拟现实的网络世界。


3、生态技术图谱


元宇宙生态包含了从技术基础到各种支持系统的项目,生态图谱极其庞大。



图片来源:悦财经





作者:Meng
链接:https://juejin.cn/post/7032217003486085133
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

必学必知的自定义View基础

前言自定义View原理是Android开发者必须了解的基础;在了解自定义View之前,你需要有一定的知识储备;本文将全面解析关于自定义View中的所有知识基础。目录1. 视图定义即日常说的View,具体表现为显示在屏幕上的各种视图控件,如TextView、Li...
继续阅读 »

前言

  • 自定义View原理是Android开发者必须了解的基础;
  • 在了解自定义View之前,你需要有一定的知识储备;
  • 本文将全面解析关于自定义View中的所有知识基础。

目录

示意图


1. 视图定义

即日常说的View,具体表现为显示在屏幕上的各种视图控件,如TextView、LinearLayout等。


2. 视图分类

视图View主要分为两类:

  • 单一视图:即一个View、不包含子View,如TextView
  • 视图组,即多个View组成的ViewGroup、包含子View,如LinearLayout

Android中的UI组件都由View、ViewGroup共同组成。


3. 视图类简介

  • 视图的核心类是:View类
  • View类是Android中各种组件的基类,如View是ViewGroup基类
  • View的构造函数:共有4个,具体如下:

自定义View必须重写至少一个构造函数:

// 构造函数1
// 调用场景:View是在Java代码里面new的
public CarsonView(Context context) {
super(context);
}

// 构造函数2
// 调用场景:View是在.xml里声明的
// 自定义属性是从AttributeSet参数传进来的
public CarsonView(Context context, AttributeSet attrs) {
super(context, attrs);
}

// 构造函数3
// 应用场景:View有style属性时
// 一般是在第二个构造函数里主动调用;不会自动调用
public CarsonView(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}

// 构造函数4
// 应用场景:View有style属性时、API21之后才使用
// 一般是在第二个构造函数里主动调用;不会自动调用
public CarsonView(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
super(context, attrs, defStyleAttr, defStyleRes);
}

更加具体的使用请看:深入理解View的构造函数和 理解View的构造函数


4. 视图结构

  • 对于包含子View的视图组(ViewGroup),结构是树形结构
  • ViewGroup下可能有多个ViewGroup或View,如下图:

这里需要特别注意的是:在View的绘制过程中,永远都是从View树结构的根节点开始(即从树的顶端开始),一层一层、一个个分支地自上而下遍历进行(即树形递归),最终计算整个View树中各个View,从而最终确定整个View树的相关属性。


5. Android坐标系

Android的坐标系定义为:

  • 屏幕的左上角为坐标原点
  • 向右为x轴增大方向
  • 向下为y轴增大方向

具体如下图:

注:区别于一般的数学坐标系

两者坐标系的区别


6. View位置(坐标)描述

视图的位置由四个顶点决定,如图1-3所示的A、B、C、D。

视图的位置是相对于父控件而言的,四个顶点的位置描述分别由四个与父控件相关的值决定:

  • 顶部(Top):视图上边界到父控件上边界的距离;
  • 左边(Left):视图左边界到父控件左边界的距离;
  • 右边(Right):视图右边界到父控件左边界的距离;
  • 底部(Bottom):视图下边界到父控件上边界的距离。

具体如图1-4所示。

可根据视图位置的左上顶点、右下顶点进行记忆:

  • 顶部(Top):视图左上顶点到父控件上边界的距离;
  • 左边(Left):视图左上顶点到父控件左边界的距离;
  • 右边(Right):视图右下顶点到父控件左边界的距离;
  • 底部(Bottom):视图右下顶点到父控件上边界的距离。

7. 位置获取方式

视图的位置获取是通过View.getXXX()方法进行获取。

获取顶部距离(Top):getTop()
获取左边距离(Left):getLeft()
获取右边距离(Right):getRight()
获取底部距离(Bottom):getBottom()
  • 与MotionEvent中 get() getRaw()的区别
//get() :触摸点相对于其所在组件坐标系的坐标
event.getX();
event.getY();

//getRaw() :触摸点相对于屏幕默认坐标系的坐标
event.getRawX();
event.getRawY();

具体如下图:

get() 和 getRaw() 的区别


8. 角度(angle)& 弧度(radian)

  • 自定义View实际上是将一些简单的形状通过计算,从而组合到一起形成的效果。

这会涉及到画布的相关操作(旋转)、正余弦函数计算等,即会涉及到角度(angle)与弧度(radian)的相关知识。

  • 角度和弧度都是描述角的一种度量单位,区别如下图::

角度和弧度区别

在默认的屏幕坐标系中角度增大方向为顺时针。

屏幕坐标系角度增大方向

注:在常见的数学坐标系中角度增大方向为逆时针


9. 颜色相关

Android中的颜色相关内容包括颜色模式,创建颜色的方式,以及颜色的混合模式等。

9.1 颜色模式

Android支持的颜色模式主要包括:

  • ARGB8888:四通道高精度(32位)
  • ARGB4444:四通道低精度(16位)
  • RGB565:Android屏幕默认模式(16位)
  • Alpha8:仅有透明通道(8位)

这里需要特别注意的是:

  • 字母:表示通道类型;
  • 数值:表示该类型用多少位二进制来描述;
  • 示例说明:ARGB8888,表示有四个通道(ARGB);每个对应的通道均用8位来描述。

以ARGB8888为例介绍颜色定义:

ARGB88888

9.2 颜色定义

主要分为xml定义 / java定义。

/**
* 定义方式1:xml
* 在/res/values/color.xml文件中定义
*/
<?xml version="1.0" encoding="utf-8"?>
<resources>
//定义了红色(没有alpha(透明)通道)
<color name="red">#ff0000</color>
//定义了蓝色(没有alpha(透明)通道)
<color name="green">#00ff00</color>
</resources>

// 在xml文件中以”#“开头定义颜色,后面跟十六进制的值,有如下几种定义方式:
#f00 //低精度 - 不带透明通道红色
#af00 //低精度 - 带透明通道红色
#ff0000 //高精度 - 不带透明通道红色
#aaff0000 //高精度 - 带透明通道红色

/**
* 定义方式2:Java
*/
// 使用Color类定义颜色
int color = Color.GRAY; //灰色

// Color类使用ARGB值表示
int color = Color.argb(127, 255, 0, 0); //半透明红色
int color = 0xaaff0000; //带有透明度的红色

9.3 颜色引用

主要分为xml定义 / java定义。

/**
* 引用方式1:xml
*/
// 1. 在style文件中引用
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="colorPrimary">@color/red</item>
</style>
// 2. 在layout文件中引用
android:background="@color/red"
// 3. 在layout文件中创建并使用颜色
android:background="#ff0000"

/**
* 引用方式2:Java
*/
//方法1
int color = getResources().getColor(R.color.mycolor);

//方法2(API 23及以上)
int color = getColor(R.color.myColor);

9.4 取色工具

  • 颜色都是用RGB值定义的,而我们一般是无法直观的知道自己需要颜色的值,需要借用取色工具直接从图片或者其他地方获取颜色的RGB值。
  • 有时候一些简单的颜色选取就不用去麻烦UI了,开发者自己去选取效率更高
  • 这里,取色工具我强推Markman:一款设计师用于标注的工具,主要用于尺寸标注、字体大小标注、颜色标注,而且使用简单。本人强烈推荐!




收起阅读 »

如何美化checkbox

前言 对于前端开发人员,checkbox应该是经常见到的东西。利用checkbox的checked属性,我们可以做出很多精彩的效果,之前还用checkbox来做动画暂停。前几天还看到外国大佬使用 checkbok做游戏:http://www.bryanbrau...
继续阅读 »

前言


对于前端开发人员,checkbox应该是经常见到的东西。利用checkbox的checked属性,我们可以做出很多精彩的效果,之前还用checkbox来做动画暂停。前几天还看到外国大佬使用 checkbok做游戏:http://www.bryanbraun.com/2021/09/21/… ,真的是佩服的五体投地,不过对于我这种菜鸡选手,还是只能实现一些简单的东西。对于下面的这个switch按钮,大家应该非常熟悉了,同样的在这个效果上还衍生出了各种华丽花哨的效果,例如暗黑模式的切换。一生万,掌握了一,万!还不是手到擒来。


image-20211128233027149


推荐大家看看codepen上的这个仓库:文章封面的效果,也是从这里录制的!
tql

codepen.io/oliviale/pe…


image-20211128235343983


标签


这里使用for将label和input捆绑


<input type="checkbox" id="toggle" />
<label for="toggle"></label>

同时设置input不可见


input {
display: none;
}

美化label


遇到checkbox的美化问题,基本上都是考虑用美化labl替代美化input。


设置背景颜色,宽高,以及圆角


.switch {
  display: inline-block;
  display:relative;
  width: 40px;
  height: 20px;
  background-color: rgba(0, 0, 0, 0.25);
  border-radius: 20px;
}


最终的效果如下:


image-20211128233616100


切换的圆


在label上会有一个圆,一开始是在左边的,效果如下,其实这个只需要利用伪元素+positon定位,就可以实现了。


image-20211128233732168


这是postion:absolute,同时将位置定位在top1px,left1px。同时设置圆角。


      .switch:after {
      content: "";
      position: absolute;
      width: 18px;
      height: 18px;
      border-radius: 18px;
      background-color: white;
      top: 1px;
      left: 1px;
      transition: all 0.3s;
    }

checked+小球右移动


这里点击之后圆会跑到右边,这里有两种实现方案


1.仍然通过定位


当checkbox处于checked状态,会设置top,left,bottom,right。这里将top,left设置为auto是必须的,这种的好处就是,不需要考虑label的宽度。


  input[type="checkbox"]:checked + .switch:after {
      top: auto;
      left: auto;
      bottom: 1px ;
      right: 1px ;
    }

当然知道label的宽度可以直接,设置top和left


top: 1px;
left: 21px;

2.translateX


*transform: translateX(20px)*

美化切换后的label


加上背景色


input[type="checkbox"]:checked + .switch {
background-color: #7983ff;
}

效果:


switch


后记


看上去本文是一篇介绍一个checkbox美化的效果,其实是一篇告诉你如何美化checkbox的文章,最终的思想就是依赖for的捆绑效果,美化label来达到最终的效果。


作者:半夏的故事
链接:https://juejin.cn/post/7035650204829220877

收起阅读 »

CoordinatorLayout与AppBarLayout。置顶悬停,二级悬停,类似京东、淘宝等二级悬停。

类似京东、淘宝等二级悬停。 参考+实践 一、惯例先上效果图 二、GitHub 代码地址,欢迎指正https://github.com/MNXP/SlideTop 三、XML布局主要用到的控件 1、PullRefreshLayout (借用这位大神的ht...
继续阅读 »

类似京东、淘宝等二级悬停。
参考+实践




一、惯例先上效果图


效果图


二、GitHub

三、XML布局主要用到的控件


  1、PullRefreshLayout (借用这位大神的https://github.com/genius158/PullRefreshLayout)
2、CoordinatorLayout
3、AppBarLayout

四、实现

1、布局的实现



  需要注意的几点:
1)AppBarLayout 设置 behavior 需要自己定义,为以后拦截事件用
app:layout_behavior=".weight.MyBehavior"
2)AppBarLayout 第一个子view,就是需要滑动消失的布局,设置
app:layout_scrollFlags="scroll|exitUntilCollapsed"
scroll 滚动,exitUntilCollapsed 可以在置顶后有阴影效果
3)最外层RecyclerView(也可以是各种带滑动的view,也可以是ViewPager实现分页) 设置
app:layout_behavior="@string/appbar_scrolling_view_behavior"


xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">

android:layout_width="match_parent"
android:layout_height="60dp"
android:background="#ffffff"
android:orientation="vertical">

android:layout_width="match_parent"
android:layout_height="match_parent"
android:gravity="center"
android:text="置顶滑动"
android:textColor="@color/black"
android:textSize="20sp" />
android:layout_width="match_parent"
android:layout_height="1dp"
android:layout_alignParentBottom="true"
android:background="#dddddd"/>


android:id="@+id/swipe_refresh_layout"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:prl_pullDownMaxDistance="300dp"
app:prl_twinkEnable="true">

android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_below="@+id/home_top_view"
android:orientation="vertical">

android:id="@+id/app_bar_layout"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="#ffffff"
app:layout_behavior=".weight.MyBehavior">

android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
app:layout_scrollFlags="scroll|exitUntilCollapsed">
android:layout_width="match_parent"
android:layout_height="150dp"
android:src="@mipmap/home_c"/>
android:id="@+id/top_img_rv"
android:layout_width="match_parent"
android:layout_height="wrap_content"/>


android:id="@+id/home_tab_container_layout"
android:layout_width="match_parent"
android:layout_height="55dp"
android:gravity="center"
android:orientation="horizontal">
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:gravity="center_vertical"
android:layout_marginLeft="20dp"
android:textSize="15sp"
android:textColor="#222222"
android:text="悬停标题"/>

android:id="@+id/filter_layout"
android:layout_width="40dp"
android:layout_height="40dp"
android:layout_alignParentEnd="true"
android:layout_centerVertical="true"
android:layout_marginEnd="20dp"
android:scaleType="fitXY"
android:src="@mipmap/home_icon" />




android:id="@+id/bottom_img_rv"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior="@string/appbar_scrolling_view_behavior" />








2、首先解决PullRefreshLayout 与 CoordinatorLayout(依靠AppBarLayout来处理)滑动冲突


通过AppBarLayout监听addOnOffsetChangedListener获取CoordinatorLayout是否滑动到顶部,
设置PullRefreshLayout是否可以上拉刷新

   // 记录AppBar滚动距离
appBarLayout.addOnOffsetChangedListener(View::setTag);
homeRefreshLayout.setOnTargetScrollCheckListener(new PullRefreshLayout.OnTargetScrollCheckListener() {
@Override
public boolean onScrollUpAbleCheck() {
// 根据AppBar滚动的距离来设置RefreshLayout是否可以下拉刷新
int appbarOffset = ((appBarLayout.getTag() instanceof Integer)) ? (int) appBarLayout.getTag() : 0;
return appbarOffset != 0;
}

@Override
public boolean onScrollDownAbleCheck() {
return true;
}
});

3、启用AppBarLayout滑动(不设置也可以,但有的时候会滑动有问题)


注意📢:要在数据加载之后设置,不然不起作用

CoordinatorLayout.LayoutParams params = (CoordinatorLayout.LayoutParams) appBarLayout.getLayoutParams();
MyBehavior behavior = (MyBehavior) params.getBehavior();
try {
if (behavior!=null){
behavior.setDragCallback(new AppBarLayout.Behavior.DragCallback() {
@Override
public boolean canDrag(@NonNull AppBarLayout appBarLayout) {
isFirstData = true;
//为了启用折叠工具栏的滚动
return true;
}
});
}

} catch (Exception e) {

}

4、自以为很完美了┭┮﹏┭┮,但是遇到一个小问题


  问题?
滑动置顶之后,滑动下面的recyclerview,使得recyclerview不是显示第一个item,松开手,
然后向下滑动“悬停标题”,发现可以向下滑动,🤩,是bug的味道。如下图

BUG的味道


下面就开始解决


 解决思路就是根据下面的RecyclerView滑动,设置AppBarLayout是否可以滑动,
(1) 设置监听RecyclerView第一个完整item
(2) 根据Position来设置behavior.setCanMove(position<1);
(3) MyBehavior实现是否可以滑动
上代码

// (1)设置监听RecyclerView第一个完整item
bottomRv.addOnScrollListener(new RecyclerView.OnScrollListener() {
@Override
public void onScrollStateChanged(@NonNull RecyclerView recyclerView, int newState) {
super.onScrollStateChanged(recyclerView, newState);
if (newState == SCROLL_STATE_IDLE) {
if (bottomRv != null && bottomRv.getLayoutManager() instanceof LinearLayoutManager) {
LinearLayoutManager layoutManager = (LinearLayoutManager) bottomRv.getLayoutManager();
if (layoutManager != null) {
// 根据滑动item设置置顶是否可以滑动
int firstCompletelyVisible = layoutManager.findFirstCompletelyVisibleItemPosition();
initAppbar(firstCompletelyVisible);
}
}
}
}
});
//根据Position来设置behavior.setCanMove(position<1);
private boolean isFirstData;
private int oldPosition = -2;
public void initAppbar(int position) {
if (oldPosition == position){
return;
}
oldPosition = position;
CoordinatorLayout.LayoutParams params = (CoordinatorLayout.LayoutParams) appBarLayout.getLayoutParams();
MyBehavior behavior = (MyBehavior) params.getBehavior();
try {
if (behavior!=null){
if (position == -1){
behavior.setDragCallback(new AppBarLayout.Behavior.DragCallback() {
@Override
public boolean canDrag(@NonNull AppBarLayout appBarLayout) {
isFirstData = true;
//为了启用折叠工具栏的滚动
return true;
}
});
}else {
// 置顶后,如果recyclerview不是第一个item,禁止工具栏滑动
behavior.setCanMove(position<1);
}
}

} catch (Exception e) {
}
}
// (3) MyBehavior实现是否可以滑动
@Override
public boolean onInterceptTouchEvent(@NonNull CoordinatorLayout parent, @NonNull AppBarLayout child, @NonNull MotionEvent ev) {
if (!canMove && ev.getAction() == MotionEvent.ACTION_DOWN){
return false;
}
return super.onInterceptTouchEvent(parent, child, ev);
}

public void setCanMove(boolean canMove){
this.canMove = canMove;
}

5、完整代码


Activity代码

  public class MainActivity extends AppCompatActivity {
private RecyclerView topRv;
private RecyclerView bottomRv;
private AppBarLayout appBarLayout;
private PullRefreshLayout homeRefreshLayout;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
appBarLayout = findViewById(R.id.app_bar_layout);
homeRefreshLayout = findViewById(R.id.swipe_refresh_layout);
topRv = findViewById(R.id.top_img_rv);
bottomRv = findViewById(R.id.bottom_img_rv);
topRv.setLayoutManager(new LinearLayoutManager(this));
bottomRv.setLayoutManager(new LinearLayoutManager(this));
initView();
initData();
}
private void initView() {
StoreHouseHeader header = new StoreHouseHeader(this);
header.setPadding(0, 20, 0, 20);
header.initWithString("XIANGPAN");
header.setTextColor(0xFF222222);

homeRefreshLayout.setHeaderView(header);

homeRefreshLayout.setOnRefreshListener(new PullRefreshLayout.OnRefreshListenerAdapter() {
@Override
public void onRefresh() {
initData();
checkHandler.sendEmptyMessageDelayed(0,2000);
}
});
// 记录AppBar滚动距离
appBarLayout.addOnOffsetChangedListener(View::setTag);

homeRefreshLayout.setOnTargetScrollCheckListener(new PullRefreshLayout.OnTargetScrollCheckListener() {
@Override
public boolean onScrollUpAbleCheck() {
// 根据AppBar滚动的距离来设置RefreshLayout是否可以下拉刷新
int appbarOffset = ((appBarLayout.getTag() instanceof Integer)) ? (int) appBarLayout.getTag() : 0;
return appbarOffset != 0;
}

@Override
public boolean onScrollDownAbleCheck() {
return true;
}
});

}
private void initData() {
initTop();
initBottom();
if (!isFirstData) {
initAppbar(-1);
}

appBarLayout.setExpanded(true, false);
}

private void initBottom() {
PhotoAdapter bottomAdapter = new PhotoAdapter();
bottomRv.setAdapter(bottomAdapter);
bottomAdapter.setDataList(10);
bottomRv.addOnScrollListener(new RecyclerView.OnScrollListener() {
@Override
public void onScrollStateChanged(@NonNull RecyclerView recyclerView, int newState) {
super.onScrollStateChanged(recyclerView, newState);
if (newState == SCROLL_STATE_IDLE) {
if (bottomRv != null && bottomRv.getLayoutManager() instanceof LinearLayoutManager) {
LinearLayoutManager layoutManager = (LinearLayoutManager) bottomRv.getLayoutManager();
if (layoutManager != null) {
// 根据滑动item设置置顶是否可以滑动
int firstCompletelyVisible = layoutManager.findFirstCompletelyVisibleItemPosition();
initAppbar(firstCompletelyVisible);
}
}
}
}
});
}

private void initTop() {
PhotoAdapter topAdapter = new PhotoAdapter();
topRv.setAdapter(topAdapter);
topAdapter.setDataList(4);
}
private boolean isFirstData;
private int oldPosition = -2;
public void initAppbar(int position) {
if (oldPosition == position){
return;
}
oldPosition = position;
CoordinatorLayout.LayoutParams params = (CoordinatorLayout.LayoutParams) appBarLayout.getLayoutParams();
MyBehavior behavior = (MyBehavior) params.getBehavior();
try {
if (behavior!=null){
if (position == -1){
behavior.setDragCallback(new AppBarLayout.Behavior.DragCallback() {
@Override
public boolean canDrag(@NonNull AppBarLayout appBarLayout) {
isFirstData = true;
//为了启用折叠工具栏的滚动
return true;
}
});
}else {
// 置顶后,如果recyclerview不是第一个item,禁止工具栏滑动
behavior.setCanMove(position<1);
}
}

} catch (Exception e) {

}

}
public Handler checkHandler = new Handler(Looper.getMainLooper()) {
@Override
public void handleMessage(@NonNull Message msg) {
super.handleMessage(msg);
//模拟网络请求结束,去除刷新效果
if (homeRefreshLayout != null) {
homeRefreshLayout.refreshComplete();
}
}
};
}

MyBehavior代码

public class MyBehavior extends AppBarLayout.Behavior {


private boolean canMove = true;

public MyBehavior() {

}

public MyBehavior(Context context, AttributeSet attrs) {

super(context, attrs);
}

@Override
public boolean onInterceptTouchEvent(@NonNull CoordinatorLayout parent, @NonNull AppBarLayout child, @NonNull MotionEvent ev) {
if (!canMove && ev.getAction() == MotionEvent.ACTION_DOWN){
return false;
}
return super.onInterceptTouchEvent(parent, child, ev);
}

public void setCanMove(boolean canMove){
this.canMove = canMove;
}

public boolean isCanMove() {
return canMove;
}
}



以上就是全部内容,待完善,以后会更新。如有建议和意见,请及时沟通。


作者:_xiangpan
链接:https://juejin.cn/post/7018453099794825252
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

Metaverse 已经到来:5 家公司正在构建我们的虚拟现实未来

如果你相信 Facebook,未来就是一个虚拟现实的“元宇宙”。这家上个月更名为 Meta的科技巨头计划今年投资100 亿美元来开发支持增强现实和虚拟现实的产品——机械手、高科技 VR 眼镜和复杂的软件应用程序,仅举几例。分析师预计该公司至少要花费 500 亿...
继续阅读 »

如果你相信 Facebook,未来就是一个虚拟现实的“元宇宙”

这家上个月更名为 Meta的科技巨头计划今年投资100 亿美元来开发支持增强现实虚拟现实的产品——机械手高科技 VR 眼镜和复杂的软件应用程序,仅举几例。分析师预计该公司至少要花费 500 亿美元来实现其对虚拟现实未来的承诺。

但 Meta 远非唯一的玩家。事实上,六家其他公司已经在构建将成为下一代虚拟交互的硬件和软件——华尔街认为这是一个价值 1 万亿美元的市场。这些公司包括谷歌、微软、苹果、Valve 和其他开发工作和通信产品的公司。随着投资者涌入市场,规模较小的初创公司可能会加入他们的行列。

“元宇宙是真实的,华尔街正在寻找赢家,”韦德布什分析师丹艾夫斯在一份报告中说。

在 Facebook 试图在元领域打上烙印时,这些公司的产品将不得不与之抗衡。

谷歌

Google Cardboard 可能是历史上最成功的 VR 项目。2014 年,当时世界上最大的科技公司要求数百万人用一块硬纸板将智能手机绑在脸上。谷歌表示,它出货了“数千万”可折叠耳机,谷歌 Cardboard应用程序的下载量超过 1.6 亿次。这不是最高分辨率或高科技的体验,但该策略帮助向数百万学生有抱负的开发人员介绍了虚拟现实。

它还帮助谷歌摆脱了之前的增强现实实验Glass今天,增强现实眼镜作为企业业务的工具进行销售,但当它推出时,谷歌的期望值很高。字面意思是:谷歌创始人谢尔盖·布林 (Sergey Brin) 从飞机上跳下时宣布了 1,500 美元的产品。

玻璃本质上是智能手机的内脏,在非处方眼镜框架上安装了一个小型摄像头。该项目失败了,但在催生了无数模因之前就失败了。 

微软

微软于 2015 年发布Hololens混合现实眼镜。一年后,微软并没有用营销炒作充斥消费者市场,而是悄悄推出了 Hololens 作为工业制造工具,面向选定的企业集团。价值 3,000 美元的商业套件附带专业版 Windows,具有额外的安全功能和软件以帮助应用程序开发。第二次迭代于 2019 年首次亮相,价格稍贵,但拥有更好的相机和镜头卡口,可实现更精确的操作,并提供更广泛的软件功能,包括工业应用。 

目前Hololens用户包括像肯沃斯,三得利和丰田,它使用耳机,以加快培养和汽车修理重量级人物,根据微软

苹果

如果你相信传言,苹果一直在释放的风口浪尖AR眼镜多年这家 iPhone 制造商于 2017 年在 iOS 11 中发布了ARKit,这是为 Apple 设备创建增强现实应用程序的开发者框架。 据科技网站The Information报道,Apple 在 2019 年举行了一次 1000 人的会议,讨论了 iPhone 上的 AR 和两个潜力未来的产品,N421 智能眼镜和 N301 VR 耳机分析师现在推测,苹果正准备在 2022 年及以后发布 AR 产品。   

阀门

Valve 的Index耳机可以说是市场上最强大的消费虚拟现实产品。高分辨率屏幕流畅,控制器在虚拟现实和游戏环境中提供无与伦比的控制。该索引还与 Value 的Steam视频游戏市场集成,这意味着该设备已经堆满了兼容的内容。

它也很贵而且很笨拙。完整的 Index VR 套件的价格接近 1,000 美元,要正常运行,耳机需要多条电缆和传感器。Valve 继续创新和试验沉浸式虚拟现实耳机。分析师预计,这家总部位于贝尔维尤的游戏公司将很快发布一款独立耳机,与 Facebook 的Oculus Quest 2展开竞争

魔法飞跃

尽管虚拟现实的想法部分受到科幻小说的启发,但 Big Tech 对 AR 和 VR 未来的现代愿景直接受到 Magic Leap 的启发。该公司成立于 2010 年,2014 年从谷歌和芯片制造商高通等公司筹集了超过 5 亿美元 2015 年,该公司发布了一段令人惊叹的视频,旨在展示该产品的技术。但是怀疑论者质疑这项技术,最终的产品遭到了抨击

最初的 Magic Leap 耳机是在设计和广告等创意协作行业销售的。

Magic Leap于 2018 年推出了一款精致的 AR 设备,筹集了更多资金,并计划在 2022 年初发布Magic Leap 2。该公司还计划瞄准国防、医疗保健和工业制造。

收起阅读 »

HashMap有何特别之处,为什么java面试从不缺席?

涉及知识点 看过java面试经验分享的小伙伴或者经历过准备过校招面试的小伙伴应该都曾经被Hashmap给支配过,即使是社招HashMap也仍然是高频考点,那么究竟为什么大家都喜欢问HashMap,其中包含了哪些知识点? 首先从生产的角度来说,HashMap是...
继续阅读 »

涉及知识点


看过java面试经验分享的小伙伴或者经历过准备过校招面试的小伙伴应该都曾经被Hashmap给支配过,即使是社招HashMap也仍然是高频考点,那么究竟为什么大家都喜欢问HashMap,其中包含了哪些知识点?



  • 首先从生产的角度来说,HashMap是我们在生产过程中最常用的集合之一,如果完全不懂它的原理,很难发挥出它的优势甚至会造成线上bug

  • 从数据结构和算法的角度,HashMap涉及到了数组,链表,红黑树,以及三者相互转化的过程,以及位运算等丰富的数据结构和算法内容。


所以HashMap就成为了面试的高频考点,这些过程都清楚,说明数据结构和算法的基础不会太差。


HashMap基本知识


JDK1.8之前数据结构是数组+链表
JDK1.8以后采用数组+链表+红黑树


image.png


其中,当数组元素超过64个且数组单个位置存储的链表元素个数超过8个时,会进化成红黑树,红黑树的引进时为了加快查找效率


同样,当数组单个位置存储的链表元素个数少于6个时,又会退化成链表


HashMap重要的类属性


其实JDK的源码都有非常详细的注释,但还是翻译一下吧,如下:



  • 初始容量大小为16


/**
* The default initial capacity - MUST be a power of two.
*/
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16


  • 最大容量为2^30


/**
* The maximum capacity, used if a higher value is implicitly specified
* by either of the constructors with arguments.
* MUST be a power of two <= 1<<30.
*/
static final int MAXIMUM_CAPACITY = 1 << 30;


  • 默认的负载因子为0.75


负载因子之所以选择是基于时间和空间平衡的结果选择的参数,时间和空间的平衡是指既不浪费太多的空间,又不用频繁地进行扩容


/**
* The load factor used when none specified in constructor.
*/
static final float DEFAULT_LOAD_FACTOR = 0.75f;


  • 链表元素数量进化成红黑树的阈值为8,数组元素大于64时,链表元素超过8就会进化为红黑树


/**
* The bin count threshold for using a tree rather than list for a
* bin. Bins are converted to trees when adding an element to a
* bin with at least this many nodes. The value must be greater
* than 2 and should be at least 8 to mesh with assumptions in
* tree removal about conversion back to plain bins upon
* shrinkage.
*/
static final int TREEIFY_THRESHOLD = 8;

至于为什么选8,在之前有一段很长的注释里面有说明,可以看一下原文如下:


 * Because TreeNodes are about twice the size of regular nodes, we
* use them only when bins contain enough nodes to warrant use
* (see TREEIFY_THRESHOLD). And when they become too small (due to
* removal or resizing) they are converted back to plain bins. In
* usages with well-distributed user hashCodes, tree bins are
* rarely used. Ideally, under random hashCodes, the frequency of
* nodes in bins follows a Poisson distribution
* (http://en.wikipedia.org/wiki/Poisson_distribution) with a
* parameter of about 0.5 on average for the default resizing
* threshold of 0.75, although with a large variance because of
* resizing granularity. Ignoring variance, the expected
* occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
* factorial(k)). The first values are:
*
* 0: 0.60653066
* 1: 0.30326533
* 2: 0.07581633
* 3: 0.01263606
* 4: 0.00157952
* 5: 0.00015795
* 6: 0.00001316
* 7: 0.00000094
* 8: 0.00000006
* more: less than 1 in ten million

大概意思就是:如果 hashCode的分布离散良好的话,那么红黑树是很少会被用到的,因为各个值都均匀分布,很少出现链表很长的情况。在理想情况下,链表长度符合泊松分布,各个长度的命中概率依次递减,注释中给我们展示了1-8长度的具体命中概率,当长度为8的时候,概率概率仅为0.00000006,这么小的概率,HashMap的红黑树转换几乎不会发生



  • 红黑树元素少于6个就退化成链表


至于为什么是6个不是7个是为了避免频繁在树与链表之间变换,如果是7,加一个元素就需要进化成红黑树,删一个元素就需要退化成链表


/**
* The bin count threshold for untreeifying a (split) bin during a
* resize operation. Should be less than TREEIFY_THRESHOLD, and at
* most 6 to mesh with shrinkage detection under removal.
*/
static final int UNTREEIFY_THRESHOLD = 6;


  • 链表树能进化成树时最小的数组长度,只有数组长度打到这个值链表才可能进化成树


/**
* The smallest table capacity for which bins may be treeified.
* (Otherwise the table is resized if too many nodes in a bin.)
* Should be at least 4 * TREEIFY_THRESHOLD to avoid conflicts
* between resizing and treeification thresholds.
*/
static final int MIN_TREEIFY_CAPACITY = 64;

重要的内部类


链表Node<K,V>


定义的链表Node类,next有木有很熟悉,单向链表
/**
* Basic hash bin node, used for most entries. (See below for
* TreeNode subclass, and in LinkedHashMap for its Entry subclass.)
*/
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
V value;
Node<K,V> next;

Node(int hash, K key, V value, Node<K,V> next) {
this.hash = hash;
this.key = key;
this.value = value;
this.next = next;
}

public final K getKey() { return key; }
public final V getValue() { return value; }
public final String toString() { return key + "=" + value; }

public final int hashCode() {
return Objects.hashCode(key) ^ Objects.hashCode(value);
}

public final V setValue(V newValue) {
V oldValue = value;
value = newValue;
return oldValue;
}

public final boolean equals(Object o) {
if (o == this)
return true;
if (o instanceof Map.Entry) {
Map.Entry<?,?> e = (Map.Entry<?,?>)o;
if (Objects.equals(key, e.getKey()) &&
Objects.equals(value, e.getValue()))
return true;
}
return false;
}
}

红黑树TreeNode<K,V>


/**
* Entry for Tree bins. Extends LinkedHashMap.Entry (which in turn
* extends Node) so can be used as extension of either regular or
* linked node.
*/
static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
TreeNode<K,V> parent; // red-black tree links
TreeNode<K,V> left;
TreeNode<K,V> right;
TreeNode<K,V> prev; // needed to unlink next upon deletion
boolean red;
TreeNode(int hash, K key, V val, Node<K,V> next) {
super(hash, key, val, next);
}

/**
* Returns root of tree containing this node.
*/
final TreeNode<K,V> root() {
for (TreeNode<K,V> r = this, p;;) {
if ((p = r.parent) == null)
return r;
r = p;
}
}

HashMap的put方法


实际上调用的是putVal方法


/**
* Associates the specified value with the specified key in this map.
* If the map previously contained a mapping for the key, the old
* value is replaced.
*
* @param key key with which the specified value is to be associated
* @param value value to be associated with the specified key
* @return the previous value associated with <tt>key</tt>, or
* <tt>null</tt> if there was no mapping for <tt>key</tt>.
* (A <tt>null</tt> return can also indicate that the map
* previously associated <tt>null</tt> with <tt>key</tt>.)
*/
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}

接下来看看putVal方法


/**
* Implements Map.put and related methods
*
* @param hash hash for key
* @param key the key
* @param value the value to put
* @param onlyIfAbsent if true, don't change existing value
* @param evict if false, the table is in creation mode.
* @return previous value, or null if none
*/
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
else {
Node<K,V> e; K k;
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
else if (p instanceof TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
else {
for (int binCount = 0; ; ++binCount) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
}
if (e != null) { // existing mapping for key
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
return oldValue;
}
}
++modCount;
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
}

putVal的流程如下:


HashMap的put方法执行过程.png


HashMap的resize扩容方法(重要)


先翻译一下这个方法的官方注释:
初始化或者将原来的容量翻倍,如果为空,则分配初始容量,否则,进行容量翻倍,原来存在的元素要么留在原来的位置上,要么在新的数组中向后移动原来数组容量的大小


/**
* Initializes or doubles table size. If null, allocates in
* accord with initial capacity target held in field threshold.
* Otherwise, because we are using power-of-two expansion, the
* elements from each bin must either stay at same index, or move
* with a power of two offset in the new table.
*
* @return the table
*/
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
//数组原来不为空
if (oldCap > 0) {
// 超过最大值就不再扩充了,就只好随你碰撞去吧
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
// 没超过最大值,就扩充为原来的2倍
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
//初始化,申明HashMap的时候指定了初始容量
else if (oldThr > 0) // initial capacity was placed in threshold
newCap = oldThr;
//初始化,申明HashMap的时候没有指定初始容量
else { // zero initial threshold signifies using defaults
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
// 计算新的resize上限
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;

//扩容之后的新数组
@SuppressWarnings({"rawtypes","unchecked"})
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
table = newTab;
if (oldTab != null) {
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { // preserve order
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}

整个扩容的流程如下:


HashMap的resize过程.png


链表重新整理的过程


可能会将原来一个链表拆分为两个链表,判断当前链表元素是否需要移动到新的链表的依据是:
计算(e.hash & oldCap) == 0?
true,不需要移动到另一个链表,我们用头结点为loHead的链表将这些元素串起来
false,元素需要移动到另一个新的链表,我们用头结点为hiHead的链表将这些元素串起来
(tips:其实lo和hi是low和high的缩写,这里用的是两个双指针来进行链表的拆分整理)
以数组从容量为16扩容到32为例,位于下标为1的链表扩容之后如图所示:一部分链表仍然保留在下标为1的位置,另一部分则迁移至下标为1+16的位置。


HashMap扩容链表重新整理.png
在链表重新整理的过程中,同一个链表的元素的相对顺序不会被改变


红黑树重新整理的过程


看了一下TreeNode的继承关系,TreeNdoe也是继承Node的子类,红黑树重新整理的过程也和链表相似,因为它其实也维护了一个链表的结构
拆分可能会将原来一个红黑树拆分为两个链表,或者一个红黑树一个链表,判断当前链表元素是否需要移动到新的链表的依据是:
计算(e.hash & oldCap) == 0?
true,不需要移动,仍然在原来的位置,我们用头结点为loHead的链表将这些元素串起来,如果元素的个数不小于6,则继续维护成红黑树,否则为链表
false,元素需要移动到另一个新的位置,我们用头结点为hiHead的链表将这些元素串起来,如果元素的个数不小于6,则继续维护成红黑树,否则为链表


HashMap的TreeNode.png


HashMap线程安全性


HashMap中存在的线程安全问题:


1.HashMap在读取Hash槽首元素的时候读取的是工作内存中引用所指向的对象,并发情况下,其他线程修改的值并不能被及时读取到。


2.HashMap在插入新元素的时候,主要会进行两次判断:


2.1 第一次是根据键的hash判断当前hash槽是否被占用,如果没有就放入当前插入对象。并发情况下,如果A线程判断该槽未被占用,在执行写入操作时时间片耗尽。此时线程B也执行获取hash(恰巧和A线程的对象发生hash碰撞)判断该槽未被占用,继而直接插入该对象。然后A线程被CPU重新调度继续执行写入操作,就会将线程B的数据覆盖。(注:此处也有可见性问题)


2.2 第二次是同一个hash槽内,因为HashMap特性是保持key值唯一,所以会判断当前欲插入key是否存在,存在就会覆盖。与上文类似,并发情况下,如果线程A判断最后一个节点仍未发现重复key那么会把以当前对象构建节点挂在链表或者红黑树上,如果线程B在A判断操作和写操作之间,进行了判断和写操作,也会发生数据覆盖。


除此之外扩容也会发生类似的并发问题。还有size的问题,感觉其实高并发情况下这个size的准确性可以让步性能。


参考文章


【1】tech.meituan.com/2016/06/24/…

【2】blog.csdn.net/weixin_3143…


作者:ForeverKobe
链接:https://juejin.cn/post/7033392478753390629
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

为什么 JakeWharton 建议:App 只要用到一个 Activity ?

安卓开发大神级人物 JakeWharton 前不久在接受采访时提出一个颇具争议而又没有给出原因的建议:一个 App 只需要一个 Activity ,你可以使用 Fragments,只是别用 Fragments 回退栈。 针对这一言论,有关 JakeWharto...
继续阅读 »

安卓开发大神级人物 JakeWharton 前不久在接受采访时提出一个颇具争议而又没有给出原因的建议:一个 App 只需要一个 Activity ,你可以使用 Fragments,只是别用 Fragments 回退栈。


针对这一言论,有关 JakeWharton 建议的背后原因的一个提问迅速在 Reddit 国外网站的安卓开发频道引发热评。



众多安卓开发人员纷纷提出自己的见解。其中获赞最高的一条,甚至得到 JakeWharton 本人的亲自赞评。



我们来看看这条回答都提到了哪些内容,对 Activity 和 Fragment 之间的爱恨情仇有何独到的见解,凭什么能得到 JakeWharton 本尊的青睐有加。




因为 Activity 是一个程序入口。你可以将其视为 app 的一个 main 函数。站在用户的立场上,通常你进入 app 的方式可能包括以下几种:




  • launcher 桌面程序(main 函数入口);




  • 来自参数化 main 函数入口的通知栏,并且导航到 app 的指定位置;




  • 如果你做的是一个相机应用,那么需要处理图片请求的 intents;




  • 如果你做的是一个社交产品,那么需要处理 share 请求的 intents;




差不多类似这些场景。


但是,如果你真的不用分享和来自应用的 intents 的话,并且唯一的程序入口就是 launcher 桌面,别为每一个页面创建一个新的入口。这样做其实没有意义。为什么没有意义?因为这种场景下,进程死掉后 launcher 能够启动任何你应用中的 Activity 页面。


Fragments 是处理生命周期事件的视图控制器,并且非常不错。然而,Fragments 回退栈简直垃圾;回退栈变化监听器总是不正常地被调用( 1 次 transaction 三次调用?),并且不告诉你调用什么,而在恢复事务时也不知道哪些 fragments 是可用的。


你可以给事务添加 tag 标签,然后从栈中弹出操作,但是仅仅是一个 main -> Events -> Details(id=123) 的操作流程就相当繁琐了。


同样的,一旦你将一个 Fragment 放进回退栈中,我个人不知道它的生命周期开始做什么。我曾经遇到过一个后台中的 fragment 被调用四次 onCreateView() 方法,我甚至不知道究竟怎么了。而没有位于回退栈中的 Fragments 是可以被预见的。它们的动画支持有点古怪,但至少它们还能使用。


所以如果你想知道哪些 Fragments 是你能够操作的并且哪些 views 是你正在展示的并且能够在你自己的导航状态控制之中,那么你应该自己处理导航操作。把“应用逻辑”抽象化到一个 presenter(亦枫注:MVP 模式)中听起来来很棒,但是你是不是脱离了应用视图层里面的真实情况?



但是单一 activity 的优势是什么?



更简单的生命周期处理(例如,当 app 进入后台时,你只需要处理 onStop 方法),更少错误空间,和更多控制。同样的,你可以移动视图层外面的导航状态到 domain 层,或者至少到 presenter 中。不需要太多 view.navigateToDetail(songId) 之类的东西,你只需要在你的 presenter 或者 ViewModel 或者无论哪些时髦的用法中使用 backstack.goTo(SongKey.create(songId)) 就行。借助一个合适的库,当你到了 onResume 时它会自动将这些导航调用加入队列,并且不会致使 fragment 事务发生崩溃,非常得好。


尽管 Google 给出的案例也在用 commitAllowingStateLoss(),我有使用 commitNow() 的动画爱好。在我看来,单个 activity 能够看得见的好处就是,页面间共享 views 的能力,取代通过使用 <include 标签在 18 个布局文件重复视图。其他当然是更简单的导航操作。




以上便是深得 JakeWharton 大神心意的一条回答。话虽如此,但是系统 Fragment 存在的未解之谜或者说出乎你意料的坑实在太多。如果一定要在多 activity 部分 fragments 和单 activity 多 fragments 之间选择的话,我想不只是我,很多人还是毫不犹豫地选择前者。


更多讨论内容,参见:


http://www.reddit.com/r/androidde…


作者:亦枫
链接:https://juejin.cn/post/6844903521209286663
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

termux 安卓神器

今年春节在家的时候,手头没有电脑,但是想用电脑写下代码,于是乎我找到这一款termux神器,可以把安卓手机当作一台小型的服务器来使用。利用5年前已经淘汰的安卓手机,插上适配器,这样我就可以无休止的跑我的脚本了。termux 安装在termux官网上看到最新的版...
继续阅读 »

今年春节在家的时候,手头没有电脑,但是想用电脑写下代码,于是乎我找到这一款termux神器,可以把安卓手机当作一台小型的服务器来使用。利用5年前已经淘汰的安卓手机,插上适配器,这样我就可以无休止的跑我的脚本了。

termux 安装

在termux官网上看到最新的版本,必须要安装在Android 7以上的手机,我的魅族手机经过我的一番折腾只能升级到安卓6,不能安装最新的termux,还好旧的版本0.73支持Android 5以上。  安装包下载后,就是常规的apk安装了。

termux 环境配置

termux支持sshd,所有我们不用在旧手机上进行操作,我们可以在自己新安卓手机上通过ssh连接到旧手机上,前提是termux要启动sshd.

#安装openssh
pkg install openssh
#安装后,启动sshd
sshd
#设置用户密码
passwd
#登陆用户名
whoami
#查看局域网内ip
ifconfig|grep inet

我们在另外一台手机上安卓juicessh,一款安卓的ssh客户端,由于termux的sshd端口跟我们平时使用的22端是不一样的,所以在ssh到termux采用的是8022端口,通过刚才我们查看的用户名登陆,输入我们刚刚设置的密码,就能完成ssh手机登陆了。

现在我们就能愉快的采用termux进行学习了。

vim 练习

#安装vim
pkg install vim
vim hello.txt

 这就跟我们配置在服务器用vim一样,我们就可以练习下vim的快捷键

安装nodejs

#安装nodejs
pkg install nodejs
node -v
pkg install npm
npm -v

安装软件的时候,会有点慢,但是千万不要切换镜像,因为我们的版本比较旧,国内的源没有搬运旧的,所以切换后会导致安装软件出现各自问题,这是卸载安装5次的体验。清华源网站已经提示了镜像仅适用于 Android 7.0 (API 24) 及以上版本,旧版本系统使用本镜像可能导致程序错误。

安装好nodejs后,我们可以做更多有趣的事情,运行node脚本,node server服务器,个人网站等等,甚至可以做一些定时任务,比如定时发天气预告邮件等。


作者:chiv
链接:https://juejin.cn/post/6930531076607737870
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »