Web及移动开发技术
PWA是最近一个热门话题,很多开发同学都在尝试落地,其中也有些还在犹豫。这篇文章主要阐述对几个问题的看法,供大家参考。
前言 Web业务的性能优化是一个系统工程,既有深度,又有广度。以下所简称性能均特指Web业务性能。
从概念上一个使用硬件加速(AC)时,页面显示的结构是Viewport -> Layer(s) -> Tile(s),所谓的纹理就是Tile上显示的内容。
原文链接 下面的文字在翻译时做了些调整和补充,并不完全忠实于原文。有很多我自己也没有深入学习的点,翻译也不能保证准确,所以有时间还是看原文。
在一个软件开发组织里,若干职能单位负责各个业务模块,然后就是大小各种专项。专项可以横向拉通各个单位,但专项一多,或者有点泛滥,各个业务单位的职责就会有所淡化,目标也有模糊的地方。
本文为Safari阅读模式分析过程记录,没有做很好的整理。最终的输出见另一篇iOS Safari阅读模式研究。 1. Break on evaluate b JSC::evaluate(JSC::ExecState*, JSC::ScopeCh...
这是一篇在2013年准备的资料,现在分享出来,供有需要的同学参考。 要点 (1) 阅读模式的检测 在frame加载完成后,触发一个timer来检测是否可以使用阅读模式。
网络性能评价的实现 网络的优劣会影响网络交互的延迟时间、稳定性和速度,从用户体验上集中表现为打开页面的速度缓慢。
页面性能的基础因素 最近读这本小书Designing for Performance,突然想到之前一篇网络性能评价只写了一半,在这里也里也算一个做个补充。
如下面的代码中一个函数接受一个std::string常量引用,在其函数内部需要使用std::string的一些函数操作字串。 void foo(const std::string& param) { ...... } 参数使用的是常量引用,如果传入一个std::string就不需要额外的拷贝。
一个static类,指全部成员都是static方法构成的,而没有任何成员变量, 也称为Utility class 或者Utility Pattern [参考: Utility Pattern].它可以在程序中直接使用该类的方法,而不用实例化.static class相对单例有更好的性能,原因是它的方法不需要实例方法的动态绑定 (static方法本身不能被复写)。
大家都知道遵循设计原则是开发高质量软件的重要基础,但实际运用时并不容易。Booch在中提出了四个基础原则: 抽象 核心思想是不变性的概念。去除不关心的属性,而强化重要的属性,帮助人们思考要做什么。
PostTask参数决策树 如何传递绑定的对象 官方的解释总是最权威,有疑问看这里或者直接看代码中的说明: bind_helpers.h. 传值方式 描述 this 或 对象指针 如果对象本身是一个RefCountedThread...
核心概念 设计上遵循以下原则: 1 不要在UI线程做任何阻塞式的I/O操作,以及其它耗时的操作,通过消息传递把各种操作传给相应用途的线程去做。 2 不鼓励线程加锁机制和线程安全对象。
类别 类 说明 示例 线程机制 Thread (参考:线程模型及应用指南) MessagePump MessageQueue SequencedWorkerPool 它是一个线程池,用于执行需要串行执行的任务请求,这些请求依据不同的Token分组,只在相同组内保证执行顺序。
实现说明 在Chromium跨进程架构下,也会有Browser/Renderer两个进程对相同文件进行操作的需求。
目的 达到延迟拷贝(lazy copy)的优化目的。和延迟初始化(lazy initialization)相似, 选择在恰当的时机更加有效。
内部类 (Inner Class) 目的 不用通过多重继承就可以实现多套接口,同时可以自然地向上转换(Up-casting)。
类是如何定义出来的 Object Oriented是多种软件设计方法中的一种,其核心目标是为了降低系统的复杂性,以及代码复用。
律师与委托人 (Attorney-Client) 目的 控制访问类实现细节的粒度。 动机 C++中的friend会开始类内部的所有细节,也因此破坏了封装性。
Google C++ Style Guide并不是一个百科全书,也不是一个C++使用指南,但它描述适用于Google及其开源项目的编码指南,并不追求全面和绝对正确,也有许多人置疑它的一些规则。
关于OOD中的里氏替换原则,大家耳熟能祥了,不再展开,可以参考设计模式的六大设计原则之里氏替换原则。
为什么浏览器采用多进程模型 这个问题的答案似乎是非常清楚的,可以概括为:为了安全、稳定、性能,只是要牺牲点内存作为代价。
有一种单一写线程,多个读线程并发的场景,比如测量数据的读取与更新,消费者会比较多,生产者只有一个。
观察者模式的应用,主要的行为就是注册和移除观察者(observer),以及通知所有已注册的Observers。
右值引用是一个C++11特性,标记为T&&。GSG中定义:只为移动建构函数(Move constructor)和移动赋值操作(Move assignment)使用右值引用。
Google C++ Coding Style定义 输入参数以值或者const引用形式传入,输出参数使用指针。
书中第六章 隔离。 主要在撰述什么需要定义在头文件?什么应当移到编译单元中? 核心仍然是先区分接口定义与实现细节。
智能指针使用上的问题 智能指针的使用太普遍了,它让程序员摆脱了内存管理的恶梦,但实际上智能指针本身也可能引入另一个恶梦。
经验告诉我们,某些编码实践虽然在C++中完全合法,但是绝对不能应用于大型项目环境中。 大型项目环境下必须有适当的约束,否则很容易变得难以控制并很难维护(摘自)。
现在的软件开发是在遍地敏捷,人人讲唯快不破的时代,哪有人有时间思考代码质量,设计的质量? 哪个又不是从一堆代码中杀出血路来实现另一个功能?一个产品都存活不了几年,何必考虑什么可维护性? 我们追求进度的时候,总是要牺牲些东西,或是破坏了一些东西等着后面补。
类的膨胀(Bloating)指的是类中成员过多,甚至出现无序增加的情况。过大的类,会使得复杂度急剧增加,维护会变得更为困难。
关于API的设计与实现 API的设计是软件开发中一个独特的领域。最主要的特殊点在于API是供开发者使用的界面,即Application Programmer Interfaces。
什么是软件设计的复杂度 软件技术发展的使命之一就是控制复杂度(Complexity)。从高级语言的产生,到结构化编程,再到面向对象编程、组件化编程等等。
背景 正如电脑主机和显示器之间,主机的配置千变万化,不断升级,显示器可能升级缓慢。如果这时你买的是一体机,硬件升级就要受到限制。这就是一个典型的分离变化的需求场景。
背景 世界上电源插头标准很多, 这里只说国标和英标:中国标准:英国标准:各地插头标准不同带来的另一个问题是各地的标准插座主要针对当地插头设计。 常在世界各地跑的朋友都知道一定要配个转接头, 比如这个:这个转换头名称是World Travel Adapter, 所起的作用就是适配。
单一职责原则(SRP)已经几乎是每一个程序员都知道的设计原则。最早由Robert C. Martin在中正式提出。书中作者在结论中提到: SRP是所有设计原则最简单的,但也是最难运用的。
组件(Component)和模块(Module)又是一对容易混淆的名词,也常常被用来相互替换。两者是否有差异往往取决专业背景、所在领域、以及视角。个人总结,从设计上来看,组件强调复用,模块强调职责(内聚、分离),或者说组件是达到可复用要求的模块。
讨论设计时,专业词汇满天飞,每个人的技术背景、工作经验上的不同都会导致在理解上存在着差异。无论是SEI的定义、OMG UML的定义、还有各路大神的定义,都有从不同视角带来的差异。
软件系统可以是需求驱动的,也可以是架构驱动。对一些快速变化的应用类软件,使用需求驱动是很自然的。但对于需要培养核心技术的,架构驱动会更为有效。 敏捷的执行最容易走样的就是技术管理层面的问题,反而是项目管理的层面被过度强调了。
文档的思路从需求决定设计开始展开Chromium主要设计特点。从来没有复杂的设计,它们都可以转换为简单的描述。期望能从学习中解开Chromium设计要点。
Chromium Android WebView是Chromium专为Android WebView提供一个对Content的封装层。从整体上来看可以理解为一个特殊化的Embedder, 功能可以概括为: 1. 对Content和部分Browser Components封装到Java实现,供AOSP WebView调用实现WebView功能。
关于Chromium多进程分析的文章很多了,这篇尝试以浅显的方式解释Chromium多进程机制,解析IPC内部运作的基本机制。 Chromium如何保证多进程的性能 对于一个多进程应用,其核心要解决的是并发的问题.两个面: 线程 和 IPC. 一个多进程交互程序和城市的交通管理是非常相似,我做个类比: 交通管理的问题 解决办法 对应多进程应用的情况 车多 限购。
添加新功能时,可能需要增加各层的接口,接口如何加?必然需要向Chromium的原则看齐。 首先Chromium的模块设计遵循依赖倒置原则,上层模块依赖于低层模块,低层模块不会依赖上层模块的实现。
Chromium Blink基于WebKit而来,从2008年Google开发自己的浏览就选择参与了WebKit社区。当自己还弱小时最优的方式就是与WebKit保持同步。
Linux里最头疼的就是依赖库,搭建一个开发环境就是一堆的依赖库需要安装。如果有版本冲突,虽然可以用aptitude解决,但顾了这个,另一个工程又编不了。
面向接口编程,或者说是面向抽象,是OOP中有效隔离变化的手段,同时要求开发者必须对问题进行有效抽象。Chrome为了兼容AOSP WebView和Chromium Android WebView, 在实现中做了许多的抽象,充分做到了上层只依赖于接口的原则(依赖倒置),可以有效的兼容不同的WebView实现,隔离其内部的变化。
设计是一个平衡的产物,需要在各个约束条件下(组织目标,业务目标,开发流程,技术能力,学习及维护成本等)不断地进行演进。 我们虽然不提倡做大而全的设计,但会坚持进行基础性设计,以保证我们的设计一直在正确的方向上演进。
最近在思考浏览器未来发展方向,网上也有些软文,还在炒WebApp的冷饭,并没有太大新意。我自己设了一个问题:五年后的浏览器。我大胆在这里总结一下,抛出来请大家指教。
快,是当下的工作主旋律。拿到任务,快刀斩乱麻,达成目标交差。甚至同时处理多个事务,一天到晚忙前忙后。一旦闲下来,便觉缺少了存在感。这未必是什么好事,事情做得比较浅,经验不能有效的积累,最终其实还是快不了,还反而让情绪受工作牵制。