第一篇：iOS Web App 開發心得(三)：App化

iOS Web App 開發心得

（三）：App化

三、App化

1、放到桌面

其實這個最簡單啦，點瀏覽器的加號，就會有一個菜單，添加到屏幕就行。

2、設置圖標和啟動畫面

添加到屏幕后，默認的是一個白色圖標，啟動畫面則是上次運行時的畫面截圖（所以感覺不到有啟動畫面）。

為了更像原生的App，我們添加一下圖標和啟動畫面。

圖標的添加方法是在head區添加如下代碼：

其中，xpadicon.png是圖標，必須為png格式，大小為57*57像素，不需要添加圓角和光影效果，iOS自己會處理。

啟動畫面的添加方法也差不多：

其中，xpadstartup.png是圖標，必須為png格式，縱向圖片，iphone/itouch的大小為320*460，ipad為768*1004。

要說明的是，啟動畫面的時間會很短，而且這個時間似乎是不可控的，個人感覺是在頁面ready的時候啟動畫面消失。

另外，在我試驗用的itouch3上，圖標和啟動畫面均未生效，iphone4和ipad上有效。

3、隱藏地址欄

為了更像本地App，我們要隱藏掉地址欄，而在隱藏這個之前，我們必須設定程序全屏，否則無效。

全屏：

隱藏地址欄：

4、控制用戶的縮放

作為一個網頁，事實上可以無限縮放的（當然，縮小到比viewport還小時會自動充滿viewport），而作為一個程序，我們有時候不希望這樣的事情發生，如下代碼可以解決：

上述代碼的意思是，viewport的寬度為設備寬度，initial-scale是初始的縮放值。（按照我的理解，viewport的寬度值和initial-scale這兩個屬性應該是不可以同時存在的，因為定義了一個值會自動推算出另一個值，比如我將viewport的寬度設為屏幕寬度的2倍，那么initial-scale應該自動為0.5，待驗證。）后面兩個自然是能縮放的最小和最大值了。

如果不想讓用戶縮放，則可以將最小值和最大值設為一樣，都為1.0，或者直接將user-scalable設為no。

5、離線

到這里，我們的App已經很像原生App了。可是，如果斷網了怎么辦？

于是，最的一步–離線。離線之后，我們的程序就可以在沒有網絡的時候正常運行，完全和原生App一樣了！

上述的特性都是iOS的，但是離線是HTML5的特性。

要實現離線，首先得有一個先決條件：能修改web服務器的MIME（確切地講，是MIME中有manifest類型）。關于MIME是什么就不詳細介紹了。首先，我們需要在web服務器中將.manifest后綴的MIME設

為”text/cache-manifest”。對IIS，在站點屬性中可以設置，對apache，則能直接通過修改.htaccess文件實現。不詳述。

接下來，我們需要創建一個離線文件列表，列表中的文件將被緩存供下次使用。

我建立的名叫cache.manifest，內容如下：

CACHE MANIFEST

# xpad v0.1.0009

# 指明緩存入口

CACHE:

index.html

index.css

jquery.js

xpadicon.png

xpadstartup.png

images/pic.png

# 以下資源必須在線訪問

NETWORK:

login.php

# 如果index.php無法訪問則用404.html代替

FALLBACK:

/index.php /404.html

#開頭的是注釋，這個好理解。文件分為三段：CACHE、NETWORK、FALLBACK。CACHE表示要緩存的文件，即可以離線使用的資源，可以看到，html/css/js/pic都可以緩存，當然，其他類型的也可以。

NETWORK表示必須在線訪問的，例如登錄之類的頁面。

FALLBACK表示如果在線訪問失敗時，用什么文件替換。上面的代碼表示

index.php訪問失敗時用404.html替換。這個可以用在網絡不好的時候，例如一個離線應用去訪問一個在線頁面，但是沒有訪問成功，這時就可以調用一個已經離線了的頁面去，不破壞用戶體驗。

再接下來，就是告訴iOS，我們的程序需要離線，方法是在訪問的頁面中的html標簽中加入一個屬性標記上面說的manifest文件：

訪問一次，只要文件傳輸完畢，我們的應用就成功離線啦！這時斷開網絡再次打開，依然可以使用！

App化的操作基本都完成啦，可以先喝口茶休息下。

