整合營銷服務(wù)商

          電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理

          免費咨詢熱線:

          媒體融合應(yīng)建立符合主流價值觀的評估體系

          體融合價值評估體系的建立不是簡單地對轉(zhuǎn)型過程中的各種嘗試進(jìn)行對或不對的評判,而是通過各種維度來衡量媒體融合的進(jìn)程。其核心是圍繞傳播力、影響力、引導(dǎo)力、公信力以及變現(xiàn)能力等建立評價體系,從而實現(xiàn)融合過程中的糾錯功能。媒體融合的價值評估體系必須在堅持“三個價值”統(tǒng)一的基礎(chǔ)上,量化互聯(lián)網(wǎng)運用指數(shù),并建立退出機(jī)制,實現(xiàn)傳播業(yè)態(tài)的供給側(cè)改革。

          媒體融合 評估體系 主流價值觀

          從“你中有我,我中有你”,到“你就是我,我就是你”,從“ 互聯(lián)網(wǎng)”到“互聯(lián)網(wǎng) ”。以2014年8月18日習(xí)近平總書記在中央全面深化改革領(lǐng)導(dǎo)小組第四次會議上的重要講話為起點,媒體融合在國內(nèi)已有四年的探索與實踐。這4年,媒體融合基本完成了從理論認(rèn)知到全面實證的過程,中央廚房和移動優(yōu)先戰(zhàn)略成為一種共識,不管是報業(yè)領(lǐng)域還是廣電傳媒,在融合的探索與實踐中均有不菲的業(yè)績出現(xiàn)。各具特色的融合模式令人耳目一新,呈現(xiàn)出色彩斑斕的繽紛世界。但繁華的背后亦不乏深深的憂慮。評判媒體融合的實際效果需要建構(gòu)一套“價值評估體系”,從頂層設(shè)計入手,以量化指標(biāo)來分析和甄別媒體融合的實證效應(yīng)。

          媒介與傳播形態(tài)的演變

          什么是媒體?這問題有點老套,但必須得重新探究。

          媒體(Media)一詞來源于拉丁語“Medius”,音譯為媒介,意為兩者之間。媒體是指傳播信息的媒介。它是指人借助用來傳遞信息與獲取信息的工具、渠道、載體、中介物或技術(shù)手段。美國傳播學(xué)者威爾伯·施拉姆在《傳播學(xué)概論》一書中說:“媒介就是傳播過程中,用以擴(kuò)大并延伸信息傳送的工具”。①

          其實從理論上來說,媒體和媒介還是有區(qū)別的:媒介是信息傳播所需要的載體、介質(zhì)或通道。媒體是媒介 內(nèi)容體系的組合,擁有后端內(nèi)容架構(gòu)、生產(chǎn)流程、編讀互動等系統(tǒng)支撐。也就是說媒體應(yīng)該是借助媒介對內(nèi)容進(jìn)行傳播的一種組織架構(gòu)。

          加拿大傳播學(xué)者馬歇爾·麥克盧漢在《理解媒介》一書中認(rèn)為,“媒介即訊息”。他說:“任何媒介對個人和社會的任何影響,都是由于新的尺度產(chǎn)生的。”②麥克盧漢把媒介的研究方向做了新的解構(gòu),他提出了研究媒介應(yīng)該從研究內(nèi)容的傳播效果反轉(zhuǎn)到對媒介的傳播工具的研究。《特倫斯·戈登序》中說:“麥克盧漢對傳播媒介的理解是,媒介是人體和心靈的技術(shù)延伸,任何技術(shù)、一切技術(shù)都是媒介。”③

          1440年,古騰堡的印刷機(jī)帶來了報紙的誕生。之后廣播來了,電視出現(xiàn)了。再之后互聯(lián)網(wǎng)問世了,智能手機(jī)(移動終端)誕生了。直至今天,微信、微博被廣泛地使用。當(dāng)人們很嫻熟地按照各自的喜好選擇不同的媒介來獲取和傳播信息,也印證了麥克盧漢所說的:“技術(shù)創(chuàng)造新環(huán)境,新環(huán)境引起痛苦,人體的神經(jīng)系統(tǒng)就‘關(guān)閉’和‘截除’。”④但人們“關(guān)閉”和“截除”的是某些不需要的傳播渠道,并不是“關(guān)閉”和“截除”媒介存在的形態(tài)。

          從這一理論出發(fā),我們應(yīng)該很好理解當(dāng)今各種媒介形態(tài)存在和人們選擇媒介形態(tài)的合理性。技術(shù)推進(jìn)媒體形態(tài)的發(fā)展,而這發(fā)展和變化是永恒的,或許未來會有更多新的媒介形態(tài)出現(xiàn)。而使用哪種媒介形態(tài)仍然取決于科技進(jìn)步給傳播帶來的便利性。

          這就是媒介與傳播生態(tài)。從媒介誕生之日起,媒介就在不斷地分化,從單一到多元,從供應(yīng)到共建。

          媒體為什么要“融合”

          “媒體融合”(media convergence),最早由尼古拉斯·尼葛洛龐蒂提出。美國馬薩諸塞州理工大學(xué)教授浦爾認(rèn)為媒介融合是指各種媒介呈現(xiàn)多功能一體化的趨勢。

          媒體融合是傳統(tǒng)媒體自我“救贖”的手段,是由下往上行的被動的過程。媒體融合是傳統(tǒng)媒體面對因技術(shù)演變帶來的媒介生態(tài)變化,通過與技術(shù)的嫁接,打通傳統(tǒng)媒體和以互聯(lián)網(wǎng)技術(shù)為核心的新媒體之間的壁壘,借助技術(shù)手段改變傳統(tǒng)媒體單一的點對面的傳播形態(tài),從而去拉動那些已“關(guān)閉”和“截除”傳統(tǒng)媒體的人,讓他們在傳統(tǒng)媒體設(shè)置的新的傳輸平臺上,獲取需要的內(nèi)容,最終在新的媒介形態(tài)上讓用戶回歸“傳統(tǒng)”的方式。這里所說的“傳統(tǒng)”是傳統(tǒng)的品牌,而不是傳統(tǒng)的表現(xiàn)方式。當(dāng)好酒遇到了“巷子深”的問題,唯一的出路就是走出去,融入到大的集市中。

          中宣部媒體融合專家組成員、中國人民大學(xué)教授、媒體融合實驗室總干事宋建武認(rèn)為,新聞媒體的融合發(fā)展之路其實是傳統(tǒng)媒體的互聯(lián)網(wǎng) 改造之路。國家行政學(xué)院高級經(jīng)濟(jì)師、媒體融合專家郭全中說:“媒體融合的核心問題就在于重建用戶連接,必須以用戶為中心,破解觀念、技術(shù)、機(jī)制、資金等方面的難題,在創(chuàng)新中贏得未來。”⑤原南方報業(yè)掌門人,現(xiàn)暨南大學(xué)新聞學(xué)院院長范以錦先生說:“隨著內(nèi)容創(chuàng)業(yè)熱潮的興起,媒體人更加重視內(nèi)容的打造。此外,如何將媒體內(nèi)容打造的品牌價值延伸到新的領(lǐng)域?如何通過新媒體連接產(chǎn)業(yè),找到新的商業(yè)模式?已成為各大媒體機(jī)構(gòu)關(guān)注并積極探索的問題。”⑥

          梳理三位專家的觀點,我們可以給媒體融合整理出這樣一個邏輯思路:媒體融合必須要有互聯(lián)網(wǎng)思維,通過互聯(lián)網(wǎng) 改造傳統(tǒng);媒體融合要破解觀念、技術(shù)、機(jī)制、資金等方面的難題;媒體融合最終的目的是通過內(nèi)容建設(shè)形成的品牌價值來連接平臺和用戶,拓展新的產(chǎn)業(yè),在其基礎(chǔ)上找到新的商業(yè)模式。

          媒體融合的實證效果

          4年的探索與實踐,不管是理論的認(rèn)知還是融合的實踐都取得了不菲的成績。從認(rèn)知上來看,以下三個方面應(yīng)該是共識:理清了一個思路——媒體融合是傳統(tǒng)媒體互聯(lián)網(wǎng)化的過程;認(rèn)清了一個方向——媒體融合的路徑必須是技術(shù)迭代、用戶體驗和大數(shù)據(jù)營銷;完成了 互聯(lián)網(wǎng)的過程——“93%的報紙創(chuàng)辦了自有APP,99%的報紙內(nèi)容入駐各類聚合類客戶端。”⑦

          從實踐上來看,不管是報業(yè)還是廣電,都形成了具有鮮明特色的融合模式:

          報紙系統(tǒng)大致形成了四種融合模式:人民日報完成了從中央廚房到全國黨媒信息公共平臺的搭建。全國黨媒信息公共平臺,旨在構(gòu)建起面向全國黨媒的內(nèi)容共享、技術(shù)共享、渠道共享、人才共享、盈利模式緊密協(xié)作的公共平臺,努力打造黨媒與全行業(yè)融合;中國青年報全力打造了“融媒小廚”,并以培訓(xùn)的方式作了有效的推廣;浙江日報實現(xiàn)了“傳媒控制資本,資本壯大傳媒”;上海的東方早報成功轉(zhuǎn)型“澎湃新聞”。

          廣電系統(tǒng)則形成了另一類的四種模式:央視——用戶廣泛管理模式——通過新聞移動網(wǎng)建立了媒體入駐模式,通過多渠道分發(fā),依靠多樣化的內(nèi)容與產(chǎn)品,覆蓋最廣泛的用戶。現(xiàn)有140多家矩陣號入駐,每天發(fā)稿首發(fā)量達(dá)1100條;南方財經(jīng)全媒體集團(tuán)——縱向垂直模式打通產(chǎn)業(yè)鏈的縱向垂直模式,圍繞產(chǎn)業(yè)上下游資源,幫助用戶提供決策路徑。實現(xiàn)媒體 數(shù)據(jù) 交易(由“兩報兩臺三刊三網(wǎng)兩微一端”13個媒體集群組成);芒果TV——特定用戶群模式,通過芒果直播戰(zhàn)略,依靠湖南衛(wèi)視內(nèi)容優(yōu)勢,逐漸建立了特定用戶群的模式。這一模式強(qiáng)調(diào)以內(nèi)容為核心,圍繞內(nèi)容打造可以利用的渠道,形成針對用戶群的影響力;蘇州廣播電視臺——區(qū)域用戶群模式,將用戶限定在一定的區(qū)域內(nèi),利用自己的內(nèi)容,整合服務(wù)行業(yè)的內(nèi)容,覆蓋、滿足區(qū)域市場用戶的不同需求,做區(qū)域媒體的主流平臺。

          盡管當(dāng)前的媒體融合已呈現(xiàn)出繽紛多彩的景象,但似乎并沒有感受到融合帶來的踏實感。原因一是沒有找到替代傳統(tǒng)的盈利模式;二是缺乏量化的標(biāo)準(zhǔn)體系。

          當(dāng)前媒體融合的窘境

          窘境一:如何實現(xiàn)“互聯(lián)網(wǎng) ”

          所謂的“ 互聯(lián)網(wǎng)”是指傳統(tǒng)業(yè)務(wù)通過互聯(lián)網(wǎng)來提升業(yè)務(wù)發(fā)展。“ 互聯(lián)網(wǎng)”強(qiáng)調(diào)“順勢而為”。其看重的是存量優(yōu)勢、行業(yè)標(biāo)準(zhǔn)優(yōu)勢和公信力優(yōu)勢。按照這個邏輯,傳統(tǒng)媒體在“ 互聯(lián)網(wǎng)”方面成效顯著。

          “互聯(lián)網(wǎng) ”是指基于互聯(lián)網(wǎng)平臺之上的融合。它更多強(qiáng)調(diào)“逆襲創(chuàng)新”,是以新技術(shù)為先發(fā)優(yōu)勢,帶動體制機(jī)制的創(chuàng)新來實現(xiàn)爆發(fā)性增長。

          媒體融合其核心是“互聯(lián)網(wǎng) ”,但為什么媒體融合在“互聯(lián)網(wǎng) ”這個階段無法邁步?

          哈佛大學(xué)商學(xué)院教授克里斯坦森在其《創(chuàng)新者的窘境》一書中闡述了這一觀點:越是大的公司,越是優(yōu)秀的公司,越容易在技術(shù)革新中失敗。原因就在于思維方式和管理模式的固化。他們很難接受新生的事物。這也就是當(dāng)前媒體融合過程中,我們只學(xué)到了表象而無法更深層面推進(jìn)的原因。⑧

          窘境二:技術(shù)是核心還是手段

          媒體融合的核心是強(qiáng)化互聯(lián)網(wǎng)思維。強(qiáng)化互聯(lián)網(wǎng)思維有兩個重要節(jié)點,一是在指導(dǎo)思想和思維方式上接受互聯(lián)網(wǎng)點面融合的特點,也就是線上與線下鏈接功能;二是要充分運用網(wǎng)絡(luò)技術(shù)手段去改造傳統(tǒng)媒體。從這一理論出發(fā)就必須將互聯(lián)網(wǎng)技術(shù)作為融合的核心,通過技術(shù)來實現(xiàn)信息的傳播與認(rèn)知、交流以及用戶參與三者的融合。但遺憾的是,到目前為止,傳統(tǒng)媒體的互聯(lián)網(wǎng)改造進(jìn)程并沒有按照這一邏輯去實施,更多還是停留在 的方式,這就出現(xiàn)了“兩微一端”我也有,網(wǎng)站我也有,但支撐其運營的技術(shù)參數(shù)和系統(tǒng)是分割的,數(shù)據(jù)是孤立的。用戶數(shù)是各平臺統(tǒng)計數(shù)的疊加,看似數(shù)據(jù)量很大,但是不相融。

          窘境三:“內(nèi)容為王”還是“渠道為王”

          這是近些年在媒體融合進(jìn)程中爭議最大的問題。傳統(tǒng)媒體力挺“內(nèi)容為王”這一說法,而互聯(lián)網(wǎng)媒體強(qiáng)調(diào)渠道優(yōu)先。其實這兩者之間,是相互支撐、相互作用的。再好的內(nèi)容,如果沒有平臺支撐,其內(nèi)容是無法實現(xiàn)傳播效果的;而平臺再好,如果沒有內(nèi)容供應(yīng),亦無法產(chǎn)生影響力。

          在媒體的內(nèi)部,內(nèi)容與渠道的融合路徑應(yīng)該是:通過營銷推廣等手段吸引人們訪問自己的網(wǎng)站或數(shù)字終端;就用戶感興趣的內(nèi)容吸引他們駐留;以優(yōu)質(zhì)的內(nèi)容 良好的用戶體驗贏取他們再次訪問的機(jī)會;在美譽(yù)度的基礎(chǔ)上讓他們在朋友圈中分享這些內(nèi)容。

          但在媒體融合過程中,傳統(tǒng)媒體的優(yōu)勢不僅僅是提供內(nèi)容那么簡單。它的核心競爭力應(yīng)該是新聞專業(yè)主義精神。所謂新聞專業(yè)主義精神,強(qiáng)調(diào)傳媒作為一個獨立的社會子系統(tǒng)的收集、整理、傳播信息的功能和責(zé)任。在此基礎(chǔ)上,它還包括一套關(guān)于新聞媒介社會功能的信念,一系列規(guī)范新聞工作的職業(yè)倫理,一種服從政治和經(jīng)濟(jì)權(quán)力之外的更高權(quán)威的精神和一種服務(wù)公眾的自覺態(tài)度。這種原則著眼于受眾的知情權(quán)和接近權(quán),以“公平、公正、公開”為目標(biāo)取向,強(qiáng)調(diào)社會責(zé)任意識。而現(xiàn)在很多媒體為了“10萬 ”而丟棄了我們應(yīng)該固守的傳統(tǒng)。

          窘境四:接受“算法”還是排斥“算法”

          算法是什么?算法是計算機(jī)在擁有海量數(shù)據(jù)的前提下,根據(jù)用戶體驗的習(xí)慣,將其偏好記錄下來,再從數(shù)據(jù)庫中找出與其偏好配對的內(nèi)容進(jìn)行推送,達(dá)到點對點的傳播效果。

          由于算法是以機(jī)器代替人工,缺乏內(nèi)容的審核與把關(guān),帶來了一定的負(fù)面效應(yīng)。傳統(tǒng)媒體在互聯(lián)網(wǎng)化的過程中對“算法”過于謹(jǐn)慎,過于放大其負(fù)面影響,主動放棄了對用戶需求的了解,無法滿足用戶差異化、個性化的需求。

          如何正視這一問題?復(fù)旦大學(xué)新聞學(xué)院教授周葆華認(rèn)為:“算法已經(jīng)成為當(dāng)下傳播生態(tài)由于供給和需求變化帶來的必然趨勢,我們已經(jīng)沒有辦法回到一個逃避算法的時代。我們今天應(yīng)該重視算法,同時又不應(yīng)該過分放大算法的作用。”⑨他認(rèn)為,算法一方面使整個傳播行業(yè)在供給和需求兩方面發(fā)生重大變化,讓媒體跟用戶發(fā)生緊密聯(lián)系;另一方面,也跟“移動優(yōu)先”戰(zhàn)略有關(guān),當(dāng)下,受眾永遠(yuǎn)在線的時間使用生態(tài)需要大量的內(nèi)容匹配。

          如何構(gòu)建媒體融合的價值評估體系

          媒體融合是個試錯的過程。當(dāng)前媒體融合是通過使用任意或所有的傳播工具,按照用戶期望的時間、地點和方式提供新聞,旨在滿足受眾的期望。因此在媒體融合過程中,媒體機(jī)構(gòu)使用哪一種工具最有效,哪一種組合形式最直觀、最容易被用戶所接受也就是媒體融合試錯的過程。盡管現(xiàn)在媒體融合呈現(xiàn)出比較好的發(fā)展態(tài)勢,但由于缺乏一套行之有效的評價體系來評判和規(guī)范融合的效果,融合進(jìn)展緩慢且成本增加。

          媒體融合價值評估體系的建立不是簡單地對轉(zhuǎn)型過程中的各種嘗試進(jìn)行對或不對的評判,而是通過各種維度來衡量媒體融合的進(jìn)程。其核心是圍繞傳播力、影響力、引導(dǎo)力、公信力以及變現(xiàn)能力等作為評價體系。從而實現(xiàn)融合過程中的糾錯功能。

          媒體融合的價值評估體系必須在堅持“三個價值”統(tǒng)一的基礎(chǔ)上,量化互聯(lián)網(wǎng)運用指數(shù),同時應(yīng)建立媒體融合的退出機(jī)制,實現(xiàn)傳播業(yè)態(tài)的供給側(cè)改革。

          政治價值。習(xí)總書記關(guān)于新聞輿論的重要論述是新時代中國特色社會主義思想的重要組成部分,要圍繞總書記對新聞輿論指導(dǎo)思想的“新定位、新表述、新論斷、新擘畫、新部署、新闡述、新要求”的重要論述來開展新聞宣傳與信息傳播。當(dāng)前傳播生態(tài)已經(jīng)發(fā)生了革命性的變化,融合的要件就是要在真正落實“互聯(lián)網(wǎng) ”的基礎(chǔ)上,打造具有生命力和競爭實力的傳播共享平臺,通過連接聚集數(shù)據(jù),通過數(shù)據(jù)交互,完善用戶體驗。各媒體單位要利用一切先進(jìn)的技術(shù),通過有效的手段建立各主流媒體間的信息共享機(jī)制,在此基礎(chǔ)上建立適應(yīng)現(xiàn)代傳播規(guī)律的政治語境。要通過議程設(shè)置,掌握有效的話語權(quán),用議題來引導(dǎo)受眾,用公信力來影響用戶。

          社會價值。社會主義核心價值體系是對人類未來社會價值訴求的基本看法和總體要求,是幾千年來人類所追求的社會價值理想的一種延續(xù),是對一種更人道、更平等、更自由的合理社會的理想價值訴求,它是社會主義制度的內(nèi)在精神和生命之魂,決定社會主義社會發(fā)展模式、制度體制和目標(biāo)任務(wù)。

          在媒體融合過程當(dāng)中,主流媒體的社會價值不容忽視。為了10萬 ,沒有真相、沒有信源的新聞充斥在主流媒體的新媒體傳播渠道。如果這種行為不斷出現(xiàn),恰恰把主流媒體最核心的公信力丟失了。因此,以社會價值為取向的價值評估體系顯得極為重要。要圍繞社會主義核心價值來構(gòu)建媒體融合的評價評估體系,重振新聞專業(yè)主義精神,建立媒體融合考核的負(fù)面清單。

          市場價值。媒體融合不能只計投入而不考慮產(chǎn)出。要深刻領(lǐng)會習(xí)近平總書記講話精神,推動傳統(tǒng)媒體和新興媒體融合發(fā)展,要遵循新聞傳播規(guī)律和新興媒體發(fā)展規(guī)律,強(qiáng)化互聯(lián)網(wǎng)思維,堅持傳統(tǒng)媒體和新興媒體優(yōu)勢互補(bǔ)、一體發(fā)展,堅持先進(jìn)技術(shù)為支撐、內(nèi)容建設(shè)為根本,推動傳統(tǒng)媒體和新興媒體在內(nèi)容、渠道、平臺、經(jīng)營、管理等方面的深度融合,著力打造一批形態(tài)多樣、手段先進(jìn)、具有競爭力的新型主流媒體,建成幾家擁有強(qiáng)大實力和傳播力、公信力、影響力的新型媒體集團(tuán),形成立體多樣、融合發(fā)展的現(xiàn)代傳播體系。要一手抓融合,一手抓管理,確保融合發(fā)展沿著正確方向推進(jìn)。

          媒體融合要在體制和機(jī)制上有所突破、有所創(chuàng)新。要真正理解和運用互聯(lián)網(wǎng)思維,通過新技術(shù)平臺與新的產(chǎn)業(yè)進(jìn)行有效鏈接,實現(xiàn)媒體融合下的盈利模式創(chuàng)新。

          量化互聯(lián)網(wǎng)運用指數(shù)。媒體融合的核心就是互聯(lián)網(wǎng)化。量化互聯(lián)網(wǎng)運用指數(shù),不應(yīng)僅重視數(shù)字的堆砌,更應(yīng)該從以下幾個指標(biāo)來衡量:跨界融合;創(chuàng)新驅(qū)動;品牌重塑;用戶體驗;開放生態(tài);連接一切。

          建立退出機(jī)制。媒體退出是指媒體機(jī)構(gòu)停止運行或媒體原有形態(tài)終結(jié)等。有創(chuàng)辦就必有退出。人類傳播史就是在媒體創(chuàng)辦與退出、生與死的交替中不斷演進(jìn)和發(fā)展的。因此,退出和“生”是同等程度的概念。長期以來,我國媒體單位只有準(zhǔn)入而沒有退出。近些年,各地均有媒體關(guān)閉,但基本上屬于被動退出,并不是依據(jù)產(chǎn)能效能來倒逼。建立媒體融合退出機(jī)制,有利于媒體在供給側(cè)改革的驅(qū)動下,完善存量結(jié)構(gòu)的調(diào)整。

          (作者系溫州商學(xué)院傳媒與設(shè)計藝術(shù)學(xué)院院長、教授)

          注釋:

          ①威爾伯·施拉姆:《傳播學(xué)概論》,新華出版社1984年版,第23頁。

          ②③④馬歇爾·麥克盧漢《理解媒介——論人的延伸》,譯林出版社,第19頁、第5頁、第3~4頁。

          ⑤郭全中:《媒體融合要善用智能傳播平臺》,

          http://media.people.com.cn/n1/2016/0422/c40606-28295564.html。

          ⑥《范以錦、宋建武、沈浩、郭全中談2016媒體融合》,http://www.cssn.cn/bk/bkpd_qkyw/bkpd_rdwz/201612/t20161229_3363130.shtml。

          ⑦陳國權(quán):《2017中國報業(yè)發(fā)展報告》,《編輯之友》2018年第2期。

          ⑧參見克萊頓·克里斯坦森:《創(chuàng)新者的窘境》,中信出版社2010年版。

          ⑨《編輯后撤、算法當(dāng)?shù)?媒體如何提供內(nèi)容競爭力?》,

          http://media.people.com.cn/n1/2017/0821/c14677-29484390.html

          . 背景介紹

          1.1. 業(yè)務(wù)介紹

          A平臺與B平臺同屬于同一系統(tǒng)鏈路上,前者主要致力于為用戶提供注冊入駐服務(wù),后者則專注于提供具體業(yè)務(wù)操作服務(wù)。兩者皆為運營人員所依賴的在線管理工具。

          1.2. 現(xiàn)狀分析

          目前這兩個平臺服務(wù)于同一業(yè)務(wù)方,且B應(yīng)用的頁面已經(jīng)100%嵌入到了A應(yīng)用的平臺上,除此以外目前存在系統(tǒng)上及體驗上的痛點如下:


          ??

          所以當(dāng)時我們考慮既然服務(wù)于同一業(yè)務(wù)方是否能在代碼層面上將兩個平臺進(jìn)行融合,通過系統(tǒng)的融合來達(dá)到優(yōu)化用戶體驗以及降本增效的效果呢?

          2.成果展示

          平臺融合后,主要的優(yōu)化點體現(xiàn)在以下四方面:


          ??

          優(yōu)化前(跳轉(zhuǎn)單個頁面白屏?xí)r間達(dá)2998ms左右):


          ??

          優(yōu)化后(跳轉(zhuǎn)單個頁面白屏?xí)r間800ms左右):


          ??

          3. 具體措施

          3.1. 方案調(diào)研

          3.1.1. 部署方式

          ?部署優(yōu)化:A應(yīng)用前后端合部署,現(xiàn)計劃分離前端獨立部署;

          ?資源節(jié)約:經(jīng)行云部署平臺調(diào)研,擬采用混合部署策略,將A應(yīng)用與B應(yīng)用前端靜態(tài)資源集中部署于一組容器,以優(yōu)化資源利用;


          ??

          3.1.2. 代碼倉庫整合

          ?A應(yīng)用的三個項目與后端共享一個代碼倉庫,采用統(tǒng)一的編碼標(biāo)準(zhǔn);而B應(yīng)用則使用獨立的代碼倉庫,需從中分離出前端代碼,并確保分離過程不影響現(xiàn)有配置;

          3.1.3. 項目框架

          ?4個項目的技術(shù)選型框架都為vue2,依賴項略有不同;

          3.1.3. 系統(tǒng)權(quán)限

          ?A應(yīng)用和B應(yīng)用為erp登錄;

          3.2. 架構(gòu)設(shè)計

          為了讓用戶融合無體驗差別,兩個平臺的用戶繼續(xù)使用各自的域名進(jìn)行訪問,融合后的項目可以自動識別當(dāng)前環(huán)境,加載對應(yīng)的內(nèi)容;保證融合前后用戶查看的內(nèi)容是一致的;


          ??

          3.3. 具體方案

          3.3.1. 目錄結(jié)構(gòu)設(shè)計

          針對融合,我們首先考慮的是融合后如何防止文件沖突,減少融合的復(fù)雜度,降低出問題的概率。保證兩個系統(tǒng)能正常運行;拆分邏輯分以下三個方面:

          1.文件拆分與分類

          兩個系統(tǒng)涉及到幾十個文件,經(jīng)過分析,我們將其拆分成以下幾部分內(nèi)容:【頁面文件、公共組件文件、mock文件、AxPI接口文件、基礎(chǔ)請求封裝文件、路由組件文件、Store文件、公共樣式文件、公共方法組件、mainjs文件、index.html文件】

          2. 結(jié)構(gòu)整合與差異化處理

          由于兩個項目的結(jié)構(gòu)相似,我們可以針對各個部分進(jìn)行整合。整體的思路是,對于差異比較大的文件,建立兩個獨立的文件夾,分別包含系統(tǒng)A和系統(tǒng)B的內(nèi)容;然后通過一個index文件,識別到當(dāng)前的運行環(huán)境是系統(tǒng)A還是系統(tǒng)B,再分別加載對應(yīng)的內(nèi)容;

          3. 內(nèi)容融合與沖突解決

          針對差異比較小或者無差異的文件,我們將文件內(nèi)容進(jìn)行融合。對于沖突的內(nèi)容,我們進(jìn)行了手動修改,并對全局引用部分進(jìn)行同步修改;

          ├── root
          │   ├── mocks
          │   ├── public
          │   ├── src
          │   │   ├── api
          │   │   │   ├── apiA      // 存儲 A 業(yè)務(wù)請求接口
          │   │   │   ├── apiB       // 存儲 B 業(yè)務(wù)請求接口
          │   │   │   ├── apiC         // 存儲 C 業(yè)務(wù)請求接口
          │   │   │   ├── baseHttp.js   // 封裝基礎(chǔ)請求
          │   │   │   ├── ARequest.js   // A業(yè)務(wù)的公共處理,請求header和響應(yīng)code碼等處理
          │   │   │   ├── BRequest.js  //  B業(yè)務(wù)的公共處理,請求header和響應(yīng)code碼等處理
          │   │   │   ├── CRequest.js   // C業(yè)務(wù)的公共處理,請求header和響應(yīng)code碼等處理
          │   │   │   ├── DRequest.js  //  D業(yè)務(wù)的公共處理,請求header和響應(yīng)code碼等處理
          │   │   ├── assets
          │   │   │   ├── icons     // icon內(nèi)容
          │   │   ├── common
          │   │   │   ├── config
          │   │   │   ├── styles      // 一些公共的樣式
          │   │   ├── components      // 公共組件
          │   │   ├── directive       // 自定義指令
          │   │   ├── layout        //公共布局
          │   │   ├── router
          │   │   │   ├── a.js   // 對應(yīng)a應(yīng)用
          │   │   │   ├── b.js   // 對應(yīng)b應(yīng)用
          │   │   │   ├── c.js   // 對應(yīng)c應(yīng)用
          │   │   │   ├── index.js
          │   │   ├── store
          │   │   │   ├── modules
          │   │   │   ├── getters.js
          │   │   │   ├── index.js
          │   │   ├── utils   
          │   │   ├── views
          │   │   │   ├── a    // a 業(yè)務(wù)文件
          │   │   │   ├── b    // b 業(yè)務(wù)文件
          │   │   │   ├── c    // c 業(yè)務(wù)文件
          │   │   ├── main.js
          │   │   └── App.vue
          │   ├── env
          │   ├── package.json

          3.3.2. 應(yīng)用類型判斷

          應(yīng)用類型判斷是我們重要的一環(huán),是我們識別環(huán)境的基礎(chǔ),當(dāng)用戶通過不同的域名訪問到應(yīng)用的時候,前端維護(hù)一個映射表,不同的域名代表不同的應(yīng)用;在main.js文件中會在第一時間執(zhí)行判斷識別;

          let APPLICATION_TYPE = 'a'
          let host = window.location.host;
          
          // 維護(hù)域名列表,包含測試和線上環(huán)境
          const A_HOST = ['a.com','a_pre.com']
          const B_HOST = [] 
          const C_HOST = []
          const D_HOST = []
          
          if(A_HOST.includes(host)){
              APPLICATION_TYPE = 'a'
          }else if(B_HOST.includes(host)){
              APPLICATION_TYPE = 'b'
          }else if(C_HOST.includes(host)){
              APPLICATION_TYPE = 'c'
          }else if(D_HOST.includes(host)){
              APPLICATION_TYPE = 'd'
          }
          // 掛載全局
          window._APPLICATION_TYPE = APPLICATION_TYPE

          3.3.3. 路由設(shè)計

          根據(jù)不同的域名獲取路由配置,根據(jù)路由配置生成路由;系統(tǒng)A和系統(tǒng)B各自維護(hù)一個路由列表;當(dāng)從后端請求回來路由結(jié)構(gòu)之后,根據(jù)不同的應(yīng)用映射不同的文件內(nèi)容;其中路由path保持不變,compoent增加前綴(應(yīng)用類別)找到對應(yīng)的應(yīng)用下的組件;

          ?第一步:前端獲取當(dāng)前域名,確認(rèn)當(dāng)前應(yīng)用

          根據(jù)全局的 APPLICATION_TYPE 字段識別

          ?第二步:前端維護(hù)一個路由列表

          let router=[
          {
              path: '/home',
              component: Layout,
              meta: {  title: '首頁', icon: 'el-icon-s-grid', alwaysShow: true },
              redirect: '/home',
              children: [
                {
                  path: '/home',
                  component: () => import('@/views/home/index'),
                  name: 'home',
                  meta: { title: '首頁', icon: ''}
                }
              ]
            }
          ]

          ?第三步:根據(jù)當(dāng)前應(yīng)用請求后端接口,獲取路由配置信息(component的路徑前拼接各個應(yīng)用的文件名)

          let RouterApi={'a':'/api1','b':'/api2','c':'api3'}
          api.get(RouterApi[APPLICATION_TYPE])
          component='各個應(yīng)用文件名'+接口返回路徑

          ?第四步:針對在路由信息放置在前端的應(yīng)用,前端維護(hù)一個路由的配置信息表

          import dRouter from './d.json'
          if(APPLICATION_TYPE==='d'){
             router=dRouter
          }

          ?第五步:根據(jù)路由配置信息,生成路由結(jié)構(gòu)

          ?第六步:實例化Vue對象

          3.3.4. 環(huán)境變量設(shè)計

          環(huán)境主要分為以下幾種:mock環(huán)境、本地開發(fā)環(huán)境、測試環(huán)境、線上環(huán)境

          不同的環(huán)境對應(yīng)不同的變量文件,在變量文件中設(shè)置每個端需要用到的參數(shù),結(jié)合 APPLICATION_TYPE 和變量文件的配置,獲取到對應(yīng)的參數(shù)

          示例:

          # .env.pruduction
          
          # a 業(yè)務(wù)
          VUE_APP_A_BASEURL = ''   
          # b 業(yè)務(wù)
          VUE_APP_B_BASEURL = ''
          # c 業(yè)務(wù)
          VUE_APP_C_BASEURL = ''
          # d業(yè)務(wù)
          VUE_APP_D_BASEURL = ''

          3.3.5. 請求設(shè)計

          1.公共請求的封裝

          封裝基礎(chǔ)的公共請求createHttp.js,各業(yè)務(wù)基于公共的請求和各自的code碼,請求參數(shù)等信息進(jìn)行再次封裝,然后可以按照業(yè)務(wù)需求調(diào)用;

          ?基礎(chǔ)請求:createHttp.js

          ?業(yè)務(wù)公共封裝:

          a. ARequest.js(A業(yè)務(wù)公共參數(shù)和code碼處理)

          b. BRequest.js (B業(yè)務(wù)公共參數(shù)和code碼處理)

          c. CRequest.js(C業(yè)務(wù)公共參數(shù)和code碼處理)

          d. DRequest.js(D業(yè)務(wù)公共參數(shù)和code碼處理)

          ?業(yè)務(wù)層調(diào)用:

          a. api/apiA A業(yè)務(wù)接口

          b. api/apiB B業(yè)務(wù)接口

          c. api/apiC C業(yè)務(wù)接口

          // 公共請求封裝  baseHttp.js
          export const createHttp = (baseUrl, successFun = () => {}, errorFun = () => {}, requestInterceptor = () => {}) => {
            const http = axios.create({
              baseURL: baseUrl,
              timeout: 5 * 60 * 1000,
              withCredentials: true
            })
            // http request 攔截器
            http.interceptors.request.use(
              async config => {
                await requestInterceptor(config)
                return config
              },
              err => {
                return Promise.reject(err)
              }
            )
            // http response 攔截器
            http.interceptors.response.use(successFun, errorFun)
            return http
          }

          2. 直接調(diào)用后端服務(wù)請求封裝

          //A業(yè)務(wù)基礎(chǔ)請求 
          function requestInterceptor(){
              // A系統(tǒng)公共請求參數(shù)處理... 
          }
          function successFn(){
              // A系統(tǒng)公共響應(yīng)結(jié)果處理 統(tǒng)一新增
          }
          function errorFn(){
              // A共異常處理 包括code碼等情況
          }
          export default createHttp(baseUrl,successFn,errorFn,requestinterceptor)

          3. 業(yè)務(wù)接口使用,根據(jù)不同的業(yè)務(wù)劃分不同的目錄分支

          // A業(yè)務(wù)請求調(diào)用
          ARequest.get(url,{params:data})
          //B業(yè)務(wù)請求調(diào)用
          BRequest.post(url,{params:data})

          3.3.6. 權(quán)限和登錄

          根據(jù)應(yīng)用類型字段APPLICATION_TYPE,識別不同的環(huán)境,請求不同的服務(wù)端接口;不同的服務(wù)端代表了不同的應(yīng)用;

          針對不同的應(yīng)用的未登錄情況,前端維護(hù)多套登錄處理邏輯,根據(jù)應(yīng)用類型進(jìn)行不同的處理邏輯;

          3.3.7. 公共函數(shù)設(shè)計

          創(chuàng)建一個公共的utils文件夾,針對兩個項目中的公共函數(shù)進(jìn)行合并,針對有沖突的函數(shù),進(jìn)行命名修改,全局引入的部分進(jìn)行路徑和函數(shù)的同步修改;

          3.3.8. 腳手架配置設(shè)計

          梳理了兩個項目的腳手架配置差異項及各個配置的作用,對配置作了部分的修改和優(yōu)化,在滿足原有的功能情況下不影響正常的項目運行;

          3.3.9. Vuex store設(shè)計

          store的整體結(jié)構(gòu)保持不變,在項目引用的地址也保持不變,由于項目中使用store的地方較多,保持結(jié)構(gòu)不變能保證改動成本最小,針對兩個項目中模塊名重復(fù)的情況,手動把模塊里的內(nèi)容進(jìn)行合并;


          ??

          針對現(xiàn)有的名稱重復(fù)內(nèi)容不一樣的函數(shù),根據(jù)應(yīng)用類型字段 APPLICATION_TYPE 把兩個函數(shù)進(jìn)行融合進(jìn)行分別處理;

          3.3.10. 頁面引用設(shè)計

          ?引用方式變更

          由于業(yè)務(wù)需求,應(yīng)用A中嵌套了應(yīng)用B的頁面,之前通過iframe引用。融合后,頁面文件和組件不再隔離,可以直接引入應(yīng)用B的文件和組件;

          ?后端數(shù)據(jù)打通

          應(yīng)用A的后端服務(wù)器上有一些功能,如下載列表,應(yīng)用B項目需要使用時因數(shù)據(jù)不通難以直接引用。前端融合后,可以在應(yīng)用B中直接引用應(yīng)用A的頁面組件,實現(xiàn)業(yè)務(wù)的順暢使用。效果如下:


          ??

          4. 總結(jié)

          在經(jīng)歷了為期兩個月的緊張工作后,我們成功地將兩個大型項目進(jìn)行了深度整合,取得了顯著的階段性成果。通過這一融合過程,我們不僅統(tǒng)一了項目的代碼規(guī)范和架構(gòu),還顯著提升了組件的復(fù)用率。盡管在這個過程中我們遇到了諸多挑戰(zhàn)和曲折,但最終的成果——用戶體驗的顯著提升——使一切努力都顯得彌足珍貴。

          我們深知,每一個成功的項目背后都有無數(shù)次的嘗試和優(yōu)化。在這個過程中,我們不斷學(xué)習(xí)、適應(yīng)和完善,最終實現(xiàn)了項目的無縫融合。我們相信,這段經(jīng)歷和我們所取得的成果,不僅為我們團(tuán)隊帶來了寶貴的經(jīng)驗和教訓(xùn),也可能為那些正在經(jīng)歷類似挑戰(zhàn)的同學(xué)提供了一些啟示和幫助。


          作者:京東零售 高雅薇

          來源:京東云開發(fā)者社區(qū)

          tml+css基礎(chǔ)一:html簡介和發(fā)展史

          HTML全稱(hypertext markup language)譯為超文本標(biāo)記語言,其譯文代表了HTML的含義,它和其他編程語言不同的是,HTML不是一門真正意義上編程語言,而是一種標(biāo)記語言,通過帶有尖角號的標(biāo)簽對文本進(jìn)行標(biāo)記,從而實現(xiàn)網(wǎng)頁的結(jié)構(gòu)搭建。

          1.2、HTML發(fā)展史

          HTML創(chuàng)始人(蒂姆·伯納斯-李)蒂姆·伯納斯-李除了是HTML的創(chuàng)始人,還是w3c組織的主席。

          1、HTML1.0 (1991年12月)

          1991年萬維網(wǎng)(www)在互聯(lián)網(wǎng)上首次露面,也隨之引起了巨大的轟動。

          1989年,伯納斯-李寫了一份備忘錄,提出建立一個基于互聯(lián)網(wǎng)的超文本系統(tǒng)。同年和另外一個工程師一起進(jìn)行聯(lián)合資金申請,但是這個項目并沒有通過。

          1991年底的時候,伯納斯-李公開了一份“HTML Tag”的文檔,里面描述了組成HTML初始版本的18個元素

          2、HTML2.0(1995年11月)

          HTML 2.0是HTML語言的擴(kuò)展。????

          與原始版本的HTML不同,HTML 2.0被創(chuàng)建為Web標(biāo)準(zhǔn),規(guī)定了常見的網(wǎng)頁結(jié)構(gòu)

          3、HTML3.2(1996年1月)

          慘淡的"第一次瀏覽器大戰(zhàn)時期(Netspace Vs IE)",兩大巨頭不斷推出重大舉措試圖控制整個領(lǐng)域。???????

          網(wǎng)頁開發(fā)者是這場戰(zhàn)爭中的焦點。商業(yè)戰(zhàn)爭就像軍備競賽,各家公司為了保持領(lǐng)先,招兵買馬。各家都有各家的規(guī)則。?????????

          那時候,你不得不寫兩份不同的網(wǎng)頁,一個用于網(wǎng)景的瀏覽器,另一個用于微軟的瀏覽器

          4、HTML4(1997年12月)

          瀏覽器大戰(zhàn)接近尾聲,W3C(世界萬維網(wǎng)聯(lián)盟)成立,他們打算通過制定統(tǒng)一的HTML標(biāo)準(zhǔn),使整個產(chǎn)業(yè)能有序的發(fā)展。 ? ? ? ? ? ?

          他們計劃用兩種語言分離出HTML的表達(dá)式(HTML 4.0)和結(jié)構(gòu)(CSS),并且說服瀏覽器廠商接受這些標(biāo)準(zhǔn)

          這次發(fā)布提供了規(guī)范的三種變體:

          Strict,嚴(yán)格版本;

          Transitional,過渡版本;

          Frameset,iframe框架集;

          HTML4.0 采納了許多瀏覽器特定的元素類型及屬性,但是同時也把 Netscape 的視覺化標(biāo)記標(biāo)記為過時的尋求淘汰; 贊成使用樣式表; 同時在1998年4月對HTML4.0進(jìn)行了微小的修訂,沒有增加版本號HTML5.0

          5、HTML4.01(1999年12月)

          像 HTML4.0 一樣提供了三種變體,并且他的最終錯誤修訂版在2001年的5月12日發(fā)布

          6、XHTML 1.0(2000年1月)

          各大瀏覽器廠商紛紛接受W3C標(biāo)準(zhǔn)的時候,新技術(shù)出現(xiàn)了。?????????????

          HTML和另一種語言XML融合,XHTML(可拓展的超文本標(biāo)記語言)就此誕生。???????????

          它繼承了HTML的通用型和瀏覽器的兼容性,繼承了XML的嚴(yán)密性和可拓展性

          7、HTML5(2014 年 10 月)

          HTML5是HTML最新的修訂版本,由W3C制定,目標(biāo)是取代1999年所制定的HTML 4.01和XHTML 1.0標(biāo)準(zhǔn)

          我們現(xiàn)在使用的是html5版本,因為由于新興框架的出現(xiàn)和瀏覽器兼容性的提升,讓我們選擇了html5。


          主站蜘蛛池模板: 色窝窝免费一区二区三区| 国产一区二区精品久久凹凸 | 中文字幕精品一区影音先锋| 日韩伦理一区二区| 亚洲综合av永久无码精品一区二区 | 亚洲综合国产一区二区三区| 一区二区三区日本电影| 国产成人一区二区在线不卡| 国产精品一区视频| 成人中文字幕一区二区三区| 人妻体体内射精一区二区| 精品一区二区三区四区| 日本道免费精品一区二区| 亚洲性色精品一区二区在线 | 一区二区三区视频免费| 国产视频一区二区| 美女视频一区二区| 一区二区三区日本电影| 久久精品国产亚洲一区二区三区| 搜日本一区二区三区免费高清视频 | 无码视频一区二区三区在线观看| 日本亚洲国产一区二区三区| 国产精品区一区二区三在线播放| 国产一区二区三区乱码| 无码一区二区三区免费| 亚洲视频一区在线观看| 亚洲色精品三区二区一区| 亚洲日韩AV一区二区三区四区| 精品少妇人妻AV一区二区| 日韩精品一区二区三区在线观看l| 亚洲色精品VR一区区三区 | 中文字幕aⅴ人妻一区二区| 久久国产一区二区| 日本一区二区三区爆乳| 无码日韩人妻AV一区免费l| 国产午夜毛片一区二区三区 | 国产乱码精品一区二区三区香蕉| 国产在线步兵一区二区三区| 国产一区三区三区| 国产福利91精品一区二区| 国产第一区二区三区在线观看|