fun getView(ctx: Context, filename: String): View? {
var name = filename
if(!filename.startsWith("assets/")){
name = "assets/$filename"
}
return LayoutInflater.from(ctx).inflate(am.openXmlResourceParser(name), null)
}
修改完代码后，你紧接着开始了第二波测试，却发现程序又抛出了异常：
java.io.FileNotFoundException: Corrupt XML binary file
function throttle(func, wait) {
let timer = 0;
return (...rest) => {
let now = Date.now();
let that = this;
if (now > timer + delay) {
fn.apply(that, rest);
timer = now;
}
};
}
// 定时器版本 节流函数
function throttle(func, wait) {
let timeout;
return function() {
let context = this;
let args = arguments;
if (!timeout) {
timeout = setTimeout(() => {
timeout = null;
func.apply(context, args)
}, wait)
}
}
}
let throttleAjax = throttle(ajax, 1000)
let inputc = document.getElementById('throttle')
inputc.addEventListener('keyup', function(e) {
throttleAjax(e.target.value)
})
通过_NSKVONotifyingCreateInfoWithOriginalClass 的这段伪代码你会发现我们之前频繁提到 indexedIvars 原来就是在这里初始化生成的。objc_allocateClassPair 在 runtime.h 中的声明为 Class _Nullable objc_allocateClassPair(Class _Nullable superclass, const char * _Nonnull name, size_t extraBytes) ，苹果对 extraBytes 参数的解释为“The number of bytes to allocate for indexed ivars at the end of the class and metaclass objects.”，这就是说当我们在通过 objc_allocateClassPair 来生成一个新的类时可以通过指定 extraBytes 来为此类开辟额外的空间用于存储一些数据。系统在生成 KVO 类时会额外分配 0x68 字节的空间，其具体内存布局和用途我用一个结构体描述如下：
由于用到消息转发，我们会将 SD_NSKVONotifying_Test_abcd 的setNum:对应的实现指向_objc_msgForward，然后生成一个新的 SEL__sd_B_abcd_setNum:来指向其子类的原生实现，在我们这个例子中就是 NSKVONotifying_TestsetNum:实现的即void _NSSetIntValueAndNotify(id obj, SEL sel, int number)函数。当 test 实例收到setNum:消息时会先触发消息转发机制，然后 SDMagicHook 的消息调度系统会最终通过向 test 实例发送一个__sd_B_abcd_setNum:消息来实现对被 Hook 的原生方法的回调，而现在__sd_B_abcd_setNum:对应的实现函数正是void _NSSetIntValueAndNotify(id obj, SEL sel, int number)，所以__sd_B_abcd_setNum:就会被作为 sel 参数传递到_NSSetIntValueAndNotify函数。然后当_NSSetIntValueAndNotify函数内部尝试从 indexedIvars 拿到原始类 Test 然后从 Test 上查找__sd_B_abcd_setNum:对应的方法并调用时由于找不到对应函数实现而发生 crash。为解决这个问题，我们还需要为 Test 类新增一个__sd_B_abcd_setNum:方法并将其实现指向setNum:的实现，代码如下：
目前还剩下一个问题“先调用 native-KVO 再调用 custom-KVO 再调用 native-KVO，native-KVO 运行正常，custom-KVO 失效，无 crash”。为什么会出现这个问题呢？这次我们依然以 Test 类为例，首先用 Test 类实例化了一个实例 test，然后对 test 的 num 属性进行 native-KVO 操作，这时 test 的 isa 指向了 NSKVONotifying_Test 类。然后我们再对 test 进行 custom-KVO 操作，这时我们的 custom-KVO 会基于 NSKVONotifying_Test 类再生成一个新的子类 SD_NSKVONotifying_Test_abcd，这时如果再对 test 的 num 属性进行 native-KVO 操作就会惊奇地发现 test 的 isa 又重新指向了 NSKVONotifying_Test 类然后 custom-KVO 就全部失效了。
想要弄明白这个问题首先需要研究清楚系统的 KVO 到底是如何实现的，而系统的 KVO 实现又相当复杂，我们该从哪里入手呢？想要弄清楚这个问题，我们首先需要了解下当对被 KVO 观察的目标属性进行赋值操作时到底发生了什么。这里我们以自建的 Test 类为例来说明，我们对 Test 类实例的 num 属性进行 KVO 操作：
当我们给 num 赋值时，可以看到断点命中了 KVO 类自定义的 setNum:的实现即_NSSetIntValueAndNotify 函数
states:当前应用的运行状态，对于Heimdallr-Example这个应用而言是正在前台运行的状态，这类崩溃我们称之为FOOM(Foreground Out Of Memory)；与此相对应的也有应用程序在后台发生的 OOM 崩溃，这类崩溃我们称之为BOOM(Background Out Of Memory)。
大多数 VM Region 作为一个单独的内存节点，仅记录起始地址和 Dirty、Swapped 内存作为大小，以及与其他节点之间的引用关系；而 libmalloc 维护的堆内存所在的 VM Region 则由于往往包含大多数业务逻辑中的 Objective-C 对象、C/C++对象、buffer 等，可以获取更详细的引用信息，因此需要单独处理其内部节点、引用关系。
获取所有内存节点之后，我们需要为每个节点找到更加详细的类型名称，用于后续的分析。其中，对于 VM Region 内存节点，我们可以通过 user_tag 赋予它有意义的符号信息；而堆内存对象包含 raw buffer，Objective-C/Swift、C++等对象。对于 Objective-C/Swift、C++这部分，我们通过内存中的一些运行时信息，尝试符号化获取更加详细的信息。
Objective/Swift 对象的符号化相对比较简单，很多三方库都有类似实现，Swift在内存布局上兼容了Objective-C，也有isa指针，objc相关方法可以作用于两种语言的对象上。只要保证 isa 指针合法，对象实例大小满足条件即可认为正确。
C++对象根据是否包含虚表可以分成两类。对于不包含虚表的对象，因为缺乏运行时数据，无法进行处理。
对于对于包含虚表的对象，在调研 mach-o 和 C++的 ABI 文档后，可以通过 std::type_info 和以下几个 section 的信息获取对应的类型信息。
let a = '123456444565456.889'
let b = '121231456.32'
// a + b = '123456565796913.209'
function addTwo(a, b) {
//1.比较两个数长度 然后短的一方前面补0
if (a.length > b.length) {
let arr = Array(a.length - b.length).fill(0);
b = arr.join('') + b
} else if (a.length < b.length) {
let arr = Array(b.length - a.length).fill(0);
a = arr.join('') + a
}
//2.反转两个数 （这里是因为人习惯从左往右加 而数字相加是从右到左 因此反转一下比较好理解）
a = a.split('').reverse();
b = b.split('').reverse();
function base64ToBlob(base64, mimeType) {
let bytes = window.atob(base64);
let ab = new ArrayBuffer(bytes.length);
let ia = new Uint8Array(ab);
for (let i = 0; i < bytes.length; i++) {
ia[i] = bytes.charCodeAt(i);
}
return new Blob([ab], { type: mimeType });
}
在一个 Range 首部中，可以一次性请求多个部分，服务器会以 multipart 文件的形式将其返回。如果服务器返回的是范围响应，需要使用 206 Partial Content 状态码。假如所请求的范围不合法，那么服务器会返回 416 Range Not Satisfiable 状态码，表示客户端错误。服务器允许忽略 Range 首部，从而返回整个文件，状态码用 200 。
随着 Web 技术的不断发展，浏览器的功能也越来越强大。这些年出现了很多在线 Web 设计工具，比如在线 PS、在线海报设计器或在线自定义表单设计器等。这些 Web 设计器允许用户在完成设计之后，把生成的文件保存到本地，其中有一部分设计器就是利用浏览器提供的 Web API 来实现客户端文件下载。下面阿宝哥先来介绍客户端下载中，最常见的 a 标签下载 方案。
而图片下载的功能是借助 dataUrlToBlob 和 saveFile 这两个函数来实现。它们分别用于实现 Data URLs => Blob 的转换和文件的保存，具体的代码如下所示：
function dataUrlToBlob(base64, mimeType) {
let bytes = window.atob(base64.split(",")[1]);
let ab = new ArrayBuffer(bytes.length);
let ia = new Uint8Array(ab);
for (let i = 0; i < bytes.length; i++) {
ia[i] = bytes.charCodeAt(i);
}
return new Blob([ab], { type: mimeType });
}
// 保存文件
function saveFile(blob, filename) {
const a = document.createElement("a");
a.download = filename;
a.href = URL.createObjectURL(blob);
a.click();
URL.revokeObjectURL(a.href)
}
在 文件上传，搞懂这8种场景就够了 这篇文章中，阿宝哥介绍了如何利用 JSZip 这个库提供的 API，把待上传目录下的所有文件压缩成 ZIP 文件，然后再把生成的 ZIP 文件上传到服务器。同样，利用 JSZip 这个库，我们可以实现在客户端同时下载多个文件，然后把已下载的文件压缩成 Zip 包，并下载到本地的功能。对应的操作流程如下图所示：
在以上 Gif 图中，阿宝哥演示了把 3 张素材图，打包成 Zip 文件并下载到本地的过程。接下来，我们来介绍如何使用 JSZip 这个库实现以上的功能。
//显示PopupWindow publicvoidshowAtLocation(View parent, int gravity, int x, int y) {
mParentRootView = new WeakReference<>(parent.getRootView());
showAtLocation(parent.getWindowToken(), gravity, x, y);
}
//显示PopupWindow publicvoidshowAtLocation(IBinder token, int gravity, int x, int y) { if (isShowing() || mContentView == null) { return;
}
platform :ios, '11.0' project 'iOSPlayground.xcodeproj' target 'iOSPlayground'do pod 'SDWebImage', '~> 5.6.0' pod 'SDWebImageLottieCoder', '~> 0.1.0' pod 'SDWebImageWebPCoder', '~> 0.6.1' end
然后执行 Pod install 命令 bundle exec pod install，CocoaPods 开始为你构建多依赖的开发环境；整个 Pod Install 流程最核心的就是 ::Pod::Installer 类，Pod Install 命令会初始化并配置 Installer，然后执行 install! 流程，install! 流程主要包括 6 个环节
def install! prepare resolve_dependencies # 依赖决议 download_dependencies # 依赖下载 validate_targets # Pods 校验 generate_pods_project # Pods Project 生成 if installation_options.integrate_targets? integrate_user_project # User Project 整合 else UI.section 'Skipping User Project Integration' end perform_post_install_actions # 收尾 end
下面会对这 5 个流程做一些简单分析，为了简单起见，我们会忽略一些细节。
准备阶段
这个流程主要是在 Pod Install 前做一些环境检查，并且初始化 Pod Install 的执行环境。
Pod Install 执行完成后，就将 User Target 整合到了 CocoaPods 环境中。User Target 依赖 Aggregate Target，Aggregate Target 依赖所有 Pod Targets，Pod Targets 按照 Pod 描述文件（Podspec）中的依赖关系进行依赖，这些依赖关系保证了编译顺序
iOSPlayground 工程中 User Target: iOSPlayground 依赖了 Aggregate Target 的产物 libPods-iOSPlayground.a
CocoaPods 的依赖版本决议流程是基于 Molinillo 的，Molinillo 是基于 DAG 来进行依赖解析的，通过构建图可以方便的进行依赖关系查找、依赖环查找、版本降级等。但是使用图来进行解析是有成本的，实际上大部分的本地依赖决议场景并不需要这么复杂，Podfile.lock 中的版本就是决议后的版本，大部分的研发流程直接使用 Podfile.lock 进行线性决议就可以，这可以大幅加快决议速度。
Specification 缓存
依赖分析流程中，CocoaPods 需要获取满足约束的 Specifications，1.7.5 上的流程是获取一个组件的所有版本的 Specifications 并缓存，然后从 Specifications 中筛选出满足约束的 Specifications。对于复杂的项目来说，往往对一个依赖的约束来自于多个组件，比如 A 依赖 F(>=0)，B 依赖 F (>=0)，在分析完 A 对 F 的依赖后，在处理 B 对 F 的依赖时，还是需要进行一次全量比较。通过优化 Specification 缓存层可以减少这部分耗时，直接返回。
module Pod::Specification::Set def all_specifications(warn_for_multiple_pod_sources, requirement) @all_specifications ||= {} @all_specifications[requirement] ||= begin #... end end end
module Pod::Requirement def eql?(other) @requirements.eql? other.requirements end end
循环依赖发现
当出现循环依赖时，CocoaPods 会报错，但报错信息只有谁和谁之间存在循环依赖，比如：
There is a circular dependency between A/S1 and D/S1
随着工程的复杂度提高，对于复杂的循环依赖关系，比如 A/S1 -> B -> C-> D/S2 -> D/S1 -> A/S1, 基于上面的信息我们很难找到真正的链路，而且循环依赖往往不止一条，subspec、default spec 等设置也提高了问题定位的复杂度。我们优化了循环依赖的报错，当出现循环依赖的时候，比如 A 和 D 之间有环，我们会查找 A -> D/S1 之前所有的路径，并打印出来：
There is a circular dependency between A/S1 and D/S1 Possible Paths：A/S1 -> B -> C-> D/S2 -> D/S1 -> A/S1 A/S1 -> B -> C -> C2 -> D/S2 -> D/S1 -> A/S1 A/S1 -> B -> C -> C3 -> C2 -> D/S2 -> D/S1 -> A/S1
在 Pods 工程生成流程中有三个流程会比较耗时，这些数据每次 Pod Install 都需要重新生成：
Pod 目录下的文件和目录列表，需要对目录下的所有节点做遍历；
Pod 目录下的动态库列表，需要分析二进制格式，判断是否为动态库；
Pod 文件的访问策略缓存 glob_cache，这个 glob_cache 是用于访问组件仓库中不同类型文件的，比如 source files、headers、frameworks、bundles 等。
但其实这些数据对固定版本的依赖都是唯一的，如果可以缓存一份就可以避免二次生成导致的额外耗时，我们补充了这个缓存层，以抖音为例子，使 Pod Clean Install 减少了 36%，Pod No-clean Install 减少了 42%
添加 FileAccessors 缓存层后，在效率上获得提升的同时，在稳定性上也获得了提升。因为在本地记录了 Pod 完整的文件结构，因此我们可以对 Pod 的内容做检查，避免 Pod 内容被删除导致构建失败。比如研发同学误删了缓存中的二进制库，CocoaPods 默认是难以发现的，需要延迟到链接阶段报 Symbol Not Found 的错误，但是基于 FileAccessors 缓存层，我们可以在 Pod Install 流程对 Pod 内容做检查，提前暴露出二进制库缺失，触发重新下载。
提高编译并发度
Pod Target 的依赖关系会保证 Target 按顺序编译，但是会导致 Target 编译的并发度下降，一定程度上降低了编译效率。其实生成静态库的 Pod Target 不需要按顺序进行编译，因为静态库编译不依赖产物，只是在最后进行链接。通过移除静态库的 Pod Target 对其他 Target 的依赖，可以提高整体的编译效率。
在 Multi Project 下，「Dependency Subproject」会导致索引混乱，移除静态库的 Pod Target 对其他 Target 的依赖后，我们也可以删除 Dependent Pod Subproject，减少 Xcode 检索问题。
Arguments Too Long
超大型工程在编译时稳定性降低，往往会因为工程放置的目录长产生一些未定义错误，其中错误比较大的来源就是 Arguments Too Long，表现为：
Build operation failed without specifying any errors ；Verify final result code for completed build operation
组件化的一个目标是业务代码按架构设计拆分成组件 Pod。但如果在一个组件中新增文件，比如在组件 A 中新增文件，依赖组件 A 的组件 B 是不能直接访问新增文件的头文件的，需要重新执行 Pod Install，这样会影响整体的研发效率。
为什么组件 B 不能够访问组件 A 的新增文件？在 Pod Install 后，组件 A 公共访问的头文件被索引在 Pods/Headers/Public/A/ 目录下，组件 B 的 HEADER_SEARCH_PATH 中配置了 Pods/Headers/Public/A/，因此就可以在组件 B 的代码里引入组件 A 的头文件。新增头文件的头文件没有在目录中索引，所以组件 B 就访问不到了。只需要在添加文件后，建立新增头文件的索引到 Pods/Headers/Public/A/目录下，就可以为组件 B 提供组件 A 新增文件的访问能力，这样就不需要重新 Pod Install 了。
Lockfile 生成
在依赖管理的部分场景中，我们只需要进行依赖决议，重新生成 Podfile.lock，但通过 Pod Install 生成是需要执行依赖下载及后续流程的，这些流程是比较耗时的，为了支持 Podfile.lock 的快速生成，可以对 install 命令做了简化，在依赖决议后就可以直接生成 Podfile.lock：
class Pod::Installer def quick_generate_lockfile! # 初始化 sandbox 环境 quick_prepare_env quick_resolve_dependencies quick_write_lockfiles end end
首先我们假设所有数据都是二维空间下的点，我们从图中这个R8区域说起，也就是那个shape of data object。别把那一块不规则图形看成一个数据，我们把它看作是多个数据围成的一个区域。为了实现R树结构，我们用一个最小边界矩形恰好框住这个不规则区域，这样，我们就构造出了一个区域：R8。R8的特点很明显，就是正正好好框住所有在此区域中的数据。其他实线包围住的区域，如R9，R10，R12等都是同样的道理。这样一来，我们一共得到了12个最最基本的最小矩形。这些矩形都将被存储在子结点中。
但最近在暑期实习的日子里，我特意留心观察了一下身边的实习生同学使用工具的习惯。我发现自己在大学认为高效率的工作模式，他们无论在意识层面还是在使用层面上对工具的掌握都有些蹩脚。特别是有部分同学 Mac 也没有怎么接触过，算是效率领域的门外汉了。所以本着做个负责的好师兄的态度，我将自己对工具使用的经验，分享给大家。也算是抛砖引玉，和大家一起聊聊有哪些 NB 又和好玩的工具。
需要注意的是：我这里主要以 Mac Apple 生态作为基调，但我相信工具和效率提升的思想是不变的，Win 下也有具体的工具可以替代，所以 Win 的同学也可以认真找一找，评论回复一下 Win 下的替代方案吧 🙏🏻
当然，👇 的工具，我没有办法在这种汇总类的文章里面讲透彻，所以都「点到为止」，给了相关扩展阅读的文章，所以感兴趣的话大家再外链出去研究一番，或者自行 Google 社区的优质资源 ~
主打 Mac 上的自动化流程。通过 👇 这种可视化编程的思路，创建一种动作流。比如我想实现通过 Cmd + Alt + B 搜索 Chrome 书签 🔖。社区的小伙伴们就已经帮我们实现了一套工作流。我们可以直接在 Alfred 的社区 Packtal 等论坛去下载已经实现的 Workflow 去实现这些日常生活中的小自动化流程。
再比如上面的：
ChromeHistory：搜索 Chrome 历史记录（在 Alfred 搜索中）
GithubRepos：浏览搜索自己的 GithubRepo
Colors：快速转换前端颜色（前端同学一定知道为什么这个常用）🙈
... 等等等等
我们也可以定义自己的工作流来自动化一些流程，我用自身的一个 Case 来说，我会定义很多快捷键来绑定我自己的日常操作。比如：
function compose(...fns) {
return function composed(result){
// 拷贝一份保存函数的数组
var list = fns.slice();
while (list.length > 0) {
// 将最后一个函数从列表尾部拿出
// 并执行它
result = list.pop()( result );
}
return result;
};
}
// ES6 箭头函数形式写法
var compose =
(...fns) =>
result => {
var list = fns.slice();
while (list.length > 0) {
// 将最后一个函数从列表尾部拿出
// 并执行它
result = list.pop()( result );
}
return result;
};
var error:NSError? let possibleCameraInput: AnyObject? = AVCaptureDeviceInput.deviceInputWithDevice(backCameraDevice, error: &error) if let backCameraInput = possibleCameraInput as? AVCaptureDeviceInput { if self.session.canAddInput(backCameraInput) { self.session.addInput(backCameraInput) } }
var pointInPreview = focusTapGR.locationInView(focusTapGR.view) var pointInCamera = previewLayer.captureDevicePointOfInterestForPoint(pointInPreview) ...// 锁定，配置
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
动态类型就是说运行时才确定对象的真正类型。例如我们可以向一个 id 类型的对象发送任何消息，这在编译期都是合法的，因为类型是可以动态确定的，消息真正起作用的时机也是在运行时这个对象的类型确定以后，这个下面就会讲到。我们甚至可以在运行时动态修改一个对象的 isa 指针从而修改其类型，OC 中 KVO 的实现正是对动态类型的典型应用。
Alters the order in which functions and data are laid out. For each section in the output file, any symbol in that section that are specified in the order file file is moved to the start of its section and laid out in the same order as in the order file file.
程序的运行是出于满足人们对某种逻辑需求的处理，在计算机上表现为可执行指令，正常情况下我们期望的指令是按逻辑的顺序依次执行的，而实际情况由于某些指令是耗时操作，不能立即返回结果而造成了阻塞，导致程序无法继续执行。这种情况多见于一些io操作。这时，对于用户层面来说，我们可以选择stop the world，等待操作完成返回结果后再继续操作，也可以选择继续去执行其他操作，等事件返回结果后再通知回来。这就是从用户角度来看的同步与异步。
Future<void> main() async { var startTime = DateTime.now().second; var bannerList = getBannerList(); var homeTabList = getHomeTabList(); var homeMsgList = getHomeMsgList();
