flutter阿里,flutter阿里云

我的第一个flutter项目：购物app

这是个产假作业。故事是这样的。

成都创新互联公司是专业的泰州网站建设公司，泰州接单;提供做网站、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行泰州网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

生了娃，生活一地鸡毛。擦，碎钞机的需求怎么那么多。

当时，有一堆返利优惠券app比较火

...这里扯多了这篇文章被锁了....

我就想，来扒一扒，他们是怎么赚钱的。

结论：淘宝联盟。

淘宝联盟是阿里巴巴旗下的亲儿子，不那么有名是因为是个私生子吧，官网上还有个没听过的名号叫“阿里妈妈”，呵呵。淘宝联盟是给淘宝上推广商品的人用的，他们有一个专门的名称，叫做淘宝客，即“推广者（Publisher）”，他们帮电商平台推荐商品给别的买家，买家购买后，电商平台可以增加销量，而他们则可以获得推广佣金。

后来，知道京东也有自己的联盟平台，叫做“京东联盟”，拼多多也有，叫做“多多进宝”。

回到这些app的赚钱逻辑上来。对于用户而言，它们的两个噱头是：

“用我们的app买，你可以自用省钱”

“用我们的app，分享给别人下单，你可以赚钱！”

所以，这些app推广起来很容易啊，因为谁用谁赚钱呀！

那么为何不自己搭一个呢？

与其这些佣金落到别人口袋，不如自己直接做最顶层上线，发展出N个下线，岂不是躺着赚钱，哈哈哈哈哈

搞清楚赚钱逻辑之后，我发现淘宝联盟的api是很开放的。

商品链接： ;pid=mm_343780171_368000361_101527600308itemId=595640102734src=qtka_wxxtdx=1

其中，activityId是优惠券id，pid是推广者在阿里妈妈官网注册的id，只有这个id是我注册的，那么佣金就到我口袋去了，哈哈哈。

刚好练一下flutter，一次开发，两端使用，我一个人就可以了。app暂时取名为“小猪购”，拿粉红猪贴牌。

演示视频：

做混合的话Uniapp和Flutter我应该学哪个啊？

Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策

牛笔了！阿里P8大佬熬夜15天，把所有iOS知识体系整理成了PDF

随着互联网企业的不断发展，产品项目中的模块越来越多，用户体验要求也越来越高，想实现小步快跑、快速迭代的目的越来越难，还有65535，应用之间的互相调用等等问题，插件化技术应用而生。如果没有插件化技术，美团、淘宝这些集成了大量“app”的应用，可能会有几个g那么大。

所以，当今的iOS移动开发，不会底层、算法、插件化、组件化，80%以上的面试都过不了。

阿里P8大佬每天熬夜到凌晨一两点，花了将近半个月时间将iOS逆向安防、算法、架构设计、多线程，网络进阶，还有底层、音视频、Flutter等等、iOS第三方开源框架整合成了一套系统知识笔记PDF，长达1042页！相信看完这份文档，你将会对这些iOS第三方框架有着更深入、更系统的理解。

底层原理毫无疑问还是iOS开发现在必备能力。

对象底层原理

指针与内存的一些相关面试

weak 弱引用

block 的原理

AutoreleasePool 原理

Runloop 的原理

Runtime相关、消息转发

性能优化以及架构能力相对比之前要求越来越多!

①性能优化方面：tableView的优化 - 界面卡顿原理 - app 性能分析 - 项目优化

②架构方面：设计模式、解耦手段、组件化....

数据结构算法能力占比也比较大。通常一般大公司都会有一些笔试：虽然不在核心岗位对于数据结构算法要求不是非常严格，但是也会有一些常规的数据结构和算法的题

排序

数据结构设计

复杂度讨论

一些脑经急转弯的算法题

.....

现在的iOS开发为什么会遇到瓶颈是因为：前面储备过少，坐吃山空！技术不断更新的时代，我希望你沉下心来与时俱进，不断储备技能为自己加分

这里我推荐学习：视觉方向！无论直播还是小视频，图形图像处理成为必然的技能，未来5G时代的来临，这一块技术必将成为你与其他开发人员差距的赛点！

从性能方面来说，Flutter 的性能理论上是最好的，RN和Weex次之，并且都好于传统的 WebView方案

而从社群和社区的活跃来看，RN和Flutter无疑是最活跃的

