8年老司机教你,如何写出一份“有理有据使人信服,android原生开发教程

编程入门 行业动态 更新时间:2024-10-25 17:24:36

8年老司机教你,如何写出一份“<a href=https://www.elefans.com/category/jswz/34/1673446.html style=有理有据使人信服,android原生开发教程"/>

8年老司机教你,如何写出一份“有理有据使人信服,android原生开发教程

4.1. App性能要求 (可选)

4.2. App Size 要求 (可选)

  1. 现有架构(可选)
  2. 建议架构

6.1. 引入的第三方框架/SDK的简介 (可选)

  1. 开发时间线
  2. 其他可选架构(可选)
  3. 参考文献

咱先从项目背景开始聊

项目背景

如果大家面试次数够多,应该会有听过一个叫STAR原则的东西,就是介绍自己项目的时候要遵循Situation(背景)->Target(目标)->Action(行动/做法)->Result(结果)这样的顺序,尽量做到简洁。

同样的,项目背景的介绍就是对应了这个STAR原则的S,也可以说是项目的动机,为什么要做这个项目。

这个背景和动机可以是一个产品产生的动机。比如说抖鹰的产
品经理发现竞品快脚发提供了一个新的视频滤镜,而且这个滤镜在竞品快脚 中迅速攀升到用户热度的第一位了,基于我们在产品的数据分析中blalala。。。于是我们也要做这个滤镜。这就是一个简洁明了的项目背景。当然这个背景也可以是一个纯技术方面的问题,比如架构的升级等等,当然如果是架构的升级,那需要在背景里面简单的介绍现有架构的大概的一些局限性(我们下文会提到)。

本人阅读过的一些经典反例就是,背景介绍的第一句话上来就开始直接飙产品/公司内部的一些黑话,比如某个sqlite 的 database的某一个col有问题啊,或者是公司内部的一个SDK的限制等等。这些都是技术细节,不是项目大背景。提前把这些细节说出来是没法在第一段就抓住读者的眼球的,这会让读者失去仔细观看全文的热情,导致最后你的设计文档可能收不到任何有意义的反馈。

项目术语

这一部分就更重要了。项目术语这个部分必须要尽可能的把设计中涉及到的:

  1. 新引用的SDK/框架
  2. 项目之前没用过的语言
  3. 项目/公司内部工具,服务
  4. 产品本身的组件Component.

都过一遍,尤其是对一些刚刚进组的朋友,这对他们会有很大的帮助。很多刚刚入职的朋友初来乍到,可能也不太敢在研讨会上问问题,阅读没有项目术语的文档对他们可以说是直接劝退的。作为一个往高级工程师方向努力的朋友们,扩大自己在组内影响力也是一个至关重要的点,如果你的设计文档可以对初级工程师/刚刚进组的朋友更友好,那么你已经成功了一半了。很多在组里面待了很久的老鸟会懒得在产品本身的组件Component 解释太多,因为他们想当然的会觉得这是一个他自己每天都接触的组件没有必要解释。这其实是不太好的,因为你的文档不是给自己看的,而是给其他组员,甚至老板(老板很多情况下是不了解产品的技术细节的)。

比如你在新的项目中打算使用GraphQL这个查询语言和相应的框架。那么最好的做法是先在术语环节介绍一下:

  1. GraphQL -> 是一种针对图状数据进行查询特别有优势的查询语言
  2. GraphQL Query-> 一种类似于HTTP GET的GraphQL 请求,用来查询后端数据
  3. GraphQL Mutation-> 一种类似于HTTP POST 的GraphQL请求,用来修改后端数据
  4. GraphQL Subscription-> 一种建立在客户端和后端之间的长链接,用来监听后端数据变化请求,大部分GraphQL框架用websocket来实现

有了这上面的介绍,相信你在接下来设计细节说到Query/Mutation的时候就不会有人懵逼了。

技术挑战

这个环节就比较简单了,把该项目的技术难点都列举出来,但是有一个问题要切记:

