五一假期将近，计划出游的时间到了，合计了下，日本签证还没过期，汇率也还不错，想着正适合去东京。而且去年也去过关西，经验还在，遂做了个大致计划主打休闲不累为主，定好机酒出发。这次计划依然家属负责，我主打一键跟随，不带脑子。

出行日期：2024/04/29 - 2024/05/04
道具准备：

• 电子设备： mba，手机，充电：type-c ，watch，iphone，相机充电器。
• 相机选择：A7M4+70200GM2 , 富士 x100vi
• 日本 sim 卡、Suica（西瓜卡）、日元现金 4w（都是刷卡，真准备太多了）

冰箱贴 +3 ^_^

行程日期 & 目的地

日期：2023/09/26 - 2023/10/02
目的地：马尔代夫-瓦卡鲁岛，这次旅程是这么多出行旅游中最轻松的一次了，出发前休息了几天，回来后又休息了几天。不过因为我全程没有操心行程安排、机票酒店啥的、所以我应该是最轻松的了(✧∇✧)。

整个行程基本上都是和朋友们在瓦卡鲁岛上待着，吹吹海风看看美景，换个地方躺着的假期。很蓝，很惬意~

日本4月底放开，机票价格挺美丽，就计划腾个假期去日本关西玩玩，最后定了端午去，不过等正式定行程的时候，机票贵了挺多，不过相比四月份还是便宜很多的。最初我们想定私人跟团游，但是日本的包车真的很贵，遂放弃了。最终行程和机酒路线都是自己定制，交通大部分选择公共交通。不过相比国内的交通，日本交通复杂很多，同一个车站有不同目的地，同一个车不同车厢还有可能去的地方不一样。总之，跟着google map的提示来就行，好在很多地点是中文字，细心一些不会错。

• 结果很美丽，收获超多开心和回忆~
  

前序

疫情已经快三年了，今年因为各地疫情此起披伏，一直不能远行，今年国庆眼看还有两周了，也没什么旅游长线可选，正好朋友推荐一起去呼伦贝尔，查了下，呼伦贝尔暂时还是安全的，所以就敲定了呼伦贝尔线路，太需要让自己放松下了。不过时间太赶，自驾游是来不及定了，所以就跟了游侠客的团，之前稻城亚丁川西行也是跟的游侠客，还不错，绝对不是购物团。

临近出发时，说满洲里因为疫情不能去，所以原定的左边的环线变成了右边的，去除了满洲里的行程，这年头，能出去就不错了，不挑也不遗憾。当下我们合计了下原定从海拉尔回来的机票改签了成了阿尔山飞回的机票，省事还便宜。没想到后面的变数越来越精彩，下文再详述。

行程介绍

行程日期

前序部队：2021/04/28 - 2021/05/09
集合部队：2021/05/01 - 2021/05/09

行程路线

西宁->张掖->敦煌->鸣沙山->苏干湖->茫崖翡翠湖->西台吉乃尔湖->水上雅丹->东台吉乃尔湖->大柴旦翡翠湖->茶卡盐湖->青海湖->西宁

行程亮点

翡翠湖、雅丹地貌、大戈壁、青海湖、敦煌、美食

行程日期：2020/09/28 - 2020/10/08
行程路线：杭州->丽江->香格里拉->雨崩->香格里拉->泸沽湖->丽江->杭州
行程亮点：美景、美食、高海拔徒步
人物：fufu、英英、阳阳、罗罗、虫虫、水水

参考文章:

• Revisit iOS Autorelease 之不经意间可能被影响的优化
• 自动释放池的前世今生 —- 深入解析 autoreleasepool
• 黑幕背后的Autorelease

前段时间通过搭建 Crash 平台的机会，知道了如何进行 Crash 的解析和聚类。那么如何去理解一个 Crash 呢？这篇文章是通过 WWDC 中的资料进行整理学习的。

• Understanding Crashes and Crash Logs - WWDC 2018 及相关的视频和资料。
• 参考文章：Understanding Crashes and Crash Logs

