2019年度小结

发表于   |   分类于   |   1,648 字   |   6 分钟   |  

2019年主要做了几个事情：

  1. 投屏工具（1-2月）
  2. 游戏模拟器预研（2-4月）
  3. I19t架构翻新（全年）
  4. 小爱同学对接（9月-12）
  5. 基础能力提升

投屏工具

工作情况

  • github开源项目scrcpy修改而来
    • 优点：demo效果不错，可以快速响应到前方需求
    • 缺点：问题修改不过来，强行上线比较伤
    • 效益：噱头，除此之外线下活动多了一个好用的投屏工具

      作为一个辅助工具可圈可点，作为一款产品欠缺很多

经验总结

手机端

  • 通过virtual displaymanager获取到framebuffer数据，再通过h264编码后透过socket传输到pc端
  • 音频数据通过remote submix的方式获取，再使用aac编码后透过socket传输到pc端

    音视频源数据获取方式，编码方式，Android MediaCodec流程，Socket通讯

PC端

  • ffmpeg库的使用
  • meson编译系统，cmake使用，config配置
  • SDL框架使用

    meson使用，SDL框架的基础知识，简单的播放器

简单回顾

  • 这个项目没有做好
    • 于个人来说，能力提升和知识面拓展很大
    • 但是于公司层面有点失策，整个过程大约占用15天工作量，仓促上线有点得不偿失
    • demo性质的落地和产品化落地，中间会差很多
    • 技术方案并没做详细评审和预研，导致后期遇到问题陷入无法推进的囧地。
  • 启示：
    • 拿到一个新的东西还是需要先宏观把握，大致了解整个技术脉络
    • 工具化demo和产品化demo需要区分一下，在没有了解具体需求的情况下不能贸然应对
    • 断舍离，果断的时间需要下果断的结论

游戏模拟器预研

工作情况

  • retroarch开源项目演化而来，提供一个frontend样例
    • 优点：可以快速出项目
    • 缺点：模拟器算是黑产，这也为整个项目奠定了不确定因素
    • 效益：尚未发现，初衷是可以带动外设

经验总结

技术侧有JNI和native compile技能提升，透过retroarch可以了解到libretro的应用，同时也看了“世界”程序员和自身的差距，在软件架构的把握和理解上差很大；retroarch整体是作为一个全平台适配的产品而推出的，因此：

  • 面向接口编程，退出了libretro
  • c代码重构
  • 模块插件化

简单回顾

  • 这个产品有点可惜
    • 鉴于在黑产的边缘，模拟器一直无法得到官方的认可。
    • 组员的能力都很强，也针对retroarch本身做了一些客制化
    • 怀旧主机是否属于强/真需求，有待验证
  • 启示
    • 产品化与法律风险需要一并考量

I19t架构翻新

工作情况

  • I19t已经推出了3年，距AI初版问世已经迭代2年，各种问题不断，业务耦合严重。
    • 优点：
      • 能力/业务分离，I19t回归AI能力范畴
      • 智能中台，可以服务于全平台；
      • 内部代码结构清晰；收缩防守范围，可以集中注意力解决“能力”本身问题。
    • 缺点：
      • 推进业务方比较困难，业务方集成有工作量；
      • 新SDK稳定需要时间
      • 实际代码工作量大于工作难度，填坑时间大过设计。
    • 效益：
      • 解放高耦合的dock模块，以dock为例，可以避免再去耦合非内部模块的，仅针对防守范围内（如灯效，悬浮球）做业务，解耦dock和sharktime
      • 解放自己，外丢业务模块到业务方（灯效维护灯效）

经验总结

中台业务不好做，与App业务不同，中台是常驻后台稳定输出型应用；需要考虑的是对接方的便利性和kill-killed之间的绑定关系。

  • 说服自己是理所当然的，说服业务方才是能力
  • 好的架构！=好的广告，业务方不管你的架构，而是他/她/它爽不爽
  • 模块化/复用大于一切，好的pattern大过好的代码技巧（投机代码不能提升效益/减少工作量，但是好的pattern可以）

简单回顾

  • 这个产品有希望
    • 从代码解耦的角度去宣传，好过从“你的你负责，谁家孩子谁领走”的角度去推广
    • 代码不能是一个人写出来的，大的项目需要有清晰的架构和设计文档，需要统一团队的认知
    • 文档可以暂时没有，思路一定要事先统一
  • 启示
    • 从业务的角度去看代码，先于业务有利，这样才会有人站台，不然就只能自己爽而无法落地。

小爱同学对接

工作情况

  • MIUI亮点产品
    • 优点：提高用户黏度/认可度/购买欲
    • 缺点：没有
    • 效益：需要看销量和日活/月活/年购买力

经验总结：

作为MIUI的亮点产品，小爱同学已经完全自立为一个生态了。
技术侧，手机端小爱同学功能受限/管控依赖平台（硬件和软件），从唤醒方案到语音收集再到云端NLP，最后到每个终端的云控，牵扯到的部分/模块非常多，也可以看出小爱同学的模块解耦很成功。
所以从厂家的角度来看，可做的事情就没有那么多了。

  • 唤醒方案依赖于芯片提供商
  • app客制化-不可能
  • 云控功能，考虑付费购买？

大部分的时间是在帮忙收集问题/反馈问题，所以如何高效定位问题和把问题归一化是重要的能力。

简单回顾

提高了沟通能力，同时也真的学会了换位思考。在资源有限的情况下可以把事情不做砸，也是很好的本事。

基础能力提升

  1. 旁门左道书单，佛，道，匡扶摇，摄影，魔兽世界编年史，AI西瓜书
  2. 重新学习MobileNet，DW,PW，虽然还是忘记了
  3. gradle集成

这一年最大的收获在于代码之外

  • 站在一个局外人的立场来看当下的公司，包括老板的决策，公司的运营，项目的废/立
  • 跟粉丝沟通，了解为什么购买（便宜）
  • 从开发者的角度去看，为什么要接MIUI/MI SDK
  • 凡事都问问我/你这么做能给你/我带来什么