大家好，我是「云舒编程」，今天我们来聊聊那些让我们对工作失去兴趣的原因。

一、前言

   相信很多人有过接手别人的系统，也有将自己负责的系统交接给别人的经历。既有交接出去不用在费力治理维护技术债务的喜悦，也有接手对方系统面对一系列维护问题的愁容满面。

   但是被人嫌弃的系统曾经也是「创建人」心中的白月光啊，是什么导致了「白月光」变成了「牛夫人」呢？是996，工期倒排、先上再优化，还是随时变动的需求？

   让我们来复盘系统是怎么一步一步腐化的，让我们丢失了最初的兴趣，同时总结一些经验教训以及破局之策。

二、白月光到牛夫人的经历

一般当我们设计一个系统时，总是会抱着要把该项目打造为「干净整洁」的项目的想法，

但是随着时间的推移，最后总是不可避免的变成了这样：

2.1、从0到1

   我们发现大多数人对于创建新项目总是会抱有极大的激情兴趣，会充分的考虑架构设计。但是对于接手的项目就会缺乏耐心。

   这种心理在《人月神话》一书中被说为编程职业的乐趣：

“首先，这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时 感到快乐一样，成年人喜欢创建事物，特别是自己进行设计 。我想这种 快乐是上帝创造世界的折射，一种呈现在每片独特的、崭新的树叶和雪 花上的喜悦。”

“第四，这种快乐是持续学习的快乐，它来自于这项工作的非重复特性。人们所面临的问题总有这样那样的不同，因而解决问题的人可以从 中学习新的事物，有时是实践上的，有时是理论上的，或者兼而有之。”



正是由于这样的心理，人们在面对新系统时，可以实践自身所学，主动思考如何避开曾经遇到的坑。满足了内心深处的对于创造渴望。
   当一个项目是从0到1开始设计的，并且前期是由少数「高手」成员主导开发的话，一般不会有债务体现。当然明面上没有债务，不代表没有埋下债务的种子。

2.2、抢占市场、快速迭代

   系统投入市场得到验证后，如果顺利，短期会收获大量用户。伴随着用户指数增长的同时，各种产品需求也会随着而来。一般在这个阶段将会是「工期倒排、先上再优化，需求随时变动」的高发期。

   同时由于需求的爆发，为了提高团队的交付率，在这个阶段会引入大量的“新人”。随着带来的就是新老思想的碰撞，新的同学不一定认同之前的架构设计。

   在这个阶段，如果团队存在主心骨，可以“游说”多方势力，平衡技术产品、新老开发之间的矛盾，那么在这个阶段引入的债务将会还好。但是如果团队缺乏这样的角色，就会导致公说公有理婆说婆有理，最后的结果就是架构会朝着多个方向发展，一个项目里充斥着多种不同思路的设计。有些甚至是矛盾的。如果还有【又不是不能用】的想法出现，那将是灭顶之灾。



但是在这个阶段对于参与者又是幸福的，一份【有市场、有用户、有技术、有价值】的项目，无论是对未来的晋升还是跳槽都是极大的谈资。

2.3、维护治理

   褪去了前期“曾经沧海难为水，除却巫山不是云”的热恋后，剩下的就是生活的柴米油盐。系统的最终结局也是“维护治理”。

   在这个阶段，需求的数量将大大减少，但是由于前期的“快速建设”，一个小小的需求，我们可能需要耗费数周的时间去迭代。而且系统越来越复杂，迭代越来越困难。
   
同时每天需要花费大量的时间处理客诉、定位bug，精力被完全分散。系统的设计和技术慢慢的变得僵化。并且由于用户量巨大，每次改动都要承担很大的线上风险。这样的情况对于程序员的精力、体力都是一场内耗，并且如果领导的重心也不在此项目时，更会加重这种内耗。于是该系统就会显得“人老色衰”，曾经的「白月光」也就变成了「牛夫人」。

三、牛夫人不好吗？

3.1、缺乏成就感

《人月神话》中关于程序员职业的苦恼曾说过以下几点：

随着业务趋于稳定，能够发挥创造性的地方越来越少，剩下的更多是沉闷、枯燥的维护工作。并且公司的资源会更聚焦在新业务、新方向，旧系统获得的关注更少，自然而然就缺乏成就感。也就形成了【只见新人笑，不见旧人哭】

3.2、旧系统复杂、难以维护

《A Philosophy of Software Design》一书中对复杂性进行了如下定义：“Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.”，即任何使得软件难于理解和修改的因素都是复杂性。

作者John 教授又分别从三个角度进行了解释复杂性的来源：

3.2.1、变更放大

   复杂性的第一个征兆是，看似简单的变更需要在许多不同地方进行代码修改。对于复杂的系统来说，如果代码没有聚敛，那么一次小小的需求可能会导致多处修改。同时为了保证不出故障，需要对涉及的修改点、功能点进行完整的覆盖测试。这种隐藏在背后的工作量是巨大的。

3.2.2、认知负荷

   复杂性的第二个症状是认知负荷，这是指开发人员需要多少知识才能完成一项任务。当一个系统经过多年的迭代开发，其复杂度将是指数级别的。并且会充斥这很多只有“当事人”才能理解的“离谱”功能。这就对维护者提出了极高的要求，需要掌握很多“冰山下”的知识才能做到手到擒来。而这对维护者的耐心、能力又是一次挑战。

3.2.3、未知的未知

   未知的未知是指必须修改哪些代码才能完成任务，或者说开发人员必须获得哪些信息才能成功地执行任务。这一项也是John Ousterhout教授认为复杂性中最糟糕的一个表现形式。
     这句话看起来比较抽象，如果映射到我们日常的工作中就是“我也不知道为啥这么改就好了”、“在我这是好的呀”、“刚刚还能运行啊，不知道为啥现在突然不行了”。

   这种情况就是我们不知道改动的这行代码是否能让程序正常运转，也不知道这行代码的改动是否又会引发新的问题。这时候我们发现，那些“上帝类”真的就只有上帝能拯救了。

   我曾经维护一个老系统，源码是通过文件相互传递的，没有仓库，里面的框架是自己撸的轮子，没有任何说明文档。服务部署是先在本地编译成二进制文件，然后在上传到服务器启动。每次改动上线都是就是一次生死劫，幸好没过多久，这个系统就被放弃了。

四、为何变成了牛夫人

4.1、伪敏捷

   “敏捷”已经成为了国内公司的银弹了。
   需求不做市场分析、不考虑用户体验、不做设计分析、不考虑前因后果，美其名曰“敏捷”。
   工期倒排、先上再说、明天能不能上、这个问题上了再优化，美其名曰“敏捷”。

   我曾经参与过一个项目，最开始是给了三个月的时间完成产品规划+开发，但是项目立项后领导层迟迟无法达成统一，一直持续进行了两个月的讨论后，终于确定了产品模型，进入开发。到这里留给开发的时间还剩一个月，咬咬牙也能搞定。但是开发真正进场，上报了需要开发的周期后，上面觉得太慢了，要求3周搞定，过了一天还是觉得太慢，要求2周，最后变成了要求4天搞定。遇到这种情况能怎么办，只能加人，只能怎么快怎么来。

   之前阿里程序员也开玩笑式的说出了类似的场景：“2月13号上午省领导问逍遥子全省的健康码今天上线行不行，逍遥子说可以。等消息传达到产研团队的时候已经是中午了，然后团队在下午写了第一行代码。”

4.2、人的认知局限

   《人月神话》一书中提到了一种组建团队的方式「外科手术团队」：“十个人，其中七个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性。”
   也就是团队只需要一个或者两个掌舵人，负责规划团队的方向和系统架构，其余人配合他完成任务。目前我所待过的团队也基本是按照这个模式组成的，领导会负责重要事情的决策和团队分歧时的拍板，其余人则相互配合完成目标任务。但是这样的模式也导致了一个问题：掌舵人的认知上限就决定了团队的上限，而这种认知上限天然就会导致系统架构设计存在局限性，而这种局限性又会随着“伪敏捷”放大。

4.3、人员流动

   经历过这种离职交接、活水交接的打工人应该深有体会，很多项目一旦步入这个阶段，大多数负责人就会开始放飞自我，怎么快怎么来，只想快点结束这段工作，快速奔赴下一段旅程。
   从人性的角度是很难评价这种情况的，毕竟打工人和老板天然就不是一个战线的，甚至可能是对立面的。而我们大多数人都不可能是圣人，从自身角度从发这种行为是无可厚非的。

五、如何保持白月光

   这里想首先抛个结论，系统变腐化是不可避免的。就类似人一样，随着时间的流逝，也会从以前一个连续熬夜打游戏看小说第二天依旧生龙活虎的青年变为一个在工位坐半小时都腰酸背痛，快走几步都喘的中年人。而这都来源于生活的压力、家庭的压力、工作的压力。同样的，面对业务的压力、抢占市场的压力、盈利的压力，系统也不可避免会变成“中年人”。
   就像人一样会使用护肤品、健身等手段延缓自己的衰老一样，我们也可以使用一些手段延缓系统“衰老”。
   在网上，已经有无数的文章教怎么避免代码腐化了，例如“DDD领域驱动设计”、“业务建模”、“重构”等等。
   今天我想从别的角度聊聊怎么延缓代码腐化。

