趁着最近空闲在家学学devops, B站上的视频教程很多，学起来不用费太多脑子，先总体有一个了解，让自己能保持兴趣学下去。

但是视频教程难免内容老化及有语焉不详之处，暂记此处以作查缺补漏之用。

注意事项

• 需要安装虚拟机，教程一般都是Centos7的，最好安装一致的版本，以免兼容性问题。
• 电脑内存至少16G以上，需要同时至少启动4个虚拟机，每个4G内存。
• 虚拟机创建好了默认是动态IP，最好改为静态IP
• 安装的docker和docker-compose版本要注意，安装教程中的方式可能过时了。
• docker的镜像源需要单独找，教程中的过时了。国内大多数镜像源都趴窝了，目前两种方式比较稳定，一种是github action搭配阿里云镜像服务，一种是CF中转。
• Jenkins的安装，视频里的也过时了，视频里的版本有很多Jenkins插件已经不兼容了。

常用命令

记录些常用命令，用的时候可以随时复制粘贴

复制虚拟机后修改网卡信息使用新的IP

vi /etc/sysconfig/network-scripts/ifcfg-ens33

重启网卡

systemctl restart network

Centos换阿里云源

curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

虚拟机是动态IP，最好改成静态的

IPADDR=”192.168.249.129”
NETMASK=”255.255.255.0”
GATEWAY=”192.168.249.2”
DNS1=”8.8.8.8”
DNS2=”8.8.4.4”

配置docker-compose yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

version: '2.6.1'
services:
  gitlab:
    image: your_web_image_name:latest  # 替换为你的Web应用镜像名称和标签
    container_name: gitlab
    restart: always
    ports:
      - "8929:8929"  # 将主机的8080端口映射到容器内的80端口，可根据需要修改
      - "2224:2224"
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://192.168.249.130:8929'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
    volumes:
      - './config:/etc/gitlab'
      - './logs:/var/log/gitlab'
      - './data:/var/opt/gitlab'

查看gitlab初始密码

cat /etc/gitlab/initial_root_password

jenkins yml模板

1
2
3
4
5
6
7
8
9
10

version: '2.6.1'
services:
  jenkins:
    image: jenkins/jenkins:2.319.1-lts  # 替换为你的Web应用镜像名称和标签
    container_name: jenkins
    ports:
      - 8080:8080  # 将主机的8080端口映射到容器内的80端口，可根据需要修改
      - 50000:50000
    volumes:
      - ./data/:/var/jenkins_home

Jenkins插件源

https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

暂时先记录这么多

公司年底就解散了，回想起来在这工作了有四年半了。 做一下简单下回顾，以免疏漏。

编译

• 使用增量编译：在编译时尽量只重新编译修改过的文件，而不是整个项目，可以节省大量的编译时间。
• 使用构建缓存：利用构建缓存工具如Gradle Build Cache或Buck等，可以加快编译速度。
• 使用多线程编译：在编译时使用多线程可以加快编译速度，可以在编译配置中设置并发编译数。
• 分离模块编译：将项目拆分成多个模块，分别进行编译，可以减少编译时间。
• Gradle版本升级，增加AS运行内存
• KSP代替kapt
• 删除无用依赖，调整仓库地址顺序，固定依赖版本
• 资源优化，使用webp或svg，debug构建时禁用图片无损压缩
• 禁用R文件传递
• 源码依赖改为远程依赖

Unit Test

Gradle java-test-fixture提升UT效率比较好用，在之前的项目里，由于使用了gradle脚本的dependencySubstitution方式将本地的远程依赖改为源码依赖进行构建，会有一些冲突，Gradle脚本需要做一些修改才好用。

Mockk尽量避免使用，初始化时间太长，Junit5会并行跑UT，拖慢CI/CD下的速度。

几个印象奇奇怪怪的组件

自定义图片加载decoder

