經(jīng)歷了幾次APP新版本上線的折磨后，發(fā)現(xiàn)一次成功的上線，除了需求下發(fā)、研發(fā)、測(cè)試、上線這樣理想化的流程之外，還存在很多隱性的工作需要我們考慮并完成。

　　發(fā)布前

　　1、新老版本的兼容問(wèn)題

　　比如，老版本原有的功能，新版本從底層進(jìn)行了重構(gòu)，接口如果重寫(xiě)，老版本要考慮兼容問(wèn)題。不然就會(huì)出現(xiàn)，新用戶下載的APP可以使用，老用戶不能使用的情況，如果涉及了表結(jié)構(gòu)的改變，那么還會(huì)關(guān)聯(lián)到系統(tǒng)的其他功能。

　　2、IOS，安卓，微商城的三端統(tǒng)一

　　原生頁(yè)面和h5頁(yè)面的區(qū)別

　　1）原生應(yīng)用頁(yè)面速度快，排版更清晰，體驗(yàn)效果會(huì)更好

　　2）原生可以脫機(jī)使用，運(yùn)行更快，但h5可以動(dòng)態(tài)更新，不需要更新app

　　3）h5交互動(dòng)態(tài)效果收到限制，復(fù)雜的邏輯和動(dòng)畫(huà)做不了，會(huì)影響一些頁(yè)面場(chǎng)景、邏輯的理解。

　　3、APP更新啟動(dòng)頁(yè)

　　對(duì)于大版本的更新，要有新增功能的介紹引導(dǎo)頁(yè)面，一般4-6個(gè)頁(yè)面為宜，把更新的內(nèi)容講述給用戶，別忘了可以跳過(guò)這部分的按鈕。修改涉及需要用戶重點(diǎn)關(guān)注的地方，可以在頁(yè)面上做些指引蒙版。

　　4、發(fā)布失敗應(yīng)急方案

　　常在坑里走哪有不掛的，一旦發(fā)布失敗，一定要有事先準(zhǔn)備好的應(yīng)急預(yù)案，發(fā)現(xiàn)情況不妙，可以啟動(dòng)應(yīng)急預(yù)案，差不過(guò)緊急回滾，至少把損失降到低。

　　發(fā)布中

　　5、應(yīng)用商店的審核

　　發(fā)布版本的預(yù)期時(shí)間要把應(yīng)用商店的審核時(shí)間加進(jìn)去，特別是appstore的審核比較嚴(yán)格，不符合審核標(biāo)準(zhǔn)的應(yīng)用會(huì)被拒絕發(fā)布，所以時(shí)間要預(yù)留出給AppStore審核，拒絕再修改提交的時(shí)間。

　　6、應(yīng)用商店的更新文案

　　提交給應(yīng)用商店的新功能介紹，包括文案，圖片。不要相信程序員哥哥們的文案水平，如果沒(méi)有運(yùn)營(yíng)人員，這也是我們的職責(zé)之內(nèi)。

　　7、版本號(hào)

　　版本分類(lèi)

　　Alpha是開(kāi)發(fā)人員的內(nèi)部測(cè)試版

　　Beta：這是供公司內(nèi)部測(cè)試的版本

　　RleaseCandidate：RC是發(fā)行候選版本

　　Release：交付給用戶的終版本

　　面向用戶發(fā)布的產(chǎn)品版本號(hào)要按規(guī)則管控好，確保每個(gè)應(yīng)用商店內(nèi)的安裝包是新版本，避免混亂。

　　發(fā)布后

　　8、正式環(huán)境測(cè)試

　　上線之后，按照測(cè)試用例，把用戶前端的功能全部點(diǎn)一點(diǎn)，知名是全體總動(dòng)員，要在不同機(jī)型不同環(huán)境，保證用戶體驗(yàn)。

　　9、跟蹤用戶反饋

　　及時(shí)與一線業(yè)務(wù)人員溝通，是否有未發(fā)現(xiàn)的BUG，優(yōu)先解決影響業(yè)務(wù)的問(wèn)題。