现在做一个手机热更新功能，app下载zip 包后，解压，zip包内有1000个文件，使有用的是zlib+c语言库写文件，android解压操作耗时在3s以内。没有问题，ios的fopen,fwrite,fclose三个函数，写1000个文件耗时要7s,相当头痛。单个数据测试ios的fopen,fwrite,fclose写一个几百k的文件都要5-7ms，这个数据很不合理，按linux的标准，fclose应该会调用fflush，fflush会将数据存入系统缓存，并不应该写硬盘。可是现在ios的fclose好像会直接写硬盘，导致写太慢了，我想尝试object-c的writeToFile接口，但是我怀疑并没有用。有人遇到过这个问题吗？
https://blog.csdn.net/lovesmiles/article/details/102677889
看看我写的文章，或者对你现在的议题有帮助
https://blog.csdn.net/lovesmiles/article/details/102677889
看看我写的文章，或者对你现在的议题有帮助我后来将fclose放在了子线程貌似就解决问题了
https://blog.csdn.net/lovesmiles/article/details/102677889
看看我写的文章，或者对你现在的议题有帮助我后来将fclose放在了子线程貌似就解决问题了放子线程只是表面上的解决了，只是不卡主线程，但会有严重的问题：
1，主线程向子线程发起fclose后，主线程继续执行，如果这时主线和执行fopen打开这个文件，但子线程的fclose还没有完成，这时主线程的执行fopen就会失败，有逻辑问题
2，当主线程调用fclose，比如一个for循环内,open 1000个文件，并将fclose文件工作交线子线程，子线程有一个吞吐量跟不上的问题，linux的文件句柄上限应该是1024，主线程不停的fopen新文件，写数据，然后不关闭，将fclose工作交给子线程，看起来主线程一点都不卡，但是当子线程接收超过1024个文件要关闭，但还没有完成时，主线程再想打开新文件是会失败的，这个失败时间是随机的，原因还比较难查。所以不建议用子线程fclose。如果要用，一定要处理好上面两个问题