代际差异
| 代际 | 关键词 | 重大历史事件 | 备注 |
|---|---|---|---|
| 60 | 情怀 | 改革开放 结束文革 |
|
| 70 | 闷骚 | 改革中 | 表面平淡 内心强大 |
| 80 | 纠结 | 市场经济 50 后父母 |
最辛苦的一代, 也是个人奋斗回报最大的一代 |
| 90 | 任性 | 计划生育 互联网 |
|
| 95 | 迷茫 | (更严格的)计划生育 二次元(廉价消费) |
人群:宅男腐女, 证明经济转衰(米哈游的崛起) |
| 00 | 淡定 | 民族复兴 70 后父母 |
[转载] 闲话 APPLE 的 APP REVIEW 趣事
闲话 Apple 的 App Review 趣事
起因是因为 Epic 和 Apple 的官司结案了，突然想起来之前看过的一些材料，就顺手整理了这份杂文，里面的很多内容在时效性上已经比较落后了，不一定与当下完全一致，不过当个奇闻轶事读读也好啦！
一份被忽视的资料
对于外界而言，Apple 的 App Review 团队一直都显得十分神秘，直到 2019 年 CNBC 的一篇名为《Inside Apple’s team that greenlights iPhone apps for the App Store》的文章发布后，大家才对其有了一定的了解。
其中有不少特别有意思的冷知识，例如审核人员会通过 Mac 电脑访问一个叫 App Claim 的 Web 网站，批量审核应用，然后他们通常会在 iPad 上审核应用，即使这是一款 iPhone 应用。（Reviewers “claim” a batch of apps through a web portal on a Mac desktop, called App Claim. They often examine the app on an attached iPad, even if it’s an iPhone app.）
所以，我突然明白了为什么早年间，即使我们提交的是 iPhone 应用，但在拒审邮件的截图附件中，总是能看到 iPad 屏幕截图的身影，现在看来，原来如此~
不过，去年 Epic 和 Apple 的官司 又一次把 App Review 团队带到了大众的视野中。
[转载] App 二进制文件重排已经被玩坏了
『二进制文件重排优化启动速度』本是一项上古 PC 时代就玩过的东东，前一阵子借助某宇宙大厂重新火了一把。不过令我惊讶的是：这么简单个事情竟然搞得如此复杂，而且还声称『开拓性的探索、在没有业界经验可供参考』。。。
说真话可能会得罪人，但是我怕过吗？ 我怂了，这段掐了。
其实二进制文件重排很简单啊，重点在于生成 order 文件。我基于 Clang SanitizerCoverage 和业界已有的经验，整了个 AppOrderFiles，一个调用搞定！Enjoy it！
iOS 面试题
发表于
本文字数： 166k 阅读时长 ≈ 2:31
本文字数： 166k 阅读时长 ≈ 2:31
Welcome to my blog, enter password to read.
Fishhook & mach-O
hook 在 iOS 开发中又叫 Swizzle Method, 简单说就是交换两个函数/方法的地址, 一般是交换某个系统方法和自己实现的方法, 用于实现对系统行为的监控或者边界保护.
iOS 开发中有多种 hook 的方法, 本文主要聚焦于 fishhook 的实现与应用
iOS17 Autorelease 底层改变导致不规范代码失效
今天收到一个反馈, 说有个按钮突然不显示, 排除了网络配置等因素的影响后, 查看文件修改记录, 发现最近一年都没有动过相关代码, 一时有点尬住了. 按钮的明明有 getter 方法, 但是加到 UI 上的时候就变成 nil 了, 排查代码也没有逻辑对按钮的 property 置空. 所以直接看 property 定义如下:
1 | @property (nonatomic, weak) UIButton *emptyButton; |
居然是个 weak 属性.
PNG 文件结构解析
PNG 的二进制文件由文件头(文件署名域, 决定文件类型)加上多个块组成, 其中每个块又有四个部分, 如下:
| 名称 | 字节数 | 说明 |
|---|---|---|
| Length（长度） | 4字节 | 指定数据块中数据域的长度, 其长度不超过（231- 1）字节 |
| Chunk Type Code（数据块类型码） | 4字节 | 数据块类型码由ASCII字母（A-Z和a-z）组成 |
| Chunk Data（数据块数据） | 可变长度 | 存储接照Chunk Type Code指定的数据 |
| CRC（循环冗余检测） | 4字节 | 存储用来检测是否有错误的循环冗余码 |
[转载] iOS微信内存监控
FOOM（Foreground Out Of Memory），是指App在前台因消耗内存过多引起系统强杀。对用户而言，表现跟crash一样。Facebook早在2015年8月提出FOOM检测办法，大致原理是排除各种情况后，剩余的情况是FOOM，具体链接。
微信自15年年底上线FOOM上报，从最初数据来看，每天FOOM次数与登录用户数比例接近3%，同期crash率1%不到。而16年年初某东老大反馈微信频繁闪退，在艰难拉取2G多日志后，才发现kv上报频繁打log引起FOOM。接着16年8月不少外部用户反馈微信启动不久后闪退，分析大量日志还是不能找到FOOM原因。微信急需一个有效的内存监控工具来发现问题。
[转载] Matrix for iOS macOS 卡顿监控原理
Matrix-iOS 卡顿监控
前言
–
在早期开发 iOS 微信的过程中，我们时不时会收到类似的反馈：
- “我的微信卡在主界面，怎么也滑动不了”
- “我的微信从后台切换前台卡了一下，最近偶尔会遇到几次”，等等。
这类问题有个共同点：用户的微信在一段时间内无法点击；即使获得用户的操作路径，也无法重现。 我们把这类问题叫做卡顿问题。这类问题很影响用户的体验，是必须进行解决的。为了精确地定位用户的卡顿问题，iOS 微信在 2014 年 9 月份上线了卡顿监控系统。在这几年间，卡顿监控经历了几次优化，不断成熟，在这里我们将其分享出来。