问题

业务上需要将一些数据缓存到本地，思路是定义个类，赋值后使用 Gson 转换为 Json 数据存到本地。但是由于需要 SpannableStringBuilder 来保存Text的富文本属性，尝试序列化会 Json 后，再反序列化为 SpannableStringBuilder 赋值给 TextView 会有一些意外的错误。

Stack trace:  

java.lang.IndexOutOfBoundsException: setSpan (0 ... -1) has end before start

	at android.text.SpannableStringInternal.checkRange(SpannableStringInternal.java:485)

	at android.text.SpannableStringInternal.setSpan(SpannableStringInternal.java:199)

	at android.text.SpannableStringInternal.copySpansFromSpanned(SpannableStringInternal.java:87)

	at android.text.SpannableStringInternal.<init>(SpannableStringInternal.java:48)

	at android.text.SpannedString.<init>(SpannedString.java:35)

	at android.text.SpannedString.<init>(SpannedString.java:44)

	at android.text.TextUtils.stringOrSpannedString(TextUtils.java:532)

	at android.widget.TextView.setText(TextView.java:6318)

	at android.widget.TextView.setText(TextView.java:6227)

	at android.widget.TextView.setText(TextView.java:6179)

探索

SpannableString

起初尝试将 SpannableStringBuilder 转为 SpannableString：

val spannableStringBuilder = SpannableStringBuilder("测试文本")

val spannableString = SpannableString.valueOf(spannableStringBuilder)

虽然恢复数据时不会报错，但 SpannableString 的属性全部消失了。

Html

于是开始检索如何持久化 SpannableStringBuilder， 在 Stackoverflow 上有这么一个方案

android: how to persistently store a Spanned?

其中提到需要可以使用 Android 的 Html 类的 Html.toHtml 方法将 SpannableStringBuilder 数据转换为 html 的标签语言，恢复时再使用 Html.fromHtml

val spannableStringBuilder = SpannableStringBuilder("测试文本")



val htmlString = Html.toHtml(spannableStringBuilder)



val spannableStringBuilder = Html.fromHtml(htmlString)

测试了一个，以上方式确实是一个顺利解决的崩溃问题。需要注意的是，Html 的两个方法都是耗时方法，最好异步调用。

自定义 Gson 序列化和反序列化适配器

项目的 Json 解析框架使用的是 Gson，支持自定义序列化和反序列化。于是，编写一个适配器实现 JsonSerializer和 JsonDeserializer

class SpannableStringBuilderTypeAdapter : JsonSerializer<SpannableStringBuilder>,

	JsonDeserializer<SpannableStringBuilder> {

	override fun serialize(

		src: SpannableStringBuilder?,

		typeOfSrc: Type?,

		context: JsonSerializationContext?

	): JsonElement {

		return src?.let {

			JsonPrimitive(Html.toHtml(src))

		} ?: JsonPrimitive("")

	}



	override fun deserialize(

		json: JsonElement?,

		typeOfT: Type?,

		context: JsonDeserializationContext?

	): SpannableStringBuilder {

		return json?.let {

			val fromHtml = Html.fromHtml(json.asString).trim()

			SpannableStringBuilder(fromHtml)

		} ?: SpannableStringBuilder("")

	}

}



	//使用

	Gson gson = new GsonBuilder()

				.setDateFormat("yyyy-MM-dd hh:mm:ss")

				.registerTypeAdapter(SpannableStringBuilder.class,

						new SpannableStringBuilderTypeAdapter())

				.create();

	

以上代码可以很好的工作，如果细心的话，可以注意到反序列化时用到 trim()，因为反序列化为 SpannableStringBuilder 后字符串末尾会多处两个换行符，这个 Stackoverflow 有提到HTML.fromHtml adds space at end of text?。

总结，这次探索让我对持久化多了一些思路，对于一些无法修改源码的类可以自定义适配器来序列化。

前言

JavaScript 中的 this 是一个非常重要的概念，也是一个令新手开发者甚至有些不深入理解的多年经验开发者都会感到困惑的概念。

如果你希望自己能够使用 this 编写更好的代码或者更好理解他人的代码，那就跟着我一起理解一下this吧。

要理解this的原因

我们先搞清楚为什么要理解 this 的，再去学习它。

• 学习 this 可以帮助我们更好地理解代码的上下文和执行环境，从而编写更好的代码。

例1：

function speakfullName(){

    console.log(this.firstname + this.lastname)

}



var firstname = '南'

var lastname = '墨'



const gril = {

    firstname: '黎',

    lastname: '苏苏',

    speakfullName,

}



const boy = {

    firstname: '澹台',

    lastname: '烬',

    speakfullName,

}



 gril.speakfullName(); // 输出： 黎苏苏

 boy.speakfullName(); // 输出： 澹台烬

 speakfullName(); // 输出： 南墨

在这个例子中，如果你没理解 this 的用法，那么阅读这段代码就会觉得奇怪，为什么同一个函数会输出不同的结果。之所以奇怪，是因为你不知道他的上下文到底是什么。

• 学习 this 可以帮助我们编写更具可重用性和可维护性的代码

在例1中可以在不同的上下文中使用 this，不用针对不同版本写不同的函数。当然不使用 this，也是可以的。

例2：

function speakfullName(person){

    console.log(person.firstname + person.lastname)

}



const gril = {

    firstname: '黎',

    lastname: '苏苏',

}



const boy = {

    firstname: '澹台',

    lastname: '烬',

}



speakfullName(gril); // 黎苏苏 

speakfullName(boy); // 澹台烬

虽然目前这段代码没有问题，如果后续使用的模式越来越复杂，那么这样的显示传递会让代码变得难以维护和重用，而this的隐式传递会显得更加优雅一些。因此，学习this可以帮助我们编写更具有可重用性和可维护性的代码。

接下来我们开始正式全面解析 this

解析 this

我相信大家多多少少都理解一些 this 的用法，但可能不够全面，所以接下来我们就全面性的理解 this。

很多人可能认为this 写在哪里就是指向所在位置本身，如下代码：

var a = 2

function foo (){

   var a = 1

   console.log(this.a)

}

foo();

有些人认为会输出1，实际是输出2，这就是不够理解 this 所产生的的误会。

那this的机制到底是什么样的呢？

其实this不是写在哪里就被绑定在哪里，而是代码运行的时候才被绑定的。也就是说如果一个函数中存在this，那么this到底被绑定成什么取决于这个函数以什么样的方式被调用。

既然已经提出了这样一个机制，那我们该如何根据这个机制，去理解和判断this被绑定成什么呢？

下面我们继续介绍这个机制的基本原理。

调用位置

上面说过，函数的调用位置会影响this被绑定成什么了，所以我们需要知道函数在哪里被调用了。

我们回头去看一下 例1，来理解什么是调用位置：

// ...

 gril.speakfullName(); // 输出： 黎苏苏

 boy.speakfullName(); // 输出： 澹台烬

 speakfullName(); // 输出： 南墨

同一个函数 speakfullName， 在不同的调用位置，它的输出就不一样。

在 gril 对象中调用时，输出了黎苏苏，在 boy 对象中调用时，输出了澹台烬，在全局调用时输出了南墨。

当然例子中的调用位置是非常容易看出来的。所以我们接下来继续讲解在套多层的情况下如何找到调用位置。

我们要找到调用位置就要分析调用栈。

看下简单例子：

function baz() {

  // 当前调用栈：baz

  console.log('baz')

  bar(); // bar 调用的位置

}



function bar() {

  // 当前调用栈：baz-bar

  console.log('bar')

  foo(); // foo 调用的位置

}



function foo() {

  // 当前调用栈：baz-bar-foo

  console.log('foo')

}

baz() // baz的调用位置

其实调用栈就是调用位置的链条，就像上面代码例子中所分析的一样。不过在一些复杂点的代码中，这样去分析很容易出错。所以我们可以用现代浏览器的开发者工具帮助我们分析。

比如上例中，我们想找到 foo 的调用位置，在 foo 中第一行输入debugger。

// ...



function foo() {

  debugger

  // ...

}

// ...

或者打开浏览器的开发者工具到源代码一栏找到，foo的代码的第一行打一个断点也行，如下图：

接着在源代码一栏，找到调用堆栈的foo的下一个就是bar，bar就是foo的调用位置。

绑定规则

接下来看看调用位置如何决定this被绑定成什么，并且进行总结。

默认规则

第一种情况是函数最经常被调用的方式，函数被单独调用。看以下例子：

var name = '澹台烬'

function fn(){

    console.log('我是' + this.name)

}

fn() // 我是澹台烬

运行fn后，最终输出了 我是澹台烬。众所周知，上例中的 name 是全局的变量，这样说明了fn中的 this.name 被绑定成了全局变量name。因此，this指向了全局对象。

因为在上例的代码片段中，foo的调用位置是在全局中调用的，没有其他任何修饰, 所以我们称之为默认规则。

使用了严格模式的话，上例代码会出现什么样的情况呢？

var name = '澹台烬'

function sayName(){

    "use strict"

    console.log(this) // (1)

    console.log('我是' + this.name) // (2)

}

fn() 

// undefined 

// TypeError: cannot read properties of undefined (reading 'name') as sayName

可以看出来(1)也就是this，输出了undefiend 所以(2)就直接报错了。

因此我们可以得出默认规则的结论：在非严格模式下，this默认绑定成全局对象，在严格模式下，this 被绑成 undefined。

隐式绑定

这条规则需要我们去判断函数的调用是否有上下文对象，也就是说函数调用的时候前面是否跟了一个对象，举个例子看下。

function sayName() {

    console.log(`我是` + this.name)

}

var person = {

    name: '澹台烬',

    sayName,

}

person.sayName(); // 我是澹台烬

在这个例子中， sayName 前面有一个 person，也就是说 sayName 函数有一个上下文对象person， 这样调用 sayName 的时候，函数中 this 被绑定成了person，因此 this.name 和 person.name 是一样的。

在观察隐式绑定的时候，有两种值得我们注意的情况：

• 如果说一个函数是通过对象的方式调用时，只有最后一个对象起到上下文的作用。 例3:

function sayName() {

    console.log(`我是` + this.name)

}



var child = {

    name: '澹台烬',

    sayName,

}



var father = {

    name: '澹台无极',

    child,

}



father.child.sayName(); // 我是澹台烬

这个例子中，是通过一个对象链调了sayName，没有输出我是澹台无极，而是我是澹台烬。因此 this 指向了child 对象，说明this 最终绑定为对象链的最后一个对象。

• 隐式丢失的情况就是被隐式绑定的函数丢失绑定的上下文，转而变成了应用默认绑定。

function sayName() {

    console.log(`我是` + this.name)

}

var person = {

    name: '澹台烬',

    sayName,

}



var personSayName = person.sayName;



var name = '南墨'



pesonSayName() // '我是南墨'

虽然 personSayName 看起来是由 person.sayName 赋值的来，拥有上下文对象person，但实际上 personSayName 被赋予的是 sayName 函数本身，因此此时的 personSayName其实是一个不带修饰的函数， 所以说会被认为是默认绑定。

显示绑定

隐式绑定是通过一个看起来不经意间的上下文的形式去绑定的。

那也当然也有通过一个明显的上下文强制绑定的，这就是显示绑定

在 javaScript 中，要是使用显示绑定，就要通过 call 和 apply方法去强制绑定上下文了

这两个方法的使用方法是什么样的呢？ call 和 apply的第一个参数的是一样的，就是传入一个我们想要给函数绑定的上下文。

来看一下下面的例子

function sayName () {

 console.log(this.name)

}



var person = {

   name: 南墨

}



sayName.call(person) // 南墨

看到没？ 我们通过call的方式，将函数的上下文绑定为了 person，因此打印出了 南墨。

使用了 call 绑定也会有绑定丢失的情况，所以我们需要一种保证在我意料之内的办法， 可以改造显示绑定，思考如下代码：

function sayName() {

 console.log(this.name)

}



var person = {

 name: 南墨

}



function sayNanMo() {

 sayName.call(person);

}



sayNanMo() // 南墨

setTimeout(sayNanMo， 10000) // 南墨

sayNanMo.call(window) // 南墨

这样一来，不管怎么操作，都会输出南墨，是我想要的结果

我们将 sayName.call(person) 放在的 sayNanMo 中，因此sayName 只能被绑定为我们想要绑定的 person。

我们可以将其写成可复用的函数

function bind(fn, obj) {

 return function() {

   fn.apply(obj, arguments)

 }

}

ES5 就提供了内置的方法 Function.prototype.bind，用法如下：

function sayName() {

  console.log(this.name)

}



var person = {

  name: 南墨

}



sayName.bind(person)

new绑定

new 绑定也可以影响函数调用时的 this 绑定行为，我们称之为new 绑定。

思考如下代码：

function person(name) {

   this.name = name;

   this.sayName = function() {

     console.log(this.name)

   }

}

   

var personOne = new person('南墨')



personOne.sayName() // 南墨

personOne.sayName 能够输出南墨，是因为使用 new 调用 person 时，会创建一个新的对象并将它绑定到 person中的 this 上，所以personOne.sayName中的 this.name 等于外面的this.name。

