微信小程序选项卡功能开发步骤与方法全解析
500
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的一些体验，可以保持关注。
然而这么做又会来带新的问题，那就是weex所提供的消息机制只能是在单容器内使用，按照官方的说法即这是一个实例级别的事件而不是应用级别的。那么就需要我们自己来做一套消息通知机制供应用级别使用，来解决多weex容器实例以及连通weex、native以及H5。其实这套机制并不复杂，因为原生已经有很多消息机制可以供我们选择了，包括EventBus、LocalBroadcast等等。这里可以详见我的之前有关消息机制实现的文章（传送门： https://www.jianshu.com/p/774b77ddde52 ）
之前说到大多数的weex使用场景是单容器（或者说是单实例）的，因此一般的实现也都是在一个Activity中（以安卓为例，下同）只有一个WXSDKInstance。然后有时候需求就是这么坑爹，在某些原生页面中希望可以内嵌一个甚至多个Weex的容器，那么这时候用来实现Weex容器的就不能再是Activity而是View了。我们需要自定义一个View来实现IWXRenderListener接口，并且在该View内部来维护一个WXSDKInstance，虽然初始化WXSDKInstance时候传入的Context还是Activity，但是好在instanceId是自增的，因此在一个Activity中有多个Weex的View，它们还是可以通过id来区分的。另外在使用View做容器的时候，也需要自己hook Activity的生命周期，来与WXSDKInstance中相应的方法绑定，不然在自定义Module等应用场景中将无法正确拿到Activity的生命周期回调。
想必很多团队在接触或者决定使用weex的时候，所在的项目已经是开发甚至是上线一段时间了，并且大多项目一定会用到WebView承载的H5页面，那么在开发H5相关页面时自然而然会定义很多通用的Bridge能力，比如账号登录机制、通用的loading组件、网络请求代理等等。然而我们在开发weex页面时候则不希望再重复实现这套Bridge，因此我们就需要实现一个适配器，通俗地说就是通过定义一个weex的Module去实例化H5的Bridge并且调用实例的方法。这套机制核心需要关注的是H5的Bridge需要怎么样的环境，我们通过哪种方法来实例化H5的Bridge（大多数情况下会需要用到反射）。此外，这种做法由于无法完全在weex容器中还原一个H5的环境，因此也并不是能100%复用H5的Bridge能力，对于无法复用的，我们还是需要基于weex重新开发一套。
在深度使用weex的时候，weex官方提供的组件会逐渐变得无法满足当前需求，这时就需要我们来做一些自定义的组件。当然这块并不需要用到什么黑科技，weex官方就提供了这类扩展，也就是WXComponent以及WXVContainer。常规的独立组件继承WXComponent即可，类似写一个原生的自定义View，具体的属性以及方法定义也可以参考官方文档（ http://weex.apache.org/cn/guide/extend-android.html ）。对于View的容器组件则需要继承WXVContainer，然后你就可以自定义各种cell，并且通过addSubView方法拿到加进去的cell。
weex官方提供了playground app，帮助你在设备上调试。但对于依赖自己项目环境的功能，就必须在项目内提供一个调试工具了，核心类似playground app，即提供一个扫码功能，能进入weex页面进行调试，对于调试这块功能，我会在后续的文章中详细讲解。
小程序平台现在已经成为一款应用不可或缺的阵地，因此跨端方案自然不能少了小程序这个平台。目前核心做法还是依赖于babel，并且需要在小程序端预先实现一套相对应的组件。详细的内容也将在后续文章中详细展开。
跨端方案既然是以提高效率为目的，那么自然需要有足够的数据来做支撑，因此我们需要在weex的几个生命周期内做好埋点，来统计各种耗时。另外在业务上也会有数据需求，一般也是通过埋点的形式来做统计
多端融合一定是未来移动端开发的一个方向，它除了解决一部分体验问题之外还能提高人效，因此未来各大企业也会越来越多地依赖这项技术。至于具体的方案选型，诸如weex、rn或者flutter，还是需要根据具体的业务场景来选择，目前并没有完美的方案，当然基于这些开源方案来二次开发，从而补足这些方案存在的不足则是更好的了。
对于我个人而言，自身的技术规划加上公司业务需求，有幸在这个时间点能学习到前端知识并且落地这套方案。因此我打算开一个文章系列，记录一下这套方案不断演进过程中的点点滴滴。
这段时间经历了很多事情，说是一夜长大也不为过吧。但是没有时间再自怨自艾了，找对方向，就算再难受爬着也要向前。失去的东西总会回到我们身边，虽然有时并不是以我们希望的方式。
在目前来看，Java仍然是大部分企业-后端开发语言，不过java开发难度较大、量级重，所以适用于企业级大型项目的开发。
Python 诞生得比较早，其语言特性是做事情只有一种方法，这个特点也决定了这门语言很简单。Python 是一门简洁的语言，有大量的数学、科学工具、人工智能的库，这意味着在不远的将来它会发挥更大的作用。同时在Web 开发领域也有广泛的应用，除了正常的Web开发，它还在网络爬虫中广受欢迎。
PHP 是一门很容易上手的语言，由于其容易上手，并且发展得比较成熟。适用于个人网站、企业官网等轻量级的项目开发。
目前这三种是后端开发语言的首选，后续再做补充。
产品需求--- 特定场景下，用户问题（痛点）和期望，的解决方案
需求分析：将业务需求，转换成产品需求的过程，就叫做需求分析
不管用什么方法分析需求，都要验证解决方案，业务需求 ---- 需求分析 ------ 解决方案 ---- 验证解决方案
并不是每一个需求都值得去深入分析，当我们发现了一个需求后， 结合场景 ，对其进行价值判断，以及判断需求能否被解决
有的需求，用户提供的就是一个解决方案，也可能提供一个错误的解决方案，结合业务场景和了解的知识，进行判断
痛点的价值有多大
1、是否是迫切的
2、是否必须解决
3、出现频率是否高
4、持续时间是否长
5、用户群里有多大，是不是目标用户的普遍需求，是不是大多数目标用户都有这个痛点
判断痛点能否被解决
只有 能解决有价值 的痛点，才有可能转换成需求，分析才有意义
调查是否有人解决了该痛点，解决方案是什么，解决的效果怎么样
没有解决方案，要看看为什么没有解决，关键问题是什么，这个关键问题自己能不能解决
用户需求要与愿景和目标对齐
明确产品的愿景和目标，用户的需求要与愿景和目标对齐
基于场景来分析需求
需求是在特定的场景下产生的，分析需求一定要结合用户的场景去分析，不同的场景，需求的解决方案也可能不一样
场景的描述：人 + 时间 + 地点 + 起因 + 经过 + 结果 ，人在什么时间，什么地点，做了什么事情，怎么做的，结果是什么
5W2H：七何分析法
why——为什么？为什么要这么做？理由何在？原因是什么？
what——做什么？，是什么？目的是什么？作什么工作？、
when——何时？什么时间完成？什么时机最适宜？
where——何地？在哪里做？从哪里入手？
who——何人做？有谁来承担？谁来完成？谁负责？
how——如何？如何提高效率？如何实施？方法怎么样？
how much——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
利用5W2H分析，了解选材的痛点
选材：设计师和客户沟通，根据客户的想法和使用场景，选择房屋装修，要使用的物料清单
利用5W2H分析，痛点和解决方案
1、做什么
优化，调整选材系统，解决设计师和客户的痛点，优化设计师和客户的体验
实现选材的业务在线化
2、为什么要做（ 选材的场景和痛点纯属虚构 ）
设计师期望能更快速的帮助选材，并录入系统，客户期望能更快速的获取报价单
设计师与客户选择材料后，会把物料的关键信息记录在纸质的物料清单上，记录起来比较麻烦，速度也比较慢
在选材时，客户与设计师一起，客户等待的时间比较长，尽量减少客户等待的时间 （1-5小时）
选择完物料后，设计师把纸质物料清单信息，手动录入到选材系统中，比较麻烦，耗时 （1-3小时）
客户比较关心报价，通长形成报价单给到客户，需要 2天的时间
3、用户
客户和设计师
4、时间
开始结束时间：2021-09-01 - 2021-11-01
迭代计划：2021-10-01 号 能迭代一个版本，线上运行 ，快速验证解决方案
5、何地
公司 ，PC 端 ，平板电脑
6、怎么做
设计师手动录入 ----- 设计师选择对应的空间结构，利用条码枪，扫描物料的编码，自动录入
设计师手动录入物料到选材系统 ----- 这个步骤直接去掉 ，自动录入到选材系统
形成报价单比较慢 ----- 选材系统提供根据选择的物料，生成报价单的功能，选择完物料后，直接生成报价单
7、多少
先做平板电脑端，设计师大多数用的都是平板电脑
按照现有的团队资源，预计投入一个小组7个开发人员来完成
根据设计师和客流量配置条码枪，系统对接条码枪
业务整理选材的物料，给物料贴条形码
报价单功能不用做的太细，能计算出价格
KANO模型
1、基本型需求
2、期望型需求
3、兴奋型需求
4、无差异需求
5、反向型需求
四象限法则
影响因数
必要型需求，还是期望型需求，做出来的产品价值大小，技术实现的时间，成本等
评估需求干系人的影响力，和重要性，有的干系人影响整个项目的成败，和决策
敏捷项目管理中，迭代计划交付的时间，开发团队的规模，速率等
需求池
需求池是一个需求管理的工具，记录各个来源收集过来的需求，防止需求的丢失，需求池的模板可以自己定义，比如
1、角色画像（使用场景，现状，痛点，期望等）
2、需求类型，优先级，重要程度
3、用户故事
4、需求状态
5、技术成本，产品价值
【转自】 后端开发学习业务三：需求分析 - 往事随灬锋 - 博客园 (cnblogs.com)
分析结构是在某某时间（when），某某地点（where），周围出现了某些事物（with what），特定类型的用户（who）萌发了某种欲望（desire），会通过何种手段（method）来满足该欲望。
1、使用场景分析的意义：产品经理知道这个新开发的功能是为了帮助用户解决什么问题；交互设计师可以从中获知这种使用场景的细节：“发生频率，需求强度，用户有什么样的能力和辅助工具”；其他合作伙伴了解该功能的价值会对其产生共鸣，激发干劲。
2、如何判断一个使用场景（需求）有价值？
两种衡量需求场景靠谱程度的方法：调查现阶段用户是否在凑活着使用某种产品，心里在骂娘，但还忍着用（如12306）。用最低廉的成本做出一个基本能用的解决方案，请目标用户试用，询问体验。
3、使用场景（需求）的描述方法和各部分必要性。各部分信息存在的意义如下：
when，where，with what
这几点信息其实统一地描述了需求产生的环境。从这些环境信息可以分析出诱发需求的条件和需求产生时的环境条件。
例如，“在候机时，候机厅里，用户看到手机电量过低时，会想要充电”。
基于此，可以分析出，用户是在电量低的信息刺激下，想要充电。当时他所在的位置是候机厅，一个充满电器，但是没有插座开发给乘客的地方。
who
使用场景还需要分析是什么样类型的人有这种需求，他有什么样的能力可以潜在地帮他实现目标。
继续前面的例子，坐飞机的手机用户都可能会有这种需求，因为他们下了飞机一般都会联系家人报平安，联系别人来接机。坐飞机的这些人一般都比较有钱，会带着现金或者信用卡。
desire
对需求的描述有一些注意事项，那就是某种需求背后往往还有更深层次某种需求，它只是这种需求的解决方案。
比如想给手机充电是一种需求。但背后的需求可能是打发无聊、给家人保平安、看目的地城市地图、联系旅行社等等。给手机充电只是这些背后需求用户自己能想到的一种解决方案。
不断一层一层分析需求可能帮助你更清楚地了解用户到底想要什么。那么，一旦满足某种需求实在太难，满足它背后的需求也是可以的。比如，假设在候机大厅提供充电太难，还可以向用户提供电视（打发无聊）、刷信用卡的公用电话（给家人保平安）、提供该航班目的地地图（看目的地城市地图）、代定酒店（联系旅行社）。
method
method是用户现有的解决方案。把现有解决方案清晰地描述出来可以帮助产品团队判断竞争对手是谁。这种竞品往往不局限于同行业，只要目标需求一样，就是竞争对手。
例如，针对获取地理信息这个需求，卫星地图的竞争对手可能是纸质地图，指南针和指路大妈。
有了对竞争对手的了解，就可以更明确地知道这种用户需求是否存在，强度如何，我们的新方案有何优势，对方是否弱爆了。
最近对做产品的思考中，感触最深的就是对“场景”的理解。“在什么情况下会产生需求（的冲动），比在什么情况下使用产品更重要。”如果理解了这句话，关于“场景”的理解就更进一步了。理解场景不是描述表面，而是追根溯源。
对于制作者来说，场景应用主要表现为简单、轻、快制作、快体验；
对于访问者来讲，场景应用主要表现为具有某一特定情感诉求，有交互，有延伸。 关于跨端开发应用场景分析报告和跨端开发应用场景分析报告模板的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨端开发应用场景分析报告的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于跨端开发应用场景分析报告模板、跨端开发应用场景分析报告的信息别忘了在本站进行查找喔。
本文目录一览：
- 1、跨端开发面面谈之基于WebView的Hybrid开发模式
- 2、移动APP开发该怎么分析用户场景
- 3、基于Weex的跨多端融合方案（一）
- 4、主流后端开发语言特点及应用场景
- 5、后端开发：需求分析
- 6、用户使用场景分析
跨端开发面面谈之基于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的一些体验，可以保持关注。
移动APP开发该怎么分析用户场景
随着移动互联网的发展，以及智能手机的普及，APP应用市场发展火爆。目前，国内智能手机用户已经超过了6亿。APP开发将是未来信息技术的主流。要想在众多的APP应用脱颖而出并获得成功，首先就要做好APP开发需求分析，那么我们应该怎么做呢？一、项目定位在做APP开发之前，首先要明确你的APP是做什么用的，要实现什么目的，这一点对于APP开发尤为重要。你的APP开发能解决什么问题，是工具型还是娱乐型APP应用软件。二、目标受众分析目标受众分析就是指你所开发的APP是为谁服务的。根据年龄、收入、学历、地区等多维度进行目标用户群体定位，并分析用户在不同消费场景下的需求，进而满足用户需求。三、APP竞品分析竞品分析做得好不好，也直接影响这个产品之后的发展。确定哪些产品是你的竞争对手，通过不同的渠道获得竞争对手信息，可以用SWOT分析法对产品的优势、劣势、机会和风险等四个方面与竞争对手进行全方位的比较，知道自己有哪些优势和劣势。四、产品功能设计APP的设计和开发都离不开对APP功能的分析，特别是的APP软件的方案中要多APP功能进行详细的说明。根据APP应用的使用场景和操作流程，提炼软件的功能需求，以及软件运行的硬件环境。五、用户界面设计APP的视觉设计是APP开发完成以后给APP使用者的外在形象，即APP用户在使用你的APP是看到的字体的颜色、字体的类型、APP的标识logo等。尽量提供用户特点鲜明的功能和界面，达到用户体验的最佳化，给予用户良好的视觉体验。基于Weex的跨多端融合方案（一）
大多数的应用都会在一个weex容器中进行页面跳转，这种场景下使用navigator就能比较好地实现（页面切换）。但是在实际混合开发场景中，会碰到更为复杂的跳转逻辑，如原生页面A跳转Weex页面，再从B跳转远程页面C，继而再从C跳转Weex页面D……再加上还会有跳转H5页面等等，这样对于后退栈的管理就会比较复杂。目前我们采用的解决方案是：为每一个weex页面单独使用一个容器（对于H5也是一样），这样页面的跳转就能交给原生系统的后退栈来管理。当然这么做也会有性能开销，但是综合来说，这种场景不多，因此从性价比考虑这么做是目前最合适的。然而这么做又会来带新的问题，那就是weex所提供的消息机制只能是在单容器内使用，按照官方的说法即这是一个实例级别的事件而不是应用级别的。那么就需要我们自己来做一套消息通知机制供应用级别使用，来解决多weex容器实例以及连通weex、native以及H5。其实这套机制并不复杂，因为原生已经有很多消息机制可以供我们选择了，包括EventBus、LocalBroadcast等等。这里可以详见我的之前有关消息机制实现的文章（传送门： https://www.jianshu.com/p/774b77ddde52 ）
之前说到大多数的weex使用场景是单容器（或者说是单实例）的，因此一般的实现也都是在一个Activity中（以安卓为例，下同）只有一个WXSDKInstance。然后有时候需求就是这么坑爹，在某些原生页面中希望可以内嵌一个甚至多个Weex的容器，那么这时候用来实现Weex容器的就不能再是Activity而是View了。我们需要自定义一个View来实现IWXRenderListener接口，并且在该View内部来维护一个WXSDKInstance，虽然初始化WXSDKInstance时候传入的Context还是Activity，但是好在instanceId是自增的，因此在一个Activity中有多个Weex的View，它们还是可以通过id来区分的。另外在使用View做容器的时候，也需要自己hook Activity的生命周期，来与WXSDKInstance中相应的方法绑定，不然在自定义Module等应用场景中将无法正确拿到Activity的生命周期回调。
想必很多团队在接触或者决定使用weex的时候，所在的项目已经是开发甚至是上线一段时间了，并且大多项目一定会用到WebView承载的H5页面，那么在开发H5相关页面时自然而然会定义很多通用的Bridge能力，比如账号登录机制、通用的loading组件、网络请求代理等等。然而我们在开发weex页面时候则不希望再重复实现这套Bridge，因此我们就需要实现一个适配器，通俗地说就是通过定义一个weex的Module去实例化H5的Bridge并且调用实例的方法。这套机制核心需要关注的是H5的Bridge需要怎么样的环境，我们通过哪种方法来实例化H5的Bridge（大多数情况下会需要用到反射）。此外，这种做法由于无法完全在weex容器中还原一个H5的环境，因此也并不是能100%复用H5的Bridge能力，对于无法复用的，我们还是需要基于weex重新开发一套。
在深度使用weex的时候，weex官方提供的组件会逐渐变得无法满足当前需求，这时就需要我们来做一些自定义的组件。当然这块并不需要用到什么黑科技，weex官方就提供了这类扩展，也就是WXComponent以及WXVContainer。常规的独立组件继承WXComponent即可，类似写一个原生的自定义View，具体的属性以及方法定义也可以参考官方文档（ http://weex.apache.org/cn/guide/extend-android.html ）。对于View的容器组件则需要继承WXVContainer，然后你就可以自定义各种cell，并且通过addSubView方法拿到加进去的cell。
weex官方提供了playground app，帮助你在设备上调试。但对于依赖自己项目环境的功能，就必须在项目内提供一个调试工具了，核心类似playground app，即提供一个扫码功能，能进入weex页面进行调试，对于调试这块功能，我会在后续的文章中详细讲解。
小程序平台现在已经成为一款应用不可或缺的阵地，因此跨端方案自然不能少了小程序这个平台。目前核心做法还是依赖于babel，并且需要在小程序端预先实现一套相对应的组件。详细的内容也将在后续文章中详细展开。
跨端方案既然是以提高效率为目的，那么自然需要有足够的数据来做支撑，因此我们需要在weex的几个生命周期内做好埋点，来统计各种耗时。另外在业务上也会有数据需求，一般也是通过埋点的形式来做统计
多端融合一定是未来移动端开发的一个方向，它除了解决一部分体验问题之外还能提高人效，因此未来各大企业也会越来越多地依赖这项技术。至于具体的方案选型，诸如weex、rn或者flutter，还是需要根据具体的业务场景来选择，目前并没有完美的方案，当然基于这些开源方案来二次开发，从而补足这些方案存在的不足则是更好的了。
对于我个人而言，自身的技术规划加上公司业务需求，有幸在这个时间点能学习到前端知识并且落地这套方案。因此我打算开一个文章系列，记录一下这套方案不断演进过程中的点点滴滴。
这段时间经历了很多事情，说是一夜长大也不为过吧。但是没有时间再自怨自艾了，找对方向，就算再难受爬着也要向前。失去的东西总会回到我们身边，虽然有时并不是以我们希望的方式。
主流后端开发语言特点及应用场景
这段时间空闲时间较多，就想着自学一种后端语言，但是后端语言种类如此繁多，到底选择学习哪一种，也是查了很多资料，一下总结了几种常见的后端语言的特点及应用场景。在目前来看，Java仍然是大部分企业-后端开发语言，不过java开发难度较大、量级重，所以适用于企业级大型项目的开发。
Python 诞生得比较早，其语言特性是做事情只有一种方法，这个特点也决定了这门语言很简单。Python 是一门简洁的语言，有大量的数学、科学工具、人工智能的库，这意味着在不远的将来它会发挥更大的作用。同时在Web 开发领域也有广泛的应用，除了正常的Web开发，它还在网络爬虫中广受欢迎。
PHP 是一门很容易上手的语言，由于其容易上手，并且发展得比较成熟。适用于个人网站、企业官网等轻量级的项目开发。
目前这三种是后端开发语言的首选，后续再做补充。
后端开发：需求分析
业务需求--- 用户在特定场景下的问题（痛点）和期望产品需求--- 特定场景下，用户问题（痛点）和期望，的解决方案
需求分析：将业务需求，转换成产品需求的过程，就叫做需求分析
不管用什么方法分析需求，都要验证解决方案，业务需求 ---- 需求分析 ------ 解决方案 ---- 验证解决方案
并不是每一个需求都值得去深入分析，当我们发现了一个需求后， 结合场景 ，对其进行价值判断，以及判断需求能否被解决
有的需求，用户提供的就是一个解决方案，也可能提供一个错误的解决方案，结合业务场景和了解的知识，进行判断
痛点的价值有多大
1、是否是迫切的
2、是否必须解决
3、出现频率是否高
4、持续时间是否长
5、用户群里有多大，是不是目标用户的普遍需求，是不是大多数目标用户都有这个痛点
判断痛点能否被解决
只有 能解决有价值 的痛点，才有可能转换成需求，分析才有意义
调查是否有人解决了该痛点，解决方案是什么，解决的效果怎么样
没有解决方案，要看看为什么没有解决，关键问题是什么，这个关键问题自己能不能解决
用户需求要与愿景和目标对齐
明确产品的愿景和目标，用户的需求要与愿景和目标对齐
基于场景来分析需求
需求是在特定的场景下产生的，分析需求一定要结合用户的场景去分析，不同的场景，需求的解决方案也可能不一样
场景的描述：人 + 时间 + 地点 + 起因 + 经过 + 结果 ，人在什么时间，什么地点，做了什么事情，怎么做的，结果是什么
5W2H：七何分析法
why——为什么？为什么要这么做？理由何在？原因是什么？
what——做什么？，是什么？目的是什么？作什么工作？、
when——何时？什么时间完成？什么时机最适宜？
where——何地？在哪里做？从哪里入手？
who——何人做？有谁来承担？谁来完成？谁负责？
how——如何？如何提高效率？如何实施？方法怎么样？
how much——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
利用5W2H分析，了解选材的痛点
选材：设计师和客户沟通，根据客户的想法和使用场景，选择房屋装修，要使用的物料清单
利用5W2H分析，痛点和解决方案
1、做什么
优化，调整选材系统，解决设计师和客户的痛点，优化设计师和客户的体验
实现选材的业务在线化
2、为什么要做（ 选材的场景和痛点纯属虚构 ）
设计师期望能更快速的帮助选材，并录入系统，客户期望能更快速的获取报价单
设计师与客户选择材料后，会把物料的关键信息记录在纸质的物料清单上，记录起来比较麻烦，速度也比较慢
在选材时，客户与设计师一起，客户等待的时间比较长，尽量减少客户等待的时间 （1-5小时）
选择完物料后，设计师把纸质物料清单信息，手动录入到选材系统中，比较麻烦，耗时 （1-3小时）
客户比较关心报价，通长形成报价单给到客户，需要 2天的时间
3、用户
客户和设计师
4、时间
开始结束时间：2021-09-01 - 2021-11-01
迭代计划：2021-10-01 号 能迭代一个版本，线上运行 ，快速验证解决方案
5、何地
公司 ，PC 端 ，平板电脑
6、怎么做
设计师手动录入 ----- 设计师选择对应的空间结构，利用条码枪，扫描物料的编码，自动录入
设计师手动录入物料到选材系统 ----- 这个步骤直接去掉 ，自动录入到选材系统
形成报价单比较慢 ----- 选材系统提供根据选择的物料，生成报价单的功能，选择完物料后，直接生成报价单
7、多少
先做平板电脑端，设计师大多数用的都是平板电脑
按照现有的团队资源，预计投入一个小组7个开发人员来完成
根据设计师和客流量配置条码枪，系统对接条码枪
业务整理选材的物料，给物料贴条形码
报价单功能不用做的太细，能计算出价格
KANO模型
1、基本型需求
2、期望型需求
3、兴奋型需求
4、无差异需求
5、反向型需求
四象限法则
影响因数
必要型需求，还是期望型需求，做出来的产品价值大小，技术实现的时间，成本等
评估需求干系人的影响力，和重要性，有的干系人影响整个项目的成败，和决策
敏捷项目管理中，迭代计划交付的时间，开发团队的规模，速率等
需求池
需求池是一个需求管理的工具，记录各个来源收集过来的需求，防止需求的丢失，需求池的模板可以自己定义，比如
1、角色画像（使用场景，现状，痛点，期望等）
2、需求类型，优先级，重要程度
3、用户故事
4、需求状态
5、技术成本，产品价值
【转自】 后端开发学习业务三：需求分析 - 往事随灬锋 - 博客园 (cnblogs.com)
用户使用场景分析
应用场景分析在分析和描述用户需求时更接地气，更容易理解。分析结构是在某某时间（when），某某地点（where），周围出现了某些事物（with what），特定类型的用户（who）萌发了某种欲望（desire），会通过何种手段（method）来满足该欲望。
1、使用场景分析的意义：产品经理知道这个新开发的功能是为了帮助用户解决什么问题；交互设计师可以从中获知这种使用场景的细节：“发生频率，需求强度，用户有什么样的能力和辅助工具”；其他合作伙伴了解该功能的价值会对其产生共鸣，激发干劲。
2、如何判断一个使用场景（需求）有价值？
两种衡量需求场景靠谱程度的方法：调查现阶段用户是否在凑活着使用某种产品，心里在骂娘，但还忍着用（如12306）。用最低廉的成本做出一个基本能用的解决方案，请目标用户试用，询问体验。
3、使用场景（需求）的描述方法和各部分必要性。各部分信息存在的意义如下：
when，where，with what
这几点信息其实统一地描述了需求产生的环境。从这些环境信息可以分析出诱发需求的条件和需求产生时的环境条件。
例如，“在候机时，候机厅里，用户看到手机电量过低时，会想要充电”。
基于此，可以分析出，用户是在电量低的信息刺激下，想要充电。当时他所在的位置是候机厅，一个充满电器，但是没有插座开发给乘客的地方。
who
使用场景还需要分析是什么样类型的人有这种需求，他有什么样的能力可以潜在地帮他实现目标。
继续前面的例子，坐飞机的手机用户都可能会有这种需求，因为他们下了飞机一般都会联系家人报平安，联系别人来接机。坐飞机的这些人一般都比较有钱，会带着现金或者信用卡。
desire
对需求的描述有一些注意事项，那就是某种需求背后往往还有更深层次某种需求，它只是这种需求的解决方案。
比如想给手机充电是一种需求。但背后的需求可能是打发无聊、给家人保平安、看目的地城市地图、联系旅行社等等。给手机充电只是这些背后需求用户自己能想到的一种解决方案。
不断一层一层分析需求可能帮助你更清楚地了解用户到底想要什么。那么，一旦满足某种需求实在太难，满足它背后的需求也是可以的。比如，假设在候机大厅提供充电太难，还可以向用户提供电视（打发无聊）、刷信用卡的公用电话（给家人保平安）、提供该航班目的地地图（看目的地城市地图）、代定酒店（联系旅行社）。
method
method是用户现有的解决方案。把现有解决方案清晰地描述出来可以帮助产品团队判断竞争对手是谁。这种竞品往往不局限于同行业，只要目标需求一样，就是竞争对手。
例如，针对获取地理信息这个需求，卫星地图的竞争对手可能是纸质地图，指南针和指路大妈。
有了对竞争对手的了解，就可以更明确地知道这种用户需求是否存在，强度如何，我们的新方案有何优势，对方是否弱爆了。
最近对做产品的思考中，感触最深的就是对“场景”的理解。“在什么情况下会产生需求（的冲动），比在什么情况下使用产品更重要。”如果理解了这句话，关于“场景”的理解就更进一步了。理解场景不是描述表面，而是追根溯源。
对于制作者来说，场景应用主要表现为简单、轻、快制作、快体验；
对于访问者来讲，场景应用主要表现为具有某一特定情感诉求，有交互，有延伸。 关于跨端开发应用场景分析报告和跨端开发应用场景分析报告模板的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨端开发应用场景分析报告的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于跨端开发应用场景分析报告模板、跨端开发应用场景分析报告的信息别忘了在本站进行查找喔。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
最近发表
推荐文章
热评文章
暂时没有评论，来抢沙发吧~