第二章 目標(biāo)
2.1 API 的目標(biāo)
Image I/O API 的設(shè)計(jì)是受到了對支持一系列主要目標(biāo)的渴望的影響。每個目標(biāo)都提供了對應(yīng)的一系列API功能被設(shè)計(jì)的理由。這些目標(biāo)可被分為主要由客戶端應(yīng)用程序需求所推動的和被服務(wù)器端應(yīng)用需求推動的。當(dāng)然，這些主要目標(biāo)僅代表了API所有能力的一小部分。它們在此列舉的目的是提供API設(shè)計(jì)動機(jī)的一種概念。
作為概覽的通用規(guī)則，不論何時(shí)，在方便應(yīng)用開發(fā)者使用及插件開發(fā)者使用之間的權(quán)衡都是必須的，應(yīng)用的開發(fā)者被賦予了更高的優(yōu)先權(quán)。由于相對來說希望編寫插件的API使用者還是占少數(shù)，而且甚至這些編寫插件的開發(fā)者通常也不會寫為了支持相關(guān)的圖片格式使之立即投入使用的代碼之外的東西，所以把復(fù)雜的東西盡量推到插件開發(fā)方而不是應(yīng)用程序開發(fā)方是很有道理的。
為了減輕插件開發(fā)的復(fù)雜度，我們提供了一些用來作為公用函數(shù)的工具方法和實(shí)現(xiàn)類。然而，將所有功能情景都涉及到是不可能的，并且如果提供的工具類和方法過量的話，所有API用戶的機(jī)器付出的額外開銷就會變得很大，即便這些用戶可能并不需要用到這些標(biāo)準(zhǔn)包之外的功能。當(dāng)在使用多個、獨(dú)立開發(fā)的插件時(shí)，可能也會造成一定的贅余，但大多數(shù)用戶還是傾向于在任何情況下都盡可能減少使用插件的數(shù)量。所以我們認(rèn)為，加載理論上可能會被分享但實(shí)際上沒有的代碼，其性能的開銷更容易超過在使用插件時(shí)，由于加載一些重復(fù)代碼而造成的的開銷。
2.1.1 客戶端應(yīng)用程序的目標(biāo)
可插性
使用了Image I/O API 的應(yīng)用程序應(yīng)該具有無需任何重寫和重編譯既可自動使用新插件的能力。這就需要插件盡可能地遵守一系列格式中立的接口。然而，每種圖像格式都有自己獨(dú)有的且插件必須要可以暴露給應(yīng)用程序的屬性和功能。這將由允許插件擴(kuò)展一系列API 的接口來實(shí)現(xiàn)。應(yīng)用程序在不知道具體使用了哪個插件擴(kuò)展之前，將繼續(xù)以通常插件的情形去使用這些功能，而那些確定自己使用了具體插件的應(yīng)用程序則可以使用被擴(kuò)展的接口。
針對不同圖像格式，不論是通常的還是插件專用的，對元數(shù)據(jù)（圖片格式中除了圖像數(shù)據(jù)以外的信息）獲取，都由插件提供的元數(shù)據(jù)訪問方法來實(shí)現(xiàn)。包括工業(yè)標(biāo)準(zhǔn)格式，由API定義的插件中立格式，以及插件專用格式。
插件的自動或手動選擇及安裝
對于通常無需用戶干涉圖片加載過程的簡單應(yīng)用程序來說，基于文件的內(nèi)容自動選擇對應(yīng)的讀取插件就很重要。然而，要令人滿意，那么在用戶不需要的時(shí)候，就得避免加載和實(shí)例化那些復(fù)雜的插件。插件必須能判定它是否可以在不必加載自己所有代碼的時(shí)候就處理一張給定的圖片。為了實(shí)現(xiàn)這個目標(biāo)，插件們將由一種不加載插件主體代碼就可以進(jìn)行簡單判定的服務(wù)提供者接口機(jī)制實(shí)例化。
所有同某個插件相關(guān)的二進(jìn)制碼（.class）文件應(yīng)該被放在一個JAR包里，這樣它就可以被永久性安裝到Java運(yùn)行時(shí)環(huán)境里，或者使用應(yīng)用的CLASSPATH機(jī)制被動態(tài)的載入。
手動插件選擇
盡管自動插件選擇對很多應(yīng)用陳旭來說很方便，但對于許多更加專業(yè)的程序來說，對插件選擇處理做更高級的控制也是必須要有的。該功能由應(yīng)用程序自行判定和操作插件的運(yùn)行時(shí)注冊機(jī)制實(shí)現(xiàn)。
直接I/O、基于磁盤及網(wǎng)絡(luò)
漸漸地，應(yīng)用程序需要同時(shí)處理基于磁盤的和基于網(wǎng)絡(luò)的數(shù)據(jù)。在很多時(shí)候，甚至基于磁盤的數(shù)據(jù)都會因?yàn)槠渌鸄PI的需要而通過某種InputSteam被處理。Image I/O API 提供了一系列允許處理來自File、InputSteam或其他來源的數(shù)據(jù)的接口，從而保持前向后向查找的方式統(tǒng)一。API允許新的I/O接口，包括對圖片獲取及輸出設(shè)備的直接接口直接使用而不需要重寫程序代碼。
訪問元數(shù)據(jù)
在圖片數(shù)據(jù)旁邊的元數(shù)據(jù)有時(shí)和圖片數(shù)據(jù)本身一樣重要。Java Image I/O API 提供了對元數(shù)據(jù)靈活且徹底的訪問。由于元數(shù)據(jù)可能會采用不同形式、并且包含專用的信息，所以提供對元數(shù)據(jù)直接訪問的通用API是十分困難的。因此，API需要插件將它們的元數(shù)據(jù)轉(zhuǎn)換為XML文檔結(jié)構(gòu)，也許會附加對對象的引用作為紋理數(shù)據(jù)的補(bǔ)充。一旦這些工作完成了，元數(shù)據(jù)就可以使用標(biāo)準(zhǔn)的XML DOM（文檔對象模型）接口來進(jìn)行訪問和修改了。插件與插件之間文檔的語法可能是不同的，但其結(jié)構(gòu)卻可以在對插件沒有任何了解的情況下被展示、修改或遍歷。
對高級應(yīng)用程序的支持
為了支持高級應(yīng)用程序，API必須支持訪問諸如“縮略圖”、單文件里儲存的多張圖片、多分辨率圖像及瓦片拼接圖形等功能。必須具有解碼某張巨大圖片中的某一部分的功能和在解碼時(shí)進(jìn)行二次抽樣的功能，從而支持對極巨大圖片的展示。當(dāng)寫入圖片的時(shí)候，必須要保證不需要現(xiàn)將整張圖片存入內(nèi)存，而是按塊切分，逐塊寫入圖片。
2.1.2 服務(wù)器端使用的情況
動態(tài)圖片生成
現(xiàn)代Web服務(wù)器通常動態(tài)地生成大部分內(nèi)容。Java Servlet 和 Java Server Pages（JSP）的API提供了方便的根據(jù)來自網(wǎng)絡(luò)瀏覽器請求，生成HTML頁面響應(yīng)的途徑。給每個用戶生成的自定義HTML可能都是不同的，針對圖片內(nèi)容的定制也是可以的。
在很多時(shí)候，需要動態(tài)的生成圖片內(nèi)容。例如，對股市價(jià)格圖表的支持。盡管為每個列出的股票產(chǎn)生并保存有限數(shù)量個圖表文件也是可行的，但如果允許用戶進(jìn)行自定義操作，比如價(jià)格所處的時(shí)間間隔需要顯示出來或者需要對一個或多個股票之間進(jìn)行價(jià)格的比較時(shí)，需要保存的圖片個數(shù)將會變得無法預(yù)測。只用使用動態(tài)生成的途徑才可能支持這種定制化。
圖片定制化
網(wǎng)絡(luò)圖片通常是“一個大小適配所有”的，不管接受者的顯示能力直接傳送相同的圖片數(shù)據(jù)。而激增的無線或手持設(shè)備需要定制化的適合他們有限顯示寬度和顯示能力的圖片。桌面電腦頻繁增加的顯示分辨率，也會導(dǎo)致一些網(wǎng)絡(luò)圖片顯得過小。缺乏可放縮圖片的同樣會給視力障礙的用戶造成麻煩。服務(wù)器端圖像定制化可基于用戶偏好的分辨率、色彩特征為所有用戶提供最佳化的圖片，
2.2 非目標(biāo)
線程安全
一個指定的ImageReader或ImageWriter實(shí)例不需要支持對其方法再進(jìn)入的（同時(shí)的）調(diào)用（給后來調(diào)用的方法拋出異常，告訴它當(dāng)前讀取器或?qū)懭肫髡诒徽加茫Ｈ欢粋€插件的多個實(shí)例同時(shí)進(jìn)行操作是必須要支持的。出于簡潔的目的，接下來我們只針對讀取器插件進(jìn)行討論。
完全支持并發(fā)調(diào)用要求讀取器將它所有的狀態(tài)信息（例如當(dāng)前的輸入源）綁定到一個獨(dú)立的狀態(tài)對象中，從而工作中的方法可以使用另外一個獨(dú)立進(jìn)程修改了的下次操作使用的狀態(tài)信息繼續(xù)工作。
相比于強(qiáng)制要求每個ImageReader用這種方式追蹤保存他們自己的狀態(tài)，倒不如簡單地要求應(yīng)用程序在需要多線程操作的時(shí)候?qū)嵗鄠€相同ImageReader類的實(shí)例。這意味著每個ImageReader的狀態(tài)必須只使用非京臺實(shí)例變量來保持，這對插件開發(fā)者來說應(yīng)該不算是個負(fù)擔(dān)。
