关于OOMDetector更新的几点建议

[youngsoft]

因为看到有这个不错的工具，因此在研究集成到工程中去，特意花了几天把源代码研读一番，下面是个人给出的几个建议希望能尽快升级这个库：

1.bool CStackHelper::isInAppAddress(vm_address_t addr)这个函数的实现不完全正确，第0个image的内容不一定就是可执行程序本身，有可能是dyld库或者其他一些比如用于XCODE调试和分析的一些支持库。

2.对于程序中获取所有image信息的数据结构AppImages看到只在一处进行初始化构建，但是实际中某些image是可能在运行时动态加载和卸载的，因此需要有一个机制能够在运行时动态更新所有的image信息。还是bool CStackHelper::getImageByAddr(vm_address_t addr,segImageInfo *image)这个函数有可能会返回false然后我看代码里面有不少这个函数的使用，当返回false时不进行处理，这样就如我上面说的某一些在运行时加载的image就无法查找到对应的信息从而漏了记录。

3.建议对获取的image信息进行开始地址和结束地址排序排列，这样在进行一些地址归属某个image时比如：bool CStackHelper::getImageByAddr(vm_address_t addr,segImageInfo *image)函数就可以用二分查找法来增强性能。

4.在编程风格上看到有OC代码有C++代码，但是代码中貌似没有语言层面分层的概念，有时候在众多C++代码中又突然调用OC代码，然后OC代码中又突然调用C++代码。这样的设计方法我觉得有待优化。

5.最后，优秀的开源库还是值得去接入和使用的。

[rosen0510]

1、2、3点感谢建议，我们尽快支持，也欢迎pr过来！第4点是因为有些OC的hook需要用oc实现，然后对外的接口都要用OC或者C封装，直接提供C++接口会有标准不统一带来的ABI兼容问题。

[HePingLaoSan]

对于程序中获取所有image信息的数据结构AppImages看到只在一处进行初始化构建，但是实际中某些image是可能在运行时动态加载和卸载的，因此需要有一个机制能够在运行时动态更新所有的image信息。

1、3点赞同，第二点有疑问望解答，所说的运行时动态加载和卸载场景有哪些？除了不能上架AppStore的app，应该动态库（系统库除外）都是在启动的时候已经load成功的吧？

[youngsoft]

对于动态库的问题。系统是可以在运行时动态加载其内部的系统动态库的。所以动态库以及image的数量是可变的。另外是否可以在运行时动态加载程序中Frameworks目录下的动态库呢？如果可以的话那这个也是一个运行时加载的动态库了。

[tripleCC]

对于动态库的问题。系统是可以在运行时动态加载其内部的系统动态库的。所以动态库以及image的数量是可变的。另外是否可以在运行时动态加载程序中Frameworks目录下的动态库呢？如果可以的话那这个也是一个运行时加载的动态库了。

可以在运行时 dlopen Frameworks 目录下的动态库，
https://stackoverflow.com/questions/6530701/is-the-function-dlopen-private-api

[tripleCC]

对于程序中获取所有image信息的数据结构AppImages看到只在一处进行初始化构建，但是实际中某些image是可能在运行时动态加载和卸载的，因此需要有一个机制能够在运行时动态更新所有的image信息。

1、3点赞同，第二点有疑问望解答，所说的运行时动态加载和卸载场景有哪些？除了不能上架AppStore的app，应该动态库（系统库除外）都是在启动的时候已经load成功的吧？

在工程里面创建动态库 target ，主 target 不依赖这个动态库 target ，打包时，这个动态库不会出现在 mach-o 的依赖中，没有对应的 LC_LOAD_DYLIB ，不过动态库是在 .app 里面的，可以通过 dlopen 打开

[HePingLaoSan]

对于程序中获取所有image信息的数据结构AppImages看到只在一处进行初始化构建，但是实际中某些image是可能在运行时动态加载和卸载的，因此需要有一个机制能够在运行时动态更新所有的image信息。

1、3点赞同，第二点有疑问望解答，所说的运行时动态加载和卸载场景有哪些？除了不能上架AppStore的app，应该动态库（系统库除外）都是在启动的时候已经load成功的吧？

在工程里面创建动态库 target ，主 target 不依赖这个动态库 target ，打包时，这个动态库不会出现在 mach-o 的依赖中，没有对应的 LC_LOAD_DYLIB ，不过动态库是在 .app 里面的，可以通过 dlopen 打开

学习了，不过使用dlopen的话，目前apple 会 reject 掉的，我之前想表达的是，在初始化中获取动态库，已经能够 cover 大部分场景了😄，如果设计一种机制来全量获取的话，考虑到性能损耗等成本，感觉不太合算

[tripleCC]

对于程序中获取所有image信息的数据结构AppImages看到只在一处进行初始化构建，但是实际中某些image是可能在运行时动态加载和卸载的，因此需要有一个机制能够在运行时动态更新所有的image信息。

1、3点赞同，第二点有疑问望解答，所说的运行时动态加载和卸载场景有哪些？除了不能上架AppStore的app，应该动态库（系统库除外）都是在启动的时候已经load成功的吧？

在工程里面创建动态库 target ，主 target 不依赖这个动态库 target ，打包时，这个动态库不会出现在 mach-o 的依赖中，没有对应的 LC_LOAD_DYLIB ，不过动态库是在 .app 里面的，可以通过 dlopen 打开

学习了，不过使用dlopen的话，目前apple 会 reject 掉的，我之前想表达的是，在初始化中获取动态库，已经能够 cover 大部分场景了😄，如果设计一种机制来全量获取的话，考虑到性能损耗等成本，感觉不太合算

https://stackoverflow.com/questions/6530701/is-the-function-dlopen-private-api 使用了dlopen，不过苹果并没有 reject ，dlopen 算是公用 API ，只要打开的是有签名的动态库，问题应该不大。
使用 dlopen 可以把部分不需要的模块初始化(rebase/binding/initializer)工作放到启动后执行，不过这只是我的猜想