接下來呢？接下來你可能會修改你的頁面，但是，悲劇來了，你發現無論你怎么刷新，頁面都沒有變化，即使清掉緩存也不行。

事實上，更改頁面文件并不會導致離線文件也更新，而清掉緩存也不會清掉離線的文件！

更新緩存的條件是：.manifest內容發生變化！所以如你看到那樣，我在最前面加入了版本，這樣一方面可以標版本，另一方面剛好讓程序更新緩存。

我們的Web App在打開時會檢測更新，但是，本次打開使用的仍然會是老版本，如果更新完成，再刷新或者再次啟動會是新版本，而如果更新過程未完成，則仍然是老版本。這中間不會有任何提示。

（當然，可以用腳本更新，不詳述。）

至此，一個完美的Web App就誕生了！

現在唯一的局限就是技術限制了–網頁不可能調用系統的API，如文件IO，攝像頭等等。要使用這些功能，就得老老實實地下載SDK回來開發原生的App。可是，如果用HTML+js+css，也能調用本地API，和原生App實現同樣的功能，是不是很心動？

事實上，已經有這樣的框架出現，如PhoneGap等等。有興趣不妨Google之。因超出本文范圍，故就此打住。

第二篇：Html5與APP開發比較心得

Html5與APP開發比較心得

引言

大量新生移動設備的興起，改變了當今互聯網的格局。在技術的發展上，HTML5會取代 App 應用嗎？或者說能夠在多大程度上取代呢？在 HTML5 規范中，已經加入了相機、磁力羅盤、GPS 信息的支持。很多新興瀏覽器也已經開始支持這些新特性。能否用一個統一的 HTML5 來替代 Android 和 iOS 并行開發的雙重成本呢？詳細分析了 HTML5 和本地 App 的優缺點。

以下為文章原文：

移動應用程序(App)和 HTML5 都是目前最火的技術，二者之間也有不少重疊之處。在移動設備瀏覽器里運行的 HTML5 的 Web 頁面，也可以重新打包成不同平臺上運行的 App。目前很多瀏覽器都有很好的跨平臺支持性能，HTML5的 Web 方案，對開發者來說更為方便。完成一次開發，即可多平臺使用。但這確實可行嗎？目前，仍有許多原因，使開發者選擇了 App 開發。很明顯，很多人已經在這么做了。本文將詳細分析這兩種方案的優劣。

1、功能豐富

正方：App 里可以開發出更豐富的功能。我們把移動功能分成兩類。程序本身和程序與系統的結合。比如在 Android 里，加入 Widget 圖標或者通知提醒之類的。App 對這兩者都沒問題。不用多說，這是肯定的。

反方：雖然 APP 發展迅猛，但 Web 也正在迎頭跟進。確實很多原生 App 實現的功能是 HTML5 望塵莫及的。不管你的 Web 做的再好，如果停留在一個沒有攝像頭支持的沙盒中，還是無法滿足一些功能。幸運的是，現在沒有這樣的沙盒限制了。如果你需要你的 Web 來照相，可以做一個負責照像的 App，再把你的 Web 打包進這個應用里面。開源的 PhoneGap 框架就是這么做的。

但這種混合開發的問題在于，增加了項目的復雜性，而且不象傳統 Web 那樣可以直接在瀏覽器里運行。這個問題短時間內恐怕還無法解決。不過好在現在網絡標準在不斷的高速擴充，先進的瀏覽器也在一直跟進。Android 3.1 已經支持 Camera 了。iOS 瀏覽器也開始支持 WebSocket 和設備方向檢測了。

總得來說，移動設備在發展，而 Web 也同樣在快速變化。而目前也有 5 家主要瀏覽器開發商在改進現有標準，豐富新的功能。所以原生 App 在快速前進，同時，Web 也在縮小差距。

2、運行效率

正方：原生 APP 速度更快。原生 APP 沒有瓶頸，而且可以直接調用 GPU 加速、使用多線程。

反方：現如今 Web 的速度已經很快，而且多數應用不需要這么快的速度。

這種說法有點落伍了。Chrome 發布之時帶來的 Javascript V8，給 Web 訪問速度帶來質的飛躍。而現在，計算速度變得更快了。

