第一篇：Html5與APP開發(fā)比較心得

Html5與APP開發(fā)比較心得

引言

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

以下為文章原文：

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

1、功能豐富

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

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

但這種混合開發(fā)的問題在于，增加了項目的復(fù)雜性，而且不象傳統(tǒng) Web 那樣可以直接在瀏覽器里運行。這個問題短時間內(nèi)恐怕還無法解決。不過好在現(xiàn)在網(wǎng)絡(luò)標(biāo)準(zhǔn)在不斷的高速擴(kuò)充，先進(jìn)的瀏覽器也在一直跟進(jìn)。Android 3.1 已經(jīng)支持 Camera 了。iOS 瀏覽器也開始支持 WebSocket 和設(shè)備方向檢測了。

總得來說，移動設(shè)備在發(fā)展，而 Web 也同樣在快速變化。而目前也有 5 家主要瀏覽器開發(fā)商在改進(jìn)現(xiàn)有標(biāo)準(zhǔn)，豐富新的功能。所以原生 App 在快速前進(jìn)，同時，Web 也在縮小差距。

2、運行效率

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

反方：現(xiàn)如今 Web 的速度已經(jīng)很快，而且多數(shù)應(yīng)用不需要這么快的速度。

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

圖片處理引擎已經(jīng)使用 Web 來加速?，F(xiàn)在硬件加速也已經(jīng)開始。讓我們看看用上硬件加速的 Canvas 的效果：

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

3、開發(fā)感受

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

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

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

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

4、用戶體驗

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

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

反方：Web 有自己的傳統(tǒng)，但如果你想開發(fā)帶有原有平臺那種感覺的 Web，同樣可以做出來。前面已經(jīng)講過，WEB 開發(fā)的方式，是先做一個大體適合所有平臺的版本，然后再針對不同平臺不斷改進(jìn)。當(dāng)這些改進(jìn)主要是針對功能時，你可以選擇幾個你最關(guān)心的平臺做優(yōu)化。類似于 瀏覽器檢測。我們經(jīng)?？梢月牭郊夹g(shù)論壇里的程序員們，抱怨有太多的瀏覽器版本要測試。不過如果你優(yōu)先關(guān)注兩三種主流平臺，是值得為它們多花點時間做優(yōu)化 的。

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

5、傳播途徑

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

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

6、收費

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

此外，傳統(tǒng)網(wǎng)站的廣告、贊助，在 App 里也同樣適用。

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

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

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

結(jié)論

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

如果你選擇 Web 方式，就要在 Web 標(biāo)準(zhǔn)和不斷的改進(jìn)上用心。Web 技術(shù)本身的優(yōu)點就是能兼容大批不同的操作系統(tǒng)和設(shè)備。

第二篇：iOS Web App開發(fā)心得(四)

澤思網(wǎng)絡(luò) – 上海APP開發(fā)商

iOS Web App開發(fā)心得

（四）1、關(guān)于jQuery

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

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

2、viewport帶來的問題

其實這一點在前面已經(jīng)講過，還是想再重復(fù)一下。

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

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

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

澤思網(wǎng)絡(luò) – 上海APP開發(fā)商文已經(jīng)說過。

3、iOS自己的處事方式

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

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

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

4、SVG支持不力

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

5、背景縮放的bug

按照CSS的標(biāo)準(zhǔn)，背景圖片大小是可以縮放的。實際使用時，在有的機(jī)器上有明顯bug，表現(xiàn)為有時候縮放變?yōu)槠戒?，有時候需要再加一個多點觸控才能觸發(fā)縮放。

第三篇：app開發(fā)合同2018

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

手機(jī)APP開發(fā)協(xié)議書

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

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

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

1)甲方選擇乙方為其開發(fā)軟件系統(tǒng)，乙方將在甲方規(guī)定的時間內(nèi)，根據(jù)甲方要求，為甲方開發(fā) APP 軟件系統(tǒng)。

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

規(guī)范 信息系統(tǒng)在功能、操作、環(huán)境及性能等方面要求的周密而完整的說明。

************* 任務(wù) 為完成“合同范圍”所述服務(wù)而進(jìn)行的相關(guān)活動。

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

第二條 項目內(nèi)容

甲方委托乙方開發(fā)可以在iOS、安卓操作系統(tǒng)下運行的軟件，軟件需求，app應(yīng)用開發(fā)的欄目架構(gòu)及相關(guān)功能開發(fā)細(xì)節(jié)，由雙方協(xié)商確定，作為本合同附件。第三條 履行期限

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

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

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

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

元（小寫：￥20000.00）。

第五條 驗收

乙方完成本軟件開發(fā)工作后，甲方應(yīng)在 十五 個工作日內(nèi)完成驗收，逾期驗收的，視為驗收合格。第六條 雙方權(quán)利義務(wù)：

