云自無(wú)心水自閑

有許多方法可以把一個(gè)應(yīng)用拆分成基于個(gè)獨(dú)立下載的部分。甚至于將每個(gè)類都分成單獨(dú)的文件，由ClassLoader在需要的時(shí)候加載。但是如果這樣效率是比較低下的，因?yàn)轭惖囊糜兄黠@的“引用地域”；如果你引用了一個(gè)類，往往會(huì)馬上牽涉到需要引用一大堆其他的類，如果把這些類全都打包在一起，效率會(huì)高得多。

由編譯器自動(dòng)選擇一個(gè)非常好的打包方法是比較困難的。很可能需要在應(yīng)用開發(fā)時(shí)進(jìn)行一些設(shè)定，并不時(shí)地監(jiān)控類的引用。能夠統(tǒng)計(jì)出最優(yōu)的分拆方法：應(yīng)用應(yīng)該分成幾個(gè)SWF，哪些類應(yīng)該放在哪個(gè)SWF中。但是這種方法聽起來(lái)更象是一種研究范疇，實(shí)際操作起來(lái)非常困難。

讓我們來(lái)看一些更具有操作性的方法。

很多應(yīng)用分解后，包含兩種類型的功能：“啟動(dòng)后立即填充”和“啟動(dòng)后稍后填充”。

有許許多多的應(yīng)用是這種模式的。比如：游戲；你有一個(gè)游戲引擎和一些游戲場(chǎng)景?；蛘逷ortals和Porlets; 一些基礎(chǔ)的共享功能和數(shù)據(jù)驅(qū)動(dòng)的小應(yīng)用。或者是一個(gè)大型的有著1500個(gè)頁(yè)面的保險(xiǎn)應(yīng)用，運(yùn)行特定功能是只會(huì)訪問(wèn)一小部分的頁(yè)面?；蛘呤浅涑獯罅?jī)?nèi)容的應(yīng)用，它可以獨(dú)立的更新部分內(nèi)容而不是強(qiáng)制用戶每次瀏覽時(shí)都必須下載全部?jī)?nèi)容。

我稱這些相對(duì)獨(dú)立的可以延遲加載的功能為“模塊”(Modules)，稱加載模塊的應(yīng)用為“Shell”。

在這里，我們先不看如何做，先來(lái)看一些

shell需要能夠與模塊交互，同樣模塊也需要和Shell交互。如果shell引用了modules的一個(gè)類，那么它會(huì)把它鏈接進(jìn)來(lái)。同樣，如果模塊類引用了shell類，它也會(huì)把它鏈接進(jìn)來(lái)。應(yīng)用能正常運(yùn)行只有兩個(gè)方法：或者引用是相同而且共享的(這樣就不需要下載兩次)，或者兩者是不同的，而且沒有任何關(guān)系(盡管兩個(gè)類名字相同，但是它們被認(rèn)為是無(wú)關(guān)的，而且不能交互)。

最好的解決辦法是讓模塊和shell通過(guò)接口交互。這樣，shell不需要引用模塊，而是引用模塊會(huì)實(shí)現(xiàn)的一些接口。同樣，模塊不實(shí)現(xiàn)shell的類，而是允許調(diào)用的API接口。

這樣在shell變化的時(shí)候減少了重新編譯模塊的次數(shù)。具體實(shí)現(xiàn)的變化頻率往往會(huì)比接口本身的變化高得多，而只要接口穩(wěn)定，就不需要重新編譯所有的東西。

注意：需要使用extern（或者extern-library-path)選項(xiàng)來(lái)創(chuàng)建模塊，這樣可以自動(dòng)剔除shell的類，因?yàn)槟K是被加載到shell的子應(yīng)用域中的，將shell的類剔除是安全的。這樣模塊可以真正直接引用shell中的類。

?