文件系统api为何可以这么简洁以及我們這個抓圖模塊的設計難點
文件系统api为何可以这么简洁以及我們這個抓圖模塊的設計難點
- 接口设计
文件系統定义了一个很好的抽象层，对外暴露的接口只有打開文件，關閉文件，讀寫文件。其他的一概沒有。
抓图有一个貌似简洁的抓图接口 （他有两个api，一个grab，一个pack），可是他这个接口其实一点也不简单
a 他有机会有无数的参数，parititon参数，后处理参数，等等。
b 为了最佳化各种用法的性能。它允许以最佳的方式调用。即如果能尽早把某些参数传过来，就可以早些做某些运算。否则就只能晚一点做。为了实现这点，这两个api的设计允许參數在兩個api中移動，即有的時候grab的時候告訴讀多少數據，有的時候pack的時候告訴
todo: 文件系統接口有一個異步接口，我們是不是可以參考他們的
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfileex
- 内部实现
文件系统接口简单，而内部实现允许各种各样的实现，比如不同的文件系统有完全不同的实现，如ntfs，。。
并且它内部应该还有细化。具体我没了解过
但抓图没有很多个实现这个说法，我们只要一个实现，就是万能driver。这也是困难所在。 如果我们单独写hdoa，没有难度。单独写confocal，也没有难度
處理pipeline，一部分只需要做一次，剩下的需要做很多次
這就要求系統內部要緩存做一次的那些數據
而文件繫統沒有這個做法，她只有一種緩存，就是把最后的數據緩存。他沒有緩存中間數據這個說法
