关于嵌入浏览器架构的一些总结和思考
2010-01-19 14:09
746 查看
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
一开始浏览器没有划分主线程和工作线程, 整个浏览器只有一个线程. (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
相关文章推荐
- 从“军事战争”总结了一些服务器架构思考
- 我的2013 - 年终总结 + 浏览器渲染发展的一些思考
- 关于课程设计、毕业设计的一些总结与思考
- 关于海量用户访问的通用技术架构的一些思考
- 关于系统架构的一些总结(1)
- 关于MFC中CDHtmlDialog嵌入flash和调用JS一些技术总结
- 关于海量用户访问的通用技术架构的一些思考
- 关于IT企业组织架构的一些思考
- 关于web自动化测试的一些自己的思考和总结
- 关于STM32与SD卡通信的一些思考与总结
- 关于海量用户访问的通用技术架构的一些思考
- 关于测试执行的一些总结与思考
- 关于STM32与SD卡通信的一些思考与总结
- 关于页面跳转的一些总结 浏览器对象与页面刷新 -- JAVA web
- 关于移动端架构的思考与总结
- Atitit 关于微服务的思考与理解 attilax总结 1.1. 架构的历史 微服务发展历史 Web》soa》msa 1 1.2. 微服务最大特点 独立部署 1 2. 微服务的优点 1 2.1.
- 关于课程设计、毕业设计的一些总结与思考
- 十问 TiDB :关于架构设计的一些思考
- 关于海量用户访问的通用技术架构的一些思考
- 关于业务架构的一些思考