Android I / O that thing

I / O operation program is inseparable from the topic, it is not only simple to read and write, and also to the underlying file system and storage. Speed ​​affect the efficiency of the program I / O's, this article introduces the Android platform I / O mode and usage scenarios.

Consisting essentially of 1. Linux I / O's

As we all know, Android is based on Linux system, first introduced some knowledge of Linux I / O's.

I / O operation is completed by the application, the common file system, and disk, the application sends the I / O command to the file system, the file system sends the I / O instruction to the disk at the appropriate time. I / O flow follows:

I / O operation

CPU and memory much faster than the disk, I / O operations that the performance bottleneck disk. In order to reduce the impact of the application of the disk, the file system access to various optimization.

File system

In simple terms, the file system is the way to store and organize data. The application calls read () method, the system will enter the kernel space from user space by interrupt, and then through the virtual file system specific file system page cache.

Linux-I / O Ka构

• Virtual File System (VFS). Mainly specific file system for shielding, provides a uniform interface for the operation of the application.
• File System (File System). ext4, F2FS are specific file system implementation. Each file system has their own scene.
• Page cache (Page Cache). File system cache data, check the page cache reading file, if the hit does not read the disk.

Disk

Disk storage device refers to a system, a common mechanical hard drive, solid-state disks. If you find that the application data to be read is not in the page cache, this time on the need to initiate real I / O request to the disk. Disk I / O through the process of first core layer common block, I / O scheduling level, the device driver layer, and finally to the specific hardware devices before processing.

Disk architecture

• Common block layer. Receiving an upper layer request is issued by the disk, and ultimately issuing I / O requests. It is similar to the role of the VPS.
• I / O scheduling layer. The scheduling algorithm provided merge and sort request. You can not receive the request immediately to the disk driver layer processing.
• Block device driver layer. According to a particular physical device, select the corresponding driver, complete the final I / O requests by manipulating the hardware device.

2. Android 上的 I/O

Android 现在普遍使用的是 Linux 常用的 ext4 文件系统。F2FS（Flash-Friendly File System）是三星为闪存研发的文件系统，它针对闪存进行了大量优化，F2FS 文件系统在小文件的随机读写方面比 ext4 更快。随着 Google、华为的投入和使用，F2FS 应该会成为 Android 主流的文件系统。

Android 手机使用闪存作为存储设备，也就是我们常说的 ROM。前几年闪存通常使用 eMMC 标准，近年来采用性能更好的 UFS 2.0/2.1 标准。手机存储也朝着体积更小、功耗更低、速度更快、容量更大的方向发展，闪存的随机读写速度甚至比 SSD 还快。

手机变卡

Android 手机用久了会变卡，除了系统升级、设备折旧等因素，还和 I/O 有密切关系。I/O 操作变慢的原因有下面几条：

• 内存不足。系统回收 Page Cache 和 Buffer Cache 的内存，大部分的写操作会直接落盘，导致性能低下。
• 写入放大。闪存重复写入需要先进行擦除，一次写入会引起整个块数据的迁移，导致写入时间非常久。
• 设备性能差。在高负载的情况下容易出现瓶颈。

文件损坏

文件损坏是令人头疼的问题，大多是由不正确的操作导致的。文件损坏的原因可以从应用程序、文件系统和磁盘三个角度来分析：

• 应用程序。大部分的 I/O 方法都不是原子操作，文件的跨进程或者多线程写入、使用一个已经关闭的文件描述符 fd 来操作文件，都有可能导致数据被覆盖或者删除。
• 文件系统。虽说内核崩溃或者系统突然断电都有可能导致文件系统损坏，不过文件系统也做了很多的保护措施。例如 system 分区保证只读不可写，增加异常检查和恢复机制。
• 磁盘。手机上使用的闪存是电子式的存储设备，所以在资料传输过程可能会发生电子遗失等现象导致数据错误。

3. I/O 的三种方式

I/O 有三种方式：标准 I/O、mmap 和 Direct I/O。

I/O的方式

标准 I/O

应用程序平时用到 read/write 操作都属于标准 I/O，也就是缓存 I/O（Buffered I/O）。它的关键特性有：

• 对于读操作，当应用程序读取某块数据时，如果这块数据已经在页缓存中，那么就不需要经过物理读盘操作。
• 对于写操作，应用程序会先将数据写到页缓存中去，不需要等全部数据被写回磁盘，系统会定期将页缓存中的数据刷到磁盘上。

缓存 I/O 可以很大程度减少真正读写磁盘的次数，从而提升性能。但是延迟写机制可能会导致数据丢失。在实际应用中，如果某些数据非常重要，我们应该采用同步写机制。

读操作时，数据会先从磁盘拷贝到 Page Cache 中，然后再从 Page Cache 拷贝到应用程序的用户空间，这样就会多一次内存拷贝。内存相对磁盘是高速设备，即使多拷贝一次，也比真正读一次硬盘要快。

mmap

mmap 把文件映射到进程的地址空间，提高了 I/O 的性能。

mmap 的优点有：

• 减少系统调用。只需要一次 mmap() 系统调用，后续所有的调用像操作内存一样。
• 减少数据拷贝。mmap 只需要从磁盘拷贝一次，由于做过内存映射，不需要再拷贝回用户空间。
• 可靠性高。mmap 把数据写入页缓存后，跟缓存 I/O 的延迟写机制一样。

存在的缺点：

• 虚拟内存增大。Apk、Dex、so 都是通过 mmap 读取。mmap 会导致虚拟内存增大，mmap 大文件容易出现 OOM。
• 磁盘延迟。mmap 通过缺页中断向磁盘发起真正的磁盘 I/O，不能通过 mmap 消除磁盘 I/O 的延迟。

在 Android 中可以将文件通过 MemoryFile 或者 MappedByteBuffer 映射到内存，然后进行读写，使用这种方式对于小文件和频繁读写操作的文件还是有一定优势的。

mmap more suitable for the case where the same area is read frequently recommended I / O operations to the threads. When the user logs, data reporting are met this scenario, the need for additional cross-process synchronization, mmap is also a good choice. Android has its own unique inter-process communication mechanism of Binder, it is also the internal use mmap implementation.

Direct I/O

Some databases to achieve their own data and index cache management, reliance on the page cache is not so strong. They want to bypass the page cache mechanism to reduce a copy of the data, its data will not pollute the page cache.

Direct I / O access files once time-consuming way to reduce the number of system calls and data copying, to a large extent reduce the usage of CPU and memory usage. The negative impact that reads and writes are performed synchronously cause the application to wait.

4. The synchronous and asynchronous I / O

Multithreading blocking on the I / O operations and there is no advantage, the main bottleneck I / O operations that disk bandwidth. So I / O operation can not open a lot of threads.

NIO non-blocking I / O, the I / O event notification in a way, you can reduce the overhead of thread switching. NIO biggest role was not to reduce time-consuming to read the file, but rather to enhance the application to maximize the overall CPU utilization.

In addition, highly recommended Square of Okio , it supports both synchronous and asynchronous I / O, also do a lot more optimization.

I / O optimization is very useful to improve the application experience, and I hope the above stated contents of your help.

Reproduced in: https: //www.jianshu.com/p/43af9c156674