调用detachFd分离文件描述符后是否仍需关闭ParcelFileDescriptor实例

1. 分离fd后是否需要关闭原ParcelFileDescriptor实例 #

需要，该要求仅适配Android 5.1（API 22）及更低版本系统，Android 6.0及以上版本无此问题。

底层逻辑说明：detachFd()的设计初衷是将ParcelFileDescriptor持有的文件描述符所有权完全转移给调用方，执行后原Java实例不再持有该fd的所有权，理论上无需再调用关闭方法。但Lollipop及更低版本的StrictMode资源检测逻辑存在缺陷：仅检查ParcelFileDescriptor实例是否主动调用过close()，不会识别内部fd是否已经被分离，因此会误报资源未关闭的错误。该问题在Android 6.0版本的系统源码中已经被修复，detachFd()执行后系统会自动标记该实例无需再关闭，不会触发StrictMode告警。

2. 关闭实例对native层使用分离fd的影响 #

只要调用顺序正确，关闭原ParcelFileDescriptor实例不会对native层持有的fd产生任何负面影响。
detachFd()执行时会自动将ParcelFileDescriptor内部存储的fd值置为-1，后续调用实例的close()方法时，会先判断内部fd是否为有效正值，如果为-1则直接返回，不会执行底层关闭文件描述符的逻辑，因此完全不会影响已经分离出去的fd的正常使用。

3. 使用注意事项 #

• 必须严格保证调用顺序：先执行ParcelFileDescriptor#detachFd()获取到有效fd值，再将fd传递给native层使用，最后再调用ParcelFileDescriptor#close()方法。禁止在detachFd()执行前调用close()，否则会直接关闭底层fd，导致native层访问时报Bad File Descriptor错误。
• detachFd()仅允许调用一次，重复调用会直接抛出IllegalStateException异常。
• 分离后的fd生命周期完全由native层负责，必须保证native层最终会调用close()（POSIX标准接口）或你提到的fdclose关闭该fd，避免出现真实的文件描述符泄漏问题。
• 禁止在Java层detachFd()后，再通过反射等方式读取操作ParcelFileDescriptor内部的fd字段，避免出现不可预期的错误。

内容的提问来源于stack exchange，提问作者API_1024