规则之外

值得一提的是，ES6的箭头函数，它的this无法使用以上四个规则，而是而是根据外层（函数或者全局）作用域来决定this。

  function sayName () {

     return () => {

       console.log(this.name)

     }

  }



  var person1 = {

        name: 南墨

  }



  var person2 = {

      name: '澹台烬'

  }

  sayName.call(person1)

  sayName.call(person1).call(person2) // 澹台烬，如果是普通函数会输南墨

}

总结

要想判断一个运行的函数中this的绑定，首先要找到函数调用位置，因为它会影响this的绑定。然后使用四个绑定规则：new绑定、显示绑定、隐式绑定、默认规则 来判断this的绑定。

安卓拍照、裁切、选取图片实践

前言

最近项目里面有用到裁切功能，没弄多复杂，就是系统自带的，顺便就总结了一下系统拍照、裁切、选取的使用。网上的资料说实话真是没什么营养，但是Android官网上的说明也有点太简单了，真就要实践出真理。

拍照

本来拍照是没什么难度的，不就是调用intent去系统相机拍照么，但是由于文件权限问题，Uri这东西就能把人很头疼。下面是代码(onActivityResult见后文)：

    private fun openCamera() {

        val intent = Intent(MediaStore.ACTION_IMAGE_CAPTURE)

        // 应用外部私有目录：files-Pictures

        val picFile = createFile("Camera")

        val photoUri = getUriForFile(picFile)

        // 保存路径，不要uri，读取bitmap时麻烦

        picturePath = picFile.absolutePath

        // 给目标应用一个临时授权

        intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

        //android11以后强制分区存储，外部资源无法访问，所以添加一个输出保存位置，然后取值操作

        intent.putExtra(MediaStore.EXTRA_OUTPUT, photoUri)

        startActivityForResult(intent, REQUEST_CAMERA_CODE)

    }



    private fun createFile(type: String): File {

        // 在相册创建一个临时文件

        val picFile = File(requireContext().getExternalFilesDir(Environment.DIRECTORY_PICTURES),

                "${type}_${System.currentTimeMillis()}.jpg")

        try {

            if (picFile.exists()) {

                picFile.delete()

            }

            picFile.createNewFile()

        } catch (e: IOException) {

            e.printStackTrace()

        }



        // 临时文件，后面会加long型随机数

//        return File.createTempFile(

//            type,

//            ".jpg",

//            requireContext().getExternalFilesDir(Environment.DIRECTORY_PICTURES)

//        )



        return picFile

    }



    private fun getUriForFile(file: File): Uri {

        // 转换为uri

        return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {

            //适配Android 7.0文件权限，通过FileProvider创建一个content类型的Uri

            FileProvider.getUriForFile(

                requireActivity(),

                "com.xxx.xxx.fileProvider", file

            )

        } else {

            Uri.fromFile(file)

        }

    }

简单说明

这里的file是使用getExternalFilesDir和Environment.DIRECTORY_PICTURES生成的，它的文件保存在应用外部私有目录：files-Pictures里面。这里要注意不能存放在内部的私有目录里面，不然是无法访问的，外部私有目录虽然也是私有的，但是外面是可以访问的，这里拿官网上的说明：

在搭载 Android 9（API 级别 28）或更低版本的设备上，只要您的应用具有适当的存储权限，就可以访问属于其他应用的应用专用文件。为了让用户更好地管理自己的文件并减少混乱，以 Android 10（API 级别 29）及更高版本为目标平台的应用在默认情况下被授予了对外部存储空间的分区访问权限（即分区存储）。启用分区存储后，应用将无法访问属于其他应用的应用专属目录。

Uri的获取

再一个比较麻烦的就是Uri的获取了，网上有一大堆资料，不过我这也贴一下，网上的可能有问题。

manifest.xml

        <provider

            android:name="androidx.core.content.FileProvider"

            android:authorities="com.xxx.xxx.fileProvider"

            android:exported="false"

            android:grantUriPermissions="true">

            <meta-data

                android:name="android.support.FILE_PROVIDER_PATHS"

                android:resource="@xml/file_paths"

                />

        </provider>

res -> xml -> file_paths.xml

<?xml version="1.0" encoding="utf-8"?>

<paths xmlns:android="http://schemas.android.com/apk/res/android">

    <!--1、对应内部内存卡根目录：Context.getFileDir()-->

    <files-path

        name="int_root"

        path="/" />

    <!--2、对应应用默认缓存根目录：Context.getCacheDir()-->

    <cache-path

        name="app_cache"

        path="/" />

    <!--3、对应外部内存卡根目录：Environment.getExternalStorageDirectory()-->

    <external-path

        name="ext_root"

        path="/" />

    <!--4、对应外部内存卡根目录下的APP公共目录：Context.getExternalFileDir(String)-->

    <external-files-path

        name="ext_pub"

        path="/" />

    <!--5、对应外部内存卡根目录下的APP缓存目录：Context.getExternalCacheDir()-->

    <external-cache-path

        name="ext_cache"

        path="/" />

</paths>

ps. 注意authorities这个最好填自己的包名，不然有两个应用用了同样的authorities，后面的应用会安装不上。

打开相册

这里打开相册用的是SAF框架，使用intent去选取(onActivityResult见后文)。

    private fun openAlbum() {

        val intent = Intent()

        intent.type = "image/*"

        intent.action = "android.intent.action.GET_CONTENT"

        intent.addCategory("android.intent.category.OPENABLE")

        startActivityForResult(intent, REQUEST_ALBUM_CODE)

    }

裁切

裁切这里比较麻烦，参数比较多，而且Uri那里有坑，不能使用provider，再一个就是图片传递那因为安卓版本变更，不会传略缩图了，很坑。

    private fun cropImage(path: String) {

        cropImage(getUriForFile(File(path)))

    }



    private fun cropImage(uri: Uri) {

        val intent = Intent("com.android.camera.action.CROP")

        // Android 7.0需要临时添加读取Url的权限

        intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

//        intent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

        intent.setDataAndType(uri, "image/*")

        // 使图片处于可裁剪状态

        intent.putExtra("crop", "true")

        // 裁剪框的比例（根据需要显示的图片比例进行设置）

//        if (Build.MANUFACTURER.contains("HUAWEI")) {

//            //硬件厂商为华为的，默认是圆形裁剪框，这里让它无法成圆形

//            intent.putExtra("aspectX", 9999)

//            intent.putExtra("aspectY", 9998)

//        } else {

//            //其他手机一般默认为方形

//            intent.putExtra("aspectX", 1)

//            intent.putExtra("aspectY", 1)

//        }



        // 设置裁剪区域的形状，默认为矩形，也可设置为圆形，可能无效

        // intent.putExtra("circleCrop", true);

        // 让裁剪框支持缩放

        intent.putExtra("scale", true)

        // 属性控制裁剪完毕，保存的图片的大小格式。太大会OOM（return-data）

//        intent.putExtra("outputX", 400)

//        intent.putExtra("outputY", 400)



        // 生成临时文件

        val cropFile = createFile("Crop")

        // 裁切图片时不能使用provider的uri，否则无法保存

//        val cropUri = getUriForFile(cropFile)

        val cropUri = Uri.fromFile(cropFile)

        intent.putExtra(MediaStore.EXTRA_OUTPUT, cropUri)

        // 记录临时位置

        cropPicPath = cropFile.absolutePath



        // 设置图片的输出格式

        intent.putExtra("outputFormat", Bitmap.CompressFormat.JPEG.toString())



        // return-data=true传递的为缩略图，小米手机默认传递大图， Android 11以上设置为true会闪退

        intent.putExtra("return-data", false)



        startActivityForResult(intent, REQUEST_CROP_CODE)

    }

回调处理

下面是对上面三个操作的回调处理，一开始我觉得uri没什么用，还制造麻烦，后面发现可以通过流打开uri，再去获取bitmap，好像又不是那么麻烦了。

    override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {

        super.onActivityResult(requestCode, resultCode, data)

        if (resultCode == RESULT_OK) {

            when(requestCode) {

                REQUEST_CAMERA_CODE -> {

                    // 通知系统文件更新

//                    requireContext().sendBroadcast(Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE,

//                        Uri.fromFile(File(picturePath))))

                    if (!enableCrop) {

                        val bitmap = getBitmap(picturePath)

                        bitmap?.let {

                            // 显示图片

                            binding.image.setImageBitmap(it)

                        }

                    }else {

                        cropImage(picturePath)

                    }

                }

                REQUEST_ALBUM_CODE -> {

                    data?.data?.let { uri ->

                        if (!enableCrop) {

                            val bitmap = getBitmap("", uri)

                            bitmap?.let {

                                // 显示图片

                                binding.image.setImageBitmap(it)

                            }

                        }else {

                            cropImage(uri)

                        }

                    }

                }

                REQUEST_CROP_CODE -> {

                    val bitmap = getBitmap(cropPicPath)

                    bitmap?.let {

                        // 显示图片

                        binding.image.setImageBitmap(it)

                    }

                }

            }

        }

    }



    private fun getBitmap(path: String, uri: Uri? = null): Bitmap? {

        var bitmap: Bitmap?

        val options = BitmapFactory.Options()

        // 先不读取，仅获取信息

        options.inJustDecodeBounds = true

        if (uri == null) {

            BitmapFactory.decodeFile(path, options)

        }else {

            val input = requireContext().contentResolver.openInputStream(uri)

            BitmapFactory.decodeStream(input, null, options)

        }



        // 预获取信息，大图压缩后加载

        val width = options.outWidth

        val height = options.outHeight

        Log.d("TAG", "before compress: width = " +

                options.outWidth + "， height = " + options.outHeight)



        // 尺寸压缩

        var size = 1

        while (width / size >= MAX_WIDTH || height / size >= MAX_HEIGHT) {

            size *= 2

        }

        options.inSampleSize = size

        options.inJustDecodeBounds = false

        bitmap = if (uri == null) {

            BitmapFactory.decodeFile(path, options)

        }else {

            val input = requireContext().contentResolver.openInputStream(uri)

            BitmapFactory.decodeStream(input, null, options)

        }

        Log.d("TAG", "after compress: width = " +

                options.outWidth + "， height = " + options.outHeight)



        // 质量压缩

        val baos = ByteArrayOutputStream()

        bitmap!!.compress(Bitmap.CompressFormat.JPEG, 80, baos)

        val bais = ByteArrayInputStream(baos.toByteArray())

        options.inSampleSize = 1

        bitmap = BitmapFactory.decodeStream(bais, null, options)



        return bitmap

    }

这里还做了一个图片的质量压缩和采样压缩，需要注意的是采样压缩的采样率只能是2的倍数，如果需要按任意比例采样，需要用到Matrix，不是很难，读者可以研究下。

权限问题

如果你发现你没有申请权限，那你的去申请一下相机权限；如果你发现你还申请了储存权限，那你可以试一下去掉储存权限，实际还是可以使用的，因为这里并没有用到外部储存，都是应用的私有储存内，具体关于储存的适配，可以看我转载的这几篇文章，我觉得写的非常好：

Android 存储基础