圖片處理引擎已經使用 Web 來加速。現在硬件加速也已經開始。讓我們看看用上硬件加速的 Canvas 的效果：

如果要開發 3D 游戲，或許速度還不夠，但對于普通用戶來說，新聞、郵件、時間管理、社交網絡，這些用 Web 就已經足夠。另外，越來越多的框架結合 WebGL，可以發揮 OpenGL 的優勢了。

3、開發感受

正方：原生 APP 易于開發。原生 APP 使用強壯的程序語言（Java, Objective C, C++），適合編寫復雜的程序，API 豐富，在桌面環境可以方便的用模擬器進行測試。而 Web 程序的 Runtime 和亂七八糟的各路瀏覽器讓人頭疼不已。

反方：一般來說 WEB 更簡單一些，特別是需要兼容不同設備的時候。WEB 最初的功能只限于文檔展示，而不是程序應用。更何況 Web 不只是靜止的，HTML5，CSS3都給開發者極大幫助。雖然你喜歡C++，Java, Javascript，但是現在沒人能否認 Javascript 也和前者站在同一擂臺上。

瀏覽器/Runtime 的互不兼容（碎片化），APP 也存在同樣的情況。用 Java 寫了 Android App，然后又要面對 iOS 的 Objective C。此外還有 WebOS, BlackBerry，Windows Mobile 等。如果能寫一個程序，馬上能在所有平臺上運行，這該多么方便啊。當然，這只是一個理想。要是想讓程序在每個平臺都能正常的運行，就要做不少調試和妥協。這對很多原生 APP 也是一樣的。

所謂的 Web 碎片化，一直都是如此。但好消息是現在已經有很多不錯的解決辦法。比如 Modernizr 庫就可以幫你兼容一大批主流設備，不管是哪種系統平臺。有興趣的話，你可以看看2011年的 Google IO 演示。

4、用戶體驗

正方：原生 APP 更契合原有平臺。操作感受的定義之一，就是用戶希望在你的程序里，用與系統連貫統一的方式來操作。不同的平臺，都有一些約定俗成的習慣。你不能期望用一套統一的 HTML5 App 去滿足所有用戶。

此外，整個平臺的操作感受都由用平臺自有的軟件庫協調。直接調用平臺工具包就能直接免費獲得完整支持。

反方：Web 有自己的傳統，但如果你想開發帶有原有平臺那種感覺的 Web，同樣可以做出來。前面已經講過，WEB 開發的方式，是先做一個大體適合所有平臺的版本，然后再針對不同平臺不斷改進。當這些改進主要是針對功能時，你可以選擇幾個你最關心的平臺做優化。類似于 瀏覽器檢測。我們經常可以聽到技術論壇里的程序員們，抱怨有太多的瀏覽器版本要測試。不過如果你優先關注兩三種主流平臺，是值得為它們多花點時間做優化 的。

Web 本來就有自己的操作感受。我們也可以說，不同的默認瀏覽器以及運行環境造就了獨特的“Web 感受”。從更廣的角度看，這本身就是一種用戶公認的方式。此外，還有很多成功的案例并不遵循移動設備的原生操作習慣，但卻成功了。想想你最喜歡的手機游戲 的界面？很多更傳統的 App 也是一樣，比如 Twitter 的客戶端。

5、傳播途徑

正方：原生 App 更容易接觸客戶。像 Google Play 和 Apple Store 這樣的 App 商店這幾年勢不可擋，推動了整個移動行業的發展。每個程序員都能在市場里發布自己的應用。用戶都擠在市場里瀏覽、搜索、接受推薦。不僅如此，只要你的程序 足夠好，現有用戶的打分會幫助你說服更多新的客戶。

反方：其實 Web 才容易接觸到客戶。通過 Web 找到內容，這是經過論證的可靠途徑。利用 URL，每一項發布的內容都有一個獨立的地址，包括在網站上發布的應用程序。搜索引擎幫助發現內容，其他網站提供鏈接，還有一些類似應用市場的分類網站。用戶還可以通過郵件、短信和社交網站分享你的鏈接。你的應用鏈接可以直接在不同設備上直接打開。

6、收費