Glide-AudioDecoder 支持Glide加载MP3文件的专辑图，很奇快官方既然支持了视频文件缩略图为啥不把音频文件的一起也支持了。

Coil-ScaledSvgDecoder 支持SVG图片以dp格式的原大小展示和无损缩放。Github上有人提过issue，呼声挺高的，希望官方能尽快支持dp格式的size吧。

MarkdownText

compose中显示markdown文本内容，定制了几个有意思的内容。

一个是通过参数禁止特定的格式渲染，例如禁止OrderedList但不禁止bulletList。

另外一个是检测输入的文本中是否含有带link item的table，有的话需要更改markdown内部TextView的MovementMethod, 避免link无法点击的问题。还不能直接修改，会影响a11y。

##杂项心得

• 非主线程的资源占用也会导致UI卡顿
• 文字转语音服务可以通过官方TextToSpeechService自定义实现
• 弹窗卡顿可能是因为未及时拦截已消费的事件
• Android studio看不到AAR的源码问题不知道官方解决没，临时方案是更改一个Gradle属性或者更改studio的一个设置。
• UID为system的系统应用不能访问外置存储。

自从和媳妇有了自己的车以后，就爱开着车到处闲逛。听着音乐，欣赏一路上的风景，到达某个景点，溜溜腿，唠唠闲话。 当时最喜欢的地方就是去旅顺附近，那边的路宽敞，车也少，对于新手的我来说非常友好。 另外旅顺的很多景点人也少，不拥挤，非常适合闲逛。

随着附近的景点都被我们逛个遍，我们的足迹越来越远，偶然一次发现旅顺有个叫神龙仙岛海上主题公园的地方，脑海里一下子蹦出来武侠剧里的仙岛，毫无疑问那就是我们下一个目的地。

当我们驱车到达那里时，园里映入眼帘的景象昭示着这里曾经的辉煌，如今却已是破败不堪。令人惊讶的是，门口居然还有个人收门票，看打扮像是附近的村民。

我们进入园区开始闲逛，这种早已风光不再的景区的好处就是人少，你可以十分悠闲的闲逛拍照，毫无其他景点般喧闹。 到达那里时已是下午，太阳开始下降，沿着海边向东边走边拍照，站在海豚雕塑前，阳光透过雕塑，拍出来的照片非常好看。 走到最东边，几个人站在岸边钓鱼，有块巨石矗立在海边，约有十来米高，我从未在海边见过巨石矗立，在那时的我看来这巨石是如此壮观，我还特意拍了几张照片。

沿着海边向西走，还有一处巨石，上面刻着红字： 栖凤石。 有一个观景台顺着台阶连接到上面，通过台阶还可以到达一个观景长廊，长廊从外面看有点像悬崖上的长城，长廊里很适合向外眺望一望无际的大海，沿着长廊再往里走有一个白色巨象雕塑，远处看很好看，近处由于太过巨大，拍照无法照到全貌。 长廊尽头是一片废墟，绕着墙边走又绕回了大门口。

基本上到此我们逛遍了整个园区，我打开手机导航准备打道回府，顺便看一下我们下次去哪。 就在这时，我发现地图上有个叫将军石的定位点，就在这园区里的海边，就在我们附近。 这一下子就引起了我的兴趣，到底这将军是什么，西边带观景台的明明叫栖凤石，难道是东边那个巨石？ 虽然看起来巍峨，但是怎么也联想不到将军，而且将军石的定位明明在园区的西边。 我又同媳妇返回东边巨石处，我又仔细观摩了下，还是无法确定。 此时天色已晚，我们只得离开。

自此，将军石就一直徘徊在我的脑海里，藏在一个极其隐秘的角落，时不时的跳出来打个招呼： 嘿，你找到我了么？ 一旦当一个疑问藏在心里久了，就会变成一个疙瘩，在你最不经意的时候硌你那么一下，若恰巧赶上夜深人静，负面情绪加倍放大，就会变成辗转反侧的一夜。

