一、I-jetty的web應用程序編程語言的確定。
要確定其發佈頁面的語言就要找到他發佈的服務器中頁面所在的位置，之前說服務器需要存儲卡纔可以發佈服務，所以目標鎖定在Android文件系統的sd卡。
打開eclipse，然後啓動虛擬機，找到虛擬機的文件管理器，如圖
找到mnt/sdcard目錄，查看文件夾發現多了兩個目錄，且都跟jetty有關，如圖：
在jetty文件夾下發現了webapps，仔細研究發現這個目錄類似於之前做過的jsp的目錄，再看其文件類型，可以確定這些是jsp項目的頁面：
上面的網站文件是編譯好的，均爲class文件，無法查看其源碼，是否採用了其他的自定義的類還不是很清楚，但可以看到他引入了一些jar包，在webapps-console-webinf-lib文件夾下，如圖：
目前還有一些問題有待研究，就是1.他開發網站採用的工具是什麼，是不是也是跟jsp一樣使用myeclipse進行開發，除了引入那些jar包外是否需要安裝其他的插件。2.他的網站是如何部署到服務器上去的，例子中的網站是提供了一個apk的安裝包，這個安裝包要怎麼打？或者不用安裝包像jsp網站那樣直接複製到webapps的目錄下是否可以使用？
二、關於jetty服務器的詳細介紹
看i-jetty的介紹可以瞭解他是pc端jetty服務器的簡化版，我們有必要理解一下jetty服務器是什麼，過去的一段時間裏jetty服務器一度很火，聽說谷歌就是用的jetty的服務器。下面我們瞭解一下jetty服務器。
Jetty ¶
Jetty是什麼？ ¶
Jetty是一個用Java實現的開源的Http和Web服務器，包括HTTPserver, HTTPclient和javax.servlet container。
Jetty用在何處？ ¶
Jetty的應用非常廣泛，包括：
· 大型集羣系統，如Yahoo HadoopCluster（http://developer.yahoo.net/hadoop/）
· 雲計算服務，如GoogleAppEngine （http://code.google.com/appengine/）
· SaaS(Software-as-a-service)系統，如Yahoo! Zimbra（http://www.zimbra.com/）
· 應用程序服務器，如Apache Geronimo(http://geronimo.apache.org/)
· 應用框架，如GWT(http://code.google.com/webtoolkit/)
· 工具，如 EclipseIDE(http://www.eclipse.org/)
· 移動設備，i-jetty(http://code.google.com/p/i-jetty/)
Jetty的特性是什麼？ ¶
Jetty的廣泛應用得益於其諸多優秀的特性：
· 輕量級：Jetty體積小巧，佔用系統資源較少。
· 易嵌入性：Jetty既可以像tomcat一樣獨立運行，也可以很方便的嵌入到工具、框架或其他應用服務器中運行。Jetty在設計之 初就是作爲一個可以嵌入到其他的Java代碼中的servlet容器而設計的，因此開發小組將Jetty作爲一組Jar文件提供出來，可以非常方便的在自 己的容器中將Jetty實例化成一個對象並操縱該容器對象。
· 靈活性：Jetty的體系架構及其面向接口的設計實現了功能模塊高度可插拔和可擴展的特性，可以非常方便的根據需要來配置Jetty啓用的功能。
· 穩定性：Jetty運行速度較快，即使有大量服務請求併發的情況下，系統性能也能保持在一個可以接受的狀態。
Jetty的體系架構 ¶
下面分別對上圖中的幾個部分作簡要介紹：
· Connector負責解析服務器請求併產生應答，不同的Connector用於處理不同協議的請求。
· Handler用於處理經過Connector解析的請求併產生應答內容，同樣可以通過配置不同的Handler來負責處理不同的請求。
· TheadPool：管理和調度多個線程，用於服務於多個連接請求。
· Server代表一個Jetty服務器對象，主要作用是協同Connector、Handler和TheadPool的工作。
其中，!TheadPool可以根據配置選擇是否使用，Connector和Handler也可以通過配置非常方便的實現替換。
Continuation機制 ¶
Continuation機制是Jetty用於更好的支持異步Servlet的機制。
首先簡要介紹一下技術應用的背景。異步請求是指當客戶端發送一個請求到服務器的時候，客戶端不必一直等待服務器的響應，例如Web 2.0中的Ajax(Asynchronous JavaScript and XML)技術、JDBC連接池等，當服務器端響應返回時，客戶端利用一個 Javascript 函數對返回值進行處理，以更新頁面上的部分元素的值而不必刷新整個頁面，從而帶來更好的客戶體驗。但很多時候這種異步事件只是在很小一部分的情況下才會發生，那麼怎麼保證一旦服務器端有了響應之後客戶端馬上就知道呢，我們有兩種方法來解決這個問題，一是讓瀏覽器每隔幾秒請求服務器來獲得更改，稱之爲輪詢。二是服務器維持與瀏覽器的長時間的連接來傳遞數據，長連接的技術稱之爲Comet。輪詢的主要缺點是產生了大量的傳輸浪費；而如果使用Comet技術的話，客戶端和服務器端之間必須保持一個長連接，一般來講，服務器端的一個Servlet會獨佔一個線程，如果有大量客戶端維持長連接，會給服務器端的處理能力帶來很大的挑戰。
針對上述情況，Jetty利用Java語言的非堵塞I/O技術來處理併發的大量連接。具體說來，Jetty實現了一個基於java.nioAPI 的SelectChannelConnector，允許它維持每個連接開放而不用消耗一個線程。當連接掛起時，Connector將請求維持在未決 Continuations隊列裏，用來服務請求的線程返回給TheadPool，這樣，該線程又可以服務於其他請求。暫停的請求停留在未決 Continuations 隊列裏直到指定的過期時間，或者在它的Continuation上調用resume()方法。
Jetty Vs Tomcat ¶
Tomcat作爲第一款成功的web容器，具有廣大的用戶羣體。從表面功能上Jetty和Tomcat都是差不多的，都提供Http Server和Servlet容器功能，下面我們從幾個方面比較兩者的差異：
從構架方面
Tomcat主要是作爲JSP/Servlet最新規範的參考實現而設計，屬於學 院派，但是顯得龐大而雜亂。最常見的Tomcat使用方式是將其作爲一個服務器軟件安裝到操作系統上，然後在裏面部署web應用，如果嵌入到其他JEE服 務器中以提供Web容器功能或者作爲組件嵌入到其他應用中，操作起來比較麻煩。
Jetty是由多個可以獨立運行的構件通過彼此之間可插拔的接口組裝在一起，其使用可以非常靈活。目前，Jetty在Geronimo、JBoss、Sybase EAServer、JOnAS和Glassfish等JEE應用服務器中提供Web容器功能。從性能方面
Tomcat在耗時請求連接數量不多時，也就是大多數請求能非常短的時間處理完畢的情況下，具有較好的執行效率。
Jetty 在存在大量併發連接，大多數連接又需要更多的處理時間（業務邏輯計算佔用的時間）的情況下（這種情況是目前大多數web應用具有的特點），具有更好的性能 和伸縮性。Jetty的這個優勢得益於Continuation機制，這樣可以把有限的內存資源更多的留給應用程序使用。在靜態文件服務方面，Jetty 也具有更好的性能。這是由於Jetty使用了文件內存映射機制和NIO來對靜態內容進行輸入輸出，這種方式將佔用更少的系統內存和更快發送速度。從標準規範方面
Tomcat曾是sevlet2.4規範的參考實現，從Servlet2.5之後，Tomcat不再是參考實現了，Sun公司自己創建了Glassfish，並作爲Servlet2.5、Servlet3.0、Jsp2.1的參考實現。
Jetty在執行規範方面做的非常好，是Servlet2.5規範的一個優秀實現。在Servlet3.0中，Jetty自有的continuation機制也成爲規範備選方案之一。
參考資料 ¶
三、確定開發工具
由以上說明可以確定，jetty的項目是通過eclipse+jetty服務器開發，而eclipse和jetty都是跨平臺開發工具，且均爲免費使用，是開發項目工具的首選，而且不用在乎開發所在的平臺是windows還是Linux。jetty本身是一個servlet容器，可以發佈servlet項目，同時也支持jsp項目，但對jsp支持不是很好。Jetty服務器還有一個好處就是可以把發佈在tomcat裏的jsp和servlet項目稍作修改進行發佈，實際效果怎樣還需要測試才能知道。