关于嵌入浏览器架构的一些总结和思考

1.  浏览器主线程和工作线程的任务划分

一开始浏览器没有划分主线程和工作线程, 整个浏览器只有一个线程.  (8623资源太少, 所以我们坚持很长一段时间都是一个线程).

后来, 由于CPU太烂, 加载一个页面的时间太长 (大概是2秒左右), 影响了按键的响应速度, 又后来, 执行阻塞型的JS脚本会导致动态GIF停下来,  所以我决定增加一个线程作为工作线程,  这个工作线程主要的任务就是处理一些需要快速响应的任务 (包括按键的处理, 还有一些提示性的UI) . 至此, 在8623平台上面浏览器的线程方面的架构基本确定下来, 分别是:

主线程:    资源加载, HTML解析,CSS解析, JS脚本的执行, 页面的渲染输出

工作线程: 按键接收,防抖 ,  动态GIF, 走马灯等一些动态UI的处理

可见硬件平台对软件架构的影响有多大.

 

经过这样的线程安排之后, 解决了一些问题, 比如 按键的接收不会因为加载页面而被阻塞,  动态UI不会因为加载页面而阻塞.  但是切换到8654上之后, 再回过头来看,也发现了一些问题:

主线程和工作线程都会进行UI的处理, 线程功能不明确, 不利于以后的扩展;

8654的CPU非常强劲, 现在加载一个页面的时间在200毫秒到400毫秒之间, 原来特定增加一个线程来处理按键已经显得不那么重要;

所以后面会对浏览器的架构进行适度的调整, 主线程专心处理UI 的渲染和输出, 而工作线程则处理UI渲染和输出以外的其他工作, 这样才名副其实.

 

2. 我们的浏览器应该具备什么最基本的功能

这个问题思考过很多遍, 现在基本明确下来:

能通过HTML+ CSS 来表现机顶盒的UI; (基本实现)

能通过Js 来描述和控制机顶盒业务; (基本实现)

能通过HTTP(S),FTP等传输方式来同步和更新机顶盒端的数据; (还未能实现通过HTTP直接加载页面)

 

mBrsrCore 作为浏览器的核心, 必须完成上面描述的最基本的功能 ,其他功能都应该将其排除在外, 保持浏览器核心的简洁. 所以这几天我们建立了一个基本库, 将浏览器核心原来的图片解析和加载, 字库的解析和加载, 还有一些工具类的功能(如定时器队列, ) 裁剪处理,  纳入基本库中.

应该将什么功能纳入到浏览器核心, 可以根据以下的原则进行判断:

只能将符合W3C标准的UI表现纳入; (比如不能将自定义的HTML元素或者CSS属性的实现放到mBrsrCore中)

只能将通用的基于TV的事件处理纳入; (比如基于遥控方向键的焦点跳转)

只能将标准的传输方式纳入; (比如不能将P2P下载方式纳入)

 

3. 如何对浏览器核心进行扩展

扩展的目的主要有两个:

增加UI功能,  比如对话框; (UI类)

增加业务处理能力, 比如解析节目清单的XML等; (后台业务类)

 

目前主要通过以下方式来对浏览器进行扩展:

通过自定义JS函数进行扩展;

通过自定义JS对象进行扩展 (不依赖于任何HTML元素)

通过自定义HTML元素 + 相关联的DOM对象进行扩展.

 

在采用上面的方式对浏览器进行扩展时,发现了一些问题:

通过 JS 对UI进行扩展时,  缺乏一些渲染,布局功能函数的支持 (比如文本布局), 导致实现 JS扩展函数,对象困难;

后台业务完全通过js对象实现, 缺乏灵活性;

所以, 应该在浏览器的渲染模块上提供更多布局和渲染接口, 供扩展UI使用.

应该将后台业务的实现跟浏览器分离开来, 不过浏览器应该提供数据的输入和查询接口, 供JS对象使用.

 

4. 我们的浏览器应该走专用的方向, 就像UCWEB, 为了让浏览器可以在手机上应用, 在UI呈现,  浏览器插件和数据传输方面下了很多功夫.  所以接下来应该花更多时间去研究如何将浏览器方式的应用运用在电视上面. 暂时可参考的是YAHOO WIDGET