我一定要找到将军石！ 我从没下过这样的决心，从没做过这样的决定，一块破石头么，找到了又能怎样。 可是我的行动却从没停止过，又去了一次，无功而返。 我开始从网上搜索，在抖音上找到了线索，将军石真的存在！ 再次带着媳妇前往，没有进入园区，从东侧绕了一圈，还是无功而返。 而后我们又去了一次，这一次是因为抖音上一个视频说游览旅顺的越野路线，越野车走右侧上山去采石场的路，可以到达一处观景台，可以看到将军石。 那条路在园区大门右侧，时常有装满石头的大车经过，我们步行进入了那里，最终停步在一个废旧的厂子里的一个大门前。 大门被上了锁链，再往里就是园区，若沿着采石场的路继续走的话又远又危险，最终我向着厂子里望了望，不甘心了离开了。

后来一次和媳妇游览燕窝岭，媳妇看到海边有块巨石，开始调侃我：快看，将军石！ 这使我又燃起了找到将军石的想法，于是我再次在抖音上搜索，这次终于找到一个视频，录下了进入园区后的前半段路线， 正是那个长廊下来后回到园区门口的路。 终于，又一个周末，和媳妇一起出游，忘记了去的是哪里，因为那天唯一给我留下印象的，就是快结束时，我又拖着媳妇来到了神龙仙岛。 媳妇那天有些不舒服，进入园区后坐在石凳上休息， 我便一个人上路，顺着门口右边的破路走去，当我走到一处拐角时，路边园区的墙有大约两米的缺口，我感觉这便是了。 从缺口走出去，是一小段石头路，走下去就是一个大平台，豁然开朗的大海，那海边矗立的正是将军石！

我高兴的立刻拿出手机拍照，然后跑着回去找媳妇。 媳妇不是很兴奋，因为她对这块破石头从来就不感兴趣，正当身体也不舒服，不情不愿的被我拉了过去。 当我们都到达了将军石那里，我开心的下去海边拍照，媳妇站在大平台上观望。 我兴奋的跟媳妇讲述我的心情多么舒畅：不是因为这石头有多壮观，而是因为我终于找到了它！

往往就是这些生活中的小事，逐渐变成一粒粒沙子，慢慢的摩擦，直到磨平了心性。 找到将军石让我感觉沙子一下子倾倒了出来，我知道还会有沙子出现，我也有了能够将沙子倒出来的希望。

　　昨天在w3cschool公众号上看到一个推理题：有两根不均匀分布的香，香烧完的时间是一个小时，你能用什么方法来确定一段15分钟的时间？

　　看到这个问题我的第一反应就是这还要两根香？一根不就够了么？把一根香掰断，总共四个头，一起点燃，全烧完了不就是15分钟么。

　　这问题我还有些印象，应该是流传于互联网中的老题了。今天w3cschool推送了问题标准答案：第一根香先点一端，第二根香在第一根香点燃时候同时把两端点燃，这样第二根香烧完是半小时，此时第一根香也剩半小时，在第二根香烧完的同时把第一根香的另外一端也点燃，那么从第二根香烧完到第一根香烧完的这段时间就是15分钟。

　　我的思维是不是有点太跳脱了。

　　这题又让我想起小时候猜过的几个逻辑推理题，其中印象最深刻的是猜帽子颜色和灯泡问题。说啊，有这么两个房间，一个里面有三个开关，另一个里面有三个灯泡，每个房间只允许进入一次，分辨出三个开关分别控制哪三个灯泡。

　　我为啥对这题印象这么深刻呢，因为我当时才十二三岁，那时候也没有网络，自己琢磨出了问题的答案，然后在班里问同班同学。那些看起来很聪明的孩子，一个都答不出来。然后前两天突然又想起来这个问题，让我媳妇猜，她也不会。她不仅不会这个，其它的也都不会，哈哈哈，看来我还是挺聪明的🤭。

