信创分布式存储如何助力企业实现数字化转型与创新潜能
722
2023-01-26
跨端开发应用案例分享模板（跨端开发方案）
本篇文章给大家谈谈跨端开发应用案例分享模板，以及跨端开发方案对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享跨端开发应用案例分享模板的知识，其中也会对跨端开发方案进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
有过混合应用开发经验的同学，对基于WebView的Hybrid开发模式应该不会陌生。借助于原生端各平台的WebView组件，可以实现Native和JavaScript的双向通信，从而将Web App与Mobile App融合起来，开启混合开发的新模式。
基于WebView的Hybrid开发模式到如今已经非常成熟，不再是一个实验性新技术，而是广泛应用在各大厂商的平台型应用如微信、手Q中。
jsBridge作为连接Native和JavaScript的桥梁，是基于WebView的Hybrid开发模式中的关键点。
在了解其通信原理后，再来看JSBridge究竟是什么。从前端角度来看，可能会把JSBridge理解为业务开发过程中，以全局变量注入到WebView中，帮助调用原生API的JavaScript工具库。这样的理解不够准确，按照我的理解，JSBridge不是一个标准的规范，基于原生系统为WebView组件提供的能力，已经可以建立起WebView JavaScript bridge，即使不再做更高程度的封装，也可以完成从Native到JavaScript的双向通信了。
我们所说的JSBridge，是对底层通道的抽象封装，这一过程包括了原生和JavaScript两侧内容，在原生端需要考虑系统API差异，对上层调用提供统一接口，在JavaScript端需要考虑调用方式，请求管理等内容。JSBridge的设计实现已经是成熟技术了，其设计可以参考 In-depth Profiling of JSBridge 、 Hybrid APP架构设计思路 ，一个安卓端完整JSBridge实现可以参考 JsBridge实现 。
目前，基于WebView的Hybrid开发模式非常成熟，广泛应用于各类平台型App中。实现一个完善的JSBridge是在现有App中集成使用Hybrid开发模式的基础，在完成这一基础设施建设后，大家继续在各个方向深挖，在不同的维度不断优化性能和体验。
多数App的Hybrid部分做到上面部分，已经有了还不错的体验。在我的了解中，空间团队在上面基础上继续优化给出的是当前做的更好的方案。其主要流程如下图所示，详细内容可以参考 QQ空间前端工程师如何做首屏优化
除了在现有App中集成使用这一开发模式，还可以使用这一技术开发独立App。早期的PhoneGap、Cordova、现在的Ionic，是这一领域较为知名的开发框架。
我司前端技术栈曾以Angular为主，一些App也由前端团队基于Angular技术栈选型Ionic。初入团队曾维护过基于Angular 1.x的Ionic App，用于我司投资顾问服务客户的以IM为主、综合一些其他业务，可以算一个比较复杂的应用。
前端技术背景的同学，采用Ionic框架开发App的学习成本不高。开发过程中仍在沿用前端技术，写的仍是Web App,跑在原生WebView容器中。采用Ionic提供的组件库，可以快速搭建项目界面。其扩展原生的机制也比较方便，如有原生能力的需求，并且没有现成实现的，可以自行封装使用，不过这个过程就需要原生开发同学的参与了。在我们的上述App开发中，主要是安卓端消息推送模块由原生开发同学提供了支持，其余对原生能力的需求如拍照、相册访问等常见需求，都有现成方案。
然而，采用Ionic完成上述应用，也有明显不足的地方。首先是聊天列表方面，我们知道，如微信和QQ聊天窗口，这是一个异构的无限滚动长列表，在进入聊天界面时，一般只加载最近的一屏聊天数据，然后通过滚动加载历史消息。在原生端完成这一需求有各种常见手段，而仅靠Web端技术，在各种折腾后，效果都不尽如人意。其次是动画，这里的动画包括了换页动画和其他动画，流畅程度一般。最后是前端开发通病，要处理浏览器兼容性问题，crosswalk只是一个理论解决方案，其体积限制了几乎不会被采用。
Ionic不断迭代，新的版本中依赖新的Angular。新的Angular与Angular 1.x开发体验已经完全不同，如果你还不了解，可以阅读我们团队书籍 揭秘Angular 2 。新的Ionic的开发体验，相比以往也有提升，在其工具链中，提供了拖拽式项目生成工具
同时，Ionic pro提供的开发者工具，为应用整个生命周期提供了完善的支持平台，包括了以下功能，不过，使用需要付费。
站在当下来看，对于前端技术背景开发者来说，如果已有Angular基础，不希望引入过高学习成本，需要快速开发一个复杂程度不算太高、或者对应用性能不是特别敏感的跨终端App，选择Ionic依然是一个可行方案。
然而，既然你已经身在前端领域这样一个技术更迭日新月异的圈子里，还是应该使劲的折腾，关注跨端开发这个主题新的技术热点，接下来我也会继续谈谈在NativeScript、React Native、Flutter的一些体验，可以保持关注。
1、Hilo 支持多种模块范式的包装版本，包括AMD，CMD，COMMONJS，Standalone多种方式接入。另外，你可以根据需要新增和扩展模块和类型；
2、极精简的模块设计，完全面向对象；
3、多种渲染方式, 提供DOM，Canvas，Flash，WebGL等多种渲染方案（目前已经申请专利）；
4、全端浏览器的支持和高性能方案，独有的Flash渲染方案，即使在低版本IE浏览器下也可以跑起来“酷炫” 游戏 ； DOM渲染方案能显著解决低性能手机浏览器遇到的性能问题；
5、物理引擎支持——Chipmunk，支持自扩展物理实现；骨骼动画支持——DragonBones，同时内建骨骼动画系统——Tahiti（目前内部使用）；
6、案例丰富，框架成熟，已经经历多届阿里巴巴双十一，年中大促互动营销活动考验；
舞台Stage是一个各种图形、精灵动画等的总载体。所以可见的对象都要添加到舞台或其子容器后，才会被渲染出来。
Stage构造函数接收一个参数properties，此参数包含创建stage的各种属性。
舞台Stage上的物体的运动等变化，都是通过一个定时器Ticker不断地调用Stage.tick()方法来实现刷新的。
舞台上的一切对象都是可视对象，可以是图片、精灵、文字、图形，甚至DOM元素等等。Hilo提供了一些基本的可视类供您使用，比如添加一个图片到舞台上：
要想舞台上的图形、精灵动画等对象能响应用户的点击、触碰等交互事件，就必需先为舞台开启DOM事件响应，然后就可以使用View.on()来响应事件。
接下来，您就可以开始利用hilo提供的各种可视类来创建各种图形、精灵动画，尽情发挥您的创造力，开始您的HTML5 游戏 之旅吧！
Hilo对于开发H5 游戏 的开发者和对Web端渲染感兴趣的小伙伴来说值得一看，Hilo有诸多案例可供参考，如果你想继续深入了解它，可移步官方文档或者Github一探究竟！
关于敏捷，我的观点是，敏捷的含义很广泛，但可以被分为以下四个范畴，这是四个独立话题，有人说是不同级别的敏捷，我旗帜鲜明的表示不认可，我认为基本上没有关联，并不是包含的关系。我们遇到的敏捷问题，都可以归结到其中一个范围，思索和寻找答案也请在这个范围内找，否则疑惑会越来越多。
首先是组织的敏捷，现在是VUCA时代，面对互联网的冲击，各种传统行业的转折点在不经意间就会来临，应对不好就可能死掉。老板们已经认识到这一点，他们想建立更好的体制来应对。有一本书是专门讲这个的，《赋能TeamofTeams》跟IT并没有必然联系，投入大成本开展组织敏捷实践的，往往是传统跨国企业，比如麦当劳。
然后是适合敏捷的项目任务，在项目管理范畴里面，没有最好只有最合适，看任务本身适合什么。中国的互联网行业的特点，诞生了大量适合敏捷模型的项目，特别是从0到1的阶段，但无论你是否知道敏捷，你都会不由自主这么去做，因为他是符合人的正常认知的。但仍有大量的项目任务，并不适合敏捷模型。
再说个人和团队利用敏捷来提高自己。敏捷是一种心态，一种做事哲理。你可以利用敏捷来提高自己，跟你做什么并没有关系。Scrum的三个支柱什么？透明，检视，调整。你有没有仔细思索过这三个词？敏捷使人进步，你要记得敏捷对你的好，你要感恩提供机会给你敏捷实践的人。
最后说跨团队协同。在平台型多团队研发体系中，有各种问题，立场不同，目标理解不一致，沟通GAP，责任不清晰，问题很多。不管是DEVOPS还是SAFe框架，还是什么，都是为了解决问题的。怎么样形成良性循环，我的评估标准仍然是，是否有助于透明，增加共识和减少沟通成本。是否有利于发现问题？是否有利于改善和调整。
那么我们是怎么进行跨团队协同的呢？
首先说下我们所面临的难点和困境。我们做的是To B业务，研发者天然不是用户，业务不是生活场景，开发人员不明白业务场景和业务需求。掏钱使用平台的都是中小微物流企业的企业主，都是李云龙一样的草莽英雄，他们只想着性价比，能不能通过平台挣钱，他们虽然会为平台付费，但从来不是平台的使用者。使用者都是他的员工，因为老板的命令而不得不使用，因此从最终使用者那里永远得不到正面反馈。
我们的需求来自独立的业务部门，他们仅熟悉业务语境，而研发团队只懂系统语境，存在巨大的沟通代沟。产品经理则处在一个夹心的位置，稍有不慎，就变成了两端的抱怨对象，被吐槽成“无附加价值的传话筒”，两头不讨好，他们的自我价值感很低。
而我们的平台系统，处在业务核心建设的中后期，一方面要继续建设，前期积攒的问题又在爆发，架构不合理，系统耦合性高，随便增加点功能，所有系统模块都要跟着动，所有研发团队都要参与，因此项目规模很难缩小。
系统耦合性大，你中有我我中有你，责任不清，跨团队协同非常麻烦，同时架构的优化改造又很难找到抓手。找到原因，设计解决方案那么我们要如何去解决这些纠缠不清的问题呢？
基于对我们实际情况的思索，我们找到了问题的根因。
从两个维度来分析，从业务维度，业务项目关注的的业务的价值，关注的是承载价值的业务流程，也就是由价值块组成的业务闭环。这个价值块是业务语境，跟系统实际无关。他们不关注系统是怎么实现的，只关注上线时间。
再从研发团队维度，他们不对价值块负责，只对系统模块负责，期望按照自己的敏捷节奏做事。
在价值传递的过程中，由于价值块和系统模块之间的不统一，产品经理在把价值块落地到平台系统上的时候，会遇到很多难题。架构设计上扯皮，每个研发团队的理解，会产生很多不认同。在落地的时候就会非常艰难。
找到了问题的根源，也就有了解决方案，那就是从最开始，就要把价值块和团队绑定起来，明确好责任方。根据系统和模块的现实情况，团队是改造不了的，除非废掉平台，推倒重来。那么能改的，就是对于价值块的定义。
那我们是怎么设计的呢？
我们在 Jira 上定义了”项目 — Epic — Story — 子任务”的四层级结构。
首先明确所有研发团队的性质。承担业务功能研发的，承担底层及相对独立模块的，比如成员体系，支付体系，还有前端团队。为项目分类，大业务项目立项通过后由管理员建立，技术优化类项目有研发团队自己建立。那么Epic，就明确定义为之前所说的价值块。明确由某个研发团队牵头负责，属于某个唯一项目，在业务流程图和计划中体现，这个是最关键的点，下一页我会重点说明。
然后Story属于某个唯一系统，同时属于某个唯一Epic，不跨团队，由各Scrum团队自行管理。SubTASK又属于一个唯一的Story，由一个人负责。
既然是价值块，不可能仅涉及一个团队，但是又由一个团队负责。怎么办呢，需要其他团队完成的部分，以Story的形式，指给其他团队。但是由Epic责任方承担跨团队沟通责任，作为依赖项进行明确的管理。这样，就界定了责任。从一开始避免扯皮。
这其中，最关键的点，就是拆分Epic！
对于业务团队来说，Epic是沟通业务场景的最小颗粒元素，组成业务流程图。Epic及业务流程图是是沟通业务方案的终点，但同时是技术团队沟通系统方案的起点。Epic的内容从一开始就要得到业务团队和研发团队的认同，务必要实现语境的统一，这样就形成了所有人理解一致的基础，避免了在价值传递过程中的转译。
在拆分Epic的时候，要考虑系统的现实情况，确保要以某个团队为主，让这个团队承担责任。而这个Epic中，需要其他团队完成的，由该团队的PO与其他团队PO协调一致，指给其他团队，刚才说了，有负责Epic的团队，承担跨团队沟通的责任。
这实际上，对各团队都提出了高的要求，不提高要求怎么能进步呢？同时要求各团队要向对方走进一步，不靠近怎么实现透明呢？
对于产品团队来说，进行业务模块拆分时，要充分考虑系统现状，这对产品经理的业务场景抽象能力和工作习惯提出了一些更高要求。
对于业务团队，Epic不仅仅是业务语言，不仅仅是价值块，还包含了系统因素，他需要多了解一些业务和系统的结合。
对于研发团队来讲，从一开始，就知道了可能要负责某个Epic，他必须提前进入项目，了解业务，参与Epic的梳理。
这种高要求，同时会促使团队的进步，这种大家共同促成的语境统一，降低了沟通难度，提高了合作水平。
在具体工作中，我们除了各个团队的看板以外，还设立了项目看板，每周更新一次。由三个部分组成，业务流程图，项目迭代看板，各团队依赖项看板。
首先我们把业务流程图画在墙上，当然不是所有模块都需要研发，很多是利用现有模块的，大家可以看到，上面的的每一张贴纸，都是一个 Epic，代表了任务。我们可以完成一个 Epic，就把这张纸撕掉扔掉，流程图仍然在上面。这是业务流程图。
再看项目迭代看板，每一行是一个团队，每一张贴纸，代表了他负责的 Epic。这样就是这个项目的整体进度。思路清晰的不得了。
再看依赖项看板，这是其中一个团队的。把这个项目迭代中的所有依赖项都写出来了，主要是要对方提供接口。每一行是一个团队的。每一张都是指给别人的 Story。在每周的项目站会上，大家以统一的基准过进度，确认问题。所有的问题，都可以定位到某一个 Epic，很容易确定问题范围。极大的降低了沟通复杂度。看着业务流程图和迭代看板，研发小伙伴很容易知道在做哪一个模块，在业务链条上处在什么位置。
同时各个团队有自己的 SM 和 PO，又明白了在跨团队沟通时的主从地位，在依赖项看板前沟通问题，就不用扯皮了，责任一目了然，进展一目了然。
在实际实践过程中，效果非常好。详细的内容，我们整理在 Confluence 上，包括项目情况，业务流程图，包括依赖项。
还有产品+研发团队的回顾会，大家会讨论Epic的划分是否合理，会讨论发现了哪些可以系统优化的点。这样，我们实际上走在持续改善的道路上。
除了之前介绍到的理解一致外，增加了透明，降低了沟通难度，明确了任务的标准，是 Epic 还是 Story，还明确了责任，跨团队沟通中，谁是责任方，我们还能够从任务分配和 Jira 数据统计中，发现我们系统的问题。
对于业务研发团队来说，如果任务都是业务 Epic，而缺少系统优化的自建 Epic，则说明团队业务研发负荷过重，从而忽视了系统自身的优化，这样容易积累技术债务，积累风险，贻害未来。你们可能在生产 BUG。需要加以平衡干预。
对于基础研发来说，他们的主要工作是系统能力的沉淀，和业务项目的支援，比如一些对外提供接口的 Story 任务。如果他们承担了独立的业务 Epic，或者业务项目的 Story 过多，则说明基础系统需要继续解耦，或者架构不合理，你做了哪里，就说明哪里有问题。
对于小前端团队来说，不应该承担业务逻辑，如果出现了独立的 Epic，或者业务逻辑 Story，那么做了哪里，哪里就有问题。需要将逻辑还给业务编排层及以后，逐步实现真正的前后端分离。
我们说，好的需求是涌现出来的，系统优化的点，也是不断涌现出来的。通过这个流程，我们就能够实现能够落地系统方面的持续改善。适时的改善，有业务价值的改善，不是自嗨的改善。
讲到这里，大家发现我并没有讲到太多的 Jira 和 Confluence 这些工具的使用方法。
对于工具，我的观点是：工具可以做为技术的辅助，但更重要的是使用者的思想认识；我们既要尊重现实情况，又要尊重团队各角色的需求，也要保持一定的专业度和立场，才能达成能够落地的协同，最终形成合力共同迈向目标。无论是 Jira 还是 Confluence 都是很灵活的工具，本身提供了很通用的管理要素，我们可以根据实际的需求把这些要素进行组合，把适合自身的管理和协同思想融入进去，不断实现良性循环，不断提高交付能力。
在开发之前，我们想了解一下 FileMaker 到底可以做成什么样。所以，我们搜集了部分目前这个领域里相对成熟的 FileMaker ERP（本文讨论的 ERP 是 100 人以下规模企业用来管理客户、销售、采购、库存和财务等业务流程的软件） 产品。所以，第一篇我们就来共同研究一下这个领域里最好的产品。
神机妙算
目前来说，是中文领域唯一可直接销售的进销存 FileMaker 套件，也是影响力最大的 FileMaker 套件。界面效果可谓武装到牙齿，功能和技术也都非常扎实。
神机妙算的开发者由于收到工厂色彩管理的影响，为每一个模块都配置了一种主题色。这极大的方便了用户识别模块窗口，也算是软件的一大特色。此外，权限的设计，也是软件的一大亮点。
产品可全功能试用，访问网址：[http://macdiy-]
FMStartingPoint
FMSP 是唯一一款免费的 ERP 软件，也因此是全球分发数量最多的 FileMaker 系统。
FMSP 的界面布局和模块都可谓是国外 FileMaker ERP 类产品的典型。Project、Accounts 和 Invoice 是国外中小企业的最基本要求。同时，由于软件本身也相对复杂，所以可以作为使用 FileMaker 搭建复杂系统的参考。
虽然，免费且开源只是一种营销策略，但是这种做法确实造福了很多 FileMaker 入门用户。FMSP 间接或直接地帮助 FileMaker 开发者完成了手中的项目，以及帮助他们提升了技术。
产品开源，访问网址：[http://fmstartingpoint.com]
Jarvis CRM
Jarvis CRM 是一款拿过 FileMaker 年度设计优秀奖的软件，是比较
现代风格的 FileMaker 系统。Jarvis 比较特色的地方是将甘特图、日历、图表等前端模块融入到系统之中，所以整个系统看起来比较鲜活。只提供产品介绍，访问网址： [https://jarviscrm.com]
Job Pro
老牌的 FileMaker 系统，是比较有想法的 FileMaker 产品。Job Pro的主要亮点是功能上更加关注工作流程的管理，同时也兼具小型 ERP 的功能。
产品可全功能试用，访问网址：[https://jobprocentral.com]
KiBiz
老牌的 FileMaker 系统，拥有 30 年的历史。功能详尽，拥有自己的一套操作流程。
产品可全功能试用，访问网址：[http://kibizsystems.com]
Businessman ERP
Businessman ERP 可以说是 Bug 级的产品，整个系统就像是装在 FileMaker 外壳里的网页系统。甚至连入口和列表的功能都通过其自主开发的插件将数据放到 Webviewer 中。
一句话总结，Businessman ERP 只可远观，不可以亵玩啊。
访问网址：[https://www.businessmanerp.com]
首先我推荐一个：react native，facebook推出的一个跨平台解决方案，去年推出了iOS版，手机淘宝的有一个模块“猜你喜欢”就是用react native实现的，效果还不错，另外今年9月份，facebook推出了android版，大家不妨试一下，这里针对于webapp，做了一个比对：
相对于Webapp的优势：
不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题；
有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用；
可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻弹动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。
相对于Native app的优势：
可以通过服务端远程更新JS，进而直接更新app的页面；
相对于Webapp和Native的劣势：
扩展性仍然远远不如web，也远远不如直接写Native code；
从Native到Web，要做很多概念转换，势必造成双方都要妥协。最终web要用一套CSS的阉割版，Native要费劲地把这个阉割版转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性）。
另外我以前在CocoaChina上收藏过的一个帖子，整理了许多iOS和Android跨平台解决方案，感觉很不错，现在拿出来分享给大家，希望对题主有帮助。
1、jQuery Mobile
jQuery Mobile是jQuery 在手机上和平板设备上的版本。jQuery Mobile 不仅会给主流移动平台带来jQuery核心库，而且会发布一个完整统一的jQuery移动UI框架。支持全球主流的移动平台。jQuery Mobile文档比较全面，同时有在线工具帮你快速创建自己中意的UI风格。
技术需求：HTML，CSS，jQuery
平台支持: 绝大多数移动浏览器
2、Corona SDK（使用Lua语言）：
Corona SDK的优点：
稳定；支持硬件加速、GPS、指南针及照相机等；支持与Map、Facebook、OpenFient、GameCenter的集成；内建的物理集成；Lua语言比较容易学习；
已经有了一些很不错的应用，至少能够证明这个SDK是可以做出优秀应用来的；不错的社区支持。
Corona SDK不太好的地方：
只支持iOS和Android；Lua语言不是面向对象的；每年都要交授权费（99美元/年）。
另外还有其他的一些补充，比如：
对于Corona SDK不支持的第三方SDK没法自己去集成；编译项目的时候需要把代码上传到Corona的服务器上去编译，不能在本地直接编译；无法扩展Corona的功能；物理模块还有一些缺陷。
3、Airplay SDK（后来更名为Marmalade，不少大的公司在使用Airplay SDK，尤其适用于进行2D/3D游戏的开发）
目前使用Marmalade的游戏有《割绳子》、《植物大战僵尸》、《你猜我画》、Build 'n' Bash 3D、Catch the Monkey、Need for Speed Shift以及WorkSnug Pro等多款游戏。
Airplay SDK文档中还包含多个示例。“感觉受到限制”的开发者还可以在Airplay SDK上进行扩展。开发者需要对C++比较熟悉。
4、Appcelerator（Titanium）
Appcelerator允许使用HTML/Javascript来开发原生app，开发者可以免费使用。目前世界上185个国家中有超多46万的开发者在使用Appcelerator提供的解决方案。
Titanium为Appcelerator于2008年底所推出的跨平台应用程序开发解决方案，目前支持iOS/Android/Blackberry/WM7等行动平台，以及Windows/Linux/OS X这三种主流的桌上型平台。
所谓的跨平台app开发就是一套代码写完以后可以多端发布运行到各个平台，比如：安卓、iOS、微信 JS SDK、web、百度直达号、360流应用..
解决方法：WEB APP。
所谓的 web app就是给web站打了个包加了个壳，我们看起来像是一个app可以上传到应用商店，可以从上面-，但是我们在手机上打开之后看到的实际上还是网页，只不过写成的是自适应的网页能够在手机上显示的也比较好，能够唬人，做到跟原生app神似！
Web App从实现角度是不是可以分为几种：
1、直接使用移动设备浏览器使用；
2、使用本地封装Embed Browser来调用Web接口；
3、使用Web技术（HTML，JavaScript，CSS）直接构建本地应用；
从这个角度讲，后两种很难分清Web和Native的区别，由于HTML5的支持以及现在JavaScript/CSS/DOM等性能和稳定程度越来越高，他们的表现不一定会跟Native差别太大。
跨平台app开发的UI就是基于html5 css3和js的，工程师只需要会前端就可以轻松学会跨平台app开发，大大降低了app开发的成本。 关于跨端开发应用案例分享模板和跨端开发方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨端开发应用案例分享模板的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于跨端开发方案、跨端开发应用案例分享模板的信息别忘了在本站进行查找喔。
本文目录一览：
- 1、跨端开发面面谈之基于WebView的Hybrid开发模式
- 2、阿里跨终端的H5游戏开发解决方案——Hilo
- 3、跨敏捷团队的大规模项目协同案例分享
- 4、行业案例与应用—国内外 FileMaker 开发 ERP 案例分享
- 5、如何实现iOS和安卓跨平台的开发
- 6、如何开发跨平台移动App应用
跨端开发面面谈之基于WebView的Hybrid开发模式
跨终端移动开发是近期准备总结的一个主题，作为这一系列的开始，首先简单说说基于WebView的Hybrid混合开发模式。有过混合应用开发经验的同学，对基于WebView的Hybrid开发模式应该不会陌生。借助于原生端各平台的WebView组件，可以实现Native和JavaScript的双向通信，从而将Web App与Mobile App融合起来，开启混合开发的新模式。
基于WebView的Hybrid开发模式到如今已经非常成熟，不再是一个实验性新技术，而是广泛应用在各大厂商的平台型应用如微信、手Q中。
jsBridge作为连接Native和JavaScript的桥梁，是基于WebView的Hybrid开发模式中的关键点。
在了解其通信原理后，再来看JSBridge究竟是什么。从前端角度来看，可能会把JSBridge理解为业务开发过程中，以全局变量注入到WebView中，帮助调用原生API的JavaScript工具库。这样的理解不够准确，按照我的理解，JSBridge不是一个标准的规范，基于原生系统为WebView组件提供的能力，已经可以建立起WebView JavaScript bridge，即使不再做更高程度的封装，也可以完成从Native到JavaScript的双向通信了。
我们所说的JSBridge，是对底层通道的抽象封装，这一过程包括了原生和JavaScript两侧内容，在原生端需要考虑系统API差异，对上层调用提供统一接口，在JavaScript端需要考虑调用方式，请求管理等内容。JSBridge的设计实现已经是成熟技术了，其设计可以参考 In-depth Profiling of JSBridge 、 Hybrid APP架构设计思路 ，一个安卓端完整JSBridge实现可以参考 JsBridge实现 。
目前，基于WebView的Hybrid开发模式非常成熟，广泛应用于各类平台型App中。实现一个完善的JSBridge是在现有App中集成使用Hybrid开发模式的基础，在完成这一基础设施建设后，大家继续在各个方向深挖，在不同的维度不断优化性能和体验。
多数App的Hybrid部分做到上面部分，已经有了还不错的体验。在我的了解中，空间团队在上面基础上继续优化给出的是当前做的更好的方案。其主要流程如下图所示，详细内容可以参考 QQ空间前端工程师如何做首屏优化
除了在现有App中集成使用这一开发模式，还可以使用这一技术开发独立App。早期的PhoneGap、Cordova、现在的Ionic，是这一领域较为知名的开发框架。
我司前端技术栈曾以Angular为主，一些App也由前端团队基于Angular技术栈选型Ionic。初入团队曾维护过基于Angular 1.x的Ionic App，用于我司投资顾问服务客户的以IM为主、综合一些其他业务，可以算一个比较复杂的应用。
前端技术背景的同学，采用Ionic框架开发App的学习成本不高。开发过程中仍在沿用前端技术，写的仍是Web App,跑在原生WebView容器中。采用Ionic提供的组件库，可以快速搭建项目界面。其扩展原生的机制也比较方便，如有原生能力的需求，并且没有现成实现的，可以自行封装使用，不过这个过程就需要原生开发同学的参与了。在我们的上述App开发中，主要是安卓端消息推送模块由原生开发同学提供了支持，其余对原生能力的需求如拍照、相册访问等常见需求，都有现成方案。
然而，采用Ionic完成上述应用，也有明显不足的地方。首先是聊天列表方面，我们知道，如微信和QQ聊天窗口，这是一个异构的无限滚动长列表，在进入聊天界面时，一般只加载最近的一屏聊天数据，然后通过滚动加载历史消息。在原生端完成这一需求有各种常见手段，而仅靠Web端技术，在各种折腾后，效果都不尽如人意。其次是动画，这里的动画包括了换页动画和其他动画，流畅程度一般。最后是前端开发通病，要处理浏览器兼容性问题，crosswalk只是一个理论解决方案，其体积限制了几乎不会被采用。
Ionic不断迭代，新的版本中依赖新的Angular。新的Angular与Angular 1.x开发体验已经完全不同，如果你还不了解，可以阅读我们团队书籍 揭秘Angular 2 。新的Ionic的开发体验，相比以往也有提升，在其工具链中，提供了拖拽式项目生成工具
同时，Ionic pro提供的开发者工具，为应用整个生命周期提供了完善的支持平台，包括了以下功能，不过，使用需要付费。
站在当下来看，对于前端技术背景开发者来说，如果已有Angular基础，不希望引入过高学习成本，需要快速开发一个复杂程度不算太高、或者对应用性能不是特别敏感的跨终端App，选择Ionic依然是一个可行方案。
然而，既然你已经身在前端领域这样一个技术更迭日新月异的圈子里，还是应该使劲的折腾，关注跨端开发这个主题新的技术热点，接下来我也会继续谈谈在NativeScript、React Native、Flutter的一些体验，可以保持关注。
阿里跨终端的H5游戏开发解决方案——Hilo
Hilo是由阿里巴巴集团开发的一款 HTML5 跨终端 游戏 解决方案，可以帮助开发者快速创建 HTML5 游戏 。有以下特征：独立模块设计，支持多种模块范式的包装版本;面向对象程序化开发;多重渲染模型，其中包括 Canvas，DOM 和 WebGL 等;兼容多台台式机和移动浏览器；使用 Flash Shim 来支持 IE ;支持物理扩展： Chipmunk；支持骨骼动画扩展： DragonBone！1、Hilo 支持多种模块范式的包装版本，包括AMD，CMD，COMMONJS，Standalone多种方式接入。另外，你可以根据需要新增和扩展模块和类型；
2、极精简的模块设计，完全面向对象；
3、多种渲染方式, 提供DOM，Canvas，Flash，WebGL等多种渲染方案（目前已经申请专利）；
4、全端浏览器的支持和高性能方案，独有的Flash渲染方案，即使在低版本IE浏览器下也可以跑起来“酷炫” 游戏 ； DOM渲染方案能显著解决低性能手机浏览器遇到的性能问题；
5、物理引擎支持——Chipmunk，支持自扩展物理实现；骨骼动画支持——DragonBones，同时内建骨骼动画系统——Tahiti（目前内部使用）；
6、案例丰富，框架成熟，已经经历多届阿里巴巴双十一，年中大促互动营销活动考验；
舞台Stage是一个各种图形、精灵动画等的总载体。所以可见的对象都要添加到舞台或其子容器后，才会被渲染出来。
Stage构造函数接收一个参数properties，此参数包含创建stage的各种属性。
舞台Stage上的物体的运动等变化，都是通过一个定时器Ticker不断地调用Stage.tick()方法来实现刷新的。
舞台上的一切对象都是可视对象，可以是图片、精灵、文字、图形，甚至DOM元素等等。Hilo提供了一些基本的可视类供您使用，比如添加一个图片到舞台上：
要想舞台上的图形、精灵动画等对象能响应用户的点击、触碰等交互事件，就必需先为舞台开启DOM事件响应，然后就可以使用View.on()来响应事件。
接下来，您就可以开始利用hilo提供的各种可视类来创建各种图形、精灵动画，尽情发挥您的创造力，开始您的HTML5 游戏 之旅吧！
Hilo对于开发H5 游戏 的开发者和对Web端渲染感兴趣的小伙伴来说值得一看，Hilo有诸多案例可供参考，如果你想继续深入了解它，可移步官方文档或者Github一探究竟！
跨敏捷团队的大规模项目协同案例分享
我们公司的研发队伍有200人左右，1年多之前，我以总操盘手的身份，推动全部IT团队开展敏捷实践。所有敏捷团队都在以Scrum框架开展实践，利用 Jira 展开对 Story、Task 的敏捷管理。有的已经连续进行了20多个 Sprint 周期，开始主动重构自己的系统，大家都玩的很嗨。在这个过程当中，也有某些同事在转型中碰到了问题，甚至质疑我的方向。但最终我用结果证明了转型的正确性，同时在研发团队内推动形成了良好的敏捷气氛。关于敏捷，我的观点是，敏捷的含义很广泛，但可以被分为以下四个范畴，这是四个独立话题，有人说是不同级别的敏捷，我旗帜鲜明的表示不认可，我认为基本上没有关联，并不是包含的关系。我们遇到的敏捷问题，都可以归结到其中一个范围，思索和寻找答案也请在这个范围内找，否则疑惑会越来越多。
首先是组织的敏捷，现在是VUCA时代，面对互联网的冲击，各种传统行业的转折点在不经意间就会来临，应对不好就可能死掉。老板们已经认识到这一点，他们想建立更好的体制来应对。有一本书是专门讲这个的，《赋能TeamofTeams》跟IT并没有必然联系，投入大成本开展组织敏捷实践的，往往是传统跨国企业，比如麦当劳。
然后是适合敏捷的项目任务，在项目管理范畴里面，没有最好只有最合适，看任务本身适合什么。中国的互联网行业的特点，诞生了大量适合敏捷模型的项目，特别是从0到1的阶段，但无论你是否知道敏捷，你都会不由自主这么去做，因为他是符合人的正常认知的。但仍有大量的项目任务，并不适合敏捷模型。
再说个人和团队利用敏捷来提高自己。敏捷是一种心态，一种做事哲理。你可以利用敏捷来提高自己，跟你做什么并没有关系。Scrum的三个支柱什么？透明，检视，调整。你有没有仔细思索过这三个词？敏捷使人进步，你要记得敏捷对你的好，你要感恩提供机会给你敏捷实践的人。
最后说跨团队协同。在平台型多团队研发体系中，有各种问题，立场不同，目标理解不一致，沟通GAP，责任不清晰，问题很多。不管是DEVOPS还是SAFe框架，还是什么，都是为了解决问题的。怎么样形成良性循环，我的评估标准仍然是，是否有助于透明，增加共识和减少沟通成本。是否有利于发现问题？是否有利于改善和调整。
那么我们是怎么进行跨团队协同的呢？
首先说下我们所面临的难点和困境。我们做的是To B业务，研发者天然不是用户，业务不是生活场景，开发人员不明白业务场景和业务需求。掏钱使用平台的都是中小微物流企业的企业主，都是李云龙一样的草莽英雄，他们只想着性价比，能不能通过平台挣钱，他们虽然会为平台付费，但从来不是平台的使用者。使用者都是他的员工，因为老板的命令而不得不使用，因此从最终使用者那里永远得不到正面反馈。
我们的需求来自独立的业务部门，他们仅熟悉业务语境，而研发团队只懂系统语境，存在巨大的沟通代沟。产品经理则处在一个夹心的位置，稍有不慎，就变成了两端的抱怨对象，被吐槽成“无附加价值的传话筒”，两头不讨好，他们的自我价值感很低。
而我们的平台系统，处在业务核心建设的中后期，一方面要继续建设，前期积攒的问题又在爆发，架构不合理，系统耦合性高，随便增加点功能，所有系统模块都要跟着动，所有研发团队都要参与，因此项目规模很难缩小。
系统耦合性大，你中有我我中有你，责任不清，跨团队协同非常麻烦，同时架构的优化改造又很难找到抓手。找到原因，设计解决方案那么我们要如何去解决这些纠缠不清的问题呢？
基于对我们实际情况的思索，我们找到了问题的根因。
从两个维度来分析，从业务维度，业务项目关注的的业务的价值，关注的是承载价值的业务流程，也就是由价值块组成的业务闭环。这个价值块是业务语境，跟系统实际无关。他们不关注系统是怎么实现的，只关注上线时间。
再从研发团队维度，他们不对价值块负责，只对系统模块负责，期望按照自己的敏捷节奏做事。
在价值传递的过程中，由于价值块和系统模块之间的不统一，产品经理在把价值块落地到平台系统上的时候，会遇到很多难题。架构设计上扯皮，每个研发团队的理解，会产生很多不认同。在落地的时候就会非常艰难。
找到了问题的根源，也就有了解决方案，那就是从最开始，就要把价值块和团队绑定起来，明确好责任方。根据系统和模块的现实情况，团队是改造不了的，除非废掉平台，推倒重来。那么能改的，就是对于价值块的定义。
那我们是怎么设计的呢？
我们在 Jira 上定义了”项目 — Epic — Story — 子任务”的四层级结构。
首先明确所有研发团队的性质。承担业务功能研发的，承担底层及相对独立模块的，比如成员体系，支付体系，还有前端团队。为项目分类，大业务项目立项通过后由管理员建立，技术优化类项目有研发团队自己建立。那么Epic，就明确定义为之前所说的价值块。明确由某个研发团队牵头负责，属于某个唯一项目，在业务流程图和计划中体现，这个是最关键的点，下一页我会重点说明。
然后Story属于某个唯一系统，同时属于某个唯一Epic，不跨团队，由各Scrum团队自行管理。SubTASK又属于一个唯一的Story，由一个人负责。
既然是价值块，不可能仅涉及一个团队，但是又由一个团队负责。怎么办呢，需要其他团队完成的部分，以Story的形式，指给其他团队。但是由Epic责任方承担跨团队沟通责任，作为依赖项进行明确的管理。这样，就界定了责任。从一开始避免扯皮。
这其中，最关键的点，就是拆分Epic！
对于业务团队来说，Epic是沟通业务场景的最小颗粒元素，组成业务流程图。Epic及业务流程图是是沟通业务方案的终点，但同时是技术团队沟通系统方案的起点。Epic的内容从一开始就要得到业务团队和研发团队的认同，务必要实现语境的统一，这样就形成了所有人理解一致的基础，避免了在价值传递过程中的转译。
在拆分Epic的时候，要考虑系统的现实情况，确保要以某个团队为主，让这个团队承担责任。而这个Epic中，需要其他团队完成的，由该团队的PO与其他团队PO协调一致，指给其他团队，刚才说了，有负责Epic的团队，承担跨团队沟通的责任。
这实际上，对各团队都提出了高的要求，不提高要求怎么能进步呢？同时要求各团队要向对方走进一步，不靠近怎么实现透明呢？
对于产品团队来说，进行业务模块拆分时，要充分考虑系统现状，这对产品经理的业务场景抽象能力和工作习惯提出了一些更高要求。
对于业务团队，Epic不仅仅是业务语言，不仅仅是价值块，还包含了系统因素，他需要多了解一些业务和系统的结合。
对于研发团队来讲，从一开始，就知道了可能要负责某个Epic，他必须提前进入项目，了解业务，参与Epic的梳理。
这种高要求，同时会促使团队的进步，这种大家共同促成的语境统一，降低了沟通难度，提高了合作水平。
在具体工作中，我们除了各个团队的看板以外，还设立了项目看板，每周更新一次。由三个部分组成，业务流程图，项目迭代看板，各团队依赖项看板。
首先我们把业务流程图画在墙上，当然不是所有模块都需要研发，很多是利用现有模块的，大家可以看到，上面的的每一张贴纸，都是一个 Epic，代表了任务。我们可以完成一个 Epic，就把这张纸撕掉扔掉，流程图仍然在上面。这是业务流程图。
再看项目迭代看板，每一行是一个团队，每一张贴纸，代表了他负责的 Epic。这样就是这个项目的整体进度。思路清晰的不得了。
再看依赖项看板，这是其中一个团队的。把这个项目迭代中的所有依赖项都写出来了，主要是要对方提供接口。每一行是一个团队的。每一张都是指给别人的 Story。在每周的项目站会上，大家以统一的基准过进度，确认问题。所有的问题，都可以定位到某一个 Epic，很容易确定问题范围。极大的降低了沟通复杂度。看着业务流程图和迭代看板，研发小伙伴很容易知道在做哪一个模块，在业务链条上处在什么位置。
同时各个团队有自己的 SM 和 PO，又明白了在跨团队沟通时的主从地位，在依赖项看板前沟通问题，就不用扯皮了，责任一目了然，进展一目了然。
在实际实践过程中，效果非常好。详细的内容，我们整理在 Confluence 上，包括项目情况，业务流程图，包括依赖项。
还有产品+研发团队的回顾会，大家会讨论Epic的划分是否合理，会讨论发现了哪些可以系统优化的点。这样，我们实际上走在持续改善的道路上。
除了之前介绍到的理解一致外，增加了透明，降低了沟通难度，明确了任务的标准，是 Epic 还是 Story，还明确了责任，跨团队沟通中，谁是责任方，我们还能够从任务分配和 Jira 数据统计中，发现我们系统的问题。
对于业务研发团队来说，如果任务都是业务 Epic，而缺少系统优化的自建 Epic，则说明团队业务研发负荷过重，从而忽视了系统自身的优化，这样容易积累技术债务，积累风险，贻害未来。你们可能在生产 BUG。需要加以平衡干预。
对于基础研发来说，他们的主要工作是系统能力的沉淀，和业务项目的支援，比如一些对外提供接口的 Story 任务。如果他们承担了独立的业务 Epic，或者业务项目的 Story 过多，则说明基础系统需要继续解耦，或者架构不合理，你做了哪里，就说明哪里有问题。
对于小前端团队来说，不应该承担业务逻辑，如果出现了独立的 Epic，或者业务逻辑 Story，那么做了哪里，哪里就有问题。需要将逻辑还给业务编排层及以后，逐步实现真正的前后端分离。
我们说，好的需求是涌现出来的，系统优化的点，也是不断涌现出来的。通过这个流程，我们就能够实现能够落地系统方面的持续改善。适时的改善，有业务价值的改善，不是自嗨的改善。
讲到这里，大家发现我并没有讲到太多的 Jira 和 Confluence 这些工具的使用方法。
对于工具，我的观点是：工具可以做为技术的辅助，但更重要的是使用者的思想认识；我们既要尊重现实情况，又要尊重团队各角色的需求，也要保持一定的专业度和立场，才能达成能够落地的协同，最终形成合力共同迈向目标。无论是 Jira 还是 Confluence 都是很灵活的工具，本身提供了很通用的管理要素，我们可以根据实际的需求把这些要素进行组合，把适合自身的管理和协同思想融入进去，不断实现良性循环，不断提高交付能力。
行业案例与应用—国内外 FileMaker 开发 ERP 案例分享
关于 FileMaker 开发，我们已经分享过很多技巧。最近，我们有一位客户委托我们根据他们的流程开发一套 ERP，这正好让我们可以去实践我们关于中小企业应用现代化软件的观念和思考。当然，这个项目对我们来说也是一次挑战，所以计划将项目开发过程中的一些感受和资料分 3 次分享给大家。在开发之前，我们想了解一下 FileMaker 到底可以做成什么样。所以，我们搜集了部分目前这个领域里相对成熟的 FileMaker ERP（本文讨论的 ERP 是 100 人以下规模企业用来管理客户、销售、采购、库存和财务等业务流程的软件） 产品。所以，第一篇我们就来共同研究一下这个领域里最好的产品。
神机妙算
目前来说，是中文领域唯一可直接销售的进销存 FileMaker 套件，也是影响力最大的 FileMaker 套件。界面效果可谓武装到牙齿，功能和技术也都非常扎实。
神机妙算的开发者由于收到工厂色彩管理的影响，为每一个模块都配置了一种主题色。这极大的方便了用户识别模块窗口，也算是软件的一大特色。此外，权限的设计，也是软件的一大亮点。
产品可全功能试用，访问网址：[http://macdiy-]
FMStartingPoint
FMSP 是唯一一款免费的 ERP 软件，也因此是全球分发数量最多的 FileMaker 系统。
FMSP 的界面布局和模块都可谓是国外 FileMaker ERP 类产品的典型。Project、Accounts 和 Invoice 是国外中小企业的最基本要求。同时，由于软件本身也相对复杂，所以可以作为使用 FileMaker 搭建复杂系统的参考。
虽然，免费且开源只是一种营销策略，但是这种做法确实造福了很多 FileMaker 入门用户。FMSP 间接或直接地帮助 FileMaker 开发者完成了手中的项目，以及帮助他们提升了技术。
产品开源，访问网址：[http://fmstartingpoint.com]
Jarvis CRM
Jarvis CRM 是一款拿过 FileMaker 年度设计优秀奖的软件，是比较
现代风格的 FileMaker 系统。Jarvis 比较特色的地方是将甘特图、日历、图表等前端模块融入到系统之中，所以整个系统看起来比较鲜活。只提供产品介绍，访问网址： [https://jarviscrm.com]
Job Pro
老牌的 FileMaker 系统，是比较有想法的 FileMaker 产品。Job Pro的主要亮点是功能上更加关注工作流程的管理，同时也兼具小型 ERP 的功能。
产品可全功能试用，访问网址：[https://jobprocentral.com]
KiBiz
老牌的 FileMaker 系统，拥有 30 年的历史。功能详尽，拥有自己的一套操作流程。
产品可全功能试用，访问网址：[http://kibizsystems.com]
Businessman ERP
Businessman ERP 可以说是 Bug 级的产品，整个系统就像是装在 FileMaker 外壳里的网页系统。甚至连入口和列表的功能都通过其自主开发的插件将数据放到 Webviewer 中。
一句话总结，Businessman ERP 只可远观，不可以亵玩啊。
访问网址：[https://www.businessmanerp.com]
如何实现iOS和安卓跨平台的开发
这是个比较专业的问题首先我推荐一个：react native，facebook推出的一个跨平台解决方案，去年推出了iOS版，手机淘宝的有一个模块“猜你喜欢”就是用react native实现的，效果还不错，另外今年9月份，facebook推出了android版，大家不妨试一下，这里针对于webapp，做了一个比对：
相对于Webapp的优势：
不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题；
有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用；
可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻弹动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。
相对于Native app的优势：
可以通过服务端远程更新JS，进而直接更新app的页面；
相对于Webapp和Native的劣势：
扩展性仍然远远不如web，也远远不如直接写Native code；
从Native到Web，要做很多概念转换，势必造成双方都要妥协。最终web要用一套CSS的阉割版，Native要费劲地把这个阉割版转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性）。
另外我以前在CocoaChina上收藏过的一个帖子，整理了许多iOS和Android跨平台解决方案，感觉很不错，现在拿出来分享给大家，希望对题主有帮助。
1、jQuery Mobile
jQuery Mobile是jQuery 在手机上和平板设备上的版本。jQuery Mobile 不仅会给主流移动平台带来jQuery核心库，而且会发布一个完整统一的jQuery移动UI框架。支持全球主流的移动平台。jQuery Mobile文档比较全面，同时有在线工具帮你快速创建自己中意的UI风格。
技术需求：HTML，CSS，jQuery
平台支持: 绝大多数移动浏览器
2、Corona SDK（使用Lua语言）：
Corona SDK的优点：
稳定；支持硬件加速、GPS、指南针及照相机等；支持与Map、Facebook、OpenFient、GameCenter的集成；内建的物理集成；Lua语言比较容易学习；
已经有了一些很不错的应用，至少能够证明这个SDK是可以做出优秀应用来的；不错的社区支持。
Corona SDK不太好的地方：
只支持iOS和Android；Lua语言不是面向对象的；每年都要交授权费（99美元/年）。
另外还有其他的一些补充，比如：
对于Corona SDK不支持的第三方SDK没法自己去集成；编译项目的时候需要把代码上传到Corona的服务器上去编译，不能在本地直接编译；无法扩展Corona的功能；物理模块还有一些缺陷。
3、Airplay SDK（后来更名为Marmalade，不少大的公司在使用Airplay SDK，尤其适用于进行2D/3D游戏的开发）
目前使用Marmalade的游戏有《割绳子》、《植物大战僵尸》、《你猜我画》、Build 'n' Bash 3D、Catch the Monkey、Need for Speed Shift以及WorkSnug Pro等多款游戏。
Airplay SDK文档中还包含多个示例。“感觉受到限制”的开发者还可以在Airplay SDK上进行扩展。开发者需要对C++比较熟悉。
4、Appcelerator（Titanium）
Appcelerator允许使用HTML/Javascript来开发原生app，开发者可以免费使用。目前世界上185个国家中有超多46万的开发者在使用Appcelerator提供的解决方案。
Titanium为Appcelerator于2008年底所推出的跨平台应用程序开发解决方案，目前支持iOS/Android/Blackberry/WM7等行动平台，以及Windows/Linux/OS X这三种主流的桌上型平台。
如何开发跨平台移动App应用
什么是跨平台app？所谓的跨平台app开发就是一套代码写完以后可以多端发布运行到各个平台，比如：安卓、iOS、微信 JS SDK、web、百度直达号、360流应用..
解决方法：WEB APP。
所谓的 web app就是给web站打了个包加了个壳，我们看起来像是一个app可以上传到应用商店，可以从上面-，但是我们在手机上打开之后看到的实际上还是网页，只不过写成的是自适应的网页能够在手机上显示的也比较好，能够唬人，做到跟原生app神似！
Web App从实现角度是不是可以分为几种：
1、直接使用移动设备浏览器使用；
2、使用本地封装Embed Browser来调用Web接口；
3、使用Web技术（HTML，JavaScript，CSS）直接构建本地应用；
从这个角度讲，后两种很难分清Web和Native的区别，由于HTML5的支持以及现在JavaScript/CSS/DOM等性能和稳定程度越来越高，他们的表现不一定会跟Native差别太大。
跨平台app开发的UI就是基于html5 css3和js的，工程师只需要会前端就可以轻松学会跨平台app开发，大大降低了app开发的成本。 关于跨端开发应用案例分享模板和跨端开发方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨端开发应用案例分享模板的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于跨端开发方案、跨端开发应用案例分享模板的信息别忘了在本站进行查找喔。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
最近发表
推荐文章
热评文章
暂时没有评论，来抢沙发吧~