6.1 甲方的權(quán)利義務(wù)

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

************* 4)甲方有責(zé)任對本協(xié)議的內(nèi)容進(jìn)行保密;5)甲方有責(zé)任對乙方的軟件開發(fā)技術(shù)進(jìn)行保密，在未經(jīng)乙方書面許可的情況下，不得向第三方泄露。

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

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

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

6.2 乙方的權(quán)利義務(wù)

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

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

第七條 保密條款

1)雙方不得向第三者泄露本協(xié)議的任何內(nèi)容。

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

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

1)

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

2)訂立本合同所依據(jù)的客觀情況發(fā)生重大變化，致使本合同無法履行的，經(jīng)雙方協(xié)商同意，可以變更本合同相關(guān)內(nèi)容或者終止合同的履行。第九條 違約責(zé)任

1)甲方每逾期付款一天，應(yīng)按照乙方開發(fā)費用的 5 %支付逾期付款違約金。2)乙方未按時交付的，每逾期一天，甲方將扣除開發(fā)費用的 5%作為補(bǔ)償，如因甲方未提供相關(guān)技術(shù)資料、調(diào)試環(huán)境支持、需求溝通不明確等原因，致使乙方延期交付的，乙方不承擔(dān)違約責(zé)任。

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

第十條 糾紛解決

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

第十一條 通知與送達(dá)

1)甲方、乙方確認(rèn)，雙方履行本合同的溝通可采取面談、電話、傳真和電郵的方式，本協(xié)議所載的雙方聯(lián)系地址、電話和電子郵箱均為真實、有效的聯(lián)系方式。雙方確認(rèn)，一經(jīng)向?qū)Ψ桨l(fā)送電郵，即視為收到通知；一方按本協(xié)議載明地址所發(fā)出的書面文件，自發(fā)出之日起七日內(nèi)視為送達(dá)，無論是否簽收或拒收。

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

************* 3)如任一方的聯(lián)系方式有改變，應(yīng)在3天內(nèi)書面通知對方。

第十二條 其他事項

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

3)本協(xié)議標(biāo)題僅供參考之用，并不構(gòu)成本協(xié)議的一部分，亦不得被用以解釋本協(xié)議。

4)本協(xié)議一方延遲或未能行使本協(xié)議下的權(quán)力、權(quán)利或救濟(jì)不應(yīng)作為對任何該等權(quán)力、權(quán)利或救濟(jì)的棄權(quán)。

5)如果本協(xié)議的任何條款或規(guī)定在任何適用法律下被認(rèn)定為全部或部分無效或不可強(qiáng)制執(zhí)行，其應(yīng)（在該等無效或不可強(qiáng)制執(zhí)行的范圍內(nèi)）從本協(xié)議中被排除，但本協(xié)議的所有其他條款和規(guī)定均保持全部有效。

（本頁以下無正文）

甲方： 乙方： 負(fù)責(zé)人： 負(fù)責(zé)人：（簽章）（簽章）

年 月 日 年 月 日

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

iOS Web App 開發(fā)心得

（三）：App化

三、App化

1、放到桌面

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

2、設(shè)置圖標(biāo)和啟動畫面

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

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

圖標(biāo)的添加方法是在head區(qū)添加如下代碼：

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

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

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

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

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

3、隱藏地址欄

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

全屏：

隱藏地址欄：

4、控制用戶的縮放

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

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

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

5、離線

到這里，我們的App已經(jīng)很像原生App了?？墒牵绻麛嗑W(wǎng)了怎么辦？

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

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

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

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

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

我建立的名叫cache.manifest，內(nèi)容如下：

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都可以緩存，當(dāng)然，其他類型的也可以。

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

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

index.php訪問失敗時用404.html替換。這個可以用在網(wǎng)絡(luò)不好的時候，例如一個離線應(yīng)用去訪問一個在線頁面，但是沒有訪問成功，這時就可以調(diào)用一個已經(jīng)離線了的頁面去，不破壞用戶體驗。

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

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

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

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

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

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

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

（當(dāng)然，可以用腳本更新，不詳述。）

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

現(xiàn)在唯一的局限就是技術(shù)限制了–網(wǎng)頁不可能調(diào)用系統(tǒng)的API，如文件IO，攝像頭等等。要使用這些功能，就得老老實實地下載SDK回來開發(fā)原生的App?？墒?，如果用HTML+js+css，也能調(diào)用本地API，和原生App實現(xiàn)同樣的功能，是不是很心動？

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

第五篇：APP開發(fā)保密協(xié)議

軟件開發(fā)保密協(xié)議

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

鑒于乙方將開發(fā)甲方的手機(jī)應(yīng)用（APP）軟件項目，為確保雙方的保密信息不向

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