時(shí)間：2016422（星期五）地點(diǎn)：國際會(huì)議中心，一層5號(hào)廳，，道來給我們介紹一下Weex各種各樣的東西。具體不多說了，大家聽聽內(nèi)容。道負(fù)責(zé)下半場。我們今天要的內(nèi)容叫“Weex移動(dòng)端高性能動(dòng)態(tài)化方案。昨天大家也參與了我們QCon第一天的會(huì)議，我們大也宣布了我們Weex會(huì)啟動(dòng)開源內(nèi)測，截至到今天中午，我們統(tǒng)計(jì)申請(qǐng)內(nèi)測用戶突破1400家熱烈程度遠(yuǎn)遠(yuǎn)超過我動(dòng)態(tài)性，這肯定是我們最需要的東西。第二個(gè)，它一定是開放互聯(lián)的，PC端一直也是這樣方案。Weex是從去年雙十要的時(shí)候第一次在我們正式產(chǎn)品中使用，承載了雙十一主會(huì)場工作，Weex是不是除了做主會(huì)場別的地方就比較吃力呢？從去年雙十一到現(xiàn)在，包括我們自尸動(dòng)畫，掃雷、計(jì)算器都有，各種豐富場景的東西都可以通過Weex做出來，不僅僅是做主會(huì)場的技術(shù)方案。我們談?wù)刉eex團(tuán)隊(duì)對(duì)移動(dòng)端開發(fā)模型的理解。APP是這樣一個(gè)最佳實(shí)踐，首先把移動(dòng)端所有界面拆分成各個(gè)配HTML這些前端非?？焖賾?yīng)用好學(xué)的語法作為一個(gè)開發(fā)體驗(yàn)，提供給我們的開發(fā)者。這里強(qiáng)調(diào)一下，我們語法設(shè)計(jì)尊重了web標(biāo)準(zhǔn)，包括源代碼都是非常優(yōu)秀的框架來的。我們開源內(nèi)測同步在海外通過途徑在宣傳，得到了非常熱和激動(dòng)，想知道什么時(shí)候看到源代碼，和我們們覺得也是值得高興的一件事情。最激動(dòng)人心的是現(xiàn)場寫東西，接下來我會(huì)做一個(gè)demo。昨天Kindle最后提問環(huán)節(jié)有人問到我們說Weex可不可以（英文當(dāng)時(shí)說沒有，其實(shí)我們只是做好了，只不過沒有給做演示，所以大家今天比較有幸能夠比更早看到livedemo的東西。我們有 ，左下角，大家可以在官網(wǎng)Android版本。除了這些具體例子之外，右上角有 都沒有，接下來我現(xiàn)寫代碼，讓大家感受一下Weex開發(fā)有方便快捷。我現(xiàn)在寫一段文本text，oQCon保存，就會(huì)呈現(xiàn)完整狀態(tài)。如果加一些樣式，保存之后字跡會(huì)變大，接下來我加一個(gè)，我把QConlogo加進(jìn)來，是我提的，想共用，我們有一個(gè)最佳實(shí)踐，寫一個(gè)class，比如讓它居中，我設(shè)計(jì)一個(gè)class，如果讓它不要頂在天上我可以寫一個(gè)100像素的margin-top這是基本的演示和功能。repeat，通過下面的數(shù)據(jù)綁定一段數(shù)據(jù)，這個(gè)數(shù)據(jù)可以通過repeat展開，比如listAC清零。這里結(jié)構(gòu)做好，數(shù)據(jù)綁定好，樣式做好，下面寫API調(diào)用的，這里給大家兩個(gè)簡單的例子。上下各有兩段文本，這個(gè)功能一同時(shí)會(huì)彈一個(gè)（英文APImodel模塊，一個(gè)是（英文）模塊，點(diǎn)擊這toastAPI調(diào)用和模塊加載的簡單演示。template，style，scrIptview里面modelview非常順暢的控制邏輯和代碼方式，這也算是Weex上層語法設(shè)計(jì)基礎(chǔ)。如果大家做的界面比較復(fù)雜，可能有細(xì)節(jié)，或者做分解，我們需要從整體上對(duì)整個(gè)界以模塊為單位作為拆解，對(duì)每個(gè)模塊做定義，如templatevirtualDOMtree展示，包括事件綁定，組件跟組件之間還可以嵌套，還可以有子元素，這是整體template結(jié)構(gòu)。styletemplate結(jié)構(gòu)更加清晰，不至于陷入到整個(gè)具體描述當(dāng)中去。我們?cè)谶@邊會(huì)做一些收斂，我們只支持了單個(gè)class的cssNN的數(shù)據(jù)庫，匹配過程非常復(fù)雜，性能也得selectorclass，性能可以保證。scopedclassname，不擔(dān)心和其他組件相，其實(shí)這也是我們非常重視的，在實(shí)踐上我們把它做到了scoped。其Android下，界面加載過程用戶是可感知的，不是一瞬間做到的。我們加這個(gè)值可以讓你精append設(shè)計(jì)東西的話，里面一系列東西會(huì)做加載，IDID拿到這個(gè)值，把APIdiv空白容器、圖scrollerlist，性能上自動(dòng)做內(nèi)存管理和資input，輸入框我們是最近才做的，templatestyle部分的介紹。lxllxied和tickytickyBC果就是tick，當(dāng)你走它就跟著走在各端當(dāng)中呈出來。樣，clckcaear和aaeararcitvielaa和esae創(chuàng)建的候數(shù)完的時(shí)候我們會(huì)三個(gè)生命期方法只要把三個(gè)方a和esaeo組件通過o就以嵌入別的o件中來，遞的話可以在o組件中寫a和，o也是事機(jī)制個(gè)組件以通過定和解自定義事的解綁定想觸發(fā)vew同時(shí)我們望收集相關(guān)素，做出具，提供好的開者體驗(yàn)大家。的內(nèi)容，包括剛才演示的ground-APP都可以通過我們的官網(wǎng)找到，現(xiàn)在處在開源算是一個(gè)感性直觀的對(duì)Weex的感受，接下來同事鬼道會(huì)為大家介紹一下它背后的工作原理，還有Weex具體團(tuán)隊(duì)做這件事情的時(shí)候，以及工程化角度的思考，給大家維度的：感謝勾股的，我在下半場會(huì)給大家介紹Weex的工作原理。這大家DSLH5，我刻意把它用不一方稍微加亮一些。我們把剛才這再稍微展開一下，最上面是我們的DSL，我們一般叫轉(zhuǎn)換是不是有性能問題，因?yàn)檫@在服務(wù)端就已經(jīng)完成。到了客戶端，第一層是我們的JS，成基本語法約定包括自變量的轉(zhuǎn)換最后是基本上是直譯過來這里出現(xiàn)nativeJS線程優(yōu)先保障我們的流暢性，未來我們會(huì)有的技術(shù)文檔，比較細(xì)節(jié)的放出來。，放在連忙，大家如果是能夠看到的。在我們做壓測的時(shí)候調(diào)到三千個(gè)節(jié)點(diǎn)，大概10100個(gè)節(jié)點(diǎn)左右。我們看一下數(shù)據(jù)，第一個(gè)性能對(duì)一幀，scrollerrecycleview，會(huì)好一些。再往下是CPU，靜默CPU消耗，還有運(yùn)行過程中CPU的峰值。靜默CPU0點(diǎn)幾，我們不1616CPU會(huì)更高一些。這是一個(gè)真實(shí)數(shù)據(jù)，3月份頁面上線之后我們看了一下，這張頁面是一個(gè)活動(dòng)，3月份往往都會(huì)提到幀率、加載時(shí)間，但往往會(huì)忽略一個(gè)事情，H5開發(fā)中沒有說有一個(gè)資源在服務(wù)端加載，有一個(gè)副作用，我們有一個(gè)JS必須從服務(wù)端，我們把JS弄到客戶端里，免WeexWeex例子，第一排舉一個(gè)具體數(shù)字，業(yè)務(wù)代碼改了三個(gè)版本（英文）三個(gè)版本，最后會(huì)有三的立方27跑在（英文環(huán)境下，但和JS安全還是有差異。再往下是自動(dòng)化工作，這塊工作細(xì)分也可以API級(jí)別的效果不是很好。所以這種我們會(huì)通layoutresultsmodel，包括其他再就是擴(kuò)展性，我們先回顧一下這，前面也有提到，目前Weex給大家直觀的感覺是可以用Weex寫很多頁面，有一個(gè)路由機(jī)制，叫導(dǎo)航條，一系列機(jī)器幫助你將頁面進(jìn)在DSL上看到的是API，底層就是module。如果擴(kuò)展module也是一樣的，這是很簡單的跳module就完成了，很簡單。componentslifecycle考慮，再是動(dòng)Weex容器之間通信機(jī)制，數(shù)據(jù)、網(wǎng)絡(luò)，包括下面涉及到的一堆傳感器，包括基礎(chǔ)的FS，還有偏業(yè)務(wù)類的東西，module上，目前已經(jīng)達(dá)到這個(gè)狀態(tài)。們正在討論以及會(huì)安排時(shí)間逐步完成的東西這些都是工具我們首先給大家提供一個(gè)如果只是的話是可以的，如果自己做一個(gè)獨(dú)立的APP，你要用Weex做的話我們也會(huì)給，最后，Weex提到了模式的概念，大家可以把它當(dāng)成一個(gè)全頁來應(yīng)用，就像用H5寫一fullpageH5（英文nativecomponent。H5H5componentAPPFramework這做一個(gè)完整頁面，nativecomponent，大家打開手淘就會(huì)看到這個(gè)頁面。再看一下H5component，直接看效果。大家關(guān)注中間，應(yīng)該可以感覺到下面是幾張不同的H5頁面，代H5H5H5中保持駐留，點(diǎn)擊效果好一些。右邊是一個(gè)用H5寫的常列表。當(dāng)我們寫這樣一個(gè)H5component，然后做一個(gè)替換是滾動(dòng)的事件跟隨，H5Weex300坑位很長的頁面，H510020兆左右。，將版本獨(dú)立出獨(dú)立的客戶端可使用的SDK，將樣式，將基礎(chǔ)的component做了擴(kuò)展，這onensourcepublic就會(huì)開放出來。最后APPFramework這些東西會(huì)放出來。最后是我們的官網(wǎng)，大家可以掃頁面去訂閱，或者察看你感的信息，也可以在上和我們聯(lián)系，謝謝大家！事想了解Weex情況可以到門口聯(lián)系。是開發(fā)的開源框架，既然叫ReactMix，肯定和React是有關(guān)系的，從前端思路讓你把H5的？大家覺得有哪些不好用？JS變量定義，如果用其他的定義需要引入其他模塊。這是我覺得它很不爽的地方。CSSCSSclassname實(shí)現(xiàn)基本的復(fù)用，如果少了這ReactNative一些它的寫法像JS寫法，包括推出來的，都是希望大家基于這個(gè)方式來寫。第二點(diǎn)說出了Weex最大的不同是什么，WeexclassReactMixclass，這樣的話就很像你H5一樣，H5classnameclassname同時(shí)存在的時(shí)候才可以。它H5。ReactMixCSSReactMixCSS現(xiàn)有頁面，怎么用呢？在ReactNative里面是通過關(guān)鍵字加載的，找到你這個(gè)文件的路徑，這個(gè)文件打包的方式，也可以說利用這個(gè)，在這里你直接使用require，在運(yùn)行的時(shí)候動(dòng)態(tài)解析requireAPI，甚至你可以把這個(gè)東西做成一個(gè)別名，后面會(huì)有一個(gè)編譯器幫助你翻譯，它在瀏覽器運(yùn)行環(huán)境里可以動(dòng)態(tài)幫你把它加在里面。但是在ReactNative里面只需要寫一個(gè)require，解析，ReactNative只是CSS文件的類別寫法，對(duì)于很多屬性你必須明確含義，不能夠支持CSS的簡寫，有些屬性ReactNative幫你做了，有些沒做，它可能上下兩個(gè)方向幫你做CSSCSS文件一樣的JSReactNativeCSSReactNativeCSS文件，就是原始的文件。queryqueryCSSCSS文件，如何編譯成為你ReactNative支持的文件，包括文件變化，包括整個(gè)的編譯。，的5和6相比6的屏幕要比5要大，我如果按照5，前面提了一個(gè)點(diǎn)，像ReactNative只支持內(nèi)連的CSS，我們要實(shí)現(xiàn)下面這種例子，比如說像.classB，.classA，最終節(jié)點(diǎn)渲染需要往下查副節(jié)點(diǎn)，判斷最終節(jié)點(diǎn)里有哪些class屬性，舉一個(gè)例子比如我有個(gè)節(jié)點(diǎn)有classname屬性在CSS文件里定義可能就（英文，要滿足副節(jié)點(diǎn)包含classB副副節(jié)點(diǎn)包含classC對(duì)于ReactMix來說如果直接按照classA、B、CABC三個(gè)樣式組合在一起，可以看到樣式組合。這個(gè)時(shí)候我要以最終生效的節(jié)點(diǎn)，比如以classC為例，做個(gè)標(biāo)記，比如向上的小classB之前有哪些限制條件。包括classC和classB這些，我會(huì)再對(duì)這個(gè)節(jié)點(diǎn)做向上編譯，看副節(jié)點(diǎn)是否滿足我語言最后元素。如果包含取出來最后語言樣數(shù)我就認(rèn)為它滿足條件，并且為空，我就可以利用prefix樣式，稱之為多重classnameH5時(shí)是經(jīng)常被用到的例子。這邊一是我們剛才說的我們?nèi)绻枰ソ馕鼋?jīng)常說的CSS文件里面的單位要怎么API，算出頁面的尺寸大小，然后做計(jì)算，最終生HTML的問題，更加簡單一點(diǎn)。正常來看，對(duì)HTMLdivspanimage來說可以實(shí)現(xiàn)對(duì)應(yīng)的例子，但你需要去做什么事呢？在瀏覽器里面，image可以動(dòng)態(tài)獲知大小，根據(jù)大小給它定義一ReactNativeReactMix來說，你可以不需要知道大小，動(dòng)態(tài)內(nèi)容，根據(jù)內(nèi)容動(dòng)態(tài)信息，自動(dòng)大小，HTMLAPI，你可以直接寫自己的自定義事件，同時(shí)得到事件的傳遞參數(shù)，domevent對(duì)象，手動(dòng)觸發(fā)它的冒泡機(jī)制。這里面還有一個(gè)比較討厭的點(diǎn)，我們要去找一個(gè)具體的元素有這樣一個(gè)問題，我只能局限在component里面，把它分割過小就會(huì)遇到一個(gè)問題，componentReactNative寫比較麻煩。我需要對(duì)子元素做一個(gè)屬性，定義個(gè)，找到componentA的節(jié)點(diǎn)，我可以基于sizzle選擇器找到這element對(duì)象。我們是怎么找到這個(gè)元素的呢？其實(shí)找到元素的方法有很多，在每個(gè)節(jié)點(diǎn)動(dòng)態(tài)給你數(shù)，如果丟添加他不會(huì)添加，如果你沒添加他會(huì)動(dòng)態(tài)給你添加屬性，有了這個(gè)ID，他會(huì)一個(gè)數(shù)組把這個(gè)ID給添加上去當(dāng)你根據(jù)數(shù)據(jù)節(jié)點(diǎn)找這個(gè)元素可以在里面找。classname也有對(duì)應(yīng)的數(shù)據(jù)。我們剛才封裝了對(duì)象，判斷我寫的關(guān)系是否正確，HTML的事件，我們可以支持標(biāo)準(zhǔn)的CSS文件和屬性，我們擴(kuò)展了元素的實(shí)現(xiàn)。這些步驟全部做完之后，我可以把ReactNativeH5開發(fā)。剩下要解決的問題就比較簡單了，API同步問題。ReactNative里APIReactNativeAPI，對(duì)于我H5functionmethod代碼，變成ReactNative代碼，async+awaitcodestyleAPI是同步的，哪些是異步的。需要加關(guān)鍵字，把異步代碼轉(zhuǎn)成API放在關(guān)鍵字列表里面，動(dòng)態(tài)編譯的時(shí)候動(dòng)態(tài)添加異步關(guān)鍵字，對(duì)于開發(fā)完全透明，他只要像瀏覽器一樣寫自己熟知的API就可以了。我們基于ES7的語法，需要通過babel等工具做代碼降級(jí)。我前面說的這些點(diǎn)都是ReactMix基于由于強(qiáng)方式做代碼，比如大家都使用ReactNative，或者你有一個(gè)項(xiàng)目，你引入了第插件，或者你在H5框架要使用了（英文）框架，怎么實(shí)現(xiàn)這些框架之間的互相兼容的就像兩只都是猴子大家都是72變對(duì)于來說沒有真和區(qū)別，它的功能完全一樣的，只要我不存在命名，把命名環(huán)境縮小，理論上就不會(huì)，也就是說它是語法插件與任何框架都是無侵入式的體驗(yàn)?zāi)憧梢栽谑褂肦eactNative，可以使用其他類似的實(shí)現(xiàn)，但如果你想基于H5方式，比如你想的現(xiàn)有H5代碼，你的JS+CSSrequire也一樣，這個(gè)東西也可以動(dòng)態(tài)轉(zhuǎn)移。最后一個(gè)問題，我們前面這些問題都解決完之后有一個(gè)思考，ReactMix提供了很多語法分，拆分為兩個(gè)部分。第一個(gè)部分，我們經(jīng)常去使用的一部分，不太會(huì)變的，包括H5本身的代碼，包括語法糖的代碼，包的大小差不多200K左右，加在一起差不多30K左右大小，大部分并行操作是靜態(tài)編譯實(shí)行的真正對(duì)于業(yè)務(wù)來說它的包肯定更小一般來說在300K左右的樣子，比如我們要實(shí)現(xiàn)具體機(jī)票預(yù)定流程和航班動(dòng)態(tài)查詢，加上CSS和JS文件，加在一起差不多是這個(gè)規(guī)模。頁面的平均渲染時(shí)間差不多是IOS200，Android400作用，平均比hybrid加載速度快30%，我們希望能夠使用ReactNative幫助項(xiàng)目性能進(jìn)行整體加速。這 classname里的老師講他們只有一個(gè)是為了提高性能問題，問一下，在ReactMix在轉(zhuǎn)的時(shí)候有沒有對(duì)性能有什么提升。第二個(gè)問題，classname在這里面有沒有（英文）概念，不同的（英classname數(shù)組判斷關(guān)系，在瀏覽器里面也是這樣的實(shí)現(xiàn)原理。第二個(gè)問題，你剛剛說生命V8V8殼里面，譯概念幫助它解決CSS問題現(xiàn)在我感覺下來我們?cè)賹?duì)它做補(bǔ)丁就是做運(yùn)行時(shí)方法，提問2：知道你現(xiàn)在用的你的on，你之前的版本是0.17，現(xiàn)在是0.23，現(xiàn)在0.230.17怎么辦？有的項(xiàng)目，這個(gè)過程對(duì)開發(fā)是透明的，全部都標(biāo)注語法。（CSS文件標(biāo)準(zhǔn)翻譯中間，把它翻譯成它能夠支持的動(dòng)態(tài)元素。提問3：因?yàn)槲覀冊(cè)诳碦eactNative這部分的時(shí)候，他們有一個(gè)研發(fā)團(tuán)隊(duì)的概IOSAndroid個(gè)性的話，我怎么實(shí)現(xiàn)這個(gè)轉(zhuǎn)換？薛端陽：這部分我剛才沒說，ReactMix是語法糖，你要寫差異性的話可以寫自定義組ReactNativeAndroid寫一套阿里組件，給H5用就好了，你一旦自定義空間有一個(gè)問題，很多基本的，你對(duì)日歷空間具體的節(jié)點(diǎn)，比大家好我今天主要偏重在音方面相關(guān)的優(yōu)化或者說我們踩過的一些坑，，大家都知道，現(xiàn)在最火的就是里面最火的就是秀場類，或者秀場類互動(dòng)，需求肯定很多，很活。另外，除了秀場之外，還有教育類的互動(dòng)，方面游戲也是很大的。為什么現(xiàn)在移動(dòng)這么流行？主要是帶寬好了，4G還是相當(dāng)不錯(cuò)的，有時(shí)候比WIFI還好一點(diǎn)，再加上資費(fèi)也便宜，可以隨時(shí)隨地。說到，肯定性能好，以前不是智能機(jī)想也不來，裝不了什么東西。現(xiàn)在的24核，高端，我歸納為音編碼的SDK包括發(fā)送，里面展開講每個(gè)地方都可以講很深入的細(xì)節(jié)，不管你是的還是PC的，或者是的，都要經(jīng)過編碼發(fā)送的過程，這個(gè)基本上都第二個(gè)是流服務(wù)器和CDN分發(fā)平臺(tái)，如果你要做量很少，幾十個(gè)人沒意義，如果CDNCDN的時(shí)候，或者推到CDN邊緣流協(xié)議目前最主流的是RTMP，HLS的缺點(diǎn)是延時(shí)比較大，如果你能夠也可以，另外一個(gè)是傳統(tǒng)行業(yè)的HTTP，用的，HTTP和RTMP不一樣。到CDN之后，后面就是分發(fā)，基本上我們現(xiàn)在拉流的時(shí)候，比如我們的時(shí)候?yàn)榱诉m應(yīng)多終PCWEBAndroidIOS現(xiàn)在用的肯定比較多，因?yàn)槭且苿?dòng)端。WEB端也多，因?yàn)榇蠹疑暇W(wǎng)方便。PCwindows的APP讓大家裝一下，大家現(xiàn)在可能都沒這個(gè)需求。所以這幾種拉流方式會(huì)產(chǎn)生不同的拉流協(xié)議去做，比如說第一種就是RTMP，我們RTMP上到流服務(wù)器，把RTMP拉回去，特點(diǎn)是延時(shí)低，但缺點(diǎn)是有端口限制，不是誰都能開的。第二種的是IOS，我們?cè)诹鞣?wù)器端實(shí)時(shí)轉(zhuǎn)一下封裝格式，我們把它轉(zhuǎn)成TS封裝，但這個(gè)過程不需要什么編碼，不是什么好，了，這是最大的。另外，現(xiàn)在最大的好處是現(xiàn)在移動(dòng)端瀏覽器基本都支持，比如時(shí)來說理論上RTMP最少，其次是HTTP，然后是HLS，這是過程。，，一種是你已經(jīng)有到文件比如說你機(jī)來的當(dāng)然機(jī)也可以，HTTP上傳，正常是一個(gè)服務(wù)器，音，特別是，量很大，不可能既做轉(zhuǎn)碼又和服務(wù)器放在一起，就是，可以要CPU很差的，沒問題，轉(zhuǎn)碼如果CPU很差就歇菜了。你的時(shí)候可以錄制下來，錄制有兩種方式：一種是本地錄制，一邊一邊錄，一般端不會(huì)這么干，畢竟的空間有限。另外不停的錄，一會(huì)兒空間就搞死了。一般我們是在流塊錄下來，還有用第，比如用CDN，用其他第平臺(tái)的，我讓第給我錄也可以，但是他們要的，基本上這都屬于額外功能，都要，不光是錄制錢，還有錢，還有拉流回來，你可以自己搭一個(gè)錄制的服務(wù)器，有點(diǎn)像的客戶端，只不過加了服務(wù)器功能通過錄務(wù)器錄下來假如現(xiàn)在是一個(gè)秀場你要做產(chǎn)品，，，時(shí)候直接上行推三個(gè)不同的分辨率現(xiàn)在多屏屏幕Pad屏幕和PC屏幕肯定不一樣，720P的，360P也能看，有些流量上的考慮。所以一般情況下我們都是推比較合適的上去，如果條件可以，我們會(huì)推720P一點(diǎn)的，在服務(wù)器端有流實(shí)時(shí)轉(zhuǎn)碼，成本比較大。點(diǎn)播，文件上來了，1080P的，純的，一般都是轉(zhuǎn)成四檔分辨率，720P，甚至更低一點(diǎn)。通過一個(gè)多轉(zhuǎn)碼系統(tǒng)，這個(gè)轉(zhuǎn)碼系統(tǒng)比較耗CPU，大家也可以用GPU能轉(zhuǎn)多種分辨率轉(zhuǎn)好之后你的語言回到你的服務(wù)器上去接下來是從用戶角度來說，比如說你現(xiàn)在打開，PC打開一個(gè)網(wǎng)頁，你看到一個(gè)封面，點(diǎn)過去第一個(gè)響應(yīng)的是CDN流分發(fā)平臺(tái)上，CDN有一個(gè)好處是緩存，支持大并發(fā)。比如你這個(gè)語言很高，，CDN播服務(wù)器要這個(gè)流，點(diǎn)播服務(wù)器還要個(gè)作用（英文，刷總不能希望我一個(gè)2G的從頭CDN。大家如果感，比如VOD怎么算出來的，一般我們所有的都有一個(gè)（英文）pass一遍，會(huì)等很久，一拖動(dòng)一點(diǎn)響應(yīng)沒有?？偟膩碚f，這是總的完整的音點(diǎn)播和，數(shù)據(jù)流程就是這么走的。下面主要是針對(duì)SDK這一端各個(gè)環(huán)節(jié)展開講一下。第一個(gè)先講推流端，推流端主要是上用到的，我們還是以為例第一個(gè)是大家都知道不是采麥克風(fēng)就是采頭這兩個(gè)通用，個(gè)或者內(nèi)置一個(gè)卡同樣可以這個(gè)地方主要難度是有很強(qiáng)的平臺(tái)相關(guān)性。SDIAPI驅(qū)動(dòng)。這塊做起來看你實(shí)際項(xiàng)目需求，不可能一個(gè)人全搞常，或者說不是，就算錄東西，第一個(gè)對(duì)聲音來說就是降噪，不降噪的話壓根沒法聽。第二個(gè)是實(shí)時(shí)通話。第三個(gè)是混音，比如唱卡拉OK那種，這是音頻處理。我現(xiàn)在水印主要是從保護(hù)角度來說，比如你一個(gè)教育不想讓別人錄走還一點(diǎn)表說是高分辨率高碼率上，都是2K以上分辨率，清，比如現(xiàn)在宣傳的4K、8K這種分辨率下你是有優(yōu)勢的，但如果我們只是，搞640×360，一點(diǎn)意義沒有，至少265不和硬件，可以節(jié)省很多CPU資源。VP8和VP9，這是主推的編碼方式，號(hào)稱以VP8264比較，它的編碼質(zhì)量比264差很多，VP9好一點(diǎn)，但不通用。如果要做互動(dòng)的時(shí)候，或者實(shí)時(shí)音通話，肯定希望利用WebRTC，網(wǎng)頁打開就能音通話，就能，就能看，這樣的話幫你做了很多事情，你到時(shí)候會(huì)用VP8、VP9，但很，他不給你用264。所以如用到VP8、VP9，你可能想的是它倆的互通問題，你要在流服務(wù)器上做，實(shí)時(shí)轉(zhuǎn)換，或AACvorbis據(jù)包，直接發(fā)送出去就好了。MP4基本不用來做，因?yàn)镸P4現(xiàn)在基本上只要是一個(gè)設(shè)MP4FLV、TS、MP4都是通用的，H5上直接可以放。最后一個(gè)，推送。推送主要是協(xié)議上的問題，特別是在的時(shí)候，動(dòng)態(tài)QOS調(diào)整問題。這里RTMP、HLS、HTTP、RTP你都要自己做一個(gè)自反饋，根據(jù)發(fā)送端現(xiàn)在發(fā)送的流暢，流暢的前提下更加清晰，只要是QOS做。，下面講一下端端比較簡單。一個(gè)編里面就包含一個(gè)器，照著做就行，，第二點(diǎn)，接收數(shù)據(jù)之后，但是這里有一個(gè)問題，針對(duì)來說還好，因?yàn)榛旧衔揖幍奈医獾幕蛘哒f我編的只是通用格式還好說但如果你做成通用器或者離線，并不是說所有百分之百器都支持編特性比如特別偏門的特性它也編進(jìn)去了，結(jié)果這個(gè)問題，性能允許的情況下你可以盡量用軟件，軟件器兼容性會(huì)做的好一點(diǎn)，不會(huì)比硬件那么差。這個(gè)過程一般情況下我們器都不會(huì)做，我們項(xiàng)目主要用到兩個(gè)東西，顏效果，把它提亮之類的，但是沒有必要。音量增強(qiáng)，比如那個(gè)離麥克風(fēng)很遠(yuǎn)，我們可以把它增強(qiáng)到默認(rèn)的方式，因?yàn)橐纛l處理耗CPU不是很的。最后一個(gè)是顯示，特別是針對(duì)聲音來說還好，只要發(fā)268就可以了，基本上也沒什么問題。主要有一些處理，最主要的是拉伸和裁剪，針對(duì)全屏，有時(shí)候全屏很郁悶，因?yàn)閷捀弑群推聊粚捀弑炔灰欢ㄊ且恢碌模热缥沂?：3，你是16：9的屏幕，或者Android很多是16：10的，有兩種結(jié)果，一種是給下左右填很大的黑邊，另外是拉伸，拉了之后你會(huì)感覺你的人都變形了，打打就沒了，搞個(gè)走馬燈，不停的在頁面上滾動(dòng)，打碼肯定打不到的。另外，一般器用不到，對(duì)于行業(yè)器用到，比如我們有一個(gè)項(xiàng)目，他要畫面動(dòng)態(tài)放過程中， 一個(gè)客戶端的APP，或者APP下面的SDK，還有的SDK，如果你要把產(chǎn)品做好了全是跨下面的是應(yīng)用管理服務(wù)器如果你要做成一個(gè)產(chǎn)品你肯定希望我能控制用戶他登陸或者，另外還有一種要上來，我可以給他動(dòng)態(tài)分配一組地址，我直接去管理服務(wù)器要一個(gè)地址也可以各種服務(wù)器管理策略云管理服務(wù)器主要是提供相應(yīng)的服務(wù)端窗口，服務(wù)器還有Web端頁面，你自己登陸，相當(dāng)于針對(duì)企業(yè)的管理，你登陸進(jìn)去看到自己有，還有大數(shù)據(jù)，數(shù)據(jù)分析，這些東西我們對(duì)接的時(shí)候都有一個(gè)云計(jì)算平臺(tái)，所以還有己寫個(gè)APP，SDK提供的，你的APP寫成什么樣就是什么樣，另外，如果的應(yīng)用做的話所有的東西都要自己搭一遍，當(dāng)然，這里有個(gè)CDN，你可以接第CDN廠商，這個(gè)，SDK，我們?cè)谖募蟼鞯臅r(shí)候，特別是云端網(wǎng)絡(luò)，可以提升30%-50%，有些，比如做小咖秀的，拍一段再上傳，但你如果沒做優(yōu)化，拍5分鐘，可能上傳的時(shí)候花5分鐘，你覺得太郁悶了，如果花5秒鐘10秒鐘上傳用戶體驗(yàn)會(huì)好很多，所以有個(gè)上傳加速。我們這邊直接傳到網(wǎng)易云上，，，下來是轉(zhuǎn)碼處理因?yàn)樯婕暗蕉嗥练职l(fā)涉及不同客戶網(wǎng)絡(luò)帶寬不一樣設(shè)備不一樣，你可能傳的，各種分辨率，各種碼率，只要用戶認(rèn)為你的帶寬吃的消的話可以選擇任何一個(gè)清晰度也會(huì)越好轉(zhuǎn)碼之后的是一樣的然后是這里少了一個(gè)RTMP拉流，RTMPHLSHTTP。點(diǎn)播的時(shí)候要等文件下完才能進(jìn)行拖動(dòng)，要把它前移，前移的工具有開源的，也有自己寫的。最常用的是（英可以任意拖動(dòng)（英文。關(guān)于應(yīng)用管理服務(wù)器和是一樣的，對(duì)于我們自己開發(fā)來說是同一異步系統(tǒng)堆一堆再調(diào)就好了，同步不能堆錄務(wù)器如果是自己寫的錄制就是，，勢來選就是264，音頻AAC就可以了。涉及到編器優(yōu)化，264有個(gè)編可以選擇，一H264，一個(gè)是（英文，H264比較全一點(diǎn)，它最早做出來是針對(duì)離線編碼，編碼質(zhì)量各方面一點(diǎn)（英文）是開源的，如果你的產(chǎn)品需要音通話的，比如我做互動(dòng)的，264個(gè)可以寫在具體編碼控制里面你選好一個(gè)編如果你是開源基本上大家都不會(huì)改到這。最后是緩沖策略的問題，緩沖策略也是根據(jù)場景來的大家都希望低延時(shí)，如果是。，，現(xiàn)在好了一點(diǎn)10分鐘的位置我可能加載到12分鐘，不會(huì)再往前加載，因?yàn)闉槟闶×魈鴰梢苑旨?jí)跳，如果網(wǎng)絡(luò)卡動(dòng)的話先把T3扔掉，對(duì)T2不影響，如果把T2扔掉它對(duì)T3影響，但問題是T3扔掉了，你不可能把T0扔掉，這個(gè)箭頭指的是參考依賴關(guān)系，如果大家不太確定的話可以下面再討論。另外做的時(shí)候有個(gè)鏈路優(yōu)化，我們正常用的是DNS調(diào)度，但有些用戶是錯(cuò)的，可以根據(jù)用戶出口IP調(diào)度，在SDK層，或者是，，（英文）層，把IP拿到，我們現(xiàn)在采取的策略是這樣的，采用中心調(diào)度策略，我要，我先發(fā)一個(gè)消息到流服務(wù)器，他會(huì)返回一組IP地址，中間可以加個(gè)測速環(huán)節(jié)，比的SDK里面，只要相關(guān)實(shí)時(shí)的，推流的信息，幀率碼率分辨率各種運(yùn)營商等等統(tǒng)計(jì)上10分鐘還沒爬回去，總體是大家不停的測試統(tǒng)計(jì)，選擇最優(yōu)的的是硬件編碼，這個(gè)沒問題，但效果不好。Android目前來說沒有很好的美白效果。（5分鐘，45分鐘開始?！禡VVM與FRP編程實(shí)戰(zhàn)》，個(gè)業(yè)務(wù)比較復(fù)雜，業(yè)務(wù)場景很復(fù)雜的時(shí)候，怎么從代碼結(jié)構(gòu)上更好的去應(yīng)對(duì)他們的是講一些關(guān)于編程技巧和架構(gòu)設(shè)計(jì)的東西，接下來有請(qǐng)和給我們帶來美團(tuán)在MVVMFRP編程實(shí)戰(zhàn)。，是忙著吃飯去了，而不是被我嚇跑了。下面由我和給大家介紹一下我們?cè)贛VVM與FRP在美團(tuán)的一些實(shí)踐。首先做一個(gè)個(gè)人簡介。我叫，2009年不亞于航空航天大學(xué)，隨后在IBMCDL工作五年。2014年加感希望志同道合的朋友多跟我交流這里面介紹的一個(gè)背景是在我加入到美團(tuán)以后，中的垂直業(yè)務(wù)，比如說酒店和旅游。這樣一種架構(gòu)和模式的轉(zhuǎn)變?yōu)槲覀儙砹藱C(jī)遇和。一些東西怎么辦最快？拷過來，直接帶來的問題是APP的包大小顯著增大，現(xiàn)在美團(tuán)APP100IOSMVC模式，MVCviewcontroller是緊緊綁在一起MVVM這種模式。下面這幅圖介紹了典型的MVVM模式。這里提供松耦合的方式，可以view和viewmodelviewmodel實(shí)現(xiàn)方法，這也是標(biāo)準(zhǔn)的MVVMviewmodelviewmodel部分，view相關(guān)的屬性，所有的業(yè)務(wù)邏輯寫在子類中，顯然，不同的子類可以實(shí)現(xiàn)viewmodel的過程。在這種模式viewmodelview，從而實(shí)現(xiàn)代碼復(fù)用。同時(shí)我UI相關(guān)的部分，下面的部分是業(yè)務(wù)邏輯相關(guān)的部分，分工的指導(dǎo)原則也就出來了。我UI，對(duì)這塊的單元測試是非常容易進(jìn)行的。表頁中我們關(guān)注其中一個(gè)（英文UI元素，對(duì)應(yīng)的viewmodelUI元素所viewmodel取出數(shù)據(jù)，包含相關(guān)的一系列字段，這些字段到對(duì)應(yīng)的屬性中，和view執(zhí)行綁定，我們就實(shí)現(xiàn)了view顯示過程。如果用（英文）實(shí)現(xiàn)酒店業(yè)務(wù)，我只要把酒店數(shù)據(jù)對(duì)應(yīng)取回來，到viewmodel中就可以實(shí)現(xiàn)。這里我故意選了一個(gè)不好的信息，信息，可以復(fù)用的view一定不能帶著業(yè)務(wù)的概念做事情，和view相關(guān)的viewmodel業(yè)務(wù)里有信息，這是和業(yè)務(wù)相關(guān)的，view是可以復(fù)用的，不同業(yè)務(wù)線實(shí)現(xiàn)自己的viewmodel，實(shí)現(xiàn)業(yè)務(wù)線之間的復(fù)用。同時(shí)業(yè)務(wù)線可以替換，viewmodel可以繼vewmI允許不同的vewml對(duì)它發(fā)消息和閱消息同的viewml之間用互相到，只需要對(duì)息總線就可達(dá)到發(fā)消息和閱息的目的這的話可真正實(shí)總線和viewml定顏值要求高一些，投圖頁現(xiàn)有的不可用，進(jìn)行重選替換view，后面的票型模塊和團(tuán)購的，我們開發(fā)業(yè)務(wù)的時(shí)候拆分成若干個(gè)組件，看現(xiàn)有組件是否可用，如果組件UI可用，我viewmodel是否現(xiàn)有可用，不可用就重寫，如果可用的，它的數(shù)據(jù)，它和總線view、viewmodel用統(tǒng)一方法做事情，進(jìn)一步把頁面里面所依賴的組件寫到配置文件里，再進(jìn)一步通過下發(fā)配置文件，我們完全可以動(dòng)態(tài)去產(chǎn)生一個(gè)原來并不存在的頁面，它里面使用的文件我們可以做的一些，比如像517大促日子的壓力比較大，我們完全可以通過可以解決這個(gè)時(shí)期服務(wù)器壓力問題，可以減輕服務(wù)器壓力。另一方面，我們想去做一些AB，總結(jié)一下，首先是拆，通過拆分，我們有兩種不同的維度進(jìn)行拆分，一種是以MVVM現(xiàn)開發(fā)效率的提升。OnemoreThing，在引入重要的之前都會(huì)說這樣一句話，前面介紹了關(guān)MVVM中它有至關(guān)重要的作用，我們?nèi)绾文軌騼?yōu)雅的實(shí)現(xiàn)綁定，我這里就可以告訴你，F(xiàn)RP是可以幫助到你的，下面就有請(qǐng)同學(xué)為我們介紹FRP在MVVM開發(fā)過程：首先感謝同學(xué)給我們帶來，給我們介紹了很多宏觀上中的策略和架構(gòu)，接下來我會(huì)圍繞MVVM首先，很有幸來到QCon大會(huì)與大家進(jìn)行，簡單自我介紹一下。我叫，來自語言的學(xué)習(xí)和研究加深理解。已經(jīng)五點(diǎn)多了，大家仍然情緒高漲在這聽，我很開心。FRP的基本概念和簡介，個(gè)圖剛剛同學(xué)給我們介紹過這里邊體現(xiàn)了簡單綁定的過程右邊有一個(gè)viewmodel，Ticketviewmodel，列表視圖里有很多票據(jù)，涉及綁定難題，集合綁定如何處理，既要考慮到集合綁定的增與刪，也要考慮到集合綁定的改和藏。第二個(gè)圖，Ticketviewmodel里Ticketviewmodelcell會(huì)產(chǎn)生關(guān)系。除了單向綁定還有雙向綁定，viewmodelview一定的指示，view修改，viewmodel要實(shí)時(shí)偵測到修改，每當(dāng)更換我們會(huì)打開一個(gè)聯(lián)系人列表，從聯(lián)系人列表中選擇某一個(gè)熟知聯(lián)系人，我們選擇列表的時(shí)候會(huì)根本viewmodel，同時(shí)作用于我們進(jìn)行分層，這種錯(cuò)誤通常是由于網(wǎng)絡(luò)層、viewmodelview的，美團(tuán)工程師想到了用FRP與ReactiveCocoa來解決。什么是FRP？以函數(shù)作為一類CC隨時(shí)變化，實(shí)現(xiàn)的想法就是響應(yīng)式的編程。Excel們；做了很好的實(shí)踐，B1A1+5，