总结：我个人针对现在的行情比较推荐大家学习：Flutter

学习iOS逆向的目的

大家都懂的薪资高。。。。

1 学习优秀App的设计

当你看到一个App有一些非常好用的功能，你想学习或者你也需要实现相同的功能，这样你就可以逆向它的实现，去分析它的实现过程

2 更好的去加强自己开发App的安全

当你熟悉了iOS逆向工程，今后在开发自己App的时候，哪些地方更容易别被人攻破，从而有效的去避免

3 学习iOS系统未开源库的一些实现。

比如我们常用的UIKit的实现等等

4 视野更远了，iOS开发就会不在局限于画界面，数据，网络这些操作了

iOS逆向你能够了解到整个iOS系统的大致底层，内核，程序加载过程呀，App编译过程呀，等等

5 可以改变现有app的一些功能

去爱奇艺App的广告，微信抢红包等等。（当然这个学习可以，不可以作为商业利益，违法的）

阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化

本文由阿里闲鱼技术团队逸昂分享，原题“消息链路优化之弱感知链路优化”，有修订和改动，感谢作者的分享。

闲鱼的IM消息系统作为买家与卖家的沟通工具，增进理解、促进信任，对闲鱼的商品成交有重要的价值，是提升用户体验最关键的环节。

然而，随着业务体量的快速增长，当前这套消息系统正面临着诸多急待解决的问题。

以下几个问题典型最为典型：

1）在线消息的体验提升；

2）离线推送的到达率；

3）消息玩法与消息底层系统的耦合过强。

经过评估，我们认为现阶段离线推送的到达率问题最为关键，对用户体验影响较大。

本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践，内容包括问题分析和技术优化思路等，希望能带给你启发。

（本文已同步发布于：）

本文是系列文章的第6篇，总目录如下：

《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》

《阿里IM技术分享(二)：闲鱼IM基于Flutter的移动端跨端改造实践》

《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》

《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》

《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》

《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》（* 本文）

从数据通信链接的技术角度，我们根据闲鱼客户端是否在线，将整体消息链路大致分为强感知链路和弱感知链路。

强感知链路由以下子系统或模块：

1）发送方客户端；

2） idleapi-message（闲鱼的消息网关）；

3） heracles（闲鱼的消息底层服务）；

4） accs（阿里自研的长连接通道）；

5）接收方客户端组成。

整条链路的核心指标在于端到端延迟和消息到达率。

强感知链路中的双方都是在线的，消息到达客户端就可以保证接收方感知到。强感知链路的主要痛点在消息的端到端延迟。

弱感知链路与强感知链路的主要不同在于：弱感知链路的接收方是离线的，需要依赖离线推送这样的方式送达。

因此弱感知链路的用户感知度不强，其核心指标在于消息的到达率，而非延迟。

所以当前阶段，优化弱感知链路的重点也就是提升离线消息的到达率。换句话说，提升离线消息到达率问题，也就是优化弱感知链路本身。

下图一张整个IM消息系统的架构图，感受下整体链路：

如上图所示，各主要组件和子系统分工如下：

1） HSF是一个远程服务框架，是dubbo的内部版本；

2） tair是阿里自研的分布式缓存框架，支持 memcached、Redis、LevelDB 等不同存储引擎；

3） agoo是阿里的离线推送中台，负责整合不同厂商的离线推送通道，向集团用户提供一个统一的离线推送服务；

4） accs是阿里自研的长连接通道，为客户端、服务端的实时双向交互提供便利；

5） lindorm是阿里自研的NoSQL产品，与HBase有异曲同工之妙；

6）域环是闲鱼消息优化性能的核心结构，用来存储用户最新的若干条消息。

强感知链路和弱感知链路在通道选择上是不同的：

1）强感知链路使用accs这个在线通道；

2）弱感知链路使用agoo这个离线通道。

通俗了说，弱感知链路指的就是离线消息推送系统。

相比较于在线消息和端内推送（也就是上面说的强感知链路），离线推送难以确保被用户感知到。

典型的情况包括：

1）未发送到用户设备：即推送未送达用户设备，这种情况可以从通道的返回分析；

2）发送到用户设备但没有展示到系统通知栏：闲鱼曾遇到通道返回成功，但是用户未看到推送的案例；