不要贴源码!不要贴源码!不要贴源码!

很多朋友,包括在写博客的时候都是一言不合直接复制粘贴源码,这样的做法是非常让人讨厌的,说白了就是偷懒,连精炼一下源码,哪怕做一份伪代码加comment的功夫都不肯下。还是那句话,文档是写给别人看的,不是写给自己的。

这里我用KunMinX juejin.im/user/58ab0d… 大哥的博客里面的伪代码做正面 例子,大家如果看到这一份安卓事件分发的源代码 (KunMinX 大哥如果你看到了觉得不想自己的例子被放进我的文章,请联系我,会及时删掉并替换,在这里先感谢你):

@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(ev, 1);
}
// If the event targets the accessibility focused view and this is it, start
// normal event dispatch. Maybe a descendant is what will handle the click.
if (ev.isTargetAccessibilityFocus() && isAccessibilityFocusedViewOrHost()) {
ev.setTargetAccessibilityFocus(false);
}
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
cancelAndClearTouchTargets(ev);
resetTouchState();
}
// Check for interception.
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true;
}
// If intercepted, start normal event dispatch. Also if there is already
// a view that is handling the gesture, do normal event dispatch.
if (intercepted || mFirstTouchTarget != null) {
ev.setTargetAccessibilityFocus(false);
}

复制代码

是不是瞬间没有任何兴趣了?请注意我还没有全部都复制上来,就只是一小段而已。

再看KunMinX大哥的精简版伪代码:

juejin.im/post/5d3140…

是不是瞬间就豁然开朗了。

写文档也是这样,如果我是审查者看到上来就贴项目内部的源代码的设计文档,对不起,我会直接打零分,贴源代码的设计文档,像极了初中的时候为了凑八百字而生硬的加排比句的作文一样,看起来很丰满,其实都是骨头没有肉。当你自己想钻研技术的时候,一行行的研究源码是没毛病的,但是如果你是要分享给他人的时候,千万别直接复制粘贴。

完成要求

这个环节也不多做介绍,这是和公司/产品内部的需求有关系。比如你做结构的修改,做完之后是否会影响到原有的开发流程,如果有,是否会严重的影响,这些都是需要列出来的。

现有架构和建议架构

一提到架构,很多人都会觉得很虚,感觉无从下手。其实在这方面,流程图和组件通信图都是很好的帮手。有时候可能自己会觉得无从写起,但是其实只要把流程图/组件通信图一画,其实就豁然开朗了。

这里我以我司的一个最近刚刚开源的移动开发框架 Amplify(aws.amazon/cn/amplify/)为例。

假如我在我的最新设计中提议使用这么一个新的框架,那么首先我得阐明这个框架是做什么的(PS:这是我自己总结的,和公司文案无关):

Amplify Mobile sdk 给客户端提供了一套离线应用解决方案,它包括了离线存储,和服务端数据增量更新,还有身份验证,日志发送等等移动端所需的功能。该框架以GraphQL语言为基础,通过WebSocket保持和服务器端的实时连接,还有基于时间戳的增量/全量更新保持客户端和服务端的数据一致。

好了,那你们组的高级工程师可能会问,那这个Amplify Mobile SDK内部是大概怎么实现离线还有和服务器端数据一致性的呢?

这个时候组件通信图就派上用场了。话不多说,先上图 (这里我们用 arcentry/app/ 来做示范,这个工具提供了很多AWS相关的服务组件图,比较好上手)。

一致性的呢?

这个时候组件通信图就派上用场了。话不多说,先上图 (这里我们用 arcentry/app/ 来做示范,这个工具提供了很多AWS相关的服务组件图,比较好上手)。

[外链图片转存中…(img-t5656pGG-1642735303097)]

更多推荐

8年老司机教你,如何写出一份“有理有据使人信服,android原生开发教程

本文发布于:2024-02-05 02:33:31,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/34/1673443.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:有理有据   教你   使人   司机   教程

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!