5.1、避免通用

   软件领域有个特点，那就是复用。程序员们总是在思考怎么样写一段到处通用的代码，以不变应万变。特别是当国内提出中台战略后，这种情况就如脱缰的野马一般，不可阻挡。要是你做的业务、架构不带上xx中台，赋能xx，你都觉得你低人一等。
   但是其实我们大部分人做的都是业务系统，本身就是面向某块特定市场的、特定用户的。这就天然决定了其局限性。
   很多时候你会发现你用了100%的力气，设计了一个80%你认为有用的通用中台，最后只有20%产生了作用，剩下60%要么再也没有动过，要么就是被后来参与者喷的体无完肤。
   当然这里也不说，设计时就按照当前产品提出的需求设计就行，一点扩展的余地都不留，而是在「通用」与「业务需求」之间取一个平衡。而这种平衡就取决于经验了。如果你没有这方面经验，那你就去找产品要「抄袭」的是哪个产品，看看他们有哪些功能，可以预留这些功能的设计点。

5.2、Clean Code

说实话，国内的业务系统80%都没有到需要谈论架构设计的地步。能够做到以下几点已经赢麻了：

5.3、学会拒绝

   自从国内开始掀起敏捷开发的浪潮后，在项目管理方面就出现了一个莫名其妙的指标：每次迭代的需求数都有会有一个数值，而且还不能比上一次迭代的少。
   这种情况出现的原因是需求提出者无法确定这个需求可以带来多大的收益，这个收益是否满足老板的要求。那么他只能一股脑上一堆，这样即使最后效果不及预期，也可以怪罪于用户不买账。不是他不努力。
   在这种时候，就需要开发学会识别哪些是真需求，哪些是伪需求，对于伪需求要学会说不。当然说不，不是让你上来就是开喷，而是你可以提出更加合理的理由，甚至你可以提出其他需求代替伪需求。这一般需要你对这块业务有非常深入的研究，同时对系统有上帝视角。
   基本上在每个公司的迭代周期都是有时间要求的，比如我们就是两周一迭代，如果需求是你可控的，那么你就有更多的时间和心思在维护系统上，延缓他的衰老。

结尾

       分享一些我摸鱼时喜欢看的书，除了本文总是提到的《人月神话》《A Philosophy of Software Design》外，还有《黑客与画家》、《演进式架构》。有需要的可以关注 公众号「云舒编程」，回复"书籍"即可免费获取：跳转地址

本来是想通过CameraX实现同时预览多个摄像头，通过官网文档介绍，在CameraX 1.3 后通过ConcurrentCamera运行多个摄像头，但实际在小米10（Android 13）运行,报错当前设备不支持ConcurrentCamera,代码CameraProvider.availableConcurrentCameraInfos查询也是返回数量0，表示设备不支持。

请教ChatGPT回答，来进行编写，回答可以通过代码创建多个preview和requireLensFacing,但是实际运行时不可行的。程序会报下面代码问题，选择摄像头设备异常。

val cameraSelector =builder

    .requireLensFacing(CameraSelector.LENS_FACING_BACK)

    .requireLensFacing(CameraSelector.LENS_FACING_FRONT)

    .build()

因此个人下定义是在cameraX 1.3.0-alpha07前应该是不支持预览多摄像头的。如果有小伙伴验证OK，希望可以告知，多谢。

故采用Camera2来实现多摄像头同时预览。

Camera2 同时预览摄像头

记得先申请权限,以及动态申请！！

    <uses-feature android:name="android.hardware.camera.any" />

    <uses-permission android:name="android.permission.CAMERA" />

记得先申请权限,以及动态申请！！

1、判断设备是否支持摄像头

fun isSupportCamera(): Boolean {

    initCameraManager()

    return cameraManager!!.cameraIdList.isNotEmpty()

}

initCameraManager主要是初始化CameraManager对象cameraManager。我们通过cameraIdList列表是否空来判断是否有摄像头。

private fun initCameraManager() {

    if (cameraManager == null) {

        cameraManager = getApplication<Application>().getSystemService(AppCompatActivity.CAMERA_SERVICE) as 			CameraManager

    }

}

2、获取摄像头列表

我们遍历第1步获取到的摄像头ID列表，然后通过getCameraCharacteristics查询该摄像头相关的数据，封装到NCameraInfo对象中。这里我们只查询几个简单的信息。

fun getCameraListInfo() {

    

    initCameraManager()

    

    if (cameraManager.cameraIdList.isNotEmpty()) {

        for (cameraId in cameraManager.cameraIdList) {

            val cameInfo = NCameraInfo()

            val characteristics = cameraManager.getCameraCharacteristics(cameraId)

            val facing = characteristics.get(CameraCharacteristics.LENS_FACING)



            cameInfo.id = cameraId

            cameInfo.face ="${ getFaceStr(facing)},CameraId:${cameraId}"

            cameraMap[cameraId] = cameInfo

        }

        cameraInfo.value = cameraMap.values.toList()

    }

}

3、打开摄像头

打开摄像头非常简单，只需要调用openCamera函数即可，主要是stateCallback函数的实现。其中handler，是用来切换到主线程var handler = Handler(Looper.getMainLooper())。

fun openCamera(cameraId: String) {

    initCameraManager()

    cameraManager?.openCamera(cameraId, stateCallback, handler)

}

我们一起看看stateCallback函数的实现。也就是当我们打开摄像头，摄像头相关状态会通过下面三个函数进行回调，因为这里采用ViewModel方式，所以会多一份回调到Activity。不用着急，最后有完整代码。

   private val stateCallback=object : StateCallback() {

        override fun onOpened(camera: CameraDevice) {

            cameraMap[camera.id]?.apply {

                cameraDevice = camera

                state = 1

                cameraCallback?.onCameraOpen(this)

            }



        }



        override fun onDisconnected(camera: CameraDevice) {

            cameraMap[camera.id]?.apply {

                cameraDevice = camera

                state = 0

                cameraCallback?.onCameraClose(this)

            }

        }



        override fun onError(camera: CameraDevice, error: Int) {

            Log.e(TAG, "camera ${camera.id} error code:${error}")

            cameraMap[camera.id]?.apply {

                cameraDevice = camera

                state = 3

                cameraCallback?.onCameraError(this,error)

            }

        }

    }

我们查看Activity中的实现。onCameraOpen函数主要动态创建TextureView对象，添加到界面中，用于预览摄像头内容。

	 override fun onCameraOpen(camera: NCameraInfo) {

        adapter.notifyItemChanged(adapter.items.indexOf(camera))

        

        //创建TextureView

        val textureView = TextureView(this)

        textureView.id = View.generateViewId()

        camera.previewId=textureView.id

        val layoutParams = LinearLayout.LayoutParams(previewWidth, LayoutParams.MATCH_PARENT)

        viewBinding.llCameraPreview.addView(textureView, layoutParams)

		

		//textureview 与摄像头绑定

        textureView.surfaceTextureListener=object:SurfaceTextureListener{

            override fun onSurfaceTextureAvailable(surface: SurfaceTexture, width: Int, height: Int) {

               //创建Surface并用于摄像头渲染

               val surface = Surface(textureView.surfaceTexture)

               val builder = camera.cameraDevice?.createCaptureRequest(CameraDevice.TEMPLATE_PREVIEW)!!

               builder.addTarget(surface)

                

                camera.cameraDevice?.createCaptureSession(listOf(surface), object : StateCallback() {

                    override fun onConfigured(session: CameraCaptureSession) {

                        session.setRepeatingRequest(builder.build(),null,model.handler)

                    }



                    override fun onConfigureFailed(session: CameraCaptureSession) {



                    }

                }, model.handler)

            }



            override fun onSurfaceTextureSizeChanged(surface: SurfaceTexture, width: Int, height: Int) {

                Log.d(TAG,"onSurfaceTextureSizeChanged")

            }



            override fun onSurfaceTextureDestroyed(surface: SurfaceTexture): Boolean {

                Log.d(TAG,"onSurfaceTextureDestroyed")

                return true

            }



            override fun onSurfaceTextureUpdated(surface: SurfaceTexture) {

                //Log.d(TAG,"onSurfaceTextureUpdated")

            }

        }





    }



    override fun onCameraClose(camera: NCameraInfo) {

        Log.d(TAG,"onCameraClose:${camera}")

        adapter.notifyItemChanged(adapter.items.indexOf(camera))

        camera.cameraDevice?.close()

        val view=viewBinding.llCameraPreview.findViewById<TextureView>(camera.previewId)

        viewBinding.llCameraPreview.removeView(view)

    }



    override fun onCameraError(camera: NCameraInfo, error: Int) {

        Log.e(TAG,"onCameraError:${camera}，${error}")

        adapter.notifyItemChanged(adapter.items.indexOf(camera))

        camera.cameraDevice?.close()

    }

4、效果

5、小坑

• 实测在小米10手机，先开启后摄，再开启前摄，前摄无法打开=》异常。先开前摄，再开后摄正常。


• 小米11、诺基亚x7实测正常。

项目地址,点我跳战，关键类：Camera2Activity

封装v-loading指令 从此释放双手

前言

​ 大家好, 我是旋风冲锋 - 小瑜, 又到了周六~~ 没错, 是卷王们疯狂成长的日子, 今天早上突发奇想, 想去自习室体验一下敲代码的快感, 心想着卷到下午,面对着窗口看着夕阳西下的场景, 然后可以拍个照片发朋友圈装逼.

​ 但是想象很美好, 坐着地铁到了自习室, 发现大家伙都是在非常安静, 唯一能出声音的就是翻书或者写字的声音. 为了不影响其他人故意挑一个靠窗户的位置,接着对着电脑开始疯狂进攻. 我的键盘声很快传遍了整见屋子. 虽然别人没有说什么, 但是自己觉得好像是故意来捣乱的, 今天的键盘声音显得格外的大声. 没多久我知趣的溜溜球. 美团体验卷直接gg, 哈哈哈, 问题不大~

​ 言归正传, 今天给大家分享的是利用 VUE3 实现v-loading的加载效果 , 先看一下实现效果吧~

