趁着最近空闲在家学学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的系统应用不能访问外置存储。

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

　　由于毕业后一直没有出来面试，并且时间仓促，当面试官问到这个问题时，我回想最近一位经常向我寻求帮助的同事，才一下子意识到，这些问题对他来说是疑难问题，但实际上在我看来非常简单。仓促之间只讲了如何处理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爽啊。就是还有很多特性尚未掌握，内联，类型投影等等。还有协程，看起来用着简单，要熟练掌握还是有难度的，今年再接再厉吧。

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