WebView开发日志
(2012-02-18 19:16:47)
转载
2012年2月18日
===============
昨天在sourceforge上创建了一个新的开源项目WebWiew。这是一个专为移动设备开发的Web界面框架。
目前，移动应用程序主要采用本地组件作界面开发，而WebView主张以HTML+JS组件开发移动应用的主界面。
这样的开发方式优点很多：
1）跨平台的统一应用界面成为可能。无需再使用Java或Object-c分别为不同的设备开发不同的界面代码。
2）UI界面甚至可以在线更新，无需重新构建工程与下载应用。
3）HTML远比XML更适合界面UI开发。以Android为例，XML不足以完全配置程序界面，还需辅之以Java代码；HTML则能直接嵌入JS与CSS，天生就适合作界面，而且HTML界面更简便直观（直接在浏览器中）开发与维护。
4）JS组件远比本地组件更容易开发，更容易换肤，更适应分辨率与比例。更有大量开发人员与组件库支持。
5）本地应用程序中无需再编写界面代码，只需提供功能性代码即可。极大的精简了代码量，开发与维护移动应用更快更容易。
缺点是：
1）浏览器内核的JS执行性能稍差；
===============
昨天在sourceforge上创建了一个新的开源项目WebWiew。这是一个专为移动设备开发的Web界面框架。
目前，移动应用程序主要采用本地组件作界面开发，而WebView主张以HTML+JS组件开发移动应用的主界面。
这样的开发方式优点很多：
1）跨平台的统一应用界面成为可能。无需再使用Java或Object-c分别为不同的设备开发不同的界面代码。
2）UI界面甚至可以在线更新，无需重新构建工程与下载应用。
3）HTML远比XML更适合界面UI开发。以Android为例，XML不足以完全配置程序界面，还需辅之以Java代码；HTML则能直接嵌入JS与CSS，天生就适合作界面，而且HTML界面更简便直观（直接在浏览器中）开发与维护。
4）JS组件远比本地组件更容易开发，更容易换肤，更适应分辨率与比例。更有大量开发人员与组件库支持。
5）本地应用程序中无需再编写界面代码，只需提供功能性代码即可。极大的精简了代码量，开发与维护移动应用更快更容易。
缺点是：
1）浏览器内核的JS执行性能稍差；
2）不能与本地代码直接联调。（不过可以让界面单独在浏览器中调试，甚至可以提供一个JS版的设备模拟器）
上述idea，（两周前）我刚进入移动部门就和其他团队成员讨论会上提出：我们应基于HTML来开发移动应用，我相信未来这必将成为移动开发界的主流。从上周三开始正式学习Android开发，到昨天给大家演示了一个Android下的示例程序：JS组件如何在Java端注册，如何调用Java端功能接口；Java代码又如何调用JS组件接口方法。我给大家讲解了示例原型的代码，大家觉得API很简便好用、易扩展：Java端代码仅需要我自写的一个（继承自Android）WebView类即可。演示完程序后，我立即上sourceforge注册了一个新项目。想了想，项目名就叫做“WebView”吧：iPhone\Android都用的浏览器View控件名。
从初学Android到提出（在Android）创建框架不过一周多，是不是有些“疯狂”？
世界在这两周正为“林书豪”疯狂。为什么，移动开发界未来不会打破成见（本地应用一定要用本地组件开发界面），为"WebView"而疯狂呢？为什么不能让Google/Apple未来积极提升浏览器内核(webkit)的性能，而不是花心思在本地UI组件的升级上？
PS：今天下午搜索、下载了大量iPhone、Android的UI界面设计素材（280M）。下周，我会列出详细的开发计划，开始WebView的开发。
在七天长假中，我花了足足三天的时间，阅读了sencha的几乎所有教程文档。边读边赞叹：数年不看Ext文档，但制作得越发出色了。凭借Ext团队在UI对象体系的丰富设计与制作经验，其移动UI框架也是世界级的。不过，在写应用代码的过程，也发现一些小BUG（比如，某些不该出现的空指针BUG以及Msg的参数设置不全等），不过不影响正常使用。
在UI方面，Ext+sencha绝对是JSUI+WebView的赶超目标（毕竟Ext拥有80人的开发团队，jack从05年就开始了）。在JSDK的下一个版本，我将对JSUI重点关照。在我看来，Ext在底层的线程对象以及反射/切面对象设计上，不及JSDK，至于既可以支持游戏开发又能支持组件开发上，那更是不及JS2D+JSGF的组合。
PS：
今天，将放假期间写好的新web应用移植到Android工程下。本以为很轻松，结果发现：在PC的chrome上正常浏览的Web页，在模拟器上用webview访问本地web页却死活都是空白页。于是花了一天的时间，一点点的怀疑，一点点查资料，一点点的排查，直到晚上12点，终于确定这是Ext.Loader.require方法的一个BUG：在android的WebView浏览器上，lazy-load本地JS文件时出现失败，不能成功加载所需类文件，导致Appliation无法顺利执行，所以出现空白页。所幸这个BUG不太严重（隐藏得相当深），可以通过直接添加<script>标签或者另写一个懒加载函数来解决。打算以后抽空整理所有的BUG，向sencha开发团队报告。
这个BUG在stackoverflow.com已有一个老外报出，但没有人给出正确原因（很多人提供的解决办法都是无效的）。这个BUG较少有人遇到，也较少有人深究，大致原因是：1）用sencha写正式应用的项目还不多，玩的比较多；2）绝大多数都是将sencha写的应用部署到internet上，此时用webview加载一个远程URL的sencha应用，不会有任何问题。
在查这个BUG的过程中，我也深刻感觉到，如果在WebView加载页面出现疑难问题，真是无法对JS加断点，无法调试（只能逐行排查）。幸好，chrome浏览器与webview使用同一内核，绝大部分JS问题可在PC浏览器上调试。
上述idea，（两周前）我刚进入移动部门就和其他团队成员讨论会上提出：我们应基于HTML来开发移动应用，我相信未来这必将成为移动开发界的主流。从上周三开始正式学习Android开发，到昨天给大家演示了一个Android下的示例程序：JS组件如何在Java端注册，如何调用Java端功能接口；Java代码又如何调用JS组件接口方法。我给大家讲解了示例原型的代码，大家觉得API很简便好用、易扩展：Java端代码仅需要我自写的一个（继承自Android）WebView类即可。演示完程序后，我立即上sourceforge注册了一个新项目。想了想，项目名就叫做“WebView”吧：iPhone\Android都用的浏览器View控件名。
从初学Android到提出（在Android）创建框架不过一周多，是不是有些“疯狂”？
世界在这两周正为“林书豪”疯狂。为什么，移动开发界未来不会打破成见（本地应用一定要用本地组件开发界面），为"WebView"而疯狂呢？为什么不能让Google/Apple未来积极提升浏览器内核(webkit)的性能，而不是花心思在本地UI组件的升级上？
PS：今天下午搜索、下载了大量iPhone、Android的UI界面设计素材（280M）。下周，我会列出详细的开发计划，开始WebView的开发。
2012年2月19日
===============
上午起来，打算看一下昨天下载的PSD。发现以前安装的Photoshop CS3绿色版无法正确打开一些PSD文件，于是下载了CS4，就可以正常打开这些文件了（不过比CS3占更大内存，PS操作明显变慢）。
===============
上午起来，打算看一下昨天下载的PSD。发现以前安装的Photoshop CS3绿色版无法正确打开一些PSD文件，于是下载了CS4，就可以正常打开这些文件了（不过比CS3占更大内存，PS操作明显变慢）。
顺便定义WebView的组件术语：
Component: 组件
Widget: UI型组件，简称部件。
Control：功能型组件，简称控件。
2012年2月29日
===============
昨天下午，和团队成员去淘宝参加了一场沙龙：淘宝两年来的开发历程分享。他们的Android框架没有给我留下什么印象，架构能力和经验更没有印象，Android应用的前端能力更是可以忽略不计。除了，他们拥有庞大的开发团队和数百台测试机外。
我只关心一个问题：为什么淘宝android应用的WebUI比起NativeUI在整个应用页面的份额正在逐步下降。目前的3.0版，据他们说只有10%的页面是纯web的（1.0时这个数字是60-70%）。详细询问了他们的理由：1）web页面中操作多后内存占用多；2）和NativeUI的交互不太好；3）下载web资源占用很大网络带宽，且页面装载慢。
后两个问题，在我看来都不是问题。第一个问题，我想可以这么解决：通过WebView可以让JS调用NativeAPI释放缓存或内存，或者让WebView监听页面加载事件作自动化清理工作。
今天，开始用PS切割Android界面，搭建了一个HTML版Android手机“模拟器”的雏形。
2012年4月10日
===============
节前，注意到sencha touch在3月份刚发布2.0版本。试用了一下，UI效果相当不错，不愧是EXT团队开发。马上向团队推荐——打算购买其license，直接用于当前正在开发中的Android应用。
这个应用已经用Java代码完成一半以上的界面与功能，但越到后期越感到界面与样式的繁重修改、重构工作。所以，看到sencha写出的Example代码是那样的简洁清晰，用不着我说服谁，凭着工程师的高度理性，都明白我常说的那个“道理”——用Java和XML写界面那就是一场灾难，再加上Android的天生弱智级的文件管理与复杂低效的API设计，那就是一场浩劫。
Component: 组件
Widget: UI型组件，简称部件。
Control：功能型组件，简称控件。
2012年2月29日
===============
昨天下午，和团队成员去淘宝参加了一场沙龙：淘宝两年来的开发历程分享。他们的Android框架没有给我留下什么印象，架构能力和经验更没有印象，Android应用的前端能力更是可以忽略不计。除了，他们拥有庞大的开发团队和数百台测试机外。
我只关心一个问题：为什么淘宝android应用的WebUI比起NativeUI在整个应用页面的份额正在逐步下降。目前的3.0版，据他们说只有10%的页面是纯web的（1.0时这个数字是60-70%）。详细询问了他们的理由：1）web页面中操作多后内存占用多；2）和NativeUI的交互不太好；3）下载web资源占用很大网络带宽，且页面装载慢。
后两个问题，在我看来都不是问题。第一个问题，我想可以这么解决：通过WebView可以让JS调用NativeAPI释放缓存或内存，或者让WebView监听页面加载事件作自动化清理工作。
今天，开始用PS切割Android界面，搭建了一个HTML版Android手机“模拟器”的雏形。
2012年4月10日
===============
节前，注意到sencha touch在3月份刚发布2.0版本。试用了一下，UI效果相当不错，不愧是EXT团队开发。马上向团队推荐——打算购买其license，直接用于当前正在开发中的Android应用。
这个应用已经用Java代码完成一半以上的界面与功能，但越到后期越感到界面与样式的繁重修改、重构工作。所以，看到sencha写出的Example代码是那样的简洁清晰，用不着我说服谁，凭着工程师的高度理性，都明白我常说的那个“道理”——用Java和XML写界面那就是一场灾难，再加上Android的天生弱智级的文件管理与复杂低效的API设计，那就是一场浩劫。
在七天长假中，我花了足足三天的时间，阅读了sencha的几乎所有教程文档。边读边赞叹：数年不看Ext文档，但制作得越发出色了。凭借Ext团队在UI对象体系的丰富设计与制作经验，其移动UI框架也是世界级的。不过，在写应用代码的过程，也发现一些小BUG（比如，某些不该出现的空指针BUG以及Msg的参数设置不全等），不过不影响正常使用。
在UI方面，Ext+sencha绝对是JSUI+WebView的赶超目标（毕竟Ext拥有80人的开发团队，jack从05年就开始了）。在JSDK的下一个版本，我将对JSUI重点关照。在我看来，Ext在底层的线程对象以及反射/切面对象设计上，不及JSDK，至于既可以支持游戏开发又能支持组件开发上，那更是不及JS2D+JSGF的组合。
PS：
今天，将放假期间写好的新web应用移植到Android工程下。本以为很轻松，结果发现：在PC的chrome上正常浏览的Web页，在模拟器上用webview访问本地web页却死活都是空白页。于是花了一天的时间，一点点的怀疑，一点点查资料，一点点的排查，直到晚上12点，终于确定这是Ext.Loader.require方法的一个BUG：在android的WebView浏览器上，lazy-load本地JS文件时出现失败，不能成功加载所需类文件，导致Appliation无法顺利执行，所以出现空白页。所幸这个BUG不太严重（隐藏得相当深），可以通过直接添加<script>标签或者另写一个懒加载函数来解决。打算以后抽空整理所有的BUG，向sencha开发团队报告。
这个BUG在stackoverflow.com已有一个老外报出，但没有人给出正确原因（很多人提供的解决办法都是无效的）。这个BUG较少有人遇到，也较少有人深究，大致原因是：1）用sencha写正式应用的项目还不多，玩的比较多；2）绝大多数都是将sencha写的应用部署到internet上，此时用webview加载一个远程URL的sencha应用，不会有任何问题。
在查这个BUG的过程中，我也深刻感觉到，如果在WebView加载页面出现疑难问题，真是无法对JS加断点，无法调试（只能逐行排查）。幸好，chrome浏览器与webview使用同一内核，绝大部分JS问题可在PC浏览器上调试。
832
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