崩溃的基本原理

什么是崩溃

崩溃当你的 app 试图做一些不被允许的事情导致被突然终止。如：

• impossible for CPU to execute code : CPU 无法执行某些代码 （除以0）
• Operating system is enforcing a policy: 操作系统正在执行某些策略 (为了保证系统流畅性，操作系统kill了 启动时间过长、使用了太多内存的app)
• Programming language is preventing failure: 编程语言自身阻止失败并触发崩溃 (数组越界)
• Developer is preventing failure: 开发者自己触发（assert）

查看崩溃的方式

• Crashes Organizer window
• Devices window
• Automated testing (Xcode、 Xcode Server、 Xcode-build)
• Console app
• Sharing from device (用户隐私共享数据分享)

前期调研准备可参考上一篇系列文章：https://www.xuyanlan.com/2019/02/20/iOS-crash-report/

客户端收集 Crash

客户端收集 Crash 使用的是 PLCrashReporter 这个开源的库，集成方法有很多成熟的文章可以参考，这里不再赘述。而且有需要的话你可以在 signal_handler_callback 方法中获取到崩溃信息然后追加崩溃瞬间的一些 App 信息，对于定位 Crash 有着重要的作用。

Crash 解析 - llvm8.0

实践中 Crash 解析方式并未用到上一篇文章中提到的自己实现的 macho 解析工具，但是前期的准备工作让后期搭建工作更加顺利。如果你的服务器不是 MacOS (是的话可以直接是使用 symbolicatecrash，只需要收集各个版本的固件即可)。我们所部署的 Crash 解析服务器是Linux。
发现了一个成熟的 Crash 解析工具 - llvm, 我所使用的版本是llvm8.0，部署非常简单，下载解压后就能使用。http://llvm.org/docs/CommandGuide/ 中列出了一些 Commands。 其中主要使用到的是:

• llvm-symbolizer - convert addresses into source code locations
• llvm-readelf - GNU-style LLVM Object Reader

llvm-symbolizer 用于定位代码位置，这个是解析 Crash 的重点，来看一个例子：

1

llvm-symbolizer --obj=XXX:arm64 0x100301A5C  0x1003014DC 0x1002FDE74 0x1002FDD3C  0x1002FBE60 0x100188B10

深入理解 runloop

本文参考了多位前辈的文章、视频和源码进行学习、以及总结加深理解。

• iOS线下分享《RunLoop》by 孙源@sunnyxx
• 深入理解RunLoop
  RunLoop 是 iOS 和 OSX 开发中非常基础的一个概念。runloop是与线程相关的基础架构的一部分。runloop是指用于安排工作，并协调接收传入事件的事件处理循环。runloop的目的是在有工作时保持线程忙，并在没有工作时时让线程进入休眠状态。本文从源码入手，理解 runloop 原理，以及相关自动释放池、延迟回调、触摸事件、屏幕刷新等功能。

RunLoop 概念

一般来讲，一个线程一次只执行一个任务，任务执行完成后线程就退出了，runloop 就是能让线程保持随时能处理任务但不退出的一个机制。这种机制就是 Event Loop 模型，实现这种模型的关键点在于：如何管理事件/消息，如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒。

OSX/iOS 系统中，提供了两个这样的对象：NSRunLoop 和 CFRunLoopRef。
CFRunLoopRef 是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，所有这些 API 都是线程安全的。
NSRunLoop 是基于 CFRunLoopRef 的封装，提供了面向对象的 API，但是这些 API 不是线程安全的。

RunLoop 实际上就是一个对象，这个对象管理了其需要处理的事件和消息，并提供了一个入口函数来执行上面 Event Loop 的逻辑。线程执行了这个函数后，就会一直处于这个函数内部 “接受消息->等待->处理” 的循环中，直到这个循环结束（比如传入 quit 的消息），函数返回。这种说法比较抽象，下面会结合开发过程中使用到的例子来配合源码进行理解。