3）展示到通知栏，并被系统折叠：不同安卓厂商对推送的折叠策略不同，被折叠后，需用户主动展开才能看到内容，触达效果明显变差；

4）展示到通知栏，并被用户忽略：离线推送的点击率相比于在线推送更低。

针对“1）未发送到用户设备”，原因有：

1）离线通道的token失效；

2）参数错误；

3）用户关闭应用通知；

4）用户已卸载等。

针对“3）展示到通知栏，并被系统折叠”，原因有：

1）通知的点击率；

2）应用在厂商处的权重；

3）推送的数量等。

针对“4）展示到通知栏，并被用户忽略”，原因有：

1）用户不愿意查看推送；

2）用户看到了推送，但是对内容不感兴趣；

3）用户在忙别的事，无暇处理。

总之：以上这些离线消息推送场景，对于用户来说感知度不高，我们也便称之为弱感知链路。

我们的弱感知链路分为3部分，即：

1）系统；

2）通道；

3）用户。

共包含了Hermes、agoo、厂商、设备、用户、承接页这几个环节。具体如下图所示。

从推送的产生到用户最终进入APP，共分为如下几个步骤：

步骤1 ：Hermes是闲鱼的用户触达系统，负责人群管理、内容管理、时机把控，是整个弱感知链路的起点。；

步骤2 ：agoo是阿里内部承接离线推送的中台，是闲鱼离线推送能力的基础；

步骤3 ：agoo实现离线推送依靠的是厂商的推送通道（如：苹果的 apns通道、Google的fcm通道、及国内各厂商的自建通道。；

步骤4 ：通过厂商的通道，推送最终出现在用户的设备上，这是用户能感知到推送的前提条件；

步骤5 ：如果用户刚巧看到这条推送，推送的内容也很有趣，在用户的主动点击下会唤起APP，打开承接页，进而给用户展示个性化的商品。

经过以上5个步骤，至此弱感知链路就完成了使命。

弱感知链路的核心问题在于：

1）推送的消息是否投递给了用户；

2）已投递到的消息用户是否有感知。

这对应推送的两个阶段：

1）推送消息是否已到达设备；

2）用户是否查看推送并点击。

其中：到达设备这个阶段是最基础的，也是本次优化的核心。

我们可以将每一步的消息处理量依次平铺，展开为一张漏斗图，从而直观的查看链路的瓶颈。

漏斗图斜率最大的地方是优化的重点，差异小的地方不需要优化：

通过分析以上漏斗图，弱感知链路的优化重点在三个方面：

1） agoo受理率：是指我们发送推送请到的数量到可以通过agoo（阿里承接离线推送的中台）转发到厂商通道的数量之间的漏斗；

2）厂商受理率：是指agoo中台受理的量到厂商返回成功的量之间的漏斗；

3） Push点击率：也就通过以上通道最终已送到到用户终端的消息，是否最终转化为用户的主动“点击”。

有了优化方向，我们来看看优化手段吧。

跟随推送的视角，顺着链路看一下我们是如何进行优化的。

用户的推送，从 Hermes 站点搭乘“班车”，驶向下一站： agoo 。

这是推送经历的第一站。到站一看，傻眼了，只有不到一半的推送到站下车了。这是咋回事嘞？

这就要先说说 agoo 了，调用 agoo 有两种方式：

1）指定设备和客户端，agoo直接将推送投递到相应的设备；

2）指定用户和客户端，agoo根据内部的转换表，找到用户对应的设备，再进行投递。

我们的系统不保存用户的设备信息。因此，是按照用户来调用agoo的。

同时：由于没有用户的设备信息，并不知道用户是 iOS 客户端还是 Android 客户端。工程侧不得不向 iOS 和 Android 都发送一遍推送。虽然保证了到达，但是，一半的调用都是无效的。

为了解这个问题：我们使用了agoo的设备信息。将用户转换设备这一阶段提前到了调用 agoo 之前，先明确用户对应的设备，再指定设备调用 agoo，从而避免无效调用。

agoo调用方式优化后，立刻剔除了无效调用，agoo受理率有了明显提升。

至此：我们总算能对 agoo 受理失败的真正原因做一个高大上的分析了。

根据统计：推送被 agoo 拒绝的主要原因是——用户关闭了通知权限。同时，我们对 agoo 调用数据的进一步分析发现——有部分用户找不到对应的设备。优化到此，我们猛然发现多了两个问题。

那就继续优化呗：

1）通知体验优化，引导打开通知权限；

2）与agoo共建设备库，解决设备转换失败的问题。

这两个优化方向又是一片新天地，我们择日再聊。

推送到达 agoo ，分机型搭乘厂商“专列”，驶向下一站：用户设备。

这是推送经历的第二站。出站查票，发现竟然超员了。

于是乎：我们每天有大量推送因为超过厂商设定的限额被拦截。

为什么会这样呢？

实际上：提供推送通道的厂商（没错，各手机厂商的自家推送通道良莠不齐），为了保证用户体验，会对每个应用能够推送的消息总量进行限制。

对于厂商而言，这个限制会根据推送的类型和应用的用户规模设定——推送主要分为产品类的推送和营销类的推送。

厂商推送通道对于不同类型消息的限制是：

1）对于产品类推送，厂商会保证到达；

2）对于营销类推送，厂商会进行额度限制；

3）未标记的推送，默认作为营销类推送对待。

我们刚好没有对推送进行标记，因此触发了厂商的推送限制。

这对我们的用户来说，会带来困扰。闲鱼的交易，很依赖买卖家之间的消息互动。这部分消息是需要确保到达的。

同样：订单类的消息、用户的关注，也需要保证推送给用户。

根据主流厂商的接口协议，我们将推送的消息分为以下几类，并进行相应标记：

1）即时通讯消息；

2）订单状态变化；

3）用户关注内容；

4）营销消息这几类。

同时，在业务上，我们也进行了推送的治理——将用户关注度不高的消息，取消推送，避免打扰。

经过这些优化，因为超过厂商限额而被拦截的推送实现了清零。

通过优化agoo受理率、厂商受理率，我们解决了推送到达量的瓶颈。但即使消息被最终送达，用户到底点击了没有？这才是消息推送的根本意义所在。

于是，在日常的开发测试过程中，我们发现了推送的两个体验问题：

1）用户点击Push有开屏广告；

2）营销Push也有权限校验，更换用户登陆后无法点击。

对于开屏广告功能，我们增加了Push点击跳过广告的能力。

针对Push的权限校验功能，闲鱼根据场景做了细分：

1）涉及个人隐私的推送，保持权限校验不变；

2）营销类的推送，放开权限校验。

以上是点击体验的优化，我们还需要考虑用户的点击意愿。

用户点击量与推送的曝光量、推送素材的有趣程度相关。推送的曝光量又和推送的到达量、推送的到达时机有关。

具体的优化手段是：

1）在推送内容上：我们需要优化的是推送的时机和相应的素材；

2）在推送时机上：算法会根据用户的偏好和个性化行为数据，计算每个用户的个性化推送时间，在用户空闲的时间推送（避免在不合适的时间打扰用户，同时也能提升用户看到推送的可能性）。

3）在推送素材上：算法会根据素材的实时点击反馈，对素材做实时赛马。只发用户感兴趣的素材，提高用户点击意愿。

通过以上我们的分析和技术优化手段，整体弱推送链路链路有了不错的提升，离线消息的到达率相对提升了两位数。

本篇主要和大家聊的是只是IM消息系统链路中的一环——弱感知链路的优化，落地到到具体的业务也就是离线消息送达率问题。

整体IM消息系统，还是一个比较复杂的领域。

我们在消息系统的发展过程中，面临着如下问题：

1）如何进行消息的链路追踪；

2）如何保证IM消息的快速到达（见《闲鱼亿级IM消息系统的及时性优化实践》)；

3）如何将消息的玩法和底层能力分离；

4）离线推送中如何通过用户找到对应的设备。

这些问题，我们在以前的文章中有所分享，以后也会陆续分享更多，敬请期待。

[1] Android P正式版即将到来：后台应用保活、消息推送的真正噩梦

[2] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[3] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[4] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[5] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[6] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[7] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[8] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[9] 现代IM系统中聊天消息的同步和存储方案探讨

[10] 新手入门一篇就够：从零开发移动端IM

[11] 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”

[12] 移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结

[13] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[14] IM消息送达保证机制实现(二)：保证离线消息的可靠投递

[15] 零基础IM开发入门(一)：什么是IM系统？

[16] 零基础IM开发入门(二)：什么是IM系统的实时性？

[17] 零基础IM开发入门(三)：什么是IM系统的可靠性？

[18] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？