正方：App 收費，應天意，順民生。“六歲孩子在午飯時做的 App，3美刀一個，已經賣出幾百萬”。最近常聽到類似的新聞。各種大小廠商也跟著蜂擁而至，等著圈錢。應用商點幫開發商直接收費。最簡單的辦法，一次性 收費。也有在 App 里再另行收費或者做訂閱收費的，這都幫助開發商贏得長期穩定的回報。

此外，傳統網站的廣告、贊助，在 App 里也同樣適用。

反方：網站賺錢，從來都不是問題。現在機會還會越來越多。Web 能成為現在社會的推動力，有能力用多種方式取得回報，這是基本條件。雖然使用付費并不普遍。但 SaaS 的模式已經相當普及了。成功案例包括 Google Apps 系列產品，各類郵件的收費版等等。另外，直接收費并不是 Web 應用的唯一模式。廣告、會員鏈接、贊助和其他產品服務的交叉推廣都是可選的模式。

看著能在應用市場里直接賺錢而眼紅的 Web 開發者們，你們不能直接把你的 URL 發進市場，但是做一個瀏覽 Web 的 App 的殼子來連接到自己的 Web 上怎么樣？現在市場中已經有成百上千的 App 正在這樣做。有些包裝的很好，以至于你甚至都察覺不到它是一個 Web 程序。

以后應用市場會直接支持 Web 程序嗎？這個現在還不好說，但 Google 已經建建立了 Chrome Web Store。雖然還只能從桌面電腦放問，但這已經挑起了瀏覽器廠商的興趣。

結論

現在還看不出有完勝的一方。有些應用適合做 App，有一些適合用 HTML5。以目前的情況來看，原生 APP 肯定是一個很重要的方向。上面提到的混合式開發，可能是一個不錯的妥協方案。能用 Web 的時候用 App 調用 Web，Web 實現不了的功能再用 App 開發。

如果你選擇 Web 方式，就要在 Web 標準和不斷的改進上用心。Web 技術本身的優點就是能兼容大批不同的操作系統和設備。

第三篇：iOS Web App開發心得(四)

澤思網絡 – 上海APP開發商

iOS Web App開發心得

（四）1、關于jQuery

事實上，jQuery已經針對移動設備推出了jQuery Mobile（2012年8月27日注：jQuery和jQuery Mobile完全不是一個東西），但是我沒有去下載，而是直接用了jQuery，并沒有什么理由。從實際效果來看，也還算理想，mobile safari跑jQuery還算流暢，與桌面瀏覽器的差異并沒有那么夸張。

但是，有一點不完美，就是觸控的事件，不能使用jQuery的綁定方式（bind方法），而必須使用javascript的原生語法。猜測應該是jQuery對事件做了封裝并做了兼容性處理，沒有考慮到觸控事件。（2012年8月27日注：完全可以用jQuery來綁定，只是在事件處理的時候取jQuery封閉事件中的originalEvent就可以了。）

2、viewport帶來的問題

其實這一點在前面已經講過，還是想再重復一下。

因為只有viewport的概念，導致了很多和桌面瀏覽器不一樣的地方，比如沒有滾動條，需要手工去處理很多事情。

同樣因為viewport，元素的fixed定位方式失效。

另外由于viewport自身的操作需要很多觸控動作，給交互也帶來不小的麻煩，前

澤思網絡 – 上海APP開發商文已經說過。

3、iOS自己的處事方式

iOS在一些地方有自己的特殊處理方式，需要注意。

比如不允許用戶從瀏覽器中上傳文件，這個特性就讓應用的空間一下子少了好多。(2012年8月27日注：iOS6已經允許了。)

再比如對于選擇框，并不是像桌面瀏覽器一樣下拉，而是一個系統的模態窗口選擇，完全是蘋果自己的風格。

4、SVG支持不力

網上查到SVG的嵌入方式有三種，除了iframe外，其余兩種均試過，很遺憾，不能生效。

5、背景縮放的bug

按照CSS的標準，背景圖片大小是可以縮放的。實際使用時，在有的機器上有明顯bug，表現為有時候縮放變為平鋪，有時候需要再加一個多點觸控才能觸發縮放。

第四篇：app開發合同2018

*************

手機APP開發協議書

委托方（下稱甲方）： 法定代表人： 注冊地址： 聯系電話： 電子郵箱：

