PPT 模版

这是一个 PPT 的大纲.

今天被反馈了一个 UIPageControl 莫名错位的线上问题, 本应在屏幕底部中间的指示器, 突然跑到了屏幕的右下角, 经过定位, 是 pageControl的宽度由 428 变成了 856 导致的, hook 了 pageControl 的 setFrame: 后, 断点停在了自动布局的堆栈, 系统自动布局计算宽度就是 856, 一番 Google 后最后发现是 autoresizingMask 的问题.

由于原文已经删除, 在此转载供个人学习记录.

[转载]OCS:史上最疯狂的iOS动态化方案

在iOS的发展历程上，涌现了很多动态化方案，有历史悠久的WaxPatch动态化方案，有远近闻名的JSPatch动态化方案。今天我们向大家介绍一款堪称“史上最疯狂”的iOS动态化方案——OCS.

初窥OCS

OCS是全新设计的iOS动态化方案。我们定义了一套精确描述OC语义的字节码指令集(OCScript)，开发了一套全自动编译器（OCSCompiler），实现了一个高性能的虚拟机（OCSVM）以及一个可以跟底层无缝对接的桥接器(OCSBridge)。我们首先使用OCS编译器把OC源码转化成OCS字节码，然后通过OCS桥接器实现OCS虚拟机与Native运行时的互联，最后使用OCS虚拟机对OCS字节码进行解释运算，并驱动Native运行时完成逻辑的执行，以此达到Native代码动态化的效果。OCS被用于iOS APP安装包减包、功能插件化、HotPatch等方方面面动态化需求。

iOS 工程在云服务器打包, 打普通的体验包没问题, 但是打 TestFlight 包就报错, 错误日志如下

1
2
3
4

IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path '/var/folders/rw/4zvtml0922j4k36bbjxbny380000gp/T/App_2022-03-03_18-38-20.927.xcdistributionlogs'.
xcodebuild[39445:78833] [MT] IDEDistributionMethodManager: -[IDEDistributionMethodManager orderedDistributionMethodsForTask:archive:]: Error = Error Domain=IDEDistributionMethodManagerErrorDomain Code=2 "Unknown Distribution Error" UserInfo={NSLocalizedDescription=Unknown Distribution Error}
exportArchive: exportOptionsPlist error for key 'method': expected one of {}, but found app-store
Error Domain=IDEFoundationErrorDomain Code=1 "exportOptionsPlist error for key 'method': expected one of {}, but found app-store" UserInfo={NSLocalizedDescription=exportOptionsPlist error for key 'method': expected one of {}, but found app-store}

从上面日志粗略看是编译错误, 搜索相关的错误描述, 网上会有不少相关案例, 在问题分析定位结束后, 解决方案是这一个xcodebuild -exportArchive: exportOptionsPlist error for key ‘method’: expected one of {}, 将子工程的 SKIP_INSTALL 设置为 YES. 但是要注意的是 子工程的 Project 设置以及 Target 设置都应该设置为 YES, 我一开始只设置了 Target 的, 子工程 Project 设置的 SKIP_INSTALL 未设置, 默认值是 NO, 导致后续浪费了很多时间. 以及移除子工程中 “Build Phase” 的’Headers’选项, 两个改动后 tf 可以正常打包.

记录一次遇到线上问题处理的步骤.

线上问题处理步骤

1. 评估影响 影响范围以及严重程度.
   1. 是不是核心路径
   2. 影响级别, 是显示问题还是必现崩溃
   3. 影响用户量级
      1. 如果有线上上报, 查询上报数据库可知道影响量级.
      2. 根据当前版本 DAU 以及反馈数推测影响量级.
      3. 统计每个用户触发次数.
2. 定位问题, 及时或定时(半小时或一小时)同步结论.
   1. 确定引入问题时间以及原因.
   2. 评估修复方案.
   3. 是否需要紧急合入代码, 如果是灰度发现问题, 就可以通过合代码解决.
   4. 总结问题出现原因, 以及避免方案.
3. 确定是否有线上修复方案.
   1. 配置文件修改能否屏蔽问题.
   2. 后端配合修改能否解决.
   3. 是不是有热修复方案(Hotfix).

在 RFC 3986 文档中规定，URL 中只允许包含以下四种：

1. 英文字母 a-z 以及 A-Z
2. 数字 0-9
3. 4个特殊字符：中横线 -、下划线 _、小数点 . 以及波浪线 ~
4. 保留字符：!*’();:@&=+$,/?#[]

除上述四种字符外，所有其他字符都将被替换成百分号 % + 两位十六进制数。

<iOS应用架构谈> 学习笔记

本篇内容全部来自于 https://casatwy.com/ iOS应用架构谈 系列文章

iOS应用架构谈 开篇

架构要考虑的事情

1. 调用网络API (网络) 如何让业务开发工程师方便安全地调用网络API？然后尽可能保证用户在各种网络环境下都能有良好的体验？
2. 页面展示 (UI) 页面如何组织，才能尽可能降低业务方代码的耦合度？尽可能降低业务方开发界面的复杂度，提高他们的效率？
3. 数据的本地持久化 (数据库) 当数据有在本地存取的需求的时候，如何能够保证数据在本地的合理安排？如何尽可能地减小性能消耗？
4. 动态部署方案 iOS应用有审核周期，如何能够通过不发版本的方式展示新的内容给用户？如何修复紧急bug？

iOS 开发 - 衡量图片加载及优化思路

图片展示是移动端开发非常重要的功能, 从展示 App 内置的图片到 Instagram 这样的图片 Feed 流应用, 图片加载消耗了巨大的带宽, 占用手机大部分的内存, 也在指尖的滑动过程中不断消耗着 CPU 资源. 本文将以优秀的开源库 SDWebImage 为例, 从开发的角度来衡量图片加载这一功能, 并会涉及到缓存/解码/图片格式等问题的研究, 从而引出后续优化方案.

MessageThrottle 结合业务需求的修改

MessageThrottle 是什么, 解决了什么痛点

MessageThrottle 是使用 Objective-C 实现的 iOS 函数节流(Throttle)和防抖(Debounce)的工具库. 在实现 App 交互的时候, 逻辑的刷新太频繁会导致性能上的问题, 比如不断有新的数据加载导致列表一直在刷新, 按钮的点击速度太快导致逻辑被多次执行, Slider 或者 滑动手势等频繁回调导致性能跟不上, 数据一直在变化导致耗费诸多性能在中间状态上等. 在业务层, 我们经常要结合业务来做限频或者定时刷新等逻辑, 来解决上面这些问题, 但是 MessageThrottle 提供了新的思路, 在不耦合业务逻辑的情况下, 实现间隔性消息调用, 即函数节流(Throttle)和防抖(Debounce).

使用 MessageThrottle, 只需如下简单的代码

崩溃???

今天在开发一个列表需求, 由于有非常多因素导致列表变化, 所以需要方法节流（throttle）, 直接使用了MessageThrottle 这个第三方库. 然后由于需求本身也使用了 ReactiveObjC 来开发, 当页面的 vm 跟 RAC 绑定, 然后又使用 MessageThrottle 时, 退出页面, RAC开始了释放逻辑, 而 MessageThrottle 防抖模式下, 延时执行被”节流”的方法, 最终导致应用崩溃.