最近遇到一个问题, 需要定位到 TableView 的某一行, 历史代码是使用

1

- (CGRect)rectForRowAtIndexPath:(NSIndexPath *)indexPath;

获取到对应的cell 在 TableView 上的位置, 然后再根据业务做了一些简单的计算, 最后使用

1

- (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated;

跳转到最终的位置.

但是由于这个业务比较复杂, 为了性能, 开启了预估行高(estimatedHeightForRowAtIndexPath), 实际上, TableViewCell 的高度也根据业务各不一样, 预估值也与实际情况出入较大, 导致上面的 setContentOffset 跳到了不正确的行高.

团队协作培养

团队融入

• 信任建立：
  • 主动引荐新人认识团队
  • 通过日常接触（饭搭子 / 散步/ 运动健身）、非正式交流（咖啡 / 奶茶）消除心理屏障,
    • 工作生活上的经验分享
    • 需求进度卡点交流
• 合理授权：
  • 鼓励新人独立负责任务 (了解新人是什么样的类型)
    • 爱学习的人可以减少干扰, 以答疑为主, 引导独立思考并发表观点
    • 偏懒惰的人需要积极引导, 必要时可以请上级出面帮忙给点压力
  • 导师适时把关，避免亲力亲为。

原文地址

前情描述

针对iOS客户端部署一套完善的静态代码检测系统。

目前市面开源的方案

原文地址

知其然，然后知其所以然。本文主要是对学习赛博活佛Andrej Karpathy 7个小时教学视频的总结和拓展阅读笔记，推荐去看原视频，很精彩，链接在文末。从最常用的聊天应用过程分析开始，引入对话过程原理浅析，再到LLM训练过程；再结合当前主流的应用形式，在得知最新用法的同时，加深对LLM的理解；再谈谈AI的最新重大进展MCP；以及作为JAVAer，在Java领域有哪些前沿能力去整合LLM。

最后再罗列一下在公司内部一些AI平台、工具。最好的学习方法是带着问题去寻找答案，以费曼学习法为标准，产出可教学的资料。本文是个人所学梳理和所想记录，作为AI的小白，个人知识有限，难免有所错误、疏漏，请及时纠偏、不吝赐教，感谢。

最近做需求时候, 遇到一个后端联调问题, 需求是 后端A 把一个 json 转成 string 后放到 scheme 的payload参数中, json 如下, text1 是一个字符串,

1
2
3
4

{
    "text1": "今天是个好日子", 
    "trackID1": 123456
}

转换为字符串payload后变成

1

{\"text1\":\"今天是个好日子\",\"trackID1\":123456}

scheme 大致如下:

1

scheme://test/ui/func?p={"hintPayload":"{\"text1\":\"今天是个好日子\",\"trackID1\":123456}","param2":"9"}

然后对 scheme 转义, 下发给客户端, 客户端在解析 scheme 后, 获取各个参数, 然后把payload 字符串给另一个业务后端B.
自测阶段没什么问题, 但是测试发现text1中有换行符以及"时候就不行了, 客户端问题就出在解析 scheme 时候, 会对参数做一次 string 转 json 处理, 这次处理失败了.

原文地址

1、前言

众所周知，微信在后台服务器不保存聊天记录，微信在移动客户端所有的聊天记录都存储在一个 SQLite 数据库中，一旦这个数据库损坏，将会丢失用户多年的聊天记录。而我们监控到现网的损坏率是0.02%，也就是每 1w 个用户就有 2 个会遇到数据库损坏。考虑到微信这么庞大的用户基数，这个损坏率就很严重了。更严重的是我们用的官方修复算法，修复成功率只有 30%。损坏率高，修复率低，这两个问题都需要我们着手解决。

原文地址

前言

Matrix 是微信终端自研和正在使用的一套 APM（应用性能管理）系统。

SQLite 在移动端开发中广泛使用，其使用质量直接影响到产品的体验。微信是个重度使用 SQLite 的应用，相关的质量检测也是质量监控体系中不可忽视的一部分。  

常见的 SQLite 质量监控一般都是依赖上线后反馈的机制，比如耗时监控或者用户反馈。这种方式问题是：事后发现，负面影响已经发生。

关注的只是没这么差。eg. 监控阈值为 500ms ，那么一条可优化为 20ms 而平均耗时只有 490ms 的 sql 就被忽略了。

能否在上线前就进行SQLite使用质量的监控？于是我们尝试开发了一个工具: SQLiteLint。虽然名带 “lint “，但并不是代码的静态检查，而是在 APP 运行时对 sql 语句、执行序列、表信息等进行分析检测。而和 “lint” 有点类似的是：在开发阶段就介入，并运用一些最佳实践的规则来检测，从而发现潜在的、可疑的 SQLite 使用问题。

本文会介绍 SQLiteLint 的思路，也算是 SQLite 使用经验的分享，希望对大家有所帮助。

最近遇到了 hexo 标签打不开的问题, 同一个标签, 比如 Swift, 有的文章使用的是 swift, 有的文章又是 Swift, 我尝试把所有文章的小写单词都换成大写, 在本地预览无误, 但是推到服务器后发现还是打不开, 点击Swift标签, 打开的页面却是https://xxx/tags/swift/, 同时页面显示 404, 在服务器上查看 tag 下的目录, 也是 swift, 删掉该目录重新推一次, 仍旧无法解决.

原文地址

如果你爱 SwiftUI😍，那你很可能也恨 SwiftUI Preview😡。

之所以这么说，是因为大部分使用 SwiftUI 的开发者，都或多或少遇到过这样的一个界面：

原文地址

💡 能，但还比较勉强。

在客户端上跑大模型，一定是未来的趋势。

1. 上个时代 AI 的核心应用是推荐系统，推荐是依赖海量数据的，海量数据只有服务端上存在，在推荐这主场景下客户端 AI 上能做的事很少，发展得比较吃力。
2. 生成式 AI 时代，最大的应用就是模型本身，只有训练时依赖海量数据，使用时并不依赖数据，那理论上只要客户端硬件资源足够，在客户端使用，跟在服务端使用，场景和效果是一致的。
3. 生成式 AI 在端上跑模型，最大的优势是成本。成本是当前生成式 AI 应用除了效果以外第二大关键因素，在用户客户端上跑模型，对服务提供方来说就是 0 成本，0 成本使更多场景大规模免费应用成为可能。其他的优势还包括 隐私保护、实时性、离线可用。