受托方（下稱乙方）： 法定代表人： 注冊地址： 聯系電話： 電子郵箱：

雙方經友好協商，依據《中華人民共和國合同法》的有關規定，就委托乙方開發（以下簡稱“本軟件”）的事宜達成如下協議，以資共 同遵守。第一條 定義

1)甲方選擇乙方為其開發軟件系統，乙方將在甲方規定的時間內，根據甲方要求，為甲方開發 APP 軟件系統。

2)所開發的軟件可以在iOS、安卓操作系統下運行的軟件，軟件需求，App應用開發的項目架構及相關功能開發細節，由雙方協商確定，作為本合同附件。3)甲、乙雙方經友好協商，根據《中華人民共和國合同法》等有關法規，就乙方承擔甲方系統軟件開發項目事宜，達成以下協議條款 4)本合同中所用術語的定義如下： 服務 由乙方提供的項目管理、需求分析、軟件開發、測試，以及咨詢、計劃、實施、操作培訓、安裝、調試、維護、升級等服務。

規范 信息系統在功能、操作、環境及性能等方面要求的周密而完整的說明。

************* 任務 為完成“合同范圍”所述服務而進行的相關活動。

指在本軟件開發完成后乙方需要交付給甲方的文件，包括但不限于：交付文件 程序文件、編譯前的源代碼、數據庫文件、操作手冊、產品制作原型圖、技術開發文檔等。

第二條 項目內容

甲方委托乙方開發可以在iOS、安卓操作系統下運行的軟件，軟件需求，app應用開發的欄目架構及相關功能開發細節，由雙方協商確定，作為本合同附件。第三條 履行期限

乙方應在本合同簽訂之日的次日起 45 個工作日即 2017年7月15日之前完成，本軟件開發并交付軟件和相關文件。乙方可提前交付，并協助甲方進行軟件的測試、鑒定工作。第四條 費用及支付

1)本次項目開發費用合計為人民幣（幣種下同）肆萬 元（小寫：￥40000.00），甲方按以下方式分期支付：

2)在合同簽訂之日起5日內甲方向乙方支付合同額的50%金額為 貳萬元元（小寫： ￥20000.00）；

3)在項目開發十五個工作日內甲方向乙方支付合同額的 50%項目款為

元（小寫：￥20000.00）。

第五條 驗收

乙方完成本軟件開發工作后，甲方應在 十五 個工作日內完成驗收，逾期驗收的，視為驗收合格。第六條 雙方權利義務：

6.1 甲方的權利義務

1)甲方有權利督促乙方按規定時間完成項目開發，有增加或修改內容雙方需另行協商解決;在不影響進程的情況下，對于甲方的細微規模變動的需求，乙方必須滿足;若出現較大幅度的變更，則甲乙雙方商議增加開發費用和延長開發周期。2)甲方完全擁有軟件系統的所有權，包括使用權、著作權等所有權利;3)甲方應當按照協議，按時向乙方支付開發費用;

************* 4)甲方有責任對本協議的內容進行保密;5)甲方有責任對乙方的軟件開發技術進行保密，在未經乙方書面許可的情況下，不得向第三方泄露。

6)甲方從項目成立起，派專人全程跟蹤，乙方必須配合。

7)甲方有責任自行向乙方提供或者請求乙方協助提供軟件開發所需要的硬件、軟件接口、產品需求說明書及必要配合，其中甲方須在合同簽訂時或合同簽訂日之后 1工作日內向乙方提供明確的《產品需求說明書》，該《產品需求說明書》內容包括產品的后端和接口說明；

8)甲方有責任保密乙方的個人信息，不得向第三方泄露。

6.2 乙方的權利義務

1)乙方有責任按甲方的要求在規定時間內完成合同項目內容的開發并向甲方提供相關文檔，項目開發內容以該合同及產品需求說明書為準，若甲方提供的合同及產品需求說明書未明確說明產品開發需求，則乙方與甲方協商明確完成相關內容開發;2)在項目開發完畢之后，乙方有義務協助甲方軟件上線部署，在乙方對甲方提供的維護服務期之內，由于甲方設計變更而導致的變更，若變更范圍在本合同所規定的功能范圍之內，乙方有義務協助甲方修改變更內容;3)乙方有責任對本協議的內容進行保密;4)乙方有責任對與甲方項目的接口規范進行保密，在未經甲方書面許可的情況下，不得向第三方泄露;5)乙方有責任在項目驗收合格完成之后，向甲方提供一年的免費售后服務，此售后服務包括但不限于由于乙方開發原因而導致的功能故障、bug。

