docs: 增加系统 UI API 子线程监控能力，并输出堆栈

Chapter1 - iOS/1.90.md

@@ -26,4 +26,28 @@ _imageView.image = image;
 
 pthread_mutex_lock
 
-pthread_mutex_unlock
+pthread_mutex_unlock
+
+
+## 内存方面
+图片相关小建议
+目前对于大图片没有特别好的方法进行内存峰值的控制
+内存峰值：解码一瞬间带来的内存压力，无关最终图片可能缩放的大小
+1. 下发图片不要太大，字节内部大多数直接接入 ImageX 可以直接控制，
+图片下发尽可能不要超大类型的图片，这样对客户端下载和解码带来的压力都不低
+( 字节ImageX 外部也可接入服务 )
+2. 大部分主流图片库支持 Force Redraw 概念，默认都是开启的
+ForceRedraw 开启：3倍内存峰值，提升FPS
+ForceRedraw 关闭：2倍内存峰值，直到需要图片才进行渲染，降低 FPS
+( 字节图片库可以指定是否开启 )
+3. 如果是用户上传的图片，可以选择显示图片大小有一定范围，比如最大不超过 1920x1080，
+否则本地进行图片缩小后上传
+4. 部分低端机可以增加更多的解码限制，举例：
+iPhone6 内存大小为 1GB，iPhone6s 内存大小为 2GB
+对于 iPhone6 而言，一张 4000x6000，或着三张 1920x1080同时解码，就是压力的极限
+对于 iPhone6s 而言，两张 4000x6000，或着五张 1920x1080同时解码，就是压力的极限
+( 字节图片库支持提前获取图片大小，然后让选择是否解码图片的功能 )
+5. 图片解码后可以进行降采样
+虽然无法控制解码当时的内存峰值，但是对于解码后的图库可以进行缩放，
+例如在一个 100x100 的UIImageView 里展示一张 4000x6000的图片，显然非常浪费
+( 字节的图片库也支持自动降采样操作 )

Chapter1 - iOS/1.99.md

@@ -1,9 +1,10 @@
 #  App 质量把控
 
 > 笔者结合中台经验，本文重点谈谈 App 的质量稳定性该如何做。业务作为 App 的核心服务之一，业务异常监控当然也很重要，这不是本文重点。
-## 质量问题的现状
-对于质量问题，直接以小故事的形式展开。
 
+## 质量问题的现状
+
+对于质量问题，直接以小故事的形式展开。下面是移动中台年度针对质量复盘的一些思考
 
 1. 技术方案阶体现测试用例
 对于业务项目来说，会存在测试资源、冒烟用例、精准测试、QA 新业务的业务回归、核心业务的 UI 自动化、高铁阶段的 QA 人工回归等。这里简单讲讲这些词语，对于新的业务项目，一定会有测试资源，简单说就是 QA，新项目在经过 PRD、MRD、需求讨论会、Kick-off 之后，技术方案评审后，会经过测试用例评审，产出的结果就是用例指南，到时候 QA 会在用例平台指配给对应的开发。