　　简历里写了工作中经常帮助同事解决疑难问题，面试的时候被问题，都解决了哪些疑难问题呢？

　　由于毕业后一直没有出来面试，并且时间仓促，当面试官问到这个问题时，我回想最近一位经常向我寻求帮助的同事，才一下子意识到，这些问题对他来说是疑难问题，但实际上在我看来非常简单。仓促之间只讲了如何处理ANR。

　　面试过后，回想起来我其实还有很多比ANR好得多的可讲的。比如我做过的系统开机时间优化，应用启动优化；主动承担动效非常复杂的风车UI；刚工作那两年调查的系统无故黑屏死机等问题。还有个非常有意思的，在我刚工作不到半年的时候，一位同事写了一段读取USB下某个文件的代码，但是在他的应用内一直都获取不到，将这段代码复制到一个新建的应用内，就没有问题。我检查了他的权限申请，他的代码逻辑，怎么看都没有问题。我花了很长时间去找原因，最后我发现，他的应用使用到了系统权限，他将自己的应用UID设置成了System。根据我的直觉推测，Android UID为System的是无法直接访问USB的，以保证系统安全避免入侵漏洞。最后经过验证我的推测是对的。我觉得这些才是我应该在面试中分享出来的。

　　小时候，有时候会跟人辩论或吵架，回到家后就在脑海里复盘过程，然后默默懊悔：我当时应该这么说才对。。。。。。 这么多年了我还是没什么长进哪！

　　所以，残念哪！！！

　　幸好，我最后面试还是过了，🤭。

红红火火过年了，盘点一下这一年来工作中学到的和容易遗忘的重要知识点。

1. Google jetpack–>Room，LiveData,ViewModel,Paging,Navigation等。jetpack这个香啊，Android将来的开发趋势啊。
2. Java泛型的操作，如何避免泛型的擦除，获取对象携带的泛型，使用泛型+Interface+Type实现灵活多态化接口。通过对接口的组合、实现，完成对旧接口的兼容。
3. AIDL对方法重载的限制，传递数据的上限，是很容易被忽略的点。 尤其是上限，根据网络搜索结果来看，默认1M是上限。但实际在我这个项目平台上，700-800K就会触发限制。根据我对平台方的了解，他们不会去修改这个默认限制大小。所以个人人为这1M限制的不是单次而是带宽。 或者数据是700k，而同时为传递数据占用的其他内存超过了300k。没有深究，总之是有限制。因此传递前需要检查要传递数据的大小，太大需要分批传递。
4. AIDL的延迟绑定，绑定成功后返回一个代理binder，待service准备好后，返回对应配置的binder，connection再向上通知绑定成功。
5. 动态代理香啊。
6. 使用fat-aar合并aar，并上传源码和文档到maven私服。上传文档时遇到个坑，上传方法都是百度上copy来的，文档乱码，百度不到原因。经过我一番瞎研究发现，options只设置了encoding，还需要设置charSet才可以。加上options.charSet = “UTF-8”就可以了。
7. Scanner的实现，配置化。文件少量的时候，使用Java扫描较快，文件越多，使用C扫描的优势越明显。最耗时的在于根据文件名中英文数字排序，以及解析保存专辑图。但是专辑图有了使用glide的更好方案。
8. glide自定义模块，看源码了解了一下ModelLoader,DataFetcher,Decoder等glide模块作用，可以自定义一个Decoder解析MP3的专辑图，这样应该可以减少Scanner很多扫描时间，岂不是很香。
9. 使用javapoet实现APT。能做的事，比动态代理多很多。
10. kotlin这个香啊，还有很多java没有的特性，用起来比Java爽啊。就是还有很多特性尚未掌握，内联，类型投影等等。还有协程，看起来用着简单，要熟练掌握还是有难度的，今年再接再厉吧。

就这样，想到的就这些，接下来看今年还会有什么有意思的吧。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment