flutter后台微服务,flutter服务端

Flutter：State生命周期以及页面重载问题详解

这里需要混入WidgetsBindingObserver，重写didChangeAppLifecycleState方法才能看到app进入前后台的状态

我这边使用的是一个嵌套行页面，主页面(TabBarViewPage)是一个TabBar+TabBarView实现的子页面切换，子页面是三个页面(HomeItemPage,EmailItemPage,MineItemPage)

子页面互相切换的时候下一个页面创建，上一个页面就会被销毁，这是flutter默认的情况，页面会被移除然后重载。当然你也可以设置需要的页面不被重载的页面，这个后面再讲

解决页面重载需要三步

可以看到home并没有被销毁也没有重载，但是mail被销毁了然后重载了

可以看到当主页面销毁的时候，home也是被销毁的

相关问答

Q1: flutter应用长时间在后台，点开黑屏

重新打开即可。

因为软件在后台时间过长，软件会出现一个黑屏动画，就需要重启软件即可恢复。

Q2: 《知行》技术人的管理之路（三）管理规划

《知行》感悟系列文章历史浏览：

《知行》技术人的管理之路（一）管理的基本框架

《知行》技术人的管理之路（二）角色认知

在互联网行业中当角色转变为管理岗位或者是某个团队的负责人的时候，就不能事事等着上级来安排，要学会自己规划事情。

这在里所说的管理规划就不仅仅是指工作上的规划，而是上升到整个团队；从核心内容来看，管理规划要求管理者回答清楚这样一个问题： “这个团队你打算怎么带？”

怎么回答这个问题呢？我们要根据管理规划四要素以做回答。

本文围绕管理的四要素，以及移动端负责人的身份来进行展开讨论..

团队所谓的“职能”就是回答“团队是干什么的”这个问题。

如果你想回答好这个问题不妨先思考以下下面3个问题

我的回答：

思考的问题回答完了，那么我的团队职能是什么呢？也就是我的团队是干什么的呢？

开发并设计一款高质量的使用在移动端的应用程序，以提高居民的生活的便利，并且可以为公司提供良好的品牌效应。

当所有的团队成员清楚了团队职能才能产生如下的效果：

1.提升团队凝聚力

2.有效激励员工

3.提升员工的主动性

为什么这里说是团队的职能而不是说职责，因为团队的职能包含了两个层次：

职责和使命。职责是团队职能的下限，使命是团队职能的上限。

简单描述就是基本职责解决的是团队的“生存问题”，而使命解决的是“团队实现”问题。类似就像个人的自我价值实现一样，具体就不展开说了。

既然团队职能的2个层次都说明了，那么我们就要做点什么了，那就是为团队设定基本职责，也需要为团队确定使命。

第一步：收集信息

从如下的四个角度梳理收集职能信息

第二步：提炼和升华

第三步：确认和主张

团队的职能的设定和宣贯是一个长期任务，不是一蹴而就的。越早做越好，逐渐的形成潜移默化的概念。

职能的界定明确来团队的价值，那么目标就是回答了“通过什么来体现团队价值”。也就是取得什么成果来体现其价值，以自身为例

本节主要是通过意义、原则、维度、形式、挑战来展开对目标的讨论。

1.目标首先意味着期待

2.目标意味着资源的有效配置

3.目标意味着执行力

4.目标意味着凝聚力

5.目标意味着激励

确定下清晰合理的目标不仅可以“做事”，甚至还可以“带人”，是一举两得的事情。在目标确定之后要想一想，是否和团队成员都同步了目标，以及对这个目标是否有疑惑等等。

目标的设定我们遵守SMART原则即：

1.明确性（Specific）

2.可衡量性(Measurable)

3.可达性(Attainable)

4.相关性(Relevant)

5.时限性(Time-bound)

我们首先看一个没有设定原则的目标：

我们的目标是优化App的体积。

在看一个通过设定原则优化过的目标：

从本周一到下周一，将App的体积大小减少20%。

判断一个目标是否足够清晰，只有当SMART都符合的时候才能说明目标是清晰的，而且设定的目标时尽可能少而细。通过SMART原则检查清单可以检测当前目标是否足够清晰

SMART原则检查清单：

目标维度从3个维度考虑：1.业务目标。 2.团建目标（梯队、规模）。 3.专业目标

简单说书这3个维度，这三个维度简单点说就是业绩产出，团队发展和专业能力。

业绩是要对公司以及上级或者是老板负责的，这个目标是一定要设定的；而团建目标的设定体现了管理规划的完整性，也就是说为什么目标和带人是不可分的；专业目标的设定可以提升团队的专业性，也有利于提高个人的专业能力。

从个人成长角度来说，业务的目标设定到完成的过程中，可以在时间充裕时设定自己的专业目标，通过专业目标的达成最好是能提高业绩的产出；这种不仅提高了个人的能力，还完成了公司的任务。

1.可以量化的指标 KPI

2.不可量化的目标 KRA或OKR

简单的通过KPI常见句式为：到某时间点，什么指标达到什么数字

例：“到九月底，把单机性能从300qps提升到500qps”

KRA或者OKR常见句式为：到某时间点，完成什么工作，该工作实现了哪些功能活达到了那些效果

例：“到12月地，发布BI系统1.0，支持KPI数据统计、全量数据到吃分析功能”

这部分的内容先不展开说了，有必要的时候单独写一篇文章来分析 KPI、KRA、OKR。

作者的总结就是，OKR适用于开放性强、追求创造性的组织；KPI适用于规则成熟、追求执行性的组织。

通常在目标设定遇到困难的时候，可以通过以下四类问题换个角度找到答案。

这类问题往往的情况就是，接到了一个需求任务，给你的第一反应就是这个项目够呛能做完，压力很大，完成的程度也不确定。

面对这类问题和挑战的钥匙叫做“以终为始的出发点”； 通过最终你想要什么来对你的团队进行调配或者是补充资源。

遇见这类性通常都是接到的任务太庞统，太大，比如说今年年底上线一个APP。。主要强调了“我做了什么”，没有交代做完这些工作后“收到了什么效果”

面对这类问题和挑战的钥匙叫做“结果导向的描述”。根据这个任务的需求，来对该任务进行拆分，上线的APP都具有什么功能。比如上限一个APP具有登记开门的功能。

解决办法就是向下传达了，方式有很多，可能就是微信QQ的简单一句话。如果功能业务比较复杂，可以开一个简短的业务分析会。

例如最近的时候做了一个移动端产品的一个业务规划（业务稍微有点复杂），在规划的过程中也确定了当时所能想到的方案和解决办法。方案出来了就是具体的任务落地，将方案转变成实际的工作下发出去。这时候如果不向下传递，那么可能会导致开发者不知道你的需求和业务，开发完的东西不一定满足要求，并且反复修改还会出现抱怨。 借鉴了以往的经验，这次选择了直接和该模块的后台开发负责人进行了过会讨论，在讨论问题和向下传递的过程中，还总结出了一些之前方案中不足的地方，并且愉快的进行了消息同步，效果感觉特别好。

由于公司的战略转变或者是其他的原因，往往大的目标会经常出现改变，而导致了之前我们设立的目标出现了变形，或者是根本不能执行了

面对这类问题和挑战的钥匙叫做 “设定专业目标” 。用专业目标来增强团队的内在定力，而不是被外在的需求将团队作为了救火队员。所谓的那些需求战略的改变往往都是大的战略方向的改变，但是团队内部的核心业务往往也存在于各个项目中。

这一点从自己团队的角度来说，团队内有很长的一段时候都属于那种救火队员，遇到了紧急需求而全力应对，导致看上去没有属于自己的核心业务。这时候需要找到一条出路来做一定的改变。比如重构以往的工程，后台使用微服务的架构，这就属于内在目标；而通过微服务每个团队成员都各负责一个模块，每个人都对自己的模块负责；

对自己来说，设定一个专业目标就是flutter的学习以及产品思维的锻炼，无论工作内容如何改，这两点贯穿到最后，个人的能力都会得到锻炼。

本节主要是从3个团队规划角度分析团队问题，团队建设问题会从后续的章节展开讨论。

刚刚我们说明了团队的目标设定的要点，现在说明的是团建的目标如何设定。团建目标就是团队未来会发展成什么样？

衡量方式如下：

通过上述的3中衡量方式只要盘点清楚现在实际的规模、分工、梯队和未来的规模、分工、梯队，就能把握住未来团建工作的重心了。

从资源视角看待团队，是一个成熟管理者的标志之一。

管理者做人力预算的时候要给出十分充足的理由，为什么需要这些人，为什么会是这么多人，以及依据和估算逻辑是什么。

那么要如何做这个预算呢，首先是自己对业务的理解，以及希望达成的目标角度来看；其次是参照行业资源配比情况，例如产品、设计、开发、测试、运维几个方面。

这个视角的核心含义是，到下一个时间节点，你需要重点培养出哪些人，给他们什么样的平台和空间，以及你有能力提供给他们什么指导和支持，期待他们能够胜任什么职能和角色。

新人的引进我们要了解一个概念“团队消化能力”。就是说团队现在的梯队情况和新人导师的经理问题，一个团队能够良性吸纳的新人是有限的，我们把这个限度称为“团队消化能力”。

怎么估算团队消化能力呢？首先看看团队内谁能带人，分别带几个比较合理。这里的合理就是新人导师既能带人又能兼顾对业务的投入；其次看看团队的新人培养机制是否成熟健全。

带着团队前往目标有那些可选的路径是需要管理者进行筹划的。筹划的工作主要回答了2个问题

第一个问题可以判断出我们达成目标手段是否合理，第二个问题可以判断我们申请的资源是否合理。

综上，我们通过下面的三个方面考虑路径和资源的问题

完成团队的目标需要考虑所带的团队都有那些资源；在这里资源包括时间、信息、权限。时间就是你的目标完成时间，信息就是为了完成这个目标需要自己主动的在公司内外主动收集一些相关的信息，权限就是公司在然你完成这个任务你有多大的权限协调资源等。

站在管理者的视角，需要评估一段时间内的产出效率，而不是追求工作的极致品质了。衡量一项工作“到底需要话5天完成70分，还是花10天做到90分”，这个是管理者的日常工作。通过全局来看，由于时间原因90分不一定有70分好。注意这里优秀的工程师应该放弃一些执念，转换视角，完成工作有很多手段供选择。

对于不同的方案意味着多高的成本，如下的表哥可以帮助新经理扩展思路，看到解决问题手段的多样性，避免思路过于单一。（填写大中小或者打分）

手段-成本盘点表

成熟而职业的技术管理者在倚重技术和迷信技术中间会找到一个平衡，提供一个既能解决问题、成本又合理、兼顾长短期的可行方案，而不是一个只顾眼前的“应急”对策。不是所有的人力短缺都是通过招聘来决绝的，需要综合前面的手段多样性综合来考虑。

我们在评估一个项目的结果的时候，有三个衡量维度是最重要的。

在这3个维度上是有弹性的，可以在一定的范围内灵活把握，这3个维度称为“结果评估三要素”。

在这里值得注意两点

这样我们可以总结出一个原则：对于任何一项工作，评估其结果的关键指标到底是进度、质量还是效果，决定着我们以什么方式投入什么类型的资源，就是说只有我们清楚了最关注的指标，才能让资源的投入得到最大化的发挥。

管理规划从4个方面展开职能、目标、团队、路径。

设定目标的时候，要基于当前的团队的现实情况和可用资源；盘点团队的时候，脱不开目标的设定和路径的选择；探讨路径以及做预算资源的时候，离不开目标和团队。

所以虽然把几个点展开讨论，但是几个要素之间并不独立和割裂的而是以职能为基础，彼此依赖，需要把四个要素统筹来梳理明白，才是一份完整的管理规划。

Q3: Flutter APP 上架 APP Stroe--- Flutter产物是Debug 版被拒绝上传

ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/Flutter.framework/Flutter: _ptrace. 

原因: 使用了 Flutter 的debug 版产物 打成 iPa 包 

就是Frameworks/Flutter.framework 是debug 版的产物

Debug 版的 Flutter 产物 ,SDK 内部使用了 苹果内部私有的API , 会被苹果审核监测到,存在安全性隐患. 导致拒绝上传到苹果后台.

产生的原因: 因为开发过程中,直接使用了debug 模式进行开发, 在打包的时候,直接打开 iOS 文件夹下面的工程,在Xcode 里设置 release 模式时,此时,Flutter 的产物还是 debug 模式下的产物. 没有删除替换成 release 产物

1.先 将工程 清理一遍,清理之前debug模式下 的Flutter 产物

2.然后 打开Xcode 工程,配置好相关 版本号,证书,release 模式

3. 使用命令行 打包 release ,这样Flutter.framework就会生成 release  产物

4.最后 在Xcode 工程内,按照正常 打包上传 包过程就可以了

1.进入 Flutter 工程 命令行操作

flutter clean

2 .清理之前debug 模式下的 残留产物 (或者手动进入文件夹删除)

rm -rf ios/Flutter/Flutter.framework

3. 获取 Flutter 的第三方依赖库

flutter pub get

4.编译 release 打包 产物 

flutter build ios --release 

(此时这里可以打包出 app 了, 为了安全起见,最好再次进入Xcode 清理一遍,直接打包上传,)

上面这一步,主要目的是生成 Flutter.framework  的release 版本产物

5.进入Xcode 工程,clean 一遍,检查相关证书配置,版本号等

6.直接 Xcode  Archive 打包IPA 上传 苹果后台

最后上传成功:

  思路: 通过检查Flutter.framework 它的CPU 架构支持

  如果: 该产物 支持模拟器 x86_arm64 这样的架构的话,说明该产物就是 Debug 版的 产物

   因为release 版的 产物是 不支持 模拟器CPU架构的.   

输入终端命令:  lipo -info  产物的物理路径

比如:  lipo -info /Users/zzc/Documents/rce_flutter/ios/Flutter/Flutter.framework/Flutter