标签：我們 緩存 這個 模塊 文件系统 接口 數據 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，一部分只需要做一次，剩下的需要做很多次
這就要求系統內部要緩存做一次的那些數據
而文件繫統沒有這個做法，她只有一種緩存，就是把最后的數據緩存。他沒有緩存中間數據這個說法
标签：我們,緩存,這個,模塊,文件系统,接口,數據,api,時候 来源： https://www.cnblogs.com/cutepig/p/14354526.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。