这一类效果在使用组件库, 例如饿了么中出现的频率很高, 使用方法也很简单, 给对应的结构添加上

v-loading="布尔值"即可, 是不是很好奇是怎么实现的? 那么就和旋风冲锋小瑜开始冲!

实现思路

• loading肯定也是一个组件, 其中包含加载效果还有提示文字, 并且使用的时候可以去修改文字以及开启或者关闭加载动画


• 实现的周期是在 异步开始前, 开启loading, 在异步处理[数据加载]完成后 关闭loading


• 既然是在模版中通过 v-xxx来实现的, 那么肯定就是一个自定义指令, Vue提供指令, 也就是去操作DOM[组件实例]

那么按照以上的实现思路, 一步一步去完成, 首先搭设一个Demo的模版结构和样式

搭设基本模版

利用Vue3搭设demo架子, 头部tab栏, 切换路由 , main区域的显示内容

App.vue

<script setup lang="ts"></script>



<template>

  <div class="container">

    // Tab栏

    <Tabs></Tabs> 

    // 一级路由出口

    <router-view></router-view>

  </div>

</template>



<style lang="scss">

.container {

  width: 100vw;

  height: 100vh;

  background-color: #1e1e1e;

}

</style>

router路由

 routes: [

    {

      path: '/',

      redirect: '/huawei'

    },

    {

      path: '/huawei',

      component: () => import('@/views/Huawei/index.vue'),

      meta: {

        title: '华为'

      }

    },

    {

      path: '/rongyao',

      component: () => import('@/views/Rongyao/index.vue'),

      meta: {

        title: '荣耀'

      }

    },

    {

      path: '/xiaomi',

      component: () => import('@/views/Xiaomi/index.vue'),

      meta: {

        title: '小米'

      }

    },

    {

      path: '/oppo',

      component: () => import('@/views/Oppo/index.vue'),

      meta: {

        title: 'oppo'

      }

    }

  ]

Tabs组件

<script setup lang="ts">

import { ref } from 'vue'

const tabList = ref([

  { id: 1, text: '华为', path: '/huawei' },

  { id: 2, text: '荣耀', path: '/rongyao' },

  { id: 3, text: '小米', path: '/xiaomi' },

  { id: 4, text: 'oppo', path: '/oppo' }

])

const activeIndex = ref(0)

</script>



<template>

  <div class="tabs-box">

    <router-link

      class="tab-item"

      :to="item.path"

      v-for="(item, index) in tabList"

      :key="item.id"

    >

      <span

        class="tab-link"

        :class="{ active: activeIndex === index }"

        @click="activeIndex = index"

      >

        {{ item.text }}

      </span>

    </router-link>

  </div>

</template>



<style lang="scss" scoped>

.tabs-box {

  width: 100%;

  display: flex;

  justify-content: space-around;

  .tab-item {

    padding: 10px;

    &.router-link-active {

      .tab-link {

        transition: border 0.3s;

        color: gold;

        padding-bottom: 5px;

        border-bottom: 2px solid gold;

        &.active {

          border-bottom: 2px solid gold;

          color: gold;

        }

      }

    }

  }

}

</style>

按照路由去创建4个文件夹,这里按照huawei做举例

<script setup lang="ts">

 const src = ref('')

</script>



<template>

  <div class="box" >

    <div class="img-box">

      <img :src="src" alt=""  />

    </div>

  </div>

</template>

创建Loading组件

首先按照最直接的方式, 利用 v-if 以及组件通讯, 实现组件方式的实现

注意 这里是通过 position: absolute; 通过定位的方式进行垂直水平居中, 先埋下伏笔

<script setup lang="ts">



 defineProps({

   title: {

    type: String,

     default: '正在加载中...'

   }

 })



</script>



<template>

  <div class="loading-box">

    <div class="loading-content">

      // loading 动图

      <img src="./loading.gif" />

       // 底部提示文字

      <p class="desc">{{ title }}</p>

    </div>

  </div>

</template>



<style lang="scss" scoped>

.loading-box {

  position: absolute;

  top: 50%;

  left: 50%;

  transform: translate3d(-50%, -50%, 0);

  .loading-content {

    text-align: center;

    img {

      width: 35px !important;

      height: 35px !important;

    }

    .desc {

      line-height: 20px;

      font-size: 12px;

      color: #fff;

      position: relative;

    }

  }

}

</style>

在对应组件中使用Loading组件, 利用延时器模拟异步操作

<script>

const src = ref('')

const title = ref('华为加载中...')

const showLoading = ref(true) // 控制loading的显示和隐藏



onMounted(() => {

  showLoading.value = true

 // 模拟异步请求

 window.setTimeout(() => {

   src.value =

      'https://ms.bdimg.com/pacific/0/pic/-1284887113_-1109246585.jpg?x=0&y=0&h=340&w=510&vh=340.00&vw=510.00&oh=340.00&ow=510.00'

  showLoading.value = false

  }, 1000)

})  

</script>



<template>

  <div class="box">

    <div class="img-box" v-if="!showLoading">

      <img :src="src" alt="" />

    </div>

  </div>

  <Loading v-if="showLoading"></Loading>

</template>

效果一样可以出来, 接下来就利用指令的方式来优化

V-loading 指令实现

思路:

• 在dom挂载完成后, 创建Loading实例, 需要挂载到写在具体指令结构上


• loading需要知道传递的显示文字, 这里通过指令动态的参数传递


• 当loading组件参数更新后卸载, 关闭loading

1. 使用自定义指令的参数

和内置指令类似，自定义指令的参数也可以是动态的, 下面是Vue官网的截图

在模版中使用 v-loading:[title]="showLoading"

const title = ref('华为加载中...')



<template>

  <div class="box" v-loading:[title]="showLoading">

    ...

  </div>

  <!-- <Loading v-if="showLoading"></Loading> -->

</template>

2. 利用插件注册指令

在Loading文件下创建js文件

import Loading from './index.vue' // 导入.vue文件

const loadingDirective = {

}

export default loadingDirective

components下创建index.js文件

import loading from '@/components/Loading/index'

