注册
环信即时通讯云

环信即时通讯云

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

环信开发文档

Demo体验

Demo体验

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

RTE开发者社区

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

技术讨论区

技术交流、答疑
资源下载

资源下载

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

iOS Library

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

Android Library

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

用Canvas绘制一个数字键盘

Hello啊老铁们,这篇文章还是阐述自定义View相关的内容,用Canvas轻轻松松搞一个数字键盘,本身没什么难度,这种效果实现的方式也是多种多样,这篇只是其中的一种,要说本篇有什么特别之处,可能就是纯绘制,没有用到其它的任何资源,一个类就搞定了,文中不足之处...
继续阅读 »

Hello啊老铁们,这篇文章还是阐述自定义View相关的内容,用Canvas轻轻松松搞一个数字键盘,本身没什么难度,这种效果实现的方式也是多种多样,这篇只是其中的一种,要说本篇有什么特别之处,可能就是纯绘制,没有用到其它的任何资源,一个类就搞定了,文中不足之处,各位老铁多包含,多指正。


今天的内容大概如下:


1、效果展示


2、快速使用及属性介绍


3、具体代码实现


4、源文件地址及总结


一、效果展示


很常见的数字键盘,背景,颜色,文字大小,点击的事件等等,均已配置好,大家可以看第2项中相关介绍。


静态效果展示:



动态效果展示,录了一个gif,大家可以看下具体的触摸效果。



二、快速使用及属性介绍


鉴于本身就一个类,不值当去打一个远程的Maven,大家用的话可以直接下载,把文件复制到项目里即可,复制到项目中,就可以按照下面的步骤去使用。


引用


1、xml中引用,可以根据需要,设置宽高及相关属性

<KeyboardView
android:id="@+id/key_board_view"
android:layout_width="match_parent"
android:layout_height="wrap_content" />

2、代码直接创建,然后追加到相关视图里即可

val keyboardView=KeyboardView(this)

方法及属性介绍


单个点击的触发监听:

keyboardView.setOnSingleClickListener {
//键盘点击的数字

}

获取最终的字符串点击监听,其实就是把你点击的数字拼接起来,一起输出,特别在密码使用的时候,省的你再自己拼接了,配合number_size属性和setNumberSize方法一起使用,默认是6个长度,可以根据需求,动态设置。

keyboardView.setOnNumClickListener {
//获取最终的点击数字字符串,如:123456,通过number_size属性或setNumberSize方法,设置最长字符
}

其它方法




















































方法参数概述
hintLetter无参隐藏字母
setBackGroundColorint类型的颜色值设置整体背景色
setRectBackGroundColorint类型的颜色值设置数字格子背景色
setTextColorint类型的颜色值设置文字颜色
setTextSizeFloat设置数字大小
setNumberSizeint类型设置按下的数字总长度
setRectHeightFloat设置数字键盘每格高度
setSpacingFloat设置数字键盘每格间隔距离

属性介绍






























































属性类型概述
background_colorcolor背景颜色
rect_background_colorcolor数字格子背景色
down_background_colorcolor手指按下的背景颜色
text_colorcolor文字颜色
text_sizedimension文字大小
letter_text_sizedimension字母的文字大小
rect_heightdimension数字格子高度
rect_spacingdimension格子间距
is_rect_letterboolean是否显示字母
number_sizeinteger按下的数字总长度字符

三、具体代码实现


代码实现上其实也没有什么难的,主要就是用到了自定义View中的onDraw方法,简单的初始化,设置画笔,默认属性就不一一介绍了,直接讲述主要的绘制部分,我的实现思路如下,第一步,绘制方格,按照UI效果图,应该是12个方格,简图如下,需要注意的是,第10个是空的,也就是再绘制的时候,需要进行跳过,最后一个是一个删除的按钮,绘制的时候也需要跳过,直接绘制删除按钮即可。



1、关于方格的绘制


方格的宽度计算很简单,(手机的宽度-方格间距*4)/3即可,绘制方格,直接调用canvas的drawRoundRect方法,单纯的和数字一起绘制,直接遍历12个数即可,记住9的位置跳过,11的位置,绘制删除按钮。

mRectWidth = (width - mSpacing * 4) / 3
mPaint!!.strokeWidth = 10f
for (i in 0..11) {
//设置方格
val rect = RectF()
val iTemp = i / 3
val rectTop = mHeight * iTemp + mSpacing * (iTemp + 1f)
rect.top = rectTop
rect.bottom = rect.top + mHeight
var leftSpacing = (mSpacing * (i % 3f))
leftSpacing += mSpacing
rect.left = mRectWidth!! * (i % 3f) + leftSpacing
rect.right = rect.left + mRectWidth!!
//9的位置是空的,跳过不绘制
if (i == 9) {
continue
}
//11的位置,是删除按钮,直接绘制删除按钮
if (i == 11) {
drawDelete(canvas, rect.right, rect.top)
continue
}
mPaint!!.textSize = mTextSize
mPaint!!.style = Paint.Style.FILL
//按下的索引 和 方格的 索引一致,改变背景颜色
if (mDownPosition == (i + 1)) {
mPaint!!.color = mDownBackGroundColor
} else {
mPaint!!.color = mRectBackGroundColor
}
//绘制方格
canvas!!.drawRoundRect(rect, 10f, 10f, mPaint!!)
}

2、关于数字的绘制


没有字母显示的情况下,数字要绘制到中间的位置,有字母的情况下,数字应该往上偏移,让整体进行居中,通过方格的宽高和自身文字内容的宽高来计算显示的位置。

//绘制数字
mPaint!!.color = mTextColor
var keyWord = "${i + 1}"
//索引等于 10 从新赋值为 0
if (i == 10) {
keyWord = "0"
}
val rectWord = Rect()
mPaint!!.getTextBounds(keyWord, 0, keyWord.length, rectWord)
val wWord = rectWord.width()
val htWord = rectWord.height()
var yWord = rect.bottom - mHeight / 2 + (htWord / 2)
//上移
if (i != 0 && i != 10 && mIsShowLetter) {
yWord -= htWord / 3
}
canvas.drawText(
keyWord,
rect.right - mRectWidth!! / 2 - (wWord / 2),
yWord,
mPaint!!
)

3、关于字母的绘制


因为字母是和数字一起绘制的,所以需要对应的字母则向下偏移,否则不会达到整体居中的效果,具体的绘制如下,和数字的绘制类似,拿到方格的宽高,以及字母的宽高,进行计算横向和纵向位置。

    	//绘制字母
if ((i in 1..8) && mIsShowLetter) {
mPaint!!.textSize = mLetterTextSize
val s = mWordArray[i - 1]
val rectW = Rect()
mPaint!!.getTextBounds(s, 0, s.length, rectW)
val w = rectW.width()
val h = rectW.height()
canvas.drawText(
s,
rect.right - mRectWidth!! / 2 - (w / 2),
rect.bottom - mHeight / 2 + h * 2,
mPaint!!
)
}

4、关于删除按钮的绘制


删除按钮是纯线条的绘制,没有使用图片资源,不过大家可以使用图片资源,因为图片资源还是比较的靠谱。

 /**
* AUTHOR:AbnerMing
* INTRODUCE:绘制删除按键,直接canvas自绘,不使用图片
*/
private fun drawDelete(canvas: Canvas?, right: Float, top: Float) {
val rWidth = 15
val lineWidth = 35
val x = right - mRectWidth!! / 2 - (rWidth + lineWidth) / 4
val y = top + mHeight / 2
val path = Path()
path.moveTo(x - rWidth, y)
path.lineTo(x, y - rWidth)
path.lineTo(x + lineWidth, y - rWidth)
path.lineTo(x + lineWidth, y + rWidth)
path.lineTo(x, y + rWidth)
path.lineTo(x - rWidth, y)
path.close()
mPaint!!.strokeWidth = 2f
mPaint!!.style = Paint.Style.STROKE
mPaint!!.color = mTextColor
canvas!!.drawPath(path, mPaint!!)

//绘制小×号
mPaint!!.style = Paint.Style.FILL
mPaint!!.textSize = 30f
val content = "×"
val rectWord = Rect()
mPaint!!.getTextBounds(content, 0, content.length, rectWord)
val wWord = rectWord.width()
val htWord = rectWord.height()
canvas.drawText(
content,
right - mRectWidth!! / 2 - wWord / 2 + 3,
y + htWord / 3 * 2 + 2,
mPaint!!
)

}

5、按下效果的处理


按下的效果处理,重写onTouchEvent方法,然后在down事件里通过,手指触摸的XY坐标,判断当前触摸的是那个方格,记录下索引,并使用invalidate进行刷新View,在onDraw里进行改变画笔的颜色即可。


根据XY坐标,返回触摸的位置

 /**
* AUTHOR:AbnerMing
* INTRODUCE:返回触摸的位置
*/
private fun getTouch(upX: Float, upY: Float): Int {
var position = -2
for (i in 0..11) {
val iTemp = i / 3
val rectTop = mHeight * iTemp + mSpacing * (iTemp + 1f)
val top = rectTop
val bottom = top + mHeight
var leftSpacing = (mSpacing * (i % 3f))
leftSpacing += 10f
val left = mRectWidth!! * (i % 3f) + leftSpacing
val right = left + mRectWidth!!
if (upX > left && upX < right && upY > top && upY < bottom) {
position = i + 1
//位置11默认为 数字 0
if (position == 11) {
position = 0
}
//位置12 数字为 -1 意为删除
if (position == 12) {
position = -1
}
}
}
return position
}

在onDraw里进行改变画笔的颜色。

 //按下的索引 和 方格的 索引一致,改变背景颜色
if (mDownPosition == (i + 1)) {
mPaint!!.color = mDownBackGroundColor
} else {
mPaint!!.color = mRectBackGroundColor
}

6、wrap_content处理


在使用当前控件的时候,需要处理wrap_content的属性,否则效果就会和match_parent一样了,具体的处理如下,重写onMeasure方法,获取高度的模式后进行单独的设置。

    override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {
super.onMeasure(widthMeasureSpec, heightMeasureSpec)
val heightSpecMode = MeasureSpec.getMode(heightMeasureSpec)
val widthSpecSize = MeasureSpec.getSize(widthMeasureSpec)
if (heightSpecMode == MeasureSpec.AT_MOST) {
//当高度为 wrap_content 时 设置一个合适的高度
setMeasuredDimension(widthSpecSize, (mHeight * 4 + mSpacing * 5 + 10).toInt())
}
}

四、源文件地址及总结


源文件地址:


github.com/AbnerMing88…


源文件不是一个项目,是一个单纯的文件,大家直接复制到项目中使用即可,对于26个英文字母键盘绘制,基本上思路是一致的,大家可以在此基础上进行拓展,本文就先到这里吧,整体略有瑕疵,忘包含。


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

Android 系统启动到App 界面完全展示终于明白(图文版)

之前文章有分析过Activity创建到View的显示过程,属于单应用层面的知识范畴,本篇将结合Android 系统启动部分知识将两者串联分析,以期达到融会贯通的目标。 通过本篇文章,你将了解到: Android 系统启动流程概览 ServiceManage...
继续阅读 »

之前文章有分析过Activity创建到View的显示过程,属于单应用层面的知识范畴,本篇将结合Android 系统启动部分知识将两者串联分析,以期达到融会贯通的目标。

通过本篇文章,你将了解到:




  1. Android 系统启动流程概览

  2. ServiceManager 进程作用

  3. Zygote 进程创建与fork子进程

  4. system_server 进程作用

  5. App 与 system_server 交互

  6. Activity 与 View的展示

  7. 全流程图



1. Android 系统启动流程概览



image.png




  • init 是用户空间的第一个进程,它的父进程是idle进程

  • init 进程通过解析init.rc 文件并fork出相应的进程

  • zygote是第一个Java 虚拟机进程,通过它孵化出system_server 进程

  • system_server 进程启动桌面(Launcher)App



以上为Android 系统上电到桌面启动的简略过程,我们重点关注其中几个进程:



init、servicemanger、zygote、system_server



idle 与 init 关系如下:



image.png


查看依赖关系:



image.png


init.rc 启动servicemanager、zygote 配置如下:



image.png



image.png


2. ServiceManager 进程作用


Android 进程间通信运用最广泛的是Binder机制,而ServiceManager进程与Binder息息相关。
DNS 存储着域名和ip的映射关系,类似的ServiceManager存储着Binder客户端和服务端的映射。



image.png


App1作为Binder Client端,App2 作为Binder Server端,App2 开放一个接口给App1使用(通常称为服务),此时步骤如下:




  1. App2 向ServiceManager注册服务,过程为:App2 获取ServiceManager的Binder引用,通过该Binder引用将App2 的Binder对象(实现了接口)添加到Binder驱动,Binder驱动记录对象与生成handle并返回给ServiceManager,ServiceManager记录关键信息(如服务名,handle)。

  2. App1 向ServcieManager查询服务,过程为: App1 获取ServiceManager的Binder引用,通过该Binder引用发送查询命令给Binder驱动,Binder驱动委托ServiceManager进行查询,ServiceManager根据服务名从自己的缓存链表里查出对应服务,并将该服务的handle写入驱动,进而转为App1的Binder代理。

  3. App1 拿到App2 的Binder代理后,App1 就可以通过Binder与App2进行IPC通信了,此时ServiceManager已经默默退居幕后,深藏功与名。



由上可知,ServiceManager进程扮演着中介的角色。


3. Zygote 进程创建与fork子进程


Zygote 进程的创建


Zygote 进程大名鼎鼎,Android 上所有的Java 进程都由Zygote孵化,Zygote名字本身也即是受精卵,当然文雅点一般称为孵化器。



image.png


Zygote 进程是由init进程fork出来的,进程启动后从入口文件(app_main.cpp)入口函数开始执行:




  1. 构造AppRuntime对象,并创建Java虚拟机、注册一系列的jni函数(Java和Native层关联起来)

  2. 从Native层切换到Java层,执行ZygoteInit.java main()函数

  3. fork system_server进程,预加载进程公共资源(后续fork的子进程可以复用,加快进程执行速度)

  4. 最后开启LocalSocket,并循环监听来自system_server创建子进程的Socket请求。



通过以上步骤,Zygote 启动完成,并等待创建进程的请求。



image.png


初始状态步骤:




  1. Zygote fork system_server 进程并等待Socket请求

  2. system_server 进程启动后会请求打开Launcher(桌面),此时通过Socket发送创建请求给Zygote,Zygote 收到请求后负责fork 出Launcher进程并执行它的入口函数

  3. Launcher 启动后用户就可以看到初始的界面了



用户操作:

桌面显示出来后,此时用户想打开微信,于是点击了桌面上的微信图标,背后的故事如下:




  1. Launcher App 收到点击请求,会执行startActivity,这个命令会通过Binder传递给system_server进程里的AMS(ActivityManagerService)模块

  2. AMS 发现对应的微信进程并没有启动,于是通过Socket发送创建微信进程的请求给Zygote

  3. Zygote 收到Socket请求后,fork 微信进程并执行对应的入口函数,之后就会显示出微信的界面了



用图表示如下:



image.png


由上可知,App进程和system_server 进程之间通信方式为Binder,而system_server和Zygote 通信方式为Socket,App进程并不直接请求Zygote做事情,而是通过system_server进行处理,system_server 记录着当前所有App 进程的状态,由它来统一管理各个App的生命周期。


Zygote 进程fork 子进程



image.png


Zygote 进程在Java层监听Socket请求,收到请求后层层调用最后切换到Native执行系统调用fork()函数,最后根据fork()返回值区分父子进程,并在子进程里执行入口函数。


4. system_server 进程作用


system_server 为所有App提供服务,可以说是系统的核心进程之一,它主要的功能如下:



image.png


可以看出,它创建并启动了许多服务,常见的AMS、PMS、WMS,我们常说系统某某服务返回了啥,往细的说这里的"系统"可以认为是system_server进程。

需要注意的是,这里所说的服务并不是Android四大组件的Service,而是某一类功能。


四大组件的交互也要依靠system_server:



image.png


实际调用流程如下:



image.png


由上图可知,不管是同一进程内的通信亦或是不同进程间的通信,都需要system_server介入。


App 和 system_server 是属于不同的进程,App进程如何找到system_server呢?

还是要借助ServiceManager进程:



image.png


system_server 在启动时候不仅开启了各种服务,同时还将需要暴露的服务注册到ServiceManager里,其它进程想要使用system_server的功能时只需要从SystemManager里查询即可。


5. App 与 system_server 交互


App 想要获取系统的功能,在大部分情况下是绕不过system_server的,接着来看看App如何与system_server进行交互。


前面分析过,App想要获取system_server 服务只需要从ServiceManager里获取即可,调用形式如下:

getSystemService(Context.WINDOW_SERVICE)

那反过来呢?system_server如何主动调用App的服务呢?

既然获取服务的本质是拿到对端的Binder引用,那么也可以反过来,将App的Binder传递给system_server,等到system_server想要调用App时候拿出来用即可,类似回调的功能,如下图:



image.png


再细化一下流程:



image.png




  1. App 进程在启动后执行ActivityThread.java里的main()方法,在该方法里调用system_server的接口,并将自己的Binder引用(mAppThread)传递给system_server

  2. system_server 掌管着Application和四大组件的生命周期,system_server会告诉App进程当前是需要创建Application实例还是调用到Activity某个生命周期阶段(如onCreate/onResume等),此时就是依靠mAppThread回调回来

  3. 此时的App进程作为Binder Server端,它是在子线程收到system_server进程的消息,因此需要通过post到主线程执行

  4. 最终Application/Activity 的生命周期函数将会在主线程执行,这也就是为什么四大组件不能执行耗时任务的原因,因为都会切换到主线程执行四大组件的各种重写方法



6. Activity 与 View的展示


通过上面的分析可知现在的流程已经走到App进程本身,Application、Activity 都已经创建完毕了,什么时候会显示View呢?

先看Activity.onCreate()的调用流程:



image.png


此流程结束,整个ViewTree都构建好了。


接着需要将ViewTree添加到Window里流程如下:



image.png


最后监听屏幕刷新信号,当信号到来之后遍历ViewTree进行Measure、Layout、Draw操作,最终渲染到屏幕上,此时我们的App界面就显示出来了。



image.png


7. 全流程图



image.png


附源码路径:

init.rc配置文件

ServiceManager入口

Zygote native入口

Zygote java入口

system_server入口

App入口


更多Android 源码查看方式请移步:Android-系统源码查看的几种方式


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

Kotlin 协程如何与 Java 进行混编?

问题 在 Java 与 Kotlin 混编项目中大概率是会遇到 Kotlin 线程的使用问题。协程的混编相对于其他特性的使用上会相对麻烦而且比较容易踩坑。我们以获取 token 来举例,比如有一个获取 token 的 suspend 函数:// 常规的 sus...
继续阅读 »

问题


在 Java 与 Kotlin 混编项目中大概率是会遇到 Kotlin 线程的使用问题。协程的混编相对于其他特性的使用上会相对麻烦而且比较容易踩坑。我们以获取 token 来举例,比如有一个获取 token 的 suspend 函数:

// 常规的 suspend 函数,可以供 Kotlin 使用,Java 无法直接使用
suspend fun getTokenSuspend(): String {
// do something too long
return "Token"
}

想要在 Java 中直接调用则会产出如下错误:


image.png


了解 Kotlin 协程机制的同学应该知道 suspend 修饰符在 Kotlin 编译器期会被处理成对应的 Continuation 类,这里不展开讨论。


这个问题也可以使用简单的方式进行解决,那就是使用 runBlocking 进行简单包装一下即可。


使用 runBlocking 解决


一般情况下我们可能会使用以下代码解决上述问题。定义的 Kotlin 协程代码如下:

// 提供给 Java 使用的封装函数,Java 代码可以直接使用
fun getTokenBlocking(): String =runBlocking{// invoke suspend fun
getTokenSuspend()
}

在 Java 层代码的使用方式大致如下:

public void funInJava() {
String token = TokenKt.getTokenBlocking();
}

看上去方案比较简单,但是直接使用 runBlocking 也会存在一些隐患。 runBlocking 会阻塞当前调用者的线程,如果是在主线程进行调用的话,会导致 App 卡顿,严重的会导致 ANR 问题。那有没有比 runBlocking 更合理的解决方案呐?


回答这个问题之前,先梳理下 Java 与 Kotlin 两种语言在处理耗时函数的一般做法。


Java & Kotlin 耗时函数的一般定义


Java



  • 靠语义约束。比如定义的函数名中 sync 修饰,表明他可能是一个耗时的函数,更好的还会添加 @WorkerThread 注解,让 lint 帮助使用者去做一些检查,确保不会在主线程中去调用一些耗时函数导致页面卡顿。

  • 靠语法约束,定义 Callback。将耗时的函数执行放到一个单独的线程中执行,然后将回调的结果通过 Callback 的形式返回。这种方式无论调用者是什么水平,代码质量都不会有问题;


Kotlin



  • 靠语义约束,同 Java

  • 添加 suspend 修饰,靠语法约束。内部耗时函数切到子线程中执行。外部调用者使用同步的方式调用耗时函数却不会阻塞主线程(这也是 Kotlin 协程主要宣传的点)。


在 Java 与 Kotlin 混编的项目中,上述情况的复杂度将会上升。


使用 CompletableFuture 解决


在审视一下 runBlocking 的使用问题,这种做法是将 Kotlin 中的语法约束退化到语义约束层面了,有的可能连语义层面的约束都没有,这种情况只能祈求调用者的使用是正确的 -- 在子线程调用,而不是在主线程调用。那应该如何怎么处理,就是采用回调的方式,让语法能够规避的问题就不要采用语义来处理。

suspend fun getToken(): String {
// do something too long
return "Token"
}

fun getTokenFuture(): CompletableFuture<String> {
returnCoroutineScope(Dispatchers.IO).future{getToken()}
}

注意:future 是 org.jetbrains.kotlinx:kotlinx-coroutines-jdk8 包中提供的工具类,基于 CoroutineScope 定义的扩展函数,使用时需要导入依赖包。


Java 中的使用方式如下:

public void funInJava() {
try {
// 通过 Future get() 显示调用 getTokenFuture 函数
TestKt.getTokenFuture().get();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}

可能会问这里看上去和直接在函数内部使用 runBlocking 没有太大的区别,反而使用上会更麻烦些。的确是这样的,这样的目的是把选择权交给调用者,或者说让调用者显示的知道这不是一个简单的函数,从而提高其在使用 API 时的警惕度,也就是之前提到的从语法层面对 API 进行约束。


退一步说,上述的内容是针对的仅仅是“不得不”这么做的场景,但是对于大部分场景都是可以通过合理的设计来避免出现上述情况:



  • 底层定义的 suspend 函数可以在上层的 ViewModel 中的 viewModelScope 中调用解决;

  • 统一对外暴露的 API 是 Java 类的话,新增的 API 提供可以使用 suspend 类型的扩展函数,使用 suspend 类型对外暴露;

  • 如果明确知道调用者是 Java 代码,那么请提供 Callback 的 API 定义;


总结


尽量使用合理的设计来尽量规避 Kotlin 协程与 Java 混用的情况,在 API 的定义上语法约束优先与语义约束,语义约束优于没有任何约束。当然在特殊的情况下也可以使用 CompletableFuture API 来封装协程相关 API。


下面对几种常见场景推荐的一些写法:



  1. 在单元测试中可以直接使用 runBlocking

  2. 耗时函数可以直接定义为 suspend 函数或者使用 Callback 形式返回;

  3. 对于 Java 类中调用协程函数的场景应使用显示的声明告知调用者,严格一点的可以判断线程,对于在主线程调用的可以抛出异常或者记录下来统一处理;

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

通俗易懂 Android 架构组件发展史

前言 谈到 Android 架构,相信谁都能说上两句。从 MVC,MVP,MVVM,再到时下兴起 MVI,架构设计层出不穷。如何为项目选择合适架构,也成常备课题。 由于架构并非空穴来风,每一种设计都有其存在依据。故今天我们一起探寻 “架构演化” 来龙去脉,相信...
继续阅读 »

前言


谈到 Android 架构,相信谁都能说上两句。从 MVC,MVP,MVVM,再到时下兴起 MVI,架构设计层出不穷。如何为项目选择合适架构,也成常备课题。


由于架构并非空穴来风,每一种设计都有其存在依据。故今天我们一起探寻 “架构演化” 来龙去脉,相信阅读后你会豁然开朗。


文章目录一览



  • 前言

  • 原生架构

    • 原始图形化架构

      • 高频痛点 1:Null 安全一致性问题



    • 原始工程架构 MVC

      • 高频痛点 2:成员变量爆炸

      • 高频痛点 3:状态管理一致性问题

      • 高频痛点 4:消息分发一致性问题





  • 它山之石

    • 矫枉过正 MVP

      • 反客为主 Presenter

      • 简明易用 三方库



    • 拨乱反正 MVVM

      • 曲高和寡 DataBinding

      • 未卜先知 mBinding





  • 力挽狂澜

    • 官方牵头 Jetpack

      • 一举多得 ViewModel



    • 半路杀出 Kotlin

      • 喜闻乐见 ViewBinding





  • 百花齐放

    • 最佳实践 Jetpack MVVM

      • 屏蔽回推 UnPeekLiveData

      • 消息分发 Dispatcher

      • 严格模式 DataBinding



    • 另起炉灶 Compose



  • 综上


原生架构


原始图形化架构


完整软件服务,通常包含客户端和服务端。


Linux 服务端,开发者通过命令行操作;Android 客户端,面向普通用户,须提供图形化操作。为此,Android 将图形系统设计为,通过客户端 Canvas 绘制图形,并交由 Surface Flinger 渲染。


但正如《过目难忘 Android GUI 关系梳理》所述,复杂图形绘制离不开排版过程,而开发者良莠不齐,如直接暴露 Canvas,易导致开发者误用和产生不可预期错误,


为此 Android 索性基于 “模板方法模式” 设计 View、Drawable 等排版模板,让 UI 开发者可继承标准化模板,配置出诸如 TextView、ImageView、ShapeDrawable 等自定义模板,供业务开发者用。



这样误用 Canvas 问题看似解决,却引入 “高频痛点 1”:View 实例 Null 安全一致性问题。这是 Java 语言项目硬伤,客户端背景下尤明显。



高频痛点 1:Null 安全一致性问题


例如某页面有横竖两布局,竖布局有 TextViewA,横布局无,那么横屏时,findViewbyId 拿到则是 Null 实例,后续 mTextViewA.setText( ) 如未判空处理,即造成 Null 安全问题,



对此不能一味强调 “手动判空”,毕竟一个页面中,控件成员多达十数个,每个控件实例亦遍布数十方法中。疏忽难避免。



那怎办?此时 2008 年,回顾历史,可总结为:“同志们,7 年暗夜已开始,7 年后会有个框架,驾着七彩祥云来救你”。



原始工程架构 MVC


时间来到 2013,以该年问世 Android Studio 为例,


工程结构主要包含 Java 代码和 res 资源。考虑到布局编写预览需求,Android 开发默认基于 XML 声明 Layout,MVC 形态油然而生,



其中 XML 作 View 角色,供 View-Controller 获取实例和控制,


Activity 作 View-Controller 角色,结合 View 和 Model 控制逻辑,


开发者另外封装 DataManager,POJO 等,作 Model 角色,用于数据请求响应,



显而易见,该架构实际仅两层:控制层和数据层,


Activity 越界承担 “领域层” 业务逻辑职责,也因此滋生如下 3 个高频痛点:


高频痛点 2:成员变量爆炸


成员声明,动辄数十行,令人眼花缭乱。接手老项目开发者,最有体会。



高频痛点 3:状态管理一致性问题


View 状态保存和恢复,使用原生 onInstanceStateSave & Restore 机制,开发者容易因 “记得 restore、遗漏 save” 而产生不可预期错误。



高频痛点 4:消息分发一致性问题


由于 Activity 额外承担 “领域层” 职责,乃至消息收发工作也直接在 Activity 内进行,这使消息来源无法保证时效性、一致性,易 “被迫收到” 不可预期推送,滋生千奇百怪问题。


EventBus 等 “缺乏鉴权结构” 框架,皆为该背景下 “消息分发不一致” 帮凶。



“同志们,5 年水深火热已过去,再过 2 年,曙光降临”


好家伙,这是提前拿到剧本。既然如此,这 2 年时间,不如放开手脚,引入它山之石试试(就逝世)。



它山之石


矫枉过正 MVP


这一版对 “现实状况” 判断有偏差。


MVP 规定 Activity 应充当 View,而 Presenter 独吞 “表现层” 逻辑,通过 “契约接口” 与 View、Model 通信,


这使 Activity 职能被严重剥夺,只剩末端通知 View 状态改变,无法全权自治 “表现逻辑”。



反客为主 Presenter


从 Presenter 角度看,似乎遵循 “依赖倒置原则” 和 “最小知道原则”,但从关系界限层面看,Presenter 属 “空降” 角色,一切都其自作主张、暗箱操作,不仅 “未能实质解决” 原 Activity 面临上述 4 大痛点,反因贪婪夺权引入更多烂事。


这也是为何,开发过 MVP 项目,都知有多别扭。


简明易用 三方库


基于其本质 “依赖倒置原则” 和 “最小知道原则”,更建议将其用于 “局部功能设计”,如 “三方库” 设计,使开发者 无需知道内部逻辑,简单配置即可使用



Github:Linkage-RecyclerView


我们维护的 “饿了么二级联动列表” 库,即是基于该模式设计,感兴趣可自行查阅。



拨乱反正 MVVM


经历漫长黑夜,Android 开发引来曙光。


2015 年 Google I/O 大会,DataBinding 框架面世。


该框架可用于解决 “高频痛点1:View 实例 Null 安全一致性问题”,并跟随 MVVM 模式步入开发者视野。


曲高和寡 DataBinding



MVVM 是种约定,双向绑定是 MVVM 特征,但非 DataBinding 本质,故长久以来,开发者对 DataBinding 存在误解,认为使用 DataBinding 即须双向绑定、且在 XML 中调试。



事实并非如此。


DataBinding 是通过 “可观察数据 ObservableField” 在编译时与 XML 中对应 View 实例绑定,这使上文所述 “竖布局有 TextViewA 而横布局无” 情况下,有 TextViewA 即被绑定,无即无绑定,于是无论何种情况,都不至于 findViewById 拿到 Null 实例从而诱发 Null 安全问题。



也即,DataBinding 仅负责通知末端 View 状态改变,仅用于规避 Null 安全问题,不参与视图逻辑。而反向绑定是 “迁就” 这一结构的派生设计,非核心本质。



碍于篇幅限制,如这么说无体会,可参见《从被误解到 “真香” Jeptack DataBinding》解析,本文不再累述。



未卜先知 mBinding


除了本质难理解,DataBinding 也有硬伤,由于隔着一层 BindingAdapter,难获取 View 体系坐标等 getter 属性,乃至 “属性动画” 等框架难兼容。



有说 MotionLayout 可破此局,于多数场景轻松完成动画。


但它也非省油灯,不同时支持 Drag & Click,难实现我们 示例项目 “展开面板” 场景。



于是,DataBinding 做出 “违背祖宗” 决定 —— 允许开发者在 Java 代码中拿到 mBinding 乃至 View 实例 … 如此上一节提到的 “改用 ObservableField 的绑定来消除 Null 安全问题” 的努力前功尽弃。


—— 鉴于 App 页面并非总是 “横竖布局皆有”,于是开发者索性通过 “强制竖屏” 扼杀 View 实例 Null 安全隐患,而调用 mBinding 实例仅用于规避 findViewById 样板代码。



至于为何说 mBinding 使用即 “未卜先知”,因为群众智慧多年后即被应验。



力挽狂澜


官方牵头 Jetpack


时间回到 2017,这年 Google I/O 引入一系列 AAC(Android Architecture Components)


一举多得 ViewModel


其中 Jetpack ViewModel,通过支持 View 实例状态 “托管” 和 “保存恢复”,


一举解决 “高频痛点2:成员变量爆炸” 和 “高频痛点 3:状态管理一致性问题”,


Activity 成员变量表,一下简洁许多。Save & Restore 样板代码亦烟消云散。



半路杀出 Kotlin


并且这时期,Kotlin 被扶持为官方语言,背景发生剧变。


Kotlin 直接从语言层面支持 Null 安全,于是 DataBinding 在 Kotlin 项目式微。


喜闻乐见 ViewBinding


千呼万唤,ViewBinding 问世 2019。


如布局中 View 实例隐含 Null 安全隐患,则编译时 ViewBinding 中间代码为其生成 @Nullable 注解,使 Kotlin 开发过程中,Android Studio 自动提醒 “强制使用 Null 安全符”,由此确保 Null 安全一致。



ViewBinding 于 Kotlin 项目可平替 DataBinding,开发者喜闻乐见 mBinding 使用。


百花齐放


最佳实践 Jetpack MVVM


自 2017 年 AAC 问世,部分原生 Jetpack 架构组件至今仍存在设计隐患,


基于 “架构组件本质即解决一致性问题” 理解,我们于 2019 陆续将 “隐患组件” 改造和开源。


屏蔽回推 UnPeekLiveData


LiveData 是效仿响应式编程 BehaviorSubject 的设计,由于


1.Jetpack 架构示例通常只包含 “表现层” 和 “数据层” 两层,缺乏在 “领域层” 分发数据的工具,


2.LiveData Observer 的设计缺乏边界感,


容易让开发者误当做 “一次性事件分发组件” 来使用,造成订阅时 "自动回推脏数据";


容易让开发者误将同一控件实例放在多个 Observer 回调中 造成恢复状态时 “数据不一致” 等问题(具体可参见《MVI 的存在意义》 关于 “响应式编程漏洞” 的描述)


3.DataBinding ObservableField 组件的 Observer 能限定为 "与控件一对一绑定",更适合承担表现层 BehaviorSubject 工作,


4.LiveData 具备生命周期安全等优势,


因此决定将 LiveData 往领域层 PublishSubject 方向改造,去除其 “自动推送最后一次状态” 的能力,使其专职生命周期安全的数据分发。



具体可参见 Github:UnPeek-LiveData 使用。



消息分发 Dispatcher


由于 LiveData 存在的初衷并非是专业的 “一次性事件分发组件”,改造过的 UnPeekLiveData 也只适用于 “低频次数据分发(例如每秒推送 1 次)” 场景,


因而若想满足 “高频次事件分发” 需求(例如每秒推送 5 次以上),请改用或参考专职 “领域层” 数据分发的 Github:MVI-Dispatcher 组件,该组件内部通过消息队列设计,确保不漏掉每一次推送。




Dispatcher 的存在解决了 “高频痛点 4:消息分发一致性问题”,


也即通过在领域层设立 “专职业务处理和结果回推” 的 Dispatcher,来将业务处理过程中产生的 Event 或 State,以串流的方式统一从 output 出口回传,


由此表现层页面可根据消息的性质,采取 “一致性执行” 或 “交由 BehaviorSubject 托管状态”。


对此具体可参见《解决 MVI 架构实战痛点》 解析。



严格模式 DataBinding


此外我们明确约定 Java 下 DataBinding 使用原则,确保 100% Null 安全。如违背原则,便 Debug 模式下警告,方便开发者留意。



具体可参见 Github:KunMinX-MVVM 使用。



另起炉灶 Compose


回到文章开头 Canvas,为实现 View 实例 Null 安全,先是 DataBinding 框架,但它作为一框架,并不体系自洽,与 “属性动画” 等框架难兼容。


于是出现声明式 UI,通过函数式编程 “纯函数原子性” 解决 Null 安全一致。且体系自洽,动画无兼容问题,学习成本也低于 View 体系。


后续如性能全面跟上、120Hz 无压力,建议直接上手 Compose 开发。



注:关于声明式 UI 函数式编程本质,及纯函数原子性为何能实现 Null 安全一致,详见《一通百通 “声明式 UI” 扫盲干货》,本文不作累述。



综上


高频痛点1:Null 安全一致性问题


客户端,图形化,需 Canvas,


为避免接触 Canvas 导致不可预期错误,原生架构提供 View、Drawable 排版模板。


为解决 Java 下 View 实例 Null 安全一致性问题,引入 DataBinding。


但 DataBinding 仅是一框架,难体系自洽,


于是兵分两路,Kotlin + ViewBinding 或 Kotlin + Compose 取代 DataBinding。


高频痛点2:成员变量爆炸


高频痛点3:状态管理一致性问题


引入 Jetpack ViewModel,实现状态托管和保存恢复。


高频痛点4:消息分发一致性问题


引入 Dispatcher 承担 PublishSubject,实现统一的消息推送。


最后,天下无完美架构,唯有高频痛点熟稔于心,不断死磕精进,集思广益,迭代特定场景最优解。


相关资料


Canvas,View,Drawable,排版模板:《过目难忘 Android GUI 关系梳理》


DataBinding,Null 安全一致,ViewBinding:《从被误解到 “真香” Jetpack DataBinding》


Dispatcher,消息分发,State,Event:《解决 MVI 架构实战痛点》


架构组件解决一致性问题:《耳目一新 Jetpack MVVM 精讲》


Compose,纯函数原子性,Null 安全一致:《一通百通 “声明式 UI” 扫盲干货》


版权声明



Copyright © 2019-present KunMinX 原创版权所有。



如需 转载本文,或引用、借鉴 本文 “引言、思路、结论、配图” 进行二次创作发行,须注明链接出处,否则我们保留追责权利。


本文封面 Android 机器人是在 Google 原创及共享成果基础上再创作而成,遵照知识共享署名 3.0 许可所述条款付诸应用。


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

Kotlin 协程探索

Kotlin 协程是什么? 本文只是自己经过研究后,对 Kotlin 协程的理解概括,如有偏差,还请斧正。 简要概括: 协程是 Kotlin 提供的一套线程 API 框架,可以很方便的做线程切换。 而且在不用关心线程调度的情况下,能轻松的做并发编程。也可以说...
继续阅读 »

Kotlin 协程是什么?


本文只是自己经过研究后,对 Kotlin 协程的理解概括,如有偏差,还请斧正。


简要概括:



协程是 Kotlin 提供的一套线程 API 框架,可以很方便的做线程切换。 而且在不用关心线程调度的情况下,能轻松的做并发编程。也可以说协程就是一种并发设计模式。



下面是使用传统线程和协程执行任务:

       Thread{
//执行耗时任务
}.start()

val executors = Executors.newCachedThreadPool()
executors.execute {
//执行耗时任务
}

GlobalScope.launch(Dispatchers.IO) {
//执行耗时任务
}

在实际应用开发中,通常是在主线中去启动子线程执行耗时任务,等耗时任务执行完成,再将结果给主线程,然后刷新UI:

       Thread{
//执行耗时任务
runOnMainThread {
//获取耗时任务结果,刷新UI
}
}.start()

val executors = Executors.newCachedThreadPool()
executors.execute {
//执行耗时任务
runOnMainThread {
//获取耗时任务结果,刷新UI
}
}

Observable.unsafeCreate<Unit> {
//执行耗时任务
}.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()).subscribe {
//获取耗时任务结果,刷新UI
}

GlobalScope.launch(Dispatchers.Main) {
val result = withContext(Dispatchers.IO){
//执行耗时任务
}
//直接拿到耗时任务结果,刷新UI
refreshUI(result)
}

从上面可以看到,使用Java 的 ThreadExecutors 都需要手动去处理线程切换,这样的代码不仅不优雅,而且有一个重要问题,那就是要去处理与生命周期相关的上下文判断,这导致逻辑变复杂,而且容易出错。


RxJava 是一套优雅的异步处理框架,代码逻辑简化,可读性和可维护性都很高,很好的帮我们处理线程切换操作。这在 Java 语言环境开发下,是如虎添翼,但是在 Kotlin 语言环境中开发,如今的协程就比 RxJava 更方便,或者说更有优势。


下面看一个 Kotlin 中使用协程的例子:

        GlobalScope.launch(Dispatchers.Main) {
Log.d("TestCoroutine", "launch start: ${Thread.currentThread()}")
val numbersTo50Sum = withContext(Dispatchers.IO) {
//在子线程中执行 1-50 的自然数和
Log.d("TestCoroutine", "launch:numbersTo50Sum: ${Thread.currentThread()}")
delay(1000)
val naturalNumbers = generateSequence(0) { it + 1 }
val numbersTo50 = naturalNumbers.takeWhile { it <= 50 }
numbersTo50.sum()
}

val numbers50To100Sum = withContext(Dispatchers.IO) {
//在子线程中执行 51-100 的自然数和
Log.d("TestCoroutine", "launch:numbers50To100Sum: ${Thread.currentThread()}")
delay(1000)
val naturalNumbers = generateSequence(51) { it + 1 }
val numbers50To100 = naturalNumbers.takeWhile { it in 51..100 }
numbers50To100.sum()
}

val result = numbersTo50Sum + numbers50To100Sum
Log.d("TestCoroutine", "launch end:result=$result ${Thread.currentThread()}")
}
Log.d("TestCoroutine", "Hello World!,${Thread.currentThread()}")
控制台输出结果:
2023-01-02 16:05:45.846 10153-10153/com.wangjiang.example D/TestCoroutine: Hello World!,Thread[main,5,main]
2023-01-02 16:05:48.058 10153-10153/com.wangjiang.example D/TestCoroutine: launch start: Thread[main,5,main]
2023-01-02 16:05:48.059 10153-10322/com.wangjiang.example D/TestCoroutine: launch:numbersTo50Sum: Thread[DefaultDispatcher-worker-1,5,main]
2023-01-02 16:05:49.114 10153-10322/com.wangjiang.example D/TestCoroutine: launch:numbers50To100Sum: Thread[DefaultDispatcher-worker-1,5,main]
2023-01-02 16:05:50.376 10153-10153/com.wangjiang.example D/TestCoroutine: launch end:result=5050 Thread[main,5,main]

在上面的代码中:



  • launch 是一个函数,用于创建协程并将其函数主体的执行分派给相应的调度程序。

  • Dispatchers.MAIN 指示此协程应在为 UI 操作预留的主线程上执行。

  • Dispatchers.IO 指示此协程应在为 I/O 操作预留的线程上执行。

  • withContext(Dispatchers.IO) 将协程的执行操作移至一个 I/O 线程。


从控制台输出结果中,可以看出在计算 1-50 和 51-100 的自然数和的时候,线程是从主线程(Thread[main,5,main])切换到了协程的线程(DefaultDispatcher-worker-1,5,main),这里计算 1-50 和 51-100 都是同一个子线程。


在这里有一个重要的现象,代码从逻辑上看起来是同步的,并且启动协程执行任务的时候,没有阻塞主线程继续执行相关操作,而且在协程中的异步任务执行完成之后,又自动切回了主线程。这就是 Kotlin 协程给开发做并发编程带来的好处。这也是有个概念的来源: Kotlin 协程同步非阻塞


同步非阻塞”是真的“同步非阻塞” 吗?下面探究一下其中的猫腻,通过 Android Studio ,查看 .class 文件中的上面一段代码:

      BuildersKt.launch$default((CoroutineScope)GlobalScope.INSTANCE, (CoroutineContext)Dispatchers.getMain(), (CoroutineStart)null, (Function2)(new Function2((Continuation)null) {
int I$0;
int label;

@Nullable
public final Object invokeSuspend(@NotNull Object $result) {
Object var10000;
int numbersTo50Sum;
label17: {
Object var5 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
Function2 var10001;
CoroutineContext var6;
switch(this.label) {
case 0:
ResultKt.throwOnFailure($result);
Log.d("TestCoroutine", "launch start: " + Thread.currentThread());
var6 = (CoroutineContext)Dispatchers.getIO();
var10001 = (Function2)(new Function2((Continuation)null) {
int label;

@Nullable
public final Object invokeSuspend(@NotNull Object $result) {
Object var4 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
switch(this.label) {
case 0:
ResultKt.throwOnFailure($result);
Log.d("TestCoroutine", "launch:numbersTo50Sum: " + Thread.currentThread());
this.label = 1;
if (DelayKt.delay(1000L, this) == var4) {
return var4;
}
break;
case 1:
ResultKt.throwOnFailure($result);
break;
default:
throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}

Sequence naturalNumbers = SequencesKt.generateSequence(Boxing.boxInt(0), (Function1)null.INSTANCE);
Sequence numbersTo50 = SequencesKt.takeWhile(naturalNumbers, (Function1)null.INSTANCE);
return Boxing.boxInt(SequencesKt.sumOfInt(numbersTo50));
}

@NotNull
public final Continuation create(@Nullable Object value, @NotNull Continuation completion) {
Intrinsics.checkNotNullParameter(completion, "completion");
Function2 var3 = new <anonymous constructor>(completion);
return var3;
}

public final Object invoke(Object var1, Object var2) {
return ((<undefinedtype>)this.create(var1, (Continuation)var2)).invokeSuspend(Unit.INSTANCE);
}
});
this.label = 1;
var10000 = BuildersKt.withContext(var6, var10001, this);
if (var10000 == var5) {
return var5;
}
break;
case 1:
ResultKt.throwOnFailure($result);
var10000 = $result;
break;
case 2:
numbersTo50Sum = this.I$0;
ResultKt.throwOnFailure($result);
var10000 = $result;
break label17;
default:
throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}

numbersTo50Sum = ((Number)var10000).intValue();
var6 = (CoroutineContext)Dispatchers.getIO();
var10001 = (Function2)(new Function2((Continuation)null) {
int label;

@Nullable
public final Object invokeSuspend(@NotNull Object $result) {
Object var4 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
switch(this.label) {
case 0:
ResultKt.throwOnFailure($result);
Log.d("TestCoroutine", "launch:numbers50To100Sum: " + Thread.currentThread());
this.label = 1;
if (DelayKt.delay(1000L, this) == var4) {
return var4;
}
break;
case 1:
ResultKt.throwOnFailure($result);
break;
default:
throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}

Sequence naturalNumbers = SequencesKt.generateSequence(Boxing.boxInt(51), (Function1)null.INSTANCE);
Sequence numbers50To100 = SequencesKt.takeWhile(naturalNumbers, (Function1)null.INSTANCE);
return Boxing.boxInt(SequencesKt.sumOfInt(numbers50To100));
}

@NotNull
public final Continuation create(@Nullable Object value, @NotNull Continuation completion) {
Intrinsics.checkNotNullParameter(completion, "completion");
Function2 var3 = new <anonymous constructor>(completion);
return var3;
}

public final Object invoke(Object var1, Object var2) {
return ((<undefinedtype>)this.create(var1, (Continuation)var2)).invokeSuspend(Unit.INSTANCE);
}
});
this.I$0 = numbersTo50Sum;
this.label = 2;
var10000 = BuildersKt.withContext(var6, var10001, this);
if (var10000 == var5) {
return var5;
}
}

int numbers50To100Sum = ((Number)var10000).intValue();
int result = numbersTo50Sum + numbers50To100Sum;
Log.d("TestCoroutine", "launch end:result=" + result + ' ' + Thread.currentThread());
return Unit.INSTANCE;
}

@NotNull
public final Continuation create(@Nullable Object value, @NotNull Continuation completion) {
Intrinsics.checkNotNullParameter(completion, "completion");
Function2 var3 = new <anonymous constructor>(completion);
return var3;
}

public final Object invoke(Object var1, Object var2) {
return ((<undefinedtype>)this.create(var1, (Continuation)var2)).invokeSuspend(Unit.INSTANCE);
}
}), 2, (Object)null);
Log.d("TestCoroutine", "Hello World!," + Thread.currentThread());

虽然上面 .class 文件中的代码比较复杂,但是从大体逻辑可以看出,Kotlin 协程也是通过回调接口来实现异步操作的,这也解释了 Kotlin 协程只是让代码逻辑是同步非阻塞,但是实际上并没有,只是 Kotlin 编译器为代码做了很多事情,这也是说 Kotlin 协程其实就是一套线程 API 框架的原因。


再看一个上面例子的变种:

        GlobalScope.launch(Dispatchers.Main) {
Log.d("TestCoroutine", "launch start: ${Thread.currentThread()}")
val numbersTo50Sum = async {
withContext(Dispatchers.IO) {
Log.d("TestCoroutine", "launch:numbersTo50Sum: ${Thread.currentThread()}")
delay(2000)
val naturalNumbers = generateSequence(0) { it + 1 }
val numbersTo50 = naturalNumbers.takeWhile { it <= 50 }
numbersTo50.sum()
}
}

val numbers50To100Sum = async {
withContext(Dispatchers.IO) {
Log.d("TestCoroutine", "launch:numbers50To100Sum: ${Thread.currentThread()}")
delay(500)
val naturalNumbers = generateSequence(51) { it + 1 }
val numbers50To100 = naturalNumbers.takeWhile { it in 51..100 }
numbers50To100.sum()
}
}
// 计算 1-50 和 51-100 的自然数和是两个并发操作
val result = numbersTo50Sum.await() + numbers50To100Sum.await()
Log.d("TestCoroutine", "launch end:result=$result ${Thread.currentThread()}")
}
Log.d("TestCoroutine", "Hello World!,${Thread.currentThread()}")

控制台输出结果:
2023-01-02 16:32:12.637 13303-13303/com.wangjiang.example D/TestCoroutine: Hello World!,Thread[main,5,main]
2023-01-02 16:32:13.120 13303-13303/com.wangjiang.example D/TestCoroutine: launch start: Thread[main,5,main]
2023-01-02 16:32:14.852 13303-13444/com.wangjiang.example D/TestCoroutine: launch:numbersTo50Sum: Thread[DefaultDispatcher-worker-2,5,main]
2023-01-02 16:32:14.853 13303-13443/com.wangjiang.example D/TestCoroutine: launch:numbers50To100Sum: Thread[DefaultDispatcher-worker-1,5,main]
2023-01-02 16:32:17.462 13303-13303/com.wangjiang.example D/TestCoroutine: launch end:result=5050 Thread[main,5,main]

async 创建了一个协程,它让计算 1-50 和 51-100 的自然数和是两个并发操作。上面控制台输出结果可以看到计算 1-50 的自然数和是在线程 Thread[DefaultDispatcher-worker-2,5,main] 中,而计算 51-100 的自然数和是在另一个线程Thread[DefaultDispatcher-worker-1,5,main]中。


从上面的例子,协程在异步操作,也就是线程切换上:主线程启动子线程执行耗时操作,耗时操作执行完成将结果更新到主线程的过程中,代码逻辑简化,可读性高。


suspend 是什么?


suspend 直译就是:挂起


suspend 是 Kotlin 语言中一个 关键字,用于修饰方法,当修饰方法时,表示这个方法只能被 suspend 修饰的方法调用或者在协程中被调用。


下面看一下将上面代码案例拆分成几个 suspend 方法:

    fun getNumbersTo100Sum() {
GlobalScope.launch(Dispatchers.Main) {
Log.d("TestCoroutine", "launch start: ${Thread.currentThread()}")
val result = calcNumbers1To100Sum()
Log.d("TestCoroutine", "launch end:result=$result ${Thread.currentThread()}")
}
Log.d("TestCoroutine", "Hello World!,${Thread.currentThread()}")
}

private suspend fun calcNumbers1To100Sum(): Int {
return calcNumbersTo50Sum() + calcNumbers50To100Sum()
}

private suspend fun calcNumbersTo50Sum(): Int {
return withContext(Dispatchers.IO) {
Log.d("TestCoroutine", "launch:numbersTo50Sum: ${Thread.currentThread()}")
delay(1000)
val naturalNumbers = generateSequence(0) { it + 1 }
val numbersTo50 = naturalNumbers.takeWhile { it <= 50 }
numbersTo50.sum()
}
}

private suspend fun calcNumbers50To100Sum(): Int {
return withContext(Dispatchers.IO) {
Log.d("TestCoroutine", "launch:numbers50To100Sum: ${Thread.currentThread()}")
delay(1000)
val naturalNumbers = generateSequence(51) { it + 1 }
val numbers50To100 = naturalNumbers.takeWhile { it in 51..100 }
numbers50To100.sum()
}
}
控制台输出结果:
2023-01-03 14:47:57.047 11349-11349/com.wangjiang.example D/TestCoroutine: Hello World!,Thread[main,5,main]
2023-01-03 14:47:59.311 11349-11349/com.wangjiang.example D/TestCoroutine: launch start: Thread[main,5,main]
2023-01-03 14:47:59.312 11349-11537/com.wangjiang.example D/TestCoroutine: launch:numbersTo50Sum: Thread[DefaultDispatcher-worker-3,5,main]
2023-01-03 14:48:00.336 11349-11535/com.wangjiang.example D/TestCoroutine: launch:numbers50To100Sum: Thread[DefaultDispatcher-worker-1,5,main]
2023-01-03 14:48:01.339 11349-11349/com.wangjiang.example D/TestCoroutine: launch end:result=5050 Thread[main,5,main]

suspend 关键字标记方法时,其实是告诉 Kotlin 从协程内调用方法。所以这个“挂起”,并不是说方法或函数被挂起,也不是说线程被挂起


假设一个非 suspend 修饰的方法调用 suspend 修饰的方法会怎么样呢?

  private fun calcNumbersTo100Sum(): Int {
return calcNumbersTo50Sum() + calcNumbers50To100Sum()
}

此时,编译器会提示:

Suspend function 'calcNumbersTo50Sum' should be called only from a coroutine or another suspend function
Suspend function 'calcNumbers50To100' should be called only from a coroutine or another suspend function

下面查看 .class 文件中的上面方法 calcNumbers50To100Sum 代码:

   private final Object calcNumbers50To100Sum(Continuation $completion) {
return BuildersKt.withContext((CoroutineContext)Dispatchers.getIO(), (Function2)(new Function2((Continuation)null) {
int label;

@Nullable
public final Object invokeSuspend(@NotNull Object $result) {
Object var4 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
switch(this.label) {
case 0:
ResultKt.throwOnFailure($result);
Log.d("TestCoroutine", "launch:numbers50To100Sum: " + Thread.currentThread());
this.label = 1;
if (DelayKt.delay(1000L, this) == var4) {
return var4;
}
break;
case 1:
ResultKt.throwOnFailure($result);
break;
default:
throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}

Sequence naturalNumbers = SequencesKt.generateSequence(Boxing.boxInt(51), (Function1)null.INSTANCE);
Sequence numbers50To100 = SequencesKt.takeWhile(naturalNumbers, (Function1)null.INSTANCE);
return Boxing.boxInt(SequencesKt.sumOfInt(numbers50To100));
}

@NotNull
public final Continuation create(@Nullable Object value, @NotNull Continuation completion) {
Intrinsics.checkNotNullParameter(completion, "completion");
Function2 var3 = new <anonymous constructor>(completion);
return var3;
}

public final Object invoke(Object var1, Object var2) {
return ((<undefinedtype>)this.create(var1, (Continuation)var2)).invokeSuspend(Unit.INSTANCE);
}
}), $completion);
}

可以看到 private suspend fun calcNumbers50To100Sum() 经过 Kotlin 编译器编译后变成了private final Object calcNumbers50To100Sum(Continuation $completion)suspend 消失了,方法多了一个参数 Continuation $completion,所以 suspend修饰 Kotlin 的方法或函数,编译器会对此方法做特殊处理。


另外,suspend 修饰的方法,也预示着这个方法是耗时方法,告诉方法调用者要使用协程。当执行 suspend 方法,也预示着要切换线程,此时主线程依然可以继续执行,而协程里面的代码可能被挂起了。


下面再稍为修改 calcNumbers50To100Sum 方法:

   private suspend fun calcNumbers50To100Sum(): Int {
Log.d("TestCoroutine", "launch:numbers50To100Sum:start: ${Thread.currentThread()}")
val sum= withContext(Dispatchers.Main) {
Log.d("TestCoroutine", "launch:numbers50To100Sum: ${Thread.currentThread()}")
delay(1000)
val naturalNumbers = generateSequence(51) { it + 1 }
val numbers50To100 = naturalNumbers.takeWhile { it in 51..100 }
numbers50To100.sum()
}
Log.d("TestCoroutine", "launch:numbers50To100Sum:end: ${Thread.currentThread()}")
return sum
}
控制台输出结果:
2023-01-03 15:28:04.349 15131-15131/com.bilibili.studio D/TestCoroutine: Hello World!,Thread[main,5,main]
2023-01-03 15:28:04.803 15131-15131/com.bilibili.studio D/TestCoroutine: launch start: Thread[main,5,main]
2023-01-03 15:28:04.804 15131-15266/com.bilibili.studio D/TestCoroutine: launch:numbersTo50Sum: Thread[DefaultDispatcher-worker-3,5,main]
2023-01-03 15:28:06.695 15131-15131/com.bilibili.studio D/TestCoroutine: launch:numbers50To100Sum:start: Thread[main,5,main]
2023-01-03 15:28:06.696 15131-15131/com.bilibili.studio D/TestCoroutine: launch:numbers50To100Sum: Thread[main,5,main]
2023-01-03 15:28:07.700 15131-15131/com.bilibili.studio D/TestCoroutine: launch:numbers50To100Sum:end: Thread[main,5,main]
2023-01-03 15:28:07.700 15131-15131/com.bilibili.studio D/TestCoroutine: launch end:result=5050 Thread[main,5,main]

主线程不受协程线程的影响。


总结


Kotlin 协程是一套线程 API 框架,在 Kotlin 语言环境下使用它做并发编程比传统 Thread, Executors 和 RxJava 更有优势,代码逻辑上“同步非阻塞“,而且简洁,易阅读和维护。


suspend 是 Kotlin 语言中一个关键字,用于修饰方法,当修饰方法时,该方法只能被 suspend 修饰的方法和协程调用。此时,也预示着该方法是一个耗时方法,告诉调用者需要在协程中使用。


参考文档:



  1. Android 上的 Kotlin 协程

  2. Coroutines guide


下一篇,将研究 Kotlin Flow。


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

如何不依着惯性做事

文章从一个小和尚的故事开始。 在一个古老的寺庙里,住着一位小和尚,每天的任务就是从山下的小溪里挑水到山上的寺庙。小和尚每天日出而作,日落而息,用他的小木桶,一次又一次地从山下挑水到山上,生活在这种重复中过去了好多年。 有一天,小和尚遇到了一个问题,随着寺庙里的...
继续阅读 »

文章从一个小和尚的故事开始。


在一个古老的寺庙里,住着一位小和尚,每天的任务就是从山下的小溪里挑水到山上的寺庙。小和尚每天日出而作,日落而息,用他的小木桶,一次又一次地从山下挑水到山上,生活在这种重复中过去了好多年。


有一天,小和尚遇到了一个问题,随着寺庙里的弟子越来越多,他一个人挑水已经无法满足大家的需求了。他感到非常焦虑,但加快了挑水的速度,每天几乎都精疲力尽。然而,无论他多么努力,总是无法满足大家的需求。


这一天老和尚问小和尚:「你为什么不想想看,有没有更好的方法来解决这个问题呢?」


小和尚一愣,他才意识到,他一直都是在埋头做事,从未想过有其他的方法。


于是,小和尚开始思考,他观察发现,从山上到山下有一条小溪,而这条小溪的水源就是他每天去挑水的地方。他萌生了一个念头,为何不直接将山下的水引到山上来呢?


于是,小和尚开始行动,他用竹子和石头制作了一套简单的引水系统,经过数天的努力,他成功地将水从山下引到了山上的寺庙。从此,他不再需要每天辛苦地挑水,寺庙里的水源也变得更加充足。


这个 AI 写的小故事虽然有点浅,但也告诉我们,在生活和工作中,往往会习惯性地使用过去的方法和思维模式,而忽视了其他可能的解决方案。只有当我们打破惯性,从新的角度去思考问题,才能找到更好的解决方法,实现真正的创新和突破。


这也是我们今天要聊的「如何不依着惯性做事」。


1 定义


咱们先从定义开始。




  • 惯性:惯性原本是物理学中的一个概念,指的是物体在没有受到外力作用时,静止的物体保持静止,运动的物体保持匀速直线运动的状态。在这里,我们将惯性的概念引申到思维和行为上,表示一种习惯性的思考和行动方式,倾向于维持现状,抵制改变。




  • 思维惯性:思维惯性是指个体在思考问题和决策过程中,容易受到过去经验和认知的影响,导致思维和判断受限,难以接受新观念和变革。这种现象使得人们在面对新旧问题和挑战时,容易陷入固定思维模式,缺乏创新和灵活性。




  • 依着惯性做事:依着惯性做事是指在工作和生活中,人们习惯于沿用过去的方式和方法,对新的观念和变革持保守态度,不愿意主动寻求改进和创新。这种行为方式往往会导致效率低下、缺乏竞争力,甚至无法适应不断变化的环境。




2 惯性的好与坏


辩证的看,依着惯性做事有好有坏。在某些情况下,惯性思维和行为可能有利于保持稳定和效率。然而,在其他情况下,过于依赖惯性可能会限制创新和发展。我们需要客观地评价惯性思维对于特定情境的影响,以便在恰当的时机采取适当的行动。


优点如下:




  • 保持稳定:惯性思维和行为有助于维持现状,确保日常工作的稳定进行。在某些情况下,这可能有助于降低风险和不确定性。




  • 提高效率:对于一些已经经过优化的任务和流程,遵循惯例可能会提高工作效率。在这些情况下,尝试新的方法可能会浪费时间和资源。




  • 简化决策:依赖惯性可以简化决策过程,减少思考和计划的时间。这在面临紧迫的截止日期或资源有限的情况下可能有一定优势。




缺点如下:




  • 限制创新:过度依赖惯性会阻碍创新和改进,导致陈旧的观念和方法得以延续。这可能会让我们错过新的机遇和发展潜力。




  • 降低适应能力:在不断变化的市场和技术环境中,过于依赖惯性可能导致我们在应对新挑战时缺乏灵活性和适应能力。




  • 忽视潜在问题:依赖惯性做事可能让我们忽视潜在的问题和风险。在这些情况下,持续改进和调整可能更加重要。




我们需要在不同的情境下权衡惯性思维和行为的利弊。在某些情况下,遵循惯例可能是合理的选择;而在其他情况下,我们需要挑战惯性,寻求创新和改进。关键在于识别何时应该保持现状,何时应该追求变革。


保持惯性大多数人可以做到,今天我们要聊的是如何打破惯性,不依着惯性做事,因为能够用打破惯性,突破常规的人毕竟是少数。


3 如何不依着惯性做事


在个人的认知中,有一个原理和一个架构能在一定程度上打破惯性。他们是「第一性原理」和「四项行动架构」。


3.1 第一性原理


3.1.1 第一性原理简介


第一性原理是指将问题拆解到最基本的事实或原则,然后从这些基本事实出发来重新构建问题的解决方案。在解决问题和制定决策时,从第一性原理出发,有助于深入挖掘问题的本质,避免受到惯性思维的限制。


3.1.2 如何运用第一性原理


运用第一性原理规避惯性思维可以采用以下的 4 个步骤:




  1. 拆解问题:将问题拆解到最基本的事实或原则,剥离掉惯性思维带来的先入为主的观念和偏见。




  2. 重新构建解决方案:基于拆解后的基本事实,从零开始思考问题的解决方案,避免受到过往经验和传统观念的束缚。




  3. 鼓励创新:以第一性原理为指导,积极探索新的解决方案,提高创新能力和应对变革的能力。




  4. 实事求是:第一性原理要求我们在思考问题时,始终以事实为依据,避免陷入惯性思维的主观判断。




3.1.3 应用实例


以输出质量报告为例,如何应用第一性原理呢?


当我们谈论编写质量报告时,通常会按照固定的模板或流程进行,这是惯性思维的体现。然而,当我们想要打破惯性,提升报告的质量和有效性时,我们可以尝试以下策略:




  1. 反思报告的目标:通常,我们按照惯性写报告,可能因为这是例行公事,或者是因为上级要求。但是,如果我们从第一性原理思考,报告的真正目标是什么?是传达信息,是指导行动,还是促进决策?明确目标后,我们可能需要对报告的结构、内容甚至呈现方式进行改变,以更好地达成目标。




  2. 重新审视数据和信息:在收集和呈现数据时,我们往往依赖于固定的方式和工具,如表格、图表等。但是,这样真的能有效地传达信息吗?如果我们打破惯性,尝试新的数据分析和可视化工具,可能会发现更深入、更直观的洞察,从而更好地支持报告的目标。




  3. 采用迭代的方式编写报告:依照惯性,我们可能会一次性完成报告的编写,然后提交。但是,如果我们采取迭代的方式,先编写一个初稿,然后进行反馈、修订,再反馈、修订,这样可能会花费更多的时间,但最终的报告可能会更准确、更有洞见。




  4. 引入跨领域的视角:我们通常会从自己的专业角度编写报告,但是如果我们引入其他领域的视角,比如用户体验、商业模式等,可能会发现一些意想不到的洞见,这也是打破惯性的一种方式。




3.2 四项行动架构


金教授和莫博涅教授提出的「四项行动架构」是一个用于挑战现有商业模式和行业战略逻辑的工具。其最开始出处是蓝海战略,来自《蓝海战略》一书,它通过改变现有的商业模式来区分与竞争对手的模式,从而创造出新的行业。


3.2.1 四项行动架构简介


四项行动架构主要包含以下四个关键问题,通过这四个问题挑战一个行业的战略逻辑和现行的商业模式:




  1. 删除:在我们的产品、服务或流程中,哪些被视为理所当然的元素其实可以删除?




  2. 减少:哪些元素我们可以大幅度削减,使其低于行业标准?




  3. 提升:哪些元素我们可以大幅度提升,使其高于行业标准?




  4. 创新:哪些从未在我们的产品、服务或流程中出现过的元素值得创新引入?




3.2.2 四项行动架构应用实例


在带技术团队过程中,我们也可以应用「四项行动架构」来打破惯性,以挑战技术团队的做事逻辑和现行的工作模式:



  1. 删除:技术团队中哪些看起来理所当然的要素应该被删除?




  • 可以考虑减少过多的会议和报告,将精力集中在实际的技术开发和创新上。




  • 去除过时的技术和方法,避免拖慢团队的发展速度。




  • 削减在某些环节的过度管理,让团队成员有更多自主权和创新空间。




如取消每周的固定例会,改为根据项目进度和团队需求灵活安排讨论和分享会。



  1. 消减:哪些要素应该被大幅削减到行业标准之下?




  • 减少冗余的代码审查和质量控制流程,以提高团队的工作效率。




  • 精简项目管理流程,减少不必要的文档和审批环节。




如将代码审查流程简化为一次轮流审查,而不是多次审查。



  1. 提升:哪些要素应该大幅提升到行业标准之上?




  • 加大对新技术和方法的投入,以求在行业中领先地位。




  • 提高团队成员的技能培训和成长机会,以便团队更好地适应市场变化。




如为团队成员提供更多的技术培训和参加行业大会的机会,以便他们能跟上技术的最新发展。



  1. 创造:哪些行业中从未提供的要素是应该被创造出来的?




  • 开发独特的技术解决方案,为客户创造更大的价值。




  • 创造新的合作模式,跨部门和跨行业合作,以实现技术的广泛应用。




如开发一款能够实时分析用户行为的工具,以便为客户提供更精准的个性化推荐服务。


通过运用这个四项行动架构,技术团队可以挑战现有的做事逻辑和工作模式,实现价值创新。这将有助于提高团队的竞争力,为公司创造更大的价值。


4 应用在技术团队管理


4.1 应用方法:「解脱」


打破惯性的常用方法我称之为「解脱」,从一个惯性中解脱出来。


解脱看到背后的真实,透过真实,把全部的惯性打破,也就自然而然地走出来了。


一般我们会基于意识到问题、解决问题和透过真实来不依着惯性做事,我们可以遵循以下步骤:




  1. 意识到问题:在日常工作中,关注自己的行为和思维模式。观察是否存在惯性思维,例如对新观念的排斥、抵制变革或过于依赖过去的经验。当我们意识到这些问题时,就迈出了第一步。




  2. 深入了解问题:分析惯性思维的来源,可能来自个人经验、团队文化或行业惯例。了解问题背后的原因有助于我们制定更有效的解决方案。




  3. 寻求解决方案:针对发现的问题,积极寻求创新性和实用性的解决方案。这可能包括改变思维模式、学习新技能、尝试新方法或调整工作流程。




  4. 解脱:在实践新方案的过程中,逐步摆脱惯性思维的束缚。这可能需要时间和努力,但随着不断的尝试和改进,我们会越来越不依赖惯性。




  5. 看到背后的真实:透过表面现象,关注背后的实质和深层次需求。这有助于我们更好地理解问题,找到更有效的解决方案。




  6. 持续改进:在摆脱惯性思维的过程中,保持对问题的关注和反思。不断学习和成长,培养开放、创新和挑战的心态。




通过以上六个步骤,我们可以逐渐摆脱惯性思维,实现真正的自我解脱。在这个过程中,我们需要保持耐心和毅力,不断努力提升自己的认知水平和能力,以达到更好的工作成果。


4.2 应用实践


我们以常见的问题解决方式和团队沟通为例看一下如何应用「解脱」


4.2.1 问题解决方式




  1. 意识到问题:观察团队成员在解决问题时是否习惯于采用已知的方法和经验,而忽视了其他可能的解决方案。




  2. 深入了解问题:可能是因为团队文化倾向于避免冒险,或者团队成员没有足够的技能或知识去尝试新的方法。




  3. 寻求解决方案:可以通过培训和学习,提升团队成员的技能和知识,鼓励他们在解决问题时尝试多种可能的解决方案。




  4. 解脱:在实践中,尝试新的方法和技术,逐步摆脱对过去经验的依赖。




  5. 看到背后的真实:意识到问题解决的本质是创新和改进,而不仅仅是应用已知的方法。




  6. 持续改进:在实践中,不断反思和改进,培养开放和创新的心态。




4.2.2 团队沟通




  1. 意识到问题:注意到团队成员是否在沟通中经常遇到障碍,比如信息传递不畅、沟通效率低下等。




  2. 深入了解问题:可能是因为沟通方式过于传统,比如过度依赖会议,而忽视了其他可能的沟通方式。




  3. 寻求解决方案:可以尝试新的沟通方式,比如异步沟通、立即反馈、跨部门沟通等。




  4. 解脱:在实践中,尝试新的沟通方式,逐步摆脱传统的沟通模式。




  5. 看到背后的真实:理解到沟通的本质是传递和理解信息,而不是遵循某种固定的方式。




  6. 持续改进:在实践中,不断反思和改进沟通方式,提高沟通的效率和效果。




这样的思考和实践,可以应用到技术团队管理的所有方面,包括任务分配、技术选型、项目管理等。关键是要有意识地发现和打破惯性,以创新和改进的心态去面对问题和挑战。


5 小结


小结一下,在上面的文章中我们探讨了惯性思维的利弊,尤其强调了依赖惯性思维可能对创新和发展产生限制。提出两种打破惯性思维的方法:「第一性原理」和「四项行动架构」。第一性原理鼓励我们将问题拆解到最基本的事实或原则,然后从这些基本事实出发重新构建解决方案;而四项行动架构则挑战现有商业模式和行业战略逻辑,包括"删除"、"减少"、"提升"和"创新"四个关键问题。最后详细阐述了如何在技术团队管理中应用这些方法,通过一个被称为「解脱」的过程来

作者:潘锦
来源:juejin.cn/post/7234887157000650810
摆脱惯性思维的束缚。

收起阅读 »

电视剧里的代码真能运行吗?

​大家好,欢迎来到 Crossin的编程教室 ! 前几天,后台老有小伙伴留言“爱心代码”。这不是Crossin很早之前发过的内容嘛,怎么最近突然又被人翻出来了?后来才知道 ,原来是一部有关程序员的青春偶像剧《点燃我,温暖你》在热播,而剧中有一段关于期中考试要用...
继续阅读 »

​大家好,欢迎来到 Crossin的编程教室 !


前几天,后台老有小伙伴留言“爱心代码”。这不是Crossin很早之前发过的内容嘛,怎么最近突然又被人翻出来了?后来才知道


,原来是一部有关程序员的青春偶像剧《点燃我,温暖你》在热播,而剧中有一段关于期中考试要用程序画一个爱心的桥段。


于是出于好奇,Crossin就去看了这一集(第5集,不用谢)。这一看不要紧,差点把刚吃的鸡腿给喷出来--槽点实在太多了!


忍不住做了个欢乐吐槽向的代码解读视频,在某平台上被顶到了20个w的浏览,也算蹭了一波人家电视剧的热度吧……


下面是图文版,给大家分析下剧中出现的“爱心”代码,并且来复刻一下最后男主完成的酷炫跳动爱心。


剧中代码赏析


1. 首先是路人同学的代码:



虽然剧中说是“C语言期中考试”,但这位同学的代码名叫 draw2.py,一个典型的 Python 文件,再结合截图中的 pen.forward、pen.setpos 等方法来看,应该是用 turtle 海龟作图库来画爱心。那效果通常是这样的:


import turtle as t
t.color('red')
t.setheading(50)
t.begin_fill()
t.circle(-100, 170)
t.circle(-300, 40)
t.right(38)
t.circle(-300, 40)
t.circle(-100, 170)
t.end_fill()
t.done()



而不是剧中那个命令行下用1组成的不规则的图形。


2. 然后是课代表向路人同学展示的优秀代码:



及所谓的效果:



这确实是C语言代码了,但文件依然是以 .py 为后缀,并且 include 前面没有加上 #,这显然是没法运行的。


里面的内容是可以画出爱心的,用是这个爱心曲线公式:



然后遍历一个15*17的方阵,计算每个坐标是在曲线内还是曲线外,在内部就输出#或*,外部就是-


用python改写一下是这样的:


for y in range(9, -6, -1):
for x in range(-8, 9):
print('*##*'[(x+10)%4] if (x*x+y*y-25)**3 < 25*x*x*y*y*y else '-', end=' ')
print()

​​​​​​效果:



稍微改一下输出,还能做出前面那个全是1的效果:


for y in range(9, -6, -1):
for x in range(-8, 9):
print('1' if (x*x+y*y-25)**3 < 25*x*x*y*y*y else ' ', end=' ')
print()


但跟剧中所谓的效果相去甚远。


3. 最后是主角狂拽酷炫D炸天的跳动爱心:



代码有两个片段:




但这两个片段也不C语言,而是C++,且两段并不是同一个程序,用的方法也完全不一样。


第一段代码跟前面一种思路差不多,只不过没有直接用一条曲线,而是上半部用两个圆形,下半部用两条直线,围出一个爱心。



改写成 Python 代码:


size = 10
for x in range(size):
for y in range(4*size+1):
dist1 = ((x-size)**2 + (y-size)**2) ** 0.5
dist2 = ((x-size)**2 + (y-3*size)**2) ** 0.5
if dist1 < size + 0.5 or dist2 < size + 0.5:
print('V', end=' ')
else:
print(' ', end=' ')
print()

for x in range(1, 2*size):
for y in range(x):
print(' ', end=' ')
for y in range(4*size+1-2*x):
print('V', end=' ')
print()

运行效果:



第二段代码用的是基于极坐标的爱心曲线,是遍历角度来计算点的位置。公式是:



计算出不同角度对应的点坐标,然后把它们连起来,就是一个爱心。


from math import pi, sin, cos
import matplotlib.pyplot as plt
no_pieces = 100
dt = 2*pi/no_pieces
t = 0
vx = []
vy = []
while t <= 2*pi:
vx.append(16*sin(t)**3)
vy.append(13*cos(t)-5*cos(2*t)-2*cos(3*t)-cos(4*t))
t += dt
plt.plot(vx, vy)
plt.show()

效果:



代码中循环时用到的2π是为了保证曲线长度足够绕一个圈,但其实长一点也无所谓,即使 π=100 也不影响显示效果,只是相当于同一条曲线画了很多遍。所以剧中代码里写下35位小数的π,还被女主用纸笔一字不落地抄写下来,实在是让程序员无法理解的迷惑行为。



但不管写再多位的π,上述两段代码都和最终那个跳动的效果差了五百只羊了个羊。


跳动爱心实现


作为一个总是在写一些没什么乱用的代码的编程博主,Crossin当然也不会放过这个机会,下面就来挑战一下用 Python 实现最终的那个效果。


1. 想要绘制动态的效果,必定要借助一些库的帮助,不然代码量肯定会让你感动得想哭。这里我们将使用之前 羊了个羊游戏 里用过的 pgzero 库。然后结合最后那个极坐标爱心曲线代码,先绘制出曲线上离散的点。


import pgzrun
from math import pi, sin, cos

no_p = 100
dt = 2*3/no_p
t = 0
x = []
y = []
while t <= 2*3:
x.append(16*sin(t)**3)
y.append(13*cos(t)-5*cos(2*t)-2*cos(3*t)-cos(4*t))
t += dt

def draw():
screen.clear()
for i in range(len(x)):
screen.draw.filled_rect(Rect((x[i]*10+400, -y[i]*10+300), (4, 4)), 'pink')

pgzrun.go()


2. 把点的数量增加,同时沿着原点到每个点的径向加一个随机数,并且这个随机数是按照正态分布来的(半个正态分布),大概率分布在曲线上,向曲线内部递减。这样,就得到这样一个随机分布的爱心效果。


...
no_p = 20000
...
while t <= 2*pi:
l = 10 - abs(random.gauss(10, 2) - 10)
x.append(l*16*sin(t)**3)
y.append(l*(13*cos(t)-5*cos(2*t)-2*cos(3*t)-cos(4*t)))
t += dt
...


3. 下面就是让点动起来,这步是关键,也有一点点复杂。为了方便对于每个点进行控制,这里将每个点自定义成了一个Particle类的实例。


从原理上来说,就是给每个点加一个缩放系数,这个系数是根据时间变化的正弦函数,看起来就会像呼吸的节律一样。


class Particle():
def __init__(self, pos, size, f):
self.pos = pos
self.pos0 = pos
self.size = size
self.f = f

def draw(self):
screen.draw.filled_rect(Rect((10*self.f*self.pos[0] + 400, -10*self.f*self.pos[1] + 300), self.size), 'hot pink')

def update(self, t):
df = 1 + (2 - 1.5) * sin(t * 3) / 8
self.pos = self.pos0[0] * df, self.pos0[1] * df

...

t = 0
def draw():
screen.clear()
for p in particles:
p.draw()

def update(dt):
global t
t += dt
for p in particles:
p.update(t)


4. 剧中爱心跳动时,靠中间的点波动的幅度更大,有一种扩张的效果。所以再根据每个点距离原点的远近,再加上一个系数,离得越近,系数越大。


class Particle():
...
def update(self, t):
df = 1 + (2 - 1.5 * self.f) * sin(t * 3) / 8
self.pos = self.pos0[0] * df, self.pos0[1] * df


5. 最后再用同样的方法画一个更大一点的爱心,这个爱心不需要跳动,只要每一帧随机绘制就可以了。


def draw():
...
t =
0
while t < 2*pi:
f = random.gauss(1.1, 0.1)
x = 16*sin(t)**3
y = 13*cos(t)-5*cos(2*t)-2*cos(3*t)-cos(4*t)
size = (random.uniform(0.5,2.5), random.uniform(0.5,2.5))
screen.draw.filled_rect(Rect((10*f*x + 400, -10*f*y + 300), size), 'hot pink')
t += dt * 3


合在一起,搞定!



总结一下,就是在原本的基础爱心曲线上加上一个正态分布的随机量、一个随时间变化的正弦函数和一个跟距离成反比的系数,外面再套一层更大的随机爱心,就得到类似剧中的跳动爱心效果。


但话说回来,真有人会在考场上这么干吗?


除非真的是超级大学霸,不然就是食堂伙食太好--


吃太饱撑的……



代码已开源:python666.cn/c/9


如二创发布请注明代码来源:Crossin的编程教室



作者:Crossin先生
来源:juejin.cn/post/7168388057631031332
收起阅读 »

基于人脸识别算法的考勤系统

​ 作为一个基于人脸识别算法的考勤系统的设计与实现教程,以下内容将提供详细的步骤和代码示例。本教程将使用 Python 语言和 OpenCV 库进行实现。 一、环境配置 安装 Python 请确保您已经安装了 Python 3.x。可以在Python 官网...
继续阅读 »


作为一个基于人脸识别算法的考勤系统的设计与实现教程,以下内容将提供详细的步骤和代码示例。本教程将使用 Python 语言和 OpenCV 库进行实现。


一、环境配置



  1. 安装 Python


请确保您已经安装了 Python 3.x。可以在Python 官网下载并安装。



  1. 安装所需库


在命令提示符或终端中运行以下命令来安装所需的库:


pip install opencv-python
pip install opencv-contrib-python
pip install numpy
pip install face-recognition


二、创建数据集



  1. 创建文件夹结构


在项目目录下创建如下文件夹结构:


attendance-system/
├── dataset/
│ ├── person1/
│ ├── person2/
│ └── ...
└── src/


将每个人的照片放入对应的文件夹中,例如:


attendance-system/
├── dataset/
│ ├── person1/
│ │ ├── 01.jpg
│ │ ├── 02.jpg
│ │ └── ...
│ ├── person2/
│ │ ├── 01.jpg
│ │ ├── 02.jpg
│ │ └── ...
│ └── ...
└── src/


三、实现人脸识别算法


src 文件夹下创建一个名为 face_recognition.py 的文件,并添加以下代码:


import os
import cv2
import face_recognition
import numpy as np

def load_images_from_folder(folder):
images = []
for filename in os.listdir(folder):
img = cv2.imread(os.path.join(folder, filename))
if img is not :
images.append(img)
return images

def create_known_face_encodings(root_folder):
known_face_encodings = []
known_face_names = []
for person_name in os.listdir(root_folder):
person_folder = os.path.join(root_folder, person_name)
images = load_images_from_folder(person_folder)
for image in images:
face_encoding = face_recognition.face_encodings(image)[0]
known_face_encodings.append(face_encoding)
known_face_names.append(person_name)
return known_face_encodings, known_face_names

def recognize_faces_in_video(known_face_encodings, known_face_names):
video_capture = cv2.VideoCapture(0)
face_locations = []
face_encodings = []
face_names = []
process_this_frame = True

while True:
ret, frame = video_capture.read()
small_frame = cv2.resize(frame, (0, 0), fx=0.25, fy=0.25)
rgb_small_frame = small_frame[:, :, ::-1]

if process_this_frame:
face_locations = face_recognition.face_locations(rgb_small_frame)
face_encodings = face_recognition.face_encodings(rgb_small_frame, face_locations)

face_names = []
for face_encoding in face_encodings:
matches = face_recognition.compare_faces(known_face_encodings, face_encoding)
name = "Unknown"

face_distances = face_recognition.face_distance(known_face_encodings, face_encoding)
best_match_index = np.argmin(face_distances)
if matches[best_match_index]:
name = known_face_names[best_match_index]

face_names.append(name)

process_this_frame = not process_this_frame

for (top, right, bottom, left), name in zip(face_locations, face_names):
top *= 4
right *= 4
bottom *= 4
left *= 4

cv2.rectangle(frame, (left, top), (right, bottom), (0, 0, 255), 2)
cv2.rectangle(frame, (left, bottom - 35), (right, bottom), (0, 0, 255), cv2.FILLED)
font = cv2.FONT_HERSHEY_DUPLEX
cv2.putText(frame, name, (left + 6, bottom - 6), font, 0.8, (255, 255, 255), 1)

cv2.imshow('Video', frame)
if cv2.waitKey(1) & 0xFF == ord('q'):
break

video_capture.release()
cv2.destroyAllWindows()

if __name__ == "__main__":
dataset_folder = "../dataset/"
known_face_encodings, known_face_names = create_known_face_encodings(dataset_folder)
recognize_faces_in_video(known_face_encodings, known_face_names)


四、实现考勤系统


src 文件夹下创建一个名为 attendance.py 的文件,并添加以下代码:


import os
import datetime
import csv
from face_recognition import create_known_face_encodings, recognize_faces_in_video

def save_attendance(name):
attendance_file = "../attendance/attendance.csv"
now = datetime.datetime.now()
date_string = now.strftime("%Y-%m-%d")
time_string = now.strftime("%H:%M:%S")
if not os.path.exists(attendance_file):
with open(attendance_file, "w", newline="") as csvfile:
csv_writer = csv.writer(csvfile)
csv_writer.writerow(["Name", "Date", "Time"])
with open(attendance_file, "r+", newline="") as csvfile:
csv_reader = csv.reader(csvfile)
rows = [row for row in csv_reader]
for row in rows:
if row[0] == name and row[1] == date_string:
return
csv_writer = csv.writer(csvfile)
csv_writer.writerow([name, date_string, time_string])

def custom_recognize_faces_in_video(known_face_encodings, known_face_names):
video_capture = cv2.VideoCapture(0)
face_locations = []
face_encodings = []
face_names = []
process_this_frame = True
while True:
ret, frame = video_capture.read()
small_frame = cv2.resize(frame, (0, 0), fx=0.25, fy=0.25)
rgb_small_frame = small_frame[:, :, ::-1]

if process_this_frame:
face_locations = face_recognition.face_locations(rgb_small_frame)
face_encodings = face_recognition.face_encodings(rgb_small_frame, face_locations)
face_names = []
for face_encoding in face_encodings:
matches = face_recognition.compare_faces(known_face_encodings, face_encoding)
name = "Unknown"
face_distances = face_recognition.face_distance(known_face_encodings, face_encoding)
best_match_index = np.argmin(face_distances)
if matches[best_match_index]:
name = known_face_names[best_match_index]
save_attendance(name)
face_names.append(name)
process_this_frame = not process_this_frame
for (top, right, bottom, left), name in zip(face_locations, face_names):
top *= 4
right *= 4
bottom *= 4
left *= 4
cv2.rectangle(frame, (left, top), (right, bottom), (0, 0, 255), 2)
cv2.rectangle(frame, (left, bottom - 35), (right, bottom), (0, 0, 255), cv2.FILLED)
font = cv2.FONT_HERSHEY_DUPLEX
cv2.putText(frame, name, (left + 6, bottom - 6), font, 0.8, (255, 255, 255), 1)

cv2.imshow('Video', frame)
if cv2.waitKey(1) & 0xFF == ord('q'):
break

video_capture.release()
cv2.destroyAllWindows()

if __name__ == "__main__":
dataset_folder = "../dataset/"
known_face_encodings, known_face_names = create_known_face_encodings(dataset_folder)
custom_recognize_faces_in_video(known_face_encodings, known_face_names)


五、运行考勤系统


运行 attendance.py 文件,系统将开始识别并记录考勤信息。考勤记录将保存在 attendance.csv 文件中。


python src/attendance.py


现在,您的基于人脸识别的考勤系统已经实现。请注意,这是一个基本示例,您可能需要根据实际需求对其进行优化和扩展。例如,您可以考虑添加更多的人脸识别算法、考勤规则等

作者:A等天晴
来源:juejin.cn/post/7235458133505867837


收起阅读 »

Android自定义一个省份简称键盘

hello啊各位老铁,这篇文章我们重新回到Android当中的自定义View,其实最近一直在搞Flutter,初步想法是,把Flutter当中的基础组件先封装一遍,然后接着各个工具类,列表,网络,统统由浅入深的搞一遍,弄完Flutter之后,再逐步的更新And...
继续阅读 »

hello啊各位老铁,这篇文章我们重新回到Android当中的自定义View,其实最近一直在搞Flutter,初步想法是,把Flutter当中的基础组件先封装一遍,然后接着各个工具类,列表,网络,统统由浅入深的搞一遍,弄完Flutter之后,再逐步的更新Android当中的技术点,回头一想,还是穿插着来吧,再系统的规划,难免也有变化,想到啥就写啥吧,能够坚持输出就行。


今天的这个知识点,是一个自定义View,一个省份的简称键盘,主要用到的地方,比如车牌输入等地方,相对来说还是比较的简单,我们先看下最终的实现效果:



实现方式呢有很多种,我相信大家也有自己的一套实现机制,这里,我采用的是组合View,用的是LinearLayout的方式。


今天的内容大致如下:


1、分析UI,如何布局


2、设置属性和方法,制定可扩展效果


3、部分源码剖析


4、开源地址及实用总结


一、分析UI,如何布局


拿到UI效果图后,其实也没什么好分析的,无非就是两块,顶部的完成按钮和底部的省份简称格子,一开始,打算用RecyclerView网格布局来实现,但是最后的删除按钮如何摆放就成了问题,直接悬浮在网格上边,动态计算位置,显然不太合适,也没有这样去搞的,索性直接抛弃这个方案,多布局的想法也实验过,但最终还是选择了最简单的LinearLayout组合View形式。


所谓简单,就是在省份简称数组的遍历中,不断的给LinearLayout进行追加子View,需要注意的是,本身的View,也就是我们自定义View,继承LinearLayout后,默认的是垂直方向的,往本身View追加的是横向属性的LinearLayout,这也是换行的效果,也就是,一行一个横向的LinearLayout,记住,横向属性的LinearLayout,才是最终添加View的直接父类。



换行的条件就是基于UI效果,当模于设置length等于0时,我们就重新创建一个水平的LinearLayout,这就可以了,是不是非常的简单。


至于最后的删除按钮,使其靠右,占据两个格子的权重设置即可。


二、设置属性和方法,制定可扩展效果


当我们绘制完这个身份简称键盘后,肯定是要给他人用的,基于灵活多变的需求,那么相对应的我们也需要动态的进行配置,比如背景颜色,文字的颜色,大小,还有边距,以及点击效果等等,这些都是需要外露,让使用者选择性使用的,目前所有的属性如下,大家在使用的时候,也可以对照设置。


设置属性


属性类型概述
lp_backgroundcolor整体的背景颜色
lp_rect_spacingdimension格子的边距
lp_rect_heightdimension格子的高度
lp_rect_margin_topdimension格子的距离上边
lp_margin_left_rightdimension左右距离
lp_margin_topdimension上边距离
lp_margin_bottomdimension下边距离
lp_rect_backgroundreference格子的背景
lp_rect_select_backgroundreference格子选择后的背景
lp_rect_text_sizedimension格子的文字大小
lp_rect_text_colorcolor格子的文字颜色
lp_rect_select_text_colorcolor格子的文字选中颜色
lp_is_show_completeboolean是否显示完成按钮
lp_complete_text_sizedimension完成按钮文字大小
lp_complete_text_colorcolor完成按钮文字颜色
lp_complete_textstring完成按钮文字内容
lp_complete_margin_topdimension完成按钮距离上边
lp_complete_margin_bottomdimension完成按钮距离下边
lp_complete_margin_rightdimension完成按钮距离右边
lp_text_click_effectboolean是否触发点击效果,true点击后背景消失,false不消失

定义方法


方法参数概述
keyboardContent回调函数获取点击的省份简称简称信息
keyboardDelete函数删除省份简称简称信息
keyboardComplete回调函数键盘点击完成
openProhibit函数打开禁止(使领学港澳),使其可以点击

三、关键源码剖析


这里只贴出部分的关键性代码,整体的代码,大家滑到底部查看源码地址即可。


定义身份简称数组


    //省份简称数据
private val mLicensePlateList = arrayListOf(
"京", "津", "渝", "沪", "冀", "晋", "辽", "吉", "黑", "苏",
"浙", "皖", "闽", "赣", "鲁", "豫", "鄂", "湘", "粤", "琼",
"川", "贵", "云", "陕", "甘", "青", "蒙", "桂", "宁", "新",
"藏", "使", "领", "学", "港", "澳",
)

遍历省份简称


mLength为一行展示多少个,当取模为0时,就需要换行,也就是再次创建一个水平的LinearLayout,添加至外层的垂直LinearLayout中,每个水平的LinearLayout中,则是一个一个的TextView。


  //每行对应的省份简称
var layout: LinearLayout? = null
//遍历车牌号
mLicensePlateList.forEachIndexed { index, s ->
if (index % mLength == 0) {
//重新创建,并添加View
layout = createLinearLayout()
layout?.weightSum = 1f
addView(layout)
val params = layout?.layoutParams as LayoutParams
params.apply {
topMargin = mRectMarginTop.toInt()
height = mRectHeight.toInt()
leftMargin = mMarginLeftRight.toInt()
rightMargin = mMarginLeftRight.toInt() - mSpacing.toInt()
layout?.layoutParams = this
}
}

//创建文字视图
val textView = TextView(context).apply {
text = s
//设置文字的属性
textSize = px2sp(mRectTextSize)
//最后五个是否禁止
if (mNumProhibit && index > (mLicensePlateList.size - 6)) {
setTextColor(mNumProhibitColor)
mTempTextViewList.add(this)
} else {
setTextColor(mRectTextColor)
}

setBackgroundResource(mRectBackGround)
gravity = Gravity.CENTER
setOnClickListener {
if (mNumProhibit && index > (mLicensePlateList.size - 6)) {
return@setOnClickListener
}
//每个格子的点击事件
changeTextViewState(this)
}
}

addRectView(textView, layout, 0.1f)
}

追加最后一个View


由于最后一个视图是一个图片,占据了两个格子的大小,所以需要特殊处理,需要做的就是,单独设置权重weight和单独设置宽度width,如下所示:


  /**
* AUTHOR:AbnerMing
* INTRODUCE:追加最后一个View
*/

private fun addEndView(layout: LinearLayout?) {
val endViewLayout = LinearLayout(context)
endViewLayout.gravity = Gravity.RIGHT
//删除按钮
val endView = RelativeLayout(context)
//添加删除按钮
val deleteImage = ImageView(context)
deleteImage.setImageResource(R.drawable.view_ic_key_delete)
endView.addView(deleteImage)

val imageParams = deleteImage.layoutParams as RelativeLayout.LayoutParams
imageParams.addRule(RelativeLayout.CENTER_IN_PARENT)
deleteImage.layoutParams = imageParams
endView.setOnClickListener {
//删除
mKeyboardDelete?.invoke()
invalidate()
}
endView.setBackgroundResource(mRectBackGround)
endViewLayout.addView(endView)
val params = endView.layoutParams as LayoutParams
params.width = (getScreenWidth() / mLength) * 2 - mMarginLeftRight.toInt()
params.height = LayoutParams.MATCH_PARENT

endView.layoutParams = params

layout?.addView(endViewLayout)
val endParams = endViewLayout.layoutParams as LayoutParams
endParams.apply {
width = (mSpacing * 3).toInt()
height = LayoutParams.MATCH_PARENT
weight = 0.4f
rightMargin = mSpacing.toInt()
endViewLayout.layoutParams = this
}


}

四、开源地址及使用总结


开源地址:github.com/AbnerMing88…


关于使用,其实就是一个类,大家可以下载源码,直接复制即可使用,还可以进行修改里面的代码,非常的方便,如果懒得下载源码,没关系,我也上传到了远程Maven,大家可以按照下面的方式进行使用。


Maven具体调用


1、在你的根项目下的build.gradle文件下,引入maven。


 allprojects {
repositories {
maven { url "https://gitee.com/AbnerAndroid/almighty/raw/master" }
}
}

2、在你需要使用的Module中build.gradle文件下,引入依赖。


 dependencies {
implementation 'com.vip:plate:1.0.0'
}

代码使用


   <com.vip.plate.LicensePlateView
android:id="@+id/lp_view"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:layout_constraintBottom_toBottomOf="parent"
app:lp_complete_text_size="14sp"
app:lp_margin_left_right="10dp"
app:lp_rect_spacing="6dp"
app:lp_rect_text_size="19sp"
app:lp_text_click_effect="false" />


总结


大家在使用的时候,一定对照属性表进行选择性使用;关于这个省份简称自定义View,实现方式有很多种,我目前的这种也不是最优的实现方式,只是自己的一个实现方案,给大家一个作为参考的依据,好了,铁子们,本篇文章就先到这里,希望可以帮助到大家。


作者:二流小码农
来源:juejin.cn/post/7235484890019659834
收起阅读 »

Android 逆向从入门到入“狱”

免责声明 本次技术分享仅用于逆向技术的交流与学习,请勿用于其他非法用途;技术是把双刃剑,请善用它。 逆向是什么、可以做什么、怎么做 简单讲,就是将别人打包好的 apk 进行反编译,得到源码并分析代码逻辑,最终达成自己的目的。 可以做的事: 修改 sm...
继续阅读 »

免责声明


本次技术分享仅用于逆向技术的交流与学习,请勿用于其他非法用途;技术是把双刃剑,请善用它。


逆向是什么、可以做什么、怎么做




  • 简单讲,就是将别人打包好的 apk 进行反编译,得到源码并分析代码逻辑,最终达成自己的目的。




  • 可以做的事:



    • 修改 smali 文件,使程序达到自己想要的效果,重新编译签名安装,如去广告、自动化操作、电商薅羊毛、单机游戏修改数值、破解付费内容、汉化、抓包等

    • 阅读源码,借鉴别人写好的技术实践

    • 破解:小组件盒子:http://www.coolapk.com/apk/io.ifte…




  • 怎么做:



    • 这是门庞杂的技术活,需要知识的广度、经验、深度

    • 需要具体问题,具体分析,有针对性的学习与探索

    • 了解打包原理、ARM、Smali汇编语言

    • 加固、脱壳

    • Xposed、Substrate、Fridad等框架

    • 加解密

    • 使用好工具## 今日分享涉及工具




  • apktool:反编译工具



    • 反编译:apktool d <apkPath> o <outputPath>

    • 重新打包:apktool b <fileDirPath> -o <apkPath>

    • 安装:brew install apktool




  • jadx:支持命令行和图形界面,支持apk、dex、jar、aar等格式的文件查看





  • apksigner:签名工具





  • Charles:抓包工具



    • http://www.charlesproxy.com/

    • Android 7 以上抓包 HTTPS ,需要手机 Root 后将证书安装到系统中

    • Android 7 以下 HTTPS 直接抓




正题





  • 正向编译



    • java -> class -> dex -> apk




  • 反向编译



    • apk -> dex -> smali -> java




  • Smali 是 Android 的 Dalvik 虚拟机所使用的一种 dex 格式的中间语言




  • 官方文档source.android.com/devices/tec…




  • code.flyleft.cn/posts/ac692…




  • 正题开始,以反编译某瓣App为例:




    • jadx 查看 Java 源码,找到想修改的代码




    • 反编译得到 smali 源码:apktool d douban.apk -o doubancode --only-main-classes




    • 修改:找到 debug 界面入口并打开




    • 将修改后的 smali 源码正向编译成 apk:apktool b doubancode -o douban_mock1.apk




    • 重签名:jarsigner -verbose -keystore keys.jks test.apk key0




    • 此时的包不能正常访问接口,因为豆瓣 API 做了签名校验,而我们的新 apk 是用了新的签名,看接口抓包




    • 怎么办呢?




    • 继续分析代码,修改网络请求中的 apikey




    • 来看看新的 apk






  • 也可以做爬虫等




启发与防范



  • 混淆

  • 加固

  • 加密

  • 运行环境监测

  • 不写敏感信息或操作到客户端

  • App 运行签名验证

  • Api 接口签名验证


One More Thing



作者:Sinyu101220157
来源:juejin.cn/post/7202573260659163195
收起阅读 »

Java常用JVM参数实战

在Java应用程序的部署和调优过程中,合理配置JVM参数是提升性能和稳定性的关键之一。本文将介绍一些常用的JVM参数,并给出具体的使用例子和作用的分析。 内存管理相关参数 -Xmx和-Xms -Xmx参数用于设置JVM的最大堆内存大小,而-Xms参数用于设置J...
继续阅读 »

在Java应用程序的部署和调优过程中,合理配置JVM参数是提升性能和稳定性的关键之一。本文将介绍一些常用的JVM参数,并给出具体的使用例子和作用的分析。


内存管理相关参数


-Xmx和-Xms


-Xmx参数用于设置JVM的最大堆内存大小,而-Xms参数用于设置JVM的初始堆内存大小。这两个参数可以在启动时通过命令行进行配置,例如:


java -Xmx2g -Xms512m MyApp

上述示例将JVM的最大堆内存设置为2GB,初始堆内存设置为512MB。


作用分析:



  • 较大的最大堆内存可以增加应用程序的可用内存空间,提高性能。但也需要考虑服务器硬件资源的限制。

  • 合理设置初始堆内存大小可以减少JVM的自动扩容和收缩开销。


-XX:NewRatio和-XX:SurvivorRatio


-XX:NewRatio参数用于设置新生代与老年代的比例,默认值为2。而-XX:SurvivorRatio参数用于设置Eden区与Survivor区的比例,默认值为8。


例如,我们可以使用以下参数配置:


java -XX:NewRatio=3 -XX:SurvivorRatio=4 MyApp

作用分析:



  • 调整新生代与老年代的比例可以根据应用程序的特点来优化内存分配。

  • 调整Eden区与Survivor区的比例可以控制对象在新生代中的存活时间。


-XX:MaxMetaspaceSize


在Java 8及之后的版本中,-XX:MaxMetaspaceSize参数用于设置元空间(Metaspace)的最大大小。例如:


java -XX:MaxMetaspaceSize=512m MyApp

作用分析:



  • 元空间用于存储类的元数据信息,包括类的结构、方法、字段等。

  • 调整元空间的最大大小可以避免元空间溢出的问题,提高应用程序的稳定性。


-Xmn


-Xmn参数用于设置新生代的大小。以下是一个例子:


java -Xmn256m MyApp


  • -Xmn256m将新生代的大小设置为256MB。


作用分析:



  • 新生代主要存放新创建的对象,设置合适的大小可以提高垃圾回收的效率。


垃圾回收相关参数


-XX:+UseG1GC


-XX:+UseG1GC参数用于启用G1垃圾回收器。例如:


java -XX:+UseG1GC MyApp

作用分析:



  • G1垃圾回收器是Java 9及之后版本的默认垃圾回收器,具有更好的垃圾回收性能和可预测的暂停时间。

  • 使用G1垃圾回收器可以减少垃圾回收的停顿时间,提高应用程序的吞吐量。


-XX:ParallelGCThreads和-XX:ConcGCThreads


-XX:ParallelGCThreads参数用于设置并行垃圾回收器的线程数量,而-XX:ConcGCThreads参数用于设置并发垃圾回收器的线程数量。例如:


java -XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 MyApp

作用分析:



  • 并行垃圾回收器通过使用多个线程来并行执行垃圾回收操作,提高回收效率。

  • 并发垃圾回收器在应用程序运行的同时执行垃圾回收操作,减少停顿时间。


-XX:+ExplicitGCInvokesConcurrent


-XX:+ExplicitGCInvokesConcurrent参数用于允许主动触发并发垃圾回收。例如:


java -XX:+ExplicitGCInvokesConcurrent MyApp

作用分析:



  • 默认情况下,当调用System.gc()方法时,JVM会使用串行垃圾回收器执行垃圾回收操作。使用该参数可以改为使用并发垃圾回收器执行垃圾回收操作,减少停顿时间。


性能监控和调优参数


-XX:+PrintGCDetails和-XX:+PrintGCDateStamps


-XX:+PrintGCDetails参数用于打印详细的垃圾回收信息,-XX:+PrintGCDateStamps参数用于打印垃圾回收发生的时间戳。例如:


java -XX:+PrintGCDetails -XX:+PrintGCDateStamps MyApp

作用分析:



  • 打印垃圾回收的详细信息可以帮助我们了解垃圾回收器的工作情况,检测潜在的性能问题。

  • 打印垃圾回收发生的时间戳可以帮助我们分析应用程序的垃圾回收模式和频率。


-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath


-XX:+HeapDumpOnOutOfMemoryError参数用于在发生内存溢出错误时生成堆转储文件,-XX:HeapDumpPath参数用于指定堆转储文件的路径。例如:


java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump/file MyApp

作用分析:



  • 在发生内存溢出错误时生成堆转储文件可以帮助我们分析应用程序的内存使用情况,定位内存泄漏和性能瓶颈。


-XX:ThreadStackSize


-XX:ThreadStackSize参数用于设置线程栈的大小。以下是一个例子:


java -XX:ThreadStackSize=256k MyApp

作用分析:



  • 线程栈用于存储线程执行时的方法调用和局部变量等信息。

  • 通过调整线程栈的大小,可以控制应用程序中线程的数量和资源消耗。


-XX:MaxDirectMemorySize


-XX:MaxDirectMemorySize参数用于设置直接内存的最大大小。以下是一个例子:


java -XX:MaxDirectMemorySize=1g MyApp

作用分析:



  • 直接内存是Java堆外的内存,由ByteBuffer等类使用。

  • 合理设置直接内存的最大大小可以避免直接内存溢出的问题,提高应用程序的稳定性。


其他参数


除了上述介绍的常用JVM参数,还有一些其他参数可以根据具体需求进行配置,如:



  • -XX:+DisableExplicitGC:禁止主动调用System.gc()方法。

  • -XX:+UseCompressedOops:启用指针压缩以减小对象引用的内存占用。

  • -XX:OnOutOfMemoryError:在发生OutOfMemoryError时执行特定的命令或脚本。


这些参数可以根据应用程序的特点和需求进行调优和配置,以提升应用程序的性能和稳定性。


总结


本文介绍了一些常用的JVM参数,并给出了具体的使用例子和作用分析。合理配置这些参数可以优化内存管理、垃圾回收、性能监控等方面,提升Java应用程序的性能和稳定性。


在实际应用中,建议根据应用程序的需求和性能特点,综合考虑不同参数的使用。同时,使用工具进行性能监控和分析,以找出潜在的问题和瓶颈,并根据实际情况进行调优。



我是蚂蚁背大象,文章对你有帮助给项目点个❤关注我GitHub:mxsm,文章有不正确的地方请您斧正,创建ISSUE提交PR~谢谢!


作者:蚂蚁背大象
来源:juejin.cn/post/7235435351049781304

收起阅读 »

从JS执行过程彻底讲清楚闭包、作用域链、变量提升等

web
前言 今天和大家一起 来 弄清楚一段 JavaScript 代码,它是如何执行的呢? 进而彻底讲明白闭包和作用于链的含义。 JavaScript 是一门高级语言,需要转化成机器指令,才能在电脑的 CPU 中运行。使 JavaScript 代码转换成机器指令,是...
继续阅读 »

前言


今天和大家一起 来 弄清楚一段 JavaScript 代码,它是如何执行的呢? 进而彻底讲明白闭包和作用于链的含义。

JavaScript 是一门高级语言,需要转化成机器指令,才能在电脑的 CPU 中运行。使 JavaScript 代码转换成机器指令,是通过 JavaScript 引擎来完成的。

JavaScript 引擎在把 JavaScript 代码转换成机器指令过程中,先对 JavaScript 代码进行解析(词法分析,语法分析),生成 AST 树,然后在通过一些列操作转换成机器指令,从而在 CPU 中运行。今天带大家详细讲解一下相关概念,并通过一个具体的案例加深大家对相关概念的理解。


JavaScript 执行过程


JavaSc 是一门高级语言,JavaScript 引擎会先把 JavaScript 代码转换成机器指令,先对 JavaScript 代码进行解析(词法分析,语法分析),生成 AST 树,然后转换成机器指令,进而会才能 CPU 中运行。

如下图所示:


JS执行过程.png


JS 执行过程,我们会遇到一些名词,这里在前面先做个解释


名词解释
ECS (Execution Context Stack) 执行上下文栈/调用栈以栈的形式调用创建的执行上下文。JavaScript 引擎内部实现了一个执行上文栈,目的就是为了执行代码。只要有代码执行,一定是在执行上下文栈中执行的。
GECGEC(Global Execution Context)全局执行上下文在执行全局代码前创建。 代码想要执行一定经过调用栈(上个关键词),也就意味着代码是以函数的形式被调用。但是全局代码(比如:定义变量、定义函数等)并不是函数形式,我们并不能主动调用代码,而被动的需要浏览器去调用代码。起到该作用的就是全局执行上下文,先解析全局代码然后执行。
FEC(Functional Execution Context)函数执行上下文在执行函数前创建。如果遇到函数的主动调用,就会生成一个函数执行上下文,入栈到函数调用栈中;当函数调动完成之后,就会执行出栈操作
VO(Variable Object)变量对象早期 ECMA 规范中的变量环境,对应 Object。该对象保存了当前执行上下文中的变量和函数地址(也就是当前作用域)。
VE(Variable Environment 变量环境最新 ECMA 规范中的变量环境,对应环境记录。 在最新 ECMA 的版本规范中:每一个执行上下文会关联到一个变量环境(Variable Environment,简称 VE),在执行代码中变量和函数的声明会作为环境记录(Environment Record)添加到变量环境中。对于函数来说,参数也会被作为环境记录添加到变量环境中。 简单来讲:1. 也就是相比于早期的版本规范,对于变量环境,已经去除了 VO 这个概念,提出了一个新的概念 VE;2. 没有规定 VE 必须为 Object,不同的 JS 引擎可以使用不同的类型,作为一条环境记录添加进去即可;3. 虽然新版本规范将变量环境改成了 VE,但是 JavaScript 的执行过程还是不变的,只是关联的变量环境不同,将 VE 看成 VO 即可;
GO(Global Object)全局对象全局对象,解析全局代码时创建,GEC 中关联的 VO 就是 GO
AO (Activation Object)函数对象函数对象,解析函数体代码时创建,FEC 中关联的 VO 就是 AO

名词太多不容易理解,这里不用去记,下面用到的时候重新从这里查找即可。


⚠️⚠️❗️❗️ 下面的小章节是按照特定顺序讲解的,讲解了代码生成执行过程。


解析阶段(编译器伪代码)



  1. 创建一个全局对象 GO/window(全局作用域)

  2. 词法分析。词法分析就是将我们写的代码块分解成词法单元。

  3. 检查语法是否有错误。语法分析是将词法单元流(数组)转换成一个由元素逐级嵌套所组成的代表了程序语法结构的树。这个树被称为“抽象语法树”(Abstract Syntax Tree,AST)。 并检查你的代码有没有什么低级的语法错误,如果有,引擎会停止执行并抛出异常。

  4. 给全局对象 GO 赋值(GO/VO 中不止包括变量自身,还包含其他的上下文等)


如果遇到了函数,编译阶段是不会去解析他,仅仅是在堆内存中创建了 FO 对象(会记录他的 parent scope 和 当前代码块),在 GO 中定义的函数变量会指向此变量。


生成全局对象的伪代码是什么? (变量提升考点)



  1. 从上到下查找,遇到 var 声明,先去全局作用域查找是否有同名变量,如有忽略当前声明,没有则添加声明变量为 GO 对象的属性,值为 undefined,并为变量分配内存。

  2. 遇到 function,如有同名变量,则将值替换为 function 函数,没有则添加到 GO,并分配内存并赋值。

  3. ES6 中的 class 声明也存在提升,不过它和 let、const 一样,被约束和限制了,其规定,如果再声明位置之前引用,则是不合法的,会抛出一个异常。


创建全局对象有什么用?



  • 所有的作用域(scope)都可以访问该全局对象;

  • 对象里面会包含一些全局的方法和类,像 Math、Date、String、Array、setTimeout 等等;

  • 其中有一个 window 属性是指向该全局对象自身的;

  • 该对象中会收集我们上面全局定义的变量,并设置成 undefined;

  • 全局对象是非常重要的,我们平时之所以能够使用这些全局方法和类,都是在这个全局对象中获取的;


什么是变量提升?


面试经常问是因为工作中经常因为他出现 BUG。
什么是变量提升:通常 JS 引擎会在正式执行之前先进行一次预编译,在这个过程中,首先将变量声明及函数声明提升至当前作用域的顶端,然后进行接下来的处理。



  • 函数提升只针对具名函数,而对于赋值的匿名函数(表达式函数),并不会存在函数提升。

  • 【提升优先级问题】函数提升优先级高于变量提升,且不会被同名变量声明覆盖,但是会被变量赋值后覆盖。而且存在同名函数与同名变量时,优先执行函数。


console.log(a);      //f a()
console.log(a()); //1
var a=1;
function a(){
console.log(1);
}
console.log(a); //1
a=3
console.log(a()) //a not a function

🤔 思考:(一道腾讯面试题)


var a=2;
function a() {
console.log(3);
}
console.log(typeof a);

为什么会进行变量提升?



  • 【比较信服的一种说法】正是由于第一批 JavaScript 虚拟机编译器上代码的设计失误,导致变量在声明之前就被赋予了 undefined 的初始值,而又由于这个失误产生的影响(无论好坏)过于广泛,因此在现在的 JavaScript 编译器中仍保留了变量提升的“特性”。

  • 【提升性能,这是预编译的好处,与变量提升没有没有关系】解析和预编译过程中的声明提升可以提高性能,让函数可以在执行时预先为变量分配栈空间

  • 【但也带了很多弊端】声明提升还可以提高 JS 代码的容错性,使一些不规范的代码也可以正常执行


现在讲完了变量赋值过程,接下来我们了解一下,全局执行上下文和函数执行上下文。


什么是 全局执行上下文 和 函数执行上下文?


全局执行上下文和函数执行上下文,大致也分为两个阶段:编译阶段和执行阶段。

解析过程中,获得了三个重要的信息(上下文包含的重要信息)【上下文对象中包含的信息有哪些?】:



  1. VO(Variable Object)对象:该对象保存了当前执行上下文中的变量和函数地址(也就是当前作用域)。

  2. 作用域链:VO(当前作用域) + ParentScope(父级作用域) 【在函数部分重要讲解】

  3. this 的指向: 视情况而定。


什么是作用域?


JavaScript 中的作用域说的是变量的可访问性和可见性。也就是说整个程序中哪些部分可以访问这个变量,或者说这个变量都在哪些地方可见。

作用域两个重要作用是 安全 和 命名压力(可以在不同的作用域下面定义相同的变量名)。

Javascript 中有三种作用域:



  1. 全局作用域

  2. 函数作用域

  3. 块级作用域
    作用域链:当在 Javascript 中使用一个变量的时候,首先 Javascript 引擎会尝试在当前作用域下去寻找该变量,如果没找到,再到它的上层作用域寻找,以此类推直到找到该变量或是已经到了全局作用域。


记住两句话:



  1. 父级作用域在编译阶段就已经确定了。

  2. 查找变量就是按照作用域链查找(找到近停止)[]

    也可以这么理解:作用域链是 AO 对象上的一个变量[scopeChain] 里面的变量是 当前的 VO+parentVO,当某个变量不存在时会顺着 parentVO 向上查找,直到找到为止。


什么是词法作用域?


词法作用域(也叫静态作用域)从字面意义上看是说作用域在词法化阶段(通常是编译阶段)确定而非执行阶段确定的。 JavaScript 的作用域是词法作用域。

例如:


let number = 42;
function printNumber() {
console.log(number);
}
function log() {
let number = 54;
printNumber();
}
// Prints 42
log();

上面代码可以看出无论printNumber()在哪里调用console.log(number)都会打印42

动态作用域不同,console.log(number)这行代码打印什么取决于函数printNumber()在哪里调用。

如果是动态作用域,上面console.log(number)这行代码就会打印54

使用词法作用域,我们可以仅仅看源代码就可以确定一个变量的作用范围,但如果是动态作用域,代码执行之前我们没法确定变量的作用范围。


什么是执行上下文?


简单的来说,执行上下文是一种对 Javascript 代码执行环境的一种抽象概念,也就是说只要有 Javascript 代码运行,那么它就一定是运行在执行上下文中。


Javascript 一共有三种执行上下文:



  • 全局执行上下文。

    这是一个默认的或者说基础的执行上下文,所有不在函数中的代码都会在全局执行上下文中执行。它会做两件事:创建一个全局的 window 对象(浏览器环境下),并将 this 的值设置为该全局对象,另外一个程序中只能有一个全局上下文。

  • 函数执行上下文。

    每次调用函数时,都会为该函数创建一个执行上下文,每一个函数都有自己的一个执行上下文,但注意是该执行上下文是在函数被调用的时候才会被创建。函数执行上下文会有很多个,每当一个执行上下文被创建的时候,都会按照他们定义的顺序去执行相关代码(这会在后面会说到)。

  • Eval 函数执行上下文。

    eval 函数中执行的代码也会有自己的执行上下文,但由于 eval 函数不会被经常用到,这里就不做讨论了。(译者注:eval 函数容易导致恶意攻击,并且运行代码的速度比相应的替代方法慢,因为不推荐使用)。


执行上下文栈(调用栈)?


了解了什么是全局对象后,下面就来聊聊代码具体执行的地方。JS 引擎为了执行代码,引擎内部会有一个执行上下文栈(Execution Context Stack,简称 ECS),它是用来执行代码的调用栈。


ECS 如何执行?先执行谁呢?



  • 无疑是先执行我们的全局代码块;

  • 在执行前全局代码会构建一个全局执行上下文(Global Execution Context,简称 GEC);

  • 一开始 GEC 就会被放入到 ECS 中执行;
    GEC 主要包含三个内容(和 FEC 基本一样): VO,作用域链,this 的指向。


调用栈(ECS)、全局执行上下文、函数执行上下文(FEC)三者大致的关系如下:


调用栈与全局执行上下文与函数执行上下文三者关系.png


函数执行上下文



在执行全局代码遇到函数如何执行呢?




  • 在执行的过程中遇到函数,就会根据函数体创建一个函数执行上下文(Functional Execution Context,简称 FEC),并且加入到执行上下文栈(ECS)中。

  • 函数执行上下文(FEC)包含三部分内容:

    • AO:在解析函数时,会创建一个 Activation Objec(AO);

    • 作用域链:由函数 VO 和父级 VO 组成,查找是一层层往外层查找;

    • this 指向:this 绑定的值,在函数执行时确定;



  • 其实全局执行上下文(GEC)也有自己的作用域链和 this 指向,只是它对应的作用域链就是自己本身,而 this 指向为 window。


变量环境和记录(VO 和 VE)


上文中提到了很多次 VO,那么 VO 到底是什么呢?下面从 ECMA 新旧版本规范中来谈谈 VO。

在早期 ECMA 的版本规范中:每一个执行上下文会被关联到一个变量环境(Variable Object,简称 VO),在源代码中的变量和函数声明会被作为属性添加到 VO 中。对应函数来说,参数也会被添加到 VO 中。



  • 也就是上面所创建的 GO 或者 AO 都会被关联到变量环境(VO)上,可以通过 VO 查找到需要的属性;

  • 规定了 VO 为 Object 类型,上文所提到的 GO 和 AO 都是 Object 类型;
    在最新 ECMA 的版本规范中:每一个执行上下文会关联到一个变量环境(Variable Environment,简称 VE),在执行代码中变量和函数的声明会作为环境记录(Environment Record)添加到变量环境中。对于函数来说,参数也会被作为环境记录添加到变量环境中。

  • 也就是相比于早期的版本规范,对于变量环境,已经去除了 VO 这个概念,提出了一个新的概念 VE;

  • 没有规定 VE 必须为 Object,不同的 JS 引擎可以使用不同的类型,作为一条环境记录添加进去即可;

  • 虽然新版本规范将变量环境改成了 VE,但是 JavaScript 的执行过程还是不变的,只是关联的变量环境不同,将 VE 看成 VO 即可;


什么是闭包?


MDN 上解释:闭包(closure)是一个函数以及其捆绑的周边环境状态(lexical environment,词法环境)的引用的组合。换而言之,闭包让开发者可以从内部函数访问外部函数的作用域。
也可以简单:函数 + 函数定义时的词法环境。


具体实例来理解整个执行过程


var name = 'curry'

console.log(message)

var message = 'I am new-coder.cn'

function foo() {
var name = 'foo'
console.log(name)
}

var num1 = 1
var num2 = 2

var result = num1 + num2

foo()

如下图:图中描述了上面这段代码在执行过程中所生成的变量。


JS代码执行过程


图中三个步骤的详细描述:



  1. 初始化全局对象。



  • 这里需要注意的是函数存放的是地址,会指向函数对象,与普通变量有所不同;

  • 从上往下解析 JS 代码,当解析到 foo 函数时,因为 foo 不是普通变量,并不会赋为 undefined,JS 引擎会在堆内存中开辟一块空间存放 foo 函数,在全局对象中引用其地址;

  • 这个开辟的函数存储空间最主要存放了该函数的父级作用域和函数的执行体代码块;




  1. 构建一个全局执行上下文(GEC),代码执行前将 VO 的内存地址指向 GlobalObject(GO)。




  2. 将全局执行上下文(GEC)放入执行上下文栈(ECS)中。




  3. 从上往下开始执行全局代码,依次对 GO 对象中的全局变量进行赋值。





  • 当执行 var name = 'curry'时,就从 VO(对应的就是 GO)中找到 name 属性赋值为 curry;

  • 接下来执行 console.log(message),就从 VO 中找到 message,注意此时的 message 还为 undefined,因为 message 真正赋值在下一行代码,所以就直接打印 undefined(也就是我们经常说的变量作用域提升);

  • 后面就依次进行赋值,执行到 var result = num1 + num2,也是从 VO 中找到 num1 和 num2 两个属性的值进行相加,然后赋值给 result,result 最终就为 50;

  • 最后执行到 foo(),也就是需要去执行 foo 函数了,这里的操作是比较特殊的,涉及到函数执行上下文,下面来详细了解;



  1. 遇到函数是怎么执行的
    继续来看上面的代码执行,当执行到 foo()时:



  • 先找到 foo 函数的存储地址,然后解析 foo 函数,生成函数的 AO;

  • 根据 AO 生成函数执行上下文(FEC),并将其放入执行上下文栈(ECS)中;

  • 开始执行 foo 函数内代码,依次找到 AO 中的属性并赋值,当执行 console.log(name)时,就会去 foo 的 VO(对应的就是 foo 函数的 AO)中找到 name 属性值并打印;



  1. 如此下去函数执行完成后会进行出栈,直到栈为空。代码出栈,如果出栈中发现当前上下文中的一些变量仍然被引用(形成了闭包),那就会将此出栈的上下文移动到堆中。


参考链接



作者:大熊全栈分享
来源:juejin.cn/post/7235463575300702263
收起阅读 »

前端开发:关于diff算法详解

web
前言 前端开发中,关于JS原生的内容和前端算法相关的内容一直都是前端工作中的核心,不管是在实际的前端业务开发还是前端求职面试,都是非常重要且必备的内容。那么本篇博文来分享一个关于前端开发中必备内容:diff算法,diff算法在前端实战中和前端求职面试中都是必...
继续阅读 »

前言



前端开发中,关于JS原生的内容和前端算法相关的内容一直都是前端工作中的核心,不管是在实际的前端业务开发还是前端求职面试,都是非常重要且必备的内容。那么本篇博文来分享一个关于前端开发中必备内容:diff算法,diff算法在前端实战中和前端求职面试中都是必备知识,整理总结一下,方便查阅使用。



diff算法是什么?


diff算法其实就是用于比较新旧虚拟DOM节点的差异性的算法。众所周知,每一个虚拟DOM节点都会有一个唯一标识,即Key,diff算法把树形结构按照层级分解,只比较同级元素,不同层级的节点只有创建和删除操作,通过对比新旧节点的Key来判断当前节点是否改变,把两个节点不同的地方存储在patch对象中,然后利用patch记录的消息进行局部更新DOM操作。


注意:若输入的新节点不是虚拟DOM , 那么需要将DOM节点转换为虚拟DOM才行,也就是说diff算法是针对虚拟DOM的。


patch()函数


patch函数其实就是用于节点上树,更新DOM的函数,也就是将新旧节点进行比较的函数。


diff算法的诞生


想必大家都知道,前端领域中在之前传统的DOM操作非常昂贵,数据的改变往往需要更新 DOM 树上的多个节点,可谓是牵一发而动全身,所以虚拟DOM和Diff算法的诞生就是为了解决上述问题。


前端的Web界面由 DOM 树来构成,当某一部分发生变化的时候,其实就是对应的某个 DOM 节点发生了变化。在 Vue中,构建 UI 界面的思路是由当前状态决定界面,前后两个状态就对应两套界面,然后由 Vue来比较两个界面的区别,本质是比较 DOM 节点差异当两个节点不同时应该如何处理,分为两种情况:一、节点类型不同;二、节点类型相同,但是属性不同。了解它们就需要对 DOM 树进行 Diff 算法分析。


diff算法的优势


diff算法的性能优势在于对比新旧两个 DOM节点的不同的时候,只对比同一级别的 DOM 节点,一旦发现有不同的地方,后续的DOM子节点将被删掉而不再作对比操作。使用diff算法提高了更新DOM的性能,不用再把整个页面全部删除后重新渲染;使用diff算法让虚拟DOM只包括必须的属性,不再把真实DOM的全部属性都拿出来。


diff算法的示例


这里先来以Vue来介绍一下diff算法的示例,这里直接在vue文件的模板中进行一个简单的标签实现,需要被vue处理成虚拟DOM,然后渲染到真实DOM中,具体代码如下所示:


//标签设置

//相对应的虚拟DOM结构

const dom = {

type: 'div',

attributes: [{id: 'content'}],

children: {

type: 'p',

attributes: [{class: 'sonP'}],

text: 'Hello'

}

}

通过上面的代码演示可以看到,新建标签之后,系统内存中会生成对应的虚拟DOM结构,由于真实DOM属性有很多,无法快速定位是哪个属性发生改变,然后通过diff算法能够快速找到发生变化的地方,然后只更新发生变化的部分渲染到页面上,也叫打补丁。


虚拟DOM


虚拟DOM是保存在程序内存中的,它只记录DOM的关键信息,然后结合diff算法来提高DOM更新的性能操作,在程序内存中比较差异,最后给真实DOM打补丁更新操作。


diff算法的比较规则


diff算法在进行比较操作的规则是这样的:



  1. 新节点前和旧节点前;

  2. 新节点后和旧节点后;

  3. 新节点后和旧节点前;

  4. 新节点前和旧节点后。


只要符合一种情况就不会再进行判断,若没有符合的,就需要循环来寻找,移动到旧前之前操作。结束查找的前提是:旧节点前<旧节点后 或者 新节点后>新节点前。


image.png


diff算法的三种比较方式


diff算法的比较方式有三种,分别如下所示:


方式一:根元素发生改变,直接删除重建


也就是同级比较,根元素发生改变,整个DOM树会被删除重建。如下示例:


//旧的虚拟DOM
<ul id="content">
<li class="sonP">hello</li>
</ul>
//新的虚拟DOM
<div id="content">
<p class="sonP">hello</p>
</div>

方式二:根元素不变,属性改变,元素复用,更新属性


这种方式就是在同级比较的时候,根元素不变,但是属性改变之后更新属性,示例如下所示:


//旧的虚拟DOM
<div id="content">
<p class="sonP">hello</p>
</div>
//新的虚拟DOM
<div id="content" title="hello">
<p class="sonP">hello</p>
</div>

方式三:根元素不变,子元素不变,元素内容发生变化


也就是根元素和子元素都不变,只是内容发生改变,这里涉及到三种小的情况:无Key直接更新、有Key但以索引为值、有Key但以id为值。


1、无Key直接更新


无Key直接就地更新,由于v-for不会移动DOM,所以只是尝试复用,然后就地更新;若需要v-for来移动DOM,则需要用特殊 attribute key 来提供一个排序提示。示例如下所示:


<ul id="content">
<li v-for="item in array">
{{ item }}
<input type="text">
</li>
</ul>

<button @click="addClick">在下标为1的位置新增一行</button>
export default {
data(){
return {
array: ["11", "44", "22", "33"]
}
},
methods: {
addClick(){
this.array.splice(1, 0, '44')
}
}
};

2、有Key但以索引为值


这里也是直接就地更新,通过新旧虚拟DOM对比,key存在就直接复用该标签更新的内容,若key不存在就直接新建一个。示例如下所示:


-

{{ item }}

在下标为1的位置新增一行

export default {

data(){

return {

array: ["11", "44", "22", "33"]

}

},

methods: {

addClick(){

this.array.splice(1, 0, '44')

}

}

};

通过上面代码可以看到,通过v-for循环产生新的DOM结构, 其中key是连续的, 与数据对应一致,然后比较新旧DOM结构, 通过diff算法找到差异区别, 接着打补丁到页面上,最后新增补一个li,然后从第二元素以后都要更新内容。


3、有Key但以id为值


由于Key的值只能是唯一不重复的,所以只能以字符串或数值来作为key。由于v-for不会移动DOM,所以只是尝试复用,然后就地更新;若需要v-for来移动DOM,则需要用特殊 attribute key 来提供一个排序提示。


若新DOM数据的key存在, 然后去旧的虚拟DOM里找到对应的key标记的标签, 最后复用标签;若新DOM数据的key存在, 然后去旧的虚拟DOM里没有找到对应的key标签的标签,最后直接新建标签;若旧DOM结构的key, 在新的DOM结构里不存在了, 则直接移除对应的key所在的标签。


<ul id="content">
<li v-for="object in array" :key="object.id">
{{ object.name }}
<input type="text">
</li>
</ul>

<button @click="addClick">在下标为1的位置新增一行</button>
export default {
data(){
return {
array: [{id:11,name:"11"}, {id:22,name:"22"}, {id:33,name:"33"}]
}
},
methods: {
addClick(){
this.array.splice(1, 0,{id:44,name: '44'})
}
}
};

最后


通过本文关于前端开发中关于diff算法的详细介绍,diff算法不管是在实际的前端开发工作中还是在前端求职面试中都是非常关键的知识点,所以作为前端开发者来说必须要掌握它相关的内容,尤其是从事前端开发不久的开发者来说尤为重要,是一篇值得阅读的文章,重要性就不在赘述。欢迎关注,一起交流,共同进步。


作者:三掌柜
来源:juejin.cn/post/7235534634775347261
收起阅读 »

另类年终总结:在煤老板开的软件公司实习是怎样一种体验?

某个编剧曾经说过:“怀念煤老板,他们从不干预我们创作,除了要求找女演员外,没有别的要求。”,现在的我毕业后正式工作快半年了,手上的活越来越多,负责的事项越来越多越来越杂,偶尔夜深人静走在回家的路上,也怀念当时在煤老板旗下的软件公司实习时无忧无虑的快乐生活,谨以...
继续阅读 »

某个编剧曾经说过:“怀念煤老板,他们从不干预我们创作,除了要求找女演员外,没有别的要求。”,现在的我毕业后正式工作快半年了,手上的活越来越多,负责的事项越来越多越来越杂,偶尔夜深人静走在回家的路上,也怀念当时在煤老板旗下的软件公司实习时无忧无虑的快乐生活,谨以此文纪念一下当时的时光。


煤老板还会开软件公司?


是的,煤老板家大业大,除了名下有几座矿之外,还有好多处农场、餐厅、物流等产业,可以说涉足了多个产业。当然最赚钱的主业还是矿业,听坊间传闻说,只要矿一开,钱就是哗哗的流进来。那么这个软件公司主要是做什么的呢,一小部分是给矿业服务的,负责矿山的相关人员使用记录展示每天矿上的相关数据,比如每天运输车辆的流转、每日矿上人力的核算。大部分的主力主要用于实现老板的雄伟理想,通过一个超级APP,搞定衣食住行,具体的业务如下,可以说是相当红火的。



煤老板的软件公司是怎么招聘的


这么有特色的一家公司,我是如何了解到并加入的呢。这还要从老板如何创立这家公司说起,老板在大学进修MBA的时候,认识了大学里计算机学院的几名优秀学子,然后对他们侃侃而谈自己的理念和对未来的设想,随后老板大笔一挥,我开家公司,咱们一起创业吧,钱我出,你们负责出技术。然后这几个计算机学院的同学,就携带着技术入股成为了这家软件公司的一员。随着老板的设想越来越丰富,最初进去的技术骨干也在不停的招兵买马,当时还是流行在QQ空间转发招聘信息。正是在茫茫动态中,多看了招聘信息一眼,使得该公司深深留在我的印象当中。后来我投递的时候,也是大学同学正在里面实习,于是简历直达主管。


面试都问了些啥


由于公司还处于初创阶段,所以没有那么复杂的一面二面三面HR面,一上来就是技术主管们来一个3对1面,开头聊聊大家都是校友,甚至可能还是同一个导师下的师兄弟,所以面试相对来说就没有那么难,问一问大学里写过的大作业项目,聊一聊之前实习做的东西,问一问熟悉的八股文,比如数据库事务,Spring等等,最后再关切的问一下实习时间,然后就送客等HR通知了。


工作都需要干啥


正如第一张图所示,公司的产品分成了几个模块,麻雀虽小,五脏俱全,公司里后端、前端、移动端、测试一应具全。我参与的正是公司智慧餐饮行业线的后端开发,俗称Java CRUD boy。由于公司里一众高薪招揽过来的开发,整体采用的开发理念还是很先进的。会使用sprint开发流程,每周一个迭代,就是发版上线还是不够devops,需要每周五技术leader自己启动各个脚本进行发版,将最新的代码启动到阿里云服务机器上。 虽然用户的体量不是很大,但是仍然包含Spring Cloud分布式框架、分库分表、Redis分布式锁、Elastic Search搜索框架、DTS消息传输复制框架等“高新科技”。每周伊始,会先进行需求评审,评估一下开发需要的工作量,随后就根据事先制定的节奏进行有条不紊的开发、测试、验收、上线。虽然工作难度不高,但是我在这家公司第一次亲身参与了产品迭代的全流程,为以后的实习、找工作都添加了一些工作经验。


因为是实习嘛,所以基本上都是踩点上班、准时下班。不过偶尔也存在老板一拍脑袋,说我们要两周造一个电子商城的情况,那个时候可真是加班加点,披星戴月带月的把项目的简易版本给完成、上线了。但是比较遗憾的是,后面也没有能大范围投入使用。


比如下面的自助借伞机,就是前司的一项业务,多少也是帮助了一些同学免于淋雨。



画重点,福利究竟有多好


首先公司的办公地点位于南京市中心,与新街口德基隔基相望。



每天发价值88元的内部币,用于在楼下老板开的餐厅里点餐,工作套餐有荤有素有汤有水果,可以说是非常的上流了。



如果不想吃工作套餐,还可以一起聚众点餐,一流的淮扬菜式,可以说非常爽了。 听说在点餐系统刚上线还没有内部币时,点餐是通过白名单的方式,不用付钱随便点。可惜我来晚了,没有体验到这么个好时候。



工作也标配imac一整套,虽然不好带走移动办公,但是用起来依然逼格满满。



熟悉的健身房福利当然少不了,而且还有波光粼粼的大泳池,后悔没有利用当时的机会多去几次学会游泳了。



除了这些基础福利之外,老板给的薪资比肩BAT大厂,甚至可能比他们还高一丢丢,在南京可以生活的相当滋润了。


既然说的这么好,那么为啥没有留下来呢。


唯一的问题当然是因为公司本身尚未盈利,所有这一切都依赖老板一个人的激情投入,假如老板这边出了啥问题,那整个公司也就将皮之不存,毛将焉附了。用软件领域的话来说,就是整个系统存在单点故障。所以尽管当时的各种福利很好,也选择离开找个更大的厂子先进去锻炼锻炼。


最后希望前老板矿上的生意越来越好,哪天我在外面卷不动了,还能收留我一下。


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

一个特别简单的队列功能

背景 身为一名ui仔,不光要会画ui,也有可能接触一些其他的需求,就比如我做直播的时候,就需要做礼物的队列播放,用户送礼,然后客户收到消息,然后一次播放礼物动画,这个需求很简单,自定义一个view并且里面有一个队列就可以搞定,但是如果要播放不同类型的内容,如果...
继续阅读 »

背景


身为一名ui仔,不光要会画ui,也有可能接触一些其他的需求,就比如我做直播的时候,就需要做礼物的队列播放,用户送礼,然后客户收到消息,然后一次播放礼物动画,这个需求很简单,自定义一个view并且里面有一个队列就可以搞定,但是如果要播放不同类型的内容,如果再去改这个ui,耦合度就会越来越大,那么这个view的定义就变了,那就太不酷啦,所以要将队列和ui拆开,所以我们要实现一个队列功能,然后可以接受不同类型的参数,然后依次执行。


如何实现的


一、咱们有两个队列,一个更新ui,一个缓存消息


二、咱们还要定时器,要轮询的检查任务


三、我们还要有队列进入的入口


四、我们也需要有处理队列的地方


五、我们还要有最后处理结果的方案


六、还得需要一个清除的功能,要不怎么回收呢


举一个栗子🌰


假设我们有个需求,收到消息后,弹出一个横幅通知,弹出横幅通知后几秒后消失,但是在这几秒中,会收到多条消息,你需要将这多条消息合并展示,听起来是不是很耳熟,就是说咱们聊天消息,一条消息展示一条内容,多条消息做合并。
现在看实际代码:如下所示

/**
* 堆栈消息帮助类
* */
object QueuePushHelper {
/**
* 通过type修改监听状态
* */
private var type = false


private var queuePushInterface: QueuePushInterface? = null

fun setQueuePushInterface(queuePushInterface: QueuePushInterface) {
this.queuePushInterface = queuePushInterface
}

/**
* 缓存所有消息
*/
private var cacheGiftList: LinkedList<QueuePushBean> =
LinkedList<QueuePushBean>()

/**
* 用于更新界面消息的队列
*/
private var uiMsgList: LinkedList<QueuePushBean> =
LinkedList<QueuePushBean>()

/**
* 定时器
*/
private var msgTimer = Executors.newScheduledThreadPool(2)

private lateinit var futures: ScheduledFuture<*>

/**
* 消息加入队列
*/
@JvmStatic
@Synchronized
fun onMsgReceived(customMsg: QueuePushBean) {
cacheGiftList.offer(customMsg)
}

/**
* 清空队列
* */
fun clearQueue() {
if (cacheGiftList.size > 0) {
cacheGiftList.clear()
}
if (uiMsgList.size > 0) {
uiMsgList.clear()
}
updateStatus(true)
}

/**
* 修改队列状态
* */
fun updateStatus(status: Boolean) {
type = status
}

/**
* 开启定时任务,数据清空
* */
@JvmStatic
fun startReceiveMsg() {
if (cacheGiftList.size > 0) {
cacheGiftList.clear()
}
if (uiMsgList.size > 0) {
uiMsgList.clear()
}
updateStatus(true)
futures = msgTimer.scheduleAtFixedRate(
TimerTask(),
0,
500,
TimeUnit.MILLISECONDS
)
}

/**
* 结束定时任务,数据清空
* ### 退出登录,需要清楚
* */
fun stopReceiveMsg() {
updateStatus(false)
if (cacheGiftList.size > 0) {
cacheGiftList.clear()
}
if (uiMsgList.size > 0) {
uiMsgList.clear()
}
if (::futures.isInitialized) {
futures.cancel(true)
}
msgTimer.shutdown()
}

/**
* 定时任务
* */
class TimerTask : Runnable {
override fun run() {
try {
synchronized(cacheGiftList) {
if (type) {
if (cacheGiftList.isNullOrEmpty()) {
return
}
uiMsgList.clear()
uiMsgList.offer(cacheGiftList.pollLast())
uiMsgList.poll()?.let {
if (cacheGiftList.size > 1) {
it.type = true
}
//poll一个用户信息,且从剩余集合中过滤出第一个不同名字的用户
queuePushInterface?.handleMessage(
it,
cacheGiftList.firstOrNull { its->
it.msg.fromNick !=its.msg.fromNick
}?.msg?.fromNick,
cacheGiftList.size + 1 // 因为poll了一个 所以数量加1
)
}
cacheGiftList.clear()
}
}
} catch (e: Exception) {
Log.d("QueuePushHelper", "run: e $e")
}
}
}

interface QueuePushInterface {

fun handleMessage(item: QueuePushBean, name: String?, msgCount: Int)
}
}

我代码都贴出来了,大家一看就知道 这个也太简单了。就不多解释了,如果还需要解释就留言吧,祝大家事事平安


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

浅谈 Android 线上帧率统计方案演进

帧率是我们衡量应用流畅度的一个重要基准指标。本文将简单介绍 Android 线上帧率计算方案的演进和业界基于帧率来衡量卡顿的相关指标设计。 帧率计算方案的演进 Choreographer.postFrameCallback 自 Android 4.1 引入 C...
继续阅读 »

帧率是我们衡量应用流畅度的一个重要基准指标。本文将简单介绍 Android 线上帧率计算方案的演进和业界基于帧率来衡量卡顿的相关指标设计。


帧率计算方案的演进


Choreographer.postFrameCallback


自 Android 4.1 引入 Choreographer 来调度 UI 线程的绘制相关任务之后,我们便有了一个简单衡量 UI 线程绘制效率的方案:通过持续调用 Choreographer 的 postFrameCallback 方法来得到基于 VSync 周期的回调,基于回调的间隔或者方法参数中的当前帧起始时间 frameTimeNanos 来计算帧率( 注意到基于回调间隔计算帧率的情况,由于 postFrameCallback 注册的回调类型是 Animation,早于 Traversal 但晚于 Input,实际回调的起点并不是当前帧的起点 )。


这一方案简单可靠,但关键问题在于 UI 线程通常都不会不间断地执行绘制任务,在不需要执行绘制任务( scheduleTraversals )时,UI 线程原本是不需要请求 VSync 信号的,而持续调用 postFrameCallback 方法的情况,则会连续请求 VSync 信号,使得 UI 线程始终处于比较活跃的状态,同时计算得到的帧率数据实际也会包含不需要绘制时的情况。准确来说,这一方案实际衡量的是 UI 线程的繁忙程度。


Matrix 早期方案


怎么能得到真正的帧率数据呢?腾讯 Matrix 的早期实现上,结合 Looper Printer 和 Choreographer 实现了一个比较巧妙的方案,做到了统计真正的 UI 线程绘制任务的细分耗时。


具体来说,基于 Looper Printer 做到对 UI 线程每个消息执行的监控,同时反射给 Choreographer 的 Input 回调队列头部插入一个任务,用来监听下一帧的起点。队头的 Input 任务被调用时,说明当前所在的消息是处理绘制任务的,则消息执行的终点也就是当前帧的终点。同时,在队头的 Input 任务被调用时,给 Animation 和 Traversal 的回调队列头部也插入任务,如此总共得到了四个时间点,可以将当前帧的耗时细分为 Input,Animation 和 Traversal 三个阶段。在当前处理绘制任务的消息执行完后,重新注册一个 Input 回调队列头部的任务,便可以继续监听下一帧的耗时情况。


这一方案没有使用 postFrameCallback( 不主动请求 VSync 信号 ),避免了前一个方案的问题,但整体方案上偏 hack,可能存在兼容性问题( 实际 Android 高版本上对 Choreographer 的内部回调队列确实有所调整 )。此外,当前方案也会受到上一方案的干扰,如果存在其他业务在持续调用 postFrameCallback,也会使得这里统计到的数据包含非绘制的情况。


JankStats 方案


实际在 Android 7.0 之后,官方已经引入了 FrameMetrics API 来提供帧耗时的详细数据。androidx 的 JankStats 库主要就是基于 FrameMetrics API 来实现的帧耗时数据统计。


在 Android 4.1 - 7.0 之间,JankStats 仍然是基于 Choreographer 来做帧率计算的,但方案和前两者均不同。具体来说,JankStats 通过监听 OnPreDrawListener 来感知绘制任务的发生,此时,通过反射 Choreographer 的 mLastFrameTimeNanos 来获取当前帧的起始时间,再通过往 UI 线程的消息队列头部抛任务的方式来获取当前帧的 UI 线程绘制任务结束时间( 在支持异步消息情况下,将该消息设置为异步消息,尽量保证获取结束时间的任务紧跟在当前任务之后 )。


这一方案简单可靠,而且得到的确实是真正的帧率数据。


在 Android 7.0 及以上版本,JankStats 则直接通过 Window 的新方法 addOnFrameMetricsAvailableListener,注册回调得到每一帧的详细数据 FrameMetrics。
FrameMetrics 的数据统计具体是怎么实现的?简单来说,Android 官方在整个绘制渲染流程上都做了打点来支持 FrameMetrics 的数据统计逻辑,具体包括了



  • 基于 Choreographer 记录了 VSync,Input,Animation,Traversal 的起始时间点

  • 基于 ViewRootImpl 记录了 Draw 的起始时间点( 结合 Traversal 区分开了 MeasureLayout 和 Draw 两段耗时 )

  • 基于 CanvasContext( hwui 中 RenderThread 的渲染流程 )记录了 SyncDisplayList,IssueDrawCommand,SwapBuffer 等时间点,Android 12 上更是进一步支持了 GPU 上的耗时统计


可以看到,FrameMetrics 提供了以往方案难以给到的详细分阶段耗时( 特别注意 FrameMetrics 提供的数据存在系统版本间的差异,具体的数据处理可以参考 JankStats 的内部实现 ),而且在内部实现上,相关数据在绘制渲染流程上默认便会被统计( 即使我们不注册监听 ),基于 FrameMetrics 来做帧率计算在数据采集阶段带来的额外性能开销微乎其微。


帧率相关指标设计


简单的 FPS( 平均帧率 )数据并不能很好的衡量卡顿。在能够准确采集到帧数据之后,怎么基于采集到的数据做进一步处理得到更有实际价值的指标才是更为关键的。


Android Vitals 方案


Android Vitals 本身只定义了两个指标,基于单帧耗时简单区分了卡顿问题的严重程度。将耗时大于 16ms 的帧定义为慢帧,将耗时大于 700ms 的帧定义为冻帧。


JankStats 方案


JankStats 的实现上,则默认将单帧耗时在期望耗时 2 倍以上的情况视为卡顿( 即满帧 60FPS 的情况,将单帧耗时超过 33.3ms 的情况定义为卡顿 )。


Matrix 方案


Matrix 的指标设计则在 Android Vitals 的基础上做了进一步细分,以掉帧数为量化指标( 即满帧 60FPS 的情况,将单帧耗时在 16.6ms 到 33.3ms 间的情况定义为掉一帧 ),将帧耗时细化为 Best / Normal / Middle / High / Frozen 多类情况,其中 Frozen 实际对应的就是 Android Vitals 中的冻帧。


可以看到以上三者都是基于单帧耗时本身而非平均帧率来衡量卡顿。


手淘方案


手淘的方案则给出了更多的指标。


基于帧率数据本身的,细分场景定义了滑动帧率和卡顿帧率。
滑动帧率比较好理解;
卡顿帧率指的是,在出现卡顿帧( 定义为单帧耗时 33.3ms 以上 )之后,持续统计一段时间的帧耗时( 直到达到 99.6ms ( 6 帧 )并且下一帧不是卡顿帧 )来计算帧率,通过单独统计以卡顿帧为起点的细粒度帧率来避免卡顿被平均帧率掩盖的问题。和前面几个方案相比,卡顿帧率的特点在于一定程度上保留了帧数据的时间属性,一定程度上可以区分出离散的卡顿帧和连续的卡顿。


基于单帧耗时的,将冻帧占比( 即大于 700 ms 的帧占总帧数的比例 )作为独立指标;此外还有参考 iOS 定义的 scrollHitchRate,即滑动场景下,预期外耗时( 即每一帧超过期望耗时部分的累加 )的占比。


此外,得益于 FrameMetrics 的详细数据,手淘的方案还实现了简单的自动化归因,即基于 FrameMetrics 的分阶段耗时数据简单判断是哪个阶段导致了当前这一帧的卡顿。


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

超好用的官方core-ktx库,了解一下(终)~

ktx
Handler.postDelayed()简化lambda传入 不知道大家在使用Handler下的postDelayed()方法是不是感觉很不简洁,我们看下这个函数源码:public final boolean postDelayed(@NonNull Run...
继续阅读 »

Handler.postDelayed()简化lambda传入


不知道大家在使用Handler下的postDelayed()方法是不是感觉很不简洁,我们看下这个函数源码:

public final boolean postDelayed(@NonNull Runnable r, long delayMillis) {
return sendMessageDelayed(getPostMessage(r), delayMillis);
}

可以看到Runnable类型的参数r放在第一位,在Kotlin中我们就无法利用其提供的简洁的语法糖,只能这样使用:

private fun test11(handler: Handler) {
handler.postDelayed({
//编写代码逻辑
}, 100)
}

有没有感觉很别扭,估计官方也发现了这个问题,就提供了这样一个扩展方法:

public inline fun Handler.postDelayed(
delayInMillis: Long,
token: Any? = null,
crossinline action: () -> Unit
): Runnable {
val runnable = Runnable { action() }
if (token == null) {
postDelayed(runnable, delayInMillis)
} else {
HandlerCompat.postDelayed(this, runnable, token, delayInMillis)
}
return runnable
}

可以看到将函数类型(相当于上面的Runnable中的代码执行逻辑)放到了方法参数的最后一位,这样利用kotlin的语法糖就可以这样使用:

private fun test11(handler: Handler) {
handler.postDelayed(200) {

}
}

可以看到这个函数类型使用了crossinline修饰,这个是用来加强内联的,因为其另一个Runnable的函数类型中进行了调用,这样我们就无法在这个函数类型action中使用return关键字了(return@标签除外),避免使用return关键字带来返回上的歧义不稳定性


除此之外,官方core-ktx还提供了类似的扩展方法postAtTime()方法,使用和上面一样!!


Context.getSystemService()泛型实化获取系统服务


看下以往我们怎么获取ClipboardManager:

private fun test11() {
val cm: ClipboardManager = getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
}

看下官方提供的方法:

public inline fun <reified T : Any> Context.getSystemService(): T? =
ContextCompat.getSystemService(this, T::class.java)

借助于内联泛型实化简化了获取系统服务的代码逻辑:

private fun test11() {
val cm: ClipboardManager? = getSystemService()
}

泛型实化的用处有很多应用场景,大家感兴趣可以参考我另一篇文章:Gson序列化的TypeToken写起来太麻烦?优化它


Context.withStyledAttributes简化操作自定义属性


这个扩展一般只有在自定义View中较常使用,比如读取xml中设置的属性值,先看下我们平常是如何使用的:

private fun test11(
@NonNull context: Context,
@Nullable attrs: AttributeSet,
defStyleAttr: Int
) {
val ta = context.obtainStyledAttributes(
attrs, androidx.cardview.R.styleable.CardView, defStyleAttr,
androidx.cardview.R.style.CardView
)
//获取属性执行对应的操作逻辑
val tmp = ta.getColorStateList(androidx.cardview.R.styleable.CardView_cardBackgroundColor)

ta.recycle()
}

在获取完属性值后,还需要调用recycle()方法回收TypeArray,这个一旦忘记写就不好了,能让程序保证的写法那就尽量避免人为处理,所以官方提供了下面的扩展方法:

public inline fun Context.withStyledAttributes(
@StyleRes resourceId: Int,
attrs: IntArray,
block: TypedArray.() -> Unit
) {
obtainStyledAttributes(resourceId, attrs).apply(block).recycle()
}

使用如下:

private fun test11(
@NonNull context: Context,
@Nullable attrs: AttributeSet,
defStyleAttr: Int
) {
context.withStyledAttributes(
attrs, androidx.cardview.R.styleable.CardView, defStyleAttr,
androidx.cardview.R.style.CardView
) {
val tmp = getColorStateList(androidx.cardview.R.styleable.CardView_cardBackgroundColor)
}
}

上面的写法就保证了recycle()不会漏写,并且带接收者的函数类型block: TypedArray.() -> Unit也能让我们省略this直接调用TypeArray中的公共方法。


SQLiteDatabase.transaction()自动开启事务读写数据库


平常对SQLite进行写操作时为了效率及安全保证需要开启事务,一般我们都会手动进行开启和关闭,还是那句老话,能程序自动保证的事情就尽量避免手动实现,所以一般我们都会封装一个事务开启和关闭的方法,如下:

private fun writeSQL(sql: String) {
SQLiteDatabase.beginTransaction()
//执行sql写入语句
SQLiteDatabase.endTransaction()
}

官方core-ktx也提供了相似的扩展方法:

public inline fun <T> SQLiteDatabase.transaction(
exclusive: Boolean = true,
body: SQLiteDatabase.() -> T
): T {
if (exclusive) {
beginTransaction()
} else {
beginTransactionNonExclusive()
}
try {
val result = body()
setTransactionSuccessful()
return result
} finally {
endTransaction()
}
}

大家可以自行选择使用!


<K : Any, V : Any> lruCache()简化创建LruCache


LruCache一般用作数据缓存,里面使用了LRU算法来优先淘汰那些近期最少使用的数据。在Android开发中,我们可以使用其设计一个Bitmap缓存池,感兴趣的可以参考Glide内存缓存这块的源码,就利用了LruCache实现。


相比较于原有创建LruCache的方式,官方库提供了下面的扩展方法简化其创建流程:

inline fun <K : Any, V : Any> lruCache(
maxSize: Int,
crossinline sizeOf: (key: K, value: V) -> Int = { _, _ -> 1 },
@Suppress("USELESS_CAST")
crossinline create: (key: K) -> V? = { null as V? },
crossinline onEntryRemoved: (evicted: Boolean, key: K, oldValue: V, newValue: V?) -> Unit =
{ _, _, _, _ -> }
): LruCache<K, V> {
return object : LruCache<K, V>(maxSize) {
override fun sizeOf(key: K, value: V) = sizeOf(key, value)
override fun create(key: K) = create(key)
override fun entryRemoved(evicted: Boolean, key: K, oldValue: V, newValue: V?) {
onEntryRemoved(evicted, key, oldValue, newValue)
}
}
}

看下使用:

private fun createLRU() {
lruCache<String, Bitmap>(3072, sizeOf = { _, value ->
value.byteCount
}, onEntryRemoved = { evicted: Boolean, key: String, oldValue: Bitmap, newValue: Bitmap? ->
//缓存对象被移除的回调方法
})
}

可以看到,比之手动创建LruCache要稍微简单些,能稍微节省下使用成本。


bundleOf()快捷写入并创建Bundle对象


image.png


bundleOf()方法的参数被vararg声明,代表一个可变的参数类型,参数具体的类型为Pair,这个对象我们之前的文章有讲过,可以借助中缀表达式函数to完成Pair的创建:

private fun test12() {
val bundle = bundleOf("a" to "a", "b" to 10)
}

这种通过传入可变参数实现的Bundle如果大家不太喜欢,还可以考虑自行封装通用扩展函数,在函数类型即lambda中实现更加灵活的Bundle创建及写入:


1.自定义运算符重载方法set实现Bundle写入:

operator fun Bundle.set(key: String, value: Any?) {
when (value) {
null -> putString(key, null)

is Boolean -> putBoolean(key, value)
is Byte -> putByte(key, value)
is Char -> putChar(key, value)
is Double -> putDouble(key, value)
is Float -> putFloat(key, value)
is Int -> putInt(key, value)
is Long -> putLong(key, value)
is Short -> putShort(key, value)

is Serializable -> putSerializable(key, value)
//其实数据类型自定参考bundleOf源码实现
}
}

2.自定义BundleBuild支持向Bundle写入多个值

class BundleBuild(private val bundle: Bundle) {

infix fun String.to(that: Any?) {
bundle[this] = that
}
}

其中to()方法使用了中缀表达式的写法


3.暴漏扩展方法实现在lambda中完成Bundle的写入和创建

private fun bundleOf(block: BundleBuild.() -> Unit): Bundle {
return Bundle().apply {
BundleBuild(this).apply(block)
}
}

然后就可以这样使用:

private fun test12() {
val bundle = bundleOf {
"a" to "haha"
//经过一些逻辑操作获取结果后在写入Bundle
val t1 = 10 * 5
val t2 = ""
t2 to t1
}
}

相比较于官方库提供的bundleOf()提供的创建方式,通过函数类型也就是lambda创建并写入Bundle的方式更加灵活,并内部支持执行操作逻辑获取结果后再进行写入。


总结


关于官方core-ktx的研究基本上已经七七八八了,总共输出了五篇相关文章,对该库了解能够节省我们编写模板代码的时间,提高开发效率,大家如果感觉写的不错,可以点个赞支持下哈,感谢!!


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

咱不吃亏,也不能过度自卫

我之前写了一篇《吃亏不是福》,主要奉劝大家不要吃亏。这属于保护弱者的一面。 这次我谈谈不吃亏的一种人,他们不吃亏近乎强硬。这类人一点亏都不吃,以至于过度自我保护。 我们公司人事小刘负责考勤统计。发完考勤表之后,有个员工找到他,说出勤少统计了一天。 小刘一听,感...
继续阅读 »

我之前写了一篇《吃亏不是福》,主要奉劝大家不要吃亏。这属于保护弱者的一面。


这次我谈谈不吃亏的一种人,他们不吃亏近乎强硬。这类人一点亏都不吃,以至于过度自我保护。


我们公司人事小刘负责考勤统计。发完考勤表之后,有个员工找到他,说出勤少统计了一天。


小刘一听,感觉自己有被指控的风险。


他立刻严厉起来:“每天都来公司,不一定就算全勤。没打卡我是不统计的”。


最后小刘一查,发现是自己统计错了。


小刘反而更加强势了:“这种事情,你应该早点跟我反馈,而且多催着我确认。你自己的事情都不上心,扣个钱啥的只能自己兜着”


这就是明显的不愿意吃亏,即使自己错了,也不愿意让自己置于弱势。


你的反应,决定别人怎么对你。这种连言语的亏都不吃的人,并不会让别人敬畏,反而会让人厌恶,进而影响沟通


我还有一个同事老王。他是一个职场老人,性格嘻嘻哈哈,业务能力也很强。


以前同事小赵和老王合作的时候,小赵宁愿经两层人传话给老王,也不愿意和他直接沟通。


我当时感觉小赵不善于沟通。


后来,当我和老王合作的时候,才体会到小赵的痛苦。


因为,老王是一个什么亏都不吃的人,谁来找他理论,他就怼谁。


你告诉他有疏漏,他会极力掩盖问题,并且怒怼你愚昧无知。


就算你告诉他,说他家着火了。他首先说没有。你一指那不是烧着的吗?他回复,你懂个屁,你知道我几套房吗?我说的是我另一个家没着火。


有不少人,从不吃亏,无论什么情况,都不会让自己处于弱势。


这类人喜欢大呼小叫,你不小心踩他脚了,他会大喊:践踏我的尊严,和你拼了!


心理学讲,愤怒源于恐惧,因为他想逃避当前不利的局面


人总会遇到各种不公的待遇,或误会,或委屈。


遇到争议时,最好需要确认一下,排除自己的问题。


如果自己没错,那么比较好的做法就是:“我认为你说得不合理,首先……其次……最后……”。


不盲目服软,也不得理不饶人,全程平心静气,有理有据。这种人绝对人格魅力爆棚,让人敬佩。


最后,有时候过度强硬也是一种策略,可以很好地过滤和震慑一些不重要的事物。


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

抽象类与抽象方法

类到对象是实例化。对象到类是抽象。 抽象类: 1.什么是抽象类? 类和类之间具有共同特征,将这些共同特征提取出来,形成的就是抽象类。 类本身是不存在的,所以抽象类无法创建对象(无法实例化) 2.抽象类属于什么类型?抽象类也属于引用数据类型。 3.抽象类怎么定义...
继续阅读 »

类到对象是实例化。对象到类是抽象。


抽象类:
1.什么是抽象类?
类和类之间具有共同特征,将这些共同特征提取出来,形成的就是抽象类。
类本身是不存在的,所以抽象类无法创建对象(无法实例化)


2.抽象类属于什么类型?抽象类也属于引用数据类型。


3.抽象类怎么定义?@#^%&^^&^%
语法:
(修饰符列表)abstract class类名{类体}


4.抽象类是无法实例化的,无法创建对象的,所以抽象类是用来被子类继承的。


5.final和abstract不能联合使用,这两个关键字是对立的。


6.抽象类的子类可以是抽象类。


7.抽象类虽然无法实例化,但是抽象类有构造方法,这个构造方法提供子类使用的。


8.抽象类关联到一个概念,抽象方法,什么是抽象方法呢?
抽象方法标识没有实现的方法,没有方法体的方法。例如:
public abstract void dosome();


9.抽象方法的类必须是抽象类,抽象类的方法不一定要是抽象方法。
抽象方法的特点是:特点1:没有方法体,以分号结尾。特点2:前面修饰符列表中有abstract关键字


10.抽象类中不一定有抽象方法,但抽象方法必须出现在抽象类中


11.非抽象方法集成抽象类,必须重写抽象类里的方法,如果是抽象类继承抽象类,那么就不一定要重写父类的方法


1663425406511.jpg

public abstract class AbstractTest extends AbstractChildTest{
/**
* 类到对象是实例化。对象到类是抽象
*
*/
public static void main(String[] args) {

}

@Override
void Bird() {

}
}
abstract class AbstractChildTest{
//子类继承抽象类
abstract void Bird();
}

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

检测zip文件完整(进阶:APK文件渠道号)

zip
朋友聊天讨论到一个问题,怎么检测zip的完整性。zip是我们常用的压缩格式,不管是Win/Mac/Linux下都很常用,我们做文件的下载也会经常用到,网络充满不确定性,对于多个小文件(比如配置文件)的下载,我们希望只发起一次连接,因为建立连接是很耗费资源的,即...
继续阅读 »

朋友聊天讨论到一个问题,怎么检测zip的完整性。zip是我们常用的压缩格式,不管是Win/Mac/Linux下都很常用,我们做文件的下载也会经常用到,网络充满不确定性,对于多个小文件(比如配置文件)的下载,我们希望只发起一次连接,因为建立连接是很耗费资源的,即使现在http2.0可以对一条TCP连接进行复用,我们还是希望网络请求的次数越少越好,不管是对于稳定性还是成功失败的逻辑判断,都会有益处。


这个时候我们常用的其实就是把他们压缩成一个zip文件,下载下来之后解压就好了。


但很多时候zip会解压失败,如果我们的zip已经下载下来了,其实不存在没有访问权限的问题了,那原因除了空间不够之外,就是zip格式有问题了,zip文件为空或者只下载了一半。

这个时候就需要检测一下我们下载下来的zip是不是合法有效的zip了。

有这么几种思路:



  1. 直接解压,抛异常表明zip有问题

  2. 下载前得到zip文件的length,下载后检测文件大小

  3. 使用md5或sha1等摘要算法,下载下来后做md5,然后比对合法性

  4. 检测zip文件结尾的特殊编码格式,检测是否zip合法


这几种做法有利有弊,这里我们只看第4种。

我们讨论之前,可以大致了解一下zip的格式ZIP文件格式分析,我们关注的是End of central directory record,核心目录结束标记,每个zip只会出现一次。



































































OffsetBytesDescription
04End of central directory signature = 0x06054b50核心目录结束标记(0x06054b50)
42Number of this disk当前磁盘编号
62number of the disk with the start of the central directory核心目录开始位置的磁盘编号
82total number of entries in the central directory on this disk该磁盘上所记录的核心目录数量
102total number of entries in the central directory核心目录结构总数
124Size of central directory (bytes)核心目录的大小
164offset of start of central directory with respect to the starting disk number核心目录开始位置相对于archive开始的位移
202.ZIP file comment length(n)注释长度
22n.ZIP Comment注释内容

我们可以看到,0x06054b50所在的位置其实是在zip.length减去22个字节,所以我们只需要seek到需要的位置,然后读4个字节看是否是0x06054b50,就可以确定zip是否完整。

下面是一个判断的代码

        //没有zip文件注释时候的目录结束符的偏移量
private static final int RawEndOffset = 22;
//0x06054b50占4个字节
private static final int endOfDirLength = 4;
//目录结束标识0x06054b50 的小端读取方式。
private static final byte[] endOfDir = new byte[]{0x50, 0x4B, 0x05, 0x06};

private boolean isZipFile(File file) throws IOException {
if (file.exists() && file.isFile()) {
if (file.length() <= RawEndOffset + endOfDirLength) {
return false;
}
long fileLength = file.length();
RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
//seek到结束标记所在的位置
randomAccessFile.seek(fileLength - RawEndOffset);
byte[] end = new byte[endOfDirLength];
//读取4个字节
randomAccessFile.read(end);
//关掉文件
randomAccessFile.close();
return isEndOfDir(end);
} else {
return false;
}
}

/**
* 是否符合文件夹结束标记
*/
private boolean isEndOfDir(byte[] src) {
if (src.length != endOfDirLength) {
return false;
}
for (int i = 0; i < src.length; i++) {
if (src[i] != endOfDir[i]) {
return false;
}
}
return true;
}

有人可能注意到了,你上面写的结束标识明明是0x06054b50,为什么检测的时候是反着写的。这里就涉及到一个大端小端的问题,录音的时候也能会遇到大小端顺序的问题,反过来读就好了。


涉及到二进制的查看和编辑,我们可以使用010editor这个软件来查看文件的十六进制或者二进制,并且可以手动修改某个位置的二进制。





他的界面大致长这样子,小端显示的,我们可以看到我们要得到的06 05 4b 50


我们看上面的表格里面最后一个表格里的 .ZIP file comment length(n).ZIP Comment ,意思是描述长度是两个字节,描述长度是n,表示这个长度是可变的。这个有啥作用呢?

其实就是给了一个可以写额外的描述数据的地方(.ZIP Comment),他的长度由前面的.ZIP file comment length(n)来控制。也就是zip允许你在它的文件结尾后面额外的追加内容,而不会影响前面的数据。描述文件的长度是两个字节,也就是一个short的长度,所以理论上可以寻址2^16^个位置。

举个例子:

修改之前:

修改之前


修改之后

修改之后

看上面两个文件,修改之前长度为0,我们把它改成2(注意大小端),我们改成2,然后随便在后面追加两个byte,保存,打开修改之后的zip,发现是可以正常运行的,甚至我们可以在长度是2的基础上追加多个byte,其实还是可以打开的。

所以回到标题内容,其实apk就是zip,我们同样可以在apk的Comment后面追加内容,比如可以当做渠道来源,或者完成这样的需求:h5网页A上下载的需要打开某个ActivityA,h5网页B上下载的需要打开某个ActivityB。


原理还是上面的原理,写入渠道或者配置,读取apk渠道或者配置,做相应统计或者操作。

        //magic -> yocn
private static final byte[] MAGIC = new byte[]{0x79, 0x6F, 0x63, 0x6E};
//没有zip文件注释时候的目录结束符的偏移量
private static final int RawEndOffset = 22;
//0x06054b50占4个字节
private static final int endOfDirLength = 4;
//目录结束标识0x06054b50 的小端读取方式。
private static final byte[] endOfDir = new byte[]{0x50, 0x4B, 0x05, 0x06};
//注释长度占两个字节,所以理论上可以支持 2^16 个字节。
private static final int commentLengthBytes = 2;
//注释长度
private static final int commentLength = 8;

private boolean isZipFile(File file) throws IOException {
if (file.exists() && file.isFile()) {
if (file.length() <= RawEndOffset + endOfDirLength) {
return false;
}
long fileLength = file.length();
RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r");
//seek到结束标记所在的位置
randomAccessFile.seek(fileLength - RawEndOffset);
byte[] end = new byte[endOfDirLength];
//读取4个字节
randomAccessFile.read(end);
//关掉文件
randomAccessFile.close();
return isEndOfDir(end);
} else {
return false;
}
}

/**
* 是否符合文件夹结束标记
*/
private boolean isEndOfDir(byte[] src) {
if (src.length != endOfDirLength) {
return false;
}
for (int i = 0; i < src.length; i++) {
if (src[i] != endOfDir[i]) {
return false;
}
}
return true;
}

/**
* zip(apk)尾追加渠道信息
*/
private void write2Zip(File file, String channelInfo) throws IOException {
if (isZipFile(file)) {
long fileLength = file.length();
RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
//seek到结束标记所在的位置
randomAccessFile.seek(fileLength - commentLengthBytes);
byte[] lengthBytes = new byte[2];
lengthBytes[0] = commentLength;
lengthBytes[1] = 0;
randomAccessFile.write(lengthBytes);
randomAccessFile.write(getChannel(channelInfo));
randomAccessFile.close();
}
}

/**
* 获取zip(apk)文件结尾
*
* @param file 目标哦文件
*/
private String getZipTail(File file) throws IOException {
long fileLength = file.length();
RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r");
//seek到magic的位置
randomAccessFile.seek(fileLength - MAGIC.length);
byte[] magicBytes = new byte[MAGIC.length];
//读取magic
randomAccessFile.read(magicBytes);
//如果不是magic结尾,返回空
if (!isMagicEnd(magicBytes)) return "";
//seek到读到信息的offest
randomAccessFile.seek(fileLength - commentLength);
byte[] lengthBytes = new byte[commentLength];
//读取渠道
randomAccessFile.read(lengthBytes);
randomAccessFile.close();
char[] lengthChars = new char[commentLength];
for (int i = 0; i < commentLength; i++) {
lengthChars[i] = (char) lengthBytes[i];
}
return String.valueOf(lengthChars);
}

/**
* 是否以魔数结尾
*
* @param end 检测的byte数组
* @return 是否结尾
*/
private boolean isMagicEnd(byte[] end) {
for (int i = 0; i < end.length; i++) {
if (MAGIC[i] != end[i]) {
return false;
}
}
return true;
}

/**
* 生成渠道byte数组
*/
private byte[] getChannel(String s) {
byte[] src = s.getBytes();
byte[] channelBytes = new byte[commentLength];
System.arraycopy(src, 0, channelBytes, 0, commentLength);
return channelBytes;
}

//读取源apk的路径
public static String getSourceApkPath(Context context, String packageName) {
if (TextUtils.isEmpty(packageName))
return null;
try {
ApplicationInfo appInfo = context.getPackageManager().getApplicationInfo(packageName, 0);
return appInfo.sourceDir;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
return null;
}

这里使用了一个魔数的概念,表明是否是写入了我们特定的渠道,只有写了我们特定渠道的基础上才会去读取,防止读到了没有写过的文件。

读取渠道的时候首先获取安装包的绝对路径。Android系统在用户安装app时,会把用户安装的apk拷贝一份到/data/apk/路径下,通过getSourceApkPath 可以获取该apk的绝对路径。如果使用rw可能会有权限问题,所以读取的时候只使用r就可以了。


参考:
ZIP文件格式分析
全民K歌增量升级方案


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

由浅入深,详解 Lifecycle 生命周期组件的那些事

Hi , 你好 :) 引言 在2022的今天,AndroidX 普遍的情况下,JetPack Lifecycle 也早已经成为了开发中的基础设施,小到 View(扩展库) ,大到 Activity,都隐藏着它的身影,而了解 Lifecycle 也正是理解 Je...
继续阅读 »

Hi , 你好 :)


引言


在2022的今天,AndroidX 普遍的情况下,JetPack Lifecycle 也早已经成为了开发中的基础设施,小到 View(扩展库) ,大到 Activity,都隐藏着它的身影,而了解 Lifecycle 也正是理解 JetPack 组件系列库生命感知设计的基础。



本篇定位中级,将从背景到源码实现,从而理解其背后的设计思想。



导航


看完本篇,你将会搞清以下问题:



  • Lifecycle 的前世今生;

  • Lifecycle 可以干什么;

  • Lifecycle 源码解析;


背景


在开始前,我们先聊聊关于 Lifecycle 的前世今生,从而便于我们更好的理解 Lifecycle 存在的意义。


洪荒之时


Lifecycle 之前(不排除现在😂),如果我们要在某个生命周期去执行一些操作时,经常会在Act或者Fragment写很多模版代码,如下两个示例:



  1. 比如,有一个定时器,我们需要在 Activity 关闭时将其关闭,从而避免因此导致的内存问题,所以我们自然会在 onDestory() 中去stop一下。这些事看起来似乎不麻烦,但如果是一个重复多处使用的代码,细心的开发者会将其单独抽离成为一个 case ,从而通过组合的方式降低我们主类中的逻辑,但不可避免我们依然还要存在好多模版代码,因为每次都需要 onStop() 清理或者其他操作(除非写到base,但不可接受☹️)。


📌 如果能不需要开发者自己手动,该有多好?



  1. 在老版本的友盟中,我们经常甚至需要在基类的 Activity 中复写 onResume()onPause() 等方法,这些事情说麻烦也不麻烦,但总是感觉很不舒服。不过,有经验的开发者肯定会想喷,为什么一个三方库,你就自己不会通过application.registerActivityLifecycleCallbacks 监听吗🤌🏼。


📌 注意,Application有监听全局Act生命周期的方法,Act也有这个方法。🤖


盘古开天


JetPack 之前,Android 一直秉承着传统的 MVC 架构,即 xml 作为 View, Activity 作为 ControlModel 层由数据模型或者仓库而定。虽然说官方曾经有一个MVP的示例,但真正用的人并不多。再加上官方一直也没推荐过 Android 的架构指南,这就导致传统的Android开发方式和系统的碎片化一样☹️,五花八门。随着时间的推移,眼看前端的MVVM已愈加成熟,后有Flutter,再加上开发者的需求等背景下,Google于2017年发布了新的开发架构: AAC,全名 Architecture,并且伴随着一系列相关组件,从而帮助开发者提高开发体验,降低错误概率,减少模版代码。


而本篇的主题 Lifecycle 正是其中作为基础设施的存在,在 sdk26 之后,更是被写入了基础库中。


那Lifecycle到底是干什么的呢?



Lifecycle 做的事情很简单,其就是用于检测组件(FragmentAct) 的生命周期,从而不必强依赖于 ActivityFragment ,帮助开发者降低模版代码。



常见用法


在官网中,对于 Lifecycle 的生命周期感知的整个流程如下所示:


image.png




Api介绍


相关字段




  • Event


    生命周期事件,对应具体的生命周期:


    ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_ANY




  • State


    生命周期状态节点,与 Event 紧密关联,Event 是这些结点的具体边界,换句话说,State 代表了这一时刻的具体状态,其相当于一个范围集,在这个范围里,都是这个状态。而Event代表这一状态集里面触发的具体事件是什么。


    INITIALIZED

    构造函数初始化时,且未收到 `onCreate()` 事件时的状态;

    CREATED

    在 `onCreate()` 调用之后,`onStop()` 调用之前的状态;

    STARTED

    在 `onStart()` 调用之后,`onPause()` 调用之前的状态;



RESUMED

    在 `onResume()` 调用时的状态;

`DESTROYED`

`onDestory()` 调用时的状态;

相关接口




  • LifecycleObserver


    基础 Lifecycler 实现接口,一般调用不到,可用于自定义的组件,从而避免在 Act 或者 Fragment 中的模版代码,例如ViewTreeLifecyleOwner




  • LifecycleEventObserver


    可以接受所有生命周期变化的接口;




  • FullLifecycleObserver


    用于监听生命周期变化的接口,提供了 onCreate()onStart()onPause()onStop()onDestory()onAny();




  • DefaultLifecycleObserver


    FullLifecycleObserver 的默认实现版本,相比前者,增加了默认 null 实现;






举个栗子


如下所示,通过实现 DefaultLifecycleObserver 接口,我们可以在中重写我们想要监听的生命周期方法,从而将业务代码从主类中拆离出来,且更便于复用。最后在相关类中直接使用 lifecycle.addObserver() 方法添加实例即可,这也是google推荐的用法。


image.png



上述示例中,我们使用了 viewLifecycle ,而不是 lifecycle ,这里顺便提一下。


见名之意,前者是视图(view)生命周期,后者则是非视图的生命周期,具体区别如下:


viewLifecycle 只会在 onCreateView-onDestroyView 之间有效。


lifecycle 则是代表 Fragment 的生命周期,在视图未创建时,onCreate(),onDestory() 时也会被调用到。





或者你有某个自定义View,想感知Fragment或者Act的生命周期,从而做一些事情,比如Banner组件等,与上面示例类似:


image.png



当然你也可以选择依赖:androidx.lifecycle:lifecycle-runtime 扩展库。


从而使用 view.findViewTreeLifecycleOwner() 的扩展函数获得一个 LifecycleOwner,从而在View内部自行监听生命周期,免除在Activity手动添加观察者的模版代码。


lifecycle.addObserver(view)



源码解析


Lifecycle



在官方的解释里,Lifecycle 是一个类,用于存储有关组件(Act或Fragment)声明周期状态新的类,并允许其他对象观察此类。



直接去看 Lifecycle 的源码,其实现方式如下:


image.png
总体设计如上所示,比较简单,就是观察者模式的接口模版:



使用者实现 LifecycleObserver 接口(),然后调用 addObserver() 添加到观察者列表,取消观察者时调用 rmeoveObserver() 移除掉即可。在相应的生命周期变动时,遍历观察者列表,然后通知实现了 LifecycleObserver 的实例,从而调用相应的方法。



因为其是一个抽象类,所以我们调用的一般都是它的具体实现类,也就是 LifecycleRegistry ,目前也是其的唯一实现类。




LifecycleRegistry


Lifecycle 的具体实现者,正如其名所示,主要用于管理当前订阅的 观察者对象 ,所以也承担了 Lifecycle 具体的实现逻辑。因为源码较长,所以我们做了一些删减,只需关注主流程即可,伪代码如下:

public class LifecycleRegistry extends Lifecycle {

// 生命周期观察者map,LifecycleObserver是观察者接口,ObserverWithState具体的状态分发的包装类
   private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap;
// 当前生命周期状态
   private State mState = INITIALIZED;
// 持有生命周期的提供商,Activity或者Fragment的弱引用
   private final WeakReference<LifecycleOwner> mLifecycleOwner;
// 当前正在添加的观察者数量,默认为0,超过0则认为多线程调用
   private int mAddingObserverCounter = 0;
// 是否正在分发事件
   private boolean mHandlingEvent = false;
// 是否有新的事件产生
   private boolean mNewEventOccurred = false;
// 存储主类的事件state
   private ArrayList<State> mParentStates = new ArrayList<>();

   @Override
   public void addObserver(@NonNull LifecycleObserver observer) {
       // 初始化状态,destory or init
       State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    // 📌 初始化实际分发状态的包装类
       ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    // 将观察者添加到具体的map中,如果已经存在了则返回之前的,否则创建新的添加到map中
       ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
// 如果上一步添加成功了,putIfAbsent会返回null
       if (previous != null) {
           return;
      }
    // 如果act或者ff被回收了,直接return
       LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
       if (lifecycleOwner == null) {
           return;
      }
// 当前添加的观察者数量!=0||正在处理事件
       boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    // 📌 取得观察者当前的状态
       State targetState = calculateTargetState(observer);
       mAddingObserverCounter++;
    // 📌 如果当前观察者状态小于当前生命周期所在状态&&这个观察者已经被存到了观察者列表中
       while ((statefulObserver.mState.compareTo(targetState) < 0
               && mObserverMap.contains(observer))) {
        // 保存当前的生命周期状态
           pushParentState(statefulObserver.mState);
        // 返回当前生命周期状态对应的接下来的事件序列
           final Event event = Event.upFrom(statefulObserver.mState);
          ...
           // 分发事件
           statefulObserver.dispatchEvent(lifecycleOwner, event);
        // 移除当前的生命周期状态
           popParentState();
           // 再次获得当前的状态,以便继续执行
           targetState = calculateTargetState(observer);
      }

    // 处理一遍事件,保证事件同步
       if (!isReentrance) {
           sync();
      }
    // 回归默认值
       mAddingObserverCounter--;
  }
...
   static class ObserverWithState {
       State mState;
       LifecycleEventObserver mLifecycleObserver;

       ObserverWithState(LifecycleObserver observer, State initialState) {
        // 初始化事件观察者
           mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
           mState = initialState;
      }

       void dispatchEvent(LifecycleOwner owner, Event event) {
           State newState = event.getTargetState();
           mState = min(mState, newState);
           mLifecycleObserver.onStateChanged(owner, event);
           mState = newState;
      }
  }
...
}

我们重点关注的是 addObserver() 即订阅生命周期变更时的逻辑,具体如下:



  1. 先初始化当前观察者的状态,默认两种,即 DESTROYED(销毁) 或者 INITIALIZED(无效),分别对应 onDestory()onCreate() 之前;

  2. 初始化 状态观察者(ObserverWithState) ,内部使用 Lifecycling.lifecycleEventObserver() 将我们传递进来的 生命周期观察者(LifecycleObser) 包装为一个 生命周期[事件]观察者LifecycleEventObserver,从而在状态变更时触发事件通知;

  3. 将第二步生成的状态观察者添加到缓存map中,如果之前已经存在,则停止接下来的操作,否则继续初始化;

  4. 调用 calculateTargetState() 获得当前真正的状态。

  5. 开始事件轮训,如果 当前观察者的状态小于此时真正的状态 && 观察者已经被添加到了缓存列表 中,则获得当前观察者下一个状态,并触发相应的事件通知 dispatchEvent(),然后继续轮训。直到不满足判断条件;



需要注意的是, 关于状态的判断,这里使用了compareTo() ,从而判断当前状态枚举是否小于指定状态。





Activity中的实现


Tips:


写过权限检测库的小伙伴,应该很熟悉,为了避免在 Activity 中手动实现 onActivityRequest() ,从而实现以回调的方式获得权限结果,我们往往会使用一个透明的 Fragment ,从而将模版方法拆离到单独类中,而这种实现方式正是组合的思想。


LifecycleActivity 中的实现正是上述的方式。




如下所示,当我们在 Activity 中调用 lifecycle 对象时,内部实际上是调用了 ComponentActivity.mLifecycleRegistry,具体逻辑如下:


image.png
不难发现,在我们的 Activity 初始化时,相应的 LifecycleRegistry 已经被初始化。


在上面我们说过,为了避免对基类的入侵,我们一般会用组合的方式,所以这里的 ReportFragment 正是 LifecycleActivity 中具体的逻辑承载方,具体逻辑如下:


ReportFragment.injectIfNeededIn


image.png


内部会对sdk进行判断,对应着两套流程,对于 sdk>=29 的,通过注册 Activity.registerActivityLifecycleCallbacks() 事件实现监听,对于 sdk<29 的,重写 Fragment 相应的生命周期方法完成。


ReportFragment 具体逻辑如下:


image.png




Fragment中的实现


直接去 Fragment.lifecycle 中看一下即可,伪代码如下:


image.png


总结如下:lifecycle 实例会在 Fragment 构造函数 中进行初始化,而 mViewLifecycleOwner 会在 performCreateView() 执行时初始化,然后在相应的 performXxx 生命周期执行时,调用相应的 lifecycle.handleLifecycleEvent() 从而完成事件的通知。


总结


Lifecycle 作为 JetPack 的基石,而理解其是我们贯穿相应生命周期的关键所在。


关于生命周期的通知,Lifecycle 并没有采用直接通知的方式,而是采用了 Event(事件) + State(状态) 的设计方式。




  • 对于外部生命周期订阅者而言,只需要关注事件 Event 的调用;

  • 而对于Lifecycle而言,其内部只关注 State ,并将生命周期划分为了多个阶段,每个状态又代表了一个事件集,从而对于外部调用者而言,无需拘泥于当前具体的状态是什么。



在具体的实现底层上面:




  • Activity 中,采用组合的方式而非继承,在 Activity.onCreate() 触发时,初始化了一个透明Fragment,从而将逻辑存于其中。对于sdk>=29的版本,因为 Activity 本身有监听生命周期的方法,从而直接注册监听器,并在相应的会调用触发生命周期事件更新;对于sdk<29的版本,因为需要兼容旧版本,所以重写了 Fragment 相应的生命周期方法,从而实现手动触发更新我们的生命周期观察者。

  • Fragment 中,会在 Fragment 构造函数中初始化相应的 Lifecycle ,并重写相应的生命周期方法,从而触发事件通知,实现生命周期观察者的更新。



每当我们调用 addObserver() 添加新的观察者时:



内部都会对我们的观察者进行包装,并将其包装为一个具体的事件观察者 LifecycleEventObserver,以及生成当前的观察者对应的状态实例(内部持有LifecycleEventObserver),并将其保存到 缓存map 中。接着会去对比当前的 观察者的状态lifecycle此时实际状态 ,如果 当前观察者状态<lifecycle对应的状态 ,则触发相应 Event 的通知,并 更新此观察者对应的状态 ,不断轮训,直到当前观察者状态 >= lifecycle 对应状态。



参阅



关于我


我是 Petterp ,一个 Android工程师 ,如果本文对你有所帮助,欢迎点赞支持,你的支持是我持续创作的最大鼓励!


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

雨下不下,花都结果;风吹不吹,我都是我。

最近不怎么忙了,想来写写文章,但突然也不知道从哪里开始聊,感情?工作?还是这稀里糊涂的生活。 2023年大年初六,我结束了和女朋友长达四年零七个月的爱情长跑,但很遗憾不是进入婚姻殿堂而是分手。 从18岁到23岁几乎已经占了我青春为数不多最美好的几年。但好在我熬...
继续阅读 »

最近不怎么忙了,想来写写文章,但突然也不知道从哪里开始聊,感情?工作?还是这稀里糊涂的生活。


2023年大年初六,我结束了和女朋友长达四年零七个月的爱情长跑,但很遗憾不是进入婚姻殿堂而是分手。
从18岁到23岁几乎已经占了我青春为数不多最美好的几年。但好在我熬过来了,最痛苦的那段已经过去了,我独自一人趴在地板上哭的泪水和口水混在一滩也没人看见的那段日子已经过去了,接下来是漫长而偶尔刺痛的恢复不知道要几年。


微信图片_20230330154857.jpg

“男人不经历分手永远不会成长”这句话忘了是谁说的了。以前觉得纯扯蛋的成不成长跟分手有毛关系,现在我认了,心里性格的变化自己都肉眼可见。越来越多的人生道理从几年前的不屑一顾到现在发生在自己身上才认同。可能成长就是这个样子?毕竟谁都是第一次做人,也不知道成长了该因为变成熟了而高兴还是因为离懵懂幼稚的青春越来越远而难过。


年后回来项目就开始忙,压力骤增。入职到现在八个月,平均一个月加班一次(周末)但过完年回来开始忙基本天天晚上九点十点走,其实作为程序员来说这种程度也还好,但跟年前相比确实忙了很多。年前基本是到点下班就走,但也好,忙一点,让自己不那么闲就不会胡思乱想那些乱七八糟的事情。不会那么伤感也不会那么焦虑。而且拿这个工资心里也没那么愧疚,要不天天摸鱼发工资我都想给老板退回去一点。
不过分手后也真的能攒下钱来了,就很神奇真的很神奇,两个月攒了一万二了。还借了朋友2000。以前每个月都剩不下钱来。今年回家终于不用听爸妈再说那句“攒攒钱吧”了


微信图片_20230330152333.jpg
微信图片_20230330150759.jpg

好在还有街舞、吉他、健身、养猫。这些事让我觉得不那么无聊,劳累的工作之余,周末还是要找点事情做。
不能让自己闲下来,闲下来就忍不住开始emo。


其实来南京快一年了,很去那些景点多看看,鸡鸣寺、玄武湖、夫子庙、还有逼哥的1701live house(偷偷告诉你我是因为听了很多年逼哥才选择来南京生活) 拍拍照什么的。但碍于一个人,没有小伙伴一起。觉得怪无聊的,就也放弃了,但我会改变自己的,接下来的日子我也会一个人吃火锅,一个人看电影,一个人去旅游,一个人逛小吃街,一个人拍照打卡。


其实也不是没有朋友,南京也有几个小伙伴小兄弟,认识好些年,关系也都很好,但我们的热衷不在一个频道,他们除了敲代码就是吃鸡、CSGO、联盟、元神。而我除了联盟偶尔还和他们打一打以外,基本也不怎么玩游戏了,可能是岁数大了,游戏瘾没有前几年那么狠了。


虽然现在也有很多爱好但好像也都只是单纯的打发时间,并没有哪件事不做就难受的不行的感觉,换句话说现在好像多少有点无欲无求?


微信图片_20230330152914.jpg

上周去报了江宁一个摩托车驾校,准备考个D证买个摩托车玩一玩(目前计划先买个二手GSX或者春风骑个一两年,没把自己撞死的话再换个najia或者450),但工作的地方在玄武区好像不让骑。那就只能出去玩骑啦,但也祈祷我能顺利考过,可能是我太笨了去年在北京练摩托车,油离配合老弄不好,动不动就熄火,让人笑话,去练了两次就不练了,希望这次能认真一点。


微信图片_20230330154408.jpg

其实也不是只顾着玩了,工作这方面的也在时不时的计划以及改变计划,因为毕竟现在一个岗位放出去一万个简历等着的行情确实不友好。所以现在的行情基本就是已经不再缺少初级、初中级前端。中级少了很多。那么想要在这行继续混下去就只有一条路那就是使劲的打怪刷经验,进化为高级前端。


由于前三年都是vuer,最近半年才转的reacter。所以react写起来还是没有vue那么得心应手,但是我总感觉react才是前端的未来(狗头保命)如果接下来的计划中准备好好恶补一下技术的话,应该就是以react为主vue为辅了。


去年立的flag依旧没变:在南京待1-2年狠补技术去上海冲刺,目标还是带10+人数的前端leader,天天熬夜加班的那种。


作者:我看你像个promise
来源:juejin.cn/post/7216223889487478840
收起阅读 »

从前后端的角度分析options预检请求

本文分享自华为云社区《从前后端的角度分析options预检请求——打破前后端联调的理解障碍》,作者: 砖业洋__ 。 options预检请求是干嘛的?options请求一定会在post请求之前发送吗?前端或者后端开发需要手动干预这个预检请求吗?不用文档定义堆砌...
继续阅读 »

本文分享自华为云社区《从前后端的角度分析options预检请求——打破前后端联调的理解障碍》,作者: 砖业洋__ 。


options预检请求是干嘛的?options请求一定会在post请求之前发送吗?前端或者后端开发需要手动干预这个预检请求吗?不用文档定义堆砌名词,从前后端角度单独分析,大白话带你了解!


从前端的角度看options——post请求之前一定会有options请求?信口雌黄!


你是否经常看到这种跨域请求错误?


image.png


这是因为服务器不允许跨域请求,这里会深入讲一讲OPTIONS请求。


只有在满足一定条件的跨域请求中,浏览器才会发送OPTIONS请求(预检请求)。这些请求被称为“非简单请求”。反之,如果一个跨域请求被认为是“简单请求”,那么浏览器将不会发送OPTIONS请求。


简单请求需要满足以下条件:



  1. 只使用以下HTTP方法之一:GETHEADPOST

  2. 只使用以下HTTP头部:AcceptAccept-LanguageContent-LanguageContent-Type

  3. Content-Type的值仅限于:application/x-www-form-urlencodedmultipart/form-datatext/plain


如果一个跨域请求不满足以上所有条件,那么它被认为是非简单请求。对于非简单请求,浏览器会在实际请求(例如PUTDELETEPATCH或具有自定义头部和其他Content-TypePOST请求)之前发送OPTIONS请求(预检请求)。


举个例子吧,口嗨半天是看不懂的,让我们看看 POST请求在什么情况下不发送OPTIONS请求


提示:当一个跨域POST请求满足简单请求条件时,浏览器不会发送OPTIONS请求(预检请求)。以下是一个满足简单请求条件的POST请求示例:


// 使用Fetch API发送跨域POST请求
fetch("https://example.com/api/data", {
method: "POST",
headers: {
"Content-Type": "application/x-www-form-urlencoded"
},
body: "key1=value1&key2=value2"
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error("Error:", error));

在这个示例中,我们使用Fetch API发送了一个跨域POST请求。请求满足以下简单请求条件:



  1. 使用POST方法。

  2. 使用的HTTP头部仅包括Content-Type

  3. Content-Type的值为"application/x-www-form-urlencoded",属于允许的三种类型之一(application/x-www-form-urlencoded、multipart/form-data或text/plain)。


因为这个请求满足了简单请求条件,所以浏览器不会发送OPTIONS请求(预检请求)。


我们再看看什么情况下POST请求之前会发送OPTIONS请求,同样用代码说明,进行对比


提示:在跨域请求中,如果POST请求不满足简单请求条件,浏览器会在实际POST请求之前发送OPTIONS请求(预检请求)。


// 使用Fetch API发送跨域POST请求
fetch("https://example.com/api/data", {
method: "POST",
headers: {
"Content-Type": "application/json",
"X-Custom-Header": "custom-value"
},
body: JSON.stringify({
key1: "value1",
key2: "value2"
})
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error("Error:", error));

在这个示例中,我们使用Fetch API发送了一个跨域POST请求。请求不满足简单请求条件,因为:



  1. 使用了非允许范围内的Content-Type值("application/json" 不属于 application/x-www-form-urlencodedmultipart/form-datatext/plain)。

  2. 使用了一个自定义HTTP头部 “X-Custom-Header”,这不在允许的头部列表中。


因为这个请求不满足简单请求条件,所以在实际POST请求之前,浏览器会发送OPTIONS请求(预检请求)。


你可以按F12直接在Console输入查看Network,尽管这个网址不存在,但是不影响观察OPTIONS请求,对比一下我这两个例子。


总结:当进行非简单跨域POST请求时,浏览器会在实际POST请求之前发送OPTIONS预检请求,询问服务器是否允许跨域POST请求。如果服务器不允许跨域请求,浏览器控制台会显示跨域错误提示。如果服务器允许跨域请求,那么浏览器会继续发送实际的POST请求。而对于满足简单请求条件的跨域POST请求,浏览器不会发送OPTIONS预检请求。


后端可以通过设置Access-Control-Max-Age来控制OPTIONS请求的发送频率。OPTIONS请求没有响应数据(response data),这是因为OPTIONS请求的目的是为了获取服务器对于跨域请求的配置信息(如允许的请求方法、允许的请求头部等),而不是为了获取实际的业务数据,OPTIONS请求不会命中后端某个接口。因此,当服务器返回OPTIONS响应时,响应中主要包含跨域配置信息,而不会包含实际的业务数据


本地调试一下,前端发送POST请求,后端在POST方法里面打断点调试时,也不会阻碍OPTIONS请求的返回


image.png


2.从后端的角度看options——post请求之前一定会有options请求?胡说八道!


在配置跨域时,服务器需要处理OPTIONS请求,以便在响应头中返回跨域配置信息。这个过程通常是由服务器的跨域中间件(Node.jsExpress框架的cors中间件、PythonFlask框架的flask_cors扩展)或过滤器(JavaSpringBoot框架的跨域过滤器)自动完成的,而无需开发人员手动处理。


以下是使用Spring Boot的一个跨域过滤器,供参考


import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;

@Configuration
public class CorsConfig {

public CorsConfig() {
}

@Bean
public CorsFilter corsFilter()
{
// 1. 添加cors配置信息
CorsConfiguration config = new CorsConfiguration();
// Response Headers里面的Access-Control-Allow-Origin: http://localhost:8080
config.addAllowedOrigin("http://localhost:8080");
// 其实不建议使用*,允许所有跨域
config.addAllowedOrigin("*");

// 设置是否发送cookie信息,在前端也可以设置axios.defaults.withCredentials = true;表示发送Cookie,
// 跨域请求要想带上cookie,必须要请求属性withCredentials=true,这是浏览器的同源策略导致的问题:不允许JS访问跨域的Cookie
/**
* withCredentials前后端都要设置,后端是setAllowCredentials来设置
* 如果后端设置为false而前端设置为true,前端带cookie就会报错
* 如果后端为true,前端为false,那么后端拿不到前端的cookie,cookie数组为null
* 前后端都设置withCredentials为true,表示允许前端传递cookie到后端。
* 前后端都为false,前端不会传递cookie到服务端,后端也不接受cookie
*/

// Response Headers里面的Access-Control-Allow-Credentials: true
config.setAllowCredentials(true);

// 设置允许请求的方式,比如get、post、put、delete,*表示全部
// Response Headers里面的Access-Control-Allow-Methods属性
config.addAllowedMethod("*");

// 设置允许的header
// Response Headers里面的Access-Control-Allow-Headers属性,这里是Access-Control-Allow-Headers: content-type, headeruserid, headerusertoken
config.addAllowedHeader("*");
// Response Headers里面的Access-Control-Max-Age:3600
// 表示下回同一个接口post请求,在3600s之内不会发送options请求,不管post请求成功还是失败,3600s之内不会再发送options请求
// 如果不设置这个,那么每次post请求之前必定有options请求
config.setMaxAge(3600L);
// 2. 为url添加映射路径
UrlBasedCorsConfigurationSource corsSource = new UrlBasedCorsConfigurationSource();
// /**表示该config适用于所有路由
corsSource.registerCorsConfiguration("/**", config);

// 3. 返回重新定义好的corsSource
return new CorsFilter(corsSource);
}
}


这里setMaxAge方法来设置预检请求(OPTIONS请求)的有效期,当浏览器第一次发送非简单的跨域POST请求时,它会先发送一个OPTIONS请求。如果服务器允许跨域,并且设置了Access-Control-Max-Age头(设置了setMaxAge方法),那么浏览器会缓存这个预检请求的结果。在Access-Control-Max-Age头指定的时间范围内,浏览器不会再次发送OPTIONS请求,而是直接发送实际的POST请求,不管POST请求成功还是失败,在设置的时间范围内,同一个接口请求是绝对不会再次发送OPTIONS请求的。


后端需要注意的是,我这里设置允许请求的方法是config.addAllowedMethod("*")*表示允许所有HTTP请求方法。如果未设置,则默认只允许“GET”和“HEAD”。你可以设置的HTTPMethodGET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE


经过我的测试,OPTIONS无需手动设置,因为单纯只设置OPTIONS也无效。如果你设置了允许POST,代码为config.addAllowedMethod(HttpMethod.POST); 那么其实已经默认允许了OPTIONS,如果你只允许了GET,尝试发送POST请求就会报错。


举个例子,这里只允许了GET请求,当我们尝试发送一个POST非简单请求,预检请求返回403,服务器拒绝了OPTIONS类型的请求,因为你只允许了GET,未配置允许OPTIONS请求,那么浏览器将收到一个403 Forbidden响应,表示服务器拒绝了该OPTIONS请求,POST请求的状态显示CORS error



Spring Boot中,配置允许某个请求方法(如POSTPUTDELETE)时,OPTIONS请求通常会被自动允许。这意味着在大多数情况下,后端开发人员不需要特意考虑OPTIONS请求。这种自动允许OPTIONS请求的行为取决于使用的跨域处理库或配置,最好还是显式地允许OPTIONS请求。


点击关注,第一时间了解华为云新鲜技术~


作者:华为云开发者联盟
来源:juejin.cn/post/7233587643724234811
收起阅读 »

快速生成定制化的Word文档:Python实践指南

1.1. 前言 众所周知,安服工程师又叫做Word工程师,在打工或者批量SRC的时候,如果产出很多,又需要一个一个的写报告的情况下会非常的折磨人,因此查了一些相关的资料,发现使用python的docxtpl库批量写报告效果很不错,记录一下。 1.2. 介绍 d...
继续阅读 »

1.1. 前言


众所周知,安服工程师又叫做Word工程师,在打工或者批量SRC的时候,如果产出很多,又需要一个一个的写报告的情况下会非常的折磨人,因此查了一些相关的资料,发现使用python的docxtpl库批量写报告效果很不错,记录一下。


1.2. 介绍


docxtpl 是一个用于生成 Microsoft Word 文档的模板引擎库,它结合了 docx 模块和 Jinja2 模板引擎,使用户能够使用 Microsoft Word 模板文件并在其中填充动态数据。它提供了一种方便的方式来生成个性化的 Word 文档,并支持条件语句、循环语句和变量等控制结构,以满足不同的文档生成需求。


官方GitHub地址:github.com/elapouya/py…


官方文档地址:docxtpl.readthedocs.io/en/latest/



简单来说:就是创建一个类似Jinja2语法的模板文档,然后往里面动态填充内容就可以了



安装:


pip3 install docxtpl

1.3. 基础使用


from docxtpl import DocxTemplate

doc = DocxTemplate("test.docx")
context = {'whoami': "d4m1ts"}
doc.render(context)
doc.save("generated_doc.docx")

其中,test.docx内容如下:


test.docx


生成后的结果如下:


gen


1.4. 案例介绍


1.4.1. 需求假设


写一份不考虑美观的漏扫报告,需要有统计结果图和漏洞详情,每个漏洞包括漏洞名、漏洞地址、漏洞等级、漏洞危害、复现过程、修复建议六个部分。


1.4.2. 模板文档准备


编写的模板文档如下,使用到了常见的iffor赋值等,保存为template.docx,后续只需要向里面填充数据即可。


template


1.4.3. 数据结构分析


传入数据需要一串json字符串,因此我们根据模板文档梳理好json结构,然后传入即可。


梳理好的数据结构如下:


{
"饼图": "111",
"柱状图": "222",
"漏洞简报": [
{
"漏洞名": "测试漏洞名1",
"漏洞等级": "高危"
}
],
"漏洞详情": [
{
"漏洞名": "测试漏洞名1",
"漏洞地址": "http://blog.gm7.org/",
"漏洞等级": "高危",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
}
]
}

编写代码测试一下可行性:


from docxtpl import DocxTemplate

doc = DocxTemplate("template.docx")
context = {
"饼图": "111",
"柱状图": "222",
"漏洞简报": [
{
"漏洞名": "测试漏洞名1",
"漏洞等级": "高危"
},
{
"漏洞名": "测试漏洞名2",
"漏洞等级": "严重"
},
{
"漏洞名": "测试漏洞名2",
"漏洞等级": "中危"
}
],
"漏洞详情": [
{
"漏洞名": "测试漏洞名1",
"漏洞地址": "http://blog.gm7.org/",
"漏洞等级": "高危",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
},
{
"漏洞名": "测试漏洞名2",
"漏洞地址": "http://bblog.gm7.org/",
"漏洞等级": "严重",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
},
{
"漏洞名": "测试漏洞名3",
"漏洞地址": "http://cblog.gm7.org/",
"漏洞等级": "中危",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
}
]
}

doc.render(context)
doc.save("generated_doc.docx")

很好,达到了预期的效果。


res


1.4.4. 加入图表


在上面的过程中,内容几乎是没问题了,但是图表还是没有展示出来。生成图表我们使用plotly这个库,并将生成内容写入ByteIO


相关代码如下:


import plotly.graph_objects as go
from io import BytesIO

def generatePieChart(title: str, labels: list, values: list, colors: list):
"""
生成饼图
https://juejin.cn/post/6911701157647745031#heading-3
https://juejin.cn/post/6950460207860449317#heading-5

:param title: 饼图标题
:param labels: 饼图标签
:param values: 饼图数据
:param colors: 饼图每块的颜色
:return:
"""

# 基础饼图
fig = go.Figure(data=[go.Pie(
labels=labels,
values=values,
hole=.4, # 中心环大小
insidetextorientation="horizontal"
)])
# 更新颜色
fig.update_traces(
textposition='inside', # 文本显示位置
hoverinfo='label+percent', # 悬停信息
textinfo='label+percent', # 饼图中显示的信息
textfont_size=15,
marker=dict(colors=colors)
)
# 更新标题
fig.update_layout(
title={ # 设置整个标题的名称和位置
"text": title,
"y": 0.96, # y轴数值
"x": 0.5, # x轴数值
"xanchor": "center", # x、y轴相对位置
"yanchor": "top"
}
)
image_io = BytesIO()
fig.write_image(image_io, format="png")
return image_io


def generateBarChart(title: str, x: list, y: list):
"""
生成柱状图
https://cloud.tencent.com/developer/article/1817208
https://blog.csdn.net/qq_25443541/article/details/115999537
https://blog.csdn.net/weixin_45826022/article/details/122912484

:param title: 标题
:param x: 柱状图标签
:param y: 柱状图数据
:return:
"""

# x轴长度最为18
b = x
x = []
for i in b:
if len(i) >= 18:
x.append(f"{i[:15]}...")
else:
x.append(i)

# 基础柱状图
fig = go.Figure(data=[go.Bar(
x=x,
y=y,
text=y,
textposition="outside",
marker=dict(color=["#3498DB"] * len(y)),
width=0.3
)])
# 更新标题
fig.update_layout(
title={ # 设置整个标题的名称和位置
"text": title,
"y": 0.96, # y轴数值
"x": 0.5, # x轴数值
"xanchor": "center", # x、y轴相对位置
"yanchor": "top"
},
xaxis_tickangle=-45, # 倾斜45度
plot_bgcolor='rgba(0,0,0,0)' # 背景透明
)
fig.update_xaxes(
showgrid=False
)
fig.update_yaxes(
zeroline=True,
zerolinecolor="#17202A",
zerolinewidth=1,
showgrid=True,
gridcolor="#17202A",
showline=True
)

image_io = BytesIO()
fig.write_image(image_io, format="png")
return image_io

1.4.5. 最终结果


要插入图片内容,代码语法如下:


myimage = InlineImage(tpl, image_descriptor='test_files/python_logo.png', width=Mm(20), height=Mm(10))

完整代码如下:


from docxtpl import DocxTemplate, InlineImage
from docx.shared import Mm
import plotly.graph_objects as go
from io import BytesIO


def generatePieChart(title: str, labels: list, values: list, colors: list):
"""
生成饼图
https://juejin.cn/post/6911701157647745031#heading-3
https://juejin.cn/post/6950460207860449317#heading-5

:param title: 饼图标题
:param labels: 饼图标签
:param values: 饼图数据
:param colors: 饼图每块的颜色
:return:
"""

# 基础饼图
fig = go.Figure(data=[go.Pie(
labels=labels,
values=values,
hole=.4, # 中心环大小
insidetextorientation="horizontal"
)])
# 更新颜色
fig.update_traces(
textposition='inside', # 文本显示位置
hoverinfo='label+percent', # 悬停信息
textinfo='label+percent', # 饼图中显示的信息
textfont_size=15,
marker=dict(colors=colors)
)
# 更新标题
fig.update_layout(
title={ # 设置整个标题的名称和位置
"text": title,
"y": 0.96, # y轴数值
"x": 0.5, # x轴数值
"xanchor": "center", # x、y轴相对位置
"yanchor": "top"
}
)
image_io = BytesIO()
fig.write_image(image_io, format="png")
return image_io


def generateBarChart(title: str, x: list, y: list):
"""
生成柱状图
https://cloud.tencent.com/developer/article/1817208
https://blog.csdn.net/qq_25443541/article/details/115999537
https://blog.csdn.net/weixin_45826022/article/details/122912484

:param title: 标题
:param x: 柱状图标签
:param y: 柱状图数据
:return:
"""

# x轴长度最为18
b = x
x = []
for i in b:
if len(i) >= 18:
x.append(f"{i[:15]}...")
else:
x.append(i)

# 基础柱状图
fig = go.Figure(data=[go.Bar(
x=x,
y=y,
text=y,
textposition="outside",
marker=dict(color=["#3498DB"] * len(y)),
width=0.3
)])
# 更新标题
fig.update_layout(
title={ # 设置整个标题的名称和位置
"text": title,
"y": 0.96, # y轴数值
"x": 0.5, # x轴数值
"xanchor": "center", # x、y轴相对位置
"yanchor": "top"
},
xaxis_tickangle=-45, # 倾斜45度
plot_bgcolor='rgba(0,0,0,0)' # 背景透明
)
fig.update_xaxes(
showgrid=False
)
fig.update_yaxes(
zeroline=True,
zerolinecolor="#17202A",
zerolinewidth=1,
showgrid=True,
gridcolor="#17202A",
showline=True
)

image_io = BytesIO()
fig.write_image(image_io, format="png")
return image_io


doc = DocxTemplate("template.docx")
context = {
"饼图": InlineImage(doc, image_descriptor=generatePieChart(
title="漏洞数量",
labels=["严重", "高危", "中危", "低危"],
values=[1, 1, 1, 0],
colors=["#8B0000", "red", "orange", "aqua"]
), width=Mm(130)),
"柱状图": InlineImage(doc, image_descriptor=generateBarChart(
title="漏洞类型",
x=["测试漏洞名1", "测试漏洞名2", "测试漏洞名3"],
y=[1, 1, 1]
), width=Mm(130)),
"漏洞简报": [
{
"漏洞名": "测试漏洞名1",
"漏洞等级": "高危"
},
{
"漏洞名": "测试漏洞名2",
"漏洞等级": "严重"
},
{
"漏洞名": "测试漏洞名2",
"漏洞等级": "中危"
}
],
"漏洞详情": [
{
"漏洞名": "测试漏洞名1",
"漏洞地址": "http://blog.gm7.org/",
"漏洞等级": "高危",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
},
{
"漏洞名": "测试漏洞名2",
"漏洞地址": "http://bblog.gm7.org/",
"漏洞等级": "严重",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
},
{
"漏洞名": "测试漏洞名3",
"漏洞地址": "http://cblog.gm7.org/",
"漏洞等级": "中危",
"漏洞危害": "危害XXX",
"复现过程": "先xxx,再xxx,最后xxx",
"修复建议": "更新到最新版本即可"
}
]
}

doc.render(context)
doc.save("generated_doc.docx")

结果如下:


result


作者:初始安全
来源:juejin.cn/post/7233597845919662139
收起阅读 »

看了十几篇MVX架构的文章后,我悟了...

当经过学一遍又一遍,改一遍又一遍,觉得学不懂想哭的时候,我选择了放弃(洗澡),然后我悟了。 适当开摆有益身心健康 当你纠结于文件该放在哪个包下,纠结于什么功能的代码应该放在哪个类中,于是在学习过程中不断修改,不断重构...开始了这样一个循环。 这有很大一部分原...
继续阅读 »

当经过学一遍又一遍,改一遍又一遍,觉得学不懂想哭的时候,我选择了放弃(洗澡),然后我悟了。


适当开摆有益身心健康


当你纠结于文件该放在哪个包下,纠结于什么功能的代码应该放在哪个类中,于是在学习过程中不断修改,不断重构...开始了这样一个循环。


这有很大一部分原因是因为不统一,架构是一种设计思想,而且大部分是由国外公司、大牛提出,首先在语言理解上就会有一定的差异和误解,如果我们能正确理解设计原则,就可以事半功倍。


就比如并发和并行,看过很多对于这两个的解释就是:并发是多个任务交替使用CPU,同一时刻只有一个任务在跑;并行是多个任务同时跑。


其实就是一种误解,【并发】和【并行】描述的是两个频道的事情。并发是一种处理方法,通过拆分代码,各部分代码互不影响,这样可以充分利用多核心。所以如果想让一个事情变得容易【并行】,先得让制定一个【并发】的方法。倘若一个事情压根就没有【并发】的方法,那么无论有多少个可以干活的人,也不能【并行】。


回到MVX架构,对于怎么样分包,怎么样拆分代码,我觉得应该从思想原理入手,因为文章的写法是各个作者理解,他们的理解不一定就是正确的,包括我。


就以谷歌推荐的架构原则来说,它有以下4点:分离关注点、通过数据模型驱动界面、单一数据源、单向数据流;推荐的架构图如下:


image.png


按照上面这张图,我们在Activity中写界面和界面的展示的数据,现在回看架构原则第一点”关注分离点”,于是我们把界面和界面的数据拆分开,这个过程是自然而然的,所以我更倾向于发挥自己的想象力去把架构实现好,而不是去进行拙略的模仿,现在回想起来20年时我在写项目的时候会自己思考如何去改进,于是自然而然添加了事件和状态(单向数据流),而在之前我并没有去看关于这方面的文章。


当你学习累了,那就大喊一句“开摆”,什么屁架构文章一边去,不学了。(优秀的文章还是值得我们学习的,这里只是我的情绪宣泄)


也许回过头你就学会了,这并不是什么魔法,而是把你从一个深坑中拉了出来,让你的大脑能换个方向思考问题。


我们需要重点学习的是设计原则,剩下的就是发挥我们的想象力。


相关资料


如何理解:程序、进程、线程、并发、并行、高并发? - 大宽宽 知乎 (zhihu.com)


应用架构指南  |  Android 开发者  |  Android Developers (google.cn)


作者:Fanketly
来源:juejin.cn/post/7234057845620408375
收起阅读 »

我给我的博客加了个在线运行代码功能

web
获取更多信息,可以康康我的博客,所有文章会在博客上先发布随记 - 记录指间流逝的美好 (xiaoyustudent.github.io) 前言 新的一年还没过去,我又开始搞事情了,偶尔一次用到了在线编辑网页代码的网站,顿时想到,能不能自己实现一个呢?(PS:反...
继续阅读 »

获取更多信息,可以康康我的博客,所有文章会在博客上先发布随记 - 记录指间流逝的美好 (xiaoyustudent.github.io)


前言


新的一年还没过去,我又开始搞事情了,偶尔一次用到了在线编辑网页代码的网站,顿时想到,能不能自己实现一个呢?(PS:反正也没事干),然后又想着,能不能用在博客上呢,这样有些代码可以直接展现出来,多好,说干就干,让我们康康怎么去实现一个在线编辑代码的功能吧。(PS:有瑕疵,还在学习!勿喷!orz)


大致介绍


大概的想法就是通过iframe标签,让我们自己输入的内容能够在iframe中显示出来,知识点如下,如果有其他问题,欢迎在下方评论区进行补充!



  1. 获取输入的内容

  2. 插入到iframe中

  3. 怎么在博客中显示



当然也有未解决的问题:目前输入的js代码不能操作输入的html代码,查了许多文档,我会继续研究的,各位大佬如果有想法欢迎讨论



页面搭建


页面搭建很简单,就是三个textarea块,加4个按钮,就直接上代码了


<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>在线编辑器</title>
<script src="https://cdn.staticfile.org/jquery/1.10.2/jquery.min.js"></script>
<script>
$(document).ready(function () {
$('.HTMLBtn').click(function () {
$("#cssTextarea").fadeOut(function () {
$("#htmlTextarea").fadeIn();
});
})

$('.CSSBtn').click(function () {
$("#htmlTextarea").fadeOut(function () {
$("#cssTextarea").fadeIn();
});
})
});
</script>
<style>
* {
padding: 0;
margin: 0;
}

body,
html {
width: 100%;
height: 100%;
}

.main {
display: flex;
flex-direction: row;
justify-content: space-between;
width: 100%;
height: 100%;
}

.textarea-box {
display: flex;
flex-direction: column;
width: calc(50% - 20px);
padding: 10px;
background: rgba(34, 85, 85, 0.067);
}

.textarea-function-box {
display: flex;
flex-direction: row;
justify-content: space-between;
}

.textarea-function-left,.textarea-function-right {
display: flex;
flex-direction: row;
}

.textarea-function-left div,
.textarea-function-right div {
padding: 5px 10px;
border: 1px solid rgb(9, 54, 99);
border-radius: 3px;
cursor: pointer;
}

.textarea-function-left div:not(:first-child) {
margin-left: 10px;
}

#htmlTextarea,
#cssTextarea {
height: calc(100% - 30px);
width: calc(100% - 20px);
margin-top: 10px;
padding: 10px;
overflow-y: scroll;
background: #fff;
}

.html-div {
background-color: cadetblue;
margin-top: 10px;
flex: 1;
}

.iframe-box {
width: 50%;
flex: 1;
overflow: hidden;
}
</style>
</head>

<body>
<div class="main">
<div class="textarea-box">
<div class="textarea-function-box">
<div class="textarea-function-left">
<div class="HTMLBtn">HTML</div>
<div class="CSSBtn">CSS</div>
</div>
<div class="textarea-function-right">
<input type="text" id="input_name">
<div class="run">运行</div>
<div class="download">保存</div>
</div>
</div>
<textarea id="htmlTextarea" placeholder="请输入html代码"></textarea>
<textarea id="cssTextarea" placeholder="请输入css代码" style="display: none;"></textarea>
</div>
<div class="iframe-box">
<iframe style="height: 100%;width: 100%;" src="" frameborder="0"></iframe>
</div>
</div>
</body>
</html>

忽略我的样式,能用就行!!


运行代码


这里是核心功能,应该怎么把代码运行出来呢,我这里用的是iframe,通过获取iframe元素,然后把对应的代码插入进去


$('.run').click(function () {
var htmlTextarea = document.querySelector('#htmlTextarea').value;
var cssTextarea = document.querySelector('#cssTextarea').value;
htmlTextarea += '<style>' + cssTextarea + '</style>'
// 获取html和css代码
let frameWin, frameDoc, frameBody;
frameWin = document.querySelector('iframe').contentWindow;
frameDoc = frameWin.document;
frameBody = frameDoc.body;
// 获取iframe元素

$(frameBody).html(htmlTextarea);
// 使用jqury的html方法把代码插入进去,这样能够直接执行
})

这样一个基本的在线代码编辑网页就完成了,接下来,我们看下怎么把这玩意给用在博客当中!


hexo设置


首先我们需要创建一个文件夹,用来放置我们写好的在线的html文件。在source文件夹下新建文件online,并且设置禁止渲染此文件夹,打开_config.yml文件,并设置以下


skip_render: online/*

页面设置


我目前想到的办法就是保存文件,然后在hexo里使用,添加以下代码


<div class="textarea-function-right">
<input type="text" id="input_name">
<div class="download">保存</div>
<!-- .... -->
</div>

<script>
function fake_click(obj) {
var ev = document.createEvent("MouseEvents");
ev.initMouseEvent(
"click", true, false, window, 0, 0, 0, 0, 0
, false, false, false, false, 0, null
);
obj.dispatchEvent(ev);
}

function export_raw(name, data) {
var urlObject = window.URL || window.webkitURL || window;
var export_blob = new Blob([data]);
var save_link = document.createElementNS("http://www.w3.org/1999/xhtml", "a")
save_link.href = urlObject.createObjectURL(export_blob);
save_link.download = name;
fake_click(save_link);
}

$(document).ready(function () {
$(".download").click(function () {
let scriptStr = $('html').first().context.getElementsByTagName("script")[2].innerHTML
var htmlTextarea = document.querySelector('#htmlTextarea').value != "" ? document.querySelector('#htmlTextarea').value : '""';
var cssTextarea = document.querySelector('#cssTextarea').value != "" ? document.querySelector('#cssTextarea').value : '""';
let htmlStr = $('html').first().context.getElementsByTagName("html")[0].innerHTML.replace(scriptStr, "").replace('<div class="download">保存</div>', "").replace('<input type="text" id="input_name">',"").replace("<script><\/script>", "<script>$(document).ready(function(){document.querySelector('#htmlTextarea').value = `" + htmlTextarea + "`;document.querySelector('#cssTextarea').value = `" + cssTextarea + "`;})<\/script>")
let n = $('#input_name').val()!=""?$('#input_name').val():"text";
export_raw(n+'.html', htmlStr);
})
})
</script>

可能很多同学会好奇为啥我这里用的script标签框起来,我们看下这个图片和这个代码


script.png


et scriptStr = $('html').first().context.getElementsByTagName("script")[2].innerHTML

很简单,我们保存后的代码,是没有这一段js代码的,所以需要替换掉,而这里一共有3个script块,最后一个,也就是下标为2的script块会被替换掉。同理,后面替换掉保存按钮,input输入框(输入框是输入文件名称的,默认名称是text)。


同时这里把我们输入的数据,通过js代码的方式加入进保存后的文件里,实现打开文件就能看到我们写的代码。之后我们把保存后的文件放在刚才我们创建的online文件夹下


text.png


hexo里面使用


使用就很简单了,我们通过iframe里面的src属性即可


<iframe src="/online/text.html" style="display:block;height:400px;width:100%;border:0.5px solid rgba(128,128,128,0.4);border-radius:8px;box-sizing:border-box;"></iframe>

展示图


show.png


作者:新人打工仔
来源:juejin.cn/post/7191520909709017144
收起阅读 »

判断数组成员的几种方法

web
在开发中经常需要我们在数组中查找元素又或者是判断元素是否存在,所以我列举了几种常用的方法供掘友参考学习。 indexOf() 首先想到的就是indexOf()方法,查找元素,并返回第一个找到的位置索引 [1,2,3,2].indexOf(2)  // 1 ...
继续阅读 »



在开发中经常需要我们在数组中查找元素又或者是判断元素是否存在,所以我列举了几种常用的方法供掘友参考学习。


indexOf()


首先想到的就是indexOf()方法,查找元素,并返回第一个找到的位置索引


 [1,2,3,2].indexOf(2)  // 1

他还支持第二个可选参数,指定开始查找的位置


 [1,2,3,2].indexOf(2,2)  // 3

但是indexOf()有个问题,他的实现是由===作为判断的,所以这容易造成一些问题,比如他对于NaN会造成误判


[NaN].indexOf(NaN) // -1
console.log(NaN === NaN) // false

如上,由于误判,没有找到匹配元素,所以返回-1,而在ES6对数组的原型上新增了incudes()方法,他可以代替indexOf(),下面来看看这个方法。


includes()


在ES6之前只有字符串的原型上含有include()方法来判断是否包含字串,而数组在ES6中也新增了include()方法来判断是否包含某个元素,下面来看看如何使用。


[1,2,3].includes(2) // true

数组实例直接调用,参数为要查找的目标元素,返回值为布尔值。而且他能很好地解决indexOf()的问题:


[NaN].includes(NaN) // true

如上includes()可以正确地判断NaN的查找问题,而includes()是用来判断是否包含,查找条件也比较单一,那么如果想要自定义查找条件,比如查找的范围,可以使用这么一对方法:find()与findIndex()接下来看一看他们是如何使用的。


find()与findIndex()


find()findIndex()可以匹配数组符合条件的元素


find()


find()支持三个参数,分别为valueindexarr,分别为当前值,当前位置,与原数组,,返回值为符号条件的值


let arr = [1,2,10,6,19,20]
arr.find((value,index,arr) => {
   return value > 10
}) // 19

如上,我以元素大于10为范围条件,返回了第一个符合范围条件的值:19。而find()可以返回符合条件的第一个元素,那么我们要是想拿到符合条件的第一个元素索引就可以使用findIndex()


findIndex()


findIndex()find相似也支持三个参数,但是返回值不同,其返回的是符合条件的索引


let arr = [1,2,10,6,19]
arr.findIndex((value,index,arr) => {
   return value > 10
}) // 4

例子与find()相同,返回的是19对应的索引


对于NaN值


find()findIndex()NaN值也不会误判,可以使用Object.is()来作为范围条件来判断NaN值,如下


[NaN].find((value)=> {
   return Object.is(NaN,value)
}) // NaN

如上例子,findIndex()也同理


最后


判断元素在某数组中是否存在的四种方法就说到这里,对掘友有所帮助的话就点个小心心吧,也欢迎关

作者:猪痞恶霸
来源:juejin.cn/post/7125632393821552677
注我的JS进阶专栏。

收起阅读 »

JS实现继承的几种方式

web
继承作为面向对象语言的三大特性之一,可以在不影响父类对象实现的情况下,使得子类对象具有父类对象的特性;同时还能再不影响父类对象行为的情况下扩展子类对象独有的特性,为编码带来了极大的便利。 下面我们就来看看 JavaScript 中都有哪些实现继承的方法。 原...
继续阅读 »

继承作为面向对象语言的三大特性之一,可以在不影响父类对象实现的情况下,使得子类对象具有父类对象的特性;同时还能再不影响父类对象行为的情况下扩展子类对象独有的特性,为编码带来了极大的便利。



下面我们就来看看 JavaScript 中都有哪些实现继承的方法。


原型链继承


原型链继承是比较常见的继承方式之一,其中涉及的构造函数、原型和实例,三者之间存在着一定的关系,即每一个构造函数都有一个原型对象,原型对象又包含一个指向构造函数的指针,而实例则包含一个原型对象的指针。



原型链继承的主要思想是:重写子类的prototype属性,将其指向父类的实例



下面我们结合代码来了解一下。



function Animal (name) {

  // 属性

  this.name = name

  this.type = 'Animal'

  // 实例函数

  this.sleep = function () {

    console.log(this.name + '正在睡觉');

  }

}

// 原型函数

Animal.prototype.eat = function (food) {

  console.log(`${this.name}正在吃${food}`);

}




// 子类

function Cat (name) {

  this.name = name

}

// 原型继承

Cat.prototype = new Animal()

// 将Cat的构造函数指向自身

Cat.prototype.constructor = Cat




let cat = new Cat('Tom')

console.log(cat.name) // Tom

console.log(cat.type) // Animal

cat.sleep() // Tom正在睡觉

cat.eat('猫罐头') // Tom正在吃猫罐头


在子类Cat中,我们没有增加type属性,因此会直接继承父类Animaltype属性。


在子类Cat中,我们增加了name属性,在生成子类实例时,name属性会覆盖父类Animal属性值。


同样因为Catprototype属性指向了Animal类型的实例,因此在生成实例Cat时,会继承实例函数和原型函数。



需要注意:
Cat.prototype.constructor = Cat


如果不将Cat原型对象的constructor属性指向自身的构造函数,那将指向父类Animal的构造函数。



原型链继承的优点


简单,易于实现


只需要设置子类的prototype属性指向父类的实例即可。


可通过子类直接访问父类原型链属性和函数


原型链继承的缺点


子类的所有实例将共享父类的属性


子类的所有实例将共享父类的属性会带来一个很严重的问题,父类包含引用值时,子类的实例改变该引用值会在所有实例中共享。



function Animal () {

  this.skill = ['eat', 'jump', 'sleep']

}

function Cat () {}

Cat.prototype = new Animal()

Cat.prototype.constructor = Cat




let cat1 = new Cat()

let cat2 = new Cat()

cat1.skill.push('walk')

console.log(cat1.skill) // ["eat", "jump", "sleep", "walk"]

console.log(cat2.skill) // ["eat", "jump", "sleep", "walk"]


在子类实例化时,无法向父类的构造函数传参


在通过new操作符创建子类的实例时,会调用子类的构造函数,而在子类的构造函数中并没有设置与父类关联,从而导致无法向父类的构造函数传递参数。


无法实现多继承


子类的prototype只能设置一个值,设置多个值时,后面的值会覆盖前面的值。


构造函数继承(借助 call)



构造函数继承的主要思想:在子类的构造函数中通过call()函数改变thi的指向,调用父类的构造函数,从而将父类的实例的属性和函数绑定到子类的this上。




  // 父类

function Animal (age) {

  // 属性

  this.name = 'Animal'

  this.age = age

  // 实例函数

  this.sleep = function () {

    console.log(this.name + '正在睡觉');

  }

}

// 原型函数

Animal.prototype.eat = function (food) {

  console.log(`${this.name}正在吃${food}`);

}

function Cat (name) {

  // 核心,通过call()函数实现Animal的实例的属性和函数的继承

  Animal.call(this)

  this.name = name

}




let cat = new Cat('Tom')

cat.sleep() // Tom正在睡觉

cat.eat() // Uncaught TypeError: cat.eat is not a function


通过代码可以发现,子类可以正常调用父类的实例函数,而无法调用父类原型上的函数,这是因为子类并没有通过某种方式来调用父类原型对象上的函数


构造继承的优点


解决了子类实例共享父类属性的问题


call()函数实际时改变父类Animal构造函数中this的指向,然后调用this指向了子类Cat,相当于将父类的属性和函数直接绑定到了子类的this中,成了子类实例的熟属性和函数,因此生成的子类实例中是各自拥有自己的属性和函数,不会相互影响。


创建子类的实例时,可以向父类传参



   // 父类

function Animal (age) {

  this.name = 'Animal'

  this.age = age

}

function Cat (name, parentAge) {

  // 在子类生成实例时,传递参数给call()函数,间接地传递给父类,然后被子类继承

  Animal.call(this, parentAge)

  this.name = name

}




let cat = new Cat('Tom', 10)

console.log(cat.age)


可以实现多继承


在子类的构造函数中,可以多次调用call()函数来继承多个父对象。


构造函数的缺点


实例只是子类的实例,并不是父类的实例


因为我们并未通过原型对象将子类与父类进行串联,所以生成的实例与父类并没有关系。


只能继承父类实例的属性和函数,并不能继承原型对象上的属性和函数


与上面原因相同。


无法复用父类的构造函数


因为父类的实例函数将通过call()函数绑定到子类的this中,因此子类生成的每个实例都会拥有父类实例的引用,这会造成不必要的内存消耗,影响性能。


组合继承



组合继承的主要思想:结合构造继承和原型继承的两种方式,一方面在子类的构造函数中通过call()函数调用父类的构造函数,将父类的实例的属性和函数绑定到子类的this中;另一方面,通过改变子类的prototype属性,继承父类的原型对象上的属性和函数。




// 父类

function Animal (age) {

  // 实例属性

  this.name = 'Animal'

  this.age = age

  this.skill = ['eat', 'jump', 'sleep']

  // 实例函数

  this.sleep = function () {

    console.log(this.name + '正在睡觉')

  }

}

// 原型函数

Animal.prototype.eat = function (food) {

  console.log(`${this.name}正在吃${food}`)

}




// 子类

function Cat (name) {

  // 通过构造函数继承实例的属性和函数

  Animal.call(this)

  this.name = name

}

// 通过原型继承原型对象上的属性和函数

Cat.prototype = new Animal()

Cat.prototype.constructor = Cat




let cat = new Cat('Tom')

console.log(cat.name) // Tom

cat.sleep() // Tom正在睡觉

cat.eat('猫罐头') // Tom正在吃猫罐头


组合继承的优点


既能继承父类实例的属性和函数,又能继承原型对象上的属性和函数


既是子类的实例,又是父类的实例


不存在引用属性共享的问题


构造函数作用域优先级比原型链优先级高,所以不会出现引用属性共享的问题。


可以向父类的构造函数中传参


组合继承的缺点


父类的实例属性会被绑定两次


在子类的构造函数中,通过call()函数调用了一次父类的构造函数;在改写子类的prototype属性,生成的实例时又调用了一次父类的构造函数。


寄生组合继承


组合继承方案已经足够好,但是针对其存在的缺点,我们仍然可以进行优化。


在进行子类的prototype属性的设置时,可以去掉父类实例的属性的函数



  //父类

function Animal (age) {

  // 实例属性

  this.name = 'Animal'

  this.age = age

  this.skill = ['eat', 'jump', 'sleep']

  // 实例函数

  this.sleep = function () {

    console.log(this.name + '正在睡觉')

  }

}

// 原型函数

Animal.prototype.eat = function (food) {

  console.log(`${this.name}正在吃${food}`)

}

// 子类

function Cat (name) {

  // 继承父类的实例和属性

  Animal.call(this)

  this.name = name

}

// 继承父类原型上的实例和属性

Cat.prototype = Object.create(Animal.prototype)

Cat.prototype.constructor = Cat

let cat = new Cat('Tom')




console.log(cat.name) // Tom

cat.sleep() // Tom正在睡觉

cat.eat('猫罐头') // Tom正在吃猫罐头



其中最关键的语句:






Cat.prototype = Object.create(Animal.prototype)






只取父类Animal的prototype属性,过滤掉Animal的实例属性,从而避免了父类的实例属性绑定两次。



这种寄生组合式继承方式,基本可以解决前几种继承方式的缺点,较好地实现了继承想要的结果,同时也减少了构造次数,减少了性能的开销。


整体看下来,这六种继承方式中,寄生组合式继承是这里面最优的继承方式。


总结


image.png


作者:蜡笔小群
来源:juejin.cn/post/7168856064581091364
收起阅读 »

我们在搜索一个问题的时候浏览器究竟做了什么

web
1+1=?,这个问题一直困扰着我,这天摸鱼的时间,我打开浏览器,在地址栏中输入http://www.baidu.com,按下回车,从这时起,我的疑虑从1+1=?变成了打开百度时浏览器到底做了什么工作? 这算是一个面试常见题,反正我被提问了无数次 TuT 为什...
继续阅读 »

1+1=?,这个问题一直困扰着我,这天摸鱼的时间,我打开浏览器,在地址栏中输入http://www.baidu.com,按下回车,从这时起,我的疑虑从1+1=?变成了打开百度时浏览器到底做了什么工作?



这算是一个面试常见题,反正我被提问了无数次 TuT

为什么面试官总喜欢提问这个问题?一般面试官问这个问题,是为了考察前端的广度和深度。



在浏览器地址栏键入URL地址


当我们在浏览器地址栏输入一个URL地址后,浏览器会开一个线程来对我们输入的URL进行解析处理。


1. DNS域名解析


我们在浏览器中输入的URL通常是一个域名,浏览器并不认识域名,它只知道IP,而我们平时记住的一般是域名,所以需要一个解析过程,让浏览器认得我们输入的内容。



  • IP地址:IP地址是某一台主机在互联网上的地址

  • 域名:和IP差不多意思,也是主机在互联网上的地址,人们一般记住的是域名,更有实质性意义。如果把IP比作经纬度,那么域名就是街道地址。

  • DNS:Domain Name System,负责提供域名和IP对应的查询服务,即域名解析系统;

  • URL:Uniform Resource Locator,统一资源定位符,其实就是我们说的‘网址’。


由此可以推断出,当我们敲下一行url地址时,浏览器首先做的是,先到DNS问问这个url的实际位置在哪里?


2. 发起请求



  • 协议:把数据打包成一种传输双方都看得懂的形式。

  • http:Hyper Text Transfer Protocol,超文本传输协议,通常运行在TCP之上。超文本就是用文本的方式来传输超越文本的内容,例如图片、音频等等。

  • TCP:Transmission Control Protocol,传输控制协议,是传输层的协议,用于保持通信的完整性。

  • 服务器:其实就是一台主机(电脑),目标资源可以存放在它的存储空间中。


拿到ip地址后,浏览器向目标地址发起http或者https协议的网络请求。

HTTP请求的本质是TCP/IP的请求构建。建立连接时需要进行3次握手进行验证,断开连接时需要4次挥手进行验证,保证传输的可靠性。


握手挥手过程有点复杂,具体的另出一篇文章说明!


3次握手


三次握手1.gif



  • 第一次握手:客户端发送网络包,服务端收到。

    服务端得出结论:客户端的发送能力、服务端的接收能力正常

  • 第二次握手:服务端发包,客户端收到。

    客户端得出结论:服务端的接收、发送能力正常,客户端的接收、发送能力正常。但是服务器并不能确认客户端接收能力是否正常。

  • 第三次握手:客户端发包,服务端收到。

    服务端得出结论:客户端的接收、发送能力正常,服务器的发送、接收能力正常。


三次握手.gif


4次挥手



  • 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号,此时客户端处于FIN_WAIT1状态。

    即发出连接释放报文段,并停止再发送数据,主动关闭TCP连接,进入FIN_WAIT1状态,等待服务端的确认。

  • 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,并把客户端的序列号值 +1 作为 ACK 的报文序号列值,表明已经收到客户端的报文,此时服务端处于 CLOSE_WAIT 状态。

  • 第三次挥手:服务器端关闭与客户端的连接,发送一个 FIN Seq=N 给客户端。

  • 第四次挥手:客户端返回 ACK 报文确认,确认序号 ACK 未收到的序号 N+1


四次挥手.gif


3. 服务器响应


服务器上运行的WEB服务软件根据http协议的规则,返回URL中指定的资源。

HTTP请求到达服务器,服务器进行对应的处理,最后要把数据传给浏览器,即返回网络响应。

和请求部分类似,网络响应具有三个部分:响应行、响应头和响应体,发起请求后,服务器会返回一个状态码,以示下一步的操作。


响应完成后TCP连接会断开吗


首先需要判断一下Connection字段,如果请求头或响应头中包含Connection: Keep-Alive,表示建立了持久连接,这样TCP会一直保持,之后请求统一站点的资源会复用这个连接;否则会断开TCP连接,响应流程结束。


状态码


状态码由3位数组成,第一个数字定义了响应的类别:



  1. 1xx:表示请求已接收,继续处理;

  2. 2xx:表示请求已被成功接收;

  3. 3xx:要想完成请求必须进行更进一步的操作;

  4. 4xx:客户端有误,请求有语法错误或请求无法实现;

  5. 5xx:服务器端错误,服务器未能实现合法的请求。


服务器返回相应文件


请求成功后,服务器会返回相应的网页,浏览器接收到响应成功的报文后会开始下载网页,至此,通信结束。


浏览器解析渲染页面


浏览器在接收到HTML/css/js文件之后是怎么将页面渲染在浏览器上的?

浏览器在拿到服务器返回的网页之后,首先会根据顶部定义的 DTD 类型进行对应的解析,解析过程将被交给内部的 GUI 渲染线程来处理。




  • 浏览器:浏览器是一个本地应用程序,它根据一定的标准引导页面加载和渲染页面

  • css:Cascading Style Sheets,层叠样式表,用于html中各元素样式显示

  • JS:JavaScript,在web应用中控制用户和网页应用的交互逻辑



参考文章



  1. 超详细讲解页面加载过程

  2. 网页加载过程简述


作者:在因斯坦
来源:juejin.cn/post/7174744415221579832
收起阅读 »

疫情过后的这个春招,真的会回暖吗?

哈喽大家好啊,我是Hydra。 今天是正月初七,不知道大家有没有复工,反正我今天已经坐在办公室里开始码字了。 这个春节假期相信大家过的都不错,可以看到今年无论是回家探亲、还是外出旅游的人数,都比疫情放开前两年有了爆发式的增长。假期我躺在被窝里刷抖音,每当刷到哪...
继续阅读 »

哈喽大家好啊,我是Hydra。


今天是正月初七,不知道大家有没有复工,反正我今天已经坐在办公室里开始码字了。


这个春节假期相信大家过的都不错,可以看到今年无论是回家探亲、还是外出旅游的人数,都比疫情放开前两年有了爆发式的增长。假期我躺在被窝里刷抖音,每当刷到哪个景点人满为患到走不动路的时候,都觉得自己宅在家里哪也不去真的是太对了。


好了回归正题,很多小伙伴们非常关注的一个问题,在经历了疫情放开、大规模感染的相对平稳后,这一届春招真的会回暖吗?


在聊春招之前,我觉得还是有必要再来科普一下春招的时间线。



  • 12月,一般只有少量的企业开始进行春招提前批预热,或是进行秋招的补录

  • 1月,部分公司开启春招正式批

  • 3-4月,才是春招的高峰期,大部分公司在这个时间段陆续开启春招

  • 5月,大部分的企业会结束招聘


为了了解今年的形势,我也逛了不少论坛,了解到有一些大厂在去年12月底的时候,就已经开始了秋招的补录,不少人收到了补录的通知。



通过整体氛围来看,今年春招大概率会比去年进行一波升温,在岗位的可选择性上,大伙可能也有更多的大厂岗位可以进行一波冲击。尽管如此我还是劝大家要尽早准备,因为虽然说是春招,但并不是真正到了春天才真正开始,并且春招的难度比秋招可能还要高上不少。


首先,相对于秋招来说,春招的岗位会少很多,因为春招更多是对于秋招的补充,是一个查漏补缺的过程,对秋招中没有招满、或者有新岗位出现的情况下,才会在春招中放出该岗位。少量的岗位,需要你能更好的把握信息资源,迅速出击。


其次,你可能拥有更多的竞争对手,考研、考公失利的同学如果不选择二战,将会大量涌入春招,而对于秋招找到的工作不满意想要跳槽的同学,有笔试面试经验、工作经历,将会成为你春招路上麻烦的对手。


所以说到底,大家还是不要过于盲目乐观,扎扎实实的准备肯定是不能少的,毕竟春招的难度摆在这里。在看到大规模补录的同时,我们也不能否认背后的裁员依旧存在。有可能你现在看到的hc,就是在不久前刚刚通过裁员所释放的。


另外,我还是得说点泼冷水的话,虽然看上去形势一片大好,岗位放开了很多,但不代表薪资待遇还是和以前一样的,从一个帖子中可以看到,即便是在杭州和成都的中厂里,降薪也是存在的。



因为说到底,疫情并不是经济下行的根本原因,想要寄希望于疫情放开后经济能够快速复苏基本是不可能的。


国内的互联网公司,已经过了那个爆发式发展的黄金时期,甚至说一句互联网公司规模已经能隐隐约约窥到顶峰也不过分。美联储加息、中概股暴跌、企业融资困难…面对这些困难的环境,即使疫情放开也于事无补。


尽管环境如此困难,我仍然认为互联网行业是小镇做题家们快速实现社会价值、积累财富的黄金职业。看看大厂里十几万、几十万的年终奖,并不是每个行业都能做到的。


最后还是建议大家,积极准备,不管这个春招是否回暖,还是要做到尽量不留遗憾,不要给自己找借口,再寄希望于下一个秋招。


2023年,我们一起加油!


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

浅谈理论:为什么图论是当今各行各业必备的知识?

引子 “若无必要,勿增实体”--奥卡姆剃刀原理 图论(Graph Theory)是被大众严重低估的数学基础理论。它不是研究图像、图片、图表之类的理论,而是一个抽象而简单的数学理论。图论中的图(Graph)是一个抽象概念,非常类似于关系网络(Relation...
继续阅读 »

引子



“若无必要,勿增实体”--奥卡姆剃刀原理



图论(Graph Theory)是被大众严重低估的数学基础理论。它不是研究图像、图片、图表之类的理论,而是一个抽象而简单的数学理论。图论中的(Graph)是一个抽象概念,非常类似于关系网络(Relationship Network),有对应的节点(Node)或顶点(Vertext),节点之间又有关联关系或(Edge)。图论的概念非常简单,就是图、节点、边。本篇文章将简单的介绍一下图论的基础概念,以及图论在真实世界中的应用。(注意!本文不是科学论文,所以不会有枯燥的数学公式,请放心食用)


graph


图论简述


在图论中,有三个重要的概念:



  1. 节点(Node):可以理解为某个实体,例如关系网络中的张三、李四、王五;

  2. (Edge):可以理解为实体间的关系,例如,张三和李四是夫妻,王五是他们儿子;

  3. (Graph):可以理解为所有节点、边的集合,例如张三、李四、王五组成的幸福一家。


从上面的三个基本概念,我们可以推断出节点之间的关系,例如李四的大哥李一,就是王五的舅舅,王五也是他的侄子。


graph-basic-concepts


当然,图论的应用远不止于此,在我们真实世界中,图论的应用非常之广,以至于普通大众都难以察觉它的存在。


下面,我们将介绍一下图论在技术领域的常见应用。


搜索引擎


谷歌、百度、必应,这些都是我们日常使用的搜索引擎(Search Engine)。如果我们需要了解什么知识,一般会打开搜索引擎,输入关键词(Keyword),然后搜索引擎就会返回相关的结果,而且还通常极为精确。其实,搜索引擎技术背后的核心理论就是图论。


咱们可以将某个网站的每个网页(Web Page)想象成一个节点,页面上超链接(Hyperlink)就是对应的,而网站(Site)就是,其包含所有的网页(节点)以及网页关系(边),例如下图。


webpage-graph


而搜索引擎为什么能魔法般的将搜索结果返回给用户,就是巧妙应用了 PageRank 的算法,将节点关系用线性代数表示出来,然后计算与关键词最相似的节点或网页,最后实现搜索引擎的基础搜索功能。对 PageRank 算法感兴趣的朋友,可以查看相应的资料,网上很多,就不赘述了。


自然语言


自然语言(Natural Language)其实就是中文、英文、日文等自然人对话所使用的语言。例如,张三给李四说 “我爱你”,或者你问朋友 “上周我在市区发现了个超棒的咖啡馆,这周末有空一起去么?”,甚至本篇文章的所有文字,都是自然语言。


那么,图论跟自然语言有什么关系?其实,如果我们仔细思考下,会发现中文有主语、谓语、宾语三种词性,例如 “我爱你” 这样简单的主谓宾句子。而实际上,这个句子可以由图来表示,其中主语(“我”)和宾语(“你”)是节点谓语(“爱”)就是,即表示主语对宾语的关系。当然,对于复杂的句子,关系会更复杂一些,对应的图也就更复杂,但总归可以用图、节点、边来表示各个词语之间的关系。


下图表示的是 "Susan might not believe you" 这个句子的图,它是一个树状结构(Tree Structure)。而(Tree)也是一种图,它是一种特殊结构。


natural-language-graph


现在很火的翻译软件、语音识别、聊天机器等,背后的自然语言处理(Natural Language Processing)技术都来自于图论。


思考题:程序代码(例如 Python)可以用图论处理么?


人工智能


最近一段时间,人工智能(Artificial Intelligence)技术大红大紫,其中核心技术来自于深度神经网络(Deep Neural Network),即神经网络(Neural Network)的一种特殊形式。而神经网络的概念,简单可以理解为由神经元组成的大脑神经网络类似的结构。大脑中些神经元的电信号会通过神经网络传递到其他神经元,从而产生意识、想法、认知等抽象概念,而这背后的逻辑非常简单,就是电信号触发,只不过数量极为庞大。而如今深度神经网络的成功,也受益于计算机上搭建的大规模神经网络运算系统。全球著名人工智能公司 OpenAI 的 GPT-3 语言模型,由 1750 亿个参数组成,这已经接近成人大脑神经元数量级了。


万物皆图论


图论的概念非常简单,就像物理世界中的原子、分子、化学键这样的抽象概念,很容易在数学上进行处理。因此,大到全球互联网,小到蛋白质分子结构,图论在真实世界中的绝大部分领域都可以广泛得到应用。因此,学习好图论,对我们在工作生活学习中解决真实问题有非常大的帮助。例如,最优时间安排问题,就可以用图论来建模;而白领们常用的透视表,同样可以用图论中的二部图来处理。最近,笔者也在试着将图论应用到智能网页信息提取技术。学习图论有助于帮助我们更好的理解这个世界,从而可以更加合理的处理好我们自己的生活和工作。


社区


如果您对笔者的文章感兴趣,可以加笔者微信 tikazyq1 并注明 "码之道",笔者会将你拉入 "码之道" 交流群。


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

裸辞回家遇见了她

22年,连续跳了二三家公司,辗转七八个城市。 可能还是太年轻,工作上特别急躁,加班太多会觉得太累,没事情做又觉得无聊烦躁。去年年末回老家过年因为一些巧合遇见了她。年初就润,回到了老家。当时因为苏州疫情就没回去,便开始在老家这边的坎坷之旅。 年初千里见网友 说起...
继续阅读 »

22年,连续跳了二三家公司,辗转七八个城市。

可能还是太年轻,工作上特别急躁,加班太多会觉得太累,没事情做又觉得无聊烦躁。去年年末回老家过年因为一些巧合遇见了她。年初就润,回到了老家。当时因为苏州疫情就没回去,便开始在老家这边的坎坷之旅。


年初千里见网友


说起来也是缘分,去年年末的时候,有个人加了我微信,当时也是一头雾水,还以为是传销或者什么。一看名字微信名:“xxx”,也不像是啊,当时没放在心上就随便聊了聊,也没咋放心上。后来我朋友告诉我她推的(因为觉得我挺清秀人品也还行),就把她推给了我。但是我这人自卑又社恐,加上她在我老家那边,就想反正自己好多年也不想回老家那个地方,现在即使网恋也是耽误人家,后面就没咋搭理她。

到过年的时候,我和我妈匆匆忙忙回到了老家,当时家里宅基地刚好重建装修完,背了一屁股的债务,当时很多人劝我不要建房子在老家,有钱直接在省会那边付个首付也比老家强,可我一直觉得这个房子是我奶奶心心念念了一辈子的事情。转念一想一辈人有一辈人的使命,最多就是自己再多奋斗几年就没多去计较。


后面过年期间,我和她某明奇妙的聊起来了,可能是我觉得离她近了,然后就有一丝丝念想吧,当时因为一些特殊原因,过年的时她也在上班。那几天基本每天从早聊到晚,稍微有点暧昧,之后还一起玩游戏,玩了几局,我也很菜没能赢,就这样算是更深一步了解她吧,当时也不好断定她是怎样的人。就觉得她很温柔、活泼、可爱、直爽,后面想了想好像很久好久没用遇到这样的女孩子了吧,前几年也遇到不少女孩子都没有这种感觉。是不是自己单身太久产生的幻觉。经过一段时间的发酵,我向我朋友打听了下她。


我朋友说人品没问题,就是有点矮,我想着女孩子没啥影响,反正我也矮。就决定去见见她,她也没拒绝我。缘分到了如果不抓住的话也不知道下一次是什么时候。其实那时候我们还只是看过照片,彼此感觉都是那种一般人,到了这个年纪(毕业二三年)其实都不是太在乎颜值,只要不是丑得不能见人(颜值好的话肯定是加分项)。虽然我们都在老家,但她兼职那边还是有点远,去那边需要转很多车。但也没什么,我义无反顾去见了他,也许这就是大多数人奔现的样子吧(但我心里是比较排斥这个词的)。


那天早上一大早我就急冲冲起来了,洗个了头,吹了个自认为很帅的发型,戴上小围巾就出发了(那晚上其实下了很大的雪)。因为老家比较远我都比较害怕那边没有班车,因为当时才大年初三,我们那边的习俗是过年几天不跑车,跑车一年的财运都会受影响。到路上果然没让我失望,路上一辆车都没有,也是运气好,我前几天刚好听到我表姐说要去城里,我就问了问,果真就今天去(就觉得很巧合,跟剧本一样),他们把我送到高铁站,道了个谢,就跑去赶了最早一班的高铁。


怀着忐忑的心情出发了,那时差不多路上就是这个样子吧(手机里视频传不上去)。


image.png
在路上的时候她一直强调说自己这样不行,那样不可以怕我嫌弃,我当时倒是不自卑,直接对人家就是一顿安慰。到了省会那边,又辗转几个地方去买花,那时过年基本没什么花店开门。转了几个大的花店市场才发现一家花店,订了一束不大不小的花, 又去超市买了个玩偶和巧克力,放了几颗德芙在衣服包里面(小心机)。前前后后忙完这些已经下午一点了,对比下行程,可能有点赶不上车了。匆忙坐了班车到了她上班那个市区 ,本以为一切都会很顺利,结果到了那边转车的班车停运了,当时其实是迷茫的。不知道要不要住宿等到第二天。


那时我想起本来就是一腔热情才跑过来的,也许过了那个劲就不会有那个动力去面对了,心里默想:“所爱隔山海,山海皆可平”。心疼的打了个车花了差不多五百块(大冤种过年被宰)。就这样踏上最后一段路程。路上见到不一样的山峰,矮而尖而且很密集,那个司机说天眼好像就是建筑在这边吧,路上我就一直想:即使人家见了我嫌弃我这段旅行也算很划算的吧。最终晚上七点到达了目的地,下车了还是有点紧张,我害怕她不喜欢我这样的,毕竟了解不多,也许就是你一厢情愿的认为这就是缘分和命运的安排。


终将相遇


最后一刻,我都还在想,她会不会看到我就跑了,然后不来见我。但应该不至于此,毕竟我相信我的老朋友(七年死党),也相信她的人品。我看见一个人从前面走来我还以为是她,都准备迎上去了,走近一看咋是个阿姨(吓我一跳还以为被骗了),等我反应过来那个阿姨已经走远了。然后一个声音从我对面传来:“我在这,我在这边”,我转头过去惊艳到我了,这这这是本人吗?深邃的眼眸,樱桃小嘴,不是很尖的脸蛋,短发到肩,微风吹起刘海飘啊飘,像飘进了我的心里,头后发带将一些头发束起,然后发带结成蝴蝶结,一身长白棉袄配白皮鞋,显得俏皮又惊艳。我还来不及细想,我就迎了过去,提前想好的台词都没有说出来,倒是显得有一些尴尬。


当时自卑感油然而生,自己觉得配不上她。寒暄了几句我将花递给她,没有惊喜的表情,只有一句:我都没给你准备什么礼物,你这样我会很不好意思的,她这样说我该是开心还是难过呢?我心里觉得大概要凉了。就怕一句:你是个好人,我们就这样吧。其实当时我们也没说啥喜欢啥的就是有点暧昧。所幸没有发生她嫌弃我的事情,我们延着路边一路闲聊下去,一开始我还有点拘谨,毕竟常年当程序员社交能力不是很行。


慢慢的,我们说了很多很多,她请我吃了个饭(之前说过请她没倔过她),一路走着走着,说着大学的事,小时候的事,工作的事,一时间显得我们不是陌生人,而是多年未见的好友,一下子就觉得很轻松很幸福,反正我已经深深的迷上她的人美心善。她也说了离家老远跑来这边上班的原因(不方便透露)。走着走着我发现她的手有点红,就说道:我还给你准备了个惊喜,把手伸进我衣服包里吧,我在里面放了几颗糖,上班那么辛苦有点糖就不苦了。后面我有点唐突抓住她的手,我说给她暖一下太冰了。她说放我包里就暖和了,我看她脸都红了,也觉得有点唐突了。后面发现还是太冰了,没多想就用牵住了她,嘿嘿!她直接害羞的低下了头。一下子幸福感就涌上来了。


后面很晚的时候要分别了,送他回了宿舍,并把包里的玩偶以及剩下的零食一并给了她。她说第二天来送我,我便回了酒店。


第二天我们俩随便吃了点东西(依旧很害羞没敢坐我对面),她就送我上车了,临走时她塞了一个东西在我手里,打开一看昨天的发带,抬头她已走远她小声说了一句:我们有缘再见。也许是想着我在苏州她在遵义太远了吧,可能就是最后一面了,有点伤心也没多问。


微信图片_20220831164746.jpg


感情生活波折


回去的第二天我便回到苏州那边,但是很久之前就谋划着辞职,一方面是觉得在这边技术得不到提升,一方面是觉得想换个环境吧,毕竟这边太闲了让我找不到价值。可能年轻急躁当时没多想就直接裸辞了,期间我对她说:我辞职后来看她,她有点不愿意(说感觉我们的感情有点空中楼阁),可能觉得见一面不足以确定什么吧,我可能觉得给不了他幸福也舍不得割舍吧。


后面裸辞后,蹭着苏州没有因为疫情封禁,直接带了二件衣服就回了老家。(具体细节不说了)


第二次见她,可能觉得有点陌生吧,不过慢慢的就过了那个尴尬期,我们一起去逛公园、去逛街、彼此送小礼物、一起吃饭,即使现在回来依旧觉得很美好。但是我依旧没有表白,可能我觉得这些事顺理成章的不需要。一次巧合我去了她家帮她做家务、洗头、做饭。哈哈哈,像一个家庭主男一样。可能就是那次她才真的喜欢上我的吧。


有一次见面之后因为一些很严重的事我们吵架了,本来以为就要在此结束了。后来我又去见她了,我觉得女孩子有什么顾虑很正常的,也许是不够喜欢啥的,准备最后见一面吧,但见面之后准备好的说辞一句没说,还是像原来那样相处,一下子心里就有点矛盾,后面敞开心扉说开了,心里纠结的问题也就解决了。慢慢的我们也彼此接受了,从一见钟情到建立关系,真的经历很多东西。不管是少了那一段经历我和她都不会有以后。我的果决她的温柔都是缺一不可的。


后续


她考研上岸,我离开苏州在贵阳上班。我们依旧还有很长一段路要走。后续把工作篇发出来(干web前端的)


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

职场上有什么谎言?

努力干活就能赚多点钱 职场中最大的谎言可能是“工作越忙就能赚到更多的钱”。虽然在某些情况下这是真实的,但很多时候这只是一种误解。长时间超负荷工作可能会导致身体和心理健康问题,甚至影响到家庭生活和人际关系。此外,很多公司并不愿意在工作强度过高的员工身上支付额外的...
继续阅读 »

努力干活就能赚多点钱


职场中最大的谎言可能是“工作越忙就能赚到更多的钱”。虽然在某些情况下这是真实的,但很多时候这只是一种误解。长时间超负荷工作可能会导致身体和心理健康问题,甚至影响到家庭生活和人际关系。此外,很多公司并不愿意在工作强度过高的员工身上支付额外的报酬,而是更倾向于平衡员工的工作与生活,提高员工的幸福感和满意度。因此,新进职场人士应该认识到,在职场中坚持适度的工作量、良好的工作习惯和优秀的职业素养才是取得成功的重要因素。


我都是为你好


“我都是为你好”可能是一种常见的谎言,在不同情境下被使用。在某些情况下,这可能真诚地表达出对他人的关心和照顾,但在其他情况下,这也可能成为掩盖自己私人动机或者行为错误的借口。因此,在职场和日常生活中,我们需要学会审视这句话所蕴含的背后意图,并判断其是否真实可信。同时,我们也应该秉持着开放、坦诚、尊重和理解的态度,与他人进行良好的沟通和相处,以建立健康、和谐的人际关系。


他做得比你好,向他好好学习


“他做得比你好,向他好好学习”是一句非常有益的建议,可以让人们从成功的经验中汲取营养,不断提高自己的能力和水平。在职场中,人们面对不同的工作任务和挑战,而且每个人的工作方式、思维模式和经验都不同,因此,我们应该善于借鉴他人的优点和长处,吸取别人的经验和教训,不断完善自己的职业素养和技能。然而,这并不意味着要完全依赖和模仿别人,而是应该在合适的时机,根据自身实际情况和需要,加以改进和创新,开拓自己的专业视野和发展空间。


在职场中,有些人可能会通过拍马屁、拉关系等不正当手段来获取自己的利益或者提高自己的地位。然而,这种做法可能会导致负面后果和损失,例如破坏工作团队的合作氛围、损害自己的职业形象和信誉等。因此,我们应该始终保持清醒和冷静的头脑,不受拍马屁等诱惑,专注于自己的工作和职责,努力提高自己的专业水平和职业素养。同时,我们也应该与他人建立良好的人际关系,以合理、公正、透明的方式展示自己的才华和成果,赢得别人的尊重和信任,并在适当的时刻借助他人的力量来实现共同的目标。


公司不怎么赚钱,理解一下,行情好了加工资


如果公司在过去设定了一些目标和承诺,但无法兑现或者没有达到预期的结果,那么这就是一种失信行为。画饼充当推销手段,可能会对员工、客户和利益相关方造成误导和不良影响,并破坏公司的商誉和形象。因此,公司应该根据市场实际情况和自身能力水平,制定合理、可行的计划和策略,避免过于浮夸和虚幻的承诺,注重落实和执行,加强与员工、客户和社会各方的沟通和互动,建立坦诚、透明的企业文化和价值观念。同时,员工也应该保持客观、谨慎、理性的态度,不盲目追求高回报或者虚假宣传,始终以个人职业道德和职责为先,为公司和自己的未来发展负责任。


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

关于 Android App 架构,你可能会被问到的 20 个问题

LiveData 是否已经被弃用?没有被弃用。在可以预见的未来也没有废弃的计划。LiveData 可以使用简单的方式获取一个易于观察、状态安全的对象。虽然其缺少一些丰富的操作符,但是对于一些简单的 UI 业务场景已经足够。Flow 有&nb...
继续阅读 »

LiveData 是否已经被弃用?

没有被弃用。在可以预见的未来也没有废弃的计划。

LiveData 可以使用简单的方式获取一个易于观察、状态安全的对象。虽然其缺少一些丰富的操作符,但是对于一些简单的 UI 业务场景已经足够。

Flow 有 LiveData 相同的功能,其包含大量丰富的操作符,可以简单的完成复杂的业务逻辑处理。相应的会增加一定的使用门槛,如果不需要 Flow 的 全部功能,继续使用 LiveData 即可。

更多内容:Migrating from LiveData to Kotlin’s Flow

什么是业务逻辑?为什么将业务逻辑移动到 Data Layer ?

业务逻辑是给 App 带来价值的东西,是一系列决定 App 如何运行的规则集。比如,如果你有一个显示新闻文章的 App,你点击书签按钮,从书签文章到持久的交互,这就是业务逻辑。

将业务逻辑移动到 Data Layer 的主要原因是提供单一信源,App 的不同页面和不同逻辑使用到这部分数据将从同一个地方进行获取,方便统一管理;其次是分离职责,将不同的处理逻辑(控制UI的与操作数据)分散在不同的层级中,可以减少各自交互的复杂度。

如何在 ViewModel 中获取系统资源(字符串、颜色等)?

访问资源只应该放在 UI 层,如 View 或者是 Compose。 可以在 ViewModel 中提供资源 ID,但是不应该直接在 ViewModel 中直接访问资源。除了单一职责之外,就是可以响应手机配置的变化:

  • 切换语言的时候,会变成对应的语种字符串;
  • 切换亮暗模式的时候,对应的颜色会随之变化;

另外就是 Context 的上下文与 ViewModel 的生命周期不一致,可能会导致内存泄漏。

如何让 Service 与 Compose/ViewModel 进行交互?

Modern Android App Arch.001.png

他们不应该直接进行交互或者说是互相引用。

应该采用单一信源的方式定义一个 Repository,在 Service/ViewModel 中调用 Repository 中的方法来更改状态,UI(Views/Compose) 层通过数据流的方式监听数据变化。

可以确定的是,在 ViewModel 中应尽可能少的依赖 Android 系统组件,如 Service、Activity 等。

未来平稳过度到 KMM/KMP 的最佳实践有哪些?

通常最佳实践会随着时间的推移而建立起来的。对于未来如果 KMM/KMP ,并不需要做过多的事情,遵循架构指南即可。比如:将数据的操作放在 Data Layer,在此层尽量少的调用系统 API。但是目前并需要定义跨端的接口定义,因为 KMM/KMP 还是比较新的技术,在他被大规模使用之前还有不少变数。

ViewModel 被建议当做 State Holders 之后,其在 MVVM 中的职责?

ViewModel 在 MVVM 中就是一个状态持有者。在不同的语义场景下可能有不同的含义。如果是整个页面中的 View(不论是 Activity 还是 Compose 中的目的地),其对应的是 AAC 中的 ViewModel 类。如果是普通的自定义 View 或是 Compose 中的一个可组合函数,那么 View 的状态持有者定义成一个普通的类就可以。这里可以类比下 RecycleView 中的 ViewHolder 设计。

所以这是根据 UI 的范围所决定的,整个页面对应的就是 ViewModel,局部页面对应的就是普通的类。

ViewModel 可以当做是一种特殊的状态管理器,他可以持有普通的 State Holders。

架构指南中的层级对模块化开发有什么建议么?

官方正在研究模块化的架构指南,希望今年能够完成。

应该在 DataSource/Repostory/UseCase 中使用 Flow 么?

可以,但是应该在合适的地方使用 Flow。如果是提供一个一次性的数据(比如从云端接口返回的一个数据),使用 suspend 函数是比较合适的。如果是从 Room 或者是其他类似的数据源中提供可以变化的数据流时,应该使用 Flow。

在 Repository 中会合并多个数据源的数据,这些数据可能会会随时间的变化而变化,因此需要使用 Flow。

什么时候应该使用 UseCase ?

UseCase 主要是为了解决以下两个问题:

  • 封装复杂的业务逻辑,避免出现大型的 ViewModel 类;
  • 封装多 ViewModel 通用的业务逻辑,避免代码重复;

满足上述两个条件的任何一个都可以使用 UseCase。除此之外,使用 UseCase 之后可以 ViewModel 就不必依赖 Repository,而是在构造函数中直接使用 UseCase,这样在构造函数中就可以知道 ViewModel 中做了哪些事情。

在 Repository 中传递多个 Suspend 函数是反模式的么?

并不是,如果只是进行一次性的操作应该使用 suspend 函数。否则的话应该使用 Flow

ViewModel 中如何处理页面跳转?

这部分内容在 UI Layer 中有提到,我们把他称之为 UI Event 之类的东西。不管是 UI 事件还是构建 UI 的数据都应该放在 UiState 中,一旦 UI 层监听到对应的事件,进行响应的跳转即可。

具体取决于采用何种方式建模,比如你可以把他定义为一个 Boolean 值,在 ViewModel 中更新对应的 UiState,UI 层就可以根据对应的事件跳转到对应的页面中了。

以用户登录为例,用户登录成功之后需要进入到主页面。这其实是一种状态的变化,从未登录变成了已登录,所以只要改变 UiState UI 层就可以处理他。你可能会说这是不是太复杂了?

对一些人来说这可能是一个顿悟时刻,不会把命令视为事件。ViewModel 中的事件整体上来看就是 App 的状态数据,这样 ViewModel 并不是告诉 UI 层应该做什么,而是 UI 层根据 App 的状态去做一些事情,这是思维方式上的转变。

如果根据用户配置定义导航视图?

和上一个问题基本类似,通过设置不同的 UiState 来控制导航到不同的视图。

WorkManager/Service 在架构中的什么位置?

WorkManager/Service 应该作为入口类来调用 Repository 中的 API。这样可以使我们的业务逻辑与 Android 系统的 API 中解放出来,因为 Android 系统 API 的行为逻辑一般是我们不可控的。当然还有另外的好处,比如更容易测试、以及后续有可能迁移到 KMM 。

当然,WorkManager 有其 API 自身的优势,其内部逻辑与节省电量 、WIFI 链接等 Android 平台的优势,可以根据设备自身的状态进行一次性或者周期性的任务。当然,如果是正常的耗时操作(如网络请求)使用简单的协程即可。

为什么有时在 Repository 中使用 IoDispatcher 访问数据库,有时不用?

Room 数据库目前已支持 suspend 函数,其默认会将任务放到后台线程中执行,当然也可以对其进行自定义的配置。当你调用 Room 的一个 suspend 函数的时候,你并不需要关心线程的问题,把这个问题交给 Room 处理即可。这样 Room 的所有操作都会放到 Room 控制的线程中执行,以尽可能的减少因访问同一个文件而导致的互相争夺资源的问题。

不管由于什么原因你无法使用/提供 suspend 函数,Room 不支持将其移动到另一个线程中。这种情况下可以使用 IO 线程或者 IoDispatcher 。通常情况下还是建议使用 suspend 函数或是 Flow。

另外,每个 DataSource 中都建议处理自己的线程问题,所以在 Repository 中并不需要关心 IO 线程的问题。

当我们处理内存敏感数据时,将复杂数据从一个屏幕传输到另一个屏幕的建议方法是什么?

最原始的处理方式可能是使用 Activity 当做两个 Fragment 的中介,在 Activity 中实现 Fragment 中定义接口,当 Fragment 被关联到 Activity 之后就可以调用 Fragment 中相关的逻辑了。当然这种方式已经一去不复返了。

现在可以使用 ViewModel 调用 UseCase 或者是 Repository 来更新数据,另外的 ViewModel 会使用 Flow 的方式接收到数据的变化,然后根据变化做出相应的处理即可。

在 Compose 中应该使用 MVVM 还是 MVI ?

两者没有本质的区别,都是采用单向数据流的方式。MVI 的特点是将 UI 事件封装成枚举方式,统一在一个函数中处理事件。

随着项目的扩展,我应该将 Domain Layer 或者 Data Layer移动到单独的模块吗?

这取决于你是否想进行模块化,但是两者的差异并不大,这里并没有一个明确的答案。 随着项目的扩展建议把 Data Layer 放到单独的 module 中,如果有 Domain Layer 的话,也是建议把他放在单独的模块中。

[!info] 注: 如果是在多仓库的模块架构以及同一数据层可能有不同 UI 实现的场景下建议采用上述方式,如果没有类似需求的话,个人建议通过 Feature (特性)划分模块,这样可以减少不必要的编译耗时,同样的功能也想多内聚。 当然,如果有对外提供 SDK 需求的,也应将 Data Layer 定义在单独的模块中。

将错误从其他层返回到表示层的最佳方法是什么?

指导文档 中的建议的方式是使用协程的异常处理机制将错误传递到展示层(UI Layer)。

对于使用协程或者是 Flow 的方式,建议使用协程的异常处理机制,当然 Folw 中也可以使用 catch 操作符;对于使用 suspend 函数的地方可以使用 try/catch 块。

另外一种 Data Layer 和上层交互的方式就是使用 Kotlin 自带的 Result<T> 类,此类中除了包含正常的数据 T 之外,还包含错误信息。除此之外提供很多好用的 API ,建议使用。

更多内容:Exceptions in coroutines

新的架构方式是否适用与非移动端的领域?如平板、Auto 等

在上述的领域上,仍然建议使用 UI LayerDomain LayerData Layer 这种架构方式。这种架构方式主要是用到了关注点分离以及数据驱动的方式,而这两种设计原则对非移动端的应用也是适用的。

多 Activity 还是单 Activity + 多 Fragment ?

Activity 有其自身的一些特定及职责,在以下场景中应该使用 Activity:

  • 当前页面需要支持 PIP(画中画)功能时;
  • 当 App 有多个入口可以启动时,如在其他 App 中拉起当前 App 中的一个二级页面,这个页面就需要使用 Activity;

简而言之,就是需要在 manifest 文件中 exported 需要被设置为 true 的逻辑都需要使用 Activity 来实现。

除此之外的一些逻辑,通常是 App 内部的一些页面导航,这个时候应该使用 Fragment 来实现。当然,现在我们还有另外一个新的选择,那就是使用 Compose 。

总结

这篇文章中的内容根据 Arch - MAD Skills 中的问答部分,结合自己的理解整理而得,会包含个人观点,更多详细内容可以观看原文。


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

封装Kotlin协程请求,这一篇就够了

协程(coroutines)的封装 在默认的Kotlin协程环境中,我们需要自定义协程的作用域CoroutineScope,还有负责维护协程的调度等等,有没有方法可以让协程的使用者屏蔽对底层协程的认识,简单就能使用呢?这里带来了一个封装思路。(这里没有考虑生命...
继续阅读 »

协程(coroutines)的封装


在默认的Kotlin协程环境中,我们需要自定义协程的作用域CoroutineScope,还有负责维护协程的调度等等,有没有方法可以让协程的使用者屏蔽对底层协程的认识,简单就能使用呢?这里带来了一个封装思路。(这里没有考虑生命周期相关的封装,如果需要实际落地可以在deferred里面封装),这里有个背景,比如在java kotlin混合开发的时候,如果java同学不会kotlin,就需要更上一层的抽象了


封装前例子


假如我们有个一个suspend函数

suspend fun getTest():String{
delay(5000)
return "11"
}

我们要实现的封装是:


1.执行suspend函数,并且使用者对底层无感知,无需了解协程就可以使用,这就要求我们屏蔽CoroutineScope细节


2.自动类型转换,比如返回String我们就应该可以在成功的回调中自动转型为String


3.成功的回调,失败的回调等


4.要不,来个DSL风格

//
async{
// 请求
getTest()

}.await(onSuccess = {
//成功时回调,并且具有返回的类型
Log.i("print",it)
},onError = {

},onComplete = {

})

image.png
可以看到,编译时就已经将it变为我们想要的类型了!
我们最终想要实现上面这种方式


封装开始


思路:我们自动对请求进行线程切换,使用Dispatchers即可,还有就是我们需要有监听的回调和DSL写法,所以就可以考虑用协程的async方式发起一个请求,返回值是Deferred类型,我们就可以使用扩展函数实现.await的形式!如果熟悉flutter的同学看的话,是不是很像我们的dio请求方式呢!下面是代码,可以根据更细节的需求进行补充噢:

fun <T> async(loader:suspend () ->T): Deferred<T> {
val deferred = CoroutineScope(Dispatchers.IO).async {
loader.invoke()
}
return deferred
}

fun <T> Deferred<T>.await(onSuccess:(T)->Unit,onError:(e:Exception)->Unit,onComplete:(()->Unit)?=null){
CoroutineScope(Dispatchers.Main).launch {

try{
val result = this@await.await()
onSuccess(result)

}catch (e:Exception){
onError(e)
}
finally {
onComplete?.invoke()
}
}
}

总结


是不是非常好玩呢!我们实现了一个dio风格的请求,对于开发者来说,只需定义suspend修饰的函数,就可以无缝使用我们的请求框架!


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

我尝试以最简单的方式帮你梳理 Lifecycle

前言 我们都知道 Activity 与 Fragment 都是有生命周期的,例如:onCreate()、onStop() 这些回调方法就代表着其生命周期状态。我们开发者所做的一些操作都应该合理的控制在生命周期内...
继续阅读 »

前言


我们都知道 Activity 与 Fragment 都是有生命周期的,例如:onCreate()onStop() 这些回调方法就代表着其生命周期状态。我们开发者所做的一些操作都应该合理的控制在生命周期内,比如:当我们在某个 Activity 中注册了广播接收器,那么在其 onDestory() 前要记得注销掉,避免出现内存泄漏。


生命周期的存在,帮助我们更加方便地管理这些任务。但是,在日常开发中光凭 Activity 与 Fragment 可不够,我们通常还会使用一些组件来帮助我们实现需求,而这些组件就不像 Activity 与 Fragment 一样可以很方便地感知到生命周期了。


假设当前有这么一个需求:



开发一个简易的视频播放器组件以供项目使用,要求在进入页面后注册播放器并加载资源,一旦播放器所处的页面不可见或者不位于前台时就暂停播放,等到页面可见或者又恢复到前台时再继续播放,最后在页面销毁时则注销掉播放器。



试想一下:如果现在让你来实现该需求?你会怎么去实现呢?


实现这样的需求,我们的播放器组件就需要获取到所处页面的生命周期状态,在 onCreate() 中进行注册,onResume() 开始播放,onStop() 暂停播放,onDestroy() 注销播放器。


最简单的方法:提供方法,暴露给使用方,供其自己调用控制。

class VideoPlayerComponent(private val context: Context) {

/**
* 注册,加载资源
*/
fun register() {
loadResource(context)
}

/**
* 注销,释放资源
*/
fun unRegister() {
releaseResource()
}

/**
* 开始播放当前视频资源
*/
fun startPlay() {
startPlayVideo()
}

/**
* 暂停播放
*/
fun stopPlay() {
stopPlayVideo()
}
}

然后,我们的使用方MainActivity自己,主动在其相对应的生命周期状态进行控制调用相对应的方法。

class MainActivity : AppCompatActivity() {
private lateinit var videoPlayerComponent: VideoPlayerComponent

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
videoPlayerComponent = VideoPlayerComponent(this)
videoPlayerComponent.register(this)
}

override fun onResume() {
super.onResume()
videoPlayerComponent.startPlay()
}

override fun onPause() {
super.onPause()
videoPlayerComponent.stopPlay()
}

override fun onDestroy() {
videoPlayerComponent.unRegister()
super.onDestroy()
}

}

虽然实现了需求,但显然这不是最优雅的实现方式。一旦使用方忘记在 onDestroy() 进行注销播放器,就容易造成内存泄漏,而忘记注销显然是一件很容易发生的事情😂 。


回想初衷,之所以将方法暴露给使用方来调用,就是因为我们的组件自身无法感知到使用者的生命周期。所以,一旦我们的组件自身可以感知到使用者的生命周期状态的话,我们就不需要将这些方法暴露出去了。


那么问题来了,组件如何才能感知到生命周期呢?


答:Lifecycle !


直接上案例,借助 Lifecycle 我们改进一下我们的播放器组件👇

class VideoPlayerComponent(private val context: Context) : DefaultLifecycleObserver {

override fun onCreate(owner: LifecycleOwner) {
super.onCreate(owner)
register(context)
}

override fun onResume(owner: LifecycleOwner) {
super.onResume(owner)
startPlay()
}

override fun onPause(owner: LifecycleOwner) {
super.onPause(owner)
stopPlay()
}

override fun onDestroy(owner: LifecycleOwner) {
super.onDestroy(owner)
unRegister()
}

/**
* 注册,加载资源
*/
private fun register(context: Context) {
loadResource(context)
}

/**
* 注销,释放资源
*/
private fun unRegister() {
releaseResource()
}

/**
* 开始播放当前视频资源
*/
private fun startPlay() {
startPlayVideo()
}

/**
* 暂停播放
*/
private fun stopPlay() {
stopPlayVideo()
}
}

改进完成后,我们的调用方MainActivity只需要一行代码即可。

class MainActivity : AppCompatActivity() {

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)

lifecycle.addObserver(VideoPlayerComponent(this))
}
}

这样是不是就优雅多了。


那这 Lifecycle 又是怎么感知到生命周期的呢?让我们这就带着问题,出发探一探它的实现方式与源码!


如果让你来做,你会怎么做


在查看源码前,让我们试着思考一下,如果让你来实现 Jetpack Lifecycle 这样的功能,你会怎么做呢?该从何入手呢?


我们的目的是不通过回调方法即可获取到生命周期,这其实就是解耦,实现解耦的一种很好方法就是利用观察者模式。


利用观察者模式,我们就可以这么设计👇


截屏2022-12-13 下午3.59.21.png


被观察者对象就是生命周期,而观察者对象则是需要知晓生命周期的对象,例如:我们的三方组件。


接着我们就具体探探源码,看一看Google是如何实现的吧。


Google 实现方式


Lifecycle



一个代表着Android生命周期的抽象类,也就是我们的抽象被观察者对象。

public abstract class Lifecycle {

public abstract void addObserver(@NonNull LifecycleObserver observer);

public abstract void removeObserver(@NonNull LifecycleObserver observer);

public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY;
}

public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
}

}

内包含 State 与 Event 分别者代表生命周期的状态与事件,同时定义了抽象方法 addObserver(LifecycleObserver) 与removeObserver(LifecycleObserver) 方法用于添加与删除生命周期观察者。


Event 很好理解,就像是 Activity | Fragment 的 onCreate()onDestroy()等回调方法,它代表着生命周期的事件。


那这 State 又是什么呢?何为状态?他们之间又是什么关系呢?


Event 与 State 之间的关系


关于 Event 与 State 之间的关系,Google官方给出了这么一张两者关系图👇


theRelationOfEventAndState.png


乍一看,可能第一感觉不是那么直观,我整理了一下👇


event与state关系图.png



  • INITIALIZED:在 ON_CREATE 事件触发前。

  • CREATED:在 ON_CREATE 事件触发后以及 ON_START 事件触发前;或者在 ON_STOP 事件触发后以及 ON_DESTROY 事件触发前。

  • STARTED:在 ON_START 事件触发后以及 ON_RESUME 事件触发前;或者在 ON_PAUSE 事件触发后以及 ON_STOP 事件触发前。

  • RESUMED:在 ON_RESUME 事件触发后以及 ON_PAUSE 事件触发前。

  • DESTROYED:在 ON_DESTROY 事件触发之后。


Event 代表生命周期发生变化那个瞬间点,而 State 则表示生命周期的一个阶段。这两者结合的好处就是让我们可以更加直观的感受生命周期,从而可以根据当前所处的生命周期状态来做出更加合理操作行为。


例如,在LiveData的生命周期绑定观察者源码中,就会判断当前观察者对象的生命周期状态,如果当前是DESTROYED状态,则直接移除当前观察者对象。同时,根据观察者对象当前的生命周期状态是否 >= STARTED来判断当前观察者对象是否是活跃的。

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
......

@Override
boolean shouldBeActive() {
//根据观察者对象当前的生命周期状态是否 >= STARTED 来判断当前观察者对象是否是活跃的。
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}

@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event) {
//根据当前观察者对象的生命周期状态,如果是DESTROYED,直接移除当前观察者
Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();
if (currentState == DESTROYED) {
removeObserver(mObserver);
return;
}
......
}
......

}

其实 Event 与 State 这两者之间的联系,在我们生活中也是处处可见,例如:自动洗车。


自动洗车.png


想必现在你对 Event 与 State 之间的关系有了更好的理解了吧。


LifecycleObserver



生命周期观察者,也就是我们的抽象观察者对象。

public interface LifecycleObserver {

}

所以,我们想成为观察生命周期的观察者的话,就需要具体实现该接口,也就是成为具体观察者对象。


换句话说,就是如果你想成为观察者对象来观察生命周期的话,那就必须实现 LifecycleObserver 接口。


例如Google官方提供的 DefaultLifecycleObserver、 LifecycleEventObserver 。


截屏2022-12-14 下午2.33.11.png


LifecycleOwner


正如其名字一样,生命周期的持有者,所以像我们的 Activity | Fragment 都是生命周期的持有者。


大白话很好理解,但代码应该如何实现呢?



抽象概念 + 具体实现



抽象概念:定义 LifecycleOwner 接口。

public interface LifecycleOwner {
@NonNull
Lifecycle getLifecycle();
}

具体实现:Fragment 实现 LifecycleOwner 接口。

public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,
ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner,
ActivityResultCaller {

public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
......

}

具体实现:Activity 实现 LifecycleOwner 接口。

public class ComponentActivity extends androidx.core.app.ComponentActivity implements
ContextAware,
LifecycleOwner,
ViewModelStoreOwner,
HasDefaultViewModelProviderFactory,
SavedStateRegistryOwner,
OnBackPressedDispatcherOwner,
ActivityResultRegistryOwner,
ActivityResultCaller {

@NonNull
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}

......

}

这样,Activity | Fragment 就都是生命周期持有者了。


疑问?在上方 Activity | Fragment 的类中,getLifecycle() 方法中都是返回 mLifecycleRegistry,那这个 mLifecycleRegistry 又是什么玩意呢?


LifecycleRegistry



Lifecycle 的一个具体实现类。



LifecycleRegistry 负责管理生命周期观察者对象,并将最新的生命周期事件与状态及时通知给对应的生命周期观察者对象。


添加与删除观察者对象的具体实现方法。

//用户保存生命周期观察者对象
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();

@Override
public void addObserver(@NonNull LifecycleObserver observer) {
enforceMainThreadIfNeeded("addObserver");
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
//将生命周期观察者对象包装成带生命周期状态的观察者对象
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
... 省略代码 ...
}

@Override
public void removeObserver(@NonNull LifecycleObserver observer) {
mObserverMap.remove(observer);
}

可以从上述代码中发现,LifecycleRegistry 还对生命周期观察者对象进行了包装,使其带有生命周期状态。

static class ObserverWithState {
//生命周期状态
State mState;
//生命周期观察者对象
LifecycleEventObserver mLifecycleObserver;

ObserverWithState(LifecycleObserver observer, State initialState) {
//这里确保observer为LifecycleEventObserver类型
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
//并初始化了状态
mState = initialState;
}

//分发事件
void dispatchEvent(LifecycleOwner owner, Event event) {
//根据 Event 得出当前最新的 State 状态
State newState = event.getTargetState();
mState = min(mState, newState);
//触发观察者对象的 onStateChanged() 方法
mLifecycleObserver.onStateChanged(owner, event);
//更新状态
mState = newState;
}
}

将最新的生命周期事件通知给对应的观察者对象。

public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
... 省略代码 ...
ObserverWithState observer = mObserverMap.entrySet().getValue();
observer.dispatchEvent(lifecycleOwner, event);

... 省略代码 ...
mLifecycleObserver.onStateChanged(owner, event);
}

那 handleLifecycleEvent() 方法在什么时候被调用呢?


相信看到下方这个代码,你就明白了。

public class FragmentActivity extends ComponentActivity {
......

final LifecycleRegistry mFragmentLifecycleRegistry = new LifecycleRegistry(this);

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
}

@Override
protected void onDestroy() {
mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);
}

@Override
protected void onPause() {
mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);
}

@Override
protected void onStop() {
mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
}

......

}

在 Activity | Fragment 的 onCreate()onStart()onPause()等生命周期方法中,调用LifecycleRegistry 的 handleLifecycleEvent() 方法,从而将生命周期事件通知给观察者对象。


总结


Lifecycle 通过观察者设计模式,将生命周期感知对象生命周期提供者充分解耦,不再需要通过回调方法来感知生命周期的状态,使代码变得更加的精简。


虽然不通过 Lifecycle,我们的组件也是可以获取到生命周期的,但是 Lifecycle 的意义就是提供了统一的调用接口,让我们的组件可以更加方便的感知到生命周期,方便广达开发者。而且,Google以此推出了更多的生命周期感知型组件,例如:ViewModelLiveData。正是这些组件,让我们的开发变得越来越简单。


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

我就问Zygote进程,你到底都干了啥

前言 OK,这是Android系统启动的第二篇文章。第二篇我们讲解一个我们一直都在用,但是却很少提起的进程---Zygote。 提到Zygote可能了解一些的小伙伴会说,它是分裂进程用的。没错它最大的作用的确是分裂进程,但是它除了分裂进程外还做了什么呢。 还是...
继续阅读 »

前言


OK,这是Android系统启动的第二篇文章。第二篇我们讲解一个我们一直都在用,但是却很少提起的进程---Zygote
提到Zygote可能了解一些的小伙伴会说,它是分裂进程用的。没错它最大的作用的确是分裂进程,但是它除了分裂进程外还做了什么呢。
还是老规矩,让我们抱着几个问题来看文章。最后在结尾,再对问题进行思考回复。



  1. 你能大概描述一遍Zygote的启动流程吗

  2. 我们为什么可以执行java代码,和zygote有什么关系

  3. Zygote到底都做了哪些事情


另外,我最近也看了一些写底层的文章。要么就是言简意赅到只知道Zygote的作用,但是完全不知道如何实现的,就像是背作文一样。要么是全篇都是代码,又臭又长,让人完全没有看下去的动力。


不过作为一个读者,太长的我可能完全不想看,太短的又真的完全就是被课文一点都不明白原理。


因此,本篇文章,仍旧会引入一些代码,方便大家通过代码方便记忆。但是又会将代码进行精简,以免给大家造成过度疲劳。我们的目的都是希望用最少的时间,能掌握更多的知识。


读源码时:不要过于纠结细节,不要过于纠结细节,不要过于纠结细节!重要的事情说三遍!!!


OK,让我们进入正题瞅瞅Zygote到底是个什么东西。




1.C++还是Java


选这个当标题当然是有原因的。我们知道的是Android系统启动的时候,运行的是Linux内核,执行的是C++代码。这是一个很有趣的事情。


因为我们在写App的时候,AndroidStudio默认给我们创建的都是Activity.java,而选择的语言,要么是Java要么就是Kotlin


启动时候运行的是C++代码,应用层却可以使用Java代码,这到底是为什么呢?其实这就是Zygote的功劳之一


2.Native层


Init进程创建Zygote时,会调用app_main.cpp的main() 方法。此时它依旧运行的是C++代码。我们通过下面的代码,来看下它到底做了什么。


这里它做的最关键的一件事就是启动AndroidRuntime(Android运行时)。另外这里需要注意的是 start方法 中的 "com.android.internal.os.ZygoteInit" 这个类似于全类名。他到底是做什么的?别着急,大概2分钟后,你可能就会得到答案。


Zygote的新手村:app_main.cpp

int main(int argc, char* const argv[])
{
// 创建Android运行时对象
AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv));
// 代码省略...

// 调用AppRuntime.start方法,
// 而AppRuntime是AndroidRuntime的子类,并且没有重写start方法
// 因此调用的是AndroidRuntime的start方法
runtime.start("com.android.internal.os.ZygoteInit", args, zygote);
}

精简后的代码告诉我们,这里一共就做了两件事,第一件创建AppRuntime,第二件调用start方法


不过,AppRuntimeAndroidRuntime的子类,他没有重写start方法,因此这里调用的是 AndroidRuntime的start() 方法。


奇迹的诞生地:AndroidRuntime:


这里我依旧只保留关键代码,源码关键注释也进行了保留。由下方代码看出这里做了三件改变命运的事情。



  1. startVM -- 启动Java虚拟机

  2. startReg -- 注册JNI

  3. 通过JNI调用Java方法,执行com.android.internal.os.ZygoteInit 的 main 方法
/*
* Start the Android runtime.
*/
void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote)
{
/* start the virtual machine */
JNIEnv* env;
if (startVm(&mJavaVM, &env, zygote, primary_zygote) != 0) {
return;
}

/*
* Register android functions.
*/
if (startReg(env) < 0) {
ALOGE("Unable to register all android natives\n");
return;
}
/*
* Start VM. This thread becomes the main thread of the VM, and will
* not return until the VM exits.
*/
jmethodID startMeth = env->GetStaticMethodID(startClass, "main","([Ljava/lang/String;)V");
env->CallStaticVoidMethod(startClass, startMeth, strArray);
}

有了JVM,注册了JNI,我们就可以执行Java代码了。


这里我个人建议不要过于纠结细节,比如JVM是如何创建的,JNI是如何注册的。如果感兴趣的童鞋,可以下载源码,到app_main.cpp里进行查看。这里就不进行赘述了。否则代码量太大,适得其反。




3.Java层


命运的十字路口:ZygoteInit.java:


之所以说是命运的十字路口,因为Zygote会在这里创建SystemServer,但是二者却走向了截然不同的道路。


从这里就开始执行Java代码了,当然这些Java代码是运行在JVM中的。


让我们通过代码来看一下,到底都做了些什么。

class ZygoteInit{

/**
* This is the entry point for a Zygote process. It creates the Zygote server, loads resources,
* and handles other tasks related to preparing the process for forking into applications.
* This process is started with a nice value of -20 (highest priority).
*/
// 上面是源码中的注释,小伙伴们可以自行翻译一下。
// 创建了ZygoteServer,加载资源,并且介绍了这个进程的优先级是最高的-20.
public static void main(String argv[]) {
ZygoteServer zygoteServer = null;

// 1. 预加载资源,常用的:resource,class,library等在此处进行加载
preload(bootTimingsTraceLog);

// 2. 创建ZygoteServer,实际是一个Socket用来进行跨进程间通信用的。
zygoteServer = new ZygoteServer(isPrimaryZygote);

// 3. fork出SystemServer进程,这个进程会创建AMS,ATMS,WMS,电池服务等一切只有你想不到没有它做不到的服务
forkSystemServer(abiList, zygoteSocketName, zygoteServer);

// 4.里面是一个while(true)循环,等待接收AMS创建进程的消息,类似于handler中的Looper.loop()
zygoteServer.runSelectLoop(abiList);
}
}

上面代码里的注释基本说明了ZygoteInit都干了啥。下面会再稍微总结下:



  1. 创建了ZygoteServer:这是一个Socket相关的服务,目的是进行跨进程通信。

  2. 预加载preload:预加载相关的资源。

  3. 创建SystemServer进程:通过forkSystemServer分裂出了两个进程,一个Zygote进程,一个SystemServer进程。而且由于是分裂的,所以新分裂出来的进程也拥有虚拟机,也能调用JNI,也拥有预加载的资源,也会执行后续的代码。

  4. 执行runSelectLoop():内部是一个while(true)循环,等待AMS创建新的进程的消息。(想想Looper.loop())




4. 戛然而止


没错就是这么突然,Zygote的故事到这就结束了。至于它是如何创建SystemServer,如何去创建App那就是后面的故事了。所以你还记得我的问题嘛?我替你总结一下Zygote到底做了什么:



  1. 创建虚拟机

  2. 注册JNI

  3. 回调Java方法ZygoteInit.java 的main方法,从这儿开始运行Java代码

  4. 创建ZygoteServer,内部包含Socket用于跨进程通信

  5. 预加载class,resource,library等相关资源

  6. fork 出了 SystemServer进程。他俩除了返回的pid不同,剩下一模一样。通过返回值不同来决定剩下的代码如何运行。这个留待后续进行讲解。

  7. 进入while(true)循环等待,等待AMS创建进程的消息(类似于Looper.loop()




5. 多说一句


这个系列才刚刚进行到第二章,我尽量让文章不是特别长的情况下,既有代码整理思路,又有总结方便记忆。代码是源码中摘抄的省略了很大一部分,只能保证执行顺序。有兴趣的小伙伴可以下载源码进行查看。

其实最近我看了很多文章和视频,最后却选择写文章来对知识进行总结。归根结底就是因为一句话,好记性不如烂笔头。要是真的想快速记住,真的需要亲自查看一下源码。翻源码的同时,也是在不知不觉中锻炼你阅读源码的能力。 万一以后让你学习一个新的库,你也知道大概该怎么看。


都已经到这儿了,就稍微厚个脸皮,希望各位看官,能够点个赞加个关注。毕竟一篇文章可能就要耗费几个小时的时间,上一篇文章就几个赞,感谢这几个小伙伴,让我有继续写下去的动力。 真心感谢你们。


另外,文章中有哪里出错,请及时指出。毕竟各位才是真正的大佬。希望各位Androider,可以一起取暖,度过这个互联网寒冬!加油各位!!!




6. Zygote功能图


zygote.png


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

谈公平:你十年寒窗,比人家三代家业?

有一个想法,憋了好久了,迟迟没敢说,怕三观正不正,被喷。 网上经常看到这样的一幕:一个老太太在路灯下啃着馒头卖菜,旁边广场上是穿着华丽跳舞的老太太。 网友说,这个世界太不公平了,都是同样的年龄,为什么差别这么大。取消那些跳舞老太太的退休金,让她们也去卖菜。 ...
继续阅读 »

有一个想法,憋了好久了,迟迟没敢说,怕三观正不正,被喷。


网上经常看到这样的一幕:一个老太太在路灯下啃着馒头卖菜,旁边广场上是穿着华丽跳舞的老太太。


WechatIMG5.jpeg


网友说,这个世界太不公平了,都是同样的年龄,为什么差别这么大。取消那些跳舞老太太的退休金,让她们也去卖菜。


我看完评论就在想:都去卖菜,就是公平吗?或者,都去跳广场舞才是公平?


到底什么是公平?


其实大众很难说清楚什么是公平,但是经常会提“这不公平!”。


一个出身贫困的农村孩子,经过千辛万苦,终于考上了大学。他毕业后,起早贪黑努力工作。终于,他在城里买下了两套房子,自住一套,出租一套。


看到上面的例子,大家都会说,哎呀,这叫天道酬勤!老天不会辜负努力的孩子。正是他通过自己十几年的努力,才有了今天的成绩。相比于他早就辍学的同村伙伴,相比于那些逃课打游戏的大学同学,这一切对于他来说,是公平的!


哎,再来一个例子。有一个富二代,他从小就逃课、打架,高考也没考好,花钱读了个海外大学,大学也没学啥,就学会了一周换一个女朋友。他刚毕业,他父亲就给他一栋大楼,让他练习如何赚钱。


这个例子,公平吗?


想好了再回答,考验感性和理性的时候到了。


不着急回答。对于上面的例子,我想把时间线再拉长一些。


这位富二代的爷爷,也是出身农村。他老人家从小就父母双亡。一开始他跟着伯父生活,但是伯母经常虐待他。因此,他离家出走,到城里乞讨。后来,他被好心的包子铺老板收留。他在包子铺打工,因为能吃苦,干活勤快,又懂得感恩,所以深受老板和顾客的喜爱。凭借着一膀子力气,他在城里做到了成家立业娶媳妇,后来还有了下一代。这下一代出生便在城里,教育条件也好,从小又跟着父母做生意,见得多,识得也广。后来,下一代凭借着父母积攒的老客户,在事业上越做越大,最终形成了自己的商业帝国。再后来,就有了上面的那个富二代。


大家说,将时间线拉长之后,这三代人也是一个“天道酬勤”的故事吧?开头富二代爷爷的经历,可以对标大学生的一生。


我发现人类的社会和动物的族群,有一个很明显的区别,那就是物质和精神的继承。


Snip20230517_1.png


在一个狮群里,狮王是靠本领拼出来的。下一任狮王,是不是由它的儿子当,能否继续拥有这一方领土和交配权,得看小狮子能不能打败其他狮子,成为最强者。不止是狮子,猴子也是一样。猴群里猴王是最强壮、最聪明的猴子。要是老猴王不行了,新猴王会通过战斗取代它。之所以需要最强的猴子当猴王,那是因为它能够保护整个猴群。虽然,这个猴王不是无所不能。但在这群猴子里面,找不出来比它更合适的了。


动物界的这些名利、地位、经验,是没法传给下一代的。它们的群落会不定期重新洗牌。


但是我们人类社会却不一样。一个富豪,就算他儿子不聪明,甚至身体有残疾,一样有很多人像对待猴王一样仰视他,他一样能获得最优质的繁殖资源。


你说,人类的这种方式高级不高级。


从短期看,不高级。上面说的那种人,要是在动物界,早就被淘汰了。一头斑马,即便是脚部受了点伤,也基本就宣告死亡了。大自然就是要优胜劣汰。谁让这头斑马不注意,凭什么狮子单单就咬伤了你,而不是别人。就算运气不好,这也是一种劣势。动物界,就是以此来保证强大的遗传特征,流通在群体的基因库中。


但是从长期看,人类的这种方式却很高级。因为正是有了资源继承这种特权,才让类人一想到能为子孙后代留点东西、做点事情,就不怕苦不怕累,成为永动机。


我们人类为什么这么想?我们是韭菜成精了吗?


你可能不知道,你是被遗传基因控制的。


Snip20230517_2.png


你的身高、体重,哪里长手,哪里长耳朵,都是写在基因里的。你只是照着图纸在搭建而已。


你不要觉得你有自我。哥们,咱们不配!你知道吗?基因才有自我。


基因的想法不是让你活下去,而是让它自己活下去。而且,还要一代更比一代强。它活下去的方式,就是依靠你来进行繁殖和生育。你之所以怕死,其实是基因怕自己遗传不下去。有些动物,比如鲑鱼、蝴蝶等,它们繁殖完就死掉了。


人类的基因很高级,有了后代后不但不死,而且还让你把孩子养大,甚至还给孩子看孩子。幸好DNA里没法存货物,不然有人可能抱着金条出生。这不是因为有爱,这是因为基因的控制!


为什么动物就做不到这些?因为在自然界,资源是有限的,有时候自己和后代只能保留一个。基因选择了留它自己。


人类通过物质和财富的“遗传”,解决了这个问题。那你说,这种方式是不是非常高级。


也正是这种物质和精神可以继承,才让人类从动物界中脱颖而出,成为了地球的主人。


说这么多,还扯到了生物和伦理,好像有点跑题了。但这也从某一个方面佐证了一些道理。有些事,从局部来看很不公平。但是,当把时间线拉长再看,这又是合理的。


大自然怎么会过一天算一天呢?她是想永生的。


这时,当我们再面对一些局部不公平时,你不必太过于消沉。把时间拉长,你可以把自己作为一个起点。想想那些让你感到气愤的“持有特权者”,他们从几十年前,就已经开始像你现在一样努力了。


难道你想要用你的几年奋斗,去超越人家几十年甚至上百年的沉淀吗?从长远来看,恐怕这也不公平吧?


WechatIMG4.jpeg


一个指导大家考研的老师,他说她女儿可以不用考研。短期看,这好像这是个笑话。但是,他说,考研是为了更好地谋生。她的女儿可以不用为生计发愁,把精力投入到她喜欢做的事情。


“人人平等”最早源于宗教。他们说,不管你如何威风,最后到上帝那里都一样。而法律上的平等,是为了避免社会失去秩序。


世上没有绝对的公平。因为单就“公平”这个词的定义,就很难说清楚。


好了,就说这么多吧。


我是一个理工男,思考问题的方式可能有些偏激。文中提到了“奋斗”和“努力”(不知何时这两个词变味了),我不是想给大家灌鸡汤。理工科最讨厌鸡汤,一点逻辑都没有。我只是从理性的角度,给大家分享一种思路。


总之,到与不到的,还请大家多多包涵。



是的,没错,我就是掘金@TF男孩。文章写的比代码还好的程序员。



作者:TF男孩
来源:juejin.cn/post/7234078632653013048
收起阅读 »

程序员的坏习惯

前言 每位开发人员在自己的职业生涯、学习经历中,都会出一些坏习惯,本文将列举开发人员常犯的坏习惯。希望大家能够意识和改变这些坏习惯。 不遵循项目规范 每个公司都会定义一套代码规范、代码格式规范、提交规范等,但是有些开发人员就是不遵循相关的 规范,命名不规范、...
继续阅读 »

前言


每位开发人员在自己的职业生涯、学习经历中,都会出一些坏习惯,本文将列举开发人员常犯的坏习惯。希望大家能够意识和改变这些坏习惯。


图片.png


不遵循项目规范


每个公司都会定义一套代码规范、代码格式规范、提交规范等,但是有些开发人员就是不遵循相关的 规范,命名不规范、魔鬼数字、提交代码覆盖他人代码等问题经常发生,如果大家能够遵循相关规范,这些问题都可以避免。


用复杂SQL语句来解决问题


程序员在开发功能时,总想着是否能用一条SQL语句来完成这个功能,于是实现的SQL语句写的非常复杂,包含各种子查询嵌套,函数转换等。这样的SQL语句一旦出现了性能问题,很难进行相关优化。


缺少全局把控思维,只关注某一块业务


新增新功能只关注某一小块业务,不考虑系统整体的扩展性,其他模块已经有相关的实现了,却又重复实现,导致重复代码严重。修改功能不考虑对其他模块的影响。


函数复杂冗长,逻辑混乱


一个函数几百行,复杂函数不做拆分,导致代码变得越来月臃肿,最后谁也不敢动。函数还是要遵循设计模式的单一职责,一个函数只做一件事情。如果函数逻辑确实复杂,需要进行拆分,保证逻辑清晰。


缺乏主动思考,拿来主义


实现相关功能,先网上百度一下,拷贝相关的代码,能够运行成功认为万事大吉。到了生产却出现了各种各样的问题,因为网上的demo程序和实际项目的在场景使用上有区别,尤其是相关的参数配置,一定要弄清楚具体的含义,不同场景下,设置参数的值不同。


核心业务逻辑,缺少相关日志和注释


很多核心的业务逻辑实现,整个方法几乎没看到相关注释和日志打印,除了自己能看懂代码逻辑,其他人根本看不懂。一旦生产出了问题,找不到有效的日志输出,问题根本无法定位。


修改代码,缺少必要测试


很多人都会存在侥幸心里,认为只是改了一个变量或者只修改一行代码,不用自测了应该没有问题,殊不知就是因为改一行代码导致了严重的bug。所以修改代码一定要进行自测。


需求没理清,直接写代码


很多程序员在接到需求后,不怎么思考就开始写代码,写着写着发现自己的理解与实际的需求有偏差,造成无意义返工。所以需要多花些时间梳理需求,整理相关思路,能规避很多不合理的问题。


讨论问题,表达没有逻辑、没有重点


讨论问题不交代背景,上来就说自己的方案,别人听得云里雾里,让你从头描述你又讲不明。需要学会沟通和表达,才能进行有效的沟通和合作。


不能从错误中吸取教训


作为一位开发人员,你会犯很多错误,这不可避免也没什么大不了的。但如果你总是犯同样的错误,不能从中吸取教训,那态度就出现问题了。


总结


关于这些坏习惯,你是否中招了,大家应该尽早规避这些坏习惯,成为一名优秀的程序员。


作者:剑圣无痕
来源:juejin.cn/post/7136455796979662862
收起阅读 »

十分钟,让你学会Vue的这些巧妙冷技巧

web
前言 写了两年的Vue,期间学习到好几个提高开发效率和性能的技巧,现在把这些技巧用文章的形式总结下来。 1. 巧用$attrs和$listeners $attrs用于记录从父组件传入子组件的所有不被props捕获以及不是class与style的参数,而$lis...
继续阅读 »

前言


写了两年的Vue,期间学习到好几个提高开发效率和性能的技巧,现在把这些技巧用文章的形式总结下来。


1. 巧用$attrs$listeners


$attrs用于记录从父组件传入子组件的所有不被props捕获以及不是classstyle的参数,而$listeners用于记录从父组件传入的所有不含.native修饰器的事件。那下面的代码作例子:


Vue.component('child', {
props: ['title'],
template: '<h3>{{ title }}</h3>'
})

new Vue({
data:{a:1,title:'title'},
methods:{
handleClick(){
// ...
},
handleChange(){
// ...
}
},
template:'
<child class="child-width" :a="a" b="1" :title="title" @click.native="handleClick" @change="handleChange">'
,

})

则在<child/>在中



  • attrs的值为{a:1,b:"1"}

  • listeners的值为{change: handleChange}


通常我们可以用$attrs$listeners作组件通信,在二次封装组件中使用时比较高效,如:


Vue.component("custom-dialog", {
// 通过v-bind="$attrs"和v-on="$listeners"把父组件传入的参数和事件都注入到el-dialog实例上
template: '<el-dialog v-bind="$attrs" v-on="$listeners"></el-dialog>',
});

new Vue({
data: { visible: false },
// 这样子就可以像在el-dialog一样用visible控制custom-dialog的显示和消失
template: '<custom-dialog :visible.sync="visible">',
});

再举个例子:


Vue.component("custom-select", {
template: `<el-select v-bind="$attrs" v-on="$listeners">
<el-option value="选项1" label="黄金糕"/>
<el-option value="选项2" label="双皮奶"/>
</el-select>`
,
});

new Vue({
data: { value: "" },
// v-model在这里其实是v-bind:value和v-on:change的组合,
// 在custom-select里,通过v-bind="$attrs" v-on="$listeners"的注入,
// 把父组件上的value值双向绑定到custom-select组件里的el-select上,相当于<el-select v-model="value">
// 与此同时,在custom-select注入的size变量也会通过v-bind="$attrs"注入到el-select上,从而控制el-select的大小
template: '<custom-select v-model="value" size="small">',
});

2. 巧用$props


$porps用于记录从父组件传入子组件的所有被props捕获以及不是classstyle的参数。如


Vue.component('child', {
props: ['title'],
template: '<h3>{{ title }}</h3>'
})

new Vue({
data:{a:1,title:'title'},
methods:{
handleClick(){
// ...
},
handleChange(){
// ...
}
},
template:'
<child class="child-width" :a="a" b="1" :title="title">'
,

})

则在<child/>在中,$props的值为{title:'title'}$props可以用于自组件和孙组件定义的props都相同的情况,如:


Vue.component('grand-child', {
props: ['a','b'],
template: '<h3>{{ a + b}}</h3>'
})

// child和grand-child都需要用到来自父组件的a与b的值时,
// 在child中可以通过v-bind="$props"迅速把a与b注入到grand-child里
Vue.component('child', {
props: ['a','b'],
template: `
<div>
{{a}}加{{b}}的和是:
<grand-child v-bind="$props"/>
</div>
`

})

new Vue({
template:'
<child class="child-width" :a="1" :b="2">'
,
})

举一个我在开发中常用到$props的例子:


element-uiel-tabstab-click事件中,其回调参数是被选中的标签 tab 实例(也就是el-tab-pane实例),此时我想获取el-tab-pane实例上的属性如name值,可以有下面这种写法:


<template>
<div>
<el-tabs v-model="activeTab" @tab-click="getTabName">
<el-tab-pane name="123" label="123">123</el-tab-pane>
<el-tab-pane name="456" label="456">456</el-tab-pane>
</el-tabs>
</div>
</template>

<script>
export default {
name: "App",
data() {
return {
activeTab: "123",
};
},
methods: {
getTabName(tab) {
console.log(tab.$props.name);
},
},
};
</script>

此时效果如下所示,可看到控制台打印出我们点击的tab上的name属性值:


tab-prop.gif


示例代码放在sandbox里。


3. 妙用函数式组件


函数式组件相比于一般的vue组件而言,最大的区别是非响应式的。它不会监听任何数据,也没有实例(因此没有状态,意味着不存在诸如createdmounted的生命周期)。好处是因只是函数,故渲染开销也低很多。


把开头的例子改成函数式组件,代码如下:


<script>
export default {
name: "anchor-header",
functional: true, // 以functional:true声明该组件为函数式组件
props: {
level: Number,
name: String,
content: String,
},
// 对于函数式组件,render函数会额外传入一个context参数用来表示上下文,即替代this。函数式组件没有实例,故不存在this
render: function (createElement, context) {
const anchor = {
props: {
content: String,
name: String,
},
template: '<a :id="name" :href="`#${name}`"> {{content}}</a>',
};
const anchorEl = createElement(anchor, {
props: {
content: context.props.content, //通过context.props调用props传入的变量
name: context.props.name,
},
});
const el = createElement(`h${context.props.level}`, [anchorEl]);
return el;
},
};
</script>

4. 妙用 Vue.config.devtools


其实我们在生产环境下也可以调用vue-devtools去进行调试,只要更改Vue.config.devtools配置既可,如下所示:


// 务必在加载 Vue 之后,立即同步设置以下内容
// 该配置项在开发版本默认为 `true`,生产版本默认为 `false`
Vue.config.devtools = true;

我们可以通过检测cookie里的用户角色信息去决定是否开启该配置项,从而提高线上 bug 查找的便利性。


5. 妙用 methods


Vue中的method可以赋值为高阶函数返回的结果,例如:


<script>
import { debounce } from "lodash";

export default {
methods: {
search: debounce(async function (keyword) {
// ... 请求逻辑
}, 500),
},
};
</script>

上面的search函数赋值为debounce返回的结果, 也就是具有防抖功能的请求函数。这种方式可以避免我们在组件里要自己写一遍防抖逻辑。


这里有个例子sandbox,大家可以点进去看看经过高阶函数处理的method与原始method的效果区别,如下所示:


high-class-method.gif


除此之外,method还可以定义为生成器,如果我们有个函数需要执行时很强调顺序,而且需要在data里定义变量来记录上一次的状态,则可以考虑用生成器。


例如有个很常见的场景:微信的视频通话在接通的时候会显示计时器来记录通话时间,这个通话时间需要每秒更新一次,即获取通话时间的函数需要每秒执行一次,如果写成普通函数则需要在data里存放记录时间的变量。但如果用生成器则能很巧妙地解决,如下所示:


<template>
<div id="app">
<h3>{{ timeFormat }}</h3>
</div>
</template>

<script>
export default {
name: "App",
data() {
return {
// 用于显示时间的变量,是一个HH:MM:SS时间格式的字符串
timeFormat: "",
};
},
methods: {
genTime: function* () {
// 声明存储时、分、秒的变量
let hour = 0;
let minute = 0;
let second = 0;
while (true) {
// 递增秒
second += 1;
// 如果秒到60了,则分加1,秒清零
if (second === 60) {
second = 0;
minute += 1;
}
// 如果分到60了,则时加1,分清零
if (minute === 60) {
minute = 0;
hour += 1;
}
// 最后返回最新的时间字符串
yield `${hour}:${minute}:${second}`;
}
},
},
created() {
// 通过生成器生成迭代器
let gen = this.genTime();
// 设置计时器定时从迭代器获取最新的时间字符串
const timer = setInterval(() => {
this.timeFormat = gen.next().value;
}, 1000);
// 在组件销毁的时候清空定时器和迭代器以免发生内存泄漏
this.$once("hook:beforeDestroy", () => {
clearInterval(timer);
gen = null;
});
},
};
</script>

页面效果如下所示:


gen-method.gif


代码地址:code sandbox


但需要注意的是:method 不能是箭头函数



注意,不应该使用箭头函数来定义 method 函数 (例如 plus: () => this.a++)。理由是箭头函数绑定了父级作用域的上下文,所以 this 将不会按照期望指向 Vue 实例,this.a 将是 undefined



6. 妙用 watch 的数组格式


很多开发者会在watch中某一个变量的handler里调用多个操作,如下所示:


<script>
export default {
data() {
return {
value: "",
};
},
methods: {
fn1() {},
fn2() {},
},
watch: {
value: {
handler() {
fn1();
fn2();
},
immediate: true,
deep: true,
},
},
};
</script>

虽然fn1fn2都需要在value变动的时候调用,但两者的调用时机可能不同。fn1可能仅需要在deepfalse的配置下调用既可。因此,Vuewatch的值添加了Array类型来针对上面所说的情况,如果用watchArray的写法处理可以写成下面这种形式:


<script>
watch:{
'value':[
{
handler:function(){
fn1()
},
immediate:true
},
{
handler:function(){
fn2()
},
immediate:true,
deep:true
}
]
}
</script>

7. 妙用$options


$options是一个记录当前Vue组件的初始化属性选项。通常开发中,我们想把data里的某个值重置为初始化时候的值,可以像下面这么写:


this.value = this.$options.data().value;

这样子就可以在初始值由于需求需要更改时,只在data中更改即可。


这里再举一个场景:一个el-dialog中有一个el-form,我们要求每次打开el-dialog时都要重置el-form里的数据,则可以这么写:


<template>
<div>
<el-button @click="visible=!visible">打开弹窗</el-button>
<el-dialog @open="initForm" title="个人资料" :visible.sync="visible">
<el-form>
<el-form-item label="名称">
<el-input v-model="form.name" />
</el-form-item>
<el-form-item label="性别">
<el-radio-group v-model="form.gender">
<el-radio label="male"></el-radio>
<el-radio label="female"></el-radio>
</el-radio-group>
</el-form-item>
</el-form>
</el-dialog>
</div>
</template>

<script>
export default {
name: "App",
data() {
return {
visible: false,
form: {
gender: "male",
name: "wayne",
},
};
},
methods: {
initForm() {
this.form = this.$options.data().form;
},
},
};
</script>

每次el-dialog打开之前都会调用其@open中的方法initForm,从而重置form值到初始值。如下效果所示:


option_data.gif


以上代码放在sanbox


如果要重置data里的所有值,可以像下面这么写:


Object.assign(this.$data, this.$options.data());
// 注意千万不要写成下面的样子,这样子就更改this.$data的指向。使得其指向另外的与组件脱离的状态
this.$data = this.$options.data();

8. 妙用 v-pre,v-once


v-pre


v-pre用于跳过被标记的元素以及其子元素的编译过程,如果一个元素自身及其自元素非常打,而又不带任何与Vue相关的响应式逻辑,那么可以用v-pre标记。标记后效果如下:


image.png


v-once



只渲染元素和组件一次。随后的重新渲染,元素/组件及其所有的子节点将被视为静态内容并跳过。这可以用于优化更新性能。



对于部分在首次渲染后就不会再有响应式变化的元素,可以用v-once属性去标记,如下:


<el-select>
<el-option
v-for="item in options"
v-once
:key="item.value"
:label="item.label"
:value="item.value"
>
{{i}}</el-option
>
</el-select>

如果上述例子中的变量options很大且不会再有响应式变化,那么如例子中用上v-once对性能有提升。


9. 妙用 hook 事件


如果想监听子组件的生命周期时,可以像下面例子中这么做:


<template>
<child @hook:mounted="removeLoading" />
</template>

这样的写法可以用于处理加载第三方的初始化过程稍漫长的子组件时,我们可以加loading动画,等到子组件加载完毕,到了mounted生命周期时,把loading动画移除。


初次之外hook还有一个常用的写法,在一个需要轮询更新数据的组件上,我们通常在created里开启定时器,然后在beforeDestroy上清除定时器。而通过hook,开启和销毁定时器的逻辑我们都可以在created里实现:


<script>
export default {
created() {
const timer = setInterval(() => {
// 更新逻辑
}, 1000);
// 通过$once和hook监听实例自身的beforeDestroy,触发该生命周期时清除定时器
this.$once("hook:beforeDestroy", () => {
clearInterval(timer);
});
},
};
</script>

像上面这种写法就保证了逻辑的统一,遵循了单一职责原则。


作者:村上小树
来源:juejin.cn/post/7103066172530098206
收起阅读 »

学了设计模式,我重构了原来写的垃圾代码

前言 最近笔者学习了一些设计模式,都记录在我的专栏 前端要掌握的设计模式 中,感兴趣的掘友可以移步看看。本着 学东西不能停留在用眼睛看,要动手实践 的理念,笔者今天带来的是一篇关于代码逻辑重构的文章,将学到的东西充分运用到实际的项目中。 重构代码的背景 要重构...
继续阅读 »

前言


最近笔者学习了一些设计模式,都记录在我的专栏 前端要掌握的设计模式 中,感兴趣的掘友可以移步看看。本着 学东西不能停留在用眼睛看,要动手实践 的理念,笔者今天带来的是一篇关于代码逻辑重构的文章,将学到的东西充分运用到实际的项目中。


重构代码的背景


要重构的代码是之前笔者的一篇文章——我是怎么开发一个Babel插件来实现项目需求的?,大概的逻辑就是实现 JS 代码的一些转换需求:



  1. 去掉箭头函数的第一个参数(如果是ctx(ctx, argu1) => {}转换为(argu1) => {}

  2. 函数调用加上this.: sss(ctx) 转换为 this.sss()

  3. ctx.get('one').$xxx() 转换为 this.$xxxOne()

  4. const crud = ctx.get('two'); crud.$xxx();转换为this.$xxxTwo()


  5. /**
    * 处理批量的按钮显示隐藏
    * ctx.setVisible('code1,code2,code3', true)
    * 转化为
    * this.$refs.code1.setVisible(true)
    * this.$refs.code2.setVisible(true)
    * this.$refs.code3.setVisible(true)
    */


  6. 函数调用把部分 API 第一参数为ctx的变为arguments

  7. 函数调用去掉第一个参数(如果是ctx

  8. 函数声明去掉第一个参数(如果是ctx

  9. 普通函数 转为 () => {}

  10. 标识符ctx 转为 this

  11. ctx.data 转为 this

  12. xp.message(options) 转换为 this.$message(options)

  13. const obj = { get() {} } 转化为 const obj = { get: () => {} }


具体的实现可参考之前的文章,本文主要分享一下重构的实现。


重构前


所有的逻辑全写在一个 JS 文件中:
image.png
还有一段逻辑很长:
image.png


为啥要重构?


虽然主体部分被我折叠起来了,依然可以看到上面截图的代码存在很多问题,而且主体内容只会比这更糟:



  1. 难以维护,虽然写了注释,但是让别人来改根本看不明白,改不动,甚至不想看

  2. 如果新增了转换需求,不得不来改上面的代码,违反开放封闭原则。因为你无法保证你改动的代码不会造成原有逻辑的 bug。

  3. 代码没有章法,乱的一批,里面还有一堆 if/elsetry/catch

  4. 如果某个转换逻辑,我不想启用,按照现有的只能把对应的代码注释,依然是具有破坏性的


基于以上的这些问题,我决定重构一下。


重构后


先来看下重构后的样子:
image.png
统一将代码放到一个新的文件夹code-transform下:



  • transfuncs文件夹用来放具体的转换逻辑

  • util.js中有几个工具函数

  • trans_config.js用于配置transfuncs中转换逻辑是否生效

  • index.js 导出访问者对象 visitor(可以理解为我们根据配置动态组装一个 visitor 出来)


transfuncs下面的文件格式


如下图所示,该文件夹下的每个 JS 文件都默认导出一个函数,是真正的转换逻辑。
image.png
文件名命名规则:js ast树中节点的type_执行转换的大概内容


其余三个文件内容概览


image.png
其中笔者主要说明一下index.js


import config from './trans_config'

const visitor = {}
/**
* 导出获取访问者对象的函数
*/

export function generateVisitorByConfig() {
if (Object.keys(visitor).length !== 0) {
return visitor
}
// 过滤掉 trans_config.js 中不启用的转换规则
const transKeys = Object.keys(config).filter(key => config[key])
// 导入 ./transfuncs 下的转换规则
const context = require.context('./transfuncs', false, /\.js$/)
const types = new Set()
// 统计我们定义的转换函数,是哪些 ast 节点执行转换逻辑
// 别忘了文件名命名规则:js ast树中节点的type_执行转换的大概内容
// 注意去重,因为我们可能在同一种节点类型,会执行多种转换规则。
// 比如 transfuncs 下有多个 CallExpression_ 开头的文件。
context.keys().forEach(path => {
const fileName = path.substring(path.lastIndexOf('/') + 1).replace('.js', '')
const type = fileName.split('_')[0]
types.add(type)
})

const arrTypes = [...types]
// 到此 arrTypes 可能是这样的:
// ['CallExpression', 'FunctionDeclaration', 'MemberExpression', ...]
// 接着遍历每种节点 type

arrTypes.forEach(type => {
const typeFuncs = context.keys()
// 在 transfuncs 文件夹下找出以 对应 type 开头
// 并且 trans_config 中启用了的的文件
.filter(path => path.includes(type) && transKeys.find(key => path.includes(key)))
// 得到文件导出的 function
.map(path => context(path).default)
// 如果 typeFuncs.length > 0,就给 visitor 设置该节点执行的转换逻辑
typeFuncs.length > 0 && (visitor[type] = path => {
typeFuncs.forEach(func => func(path, attribute))
})
})
// 导出 visitor
return visitor
}

最后调用:


import { generateVisitorByConfig } from '../code-transform'

const transed = babel.transform(code, {
presets: ['es2016'],
sourceType: 'module',
plugins: [
{
visitor: generateVisitorByConfig()
}
]
}).code

有些掘友可能对babel的代码转换能力、babel插件不是很了解, 看完可能还处于懵的状态,对此建议各位先去我的上一篇我是怎么开发一个Babel插件来实现项目需求的? 大致看下逻辑,或者阅读一下Babel插件手册,看完之后自然就通了。


总结


到此呢,该部分的代码重构就完成了,能够明显看出:



  1. 文件变多了,但是每个文件做的事情更专一了

  2. 可以很轻松启用、禁用转换规则了,trans_config中配置一下即可,再也不用注释代码了

  3. 可以很轻松的新增转换逻辑,你只需要关注你在哪个节点处理你的逻辑,注意下文件名即可,你甚至不需要关心引入文件,因为会自动引入。

  4. 更容易维护了,就算离职了你的同事也能改的动你的代码,不会骂人了

  5. 逻辑更清晰了

  6. 对个人来说,代码组织能力提升了😃


👊🏼感谢观看!如果对你有帮助,别忘了 点赞 ➕ 评论 + 收藏 哦!


作者:Lvzl
来源:juejin.cn/post/7224205585125556284
收起阅读 »

4年前端的迷茫与挣扎

我是一名前端开发工程师。 2022年这是我工作的第4个年头,2023年将是第5个年头,和朋友聊到这里总会难免地透露出些许错愕,不知不觉已经工作这么久了,久到已经成为了刚工作时我们导师的工龄了。 以前的我会认为,工作4年后的我一定在前端开发领域稍有建树,而此时的...
继续阅读 »

我是一名前端开发工程师。


2022年这是我工作的第4个年头,2023年将是第5个年头,和朋友聊到这里总会难免地透露出些许错愕,不知不觉已经工作这么久了,久到已经成为了刚工作时我们导师的工龄了。


以前的我会认为,工作4年后的我一定在前端开发领域稍有建树,而此时的我猛地发觉了自己的普通。看着同龄人中,有的持续进行写作,公众号积累了不少粉丝,有的有明确的技术方向,不断深耕。而我望向远方的路,却仍是迷茫。有人们总说要向前看,但我真的不知道哪里是前。


人生的意义是什么?


2022年知乎给我推送最多的消息,都与『人生的意义是什么』这个问题相关。我本以为我是有了答案的,我认为人生的意义是去追逐永恒。


因为苏格拉底说人会追求自身所缺乏的东西,而人最缺乏的东西是生命,一个人的生命在宇宙的尺度是如此的短暂。我用这个来解释人为什么会结婚,生育,抚养下一代,因为孩子延续了父母两个个体生命。而人类整个群体因此突破了个体的局限,我们的文明从诞生跨越至今。


image.png


但我逐渐意识到,结婚,生育,抚养下一代并不是我想度过的人生,我甚至内心深处可能自己都并不是很想活,但确实可以肯定的是我也是不敢死。所以我努力说服自己去寻找其他追求永恒的方式,比如像那些哲学家流传下珍贵的思想,那些作家书写下传世名作,寻找一些属于我的东西能够超越我生命的尺度。


我想有人读到这里可能会拍桌而起,并愤怒地跟我说,去他妈的,人生什么意义都没有。我也认可,但我更喜欢为人生认为地去赋予一些意义,免得像个无头的苍蝇。所以我更喜欢这样理解,人生的实在并无意义,所以你拥有无限的自由去决定该如何着手你的人生。


因为我只会写代码,所以开始将我的代码视为自己生命的延伸,希望就算从这个世界离去,也能在将自己存在过的痕迹延续的久一点。


在开源上的尝试



2022年 Commit 肝了1.1k次,PR了74次,创建了98个 Issue,多数 Issue 写的技术文章,随笔或翻译。今年有一阵子是真的比较肝,早上上班前,晚上下班后,甚至2022清明的3天假期也都用来写项目。


image.png


image.png


思考


最开始在 Github 上写的项目都是基于工作中发现的一些问题,例如 Taro2 自动化升级 Taro3 项目的工具,在百度小程序开发者工具中注入 Chrome 浏览器插件。


值得一提的是,我工作中负责的一个产品,它使用 Taro 开发小程序,使用 Next.js 开发 SSR,同一个项目需要维护两个代码库。就开始思考是否能够让 Taro H5 直接支持 SSR,以此将这两个代码库合并,不用每次需求迭代我需要前后开发两个项目。有了大概的设想,就在清明放假期间着手去做了这件事,搞出了一个最小可用项目。最终业余时间不断完善它,最后在 leader 的帮助下,协调出时间将两个代码库合并为一个!


经历了这些之后,现在我对我个人参与开源的定位如下所示,这同样也写在我 Github 个人主页的 README 中。其中我觉得最重要的是能够在平时的工作中发现问题,并能够将其分类或定义为一个别人也有可能会遇到的一个一般性问题,这甚至比解决方案更加重要。



  • 👋 不断学习并挑战自己。

  • 🌱 正在学习 Golang & Rust。

  • 🤔 如何让前端开发更加愉悦?

    • 让重复的工作自动化。

    • 定义一般问题并提供解决方案。

    • 减少需做决定的数量。

    • 工具应当稳定、高效且灵活。



  • 😕 10月不适合写代码。

  • 🤪 间歇性开发工具,持续性制造垃圾。


从创造产品角度讲,Tim Qian 写的一篇文章令我收益颇多,让我的思维产生从参与开源社区是为了玩技术,到玩技术是为了让自己的点子快速实现的转变。


另外在我看了很多顶级开源项目之后,发觉这些伟大的项目的诞生不仅是为了解决某个问题,其中还蕴含着不同的人对于问题的不同划分和定义,最终表现出不同的解决方案,通过这些痕迹你甚至能看出一些作者对于这个世界的认识和他独特的价值观。


成果


让我觉得开源做的算是有些成果时,是发觉我有免费使用 Github Copilot 资格的时候,应该是因为被邀请进了 Taro 仓库成员的缘故,被认作流行开源项目的维护者。在这之前的情绪一直比较低沉,因为确实没得到多少 Star,但最终与自己和解了,虽然没有做出令人印象深刻的项目,但至少肝过。


image.png


接下的目标


现在得到最多 Star 的是 Taro SSR 插件,现在是 189 个 Star,也迁移到了 Taro 官方库中维护,期望明年能够有一个超过 512 个 Star 的项目。


至于为什么是 512 个,这于 Github 的成就系统有关。


image.png


工作上变动


换了公司


2022年真的是互联网寒冬,之前的公司开始裁员,其中一位应届生被裁了,整个楼都是他的哀嚎声,对我来说还挺震撼的。后来我就跳槽了,并不是被裁了,而是在整体裁员的压抑的氛围下,私下面试的几家公司以防止被裁。其中的大多数都发了 offer,但确实其中有一家给的有点超过我的预期,就在各种纠结之下直接跳槽了。


这次跳槽经历感觉对面试最有帮助的是《labuladong 的算法小抄》的这本书,我写算法题的能力很差,但这本书就用着一种应试教育的方法,让你短时间能速成面试算法做题家。因为种种原因,它的豆瓣评分很低,但他对我来说确实是对症下药了。


image.png


痛苦的 Landing


在新公司最终顺利转正了,但对我个人而言是真的不顺利。


一方面是新的工作是做内部机审业务的B端前端,业务面向于技术研发逻辑极为复杂,花费几个月的时间仍然有非常多不了解的东西,且你不知道该从业务的何处下手,才能让你对业务能够更加深入。


另一方面,由于对整体业务的不熟悉,很多事情是驱动不了的,比如团队中要搞 Web IDE 这件事,但我对于现有业务有哪些,哪些有 Web IDE 的诉求,具体的诉求是什么这些事情,种种问题导致难以下手。明显的感觉就是,与在老东家相比,给你的事情你没法做的很好。


回老家?


因为新工作的压抑,导致一度想回老家找个轻松点的活做。但令打工人悲伤的事情来了,回老家的结果很有可能是,薪资缩水一半,可能还得加班。拿着二线城市的薪资,加着一线城市的班,何必呢,遂打消了这个想法。


选择真的很重要,做着差不多的工作,选择在不同的城市薪资就有如此大的差别,就更别说更大事情上面的选择了。


继续挣扎


由于转正了,所以就沉下心来在新的环境中继续挣扎,不断调整自己。新的一年里,会不断去反思哪些方面是自己能够做的,然后做的足够更好,希望能在这段新的工作中成就我们的业务,也能成就我自己。


最后


再见2022,你好2023。


image.png


作者:SyMind
来源:juejin.cn/post/7190433155399516215
收起阅读 »

一点点Vue性能优化方案分享

web
我们在开发Vue项目时候都知道,在vue开发中某些问题如果前期忽略掉,当时不会出现明显的效果,但是越向后开发越难做,而且项目做久了就会出现问题,这就是所说的蝴蝶效应,这样后期的维护成本会非常高,并且项目上线后还会影响用户体验,也会出现加载慢等一系列的性能问题,...
继续阅读 »

我们在开发Vue项目时候都知道,在vue开发中某些问题如果前期忽略掉,当时不会出现明显的效果,但是越向后开发越难做,而且项目做久了就会出现问题,这就是所说的蝴蝶效应,这样后期的维护成本会非常高,并且项目上线后还会影响用户体验,也会出现加载慢等一系列的性能问题,下面举一个简单的例子。



举个简单的例子



如果加载项目的时候加载一张图片需要0.1s,其实算不了什么可以忽略不计,但是如果我有20张图片,这就是2s的时间, 2s的时间不算长一下就过去了,但是这仅仅的只是加载了图片,还有我们的js,css都需要加载,那就需要更长的时间,可能是5s,6s...,比如加载时间是5s,用户可能等都不会等,直接关闭我们的网站,最后导致我们网站流量很少,流量少就没人用,没人用就没有钱,没有钱就涨不了工资,涨不了工资最后就是跑路了😂。通过上面的例子可以看出性能问题是多么的重要甚至关系到了我们薪资😂,那如何避免这些问题呢?废话不多说,下面分享一下自己在写项目的时用到的一些优化方案以及注意事项。



1.不要将所有的数据都放在data中



可以将一些不被视图渲染的数据声明到实例外部然后在内部引用引用,因为Vue2初始化数据的时候会将data中的所有属性遍历通过Object.definePrototype重新定义所有属性;Vue3是通过Proxy去对数据包装,内部也会涉及到递归遍历,在属性比较多的情况下很耗费性能



<template>
<button @click="updateValue">{{msg}}</button>
</template>

<script>
let keys=true;
export default {
name:'Vueinput',
data(){
return {
msg:'true'
}
},
created(){
this.text = 'text'
},
methods:{
updateValue(){
keys = !keys
this.msg = keys?'true':'false'
}
}

}
</script>

2.watch 尽量不要使用deep:true深层遍历



因为watch不存在缓存,是指定监听对象,如果deep:true,并且监听对象类型情况下,会递归处理收集依赖,最后触发更新回调



3. vue 在 v-for 时给每项元素绑定事件需要用事件代理



vue源码中是通过addEventLisener去给dom绑定事件的,比如我们使用v-for需要渲染100条数据并且并为每个节点添加点击事件,如果每个都绑定事件那就存在很多的addEventLisener,这里不用说性能上肯定不好,那我们就需要使用事件代理处理这个问题



<template>
<ul @click="EventAgent">
<li v-for="(item) in mArr" :key="item.id" :data-set="item">{{item.day}}</li>
</ul>
</template>

<script>
let keys=true;
export default {
name:'Vueinput',
data(){
return {
mArr:[{
day:1,
id:'xx1'
},{
day:2,
id:'xx2'
},{
day:2,
id:'xx2'
},
...
]
}
},
methods:{
EventAgent(e){
// 注意这里 在项目中千万不要写的这么简单,我只是为了方便理解才这么写的
console.log(e.target.getAttribute('data-set'))
}
}

}
</script>

4. v-for尽量不要与v-if一同使用



vue的编译过程是template->vnode,看下面的例子



// 假设data中存在一个arr数组
<div id="container">
<div v-for="(item,index) in arr" v-if="arr.length" key="item.id">{{item}}</div>
</div>


上面的例子有可能大家经常这么做,其实这么做也能达到效果但是在性能上面不是很好,因为Ast在转化为render函数的时候会将每个遍历生成的对象都会加入if判断,最后在渲染的时候每次都每个遍历对象都会判断一次需要不需要渲染,这样就很浪费性能,为了避免这个问题我们把代码稍微改一下



<div id="container" v-if="arr.length"> 
<div v-for="(item,index) in arr" >{{item}}</div>
</div>


这样就只判断一次就能达到渲染效果了,是不是更好一些那



5. v-for的key进行不要以遍历索引作为key


<template>
<ul>
<li v-for="(item,index) in mArr" :key="item.id
<input type="checkbox" :value="item.is" />
</li>
<button @click="remove">
移除
</button>
</ul>
</template>

<script>
let keys=true;
export default {
name:'Vueinput',
data(){
return {
mArr:[{is:false,id:1},{is:false,id:2}
]
}
},
methods:{
remove(e){
console.log('asd')
this.mArr.shift()
}
}

}
</script>


  • 默认是都没有选中,当我们在页面中选中第一个


image.png



  • 点击下面的移除按钮,再看效果


image.png



  • 调整一下代码


<template>
<ul>
<li v-for="(item,index) in mArr" :key="index">
<input type="checkbox" :value="item.is" />
</li>
<button @click="remove">
移除
</button>
</ul>
</template>

<script>
let keys=true;
export default {
name:'Vueinput',
data(){
return {
mArr:[{is:false,id:1},{is:false,id:2}
]
}
},
methods:{
remove(e){
console.log('asd')
this.mArr.shift()
}
}

}
</script>


还是选中状态,就很神奇,解释一下为什么这么神奇,因为我们选中的是0索引,然后点击移除后索引为1的就变为0,Vue的更新策略是复用dom,也就是说我索引为1的dom是用的之前索引为0的dom并没有更改,当然没有key的情况也是如此,所以key值必须为唯一标识才会做更改



6. SPA 页面采用keep-alive缓存组件


<template>
<div>
<keep-alive>
<router-view></router-view>
</keep-alive>
</div>
</template>


使用了keep-alive之后我们页面不会卸载而是会缓存起来,keep-alive底层使用的LRU算法(淘汰缓存策略),当我们从其他页面回到初始页面的时候不会重新加载而是从缓存里获取,这样既减少Http请求也不会消耗过多的加载时间



7. 避免使用v-html




  1. 可能会导致xss攻击

  2. v-html更新的是元素的 innerHTML 。内容按普通 HTML 插入, 不会作为 Vue 模板进行编译 。



8. 提取公共代码,提取组件的 CSS



将组件中公共的方法和css样式分别提取到各自的公共模块下,当我们需要使用的时候在组件中使用就可以,大大减少了代码量



9. 首页白屏-loading



当我们第一次进入Vue项目的时候,会出现白屏的情况,为了避免这种尴尬的情况,我们在Vue编译之前使用加载动画避免



 
<!DOCTYPE html>
<html>
<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">
<link rel="icon" href="<%= BASE_URL %>favicon.ico">
<title>Vue</title>
<style>

</style>
</head>
<body>
<noscript>
<strong>We're sorry but production-line doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
</noscript>
<div id="app">
<div id="loading">
loading
</div>
</div>
<!-- built files will be auto injected -->
</body>
</html>



加loading只是解决白屏问题的一种,也可以缩短首屏加载时间,就需要在其他方面做优化,这个可以参考后面的案例



10. 拆分组件



主要目的就是提高复用性、增加代码的可维护性,减少不必要的渲染,对于如何写出高性能的组件这里就不展示了,自己可以多看看那些比较火的UI库(Element,Antd)的源码



11. 合理使用 v-if 当值为false时内部指令不会执行,具有阻断功能



如果操作不是很频繁可以使用v-if替代v-show,如果很频繁我们可以使用v-show来处理



key 保证唯一性 ( 默认 vue 会采用就地复用策略 )



上面的第五条已经讲过了,如果key不是唯一的情况下,视图可能不会更新。



12. 获取dom使用ref代替document.getElementsByClassName


mounted(){
console.log(document.getElementsByClassName(“app”))
console.log(this.$refs['app'])
}


document.getElementsByClassName获取dom节点的作用是一样的,但使用ref会减少获取dom节点的消耗



13. Object.freeze 冻结数据



首先说一下Object.freeze的作用




  • 不能添加新属性

  • 不能删除已有属性

  • 不能修改已有属性的值

  • 不能修改原型

  • 不能修改已有属性的可枚举性、可配置性、可写性


data(){
return:{
objs:{
name:'aaa'
}
}
},
mounted(){
this.objs = Object.freeze({name:'bbb'})
}


使用Object.freeze处理的data属性,不会被getter,setter,减少一部分消耗,但是Object.freeze也不能滥用,当我们需要一个非常长的字符串的时候推荐使用



14. 合理使用路由懒加载、异步组件



当打包构建应用时,JavaScript 包会变得非常大,影响页面加载。然后当路由被访问的时候才加载对应组件,这样就更加高效了



// 未使用懒加载的路由
import Vue from "vue";
import VueRouter from "vue-router";
import Home from "@/views/Home";
import About from "@/views/About";

Vue.use(VueRouter);

const routes = [
{
path: "/",
name: "Home",
component: Home,
},
{
path: "/about",
name: "About",
component: About
}
];
// 使用懒加载
import Vue from "vue";
import VueRouter from "vue-router";
Vue.use(VueRouter);
const Home = () => import('../views/Home')
const About = () => import('../views/About')

const routes = [
{
path: "/",
name: "Home",
component: Home,
},
{
path: "/about",
name: "About",
component: About
}
];

15. 数据持久化的问题



数据持久化比较常见的就是token了,作为用户的标识也作为登录的状态,我们需要将其储存到localStoragesessionStorage起来每次刷新页面Vuex从localStoragesessionStorage获取状态,不然每次刷新页面用户都需要重新登录,重新获取数据




  • localStorage 需要用户手动移除才能移除,不然永久存在。

  • sessionStorage 关闭浏览器窗口就失效。

  • cookie 关闭浏览器窗口就失效,每次请求Cookie都会被一同提交给服务器。


16. 防抖、节流



这两个算是老生常谈了,就不演示代码了,下面介绍一个场景,比如我们注册新用户的时候用户输入昵称需要校验昵称的合法性,考虑到用户输入的比较快或者修改频繁,这时候我们需要使用节流,间隔性的去校验,这样就减少了判断的次数达到优化的效果。后面我们还需要需要用户手动点击保存才能注册成功,为了避免用户频繁点击保存并发送请求,我们只监听用户最后一次的点击,这时候就用到了节流操作,这样就能达到优化效果



17. 重绘,回流



  • 触发重绘浏览器重新渲染部分或者全部文档的过程叫回流

    • 频繁操作元素的样式,对于静态页面,修改类名,样式

    • 使用能够触发重绘的属性(background,visibility,width,height,display等)



  • 触发回流浏览器回将新样式赋予给元素这个过程叫做重绘

    • 添加或者删除节点

    • 页面首页渲染

    • 浏览器的窗口发生变化

    • 内容变换





回流的性能消耗比重绘大,回流一定会触发重绘,重绘不一定会回流;回流会导致渲染树需要重新计算,开销比重绘大,所以我们要尽量避免回流的产生.



18. vue中的destroyed



组件销毁时候需要做的事情,比如当页面卸载的时候需要将页面中定时器清除,销毁绑定的监听事件



19. vue3中的异步组件



异步组件与下面的组件懒加载原理是类似,都是需要使用了再去加载



<template>
<logo-img />
<hello-world msg="Welcome to Your Vue.js App" />
</template>

<script setup>
import { defineAsyncComponent } from 'vue'
import LogoImg from './components/LogoImg.vue'

// 简单用法
const HelloWorld = defineAsyncComponent(() =>
import('./components/HelloWorld.vue'),
)
</script>


20. 组件懒加载


<template>
<div id="content">
<div>
<component v-bind:is='page'></component>
</div>

</div>
</template>

<script>

// ---* 1 使用标签属性is和import *---
const FirstComFirst = ()=>import("./FirstComFirst")
const FirstComSecond = ()=>import("./FirstComSecond")
const FirstComThird = ()=>import("./FirstComThird")

export default {
name: 'home',
components: {

},
data: function(){
return{
page: FirstComFirst
}
}

}
</script>


原理与路由懒加载一样的,只有需要的时候才会加载组件



21. 动态图片使用懒加载,静态图片使用精灵图



  • 动态图片参考图片懒加载插件 (github.com/hilongjw/vu…)

  • 静态图片,将多张图片放到一起,加载的时候节省时间


22. 第三方插件的按需引入



element-ui采用babel-plugin-component插件来实现按需导入



//安装插件
npm install babel-plugin-component -D
// 修改babel文件

module.exports = {
presets: [['@babel/preset-env', { modules: false }], '@vue/cli-plugin-babel/preset'],
plugins: [
'@babel/plugin-proposal-optional-chaining',
'lodash',
[
'component',
{
libraryName: 'element-ui',
styleLibraryName: 'theme-chalk'
},
'element-ui'
],
[
'component',
{
libraryName: '@xxxx',
camel2Dash: false
},
]
]
};

23. 第三方库CDN加速


//vue.config.js

let cdn = { css: [], js: [] };
//区分环境
const isDev = process.env.NODE_ENV === 'development';
let externals = {};
if (!isDev) {
externals = {
'vue': 'Vue',
'vue-router': 'VueRouter',
'ant-design-vue': 'antd',
}
cdn = {
css: [
'https://cdn.jsdelivr.net/npm/ant-design-vue@1.7.2/dist/antd.min.css', // 提前引入ant design vue样式
], // 放置css文件目录
js: [
'https://cdn.jsdelivr.net/npm/vue@2.6.11/dist/vue.min.js', // vuejs
'https://cdn.jsdelivr.net/npm/vue-router@3.2.0/dist/vue-router.min.js',
'https://cdn.jsdelivr.net/npm/ant-design-vue@1.7.2/dist/antd.min.js'
]
}
}



module.exports = {
configureWebpack: {
// 排除打包的某些选项
externals: externals
},
chainWebpack: config => {
// 注入cdn的变量到index.html中
config.plugin('html').tap((arg) => {
arg[0].cdn = cdn
return arg
})
},

}
//index.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">
<link rel="icon" href="<%= BASE_URL %>favicon.ico">
<title><%= htmlWebpackPlugin.options.title %></title>
<!-- 引入css-cdn的文件 -->
<% for(var css of htmlWebpackPlugin.options.cdn.css) { %>
<link rel="stylesheet" href="<%=css%>">
<% } %>
</head>
<body>
<noscript>
<strong>We're sorry but <%= htmlWebpackPlugin.options.title %> doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
</noscript>
<!-- 放置js-cdn文件 -->
<% for(var js of htmlWebpackPlugin.options.cdn.js) { %>
<script src="<%=js%>" ></script>
<% } %>
<div id="app"></div>
</body>
</html>

最后



以上的优化方案不紧在代码层面起到优化而且在性能上也起到了优化作用,文章内容主要是从Vue开发的角度和部分通过源码的角度去总结的,文章中如果存在错误的地方,或者你认为还有其他更好的方案,请大佬在评论区中指出,作者会及时更正,感谢!



作者:摸鱼的汤姆
来源:juejin.cn/post/7116163839644663822
收起阅读 »

10 个超棒的 JavaScript 简写技巧

web
今天我要分享的是10个超棒的JavaScript简写方法,可以加快开发速度,让你的开发工作事半功倍哦。 开始吧! 1.合并数组 普通写法: 我们通常使用Array中的concat()方法合并两个数组。用concat()方法来合并两个或多个数组,不会更改现有的数...
继续阅读 »

今天我要分享的是10个超棒的JavaScript简写方法,可以加快开发速度,让你的开发工作事半功倍哦。


开始吧!


1.合并数组


普通写法:


我们通常使用Array中的concat()方法合并两个数组。用concat()方法来合并两个或多个数组,不会更改现有的数组,而是返回一个新的数组。请看一个简单的例子:


let apples = ['🍎', '🍏'];
let fruits = ['🍉', '🍊', '🍇'].concat(apples);

console.log( fruits );
//=> ["🍉", "🍊", "🍇", "🍎", "🍏"]


简写写法:


我们可以通过使用ES6扩展运算符(...)来减少代码,如下所示:


let apples = ['🍎', '🍏'];
let fruits = ['🍉', '🍊', '🍇', ...apples]; // <-- here

console.log( fruits );
//=> ["🍉", "🍊", "🍇", "🍎", "🍏"]


2.合并数组(在开头位置)


普通写法:
假设我们想将apples数组中的所有项添加到Fruits数组的开头,而不是像上一个示例中那样放在末尾。我们可以使用Array.prototype.unshift()来做到这一点:


let apples = ['🍎', '🍏'];
let fruits = ['🥭', '🍌', '🍒'];

// Add all items from apples onto fruits at start
Array.prototype.unshift.apply(fruits, apples)

console.log( fruits );
//=> ["🍎", "🍏", "🥭", "🍌", "🍒"]


简写写法:


我们依然可以使用ES6扩展运算符(...)缩短这段长代码,如下所示:


let apples = ['🍎', '🍏'];
let fruits = [...apples, '🥭', '🍌', '🍒']; // <-- here

console.log( fruits );
//=> ["🍎", "🍏", "🥭", "🍌", "🍒"]


3.克隆数组


普通写法:


我们可以使用Array中的slice()方法轻松克隆数组,如下所示:


let fruits = ['🍉', '🍊', '🍇', '🍎'];
let cloneFruits = fruits.slice();

console.log( cloneFruits );
//=> ["🍉", "🍊", "🍇", "🍎"]


简写写法:


我们可以使用ES6扩展运算符(...)像这样克隆一个数组:


let fruits = ['🍉', '🍊', '🍇', '🍎'];
let cloneFruits = [...fruits]; // <-- here

console.log( cloneFruits );
//=> ["🍉", "🍊", "🍇", "🍎"]


4.解构赋值


普通写法:


在处理数组时,我们有时需要将数组“解包”成一堆变量,如下所示:


let apples = ['🍎', '🍏'];
let redApple = apples[0];
let greenApple = apples[1];

console.log( redApple ); //=> 🍎
console.log( greenApple ); //=> 🍏


简写写法:


我们可以通过解构赋值用一行代码实现相同的结果:


let apples = ['🍎', '🍏'];
let [redApple, greenApple] = apples; // <-- here

console.log( redApple ); //=> 🍎
console.log( greenApple ); //=> 🍏


5.模板字面量


普通写法:


通常,当我们必须向字符串添加表达式时,我们会这样做:


// Display name in between two strings
let name = 'Palash';
console.log('Hello, ' + name + '!');
//=> Hello, Palash!

// Add & Subtract two numbers
let num1 = 20;
let num2 = 10;
console.log('Sum = ' + (num1 + num2) + ' and Subtract = ' + (num1 - num2));
//=> Sum = 30 and Subtract = 10


简写写法:


通过模板字面量,我们可以使用反引号(``),这样我们就可以将表达式包装在${…}`中,然后嵌入到字符串,如下所示:


// Display name in between two strings
let name = 'Palash';
console.log(`Hello, ${name}!`); // <-- No need to use + var + anymore
//=> Hello, Palash!

// Add two numbers
let num1 = 20;
let num2 = 10;
console.log(`Sum = ${num1 + num2} and Subtract = ${num1 - num2}`);
//=> Sum = 30 and Subtract = 10


6.For循环


普通写法:


我们可以使用for循环像这样循环遍历一个数组:


let fruits = ['🍉', '🍊', '🍇', '🍎'];

// Loop through each fruit
for (let index = 0; index < fruits.length; index++) {
console.log( fruits[index] ); // <-- get the fruit at current index
}

//=> 🍉
//=> 🍊
//=> 🍇
//=> 🍎


简写写法:


我们可以使用for...of语句实现相同的结果,而代码要少得多,如下所示:


let fruits = ['🍉', '🍊', '🍇', '🍎'];

// Using for...of statement
for (let fruit of fruits) {
console.log( fruit );
}

//=> 🍉
//=> 🍊
//=> 🍇
//=> 🍎


7.箭头函数


普通写法:


要遍历数组,我们还可以使用Array中的forEach()方法。但是需要写很多代码,虽然比最常见的for循环要少,但仍然比for...of语句多一点:


let fruits = ['🍉', '🍊', '🍇', '🍎'];

// Using forEach method
fruits.forEach(function(fruit){
console.log( fruit );
});

//=> 🍉
//=> 🍊
//=> 🍇
//=> 🍎


简写写法:


但是使用箭头函数表达式,允许我们用一行编写完整的循环代码,如下所示:


let fruits = ['🍉', '🍊', '🍇', '🍎'];
fruits.forEach(fruit => console.log( fruit )); // <-- Magic ✨

//=> 🍉
//=> 🍊
//=> 🍇
//=> 🍎


8.在数组中查找对象


普通写法:


要通过其中一个属性从对象数组中查找对象的话,我们通常使用for循环:


let inventory = [  {name: 'Bananas', quantity: 5},  {name: 'Apples', quantity: 10},  {name: 'Grapes', quantity: 2}];

// Get the object with the name `Apples` inside the array
function getApples(arr, value) {
for (let index = 0; index < arr.length; index++) {

// Check the value of this object property `name` is same as 'Apples'
if (arr[index].name === 'Apples') { //=> 🍎

// A match was found, return this object
return arr[index];
}
}
}

let result = getApples(inventory);
console.log( result )
//=> { name: "Apples", quantity: 10 }


简写写法:


上面我们写了这么多代码来实现这个逻辑。但是使用Array中的find()方法和箭头函数=>,允许我们像这样一行搞定:


// Get the object with the name `Apples` inside the array
function getApples(arr, value) {
return arr.find(obj => obj.name === 'Apples'); // <-- here
}

let result = getApples(inventory);
console.log( result )
//=> { name: "Apples", quantity: 10 }


9.将字符串转换为整数


普通写法:


parseInt()函数用于解析字符串并返回整数:


let num = parseInt("10")

console.log( num ) //=> 10
console.log( typeof num ) //=> "number"


简写写法:


我们可以通过在字符串前添加+前缀来实现相同的结果,如下所示:


let num = +"10";

console.log( num ) //=> 10
console.log( typeof num ) //=> "number"
console.log( +"10" === 10 ) //=> true


10.短路求值


普通写法:


如果我们必须根据另一个值来设置一个值不是falsy值,一般会使用if-else语句,就像这样:


function getUserRole(role) {
let userRole;

// If role is not falsy value
// set `userRole` as passed `role` value
if (role) {
userRole = role;
} else {

// else set the `userRole` as USER
userRole = 'USER';
}

return userRole;
}

console.log( getUserRole() ) //=> "USER"
console.log( getUserRole('ADMIN') ) //=> "ADMIN"


简写写法:


但是使用短路求值(||),我们可以用一行代码执行此操作,如下所示:


function getUserRole(role) {
return role || 'USER'; // <-- here
}

console.log( getUserRole() ) //=> "USER"
console.log( getUserRole('ADMIN') ) //=> "ADMIN"


补充几点


箭头函数:


如果你不需要this上下文,则在使用箭头函数时代码还可以更短:


let fruits = ['🍉', '🍊', '🍇', '🍎'];
fruits.forEach(console.log);


在数组中查找对象:


你可以使用对象解构和箭头函数使代码更精简:


// Get the object with the name `Apples` inside the array
const getApples = array => array.find(({ name }) => name === "Apples");

let result = getApples(inventory);
console.log(result);
//=> { name: "Apples", quantity: 10 }


短路求值替代方案:


const getUserRole1 = (role = "USER") => role;
const getUserRole2 = role => role ?? "USER";
const getUserRole3 = role => role ? role : "USER";


编码习惯


最后我想说下编码习惯。代码规范比比皆是,但是很少有人严格遵守。究其原因,多是在代码规范制定之前,已经有自己的一套代码习惯,很难短时间改变自己的习惯。良好的编码习惯可以为后续的成长打好基础。下面,列举一下开发规范的几点好处,让大家明白代码规范的重要性:



  • 规范的代码可以促进团队合作。

  • 规范的代码可以减少 Bug 处理。

  • 规范的代码可以降低维护成本。

  • 规范的代码有助于代码审查。

  • 养成代码规范的习惯,有助于程序员自身的
    作者:AK_哒哒哒
    来源:juejin.cn/post/7105967944613494792
    成长。

收起阅读 »

吃亏就是吃亏,福在何处?

老话说得好:吃亏是福。 老话(我也不知道是谁)还举个了例子: 小亏和小赚都是公司的员工。有一个升职的名额,老板把名额给了小亏,原因是小亏喜欢吃亏。老板说:领导岗位,得有胸怀,能吃亏,老想赚别人便宜,这种人当不了领导。 作为论据,黑白对调也不会有违和感: ...
继续阅读 »

老话说得好:吃亏是福


老话(我也不知道是谁)还举个了例子:



小亏和小赚都是公司的员工。有一个升职的名额,老板把名额给了小亏,原因是小亏喜欢吃亏。老板说:领导岗位,得有胸怀,能吃亏,老想赚别人便宜,这种人当不了领导。



作为论据,黑白对调也不会有违和感:



老板选择了给小赚升职,他说:小亏吃亏的性格,会让公司的经营处于劣势,激烈的市场竞争需要野性,利润哪有嫌多的,还吃亏?因此,选择小赚更合适。



这种故事可以随意编,讲得通就可以。编故事的人,无非就是想让因果符合自己的观点


实际上,这类故事的逻辑漏洞很多。这都是辩论赛的把戏。


那么,我们扔掉故事,从现实进行分析。


生物具有学习和记忆的能力,他会根据当前反馈,决定下一次的行为


一个幼儿,触摸到尖锐的物体,他会感觉到疼痛,以后就会躲避;如果触摸到柔软的物体,他会感觉到舒适,以后就会戏耍。


今天你对这件事的反应,会决定明天别人怎么对待你


如果你网购买到次品,不退货,选择吃亏。那么之后,大数据会瞄准你。因为,你可以接受这类商品。你能接受就给你,他不能接受就不给他。这个没毛病。


如果公司里分奖品不够,你说我不要了,留给别人吧,选择吃亏。那么下次,还不够的时候,多半还是你没有。因为,大家都知道你不在乎奖品。其他人没有,闹着上吊呢?


我们平时从教科书里读到的结局和现实不一样,故事里都是:上次给的是假货,我没有计较,下次商家给了两份以示歉意;上次分东西我没要,我高风亮节,领导不但给补上了奖品,还送给了我一面锦旗。


然而事实,多数并非如此。因为,吃亏其实就是秀下限,是在告诉别人,你不抵触什么


管理者一直教我们吃亏是福,是品质,但是他们却不愿意吃亏。


就像我们一直很喜欢老实的人,但是自己不愿意当个老实的人。另外,老实人和好人(《做好人的意义》)也是有区别的。


因为老实意味着具备可靠的利用性,当然我自己不能被别人利用


大家都想要一群老黄牛,但是谁都不愿意当这头牛。


人的差异,在于资源的多少。吃亏让资源丢失,还秀下限,真不知福从哪里来。


因此,吃亏不是福。


上面所说的吃亏,不管是买油条给个断茬的,还是买包子给了个昨儿剩下的,这都是日常生活的小亏。


但是,还有一类智慧深远的人,他们很愿意吃“大亏”。比如赚到钱,他全分给弟兄们,自己一分不留。历史上很多这样的人,比如《后汉书·董卓列传》记载,董卓宰了自己家的耕牛招待陌生客人。耕牛在农耕社会对于农户来说,那可是极其重要啊。客人感动地稀里哗啦,吃完了又给他赶来上千头牛。


他可不是傻到家了。因为他也知道,今天这事,会决定明天别人怎么对你。今天让兄弟们感觉跟着自己有肉吃,兄弟们纷纷臣服,最后你成了大哥,坐拥天下。其实,这个小技巧老子(我说的是李耳)早就发现了,因此他《道德经》里说:因其不为大,故能成其大。翻译一下就是:因为他不拿大头,反而大头都成了他的。


但是,像端茶倒水、打印复印、搬家具啥的,你就别去吃亏,时间长了,别人可能把你当成保姆了。


但是,“吃亏是福”这句话,也能继续用。因为,多数场景下,我们还是可以将故事圆起来的。比如,你虽然丢了一百块钱,但是你同事崴着脚了。你会说,这叫:破财免灾,吃亏是福。

作者:TF男孩
来源:juejin.cn/post/7176405836787351613

收起阅读 »

菜鸡也会有春天吗III

转眼马上要毕业三年了,也是在小砖厂搬砖头的第三个年头,时间过得是真快,租的房子马上到期了,今天刚帮舍友搬完家,每次搬家都很emo。去年这个时候换房子正好遇到大学实验室同学东哥,我俩都是20年毕业的,东哥在毕业之后就一直在实验室老师的公司发展,去年老师有北京的项...
继续阅读 »

转眼马上要毕业三年了,也是在小砖厂搬砖头的第三个年头,时间过得是真快,租的房子马上到期了,今天刚帮舍友搬完家,每次搬家都很emo。去年这个时候换房子正好遇到大学实验室同学东哥,我俩都是20年毕业的,东哥在毕业之后就一直在实验室老师的公司发展,去年老师有北京的项目,东哥就机缘巧合下来到了北京。


有句话叫曾经沧海难为水,来了北京之后由于薪资待遇各方面东哥都不是很满意,于是就从老师那离职了,举目无亲之下就跟我凑合着租了一间主卧。仿佛又回到了在大学实验室的日子,当年我俩的位置也挨着。。。。


故事的开始总是那么和谐,后面因为一些工作节奏上的不同有些不兼容,好在时间还是过的很快,一年时间就这么匆匆过去,前篇有两篇记录了大学生活的文章,这次借着搬家机会回忆下自己短暂的北漂生涯。


学业末尾


image.png


这张照片应该是大四上学期结束拍的,那时候感觉自己身陷囹圄,对未来充满了恐惧和焦虑,实验室王老师可谓精通各种pua手段,全方位打击实验室同门出去找工作的念头。我们那个实验室本质上是给王老师写外包项目的组织,好听点叫实验室,其实就是个黑作坊。


那时候的心态是偷偷面试,怕老师知道,其实根本原因还是不自信,怕离开了实验室又没拿到offer,老师自己也有公司,虽然是个很小很小的外包公司,但是起码是个保底的底牌,实在不行,还能跟着老师干。但就是因为这个想法,导致两头都没搞好。


这里奉劝一下有跟我类似经历的同学们,当断则断,有些时候想要左右逢源结果可能是两头都拉裤兜子,虽然破釜沉舟这四个字听起来很冠冕堂皇,但关键时候还是要有魄力。


印象大四上学期去面试了蘑菇街,当时八股文一点没背,以为自己在实验室写了两句增删改查,打过ACM拿过铜牌,过个面试岂不轻松拿捏。结果问一个不会问一个不会,给面试官问笑了都。


从那之后从淘宝店打印了一本Java核心知识的pdf,每天复习,天天就是背八股,那会的内心是非常挣扎的,偷摸复习效率不高,而且身边的同门们都沉浸在老师画的大饼里无法自拔,包括东哥也是,那会感受到一种从未有过的无力感。


这时候想起了腿哥,我跟腿哥一起进入的实验室,我选的Java后端方向,他选的爬虫方向,由于对老师实验室没有啥实质性的价值,因为老师接不到一些爬虫的外包项目嘛,于是就把腿哥发配到边疆了,王老师有个师弟,在北京开了家小互联网公司,直接把腿哥保送到那里去了,毕业后一月8k。


说实话,给哥们羡慕坏了,在北京,还能学到本事,我们在实验室老师每月给600的补助,时不时还拖欠。


因为我学校是个末尾普本学校,身边人大部分选择了三个方向,考研、考公、考编或者考教师,我们班像我一样找研发工作的一个没有,弄得我想跟别人沟通的机会都没有。


很快秋招来了,金九银十,那段时间的节奏就是,1、找机会 2、做笔试 3、笔试挂或者没后续,四处碰壁的我在牛客发了一篇求offer的帖子。


image.png


看着这么多小伙伴也挣扎在水深火热中,让我稍微释怀了下。


至暗时刻


很快情况迎来了转机,大四上学期结束,疫情肆虐全国,学校通知暂缓返校,具体返校时间听通知。那机会这不就来了。不用在老师眼皮底下了,不用偷偷摸摸的了。


每天的生活节奏变成了吃饭、复习、面试,春招的发挥明显比秋招好了很多,很多公司的笔试都顺利进入面试了,但是面试却又过不去,要么倒在一面上,要么倒在二面上,虽然每次面试都有积累,但架不住一直面试失败,曾经一度怀疑自己是个傻逼,以至于有些公司发来面试邀请第一反应是肯定面不过去,那段时间绝对算是人生的至暗时刻。


虽然在拉钩上面过了几家小公司,但就觉得很不服气,感觉自己明明值得好公司,为什么总是事与愿违,拿到offer也不愿意签,都是一些小的不能再小的小作坊。


实验室的另一个同门史总,也想出来找找机会,那会我俩没事就qq语音聊面试的事,但是那年因为疫情的原因吧,机会的确不多,挣扎了差不多一个多月,史总选择了妥协,选择了跟着老师干。


这时候老师还给我打电话逼我就范,大体意思是今年行情太差了,你要自己出去找肯定完蛋,赶紧跟我干吧,我这名额也不多,你要答应晚了我就不要了!


当时恨不得骂他两句,我就不信靠我自己找不到工作了还!


曙光初现


某天下午,我在老家下地帮忙干农活呢(说起来很喜欢在田间农作,干活的时候面朝黄土背朝天,心无杂念,烦心事都抛在脑后内心很平静)。接到了现在这家厂子的面试,要说面试,三分实力七分运气,真的是这样,有时候跟面试官聊的很投机就过了,甚至都没有聊很多技术相关的东西,或者说还没到军火展示的环节就决定了给你过还是不过。


一面我印象做了一道简单的二分查找的算法,当时看过一段时间kotlin,IDEA上装了一些插件被面试官看到了,瞬间来了兴致,聊了很多语言方面的东西,随后就问了问一些常见八股就过了。


二面直接就聊规划聊发展,甚至聊最近看了什么书,当时脸不红心不跳的吹了波牛逼,什么数学之美、浪潮之巅、人月神话啥高端说什么,心里想着千万别问我有什么心得。


image.png
终于拿到了人生中第一个offer,一家做大数据的公司,薪资各方面也很满意,当时签完offer后很冷静,没有想象中的热泪盈眶之类的,有的只是感慨吧,感慨自己明明也不差,为什么求职之路如此多艰呢。


跟HR聊完具体入职时间,等待入职的日子算是继高考后最放松的日子了,终于不用背枯燥乏味的八股文了,终于可以安心打游戏了,终于不用被老师阴阳怪气了。。。。终于可以去梦寐以求的大城市了!


开始北漂


这三年有很多人问我当时为啥选择北京,其实与其说我选择了北京,不如说北京选择了我。


2020年5月25号,曲阜东站到北京南站,当时我那一节车厢总共没有几个人,大家因为疫情都不敢出门,颇有点明知山有虎,偏向虎山行的意思


到了北京南站,琳琅满目的地铁线标识,我记得特别清楚,当时拎着两个大行李箱,一时找不到去做地铁的地方,然后有个负责指挥交通的大妈,大家应该很常见,带着小红帽穿着黄马甲,配个小音箱,搁那嗷嗷的喊"快点快点,快关门了"。


我想走扶梯,但是大妈非不让我走,说带行李箱的坐直梯,当时人又多根本听不到她说啥,反正意思就是不让做扶梯,我提溜着俩大箱子有点不知所措,我寻思这大妈不让坐扶梯,我绕开她,去另个扶梯口坐不完了嘛,结果去了另一个扶梯口也不让进,但是我听明白啥意思了。


妈的当时我胳膊累的一点劲没有,还得去找直梯,你倒是领我去啊。灰头土脸的去沙河找腿哥凑合了一晚。第二天去租房,租房大家一定要提前做好攻略,中介都不是啥好东西,净找软柿子捏,租之前房间各个东西拍好照,很多本来就是坏的,到时候他会讹你。


第一次租房的体验特别差,合租舍友是个跑滴滴的,经常凌晨两三点、三四点回来,我那房间挨着厨房,他每次回来还要自己做饭,又吵又脏,呼呼的蟑螂。。。。


好在跟腿哥是一个小区,周末没事我就去找他,能给疲乏的生活一点慰藉吧,一度不想回屋子。偶尔找腿哥转一转北京散散心。


87377d32ly1gngkkpingbj21400u0n8e.jpg


工作上刚开始压力也是拉的满满的,好几次晚上1点、12点回家,虽然当时很累,但是没有过要放弃的念头。


image.png


那时候总是希望可以通过自己的努力实现阶级跨越,从底层阶级跨越到中产阶级,现在俨然是被磨平了棱角。


心猿意马


来公司的这三年,每年金三银四都是我心猿意马的时候,因为拿完年终了嘛,总想找一些机会,去年的3月21号,公司裁员了,猝不及防的裁员,而且杀伐决断,当天签补偿当天走,当时得知裁员名单里没有自己的时候心情特别复杂,又开心又不开心,也好也不好。


裁员的第二天,我请假去望京面了一家做投资app的小公司,结果很顺利,offer也发了,薪资也很满意,但是因为公司体量的问题,比现在的公司还小,最终还是没去,只能说遗憾至今吧。那时候没想明白自己来北京是干嘛来了,还有一些大厂情节,想去大厂。


我现在想明白了,我就是来赚钱来了,谁给我钱多我跟谁干,反正我又不留在北京。


解甲归田


不知不觉在公司搬了三年砖,从沙河搬到了回龙观,有时候经常跟自己开玩笑,是不是就在一家公司从一而终了,又到了每年心猿意马的金三银四了,今年无论如何都要再找找机会,就把今年当做是最后一年。还是坚决贯彻落实,给的高就润。


今年是北京的第三年,算上今天刚租的房子,已经算是换了四个地方了。每次换房子心情都很复杂,这次尤为严重,感觉自己有点抗不住了,漂泊的滋味属实不好受,准备最后换这一次就回山东了。


立帖为证,等以后躺平了也能回忆回忆自己有段激情燃烧的岁月。


最后希望大家都有更好的发展~


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

他扔出一张对话截图:王总说的

其实,我还在纠结,到底是写,还是不写。 也罢,给大家留作一个茶余饭后的谈资吧。如有雷同,纯属胡扯。 我在一家公司从事AI开发。我的身份是一个无法再底层的一线小开发。 产品总监又在群里贴出了那张对话截图。那是产研中心的王总跟他的对话,大体意思是王总要他组织一个同...
继续阅读 »

其实,我还在纠结,到底是写,还是不写。


也罢,给大家留作一个茶余饭后的谈资吧。如有雷同,纯属胡扯。


我在一家公司从事AI开发。我的身份是一个无法再底层的一线小开发。


产品总监又在群里贴出了那张对话截图。那是产研中心的王总跟他的对话,大体意思是王总要他组织一个同合作方的会议。


这个产品总监在这个群里,已经是第三次贴出这张截图了


第一次,他说要开一个公司层面的会。总监们纷纷发问:意义何在?


产品总监扔出这张截图:王总说的。


第二次,产品部的兄弟们有疑惑:开这个会的目的是什么?


产品总监第二次扔出这张截图:王总说的。


第三次,产品总监让我主讲这个会议。


我愣了:开会的目的是什么?


产品总监第三次扔出这张截图,表示:王总说的。


我说:不管哪个总说的,我都感觉意义不大。我可预料到过程,我说你们真好,对方说感谢夸奖,然后结束会议。


这个事情,还得从我的工作说起。我不仅从事AI项目的自研工作,同时也参与一些同第三方厂商的对接工作。因为公司的AI开发就我一个人。有些基础的AI能力,我们就打算买入第三方的服务。


因此,我的领导就安排我做调研工作。我先是调研国内AI行业的巨头。再调研垂直领域头部企业的AI开放能力。调研结束后,我将结果汇总,形成分析报告。然后,通过会议的形式,我把结果给直接领导讲了一遍。后来,直接领导拉来组内的产品,我又原样讲了第2遍。再后来,我的直接领导预约了他的直接领导,也就是我的二级领导,我又原样讲了第3遍。再后来,二级领导拉来公司所有的产品,我又原样讲了第4遍


再后来,已经不知是哪级领导,预约了给王总汇报,又安排我再原样讲第5遍。王总打断了我,他说,我不想知道你调研了多少家,以及哪家好哪家差,你辛苦那是你的工作,我不care这个。我想问,你的规划是什么?成本是多少?你将应用到哪些场景?能解决什么问题?创造多少收益?


同志们,记着我开头的声明,我是一个底层小员工。我最终还是没能回答上来。


会议结束之后,我和直接领导建议,是不是先让产品梳理一下我们到底有哪些AI需求。直接领导觉得,应该分两方面。第一,我们技术先自己想想,先按自己的想法走,这条路快。第二,慢慢地渗透给产品,让他们梳理一下,到底哪些场景会用到哪些AI能力,这条路可能要慢一些。


后来,王总主动安排下来一项任务。王总找到一家垂直行业的AI能力平台,想知道我们能不能用,好不好用。


最终这事,还是落到我的头上。我就把清单上的每一个接口,都做了调用和解析,并且采用可视化的形式来呈现结果。


我将结果给直接领导汇报了一次。结果就是,这次王总找的厂商,确实不错,带有行业加持,效果比之前我们找的都要好。直接领导找来产品总监和二级领导,我又原样讲了一遍


我的直接领导这次很机智,他想让产品梳理一下我们的产品,到底哪些地方会用到哪些AI能力。语音的能力要不要用?图像的能力具体怎么用?以便于我们技术可以进一步分析这些能力,到底能不能为我们所用。


再后来,就出现开头那一幕,产品总监安排我,同合作厂商再讲第3遍我的分析报告。并且他再次声明,那是王总安排的。


于是我就回复道:



不管哪个总安排的,这个会议意义不大。我只能说,你们的接口确实不错,他们也只能回复感谢支持。然后,尴尬结束。



因为,我们的产品规划,到底哪里用AI,用哪些AI,现在还是个空。


产品总监听到这里,很生气。他连发3条消息:



第一:到底他们的接口符不符合我们的业务场景,不符合要让他们整改,让它们攻克


第二:这绝不是一个你好我好的过场会


第三:请知悉。



群里,安静了一会儿。


我说。好吧,那我就以我自己梳理的往上靠吧。


会上,依然是我主讲。我又把已经讲了2遍的内容,讲了第3遍。我把他们每一个接口都做了分析,我表示这比之前调研的接口,效果都要好。这确实也是事实。


但是,具体我们能用吗?确实得先有产品规划,我才能确定是否能用到。为了避免成为“你好我好的过场会”,对于他们无法实现的,我提出质疑,他们说下一个版本会改好。


我马上记录下来,并确认:咱们下一个版本会改好的,对吧?


说完这句话,我收到一条钉钉消息。


产品总监发来的:来自王总的提醒,并不是我们给他们钱了,还没合作呢,不要有质问的语气!


我一看,好家伙,王总也参会了。一般提前预约都约不到的王总,居然悄悄参会了


我讲完了。王总发言说:我是中途赶来的。我想说,咱们这批接口是真的很好。你们接口的开放,是行业之大幸,对推动行业振兴很有帮助。对方说,王总太客气了,通过和咱们的交流,我们也有很大收获,也学到了很多知识。


我心想:这不还是一个你好我好的过场会。


会议结束了。


过了一会儿,我领导的领导打来电话,询问了会议的情况。最主要还是我群里发的那条:不管哪个总说的,对我来说,这个会意义不大


领导安慰我说,我估计你也是话赶话,赶到那里了。我断定你没有什么坏心眼,也不会故意使坏


我当时懵了一下。不知道他们领导层之间,到底是谁把什么消息,传播成了什么,上升到了什么层面。无职业素养地蔑视领导?以道德败坏形式破坏战略合作?王总的紧急出现,到底是巧合还是听到了什么风声?


不过,这些都无所谓,我只是一个底层小职员。我的职场生命力是最强的。我去80%的公司都可以再次成为一个小职员。


纵观整个过程。我们发现,一个企业的中层管理对企业起着至关重要的作用


第一次会议,王总不关注调研细节,这是没问题的。一个老总如果关心员工是如何进行调研的,反而是不称职。第二次会议,王总为公司找到好的资源,希望加强沟通,安排开会促进交流,这也是值得肯定的。


但是,对于每一个中层管理者,却不能让高层和基层进行100%的信息交换。尤其是向领导转发员工的截图,或者向员工转发领导的截图。


我经常看很多中层做类似的转发:给老板发某某员工抱怨公司的话,给员工发老板嫌弃员工不加班的截屏。这种行为很像是友商派来的内鬼。


大多数情况下,一个职场人了解自己的直接领导需要什么,但是不会很了解领导的领导的领导需要什么。一个领导多数理解直接下属怎么想,但是无法理解下属的下属怎么想。


每一位中层管理者,不管是上传和下达,都要做一次信息的过滤和加工。比如领导抱怨员工不加班,中层需要做的不是转发,而是加紧工作计划,说要提前上线,让员工忙起来。你要一说就是老板要看加班,还排好张三加二四六,李四加一三五,那两头都得气疯了。


我的两个例子就是个反面教材。


其实,我不需要直接给王总汇报。我至多向上汇报两级(如果他们真的非要分那么多级)。某级领导结合王总的近期规划,甚至最近的心情,去做一次简要汇报。而对于同一件事情来说,如果一个基层员工参会的次数,远超过领导参会的次数,这可能是一个预警。它表示,中层管理者根本没有加工信息,完全走转发路线。


王总安排给产品总监的会议,后来我也发现其实是高层之间的会议。安排我去参加确实意义不大。让我主讲更不可取。因为我了解的信息太少了,哪个叫张总,哪个是孙总,他们之间是什么样的商业关系,他们相互间的地位如何。如果非让我参加,应当是提前打好招呼,并且把我安排到殿外侯旨,问我时我再回答。


这些,基本上都得需要中层管理者来考虑。


对于上传下达,能做好过滤和加工,这样的中层是伟大的。啥也不做,这样的中层很难成长。添油加醋,煽风点火,这样的中层不予评价。


我碰到的产品总监是个聪明人,不在以上之列。他从一开始往外放对话截图,其实就表明了态度:其实我也不想开这会,但是领导非要开,还安排给我,大家配合一下,就混过去了。


但是,走到我这儿,我却发了一个牢骚。我感觉,第一,你不愿开你就跟领导直说,愿意开就用心安排,那是你的直接领导。第二,你给我一个会议号就完了,你这不是让我配合,是完全转交给我了呀。


再反过来讲,这会议真的没有意义吗?来了好的业务资源,我们不该去把握住吗?怎么一件好事,最后落得人人都不爽的地步。我抢了你的钱,局面是我赢你输。但是,一个事情搞得大家都输的情况,也是很难的。


活,还是我干了,事儿我也惹了。我始终还是没能当成一个,传统意义上,让你开会你就开会,哪儿那么多废话的俗人。可能这世界很需要俗人。


最后,奉劝大家在公司少发表意见。尤其和领导沾边的言论。


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

怎么去选择一个公司?

一家公司的好坏,除去客观情况,更多是个人的主观感受,甲之蜜糖,乙之砒霜,别人口中的“好公司”,未必适合你。 那我们应该怎么挑选一个适合自己的公司呢?还是有一些可以考量的指标的。 企业文化和价值观 行业势头 工资待遇 公司规模 人才水平 企业文化和价值观 无...
继续阅读 »

一家公司的好坏,除去客观情况,更多是个人的主观感受,甲之蜜糖,乙之砒霜,别人口中的“好公司”,未必适合你。


那我们应该怎么挑选一个适合自己的公司呢?还是有一些可以考量的指标的。



  • 企业文化和价值观

  • 行业势头

  • 工资待遇

  • 公司规模

  • 人才水平


企业文化和价值观


无法适应企业文化和价值观的员工,注定会被边缘化,获取不到资源,直到被淘汰。而适应企业文化和价值观的员工,在公司做事情则更能够得心应手。


如何选择适合自己的企业文化和价值观


如果你打算在一个公司长期发展,可以试着找找里面的熟人,聊聊公司内部的做事风格,比如晋升、奖金、淘汰、组内合作、跨部门合作以及如何处理各种意外情况等,这样就能实际感受到企业的文化和价值观了,然后再根据自己的标准,判断是否适合自己。


行业势头


行业一般会有风口期、黄金发展期和下降期三个阶段。



  • 处于下降趋势的行业要慎重考虑。

  • 处于风口期的行业发展趋势还不是很明显,如果你之前从事的行业和新的风口相关,那么不妨试试;如果你对这些风口背后的行业不是很熟悉,那不妨等风口的势头明朗了,再做打算。

  • 处于黄金发展期的行业发展已经稳定,有成熟的盈利模式,在这样的行业中积累经验,会在行业的发展上升期变得越来越值钱。如果你对这些行业感兴趣,不妨考虑相关的公司。


工资待遇


工资待遇不仅仅包括固定工资,还有一次性收入、奖金、股票以及各种福利等。


很多新入职的员工会有一些的奖金,例如签字费、安家费等,这些是一次性的,有时还会附加”规定时间内不能离职”等约束条件。这部分钱的性价比比较低,但一般金额还不错。


奖金主要看公司,操作空间很大,它和公司的经营状况关联紧密,谈Offer时约定的数额到后面不一定能够兑现,尤其是这两年整个互联网行业都不景气,很多公司的奖金都“打骨折”甚至直接取消了。


其他福利一般包括商业医疗保险、年假、体检、补贴等,它和公司所在行业有关联,具有公司特色。


股票也是待遇中很重要的一部分,很多公司在签Offer时会约定一定数量的股票,但是会分四年左右结清,这需要考虑你能坚持四年吗?四年之后没有股票要怎么办?


公司规模


如果待遇和岗位差不多,建议优先选择头部大公司,这样你可以学到更多的经验,接触更有挑战的业务场景,让自己成长的更快。


如果你看好一个行业,那么需要努力进入这个行业的头部公司。


人才水平


一个公司的人才水平,决定了公司对人才的态度和公司内部合作与管理的风格。


举个例子,如果一个公司里程序员的水平都很一般,那么这个公司就更倾向于不相信员工的技术能力,并制定非常细致和严格的管理规范和流程,避免员工犯错。如果你的水平高,就会被各种管理规范和流程束缚住。同时,如果你发现与你合作的人的水平都很“感人”,你也需要调整自己的风格,让自己的工作成果能够适应公司普遍的水平。


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

模块化时,如何进行模块拆分?

本文内容根据 Android 开发者大会内容整理而得,详见:By Layer or Feature? Why Not Both?! Guide to Android App Modularization 问题 随着项目的逐步增多,项目中的类文件如何存放、组织...
继续阅读 »

本文内容根据 Android 开发者大会内容整理而得,详见:By Layer or Feature? Why Not Both?! Guide to Android App Modularization


问题



  1. 随着项目的逐步增多,项目中的类文件如何存放、组织逐步变成一个问题;

  2. 在模块化的过程中,如何拆分代码或者拆分代码仓库需要一个指导原则;


image.png


衡量模块化好坏的标准


衡量模块化好坏主要有三个层面:耦合程度、内聚程度以及模块的颗粒度。耦合是衡量模块相互依赖的程度,内聚衡量单个模块的元素在功能上的相关性,颗粒度是指代码模块化的程度。好的模块应做到以下几点:



  1. 低耦合:模块不应该了解其他模块的内部工作原理。 这意味着模块应该尽可能地相互独立,以便对一个模块的更改对其他模块的影响为零或最小。




  1. 高内聚:意味着模块应该仅包含相关性的代码。在一个示例电子书应用程序,将书籍和支付的代码混合在同一个模块中可能是不合适的,因为它们是两个不同的功能领域。





  1. 适中颗粒度:代码量与模块数量有恰当的比例,模块太多会产生一定的开销,模块太少达不到复用的效果。




按照层级(Layer)划分


层级是指 Android 官方架构指南中的三层架构,分别为 UI LayerDomain LayerData Layer



在小型项目中按照 Layer 进行分层是可以满足需求的,随着项目的增大,需要将更多功能拆分到更多的模块中,否则就会出现高耦合和低内聚的情况。


按照特性(Feature)划分


若是按照特性划分,每个模块中会包含相似/相同逻辑(如 Reviews),从而导致代码冗余。



模块间的依赖逻辑耦合严重,不利于独立开发。



同时使用分层和特性划分


可以同时结合分层与特性划分的优势,扬长避短。首先按照特性拆分,在拆分后的这个小的逻辑单元中再按照层级来分,这也是壳工程的一个基本思路。



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

97程序猿的自述

为什么突然想写文章了? 不要问,问就是因为无聊。(开玩笑) 1.确实是闲下来了,比刚开始工作的时候的埋头苦干,满身充实到现在闲下来之后开始迷茫 2.回头看,在一些职业生涯的选择上幸运过也不幸过。 3.希望把自己的一些经历写出来,提供给一些同在这条路上的同学们...
继续阅读 »

为什么突然想写文章了?


不要问,问就是因为无聊。(开玩笑)



1.确实是闲下来了,比刚开始工作的时候的埋头苦干,满身充实到现在闲下来之后开始迷茫


2.回头看,在一些职业生涯的选择上幸运过也不幸过。


3.希望把自己的一些经历写出来,提供给一些同在这条路上的同学们一些参考



个人标签



97、天蝎男、本四、科班、深漂、培训、后端、外包、大厂背书



本四、科班



院校:末流本科;




专业:计算机科学与技术




和常见的大学生一样,玩不断的游戏,端游:DNF、CF、大逃杀、英雄联盟等,手游:王者、吃鸡、狼人杀。通宵,逃课(可能少但是是相对而言)




在学校除了必修课程中有和计算机相关的C语言,R语言,汇编语言,算法,Java(最后成为一名JAVA开发工程师)等,仿佛程序员和我并没有挂钩的地方。




比较幸运的是我是19年毕业,当时江西师范类专业是最后一届教师资格证校内颁发的证书的,所以有信息技术的教师资格证,可能以后还有机会回老家教书。




个人认为在学校还是比较合格的,四六级、普通话、二级、连续的校级奖学金(一、二、三等都有)、优秀毕业生,优秀毕业设计等,虽然最后除了英语证书在互联网职场生涯仿佛没有什么帮助。



其实到现在这个年纪了,经常会有学校的老师推荐我给一些要出校园的学弟学妹指导,或者一些亲戚朋友考上大学的学校和专业做指导。如果有需要的话可以私信我沟通,还是比较热于与人沟通,和不同的人会有不同的收获。


实习or培训



校招路线对于普通院校来讲是不太现实的,没有好的公司会来学校开招聘会(还是会有一些本土企业,国企等)。


当然我也听有一些同事说过可以去别的学校参加招聘会,但实际上我并不认可,可以简单来讲,在大学并没有学到什么,没有核心竞争力。




当然起初大四出来实习的时候,准确的来说是大三暑假,学校要求去学校实习(师范类专业),两个选择,自己选学校去实习,或者学校随机安排去一些学校实习。


我选了自己去学校实习,但实际上我并没有去院校实习,而是来了深圳。我觉得大部分像我一样家里没矿,没厂也不吃国家粮的同学大部分都会这样选择。
18年7月,那是我第一次来深圳,当然比起许多独自深漂的大学生来讲,我是比较幸运的,爸妈从我上大学开始就已经从老家来到深圳做生意了,从刚开始的租房到二手房生意,有亏损有盈利,到现在疫情现状的基本上只能维稳。


至少来到深圳开始我就没有为租房而烦恼,也没有为吃不到家里的菜而觉得可怜。
刚开始从江西来到深圳的时候,因为家里有个叔叔是在阿里做技术专家(其实现在也不知道具体级别,只知道应该还是蛮高的职位的)虽然不是亲叔叔,还是有血缘关系的,小时候也是一起在老家,但自从去了上海之后就基本上两三年过年见一次了。


爸妈从刚从学校要安排工作实习我说来深圳的时候就一直和我说让我多问问他,看看有没有什么好的建议找个好工作。和叔叔打了很多个电话,也获得很多建议,一直都放在我的微信收藏夹里面,不知道什么时候删掉了qaq。当时给我的建议是先自学,因为我也比较实诚,在学校没学到就是没学到,也直说了。


兜兜转转,我试过了直接找工作,自学,最后工作无门才走上了培训,其实关于培训可能大部分人或者职场人都比较歧视。我也不想讲太多关于培训的事情,讲个大概就好了,一般都是半年左右,当然如果是转行之类的年龄比较大的可能会存在学习或者就业困难可能耗时会多上一到两个月,我是从18年8月到12月。培训后的第一个礼拜就找到工作,第一次入职的时间是12月20日。是一个外包公司,深圳某本,还算是比较大外包公司吧。



外包



关于人力外包,网上有很多不好的消息,很多人都会问,软件外包好不好之类的,说实话这个没有答案。如果你有好的工作机会你也不会去问软件外包好不好,工作了这么多年倒是明白了一个道理没有什么工作好不好的,只有钱多和钱少
大厂驻场开发,两年半,也是我目前最长的一份工作经历。


有一些我以前不太敢说的事情,现在也可以坦然面对了。我是幸运的,外包包装简历(写假的工作简历)成功入职,我清楚的记得那是第三次面试,一共二面,我以为一面我已经挂了,到后面被通知二面再到入职。


入职后我要装成四年工作经验的开发,不敢多问,问之前一定要搞清楚,确定什么该问什么不该问。我可以很自信的说,我工作上手后并不弱于工作多年的一些目前我认识只会写CURD的同事。


甚至于同事也不敢说真实年龄,明明是97,需要说成94。也碰到过一些很尴尬的事情。



某厂



其实在外包两年左右的时间开始我就已经提出了辞呈,面试了几家小公司(规模500人,开发团队10人左右),并且已经谈好了薪资准备入职,当时20年的时候,薪资也比较满意16K左右。于是就和本司(某本)说了之后在和leader沟通。其实一直都挺感谢我的leader,从入职对互联网什么都不懂,除了培训的一些基础操作外,到后面做骨干开发,小组长,转内部,虽然也有我努力,遇事愿意去做的原因。但如果换一个领导,可能并不会像现在这样有大厂背书,可以有更多的岗位考虑。




由于转内通道等一系列内部原因,大概花了半年时间才把整个流程走下来(这个事前leader也有和我沟通,意思就是现在有这么一个机会,你愿不愿意等),当时我其实还是蛮犹豫的,但为了背书我留了下来。甚至到后面leader们都离职了,我的流程也走下来了。




关于前公司的很多事情,其实还是蛮有意思的,不论是企业文化,还是和一些前同事,开发,测试,产品,项目经理等吃饭,打麻将。



我是幸运的,至少到目前来讲我认为。我时常和朋友讲,像我这个学历,这个工龄是不会被大厂给筛选过。


职场


tip:先讲一下大家比较感兴趣的吧


薪资
18年入职:10.5K*12


19年普调:11.6*12


20年普调+特批:14.7*12


21年转内 17.2 + 10(年终)


22年跳槽 23*14(ps:行情不好没有14了)



到目前工作第四年,不多不少刚好是第名义上的四家公司。没有换城市,一直在深圳。


也没有中间休息过,除了离职前把年假休掉外,基本上全勤。有时候真的很想直接辞职去旅旅游,说实话疫情的三年导致本来就没有旅游过的我更没有机会去玩,一直都觉得很可惜。


到现在年龄越来越大,家庭长辈的各方面的压力也越来越大,以后就更没有机会去玩了,从开始的不屑于去谈论更好的工资,离职不考虑没工资,到现在需要这么一份工作,不敢辞职,年龄越来越大真的越来越不像自己。



未完待续


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