最近一段时间一直在研究 xcframwork 相关问题:

• xcframwork 编译
• 依赖 xcframework 的同时支持点击跳转源码
• 依赖 xcframework 的同时支持源码断点调试

到目前为止已经有些阶段性成果了, 因此在这里把我们使用第三方库编译为 xcframwork 引用的整体方案给大家分享一下

炒股有好多年的经验了, 属于老韭菜一颗. 最近看到 Nvidia 股价一涨再涨, 每次都懊恼自己不能购买美股. 当然, 不能交易美股的根本原因还是因为没有境外银行账户.

最近为了解决 iOS 编译产物存储与引用的问题, 深入调研了一番 cocoapods 源码与 nexus 技术, 最后开发出了一套以 nexus 为核心的 ios 编译产物存储引用方案, 包含上传脚本与 cocoapods 下载插件

swift

Copied!

// main.swift
import Foundation

print(123)
sleep(1)
print(456)
sleep(1)
print(789)

上面是一段可以执行至少两秒钟的 Swift 代码, 我们可以在命令行中以 nohup swift main.swift &>output.txt & 命令执行, 然后在另一个命令行窗口中使用 tail -f output.txt 命令实时查看文件内容变化. 按照我们直觉, 程序会在执行的第 0 秒打印 123, 第 1 秒打印 456, 第 2 秒打印 789, 但是结果是直到第 2 秒一次性打印了所有内容, why?

最近在学习多线程底层源码, 为了方便验证各种多线程案例, 我是直接在一个 main.swift 文件中编写异步代码, 然后终端中使用 swift main.swift 命令来执行看输出的. 然后就遇到了一个很基础的问题: 命令行程序不像 iOS 或 macOS 应用, 默认是没有 runloop 的, 这就代表提交到主线程的同步代码执行完成后整个程序就退出了, 我们添加到其他线程的或者在主线程异步执行的代码就没有机会被执行了.

这个问题解决不了的话就无法使用终端程序验证多线程代码了, 经过一番学习, 发现是有多种方式能使终端程序不退出执行的, 这篇文章将我谈索道的这些方式做一下总结

最近碰巧看到了一段判断字节序大小端的代码, 顺带学习了下大小端. 可是越学习越迷糊, CPU 大小端与文件编码大小端是什么关系? 经过深入了解后撰写本文进行总结分享

今年趁着国庆 8 天假期去了凤凰古城和张家界去玩, 这次旅行遇到了很多不顺心的事情, 而这些事情大部分都是可以避免或者得到更妥当方式处理的. 因此我要记录下这次旅行

最近我们的 app 被反馈了几个不同的生产问题, 都属于偶现, 由于不能稳定复现, 因此排查起来比较困难, 只能猜测问题出现在哪里, 尝试进行修改, 改完之后也不知道有没有彻底解决, 很痛苦. 造成这种现象的原因是我们 app 目前缺乏一个日志系统, 结合前段时间的面试经历, 我意识到大型的 app 一般都会配备有日志分析系统, 而这正是我们 app 目前所欠缺的, 我觉得是时候考虑加入日志系统了

首先内部调研了一下, 同部门的安卓组倒是有日志系统, 他们采用的上报方案是通过 http 请求实时上报到后端, 后端将上报来的日志信息输出到 kibana 日志平台供安卓开发人员查询. 这种方案会频繁请求网络造成耗电, 且上报数据有限. 在我看来安卓的这种日志上报更像是埋点上报, 可能比较适合前端网页, 因为网页随时可能被用户关闭, 而且不能在磁盘进行存储, 只能进行实时上报了. 我认为应该充分利用 app 客户端的优势, 将日志写入到本地文件中, 在用户遇到问题时将日志进行上传供开发人员分析.

说干就干, 先把大致思路捋清楚吧

FlexLayout 是 iOS 上的盒式布局框架, 拥有高性能, 接口灵活易用, 职责单一等特点. 最近在组内推行了该框架的使用, 这篇文章对该框架做简要总结