ttt

get packet?

基础组件

av_read_frame

libfaac编码

event_loop/play_control

player

avformat_open_input

data

应用组件

走新的还是走老的逻辑控制：比如一期是让讲座走新的

seek

libx264编码

AVPacket

h264

play

video_thread

start

audio packet?

network

videopacket?

irc

live room1

baseui

login

core

yuv

mp4v2库打包

摄像头

aac

full screen

end

av_find_stream_info

main

log

麦克风

av_register_all

pcm

avcoder_decode_audio4

live room2

stream_open

avcodec_open

拥有独立窗口的进程

avcoder_decode_video2

course center

线上代码逻辑

学生端始终对用户提供的是单个app，不像教师端能提供独立app，我们不在原来直播间里去改动代码，而是维护一套新代码。下面详细说明下：1.新老兼容 2.新老过度 3.在新的结构下面各模块如何工作等三个问题，让整体上写代码更明确些。1. 新老兼容，就是发布的新版即包含未整合前的直播间又包含整合后的直播间。具体代码上的实现就是在学习中心进入直播间那加控制策略，当策略命中时就走到新的，否则走到老的。走到老的代码无需改动直接就能支持，走到新的要解决如下几个问题：a. 窗口怎么控制 b. 数据怎么同步 c. 子进程的生命周期怎么管理。我们走一遍进入直播间的场景：点击进入直播间 -> 启动子进程（直播间） -> 子进程getinfo调用成功 -> 主控进程窗口隐藏 -> 子进程窗口（直播间）展示 这样我们就进入到整合后的直播间了。窗口怎么控制就很好回答了，如果主控进程的窗口和直播间窗口可以共存（待交互设计定），那就不需要隐藏这么麻烦。退出直播间的流程：点击返回 -> 子进程隐藏窗口并发消息给主控进程 -> 主控进程展示 -> 子进程退出这么处理整体上看是没问题的，逻辑也简单，其中麻烦一点的是：数据怎么同步。登录获取到的用户信息、全局设置信息、未进直播间前进行的预缓存信息等。我的建议是，将主进程取到的基础信息存为json字符串在进程间同步（量少且固定）；预缓存等功能做成服务，而不应该与主控进程绑定，主控进程只是触发。其实直播间的主要数据还是从getinfo来，数据可以自给自足，像全局设置和基础信息（uid cookie）等数据需要同步，如果嫌这样麻烦，可以直接使用内存数据库，也是很不错的解决方案。不管使用ipc发消息来同步更新数据，还是内存数据库对数据的操作都需要进行一层抽象，避免业务层改动。至于生命周期就比较简单，做到直播间单例，进时创建，退时销毁就行。2. 新老过度，简单来看就是怎么按量控制学生进新还是进老，这部分的灰度策略不是现在最重要的点，但是需要注意这里的策略都是服务端控制的。3. 各个模块如何工作的，我们把原来揉在一起的代码做了拆分，分为了基础模块和业务模块。live room其实主要还是对所有业务模块的管理，当然每块业务又依赖底层的数个基础模块。业务可以分为带UI和不带UI，带UI的还可分为常驻和非常驻。目前第一步是要将带常驻UI的业务划分清楚，这个带常驻UI就是指直播间的壳，包括：顶部导航区  教学内容区  教师头像区  成就展示区 聊天区 底部工具栏。这步处理好了，下面就是整理一个个非常驻UI（触发式）的业务了，这些最基础的建议启动就加载出来，后面的业务可以触发式加载，这里的加载指实例化并初始化对应业务的控制器。各个具体的模块怎么实现，要做好两点基于a. 接口编程 b.UI层独立。至于为什么要设计成子进程的形式，好处简单说下：a. 崩溃后能捕获重启 b. 独立进程跟原来彻底分开（只耦合于需要同步的基础数据） c. 直播间独立更新（而且能动态） d. 对原来代码改造足够小，不怕相互影响。

avcodec_find_decoder

mp4

read_thread

utils

mainwindow

live room3

update

decode_thread

application

webview

stop