export default {

  install: (app: App) => {

    app.directive('loading', loading)

}

入口文件中注册插件

import MyLoading from '@/components/index'

app.use(MyLoading)

3. 指令 - 节点都挂载完成后调用

• createApp 作用: 创建一个应用实例 - 创建loading


• app.mount 作用: 将应用实例挂载在一个容器元素中


• mounted 参数 el=>获取dom


• mounted 参数 binding.value => 控制开启和关闭loding 也就是 showLoading


• mounted 参数 binding.arg => loading显示的文字 [例如华为加载中...]

const loadingDirective = {

  /* 节点都挂载完成后调用 */

  mounted(el: any, binding: DirectiveBinding) {

    /* 

       value 控制开启和关闭loding

       arg loading显示的文字

    */

    const { value, arg } = binding

    /* 创建loading实例,并挂载 */

    const app = createApp(Loading)

    // 这一步 instance === loading.vue 

    // 此时就可以视同loading.vue 也就是组件实例的方法和属性

    const instance = app.mount(document.createElement('div'))

    /* 为了让elAppend获取到创建的div元素 */

    el.instance = instance

    /* 如果传入了自定义的文字就添加title */

    if (arg) {

      instance.setTitle(arg)

    }

    /* 如果showLoading为true将loading实例挂载到指令元素中 */

    if (value) {

      // 添加方法方法, 看下文

      handleAppend(el)

    }

  },

}

可以从控制台查看binding中的title以及showLoading的值

instance.setTitle(arg) 这里既然使用到了组件实例的setTitle方法, 就需要在loading中对应的方法

注意: 在vue3中需要利用defineExpose抛出事件, 让外界可以访问或使用

Loading.vue

const title = ref('')

const setTitle = (val: string) => {

  title.value = val

}

// defineProps({ 组件通讯就使用不到了, 注释即可

//   title: {

//     type: String,

//     default: '正在加载中...'

//   }

// })



defineExpose({

  setTitle,

  title

})



<template>

  <div class="loading-box">

    <div class="loading-content">

      <img src="./loading.gif" />

      <p class="desc">{{ title }}</p>

    </div>

  </div>

</template>

4. 指令 - handleAppend(el)方法实现

/* 将loading添加到指令所在DOM */

const handleAppend = (el: any) => {

   console.log(el.instance.$el, 'el.instance.$el')

  el.appendChild(el.instance.$el)

}

5. 指令 - updated() 更新后挂载还是消除的逻辑

在第四步中, loading已经可以通过指令显示了, 此时还需要让showLoading为false的时候, 或者这么理解: 当新的值不等于老值的是够关闭loading

此时就可以利用指令中updated钩子去执行这一段关闭的逻辑, 一下是官网的说明

  /* 更新后调用 */

  updated(el: any, binding: DirectiveBinding) {

    const { value, oldValue, arg } = binding

    if (value !== oldValue) {

      /* 更新标题 */

      if (arg) {

        el.instance.setTitle(arg)

      }

      // 是显示吗? 如果是就添加 : 如果不是就删除

      value ? handleAppend(el) : c(el)

    }

  }

6. 指令 - handleRemove()方法实现

/* 将loading在DOM中移除 */

const handleRemove = (el: any) => {

  removeClass(el, relative as any)

  el.removeChild(el.instance.$el)

}

此时基本已经完成了需求, 但是上文我提到了坑点, 原因是loading是通过绝对定位的方式进行水平居中, 那么比如我要在图片中显示loading呢? 我们来实现下这个坑点

7. 坑点的说明

<template>

  <div class="box" //关闭 v-loading:[title]="showLoading">

    <div class="img-box" v-loading:[title]="showLoading">

      <img :src="src" alt="" />

    </div>

  </div>

  <!-- <Loading v-if="true"></Loading> -->

</template>

很明显发现, 执行现在图片这个盒子上, 并没有水平居中, 审查元素其实也很明显, css样式中是根据子绝父相, 但是此时大盒子并没有提供相对定位, 自然就无法水平居中

那么如何修改呢? 其实只要给绑定指令的盒子添加position: relative;属性即可, 当然absolute或者fixed效果一样可以居中

问题已找到了, 那么在appendChild时判断当前是否存在relative | absolute | fixed 的其中一个, 如果没有就需要classList.add进行添加, 同时在removeChild删除添加的relative | absolute | fixed 即可

8. 完善坑点, 实现水平居中

getComputedStyle() 在MDN上的说明:

方法返回一个对象，该对象在应用活动样式表并解析这些值可能包含的任何基本计算后报告元素的所有 CSS 属性的值。私有的 CSS 属性值可以通过对象提供的 API 或通过简单地使用 CSS 属性名称进行索引来访问。

/* 将loading添加到指令所在DOM */

const relative = 'relative'

const handleAppend = (el: any) => {

  const style = getComputedStyle(el) 

  if (!['absolute', 'relative', 'fixed'].includes(style.position)) {

    addClass(el, relative as any)

  }



  el.appendChild(el.instance.$el)

}

// 添加relative

const addClass = (el: any, className: string) => {

  if (!el.classList.contains(className)) {

    el.classList.add(className)

  }

}

// 删除relative

const removeClass = (el: any, className: string) => {

  el.classList.remove(className)

}

结尾

夜深人静又是卷到凌晨1点, 只管努力, 其他交给天意~ 旋风冲锋手动撒花 ✿✿ヽ(°▽°)ノ✿

demo地址: gitee.com/tcwty123/v-…

因为最近工作项目中用到了电子秤，需要对接电子秤设备。以前也没有对接过这种设备，当时也是一脸懵逼，脑袋空空。后来就去网上搜了一下前端怎么对接，然后就发现了SerialPort串口。

Serialport

官网地址：serialport.io/

Github：github.com/serialport/…

官方描述：使用 JavaScript 访问串行端口。Linux、OSX 和 Windows。

SerialPort是什么？

SerialPort 是一个用于在 Node.js 环境中进行串口通信的库。它允许开发者通过 JavaScript 或 TypeScript 代码与计算机上的串口设备进行交互。SerialPort 库提供了丰富的 API，使得在串口通信中能够方便地进行设置、监听和发送数据。

一般我们的设备(电子秤/扫码枪)会有一根线插入到电脑的USB口或者其他口，电脑上的这些插口就是叫串口。设备上的数据会通过这根线传输到电脑里面，比如电子秤传到电脑里的就是重量数值。那么我们前端怎么接收解析到这些数据的呢？SerialPort的作用就是用来帮我们接收设备传输过来的数据，也可以向设备发送数据。

简单概括一下：SerialPort就是我们前端和设备之间的翻译官，可以接收设备传输过来的数据，也可以向设备发送数据。

SerialPort怎么用？

SerialPort可以在Node项目中使用，也可以在Electron项目中使用，我们一般都是用在Electron项目中，接下来讲一下在Electron项目中SerialPort怎么下载和引入

1、创建Electron项目

mkdir my-electron-app && cd my-electron-app

npm init -y

npm i --save-dev electron

网上有很多Electron教程，这里不再详细说了

在package.json中看一下自己的Electron的版本，下一步会用到。

2、下载SerialPort

这里先看一下自己使用的Electron对应的Node版本是什么，打开下面electron官网看表格中的Node那一列

Electron发行时间表：http://www.electronjs.org/zh/docs/lat…

如果你Electron对应的Node版本高于v12.0.0，直接下载就行

npm install serialport

如果你Electron对应的Node版本低于或等于v12.0.0，请用对应的Node版本对应下面的serialport版本下载

serialport.io/docs/next/g…

• 对于 Node.js 版本0.10和0.12，最后一个正常运行的版本是serialport@4。


• 对于 Node.js 版本4.0，最后一个正常运行的版本是serialport@6.


• 对于 Node.js 版本8.0，最后一个正常运行的版本是serialport@8.


• 对于 Node.js 版本10.0，最后一个正常运行的版本是serialport@9.


• 对于 Node.js 版本12.0，最后一个正常运行的版本是serialport@10.

我项目的Electron版本是11.5.0，对应的Node版本号是12.0，对应的serialport版本号是serialport@10.0.0

3、编译Serialport

• 安装node-gyp 用于调用其他语言编写的程序（如果已安装过请忽略这一步）
  
  

  npm install -g node-gyp
  
  

  
  

• 进入@serialport目录
  
  

  cd ./node_modules/@serialport/bindings
  
  

  
  


• 进行编译，target后面换成当前Electron的版本号
  
  

  node-gyp rebuild --target=11.5.0
  
  

  
  

如果编译的时候报错了就将自己电脑的Node版本切换成当前Electron对应的版本号再编译一次

查看Electron对应Node版本号：http://www.electronjs.org/zh/docs/lat…

编译成功以后就可以在代码里使用Serialport了

4、使用Serialport

serialport官网使用教程：serialport.io/docs/next/g…

4.1、引入Serialport

const { SerialPort } = require('serialport')

// or

import { SerialPort } from 'serialport'

4.2、创建串口（重点！）

创建串口有两种写法，新版本是这样写法new SerialPort(params, callback)

const port = new SerialPort({

  path: 'COM1',  // 串口号

  baudRate: 9600, // 波特率

  autoOpen: true,  // 是否自动打开端口

}, function (err) {

  if (err) {

    return console.log('打开失败: ', err.message)

  }

  console.log('打开成功')

})

旧版本是下面这样的写法new Serialport(path, params, callback)，我用的是serialport@10.0.0版本就是这样的写法

const port = new Serialport('COM1', {

  baudRate: 9600,

  autoOpen: true,  // 是否自动打开端口

}, function (err) {

  if (err) {

    return console.log('打开失败: ', err.message)

  }

  console.log('打开成功')

})

创建串口的时候需要传入两个重要的参数是path和baudRate，path是串口号，baudRate是波特率。最后一个参数是回调函数

不知道怎么查看串口号和波特率看这篇文章

如何查看串口号和波特率？

4.3、手动打开串口

如果autoOpen参数是false，需要使用port.open()方法手动打开

const port = new SerialPort({

  path: 'COM1',  // 串口号

  baudRate: 9600, // 波特率

  autoOpen: false,  // 是否自动打开端口, 默认true

})

// autoOpen参数是false，需要使用port.open()方法手动打开

port.open(function (err) {

  if (err) {

    return console.log('打开失败', err.message)

  }

  console.log('打开成功')

})

4.4、接收数据（重点！）

接收到的data是一个Buffer，需要转换为字符串进行查看

port.on('data', function (data) {

  // 接收到的data是一个Buffer，需要转换为字符串进行查看

  console.log('Data:', data.toString('utf-8'))

})

接收过来的data就是设备传输过来的数据，转换后的字符串就是我们需要的数据，字符串里面可能有多个数据，我们把自己需要的数据截取出来就可以了

假设通过电子秤设备获取到的数据就是"205 000 000"，中间是四个空格分割的，第一个数字205就是获取的重量，需要把这个重量截取出来。下面是我的示例代码

port.on('data', function (data) {

  try {

      // 获取的data是一个Buffer

      // 1.将 Buffer 转换为字符串 dataString.toString('utf-8')

      let weight = data.toString('utf-8')

      // 2.将字符串分割转换成数组，取数组的第一个值.split('    ')[0]

      weight = weight.split('    ')[0]

      // 3.将取的值 去掉前后空格

      weight = weight.trim()

      // 4.最后转换成数字,获取到的数字就是重量

      weight = Number(weight)

      console.log('获取到重量：'+ weight);

  } catch (err) {

    console.error(`

      重量获取报错：${err}

      获取到的Buffer: ${data}

      Buffer转换后的值：${data.toString('utf-8')}

    `);

  }

})

4.5、写入数据

port.write('Hi Mom!')

port.write(Buffer.from('Hi Mom!'))

4.6、实时获取(监听)所有串口

const { SerialPort } = require('serialport')

​

SerialPort.list().then((ports, err) => {

    // 串口列表

    console.log('获取所有串口列表', ports);

})

更多内容

serialport官网教程：serialport.io/docs/next/g…

问题背景

最近在群里看到群友在讨论app保活的问题，回想之前做应用(运动类)开发时也遇到过类似的需求，于是便又来了兴趣，果断加入其中，和群友展开了激烈的讨论

不少群友的想法和我当初的想法一样，这特么保活不是看系统的心情么，系统想让谁活谁才能活，作为app开发者，根本无能为力，可真的是这样的吗？

保活方案

首先，我整理了从古到今，app开发者所使用过的以及当前还在使用的保活方式，主要思路有两个：保活和复活

保活的方案有：

• 1像素惨案


• 后台无声音乐


• 前台service


• 心跳机制


• socket长连接


• 无障碍服务


• ......

复活的方案有：

• 双进程守护(java层和native层)


• JobScheduler定时任务


• 推送/相互唤醒


• ......

不难看出，app开发者为了能让自己的应用多存活一会儿，可谓是绞尽脑汁，但即使这样，随着Android系统升级，尤其是进入8.0之后，系统对应用的限制越来越高，传统的保活方式已经不生效，这让Android开发者手足无措，于是乎，出现了一种比较和谐的保活方式：

• 引导用户开启手机白名单

这也是目前绝大多数应用所采用的的方式，相对于传统黑科技而言，此方式显得不那么流氓，比较容易被用户所接受。

但跟微信这样的国民级应用比起来，保活效果还是差了一大截，那么微信是怎么实现保活的呢？或者回到我们开头的问题，应用的生死真的只能靠系统调度吗？开发者能否干预控制呢？

进程调度原则

解开这个疑问之前，我们需要了解一下Android系统进程调度原则，主要介绍framework中承载四大组件的进程是如何根据组件状态而动态调节自身状态的。进程有两个比较重要的状态值：

• oom_adj，定义在frameworks/base/services/core/java/com/android/server/am/ProcessList.java当中


• procState，定义在frameworks/base/core/java/android/app/ActivityManager.java当中

OOM_ADJ

以Android10的源码为例，oom_adj划分为20级，取值范围[-10000,1001]，Android6.0以前的取值范围是[-17,16]

• oom_adj值越大，优先级越低


• oom_adj<0的进程都是系统进程。

public final class ProcessList {

    static final String TAG = TAG_WITH_CLASS_NAME ? "ProcessList" : TAG_AM;



    // The minimum time we allow between crashes, for us to consider this

    // application to be bad and stop and its services and reject broadcasts.

    static final int MIN_CRASH_INTERVAL = 60 * 1000;



    // OOM adjustments for processes in various states:



    // Uninitialized value for any major or minor adj fields

    static final int INVALID_ADJ = -10000;



    // Adjustment used in certain places where we don't know it yet.

    // (Generally this is something that is going to be cached, but we

    // don't know the exact value in the cached range to assign yet.)

    static final int UNKNOWN_ADJ = 1001;



    // This is a process only hosting activities that are not visible,

    // so it can be killed without any disruption.

    static final int CACHED_APP_MAX_ADJ = 999;

    static final int CACHED_APP_MIN_ADJ = 900;



    // This is the oom_adj level that we allow to die first. This cannot be equal to

    // CACHED_APP_MAX_ADJ unless processes are actively being assigned an oom_score_adj of

    // CACHED_APP_MAX_ADJ.

    static final int CACHED_APP_LMK_FIRST_ADJ = 950;



    // Number of levels we have available for different service connection group importance

    // levels.

    static final int CACHED_APP_IMPORTANCE_LEVELS = 5;



    // The B list of SERVICE_ADJ -- these are the old and decrepit

    // services that aren't as shiny and interesting as the ones in the A list.

    static final int SERVICE_B_ADJ = 800;



    // This is the process of the previous application that the user was in.

    // This process is kept above other things, because it is very common to

    // switch back to the previous app.  This is important both for recent

    // task switch (toggling between the two top recent apps) as well as normal

    // UI flow such as clicking on a URI in the e-mail app to view in the browser,

    // and then pressing back to return to e-mail.

    static final int PREVIOUS_APP_ADJ = 700;



    // This is a process holding the home application -- we want to try

    // avoiding killing it, even if it would normally be in the background,

    // because the user interacts with it so much.

    static final int HOME_APP_ADJ = 600;



    // This is a process holding an application service -- killing it will not

    // have much of an impact as far as the user is concerned.

    static final int SERVICE_ADJ = 500;



    // This is a process with a heavy-weight application.  It is in the

    // background, but we want to try to avoid killing it.  Value set in

    // system/rootdir/init.rc on startup.

    static final int HEAVY_WEIGHT_APP_ADJ = 400;



    // This is a process currently hosting a backup operation.  Killing it

    // is not entirely fatal but is generally a bad idea.

    static final int BACKUP_APP_ADJ = 300;



    // This is a process bound by the system (or other app) that's more important than services but

    // not so perceptible that it affects the user immediately if killed.

    static final int PERCEPTIBLE_LOW_APP_ADJ = 250;



    // This is a process only hosting components that are perceptible to the

    // user, and we really want to avoid killing them, but they are not

    // immediately visible. An example is background music playback.

    static final int PERCEPTIBLE_APP_ADJ = 200;



    // This is a process only hosting activities that are visible to the

    // user, so we'd prefer they don't disappear.

    static final int VISIBLE_APP_ADJ = 100;

    static final int VISIBLE_APP_LAYER_MAX = PERCEPTIBLE_APP_ADJ - VISIBLE_APP_ADJ - 1;



    // This is a process that was recently TOP and moved to FGS. Continue to treat it almost

    // like a foreground app for a while.

    // @see TOP_TO_FGS_GRACE_PERIOD

    static final int PERCEPTIBLE_RECENT_FOREGROUND_APP_ADJ = 50;



    // This is the process running the current foreground app.  We'd really

    // rather not kill it!

    static final int FOREGROUND_APP_ADJ = 0;



    // This is a process that the system or a persistent process has bound to,

    // and indicated it is important.

    static final int PERSISTENT_SERVICE_ADJ = -700;



    // This is a system persistent process, such as telephony.  Definitely

    // don't want to kill it, but doing so is not completely fatal.

    static final int PERSISTENT_PROC_ADJ = -800;



    // The system process runs at the default adjustment.

    static final int SYSTEM_ADJ = -900;



    // Special code for native processes that are not being managed by the system (so

    // don't have an oom adj assigned by the system).

    static final int NATIVE_ADJ = -1000;



    // Memory pages are 4K.

    static final int PAGE_SIZE = 4 * 1024;

    

    //省略部分代码

}

可以通过cat /proc/进程id/oom_score_adj查看目标进程的oom_adj值，例如我们查看电话的adj

值为935，处于不可见进程的范围内，当我启动电话app，再次查看

此时adj值为0，也就是正在与用户交互的进程

ProcessState

process_state划分为23类，取值范围为[-1,21]

@SystemService(Context.ACTIVITY_SERVICE)

public class ActivityManager {

    //省略部分代码

    /** @hide Not a real process state. */

    public static final int PROCESS_STATE_UNKNOWN = -1;



    /** @hide Process is a persistent system process. */

    public static final int PROCESS_STATE_PERSISTENT = 0;



    /** @hide Process is a persistent system process and is doing UI. */

    public static final int PROCESS_STATE_PERSISTENT_UI = 1;



    /** @hide Process is hosting the current top activities.  Note that this covers

     * all activities that are visible to the user. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_TOP = 2;



    /** @hide Process is hosting a foreground service with location type. */

    public static final int PROCESS_STATE_FOREGROUND_SERVICE_LOCATION = 3;



    /** @hide Process is bound to a TOP app. This is ranked below SERVICE_LOCATION so that

     * it doesn't get the capability of location access while-in-use. */

    public static final int PROCESS_STATE_BOUND_TOP = 4;



    /** @hide Process is hosting a foreground service. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_FOREGROUND_SERVICE = 5;



    /** @hide Process is hosting a foreground service due to a system binding. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_BOUND_FOREGROUND_SERVICE = 6;



    /** @hide Process is important to the user, and something they are aware of. */

    public static final int PROCESS_STATE_IMPORTANT_FOREGROUND = 7;



    /** @hide Process is important to the user, but not something they are aware of. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_IMPORTANT_BACKGROUND = 8;



    /** @hide Process is in the background transient so we will try to keep running. */

    public static final int PROCESS_STATE_TRANSIENT_BACKGROUND = 9;



    /** @hide Process is in the background running a backup/restore operation. */

    public static final int PROCESS_STATE_BACKUP = 10;



    /** @hide Process is in the background running a service.  Unlike oom_adj, this level

     * is used for both the normal running in background state and the executing

     * operations state. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_SERVICE = 11;



    /** @hide Process is in the background running a receiver.   Note that from the

     * perspective of oom_adj, receivers run at a higher foreground level, but for our

     * prioritization here that is not necessary and putting them below services means

     * many fewer changes in some process states as they receive broadcasts. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_RECEIVER = 12;



    /** @hide Same as {@link #PROCESS_STATE_TOP} but while device is sleeping. */

    public static final int PROCESS_STATE_TOP_SLEEPING = 13;



    /** @hide Process is in the background, but it can't restore its state so we want

     * to try to avoid killing it. */

    public static final int PROCESS_STATE_HEAVY_WEIGHT = 14;



    /** @hide Process is in the background but hosts the home activity. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_HOME = 15;



    /** @hide Process is in the background but hosts the last shown activity. */

    public static final int PROCESS_STATE_LAST_ACTIVITY = 16;



    /** @hide Process is being cached for later use and contains activities. */

    @UnsupportedAppUsage

    public static final int PROCESS_STATE_CACHED_ACTIVITY = 17;



    /** @hide Process is being cached for later use and is a client of another cached

     * process that contains activities. */

    public static final int PROCESS_STATE_CACHED_ACTIVITY_CLIENT = 18;



    /** @hide Process is being cached for later use and has an activity that corresponds

     * to an existing recent task. */

    public static final int PROCESS_STATE_CACHED_RECENT = 19;



    /** @hide Process is being cached for later use and is empty. */

    public static final int PROCESS_STATE_CACHED_EMPTY = 20;



    /** @hide Process does not exist. */

    public static final int PROCESS_STATE_NONEXISTENT = 21;

    //省略部分代码

}

进程调度算法

在frameworks/base/services/core/java/com/android/server/am/OomAdjuster.java中，有三个核心方法用于计算和更新进程的oom_adj值

• updateOomAdjLocked()：更新adj，当目标进程为空，或者被杀则返回false，否则返回true。


• computeOomAdjLocked()：计算adj，计算成功返回true，否则返回false。


• applyOomAdjLocked()：应用adj，当需要杀掉目标进程则返回false，否则返回true。

adj更新时机

也就是updateOomAdjLocked()被调用的时机。通俗的说，只要四大组件被创建或者状态发生变化，或者当前进程绑定了其他进程，都会触发adj更新，具体可在源码中查看此方法被调用的地方，比较多，这里就不列举了

adj的计算过程

computeOomAdjLocked()计算过程相当复杂，将近1000行代码，这里就不贴了，有兴趣可自行查看，总体思路就是根据当前进程的状态，设置对应的adj值，因为状态值很多，所以会有很多个if来判断每个状态是否符合，最终计算出当前进程属于哪种状态。

adj的应用

计算得出的adj值将发送给lowmemorykiller(简称lmk)，由lmk来决定进程的生死，不同的厂商，lmk的算法略有不同，下面是源码中对lmk的介绍

/* drivers/misc/lowmemorykiller.c

 *

 * The lowmemorykiller driver lets user-space specify a set of memory thresholds

 * where processes with a range of oom_score_adj values will get killed. Specify

 * the minimum oom_score_adj values in

 * /sys/module/lowmemorykiller/parameters/adj and the number of free pages in

 * /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma

 * separated list of numbers in ascending order.

 *

 * For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and

 * "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill

 * processes with a oom_score_adj value of 8 or higher when the free memory

 * drops below 4096 pages and kill processes with a oom_score_adj value of 0 or

 * higher when the free memory drops below 1024 pages.

 *

 * The driver considers memory used for caches to be free, but if a large

 * percentage of the cached memory is locked this can be very inaccurate

 * and processes may not get killed until the normal oom killer is triggered.

 *

 * Copyright (C) 2007-2008 Google, Inc.

 *

 * This software is licensed under the terms of the GNU General Public

 * License version 2, as published by the Free Software Foundation, and

 * may be copied, distributed, and modified under those terms.

 *

 * This program is distributed in the hope that it will be useful,

 * but WITHOUT ANY WARRANTY; without even the implied warranty of

 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 * GNU General Public License for more details.

 *

 */

保活核心思路

根据上面的Android进程调度原则得知，我们需要尽可能降低app进程的adj值，从而减少被lmk杀掉的可能性，而我们传统的保活方式最终目的也是降低adj值。而根据adj等级分类可以看出，通过应用层的方式最多能将adj降到100~200之间，我分别测试了微信、支付宝、酷狗音乐，启动后返回桌面并息屏，测试结果如下

微信测试结果：

微信创建了两个进程，查看这两个进程的adj值均为100，对应为adj等级表中的VISIBLE_APP_ADJ，此结果为测试机上微信未登录状态测试结果，当换成我的小米8测试后发现，登录状态下的微信有三个进程在运行

后查阅资料得知，进程名为com.tencent.soter.soterserver的进程是微信指纹支付，此进程的adj值居然为-800，上面我们说过，adj小于0的进程为系统进程，那么微信是如何做到创建一个系统进程的，我和我的小伙伴都惊呆了o.o，为此，我对比了一下支付宝的测试结果

支付宝测试结果：

支付宝创建了六个进程，查看这六个进程的adj值，除了一个为915，其余均为0，怎么肥事，0就意味着正在与用户交互的前台进程啊，我的世界要崩塌了，只有一种可能，支付宝通过未知的黑科技降低了adj值。

酷狗测试结果：

酷狗创建了两个进程，查看这两个进程的adj值分别为700、200，对应为adj等级表中的PREVIOUS_APP_ADJ和PERCEPTIBLE_APP_ADJ，还好，这个在意料之中。

测试思考

通过上面三个app的测试结果可以看出，微信和支付宝一定是使用了某种保活手段，让自身的adj降到最低，尤其是微信，居然可以创建系统进程，简直太逆天了，这是应用层绝对做不到的，一定是在native层完成的，但具体什么黑科技就不得而知了，毕竟反编译技术不是我的强项。

正当我郁郁寡欢之时，我想起了前两天看过的一篇文章《当 App 有了系统权限，真的可以为所欲为？》，文章讲述了第三方App如何利用CVE漏洞获取到系统权限，然后神不知鬼不觉的干一些匪夷所思的事儿，这让我茅塞顿开，或许这些大厂的app就是利用了系统漏洞来保活的，不然真的就说不通了，既然都能获取到系统权限了，那创建个系统进程不是分分钟的事儿吗，还需要啥厂商白名单。

总结

进程保活是一把双刃剑，增加app存活时间的同时牺牲的是用户手机的电量，内存，cpu等资源，甚至还有用户的忍耐度，作为开发者一定要合理取舍，不要为了保活而保活，即使需要保活，也尽量采用白色保活手段，别让用户手机变板砖，然后再来哭爹骂娘。

参考资料：

探讨Android6.0及以上系统APP常驻内存(保活)实现-争宠篇

探讨Android6.0及以上系统APP常驻内存(保活)实现-复活篇

探讨一种新型的双进程守护应用保活

史上最强Android保活思路：深入剖析腾讯TIM的进程永生技术

当 App 有了系统权限，真的可以为所欲为？

「 深蓝洞察 」2022 年度最“不可赦”漏洞

前言

大家好，我是未央歌，一个默默无闻的移动开发搬砖者~

本文针对 Android 各种标识符做了统一收集，方便大家比对，以供选择适合大家的唯一标识符。

标识符

IMEI

• 从 Android 6.0 开始获取 IMEI 需要权限，并且从 Android 10+ 开始官方取消了获取 IMEI 的 API，无法获取到 IMEI 了

fun getIMEI(context: Context): String {

    val telephonyManager = context

        .getSystemService(TELEPHONY_SERVICE) as TelephonyManager

    return telephonyManager.deviceId

}

Android ID（SSAID）

• 无需任何权限


• 卸载安装不会改变，除非刷机或重置系统


• Android 8.0 之后签名不同的 APP 获取的 Android ID 是不一样的


• 部分设备由于制造商错误实现，导致多台设备会返回相同的 Android ID


• 可能为空

fun getAndroidID(context: Context): String {

    return Settings.System.getString(context.contentResolver,Settings.Secure.ANDROID_ID)

}

MAC 地址

• 需要申请权限，Android 12 之后 BluetoothAdapter.getDefaultAdapter().getAddress()需要动态申请 android.permission.BLUETOOTH_CONNECT 权限


• MAC 地址具有全局唯一性，无法由用户重置，在恢复出厂设置后也不会变化


• 搭载 Android 10+ 的设备会报告不是设备所有者应用的所有应用的随机化 MAC 地址


• 在 Android 6.0 到 Android 9 中，本地设备 MAC 地址（如 WLAN 和蓝牙）无法通过第三方 API 使用 ， 会返回 02:00:00:00:00:00，且需要 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION 权限

Widevine ID

• DRM 数字版权管理 ID ，访问此 ID 无需任何权限


• 对于搭载 Android 8.0 的设备，Widevine 客户端 ID 将为每个应用软件包名称和网络源（对于网络浏览器）返回一个不同的值


• 可能为空

fun getWidevineID(): String {

    try {

        val WIDEVINE_UUID = UUID(-0x121074568629b532L, -0x5c37d8232ae2de13L)

        val mediaDrm = MediaDrm(WIDEVINE_UUID)

        val widevineId = mediaDrm.getPropertyByteArray(MediaDrm.PROPERTY_DEVICE_UNIQUE_ID);

        val sb = StringBuilder();

        for (byte in widevineId) {

            sb.append(String.format("x", byte))

        }

        return sb.toString();

    } catch (e: Exception) {

    } catch (e: Error) {

    }

    return ""

}

AAID

• 无需任何权限


• Google 推出的广告 ID ，可由用户重置的标识符，适用于广告用例


• 系统需要自带 Google Play Services 才支持，且用户可以在系统设置中重置

重置后，在未获得用户明确许可的情况下，新的广告标识符不得与先前的广告标识符或由先前的广告标识符所衍生的数据相关联。

还要注意，Google Play 开发者内容政策要求广告 ID“不得与个人身份信息或任何永久性设备标识符（例如：SSAID、MAC 地址、IMEI 等）相关联。”

在支持多个用户（包括访客用户在内）的 Android 设备上，您的应用可能会在同一设备上获得不同的广告 ID。这些不同的 ID 对应于登录该设备的不同用户。

OAID

• 无需任何权限


• 国内移动安全联盟出台的“拯救”国内移动广告的广告跟踪标识符


• 基本上是国内知名厂商 Android 10+ 才支持，且用户可以在系统设置中重置

UUID

• 生成之后本地持久化保存


• 卸载后重新安装、清除应用缓存 会改变

如何选择

同个开发商需要追踪对比旗下应用各用户的行为

• 可以采用 Android ID（SSAID），并且不同应用需使用同一签名


• 如果获得的 Android ID（SSAID）为空，可以用 UUID 代替【 OAID / AAID 代替也可，但需要引入第三方库】


• 在 Android 8.0+ 中， Android ID（SSAID）提供了一个在由同一开发者签名密钥签名的应用之间通用的标识符

希望限制应用内的免费内容（如文章）

• 可以采用 UUID ，作用域是应用范围，用户要想规避内容限制就必须重新安装应用

用户群体主要是大陆

• 可以采用 OAID ，低版本配合采用 Android ID（SSAID）/ UUID


• 可以采用 Android ID（SSAID），空的时候配合采用 UUID 等

用户群体在海外

• 可以采用 AAID


• 可以采用 Android ID（SSAID），空的时候配合采用 UUID 等

免责声明

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

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

• 简单讲，就是将别人打包好的 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等格式的文件查看
  
  
  
  
  • github.com/skylot/jadx
  
  
  
  


• apksigner：签名工具
  
  
  
  
  • developer.android.com/studio/comm…
  
  
  
  


• 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

• 工具分享：code.flyleft.cn/posts/3e3d8…


• 书籍分享：book.douban.com/subject/205…


• 进阶(下次分享)：
  
  
  
  
  • 静态调试
  
  
  • 动态调试
  
  
  • 脱壳
  
  
  • NDK你想
  
  
  • so文件修改
  
  
  
  

我们平时在写代码的时候经常会遇到这样的一种情况

提示说没有处理xxx异常

然后解决办法可以在外面加上try-catch，就像这样

所以我之前经常这样处理

//重新抛出 RuntimeException

public class ThrowsDemo {



    public void demo4throws() {

        try {

            new ThrowsSample().sample4throws();

        } catch (IOException e) {

            throw new RuntimeException(e);

        }

    }

}



//打印日志

@Slf4j

public class ThrowsDemo {



    public void demo4throws() {

        try {

            new ThrowsSample().sample4throws();

        } catch (IOException e) {

            log.error("sample4throws", e);

        }

    }

}



//继续往外抛，但是需要每个方法都添加 throws

public class ThrowsDemo {



    public void demo4throws() throws IOException {

        new ThrowsSample().sample4throws();

    }

}

但是我一直不明白

这个方法为什么不直接帮我做

反而要让我很多余的加上一步

我处理和它处理有什么区别吗？

而且变的好不美观

本来缩进就多，现在加个try-catch更是火上浇油

public class ThrowsDemo {



    public void demo4throws() {

        try {

            if (xxx) {

                try {

                    if (yyy) {

                        

                    } else {

                        

                    }

                } catch (Throwable e) {

                }

            } else {



            }

        } catch (IOException e) {

            

        }

    }

}

上面的代码，就算里面没有业务，看起来也已经比较乱了，分不清哪个括号和哪个括号是一对

还有就是对Lambda很不友好

没有办法直接用::来优化代码，所以就变成了下面这样

本来看起来很简单很舒服的Lambda，现在又变得又臭又长

为什么会强制 try-catch

为什么我们平时写的方法不需要强制try-catch，而很多jdk中的方法却要呢

那是因为那些方法在方法的定义上添加了throws关键字，并且后面跟的异常不是RuntimeException

一旦你显式的添加了这个关键字在方法上，同时后面跟的异常不是RuntimeException，那么使用这个方法的时候就必须要显示的处理

比如使用try-catch或者是给调用这个方法的方法也添加throws以及对应的异常

throws 是用来干什么的

那么为什么要给方法添加throws关键字呢？

给方法添加throws关键字是为了表明这个方法可能会抛出哪些异常

就像一个风险告知

这样你在看到这个方法的定义的时候就一目了然了：这个方法可能会出现什么异常

为什么 RuntimeException 不强制 try-catch

那为什么RuntimeException不强制try-catch呢？

因为很多的RuntimeException都是因为程序的BUG而产生的

比如我们调用Integer.parseInt("A")会抛出NumberFormatException

当我们的代码中出现了这个异常，那么我们就需要修复这个异常

当我们修复了这个异常之后，就不会再抛出这个异常了，所以try-catch就没有必要了

当然像下面这种代码除外

public boolean isInteger(String s) {

    try {

        Integer.parseInt(s);

        return true;

    } catch (NumberFormatException e) {

        return false;

    }

}

这是我们利用这个异常来达成我们的需求，是有意为之的

而另外一些异常是属于没办法用代码解决的异常，比如IOException

我们在进行网络请求的时候就有可能抛出这类异常

因为网络可能会出现不稳定的情况，而我们对这个情况是无法干预的

所以我们需要提前考虑各种突发情况

强制try-catch相当于间接的保证了程序的健壮性

毕竟我们平时写代码，如果IDE没有提示异常处理，我们完全不会认为这个方法会抛出异常

我的代码怎么可能有问题！

看来Java之父完全预判到了程序员的脑回路

throws 和 throw 的区别

java中还有一个关键词throw，和throws只有一个s的差别

throw是用来主动抛出一个异常

public class ThrowsDemo {



    public void demo4throws() throws RuntimeException {

        throw new RuntimeException();

    }

}

两者完全是不同的功能，大家不要弄错了

什么场景用 throws

我们可以发现我们平时写代码的时候其实很少使用throws

因为当我们在开发业务的时候，所有的分支都已经确定了

比如网络请求出现异常的时候，我们常用的方式可能是打印日志，或是进行重试，把异常往外抛等等

所以我们没有那么有必要去使用throws这个关键字来说明异常信息

但是当我们没有办法确定异常要怎么处理的时候呢？

比如我在GitHub上维护了一个功能库，本身没有什么业务属性，主要就是对于一些复杂的功能做了相应的封装，提供给自己或别人使用（如果有兴趣可以看看我的库，顺便给Star，嘿嘿）

对我来说，当我的方法中出现异常时，我是不清楚调用这个方法的人是想要怎么处理的

可能有的想要重试，有的想要打印日志，那么我干脆就往外抛，让调用方法的人自己去考虑，自己去处理

所以简单来说，如果方法主要是给别人用的最好用throws把异常往外抛，反之就是可加可不加

结束

很多时候你的不理解只是因为你还不够了解

背景🌟

我们公司平时在开发的时候，总是会需要开发一些组件库，去提供给组内其他人通用，这样大大提高了复用性，当然大厂会有自己的组件库，不过学无止境嘛，大家可以根据本文学会如何发布npm包！现在一起来吧~

01、步骤一注册

打开npm官网，如果没有账号就注册账号，如果有就登陆。

02、步骤二创建文件夹

按需求创建一个文件夹，本文以test为例。

03、步骤三初始化package.json文件

进入test文件夹里面，使用cmd打开命令行窗口，在命令行窗口里面输入npm init初始化package.json文件。也可以在Visual Studio Coode的终端里面使用npm init命令初始化。

04、步骤四初始化package.json文件的过程

创建package.json的步骤

01、package name: 设置包名，也就是下载时所使用的的命令，设置需谨慎。

02、version: 设置版本号，如果不设置那就默认版本号。

03、description: 包描述，就是对这个包的概括。

04、entry point: 设置入口文件，如果不设置会默认为index.js文件。

05、test command: 设置测试指令，默认值就是一句不能执行的话，可不设置。

06、git repository: 设置或创建git管理库。

07、keywords: 设置关键字，也可以不设置。

08、author: 设置作者名称，可不设置。

09、license: 备案号，可以不设置。

10、回车即可生成package.json文件，然后还有一行需要输入yes命令就推出窗口。

11、测试package.json文件是否创建成功的命令npm install -g。

05、步骤五创建index.js文件

在test文件夹根目录下创建index.js文件，接着就是编写index.js文件了，此处不作详细叙述。

06、步骤六初始化package-lock.json文件

在test根目录下使用npm link命令创建package-lock.json文件。

07、步骤七登录npm账号

使用npm login链接npm官网账号，此过程需要输入Username、Password和Email，需要提前准备好。连接成功会输出Logged in as [Username] on registry.npmjs.org/ 这句话，账号不同，输出会有不同。

08、步骤八发布包到npm服务器

执行npm publish命令发布包即可。

09、步骤九下载安装

下载安装使用包，此例的下载命令是npm install mj-calculation --save。

10、步骤十更新包

更新包的命npm version patch，更新成功会输出版本号，版本号会自动加一，此更新只针对本地而言。

11、步骤十一发布包到npm服务器

更新包至npm服务器的命令npm publish，成功会输出版本，npm服务器的版本也会更新。

12、步骤十二删除指定版本

删除指定版本npm unpublish mj-calculation@1.0.2，成功会输出删除的版本号，对应服务器也会删除。

13、步骤十三删除包

撤销已发布的包npm unpublish mj-calculation使用的命令。

14、步骤十四强制删除包

强制撤销已发布的包npm unpublish mj-calculation --force使用的命令。

日志脱敏之殇

小明同学在一家金融公司上班，为了满足安全监管要求，最近天天忙着做日志脱敏。

无意间看到了一篇文章金融用户敏感数据如何优雅地实现脱敏？ 感觉写的不错，用起来也很方便。

不过日志脱敏之后，新的问题就诞生了：日志脱敏之后，很多问题无法定位。

比如身-份-证号日志中看到的是 3****************8，业务方给一个身-份-证号也没法查日志。这可怎么办？

安全与数据唯一性

类似于数据库中敏感信息的存储，一般都会有一个哈希值，用来定位数据信息，同时保障安全。

那么日志中是否也可以使用类似的方式呢？

说干就干，小明在开源项目 sensitive 基础上，添加了对应的哈希实现。

使用入门

开源地址

github.com/houbb/sensi…

使用方式

1）maven 引入

<dependency>

    <groupId>com.github.houbb</groupId>

    <artifactId>sensitive-core</artifactId>

    <version>1.1.0</version>

</dependency>

2）引导类指定

SensitiveBs.newInstance()

.hash(Hashes.md5())

将哈希策略指定为 md5

3）功能测试

final SensitiveBs sensitiveBs = SensitiveBs.newInstance()

                .hash(Hashes.md5());



User sensitiveUser = sensitiveBs.desCopy(user);

String sensitiveJson = sensitiveBs.desJson(user);



Assert.assertEquals(sensitiveStr, sensitiveUser.toString());

Assert.assertEquals(originalStr, user.toString());

Assert.assertEquals(expectJson, sensitiveJson);

可以把如下的对象

User{username='脱敏君', idCard='123456190001011234', password='1234567', email='12345@qq.com', phone='18888888888'}

直接脱敏为：

User{username='脱**|00871641C1724BB717DD01E7E5F7D98A', idCard='123456**********34|1421E4C0F5BF57D3CC557CFC3D667C4E', password='null', email='12******.com|6EAA6A25C8D832B63429C1BEF149109C', phone='1888****888|5425DE6EC14A0722EC09A6C2E72AAE18'}

这样就可以通过明文，获取对应的哈希值，然后搜索日志了。

新的问题

不过小明还是觉得不是很满意，因为有很多系统是已经存在的。

如果全部用注解的方式实现，就会很麻烦，也很难推动。

应该怎么实现呢？

小伙伴们有什么好的思路？欢迎评论区留言

前言

之前整理过 整理下最近做的产品里 比较典型的代码规范问题，里面有一个关于可选链运算符(?.)的规范，当时只是提了一下，今天详细说下想法，欢迎大佬参与讨论。

可选链运算符(?.)，大家都很熟悉了，直接看个例子：

const result = obj?.a?.b?.c?.d

很简单例子，上面代码?前面的属性如果是空值（null或undefined），则result值是undefined，反之如果都不是空值，则会返回最后一个d属性值。

本文不是讲解这种语法的用法，主要是想分析下日常开发中，这种语法 滥用、乱用 的问题。

滥用、乱用

最近在code review一个公司项目代码，发现代码里用到的可选链运算符，很多滥用，用的很无脑，经常遇到这种代码：

const userName = data?.items?.[0]?.user?.name

↑ 不管对象以及属性有没有可能是空值，无脑加上?.就完了。

// react class component

const name = this.state?.name



// react hooks

const [items, setItems] = useState([])

items?.map(...)

setItems?.([]) // 真有这么写的

↑ React框架下，this.state 值不可能是空值，初始化以及set的值都是数组，都无脑加上?.

const item1 = obj?.item1

console.log(item1.name)

↑ 第一行代码说明obj或item1可能是空值，但第二行也明显说明不可能是空值，否则依然会抛错，第一行的?.也就没意义了。

if (obj?.item1?.item2) {

    const item2 = obj?.item1?.item2

    const name = obj?.item1?.item2?.name

}

↑ if 里已经判断了非空了，内部就没必要判断非空了。

问题、缺点

如果不考虑 ?. 使用的必要性，无脑滥用其实也没问题，不会影响功能，优点也很多：

但是问题和缺点也很明显，而且也会很严重。分两点分析下：

1. 可读性、维护性

可读性和维护性其实是一回事，都是指不是源代码作者的开发维护人员，在捋这块代码逻辑、修改bug等情况时，处理问题的效率，代码写的好处理就快，写的烂就处理慢，很简单道理。

const onClick = () => {

    const user = props.data?.items?.[0]?.user

    if (user) {

        // use user to do something

    }

}

已这行代码为例，有个bug现象是点击按钮没反应，维护开发看到这块代码，就会想这一串链式属性里，是不是有可能有空值，所以导致了user是空值，没走进if里导致没反应。然后就继续分析上层组件props传输代码，看data值从哪儿传来的，看是不是哪块代码导致data或items空值了。。。

其实呢？从外部传过来的这一串属性里不会有空值的情况，导致bug问题根本不在这儿。

const user = props.data.items[0].user

那把?.都去掉呢？维护开发追踪问题看到这行代码，data items 这些属性肯定不能是空值，不然console就抛错了，但是bug现象里并没有抛错，所以只需要检查user能不能是空值就行了，很容易就排除了很多情况。

总结就是：给代码维护人员带来了很多分析代码的干扰，代码可读性和维护性都很差。

2. 隐式过滤了异常

api.get(...).then(result => {

    const id = result?.id

    // use id to do something

})

比如有个需求，从后台api获取数据时，需要把结果里id属性获取到，然后进行数据处理，从业务流程上看，这个api返回的result以及id必须有值，如果没值的话后续的流程就会走不通。

然后后台逻辑由于写的有问题，导致个别情况返回的 result=null，但是由于前端这里加了?.，导致页面没有任何反应，js不抛错，console也没有log，后续流程出错了，这时候如果想找原因就会很困难，对代码熟悉还行，如果不是自己写的就只能看代码捋逻辑，如果是生产环境压缩混淆了就更难排查了。

api.get(...).then(result => {

    const id = result.id

    // use id to do something

})

把?.去掉呢？如果api返回值有问题，这里会立即抛错，后面的流程也就不能进行下去了，无论开发还是生产环境都能在console里快速定位问题，即使是压缩混淆的也能从error看出一二，或者在一些前端监控程序里也能监听到。

其实这种现象跟 try catch 里不加 throw 类似，把隐式异常错误完全给过滤掉了，比如下面例子：

// 这个try本意是处理api请求异常

try {

    const data = getSaveData() // 这段js逻辑也在try里，所以如果这个方法内部抛错了，页面上就没任何反应，很难追踪问题

    const result = await api.post(url, data)

    // result 逻辑处理

} catch (e) {

    // 好点的给弹个框，打个log，甚至有的啥都不处理

}

总结就是：把异常给隐式过滤掉了，导致不能快速定位问题。

3. 编译后代码冗余

如果代码是ts，并且编译目标是ES2016，编译后代码会很长。可以看下 http://www.typescriptlang.org/play 效果。

Babel在个别stage下，编译效果一样。

但并不是说一点都不用，意思是尽量减少滥用，这样使用的频率会少很多，这种编译代码沉余也会少不少。

应该怎么用？

说了这么多，.? 应该怎么用呢？意思是不用吗？当然不是不能用，这个特性对于开发肯定好处很多的，但是得合理用，不能滥用。

其实说白了就是：什么时候需要判断一个变量或属性非空，什么时候不需要。首先在使用的时候得想下，问号前面的变量或属性值，有没有可能是空值：

const userName = data?.items?.[0]?.user?.name // 不要滥用，如果某个属性有可能是空值，则需要?.

const userName = data.items[0].user?.name // 比如data.items数组肯定不是空数组

const items2 = items1.filter(item => item.checked)

if (items2?.length) { } // 不需要?.

// react class component

const name = this.state?.name // 不需要?.



// react hooks

const [items, setItems] = useState([])

items?.map(...) // 如果setItems没有赋值空值情况，则不需要?.

setItems?.([]) // 不需要?.

const item1 = obj?.item1 // 不需要?.

console.log(item1.name)

const id = obj?.id // 下面代码已经说明不能是空值了，不需要?.

const name = obj.name

if (obj?.item1?.item2) {

    const item2 = obj?.item1?.item2 // 不需要?.

    const name = obj?.item1?.item2?.name // 不需要?.

}

const id = obj?.item?.id // 不需要?.

api.get(id).then(...) // 这个api如果id是空值，则api会抛错

当然，写代码时还得多想一下属性是否可能是空值，会一定程度的影响开发效率，也一定有开发会觉得很烦，不理解，无脑写?.多容易啊，但是我从另外两个角度分析下：

总结

本文以一个 code reviewer 角度，分析了 可选链运算符(?.) 特性的滥用情况，以及“正确使用方式”，只是代表我本人的看法，欢迎大佬参与讨论，无条件接受任何反驳。

滥用的缺点：

“正确用法”：

后记（09月25日更新）

从评论上看，对于可选链的看法，大多声音是能加就加，多加总比少加好，原因就是不想背锅，不想上线后JS动不动就崩了，无论根本原因是不是前端开发没加判断导致的，第一责任人就会找到你，有的甚至会被上级追责，问题就更严重了，而且很难解释清楚；另一方面就是为了赶工期，可选链的其中一个优点就是简单，提高开发效率。

我再从几个方面浅浅的扩展下我的看法，欢迎参与讨论

总之。。。对对对，你们说的都对！

Jetpack Compose 是个啥？为啥要学它？

谷歌对 Jetpack Compose 的定义：

Jetpack Compose 是推荐用于构建原生 Android 界面的新工具包。它可简化并加快 Android 上的界面开发，使用更少的代码、强大的工具和直观的 Kotlin API，快速打造生动而精彩的应用。

提取关键词：界面开发新工具包、简化并加快界面开发、Kotlin API。

对于大部分Android项目来说，如果基础库(如网络库、hybird、图片加载、热修复库等)已经搭好，那么平时大部分时间就是跟 UI界面、需求逻辑 打交道了，而谷歌提供的 Jetpack Compose 正好是加快界面开发的工具包。

就跟魂斗罗里的子弹类型似的，使用普通子弹(XML方式)也可以通关，但是相比之下耗时更长；而换成超级子弹(Jetpack Compose)体验就不一样了，耗时更少，而且游戏体验更爽！

命令式UI vs 声明式UI

长期以来，Android 视图层次结构一直可以表示为界面 widget 树。最常见的界面更新方式是使用 findViewById() 等函数遍历树，并通过调用 button.setText(String)、container.addChild(View) 或 img.setImageBitmap(Bitmap) 等方法更改节点。这些方法会改变 widget 的内部状态，这种手动更新UI的方式即是命令式UI。

在过去的几年中，整个行业已开始转向声明性界面模型，该模型大大简化了与构建和更新界面关联的工程任务。该技术的工作原理是在概念上从头开始重新生成整个屏幕，然后仅执行必要的更改。此方法可避免手动更新有状态视图层次结构的复杂性。Compose 即是一个声明式UI框架。

Jetpack Compose要学起来了？

很遗憾，Jetpack Compose 确实要学起来了（快起来，你还能学！哈哈...），随着Jetpack Compose 版本的不断迭代，API 逐渐稳定了，性能也越来越好了。

• 更少的代码：编写代码只需要采用Kotlin，而不用拆分成 Kotlin + XML方式了。


• 直观：只需描述界面，Compose会负责处理剩余工作。应用状态变化时，界面自动更新。


• 加速开发：View 与 Compose 之间可以相互调用，兼容现有的所有代码。借助AS可以实时预览界面，轻松执行界面检查。


• 功能强大：直接访问Android API，内置对Material Design、主题、动画等的支持。