Android 10、11 存储完全适配(上）

Android 10、11 存储完全适配(下）

结语

以上代码都经过我这里实践了，确认了可用，可能写法不是最优，可以避免使用绝对路径，只使用Uri。至于请求码、布局什么的，读者自己改一下加一个就行，核心部分已经在这了。如果需要完整代码，可以看下篇文章末尾！

Android 不申请权限储存、删除相册图片

前言

亲爱的友友们，我们今天来看一下如何巧妙利用枚举来替代if语句

能实现功能的代码千篇一律，但优雅的代码万里挑一

业务背景

在工作中遇到一个需求，经过简化后就是：需要根据不同的code值，处理逻辑，然后返回对应的对象。

我就简答举个栗子哈💬

根据 不同的code，返回不同的对象 传1 返回 一个对象，包含属性：name、age ; 传2，返回一个对象，包含属性name ; 传3，返回一个对象，包含属性sex .... 字段值默认为 test

思路

摇头版

public class TestEnum {

    public static void main(String[] args) {

        Integer code = 1;//这里为了简单，直接这么写的，实际情况一般是根据参数获取

        JSONObject jsonObject = new JSONObject();

        if(Objects.equals(0,code)){

            jsonObject.fluentPut("name", "test").fluentPut("age", "test");

            System.out.println("jsonObject = " + jsonObject);

        }

        if(Objects.equals(1, code)){

            jsonObject.fluentPut("name", "test");

            System.out.println("jsonObject = " + jsonObject);

        }

        if(Objects.equals(2,code)){

            jsonObject.fluentPut("sex", "test");

            System.out.println("jsonObject = " + jsonObject);

        }

    }

}

上面的代码在功能上是没有问题滴，但是要扩展的话就💘，比如 当code为4时，ba la ba la，我们只有再去写一遍if语句，随着code的增加，if语句也会随之增加，后面的人接手你的代码时 💔

优雅版

我们首先定义一个枚举类，维护对应Code需要返回的字段

@Getter

@AllArgsConstructor

public enum DataEnum {

    /**

     * 枚举类

     */

    CODE1(1,new ArrayList<>(Arrays.asList("name","age"))),

    CODE2(2,new ArrayList<>(Arrays.asList("name"))),

    CODE3(3,new ArrayList<>(Arrays.asList("sex")))

    ;

    private Integer code;

    private List<String> fields;

	//传入code 即可获取对应的 fields

    public static List<String> getFieldsByCode(Integer code){

        DataEnum[] values = DataEnum.values();

        for (DataEnum value : values) {

            if(Objects.equals(code, value.getCode())) {

                return value.getFields();

            }

        }

        return null;

    }

}

客户端代码

public class TestEnum {

    public static void main(String[] args) {

        //优雅版

        JSONObject jsonObject = new JSONObject();

        //传入code，获取fields

        List<String> fieldsByCode = DataEnum.getFieldsByCode(1);

        assert fieldsByCode != null;

        fieldsByCode.forEach(x->{

           jsonObject.put(x,"test");

        });

        System.out.println(jsonObject);

    }

}

实现的功能和上面的一样，但是我们发现TestEnum代码里面一条if语句都没有也，这时，即使code增加了，我们也只需要维护枚举类里面的代码，压根不用在TestEnum里面添加if语句，是不是很优雅😎

小总结

【Tips】我们在写代码时，一定要考虑代码的通用性

上面的案例中，第一个版本仅仅只是能实现功能，但是当发生变化时难以维护，代码里面有大量的if语句，看着也比较臃肿，后面的人来维护时，也只能不断的添加if语句，而第二个版本巧用枚举类的方法，用一个通用的获取fields的方法，我们的TestEnum代码就变得相当优雅了😎

结语

谢谢你的阅读，由于作者水平有限，难免有不足之处，若读者发现问题，还请批评，在留言区留言或者私信告知，我一定会尽快修改的。若各位大佬有什么好的解法，或者有意义的解法都可以在评论区展示额，万分谢谢。 写作不易，望各位老板点点赞，加个关注!😘😘😘

目标

1. 提升代码质量
2. 统一编码规范和风格
3. 知识分享
4. 防止代码腐烂
5. 降低bug数量，提前检查出线上隐患

一、接入SonarQube，

1. SonarQube关于js部分的规则
   • rules.sonarsource.com/javascript/
2. sonar的主要作用
   • CR大部分情况只会关注提交部分代码，所以需要一个工具可以从全局检查潜在的代码缺陷，这其中SonarQube是一个不错的选择
   • sonar可以展示源码中重复严重的地方，人肉CR很难做到，除非对这个项目代码深入了解
   • sonar可以当做辅助CR工具，仅用于记录问题，不阻塞发布流程
   • 由于CR只针对于新增代码，所以不会照顾到老代码的质量。sonar可以辅助修复老项目代码的潜在缺陷，提高老项目的代码质量
3. 如何使用
   • SonarQube看板
   • 定时记录sonar的问题统计信息

二、增加CR环节

CR 本身的收益

1. 统一编码风格
2. 增加代码规范的主动性（⼼理暗示别⼈会review，所以会注意规范）
3. 代码复查，提升质量（尽早发现bug和设计中存在的问题）
4. 代码分享，知识共享（例如一些好用的库或者解决方案能通过CR在组内快速广播开）
5. 新人培养（CR流程可以作为新人培训的一部分，让新人能够迅速接入项目）

CR 规范

1. 所有需要发布⽣产的代码提交都要得到CR，至少需要指定一个人appove
2. 所有的comment都需要解决之后才可以合并到master
3. 应用可以设置 Review 建议需全部解决，对于非必需修改的建议可以进行打标或说明
4. MR的备注信息要详细说明本次MR的功能点，让reviewer能容易理解作者意图
5. reviewer不能指定自己
6. 优先指定熟悉项目的相关人员

CR 过程

1. 冒烟测试通过之后，提交MR到develop分支，并把MR链接发到群里并艾特reviewer，简要说明此次提交/修改的内容（也可通过机器人
2. 鼓励大胆comment，有不理解的地方，或者觉得不合适的地方都直接表达出来
3. 作者对每个comment也要做出反馈，无论是展开讨论还是简单的给个 OK 都是有效的反馈
4. 复杂的、大量的代码提交可以采用线下开会集体cr以提高效率
5. 作者处理完所有comment，代码也进行修改之后，要在群里艾特通知一下reviewer
6. reviewer确认没问题，点approve, 然后由作者来点merge

CR Gitlab配置

1. webhook配置
2. approvals设置

CR 准则

1. 如果变更达到可以提升系统整体代码质量的程度，就可以让它们通过，即使它们可能还不完美
2. 没有完美的代码，只有更好的代码。不要求代码实现每个细节都完美，应该做好修改时间和重要性之间的权衡
3. 遵循基础的代码规范指南，任何与规范不一致的地方都属于个人偏好，比如变量命名规范是驼峰，代码实现是下划线命名。但如果某项代码样式在指南中未提及，那就接受作者的样式

关于Comment

1. 一般预期挑的越多越好，但代码是人写的，很多情况下会让作者感到不适，所以在comment的时候也尽量注意一下措辞，有一些在规范之外的偏个人主观的东西，一般以建议的方式给出
2. 对于原则性的问题，还是要坚守质量标准的
3. 发现了一些好的代码好的设计，也请给予对方以肯定和赞美，这样有助于Review有效的进行

reviewer需要注意的点

1. 逻辑上

   • 代码设计
   • 功能实现
   • 边界条件
   • 性能隐患

2. 代码质量

   • 编码规范
   • 可读性：逻辑清晰、易理解，避免使用奇淫巧技、过度拆分
   • 复杂度：是否有重复可简化的复杂逻辑，代码复杂度是否过高，功能实现尽量要简洁

3. 参考 CR常见问题

4. 准则：代码是写给人看的，除非这份代码仅使用一次，不再需要维护。基于此准则review，只要作者提交的代码让你感觉到接手后维护困难，那都应该comment提出自己的想法

CR 心态

1. Author
   • 自己对代码的质量负责，因此应当怀着感恩的心去看待坚持认真帮你 Review 代码的同事，因为并不是所有人都有时间和精力来帮着提高代码质量
   • 不要依赖于reviewer，不要说什么"review的时候你怎么没看出来"这种话，就好像出了线上bug不要怪测试没有测出来，reviewer只是提供了一些建议，不是做质量把关的
   • 对comment不要有抵触情绪，有自己觉得不合理的地方，可以恰当的回复拒绝，或者说明一下自己这么做的原因
   • 代码好坏这件事情上本身就带有很大的个人偏好色彩在里面，每个commont都看做是一次思想交流就好了
2. Reviewer
   • 保持学习者的心态，review既是帮助他人提高代码质量的过程，也是学习他人，提高自己代码能力和沟通能力的过程，既要发现潜在质量问题，也要努力发现一些值得学习的亮点，这样对自己也是一个很大的帮助
   • 代码review的时候不用有什么心里负担，有什么疑惑的、不清楚的地方或者有什么自己的想法，可以直接提出来。有不少人 在写Comment的时候会犹豫，担心自己提出的问题或建议比较“蠢”

CR 疑问

1. 组员参与度和积极性不够高，无法有效对比小A和小B和小C在CR上的贡献
   • 激励措施，鼓励全员积极CR
   • 定期统计comment数量，挑选好的comment，和一些坏的代码展示并讨论
2. 对于一些重要且复杂的功能代码是否需要定期开会宣讲，多人review
3. 发布前发现问题多，改动太大，影响项目计划

三、CR常见问题（包含规范/风格指南）

1. CR常见问题 文档
2. CR常见问题仅供reviewer做参考, 分严重/中等/建议三个等级
   • 严重: 可能会造成bug
   • 中等: 造成后续维护困难
   • 建议: 代码有优化空间或者代码风格、格式问题，但是不影响使用和迭代
3. 根据项目紧急程度和对质量的要求，不同等级的问题可酌情处理
4. 规范要轻量，先抛出严重问题，不过分追求细枝末节，根据后续CR的情况持续增加

你身边有没有这样的人：面对堆积如山的工作、随时弹出的任务，接二连三的群@也能游刃有余地处理。回看自己，旧的任务还在做，新的任务已经从天而降，日程表上满是任务却无从下手……

明明忙个不停却成果甚微，这怎么跟想象的不一样！

• 说好的，一分耕耘一分收获呢？
• 说好的，世上无难事，只怕有心人呢？
• 说好的，只要功夫深，铁杵磨成针呢？

在一切讲究高效率的现代职场，职场人常常被要求高效率完成工作，但缺乏方法的大多数人选择了低效的加班加点。

《论语》中提到：“工欲善其事，必先利其器”。对于想要“逃离苦海”、提高效率的职场人来说，思维模型就是职场人最好的工具。掌握高效率的思维模型，不仅能快速看透工作的本质，不盲目地开展工作，还能让工作效率翻倍，逃离996、007的悲惨生活。

话说思维模型这么多，给点实际的行不行？要想成为精英打工人，我们可以从以下四方面出发，提高效率、解决问题不是梦！

问题1：摆烂现场

职场生存法则第一招：战略规划

要想为自己制定清晰的发展方向，首先要做的就是“认清自我”。SWOT模型、PEST模型、商业模式画布等思维方法能够帮助我们更客观、理性地认识自我或自己的产品。

以SWOT模型为例，它不仅能够帮助我们分析自身的优劣势以及外部的机会与威胁，还能通过几个象限的两两结合产生四个具有行为导向的问题：

• SO：利用哪些优势，抓住外部机会；
• ST：利用哪些优势，减少威胁；
• OW：利用哪些机会，改善自身的哪些劣势；
• WT：在哪些威胁中，需要改善自身的哪些劣势。

SWOT分析模型不会直接告诉你答案，但通过罗列分析后，答案早已浮出水面。同样，PEST、商业模式画布等模型都能够达到类似的效果。在了解了自己之后，我们就能依据这些因素，做出长远的个人规划。

问题2：混乱现场

职场生存法则第二招：目标管理

面对突如其来的各种需求，SMART原则、5W2H原则、MECE原则、黄金圈法则等目标管理模型，都可以实现任务、计划的稳步前进。再也不用担心面对目标无从下手了！

**如何正确制定目标？如何不让目标成为摆设？**用SMART原则举个例子：

SMART原则强调目标是具体的、可衡量的、可实现的、要与计划有相关性，还要有具体时限的。仅这些还不够，在设定目标时，还有需要注意的维度。

• 如何能让目标具体：用具体语言清楚说明要达成的行为标准，不能模棱两可、不能笼统模糊；
• 如何让目标可衡量：目标要数量化、行为化；
• 目标怎么定才能实现：在付出努力的情况下可以实现目标，禁止目标过高、他人强加 ；
• 目标如何相关：该目标与本职工作、其他目标是相关联的，不能漫无目的、胡乱跑题 ；
• 目标如何定时限：目标要有一定的时间限制，不能毫无期限、不设约束。

但目标如何拆分？目标如何管理？还需要借助 MECE原则、 5W2H原则、OKR等模型管理。

问题3：社恐现场

职场生存法则第三招：行为管理

想做又不敢做？这时候，福格行为模型的作用就凸显出来了 ！突破自己，再也不用担心自己做不了了！

福格行为模型简单来说可以总结如下，人的行为有三个触发因素：动机、能力、提示。满足这三个因素，人们才会做出行动。

福格行为模型有一个经典公式：

• M是动机，是想做某件事的欲望；
• A是能力，也就是能完成某件事的能力；
• P是触发条件，也就是提示你做某件事的信号。
• B就是行为，当三个条件同时起到作用时，才能使行为发生，从而完成一件事。

再次回看阿道的社恐现场：

这件事情的M动机（Motivation）是阿道在讲完课后专业技能会得到了巩固，不仅会克服社恐，说不定还会得到其他女同事的青睐，A能力（Ability）是阿道有很好的专业能力，而P触发条件（Prompt）则是老板让阿道给大家讲课。

由此看来，当M动机、A能力、P触发条件同时发生作用时，阿道最终会突破自己，做成自己曾经不敢的事情。

所以，在日常生活工作中，想做一件事，为什么没做呢？无非就是想而不能、能而不想、又能又想但缺乏触发条件而已。当遇到这些情况时，我们可以提高动机、提高能力、设置触发条件。这样我们就能“动起来”了。

问题4：挨批现场

职场生存法则第四招：总结复盘

复盘最大的好处就是能够帮助我们摆脱“低水平的重复”，避免365天过成一天的情况，停下来去反思，到底哪里做得好，哪里做得不好，这样才能够真正高效地提升我们某方面的水平。 因此，复盘是一个打工精英不可忽视的一项思维能力。

复盘相关的思维模型也有很多：PDCA循环模型、5W2H模型、KISS模型等。比如PDCA循环，能让我们用同样的时间做更多的事情，不断螺旋上升地循环起来。

以上这些场景是不是似曾相识？以前百思不得其解的问题好像一下子迎刃而解，就像点外卖时某团推来了大额优惠券、购物时打开了某宝。这些思维模型像存在于人们脑中的APP，遇到问题时能够帮助自己快速获取解决办法。

正如巴菲特的合伙人查理·芒格所说：“思维模型会给你提供—种视角或思维框架，从而决定你观察事物和看待世界的视角。顶级的思维模型能提高你成功的可能性，并帮你避免失败。 ”

其实在能力上，人与人并没有太大的区别，真正的区别在于思维的不同。对大多数职场人来说，只要能掌握其中的一部分的思维模型就足以解决日常职场生活中的各种问题。

今天是2023上半年的最后一天，刚好也是我在深圳一家公司的第6年，2017年6月我入职现在这家公司，到如今整好是6年。世事变迁，在这个6月回想6年前的6月，是怎样一番情愫呢。

6年前不同如今，那是一个很好找工作的年份，没有什么L型增长的经济，大环境滋润着众多中小企业如雨后春笋一般冒头，行业内大多数人都充满希望。但我在那时候找起工作来依然是十分困苦，四处奔走，因为我，遇到了各种各样的小公司。不过我发现一个特别之处，我与医疗行业十分有缘分，2016年3月就在北京朝阳三间房乡入职的一家企业也为医疗单位服务，虽然是我不大感兴趣的医疗咨询，并非医疗系统，但也引发了我对从事医疗系统服务的向往，没想到一年多之后来到深圳，真的如愿以偿了，在如今这家公司做了整整6年的HIS。

当然了即便是6年前，我也不可能根据自己的偏好去寻找工作，能找一份工作就心满意足，能找到匹配自己喜爱的业务场景，实在是一种幸运。当时我想的是，无论是什么行业只要是做erp类型的软件，都适配于我当时所掌握的一些技能。简单描述就是这类系统注重模块之间复杂的关系，并不需要担心什么高并发场景，笼统的说这也就是b2b的特性（与这些年网络上流行的技术路线b2c截然相反），我一直认为这种方式才比较锻炼复杂而抽象、又要能够连续下去的思维能力，这符合我长期对复杂系统的想象。当然了，面对这些模块比较多也比较杂乱的系统，很难快速响应其中一点，有时候定位一个问题都比较困难，这需要消耗不停的消耗耐心。即便是很有耐心的人，心力也会逐渐被消磨掉，就如同深圳的夏天，即便绿化很好，路上常常有树荫，但真要走一走，仍然是热到冒汗。

对版本控制的一些简言

6年前刚进现在的公司，最让我惊讶的是完全没有版本控制？！只通过ssh的scp文件拷贝来合并，好在我进入公司之后不久，由于开发进度的深入，就开始使用git与github private了。但通过这一短暂的时光，我深刻的体会到版本控制的重要性，表面上看，版本控制只是解决团队协作、文件合并的问题，在模块高度分离，负责明确的前期阶段，确实很难感受到版本控制的作用，只会感觉到多了一层麻烦。但他有很多的隐藏的好处，是很多人没有说明的，下面简单概括几点：

• 标记与溯源，很多时候只要通过提交信息，就能知道一块老代码的前世今生，即便信息粗糙，只要有提交的时间，就能对应上很多其他的信息，例如项目管理面板的bug列表、任务列表，亦或是聊天记录、邮件、保存的图片，通过这样的方式对应上，就能回答这样几个问题，何时新增的模块？ 新增模块的初衷可能是什么？ 修改的目的是什么？
• 上下文，一个提交除了一个代码段，还可能包括其他的文件，以及他前后的一些提交内容，这些信息是很丰富的，它们可以回答这样的问题，这段代码修改的前后都在做什么？ 这段修改是否可能是因为类似全局替换的批量处理，或是错误的格式化等意外导致的错误？
• 还原，或许你经常能听到这种抱怨，这个功能花费了好大精力快做完了，用户却要把整个功能设计推倒重来，这无疑是需要撤回一整个提交的，但你可能会想在项目的早期阶段很难发生这种事情，所以拖一段时间再加入版本控制也无所谓。但可能还有一种情况，没有外界的任何干预，一个功能卡在了最终阶段，在这个功能尚未结束的情况下，项目其他很多地方都没办法运行，此时急需进行一个阶段性的演示，这时你就不得不看看这个功能到底牵扯了哪些部分，没有版本控制的帮助，很难快速的只通过代码本身的上下文找到这些需要中止的部分。

这些虽然都是不多见的场景，但我都曾遇到过，如果没有版本控制几乎无从下手解决这些事项，版本控制是需要长期的使用才能感受到它的好处，它甚至不一定需要在有团队合作的场景下使用，即便是你一个人做的玩具项目，或是独立开发的小插件，都能避免这样的问题。但它们不是一时能体验到的，千万不要因为一些小麻烦而错过这么多解决小问题的预防性措施，用git并不一定要提交到一个centre，即便是全程都在本地使用，都能感受到许多益处，所以一个项目应该尽快从速的加入版本控制，不要等到有合并的需求才加入。

版本控制就像道路，不要觉得他只是为拼合一个集体而生，只有人多了才需要修路，其实只要是需要车辆通过，哪怕是一天只会通过一辆车，有条道路也比没有强一些。

多解决棘手问题了解一些极为罕见的意外情况

曾经看过这样的科普，硬盘会被环境噪声影响，速度会降低，寿命会减少，我想如果我遇到这样的问题一定不会想到是噪声的问题，因为环境噪声能严重到干扰硬盘设备，可能像因为吃香蕉而辐射超标一样不现实，但我却真实的遇到了一次极为罕见的意外情况：

Chrome语法检查插件Grammarly曾备受推崇，我在油管见过好多次他的广告，但我并没有尝试，没想到它却依然走入了我的视野，众所周知面对单词或语法错误的输入框，他会显示出一个类似于tooltip的悬浮块来提醒用户，但它却很神奇的影响了kendo前端框架的富文本输入框，会导致其高度发生变化，甚至遮盖下方的元素，用户完全无法正常使用，我百思不得其解，最终通过用户的截图发现这个插件，自己安装了一试，发现了问题，原来Chrome插件是真的会影响页面功能的。

遇到这样的情况当然是运气不好，但不能不有一些大胆的假象，如果完全不敢设想极端情况，只去寻找自身的常规的问题，那是很难解决问题的。

也不要害怕棘手的问题，如果能解决，自然可以向所有人分享自己的经验获得分享的快乐。就算最终解决不了，也可以成为一桩值得回味的悬案，就像一个开放式结局的小故事值得他人解读。

持续跟进社群的走向

这一点是毋容置疑的，最直接的影响就是技术路线的更新迭代，如果自己用于开发的语言、平台、框架本身已经没落，官方停止支持，那自然是要学习其他代替品的，但这个没落也分等级，像Flash、Visual Basic&VBScript、Windows Phone、.NET Framework&WinForm、Angular.js 1.x、属于已经宣告死亡的产品，是绝对要抽身的。而像PHP、CoffeeScript、Delphi、Memcached，是很多年前就被替代品取代但仍然被一些坚持的人维护着，这还是有些区别的，前者就算真的很热爱也无力挽救了，后者还可以倔强下去。但无论是哪种，都要面对下面几个问题：

• 即便是大多数人都不用了，也总会有维护性的需求在吧？
  • 并不可取，说不定某一天就要换新系统，维护性需求消失，不学点新的怎么能行呢，而且很多新技术变化并非翻天覆地，只要慢慢的接触，消除掉陌生感，就会自然的对新技术越来越感兴趣。
• 所处的公司业务体系庞大，短时间内很难更新技术，即便是要更新，到时候再学就是了。
  • 任务到面前了才开始学，时间够吗，现在很多产品开发周期越来越快，仓促之间错误一定不会少，后面还能改善这些错误呢？会不会需要很大的代价，并且引出更多的错误？技术栈一定要提前布局
• 新技术虽然用的人很多，但占用大、而且看上去只能做些简单的东西，恐怕做不了太复杂的需求，卡在替代过程中的某个位置就白费力气了。
  • 很多框架占用内存确实较大，但现在用户的设备越来越好，完全是有条件的，而且底层设计完善，占用的增加可能并非线性的，而是随着开发进度趋于平缓。如果认为做不了复杂需求，就应该看一下用例，甚至是我们所使用的工具，像掘金本身是Vue和Element-UI做的，如果你关注AI，你就会发现OpenAI官网也用了Vue，这就很给人信心。

即便许多年后也许离开了软件开发的行业，十余年后回顾这段历程，都找不到有人聊自己用过的技术，成为了一个完全的死话题，也无从向后来者介绍从前的开发经历与故事，是否会像一个孤寡老人一样无助呢，所以说为了自己的历程与故事，也要不断了解和学习新的技术，新技术的发展也并非需要天天了解，如今很多流行的技术其实也已经存在了七八年了，如果真的热爱，就值得持续的关注，并不占用多少时间，向后来者讲述技术演化的细节，每个人都会有自己独特的故事，这是其他媒体无法讲述的。

未完待续

@Contended是Java 8中引入的一个注解，用于减少多线程环境下的“伪共享”现象，以提高程序的性能。

要理解@Contended的作用，首先要了解一下什么是伪共享（False Sharing）。

1. 什么是伪共享？

伪共享（False Sharing）是多线程环境中的一种现象，涉及到CPU的缓存机制和缓存行（Cache Line）。

现代CPU中，为了提高访问效率，通常会在CPU内部设计一种快速存储区域，称为缓存（Cache）。CPU在读写主内存中的数据时，会首先查看该数据是否已经在缓存中。如果在，就直接从缓存读取，避免了访问主内存的耗时；如果不在，则从主内存读取数据并放入缓存，以便下次访问。

缓存不是直接对单个字节进行操作的，而是以块（通常称为“缓存行”）为单位操作的。一个缓存行通常包含64字节的数据。

在多线程环境下，如果两个或更多的线程在同一时刻分别修改存储在同一缓存行的不同数据，那么CPU为了保证数据一致性，会使得其他线程必须等待一个线程修改完数据并写回主内存后，才能读取或者修改这个缓存行的数据。尽管这些线程可能实际上操作的是不同的变量，但由于它们位于同一缓存行，因此它们之间就会存在不必要的数据竞争，这就是伪共享。

伪共享会降低并发程序的性能，因为它会增加缓存的同步操作和主内存的访问。解决伪共享的一种方式是尽量让经常被并发访问的变量分布在不同的缓存行中，例如，可以通过增加无关的填充数据，或者利用诸如Java的@Contended注解等工具。

2. @Contended注解是什么？

@Contended 是Java 8引入的一个注解，设计用于减少多线程环境下的伪共享（False Sharing）问题以提高程序性能。

伪共享是现代多核处理器中一个重要的性能瓶颈，它发生在多个处理器修改同一缓存行（Cache Line）中的不同数据时。缓存行是内存的基本单位，一般为64字节。当一个处理器读取主内存中的数据时，它会将整个缓存行（包含需要的数据）加载到本地缓存（L1，L2或L3缓存）中。如果另一个处理器修改了同一缓存行中的其他数据，那么原先加载到缓存中的数据就会变得无效，需要重新从主内存中加载。这会增加内存访问的延迟，降低程序性能。

@Contended注解可以标注在字段或者类上。它能使得被标注的字段在内存布局上尽可能地远离其他字段，使得被标注的字段或者类中的字段分布在不同的缓存行上，从而减少伪共享的发生。

例如，考虑以下代码：

public class Foo {

    @Contended

    long x;

    long y;

}

在这里，x被@Contended注解标记，所以x和y可能会被分布在不同的缓存行上，这样如果多个线程并发访问x和y，就不会引发伪共享。

需要注意的是，@Contended是JDK的内部API，它在Java 8中引入，但在默认情况下是不开放的，要使用需要添加JVM参数-XX:-RestrictContended，并且在编译时需要使用--add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED。此外，过度使用@Contended可能会浪费内存，因为它会导致大量的内存空间被用作填充以保持字段间的距离。所以在使用时需要谨慎权衡内存和性能的考虑。

3. 简单案例

在Java 8及以上版本中，@Contended注解是属于jdk的内部API，因此在正常情况下使用时需要打开开关-XX:-RestrictContended才能正常使用。同时需要注意的是，@Contended在JDK 9以后的版本中可能无法正常工作，因为JDK 9开始禁止使用Sun的内部API。

以下是一个@Contended注解的简单使用案例：

import jdk.internal.vm.annotation.Contended;



public class ContendedExample {



    @Contended

    volatile long value1 = 0L;



    @Contended

    volatile long value2 = 0L;



    public void increaseValue1() {

        value1++;

    }



    public void increaseValue2() {

        value2++;

    }



    public static void main(String[] args) {

        ContendedExample example = new ContendedExample();



        Thread thread1 = new Thread(() -> {

            for (int i = 0; i < 1000000; i++) {

                example.increaseValue1();

            }

        });



        Thread thread2 = new Thread(() -> {

            for (int i = 0; i < 1000000; i++) {

                example.increaseValue2();

            }

        });



        thread1.start();

        thread2.start();



        try {

            thread1.join();

            thread2.join();

        } catch (InterruptedException e) {

            e.printStackTrace();

        }



        System.out.println("value1: " + example.value1);

        System.out.println("value2: " + example.value2);

    }

}

这个例子中定义了两个使用了@Contended注解的volatile长整型字段value1和value2。两个线程分别对这两个字段进行增加操作。因为这两个字段使用了@Contended注解，所以他们会被分布在不同的缓存行中，减少了因伪共享带来的性能问题。但由于伪共享的影响在实际运行中并不容易直接观察，所以这个例子主要展示了@Contended注解的使用方式，而不是实际效果。

在前端开发中，多页应用（MPA，Multi-Page Application）和单页应用（SPA，Single-Page Application）是两种不同的应用构建方式，它们的主要区别在于如何处理页面切换。

多页应用(MPA)的主要特点是每个页面都是独立的 HTML 文件，页面的切换通过重新加载整个页面来实现。在 MPA 中，每个页面都有自己的控制器和视图，因此需要每个页面单独加载所需的资源，如样式表、脚本和图片等。这种架构通常适用于传统的 Web 应用程序，具有稳定的 URL 和 SEO 优化的能力。

单页应用（SPA）的主要特点是在一个 HTML 文件中加载应用程序的所有资源，如 JavaScript、CSS 和 HTML。在 SPA 中，所有页面切换都是在客户端完成的，不需要重新加载整个页面，而是通过 AJAX（FETCH） 和 JavaScript 动态地更新 DOM。由于只需要加载一次资源，因此可以提高应用程序的性能和响应速度。但是，这种架构可能不太适合需要 SEO 优化的网站，因为搜索引擎爬虫通常不能很好地处理 SPA。

多页应用（MPA）：

1. 区别：多页应用是由多个页面组成的应用程序，每个页面都有自己的 URL。在浏览器中导航时，页面会重新加载。每个页面的内容和数据都是从服务器请求的。

2. 优点：

• 对搜索引擎优化（SEO）更友好，因为每个页面都有一个独立的 URL。
• 适用于传统的网站架构，易于实现。
• 页面加载速度较快，因为用户只加载当前访问页面的资源。

3. 缺点：

• 页面间的跳转和响应速度较慢，因为每次跳转都需要重新加载页面。
• 前后端耦合度较高，需要处理多个页面的模板和资源。
• 前端代码复用率较低，因为每个页面可能都需要编写独立的代码。

单页应用（SPA）：

1. 区别：单页应用是只有一个页面的应用程序，其中所有内容和数据都通过 AJAX 请求从服务器获取。页面不会重新加载，而是通过 JavaScript 动态更新内容。

2. 优点：

• 用户体验更好，页面间跳转和响应速度快，类似于原生应用。
• 前后端分离，有利于团队协作和开发效率的提升。
• 前端代码复用率高，可以使用组件和模块化的方式构建应用。

3. 缺点：

• 对搜索引擎优化（SEO）不友好，因为只有一个 URL，部分搜索引擎爬虫可能无法解析 JavaScript 生成的内容。
• 首次加载时间较长，因为需要加载整个应用的资源和代码。
• 对于大型应用，维护和管理可能会变得复杂。

多页应用程序示例：电子商务网站

电子商务网站是一个典型的多页应用程序，它通常有多个页面，如首页、产品列表、产品详情、购物车、结账和付款等。

每个页面都有自己的 URL，因此用户可以通过书签或链接直接访问页面。每个页面都是独立的 HTML 文件，包含自己的控制器和视图，因此可以单独加载和缓存。

但是，每次用户访问新页面时，需要重新加载整个页面，这可能会影响页面切换的速度。

单页应用程序示例：后台管理系统

现在多数后台管理系统是用Vue、React等框架开发的单页应用。

它的所有功能都包含在一个 HTML 文件中，包括 JavaScript、CSS 和 HTML。页面切换是通过 AJAX 和 JavaScript 动态地更新 DOM 实现的，不需要重新加载整个页面。

由于只需要加载一次资源，因此页面切换速度非常快。但是，由于所有内容都在一个页面中，因此首次加载可能需要一些时间。此外，由于没有单独的页面，因此不太适合需要 SEO 优化的网站。

根据项目需求和目标，可以选择使用多页应用还是单页应用。一般来说，对于需要优化搜索引擎排名的网站，可以选择多页应用；对于需要提供流畅的用户体验和快速响应的应用，可以选择单页应用。

金三银四好像失效了

从去年下半年开始，互联网寒冬就总是萦绕在耳边。大量的公司倒闭、裁员。本以为等疫情过，等春天，等金三银四，一切又会变得好起来。但是站在这个本应该金光闪闪的时刻，却是无人问津。那个我们希望的春天似乎没有到来。

你是否也会像我一样焦虑

从业六年多，但是最近将近两年都在中间件行业，技术、履历都算不上优秀。年纪每一年都在增长，而我有随着年纪一起快速增长吗？我想是没有的。年后公司部门会议说到部门发展，领导说我们的产品越发稳定，对于一个中间件来说，客户需要的就是稳定，太多功能对于他们来说是无用的。这就意味着我们的产品到头了。但是这个产品到头我们再做什么呢？没人给我们答案。

要跳出当前的圈子吗

如果在这里看不见曙光，那么在别的地方是不是能有希望呢？春天，万物复苏，楼下如枯骨林立的一排排树干纷纷长出绿芽，迸发生机。我是否可以像沉寂了一整个冬天的枯树一样迎来自己的春天呢？目前看来也是没有的。投了很多家的简历，犹如石沉大海了无音讯。不知道对于别人来说是怎样，但是对我而言，这个三月并不是春天。

会有春天吗

去年我第一次为开源社区贡献了自己的代码，我觉得我变得更好了。疫情也在年底宣布画上句号，春天似乎真的要来了。物理上的春天是到来了，可是那个我们期盼的春天它真的会到来吗？总是在期盼等一等一切就会好转，因为除了等，我们似乎也并没有太多的选择。时代的轮盘一直运转，无数人的命运随之沉浮。我们更多的只能逆来顺受，接受它的变化，并随之拥抱它。可是未知的未来总是让人充满惶恐，看看自己再过两年就三十了，未婚、未育。在本就三十五岁魔咒的行业，总是惴惴不安。我总是思考如果被这个行业抛弃，不做开发我又能做什么呢？如果是你，这个答案会是什么呢？

这个文章应该有个结尾

文章总是需要结尾的，生活不是。生活还需要继续，每个人的答案都需要自己去寻找。在茫然无措的时刻，只能自己去寻找一些解药，在心绪不宁的时候，学习什么也是学不进去的。最近在看《我的解放日记》，能够缓解一些我的焦虑情绪。如果你也需要一些治愈系的剧，也可以去看看它。时代的浪潮推着我们往前，我们惶恐不安，手足无措，这都不是我们的错，我们只能尽力做好能做的。但是那些决定命运的瞬间几乎都是我们不能选择的。能活着就已经很不错了。

前言

在产品的运营期间，我们发现Android用户对App容量大小的敏感度明显高于iOS用户。

所以，为了提升产品在市场中竞争力，进一步提升产品的下载量，我们需要对基于Flutter开发的Android客户端进行包体优化。

经过调研，我们发现Flutter经过多年的发展后，DevTools已经完善，用较低的低成本即可满足需求。

下面我们会从分析开始，了解不同构成部分的容量分布情况。再对构成部分的特性来决定最终如何进行包体优化。

生成分析报告

首先，在build产物时，我们可以加上 --analyze-size 标识来生成分析报告。apk 和 appbundle 还可以指定产物的平台架构，如：--target-platform android-arm，分析实际机型的情况。

# 变异产物

# Specify one of android-arm, android-arm64, or android-x64 in the --target-platform flag.

flutter build apk --analyze-size --target-platform android-arm64

flutter build appbundle --analyze-size --target-platform android-arm64

apk 分析日志

app-release.apk (total compressed)                                         33 MB

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  assets/

    dexopt                                                                  1 KB

    flutter_assets                                                          5 MB

  classes.dex                                                               7 MB

  lib/

    arm64-v8a                                                              18 MB

    Dart AOT symbols accounted decompressed size                            8 MB

      package:flutter                                                       3 MB

      package:image                                                       799 KB

      dart:core                                                           325 KB

      package:xxx_xxx_flutter                                             293 KB

      dart:ui                                                             279 KB

      dart:typed_data                                                     226 KB

      dart:io                                                             212 KB

      dart:collection                                                     177 KB

      package:vector_graphics_compiler                                    170 KB

      dart:async                                                          154 KB

      package:flutter_localizations                                       129 KB

      package:flutter_spinkit                                              99 KB

      package:extended_image                                               93 KB

      dart:ffi                                                             85 KB

      package:petitparser                                                  73 KB

      dart:convert                                                         62 KB

      package:archive                                                      62 KB

      package:dio                                                          57 KB

      package:vector_math                                                  54 KB

      package:riverpod                                                     49 KB

  AndroidManifest.xml                                                       3 KB

  res/

    -j.png                                                                  4 KB

    1k.png                                                                 33 KB

    1r.png                                                                 91 KB

    2M.png                                                                  3 KB

    33.9.png                                                                2 KB

    3m.png                                                                  1 KB

    4C.png                                                                  1 KB

    4F.png                                                                 10 KB

    AQ.png                                                                 33 KB

    Bj.png                                                                 29 KB

    CG.png                                                                 23 KB

    Ch.png                                                                 98 KB

    D2.png                                                                 14 KB

    E7.png                                                                 98 KB

    EA.png                                                                 98 KB

    ER.9.png                                                                2 KB

    FM.9.png                                                                1 KB

    Fo.png                                                                 29 KB

    G1.png                                                                  2 KB

    J6.9.png                                                                2 KB

    JO.png                                                                 29 KB

    Mr.9.png                                                                1 KB

    NF.png                                                                  6 KB

    Ni.png                                                                 33 KB

    ON.png                                                                 91 KB

    Pi.9.png                                                                3 KB

    Q11.9.png                                                               3 KB

    RX.png                                                                 16 KB

    S9.png                                                                  2 KB

    SD.png                                                                  5 KB

    Tu.png                                                                 10 KB

    Vq.png                                                                  1 KB

    Vw.png                                                                 71 KB

    WR.png                                                                 30 KB

    XU.png                                                                  1 KB

    Yj.png                                                                  4 KB

    _C.png                                                                  3 KB

    _f.png                                                                  2 KB

    bI.png                                                                  3 KB

    color-v23                                                               2 KB

    color                                                                  16 KB

    dn.png                                                                  2 KB

    e1.xml                                                                  1 KB

    eB.9.png                                                                2 KB

    fM.png                                                                  5 KB

    fR.png                                                                 67 KB

    gV.9.png                                                                1 KB

    jy.png                                                                  8 KB

    nN.png                                                                  4 KB

    qt.png                                                                  2 KB

    tj.9.png                                                                2 KB

    u3.png                                                                  3 KB

    wi.9.png                                                                2 KB

    wi1.9.png                                                               1 KB

    wn.png                                                                 10 KB

    x4.png                                                                  3 KB

    yT.png                                                                  1 KB

    zT.png                                                                 91 KB

  resources.arsc                                                          926 KB

  client_analytics.proto                                                    1 KB

  dc/

    a.gz                                                                   37 KB

  kotlin/

    collections                                                             1 KB

    kotlin.kotlin_builtins                                                  5 KB

    ranges                                                                  1 KB

    reflect                                                                 1 KB

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

A summary of your APK analysis can be found at: /Users/xxx/.flutter-devtools/apk-code-size-analysis_01.json



To analyze your app size in Dart DevTools, run the following command:

dart devtools --appSizeBase=apk-code-size-analysis_01.json

appbundle 分析日志

app-release.aab (total compressed)                                         18 MB

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  BUNDLE-METADATA/

    assets.dexopt                                                           1 KB

    com.android.tools.build.libraries                                       8 KB

    com.android.tools.build.obfuscation                                   628 KB

  base/

    assets                                                                  5 MB

    dex                                                                     3 MB

    lib                                                                     8 MB

    Dart AOT symbols accounted decompressed size                            8 MB

      package:flutter                                                       3 MB

      package:image                                                       799 KB

      dart:core                                                           325 KB

      package:xxx_xxx_flutter                                             293 KB

      dart:ui                                                             279 KB

      dart:typed_data                                                     226 KB

      dart:io                                                             212 KB

      dart:collection                                                     177 KB

      package:vector_graphics_compiler                                    170 KB

      dart:async                                                          154 KB

      package:flutter_localizations                                       129 KB

      package:flutter_spinkit                                              99 KB

      package:extended_image                                               93 KB

      dart:ffi                                                             85 KB

      package:petitparser                                                  73 KB

      dart:convert                                                         62 KB

      package:archive                                                      62 KB

      package:dio                                                          57 KB

      package:vector_math                                                  54 KB

      package:riverpod                                                     49 KB

    manifest                                                                4 KB

    res                                                                     1 MB

    resources.pb                                                          292 KB

    root                                                                   51 KB

  META-INF/

    UPLOAD.SF                                                              46 KB

    UPLOAD.RSA                                                              1 KB

    MANIFEST.MF                                                            34 KB

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

A summary of your AAB analysis can be found at: /Users/xxx/.flutter-devtools/aab-code-size-analysis_01.json



To analyze your app size in Dart DevTools, run the following command:

dart devtools --appSizeBase=aab-code-size-analysis_01.json

✓ Built build/app/outputs/bundle/release/app-release.aab (18.2MB).

解读分析报告

使用DevTools解读报告

这里以 VS Code DevTools 举例（Install and run DevTools from VS Code）

• shift + cmd + p打开命令面板，再输入Open DevTools，打开面板。

• 选择App Size Tooling，打开，并选择需要分析的文件，路径在生成报告时会提供（如：/Users/xxx/.flutter-devtools/aab-code-size-analysis_01.json）

以上图为例，appbundle在未压缩的情况下， 体积为23.1MB，其中base占据了主要的容量。

base中占据主要大小的分别有lib (8MB)、assest (5MB)、dex (3MB)、res (1.2MB)。

分析内容物可以得出：

• lib，Flutter端的代码实现以及依赖库。
• assets，Flutter端使用到的资源文件。
• dex，原生端的代码实现以及依赖库。
• res，原生端使用到的资源文件。

除去这些主要的文件内容，剩余的多位配置文件，所占容量的比例也不大，可优化空间不大。

可探索的优化方向

第一步，通过优化素材可以直接减少包体内容的大小。

• 降低视频素材的分辨率和质量

• 多使用jpg、svg等高压缩率的图片素材

• 使用IconFont替换icon的图片素材

• 使用网络素材，替换本地素材，比如使用网络图片/视频，网络素材包等。

• 使用GoogleFonts替代本地Fonts。

第二步，减少不必要的代码模块。

• 检查 pubspec.yaml 并删除未使用的库/包。
• 对第三方库进行精简定制，再引入使用，删除不需要的功能。
• 使用Flutter提供的精简代码功能，对产物代码进行重定义。

下面介绍下Flutter提供的精简代码功能。

精简代码

在build产物时，添加 --obfuscate 和 --split-debug-info 来实现对代码的混淆，以及对代码的精简。

• --split-debug-info ，提取调试信息，实现精简代码，可单独使用。
• --obfuscate，开启代码混淆，提高代码反编译门槛。

# 指定android-arm64平台，在当前路径输出符号表（如`app.android-arm64.symbols`）

flutter build appbundle --target-platform android-arm64 --split-debug-info=. 

未精简的日志

flutter build appbundle --target-platform android-arm64                           



Running Gradle task 'bundleRelease'...                          

Font asset "MaterialIcons-Regular.otf" was tree-shaken, reducing it from 1645184 to 3124 bytes (99.8% reduction). Tree-shaking can be disabled by providing the --no-tree-shake-icons flag when building your app.

Running Gradle task 'bundleRelease'...                             26.7s

✓ Built build/app/outputs/bundle/release/app-release.aab (18.2MB).

精简后的日志

flutter build appbundle --target-platform android-arm64 --split-debug-info=. 



Running Gradle task 'bundleRelease'...                          

Font asset "MaterialIcons-Regular.otf" was tree-shaken, reducing it from 1645184 to 3124 bytes (99.8% reduction). Tree-shaking can be disabled by providing the --no-tree-shake-icons flag when building your app.

Running Gradle task 'bundleRelease'...                             56.6s

✓ Built build/app/outputs/bundle/release/app-release.aab (17.6MB).

开启混淆的日志

flutter build appbundle --target-platform android-arm64 --split-debug-info=.  --obfuscate



Running Gradle task 'bundleRelease'...                          

Font asset "MaterialIcons-Regular.otf" was tree-shaken, reducing it from 1645184 to 3124 bytes (99.8% reduction). Tree-shaking can be disabled by providing the --no-tree-shake-icons flag when building your app.

Running Gradle task 'bundleRelease'...                             57.5s

✓ Built build/app/outputs/bundle/release/app-release.aab (17.6MB).

读取混淆的堆栈跟踪

如需要调试被混淆的应用程序创建的堆栈跟踪，请遵循以下步骤将其解析为可读的内容：

• 找到与应用程序匹配的符号文件。例如，在 Android arm64 设备崩溃时，需要 app.android-arm64.symbols文件。

• 向 flutter symbolize 命令提供堆栈跟踪（存储在文件中）和符号文件。例如：

flutter symbolize -i <stack trace file> -d out/android/app.android-arm64.symbols

总结

在素材和代码模块的两个方向上进行包体优化，是比较容易操作，并且不会影响App稳定性的方案。

在出包的工作流中，我们会启用精简代码以及代码混淆，优化产物中代码所占的体积。

排查已经引入的依赖库，看是否存在未使用或者已经弃用的多余依赖。同时分析占容量较大的三方依赖，判断是否需要通过精简定制来降低容量。

最终是排查素材，筛选体积，对不达标的素材进行重新制作，或者寻找替代方案，比如改用网络资源。

参考

Obfuscating The Flutter App

Mastering Dart & Flutter DevTools — Part 3: App Size Tool

Reducing Flutter App Size

Using the app size tool

引子

如果设计一个客户端埋点上报库，日志的完整性、高效传输、日志的及时性都是需要考量的点。

其中“高效传输”除了采用更高效的序列化方案、压缩日志、还包含减少通信次数。若每产生一条日志就上报一次就浪费流量了。通常的做法是“批量上报”，即先将日志堆积在内存中，数量达到阈值时才触发一次上报。

批量上传 V1.0

假设埋点上报的实现如下:

object EasyLog {

    var maxSize = 50

    // 用于堆积日志的列表

    private val logs = mutableListOf<Any>()

    fun log(any: Any){

        logs.add(any)

        if(logs.size() >= maxSize) {

            uploadLogs(logs)

            logs.clear()

        }

    }

}

这样实现存在多线程安全问题，当log()被多线程并发访问时，共享变量logs并不是线程安全的。在多线程环境下调用 ArrayList.add() 会发生数据损坏，因为 ArrayList.add() 实现如下：

public boolean add(E e) {

    ensureCapacityInternal(size + 1);

    elementData[size++] = e;

    return true;

}

其中的前两句都不是线程安全的。

第一句是扩容，重新申请内存并将原数组拷贝至新数组。如果两个线程发现容量不足同时进行扩容，因为拷贝数组过程不是原子的，若被打断，则已复制的内容可能会被覆盖。

第二句是索引自增，++ 操作也不是原子的，多线程环境下可能发生现有数据被覆盖。

使用@Synchronized注解可以解决该问题：

object EasyLog {

    @Synchronized

    fun log(any: Any){}

}

相当于为整段代码套上 synchronized，同一瞬间只有一个线程可以输出日志。

性能更好的做法是使用线程安全的容器，比如ConcurrentLinkedQueue，它使用无锁机制实现线程安全的并发读写，关于它源码级别的分析可以点击面试题 | 徒手写一个非阻塞线程安全队列。

批量上传 V2.0 —— 调控日志生产消费速度

埋点上报场景中，日志的生产的速度远大于消费速度（上传是耗时操作）。这样用于堆积日志的容器可能无限增长，内存有爆炸的风险。

得使用一种机制调控日志生产和消费速度。比如，丢弃新/旧日志、暂停生产。

Kotlin 中的 Channel 提供了需要的所有功能，包括线程安全以及调控生产消费速度。

使用 Channel 重构如下：

object EasyLog {

    // 容量为50的 Channel

    private val channel = Channel<Any>(50)

    private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

    private var maxSize = 50

    private val logs = mutableListOf<Any>()

    init {

        //新起协程作为日志消费者

        scope.launch { channel.consumeEach { innerLog(it) } }

    }



    fun log(any: Any){

        // 新起协程作为日志生产者

        scope.launch { channel.send(any) }

    }

    

    private fun innerLog(any: Any){

        logs.add(any)// 堆积日志

        if(logs.size() >= maxSize) {// 日志数量超阈值后上传

            uploadLogs(logs)

            logs.clear()

        }

    }

}

每一条新日志都会转发到 Channel 上，在 Channel 另一头有一个单独的协程消费日志。

Channel 就像一个队列，生产者队尾插入，消费者队头取出。它是一个线程安全的容器，多线程并发写没有问题，而且现在只有一个消费者，所以消费日志的代码不会有线程安全问题。就好比四面八方涌入的购票者只能在一个窗口前排队。将并行问题串行化是实现线程安全的一种方法。

Channel 的构造方法可传入三个参数：

public fun <E> Channel(

    // 缓存大小

    capacity: Int = RENDEZVOUS,

    // 溢出策略

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND,

    // 如何处理未传递元素

    onUndeliveredElement: ((E) -> Unit)? = null

): Channel<E>

缓冲大小表示生产速度大于消费速度时最多缓存的元素数。当缓存满后继续产生的元素会触发溢出策略，默认策略是BufferOverflow.SUSPEND，表示挂起生产者，而不是阻塞，生产者线程可以继续运行。这是 Channel 相较于 Java 阻塞队列的优势。

批量上传 V3.0 —— 延迟去小尾巴

若客户端产生了49条日志，应用被杀，那这49条日志就丢了，因为还未达到50条上传阈值。为了确保日志的完整性，不得不对每一条日志进行持久化。然后在下一次应用启动时从磁盘读取并上传之。

这样依然不能满足日志的及时性，比如该用户一周之后才启动应用。

需要一种机制及时处理日志的小尾巴（未达批量阈值的日志）：当每一条日志到达时，开启倒计时，如果倒计时归零前无新日志请求，则将已堆积日志批量上传，否则关闭前一个倒计时，开启新的倒计时。

日志&埋点&上报（一）中使用 Handler 实现了这套机制。

这次换用协程实现：

object EasyLog {

    // 容量为50的 Channel

    private val channel = Channel<Any>(50)

    private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

    private var maxSize = 50

    private val logs = mutableListOf<Any>()

    // 冲刷job

    private var flushJob: Job? = null

    init {

        scope.launch { channel.consumeEach { innerLog(it) } }

    }



    fun log(any: Any){

        scope.launch { channel.send(any) }

    }

    

    private fun innerLog(any: Any){

        logs.add(log)

        flushJob?.cancel() // 取消上一次倒计时

        // 若日志数量达到阈值，则直接冲刷，否则延迟冲刷

        if (logs.size() >= maxSize) {

            flush()

        } else {

            flushJob = delayFlush()

        }

    }

    

    // 冲刷：上传内存中堆积的批量日志

    private fun flush() {

        uploadLogs(logs)

        logs.clear()

    }

    

    // 延迟冲刷

    private fun delayFlush() = scope.launch {

        delay(5000)// 延迟5秒，如果没有新日志产生，则冲刷

        flush()

    }

}

批量上报 V4.0 —— 并行问题串行化

上述代码存在多线程安全问题。

因为延迟冲刷时新起一个协程，导致 logs.clear() 和 logs.add() 可能并发执行。

为了复现这个多线程问题，写了一个压测demo：

// 线程安全的自增 Int 值

val count = AtomicInteger(0)

// 用于验证多线程问题的 Int 数组，初始值都是 -1

private val testArray = Array(100) { -1 }

val list = mutableListOf<Int>()

var flushJob: Job? = null



// 模拟并发生产日志

repeat(100) {

    scope.launch(Dispatchers.Default) {

        delay((50L..10_00L).random())

        channel.send(count.getAndIncrement())

    }

}



// 模拟串行消费日志

scope.launch {

    channel.consumeEach {

        delay((50L..200L).random())

        log(it)

    }

}

//模拟日志库入口方法

private fun log(value: Int) {

    list.add(value)

    flushJob?.cancel()

    if (list.size >= 5) {// 5条为一批

        flush()

    } else {

        flushJob = delayFlush()

    }

}



// 延迟冲刷

fun delayFlush() = scope.launch {

    delay(100)

    flush()

}



// 冲刷

private fun flush() {

    // 以批量日志的值赋值测试数组

    list.forEach { testArray[it.value] = it.value }

    list.clear()

}

检测方法是并发输出100条日志（内容为一个自增序号0-99），同时声明一个大小为100的数组，所有元素初始化为-1，每当日志被批量处理时将序号对应的数组索引值置为序号值。所有日志处理完毕后，检测数组中是否有-1，若有则表示复现多线程问题，检测代码如下：

val isOk = testArray.any { it == -1 }

若数组中所有的值都不是 -1，则表示 0-100 的日志都被正确地处理了。

运行 demo，isOk 是 false。。。。继续运行了 n 次，居然全都是 false。。。。开始怀疑我对多线程的认知，然后就问 ChatGPT：“理论上这段代码会发生线程安全问题，但是我的测试代码没有复现这个问题，如何才能复现？”

这段代码中的线程安全问题可能不容易复现，因为涉及到多个线程和协程同时运行，而且延迟时间是随机的。要复现这个问题，可以尝试以下方法：

1. 增加重复次数：增加 repeat(100) 中的数字，这将增加线程安全问题发生的可能性。
2. 减小延迟时间范围：将 delay((50L..10_00L).random()) 和 delay((50L..200L).random()) 中的延迟时间范围减小，以便让线程和协程更密集地运行。

尽管这些方法可以增加线程安全问题发生的可能性，但并不能保证一定能复现问题。线程安全问题的复现通常取决于操作系统、硬件和运行时环境等多种因素。

听了他的建议调整了 delay 的时间间隔，并增加次数到1000次，多线程问题浮现了：

java.util.ConcurrentModificationException

    at java.util.ArrayList$Itr.next(ArrayList.java:860)

    at test.taylor.com.taylorcode.concurrent.ConcurrentInitActivity.flush(ConcurrentInitActivity.kt:134)

    at test.taylor.com.taylorcode.concurrent.ConcurrentInitActivity.log(ConcurrentInitActivity.kt:66)

在遍历列表的同时增删列表元素就会发生这个问题。即使没有发生上述 crash，也可能会打印出 isOk=true，表示array中有元素为-1。

使用线程安全的ConcurrentLinkedQueue作为容器，仍然无法解决问题，因为它的clear()方法是弱一致性的，它需要遍历整个队列，但遍历是基于快照机制的。

最后还是运用 “将并行问题串行化” 来解决这个多线程问题：

// 单线程 Dispatcher

val logDispatcher = Executors.newFixedThreadPool(1).asCoroutineDispatcher()



// 在单线程上延迟冲刷

fun delayFlush() = scope.launch(logDispatcher) {

    delay(50)

    flush()

}



// 在单线程上消费日志

scope.launch(logDispatcher) {

    channel.consumeEach {

        delay((25L..100L).random())

        log(it)

    }

}

构建一个单独的线程，使得日志的消费和冲刷都在该线程进行。

单线程会降低性能吗? 不会，因为延迟冲刷是挂起剩余的代码，而不会阻塞线程。在单线程上延迟冲刷就好比使用 Handler.postDelay() 将冲刷逻辑排到主线程消息队列的末尾。

前言

前几天我写了一篇Vue2屎山代码汇总，收到了很多人的关注；这说明代码简洁这仍然是一个程序员的基本素养，大家也都对屎山代码非常关注；但是关注归关注，执行起来却非常困难；我明明知道这段代码的最佳实践，但是我就是不那样写，因为我有很多难言之隐；

没有严格的卡口

没有约束就没有行动，比方说eslint，eslint只能减少很少一部分屎山，而且如果不在打包机器上配置eslint的话那么eslint都可以被绕过；对我个人而言，实现一个需求，当然是写屎山代码要来的快一些，我写屎山代码能够6点准时下班，要是写最佳实践可能就要7点甚至8点下班了，没有人愿意为了代码整洁度而晚一点下班的。

没有CodeReview，CodeReview如果不通过会被打回重新修改，直到代码符合规范才能提交到git。CodeReview是一个很好地解决团队屎山代码的工具，只可惜它只是一个理想。因为实际情况是根本不可能有时间去做CodeReview，连基本需求都做不完，如果去跟老板申请一部分时间来做CodeReview，老板很有可能会对你进行灵魂三连问：你做为什么要做CodeReivew？CodeReview的价值是什么？有没有量化的指标？对于屎山代码的优化，对于开发体验、开发效率、维护成本方面，这些指标都非常难以衡量，它们对于业务没有直接的价值，只能间接地提高业务的开发效率，提高业务的稳定性，所以老板只注重结果，只需要你去实现这个需求，至于说代码怎么样他并不关心；

没有代码规约

大厂一般都有代码规约，比如：2021最新阿里代码规范（前端篇）、百度代码规范

但是在小公司，一般都没有代码规范，也就是说代码都无章可循；这种环境助长了屎山代码的增加，到头来屎山堆得非常高了，之后再想去通过重构来优化这些屎山代码，这就非常费力了；所以要想优化屎山代码光靠个人自觉，光靠多读点书那是没有用的，也执行不下去，必须在团队内形成一个规范约定，制定规约宜早不宜迟

没有思考的时间

另外一个造成屎山代码的原因就是没时间；产品经理让我半天完成一个需求，老大说某个需求很紧急，要我两天内上线；在这种极限压缩时间的需求里面，确实没有时间去思考代码怎么写，能cv尽量cv；但是一旦养成习惯，即使后面有时间也不会去动脑思考了；我个人的建议是不要总是cv，还是要留一些时间去思考代码怎么写，至少在接到需求到写代码之前哪怕留个5分钟去思考，也胜过一看到需求差不多就直接cv；

框架约束太少

越是自由度高的框架越是容易写出屎山代码，因为很多东西不约束的话，代码就会不按照既定规则去写了；比如下面这个例子： stackblitz.com/edit/vue-4a…

这个例子中父组件调用子组件，子组件又调用父组件，完全畅通无阻，完全可以不遵守单向数据流，这样的话为了省掉一部分父子组件通信的逻辑，就直接调用父组件或者子组件，当时为了完成需求我这么做了，事后我就后悔了，极易引起bug，比如说下一次这个需求要改到这一部分逻辑，我忘记了当初这个方法还被父组件调用，直接修改了它，于是就引发线上事故；最后自己绩效不好看，但是全是因为自己当初将父子组件之间耦合太深了；

自己需要明白一件事情那就是框架自由度越高，越需要注意每个api调用的方式，不能随便滥用；框架自由不自由这个我无法改变，我只能改变自己的习惯，那就是用每一个api之前思考一下这会给未来的维护带来什么困难；

没有代码质量管理平台

没有代码质量管理平台，你说我写的屎山，我还不承认，你说我代码写的不好，逻辑不清晰，我反问你有没有数据支撑

但是当代码质量成为上线前的一个关键指标时，每个人都不敢懈怠；常见的代码质量管理平台有SonarQube、DeepScan，这些工具能够继承到CI中，成为部署的一个关键环节，为代码质量保驾护航；代码的质量成为了一个量化指标，这样的话每个人的代码质量都清晰可见

最后

其实看到屎山代码，每一个人都应该感到庆幸，这说明有很多事情要做了，有很多基建可以开展起来；推动团队制定代码规约、开发eslint插件检查代码、为框架提供API约束或者部署一个代码质量管理平台，这一顿操作起来绩效想差都差不了；

我的感受

我有过，就拿前端来说，这些年前端飞速发展，各种新知识层出不穷，能学的东西真的好多好多，时不时就会感慨：“吾生也有涯，而知也无涯。 以有涯随无涯，殆已。”越学越累，没头。

更累的是你费半天劲学完的东西不久就忘了，记了笔记也没用，总有种白学了的感觉。

与同事对话

当我把这种感觉跟同事说的时候，他说：“我真的很佩服你的毅力，我做不到你那样，我只学用的到的东西，其余时间更喜欢玩玩游戏、陪陪家人。”

当我还在回味他说的这句话时，他又来了一句，狠狠地刺痛了我，他以开玩笑的语气说：“你学那么多，也没见你工资比我高哇，你。。。你好像比我低吧。。。”。我。。。好心痛。。。事实确实如此。

为何有学习焦虑

步入社会后我们的学习还是要更多的坚持学以致用，说白了，学就是为了用，而不是为了自我感动。

其实，很多人并不喜欢学习，他们之所以拼命学，是为了缓解焦虑，对抗危机，但如果你学的东西给你创造了不了任何价值，只能让你沉浸在不停地学学学，忘忘忘的痛苦中，这样只能白白蹉跎岁月。

怎么缓解

这个时候或许你可以停下来，仔细想想自己当前学的是不是能尽快用到实践中，给自己带来价值。

我感觉，你学习焦虑的原因并不是因为你掌握的知识不够，而是你掌握的知识并没有给你带来任何价值，说白了就是它无法给你带来钱！

你焦虑的是你没钱，怎么有钱？给别人创造价值呀；怎么创造价值？给别人解决问题呀；怎么解决问题？把你学的东西赶紧用出来哇。用呀，赶紧用。用不了？用不了你学它干啥？赶紧去学能用的去呀！

可能有些人会认为这么说有点太功利了，这就仁者见仁智者见智吧。

程序员更需要钝感力，别让自己太疲惫

程序员每个人都是聪明的，都是反应灵敏的。 一个同事说过这么一句话："都当的了程序员，大家都是聪明人，不过有些事不好意思点破罢了，他要是真的太过分，就真的撕破脸！"。

讲一个大多数同学都会遇到的事，之前在一家单位随着部门发展，空降了个老大哥（前端领导）。怎么说呢那个时候自己陷入了一个极其痛苦的时期，他呢每天都很闲不干活，活呢都交给我跟另外一个哥们干，而且功劳还是他的。我很不爽，当我跟我对象说这个事的时候，她说谁让人家是领导呢！！现在再总结的时候发现好像都释怀了，那个时候每天晚上失眠睡不着。

那个时候痛苦的点是：

1. 身为领导不作为。
2. 身为领导技术能力不行。
3. 把我的产出都当作自己的汇报给领导。

其实那个时候或多或少会跟他对着干，我对象也跟我聊过这个事说不要跟领导对着干，人家是领导不干活就不干活了。好像确实没落到什么好处，最后还是人家啥活不干，痛苦的还是自己。还是要学会向上管理。 

都是打工的，工期是按照人日排的，就是换个领导，怎么着你都要干活的啊！谁让你不是领导呢。 

到现在听到有吐槽领导会不干活、技术能力不行、功劳是自己的，锅都是我的一些吐槽。我都会笑笑不说什么，其实反过来想领导的位置不允许犯错，一般当领导的年龄都很大了（可能不是那么容易找到那么符合预期的工作了），假如再犯一些低级的错误，会被领导的领导不信任等。你如果能跟领导相处很好，就是犯错了锅是你的，最后你得绩效还是好的。

领导积极管理组织分享、一块搞些新奇的东西也好，不作为也好，干好自己的工作积极响应，自己擅长的领域就好好发挥，管他结果是啥呢，大家都聪明人，都看得明白的。有时间了就学点新东西，都是打工的，没必要搞得都心里不舒服，凡事多多人情世故下 哈哈 真不爽了离开就是了。

钝感力这个词其实跟我们常说的看开点、别往心里去、别想太多、不要太敏感等等有异曲同工之妙。

我们都需要顿感力，凡事别较真，在《高敏感是种天赋》，作者伊尔斯·桑德把高敏感比作是种天赋，是种天生具有责任感的人（任何事情都是会提前规划，反复练习不允许自己失误，努力会把事情做好），容易产生共鸣的人（不至于在工作中需要浪费太多时间沟通事情怎么做，我稍微一说你就能get到）等。

顿感力

渡边淳一再顿感力书中把顿感力解释为“迟钝的力量”，既从容面对生活中的挫折和伤痛。作者认为钝感是一种才能，一种能让人们的才华开花结果、发扬广大的力量。迟钝虽然给人一种木讷的负面印象，但钝感力确实我们赢得美好生活的手段和智慧

作者从以下几点讲了顿感力的优势：

1、从蚊子叮皮肤 展示钝感力的皮肤优势。

2、从同事被领导严格批评到我们都心疼他 到他第二天没有一点事 “白担心了”。

3、从文艺写作沙龙“石之会”结识优秀青年作家在第一次给主编投稿受打击就一蹶不振 最后销声匿迹 。

4、从“沾沾自喜”“得意忘形”到“再接再厉”。

5、从视觉过好，导致眼睛过累。

6、从听觉过好产生幻听。

7、从嗅觉过好到食物的怪味。

8、从味觉的过好到吃不到常人认为很好吃的辣度咸度。

9、从触觉的灵敏到身体感受到剧烈的疼痛。

10、从身体的关节疼痛能预知天气状况。

11、从“善睡的能人”到获得美丽 健康长寿。

一千个读者就有一千个哈姆雷特，每个人都会有不同的观点和感受, 也有一些书评如下：

读者一：

认为“钝感力”并不是什么新鲜玩意，中华五千年文化博大精深。用汉语来形容就是，一曰大智若愚，二曰难得糊涂。

大智若愚者，拥有大智慧，看起来却很笨拙，表面上给人一种木纳、不善言辞、反应迟钝的感觉，似乎不够机灵，实则心中有数，把握有度，巧藏于拙，遇事不急不躁，内心清楚明白，甚至洞若观火。

难得糊涂者，不是自我欺骗，不是装腔作势，而是表面上嘻嘻哈哈，看似糊涂，实则看透世事，看透人生，落得个与世无争，悠闲自得。

读者二：
我觉得挺好的。有了钝感力，生活会幸福一些。但是我觉得真正的钝感力，来自于自信，而自信来自于认知能力。如果我们的认知达到一定高度，钝感力自然形成。

读者三：
人生遇到的烦事50%可用四个字解决：关我屁事！
那么剩下的50%，亦可以用四个字解决：关你屁事！

如何培养顿感力呢？

1、迅速忘却不快之事；
2、认定目标，即使失败仍要继续挑战；
3、坦然面对流言蜚语；
4、对嫉妒与嘲讽心怀感激之心；
5、面对表扬，甘之如饴，但不得寸进尺，不得意忘形

敏感度检测

都读到这里了，可以做个敏感度检测摘录至《高敏感是种天赋》，作者伊尔斯·桑德书中。

主要用于高度敏感群体。每个问题有五个选项，每个数字代表问题的描述与自己的符合情况，0-4分别是：

• 0=完全不符合
• 1=有一点儿符合
• 2=基本符合
• 3=较为符合
• 4=非常符合

1. 美妙的音乐会让我非常激动。()
2. 我总是花比别人更多的精力去预测未来可能出现的问题，并做好充分的准备。()
3. 我很擅长发现新的可能和选择。()
4. 我很容易兴奋，总是有很多主意。()
5. 我知道生活不止我们看见和听见的一切。
6. 我的疼痛阈限很低。()
7. 我常常觉得对别人来说很容易的事情，对我来说却太沉重。()
8. 每天我需要一点时间独处。()
9. 如果我跟别人连续相处两到三个小时，中间几乎没有休息，这会让我非常疲惫。()
10. 预感到冲突即将出现，我会提前逃跑。()
11. 面对愤怒，即使不是针对我，也会让我倍感压力。()
12. 别人的痛苦会深深地影响到我。()
13. 每件事我总是竭尽全力，以避免不愉快的事情或者失误的发生。()
14. 我富有创造力。()
15. 艺术性的工作有时会给我带来深深的快乐。()
16. 面对多重任务，我的阈限比别人要低。比如，我很难做到一边上网，一边与人交谈。()
17. 我不喜欢待在刺激过多的地方，比如游乐场、大型超市、运动会。
18. 在电视上看到的暴力图片会影响我很久。□
19. 我会花比别人更多的时间来思考。□
20. 我很擅长感知动物和植物的生长状态。□
21. 身处美丽的自然环境中时，我整个身体里都洋溢着幸福。□
22. 我触须灵敏，能轻易感知到他人的心理状态。□
23. 我很容易感到愧疚。□
24. 我工作的时候，如果有人看我，我会很有压力。□
25. 我有一双敏锐的眼睛，能一眼看透别人的心理活动。□
26. 我很容易受到惊吓。□
27. 我能给别人提供倾情陪伴和有意义的友谊。□
28. 那些似乎不会打扰别人的声音却给我带来很大的困扰。□
29. 我非常直观。□
30. 我很享受独自一人的感觉。□
31. 多数时间我都是一个明智的决断者，但有时也会是冲动型，追求速度。□
32. 喧闹的声音，刺激的味道和强烈的光线都会影响到我。□
33. 我对在安静平和的环境中休息的需求比别人更大。□
34. 我很难从饥饿和寒冷中转移注意力。□
35. 我很容易哭泣。□

• 1-35题总分合计()

36. 我喜欢毫无准备地体验新事物。□
37. 当我在某些方面比别人更聪明，我会感觉很棒。□
38. 社交不会让我疲惫。如果气氛足够好，我可以一直在活动现场待下去，甚至不用独处休息。□
39. 我喜欢野外生存一类的夏令营。□
40. 我喜欢在压力下工作。□
41. 如果别人不舒服，我倾向于认为这是他们自己的错。□
42. 我总是充满能量，我的心情很少受到周围的事情的影响。□
43. 我常常是最后一个离开派对的人。□
44. 我习惯船到桥头自然直，很少担心。
45. 我喜欢跟朋友一起在度假小屋度过周末，并不需要独自待着。□
46. 朋友出其不意地拜访我，我会非常惊喜。□
47. 我能应对睡眠很少的状况。□
48. 我喜欢放鞭炮。□

• 36-48题总分合计()

第一组题目包括1-35。将你的答案加起来求和，如果所有问题你都选1，那么合计应该是35。

第二组题目包括36-48。将你的答案加起来求和，如果所有问题你都选2，那么合计应该是26。

接着，用第一组的总分，减去第二组的总分，以上述例子为例，答案应该是9。

最后的分数则是你的敏感分数，应该是介于52-140之间的某个值。得分越高，敏感程度越高。如果你的分数超过了60，那么你可能就是一个高度敏感型的人。

对测试结果进行解释常常需要谨慎。当我们用该测试结果描述一个人时，它肯定不是非常全面的。还有许多方面未被纳入考虑。并且测试结果还会受到你测试当天的心情的影响。你可以将该测试视为一个大概的参考，而不必过分去强调它。

结语

高敏感、迟钝也罢，怎么都是自己，试着跟自己和解，适当时候不要对自己要求太高，先暂时做好眼前事。 阅己、越己、悦己、乐己八个字送给各种程序员，工作只是生活一部分而已。尤其是在现在行情不好的时候，在工作的时候做好自己的本分工作，失业的也不要想太多，就当给自己放了个假期，后面有你大展拳脚的时候。加油哦

你和同事之间存在竞争关系

要不要把工作关系维护成伙伴关系

明枪暗箭防不胜防

背后捅刀子往往最不设防

大家是否在职场上交友是有也遇到过以上困扰呢？

不要在职场上交“朋友”，而是要寻找“盟友”。

这两者的区别在于应对策略：

我们会愿意为“朋友”牺牲自己的利益，像是一张年卡。

而结交“盟友”就是为了一起争取更多利益，《孔乙己》说得好：“这次是现钱，酒要好。”

所以，在职场上的“受欢迎”和社交场、朋友圈上的“受欢迎”之间有着本质的区别：

你和你的同事未必真心喜欢彼此，但在日常相处当中能够客气、友善地交往。

大家需要寻找盟友时会第一个想到你，在争斗冲突时会尽量绕开你，这就是一种非常理想的“受欢迎”状态。 不要在职场上寻求友谊和爱，这件事是不对的。

在这里给大家列出一个在职场上受欢迎的清单。

1.实力在及格线以上

这是一切的前提。职场新人要“先活下来，再做兄弟”，稳住了工作能力这个基本面，才有资格和同事谈交情。

实力不够的人会拖累整个团队、增加所有人的工作量，大家恨都来不及，绝对不会和他称兄道弟。

实力强可以表现为实力本身，在初级职位上，也可以表现为潜力。

极少数特别强大的人可能从一开始就能很好地完成工作，但是大部分人在新加入一个团队时都需要经过一段时间的磨合，在这个过程中有欠缺和不足都是正常的，你所表现出来的敬业精神、学习能力和进步的速度才是大家对你进行评价的关键。

刚入职的新人，对于要做的事情完全没有概念，但是为人极勤奋又上进，给他布置的任务会完成得特别扎实，每一天都在飞快地进步。这样的人在职场上永远都能收获一大把来自他人的橄榄枝。

2.比较高的自尊水平

高自尊的人对自己评价高，要求也高，又能够带着欣赏的眼光去看周围的人，他们不光是很好的父母、伴侣和朋友，同时也是职场上最好的结盟对象。

高自尊的人往往拥有很多优秀的品质，同时他们也能够理解“大局”，和他们合作不用在鸡毛蒜皮的细节上纠缠推诿，可以把精力全部用来开疆拓土，极大地降低团队的内耗。

如果你是一个高自尊的人，在日常生活中表现出了自律和很好的品行，就会收获高自尊同类的赞赏。有些低自尊的人可能会认为你的言行是在“装X”，别犹豫，把他们从你的结交名单当中划掉，高自尊会帮你筛掉一批最糟糕的潜在合作者。

如果你是一个部门的领导者，记得要维护高自尊的下属，他们都是潜在的优秀带队者，给他们一个位子就可以坐上来自己动，给他们一点精神鼓励和支持，他们就会变得无所不能。

即使高自尊的手下可能某些地方让你感到嫉妒或者冒犯（这是常见的，嫉妒是每个人都一定会有的情感），也绝对不要默许或者纵容低自尊的妄人跑去伤害他们，否则会伤了大家的心，事业就难以成功了。

“朕可以敲打丞相，但你算什么东西”就是对这种低自尊妄人最好的态度。

3.嘴严，可靠

在任何一个群体当中，多嘴多舌的人都不会受到尊重，而在职场上，嘴不严尤其危险。

如果你是一个爱说是非的人，围绕在你周围的只会是一帮同样没正事、低级趣味的家伙。你会被打上“不可靠”的标记，愿意和你交流的人越来越少，大家等着看你什么时候因为多嘴闯祸，而强者根本不会和你为伍。

有些同学曾经给我留言说，自己很内向，不知道如何跟同事拉近关系。内向的人最适合强调自己的“嘴严”和“可靠”，在职场上，这两项品质远比“能说会道”更让人喜欢。

4.随和，有分寸

体面的人不传闲话，也不会轻易对旁人发表议论。

“思想可以特立独行，生活方式最好随大流”，这是对自己的要求，而他人的生活方式是不是合理，不是我们能评价的。

哪怕是最亲近的人，都未必能知晓对方的全部经历和心里藏着的每一件小事。在职场上大家保持着客气有礼的距离，就更不可能了解每个人做事的出发点和逻辑，“看不懂”是正常的，但是完全没有必要“看不惯”。如果还要大发议论，把自己的“看不惯”到处传播，你的伙伴就只会越来越少。

有人说在北上广深这样的大城市，人和人之间距离遥远，缺人情味，太冷漠。

这不是冷漠，而是对“和自己不一样”的宽容，这份宽容就是我们在向文明社会靠拢的标志。

5.懂得如何打扮

还记得斯大林的故事吗？在他离开校园之后，从头到脚都经过精心设计，不是为了精神好看，而是要让自己看起来就像一位投身革命事业的进步青年。

有句老话叫做“先敬罗衣后敬人”，本意是讽刺那些根据衣饰打扮来评价一个人的现象。我们自己在做判断的时候要尽量避免受到这类偏见的影响，但是对他人可能存在的偏见一定要心中有数。人是视觉动物，穿着打扮是“人设（人物设定）”的一部分，在我们开口说话之前，衣饰鞋袜就已经传达了无数信息。

想要成为职场当中受欢迎的人，穿着打扮的风格就要和公司的调性保持一致，最安全的做法是向你的同事靠拢。

在一个风格统一的群体当中，“与众不同”这件事自带攻击性。如果在事业单位之类的上年纪同事比较多的地方上班，马卡龙色的衣服和颜色夸张的口红，最好等到下班时间再上身。

这不是压抑天性，而是自我保护和职业精神。

6.和优秀的人站在一起

在职场上，优秀的人品质都是相似的：勤奋，自律，不断精进。如果发现了这样的同事，就要尽量和他们保持良好关系。

但是，单纯的日常沟通并不足以让你们成为盟友，正式结盟往往是通过利益交换和分享：当你遇到棘手的工作任务，就可以主动邀请对方共同跟进，同时将一部分利益让出去。愉快的合作是关系飞跃的最好契机。

优秀的人能认可的，通常也都是自己的同类。如果你能获得他们的称许和背书，在同事当中的地位自然会有所提升。

7.知道如何求助

前两天有一位关系户同学留言说，自己即将去实习，因为家人的关系可以得到一些行业资深专家的指点，问自己应该如何表现，是不是不懂就要问，像“好奇宝宝”一样，对方就会觉得自己好学上进。

我告诉她说，不要上去就问，有任何疑惑都先用搜索引擎找一下答案，如果找不出来，再带着你搜到的细节去询问那些资深前辈。

互联网时代有个很大的变化，就是人们获取信息的成本大大降低。善用搜索引擎寻找答案，就能更快、更精准、更全面地找到自己想要的东西，这种方式比跑到对方工位边用嘴问效率高得多。

凡事都问，只会让人觉得你的文字阅读能力有限，同时既不把自己的时间当回事，也不尊重别人的时间。尤其对方还是行业中的专家，他们的时间一定比实习生的宝贵多了。如果网上找不到答案，再带着细节去仔细咨询，这样的请教才是高效的，才能证明你是一个“好学上进”的人。

职场不是校园，不会再有一群老师专门负责手把手地教你，不轻易占用其他同事的时间会让你成为一个自立、有分寸、受尊重的人。毕业之后，你取得进步的速度、最终的上升空间，都和使用搜索引擎寻找答案的能力呈正相关。

8.技巧地送出小恩小惠

小恩小惠带两个“小”字，并不意味着这是一种微末小技。事实上，即使是最普通的零食，只要讲究得法，都可以送到人心里。

你的同事当中有没有因为宗教信仰而忌口的情况？

甲和乙爱吃辣，丙和丁爱吃甜，是不是两种口味都来上一点？

要留心同事的自我暴露，最好是用一个小本本记下来，关键时刻可能派上大用场。大家都是成年人，不会像孩子一样轻易被小恩小惠打动，打动我们的往往是“你把我放在心上”的温暖。

9.良好的情绪管理能力

很多时候这是个隐藏特征，但是自带“一票否决”属性：平时表现得沉着稳重，周围同事们不会有特别明显的感觉，然而歇斯底里和失控只要有一次，之前苦心经营的人设就会全面崩塌。情绪不稳定的人一般没人敢惹，但是也没人会在意了：你会被视为一个“病人”，很难再有大的发展。

已经发泄出去的情绪不能收回来，这个时候不要反复陷入纠结和悔恨，待在情绪里不出来，钱花出去了就不要去想，不要去比价。

如果情绪失控了，应该立刻做到的是原谅自己，然后考虑如何不再有下一次失控。要知道大多数人一辈子都至少会换三四次工作，了不起是换个地方，重新再来。

有的人特别幸运，天生长得好看，容易被人喜欢。

如果不是让人眼前一亮的高颜值人士，就不要太心急了。

成为一个自律、行为可以预期的人，也能慢慢地被别人喜欢。

人生很长，被人喜欢这件事，我们不用赶时间。