6)乙方有責任自行準備軟件開發所需的硬件設備、開發資料、安排相關人員配合及 項目啟動日起每周向甲方通過郵件或 QQ作為媒介以圖片或簡單描述報告形式匯報甲方所委托的 APP開發進度。

第七條 保密條款

1)雙方不得向第三者泄露本協議的任何內容。

2)雙方按本合同規定相互提供和提交的全部文件資料，凡涉及需要保密的，以

************* 預先說明的有關條款為據。并且任何一方在沒有經過另一方書面同意的情況下，不能將另一方的保密資料（如技術資料、用戶信息）透露給第三者。第八條 合同的解除

1)

任意一方欲提前解除本合同，應提前通知對方，經雙方協商簽字同意后方可解除。甲方要求解除合同，無權要求乙方返還甲方向乙方已支付的費用，并應對乙方遭受的損失承擔賠償責任；乙方要求解除合同，應返還甲方已支付的費用，并賠償由此引起甲方的損失。

2)訂立本合同所依據的客觀情況發生重大變化，致使本合同無法履行的，經雙方協商同意，可以變更本合同相關內容或者終止合同的履行。第九條 違約責任

1)甲方每逾期付款一天，應按照乙方開發費用的 5 %支付逾期付款違約金。2)乙方未按時交付的，每逾期一天，甲方將扣除開發費用的 5%作為補償，如因甲方未提供相關技術資料、調試環境支持、需求溝通不明確等原因，致使乙方延期交付的，乙方不承擔違約責任。

3)任何一方不履行或不妥善履行本協議下任何條款被視為違約，守約方有權要求違約方賠償另一方因違約而造成的一切損失，本合同對違約責任另有約定的，從其約定。

第十條 糾紛解決

本合同履行過程中所發生的爭議，雙方協商解決；協商不成的，任何一方可向 所在地法院起訴。

第十一條 通知與送達

1)甲方、乙方確認，雙方履行本合同的溝通可采取面談、電話、傳真和電郵的方式，本協議所載的雙方聯系地址、電話和電子郵箱均為真實、有效的聯系方式。雙方確認，一經向對方發送電郵，即視為收到通知；一方按本協議載明地址所發出的書面文件，自發出之日起七日內視為送達，無論是否簽收或拒收。

2)甲方指定本協議的聯系人為，聯系電話： ；乙方指定本協議的聯系人為，聯系電話：。甲方、乙方指定的聯系人為履行本協議所作出的意思表示和行為均分別代表甲方、乙方。

************* 3)如任一方的聯系方式有改變，應在3天內書面通知對方。

第十二條 其他事項

1)雙方簽訂的補充協議、附件系本合同的組成部分，具有同等法律效力。2)本合同自雙方簽字蓋章之日起生效，一式兩份，雙方各執一份。

3)本協議標題僅供參考之用，并不構成本協議的一部分，亦不得被用以解釋本協議。

4)本協議一方延遲或未能行使本協議下的權力、權利或救濟不應作為對任何該等權力、權利或救濟的棄權。

5)如果本協議的任何條款或規定在任何適用法律下被認定為全部或部分無效或不可強制執行，其應（在該等無效或不可強制執行的范圍內）從本協議中被排除，但本協議的所有其他條款和規定均保持全部有效。

（本頁以下無正文）

甲方： 乙方： 負責人： 負責人：（簽章）（簽章）

年 月 日 年 月 日

第五篇：APP開發保密協議

軟件開發保密協議

該保密協議（以下簡稱“協議”）由（以下簡稱“甲方”）與_______________________(以下簡稱“乙方”)，于2018 年 月 日簽署并生效。本協議適用于甲、乙雙方合作洽談階段。不論甲乙雙方簽訂服務合同與否，除非另外簽署，此保密協議將持續生效。

鑒于乙方將開發甲方的手機應用（APP）軟件項目，為確保雙方的保密信息不向

3、從合法擁有該信息且對另一方無保密義務的